Server-side code for accepting crash reports and feedback
* Moved some shared code for copying InputStreams to OutputStreams into a utility class
* Modified the dev report sender to send one report per connection
* Easier to handle on the server side
* If the connection fails after sending any reports, they don't need to be resent
* Tor will reuse the circuit, so it's cheap
* Added server-side code for accepting dev reports
* We need to protect the server's resources from DoS attacks
* Reports can't be larger than 1 MB
* Connections are limited to an average rate of one per minute
* The rate limiter uses a token bucket to allow bursts of up to 1,000 connections
* If the rate limit is exceeded, connection attempts will fail - clients will retry next time they sign in
* The limits can be raised when we move to a bigger server (and when we have some users)
See merge request !288
Fix two crashes when scanning QR codes
One crash was two due the `Context` being `null` and the other due to the camera being opened within an `AsyncTask`.
Closes#583
See merge request !282
Group strings and remove unused resources
Before I grouped the strings, I removed unused resources as well to not group things that are not being used anymore.
The grouping tries to follow a normal usage lifecycle of the app where the user works their way down the navigation drawer and explores all features in one area.
Closes#342
See merge request !277
Update Tor assets if they're older than the APK
Extract the Tor binary, GeoIP database and config file from the APK if they haven't been extracted since the APK was last updated.
On the Galaxy Nexus, skipping extraction of the binary if it's already up to date shaves about 1.5 seconds off the Tor plugin's startup time.
Closes#582.
Depends on !272.
See merge request !273
Care for lint errors
No more general disabling of abortOnError
Resolved all *errors* beside language ones MissingTranslation & ImpliedQuantity
Issue context: #567
See merge request !274
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
