Don't connect to Tor if it's already running
For some time now we've had a reliable way of shutting down the Tor process (the __OwningControllerProcess command line argument combined with the TAKEOWNERSHIP command), but TorPlugin#start() still assumes that Tor may already be running. This allows another app to bind the Tor control and SOCKS ports and collect confidential data from Briar (#578). It also allows two Briar instances running on the same device to try to communicate with the same Tor process, which prevents proper shutdown (#572).
This patch prevents the Tor plugin from starting unless it's able to start its own Tor process with the expected control and SOCKS ports. If two Briar instances are running on the same device, only one of them will be able to use Tor. The other should fail to start its Tor plugin and then function normally without Tor access, including normal shutdown.
Fixes#572, #578. Open another ticket if you want two Briar instances on the same device to have their own Tor processes. :-)
See merge request !272
Allow unsubscribing from shared blogs
Only personal blogs from non-contacts can be removed.
This also adds integration tests that check the conditions under which blogs can actually be removed.
Closes#579
See merge request !268
Show Explanatory Graphic Before Scanning QR Codes
Closes#429
See merge request !270
Prevent empty state messages from showing briefly
When we clear a list in `onPause()`, the proper behavior is that the empty state
message is shown, because the list is indeed empty.
However, we will reload the list content again in `onResume()`,
so the fix chosen in this MR is to force showing the progress bar
right after clearing the list.
Closes#576
See merge request !267
When we clear a list in onPause(), the proper behavior is that the empty state
message is shown, because the list is indeed empty.
However, we will reload the list content again in onResume(),
so the fix chosen in this commit is to force showing the progress bar
right after clearing the list.
Closes#576
This commit refactors the code for sharing forums,
so it can be used for sharing blogs as well.
It does not yet include code for responding to blog invitations.
* Implemented in briar-core as a `ScheduledExecutorService`
that gets started when the app starts
* The briar-api has a `FeedManager` interface
that the UI can use to register and unregister feeds
* In this first iteration, feeds are fetched via HTTP(S), not Tor
Closes#484
Use Client Layer Events in ContactListFragment
This prevents trying to access the same group metadata in different groups.
Also, the conversation does not need to be reloaded once introduction messages arrive.
Closes#535
See merge request !254
The forum UI depended on sync layer events such as MessageStateChangedEvent.
Now, the forum client broadcasts its own high-level event (`ForumPostReceivedEvent`)
with the information the UI needs (`ForumPostHeader`).
Closes#310
This prevents trying to access the same group metadata in different groups.
Also, the conversation does not need to be reloaded once introduction messages arrive.
Closes#535
