* force decline when two of our own identities are introduced to each
other
* throw away introduction requests to the same identity
(impossible to trigger from UI)
Closes#284
Don't use inverse style for progress bars. #286
Fixes the appearance of progress bars on Gingerbread, no difference on other platforms. Thanks to @str4d for finding the source of the problem.
See merge request !145
Unit Tests for the Introduction Client
Please note that I based this MR is on top of the introduction UI in !122, because I needed to do some more refactoring on top of the other refactoring ;) The refactoring and the tests are in two separate commits.
An integration test will be added as a separate MR.
This addresses part of #276.
See merge request !136
Introduction UI
This is the user interface for the new introduction feature as specified by @Megalox in #253.
This will close#253
See merge request !122
When devices' clocks are out of sync, it is possible that a response is
shown before the request. This commit makes sure that the timestamp of
responses is always later than the last message in the conversation.
Some wording could be misunderstood to thing introductions were
successful even though they were not. That has been clarified.
A new database transaction was created when getting contacts and local
transport properties. This has been changed to re-use the existing
transaction.
Also addresses minor issues found in review.
The code made the assumption that a session state can be identified by
the unique session ID. However, when multiple identities from the same
device are involved, there are two sessions with the same ID running on
the device.
Hence, a second identifying criteria has to be used to uniquely identify
the correct session. Here, the ID of the group was chosen.
Unfortunately, the session state can not be cached easily anymore
leading to a small performance penalty when getting all messages for the
UI.
Connect to new contacts
The motivation for this change was realising that when we add a new contact, if the Tor plugin has finished publishing its descriptor and stopped polling, we'll never try to connect to that contact via Tor. I decided that instead of making a special case for Tor, we should try to connect to new contacts via all transports.
Changes:
* Don't register outgoing connections until we've read the incoming tag - this prevents the connection indicator from blinking when connecting to a contact who's removed us
* Connect to newly activated contacts using all available transports, without waiting for the poller
* Removed device IDs from transport properties, we don't know how we're going to handle multi-device support yet
See merge request !135
Clean up tests
* Broke up ConstantsTest (#280) - the key encoding parts are now in KeyEncodingAndParsingTest, the message encoding parts are in MessageSizeIntegrationTest
* Renamed the other integration tests in briar-android-tests
* Moved the integration tests in briar-android-tests to the top-level package, as they all involve code from multiple packages
* Separated DatabaseExecutorModule from DatabaseModule so we can use a different @DatabaseExecutor in integration tests
* Merged AppModule with AndroidModule (@ernir, this touches code you're working on but I don't think there are any conflicts)
* Renamed some TestUtils methods for consistency
* Used TestUtils.getRandomBytes() where applicable
Fixes#280.
See merge request !133
Close transport connection if tag isn't recognised. #281
Factored out common code from various DuplexTransportConnection implementations into an abstract superclass, and changed the logic for closing connections so that connections with unrecognised tags are closed immediately. This prevents deleted contacts from thinking they're connected to us when they're not.
See merge request !132
Create local state for clients at startup. #279
Most of the clients we've written so far use private groups shared with individual contacts and/or a local group that's not shared with anyone. To make it easier to ensure that the necessary groups exist when we need them, this patch allows clients to register startup hooks for creating their local state.
Fixes#279.
See merge request !131
Don't allow reentrant transactions
The database's transaction lock is reentrant, meaning that a thread that's already holding the lock can acquire it again. This would allow a thread that already has a transaction in progress to start another transaction, which could cause transaction isolation issues and/or lock timeouts on the database's internal locks.
Check that the current thread isn't already holding the lock when starting a transaction.
See merge request !127
Contact Introduction Backend
This MR allows you to introduce two of your contacts to each other. They both will receive an introduction with an optional message and then can accept or refuse the introduction which is presented as a notification.
When reviewing, I propose to review the individual commits separately as I took great care to split functional independent parts into separate commits. You might also want to have a look at the [Introduction Client Wiki page](https://code.briarproject.org/akwizgran/briar/wikis/IntroductionClient) to better understand what is going on before looking into the actual code.
Protocol sessions and states are not yet deleted and the UI is still missing (#253). In order to practically test this feature, the UI from !122 is needed.
See merge request !116
BQP with QR codes
This MR implements BQP for key agreement over short-range transports. It also implements the Android UI for using BQP with QR codes.
Closes#117.
See merge request !84
The database's transaction lock is reentrant, meaning that a thread that's already holding the lock can acquire it again. This would allow a thread that already has a transaction in progress to start another transaction, which could cause transaction isolation issues and/or lock timeouts on the database's internal locks.
Check that the current thread isn't already holding the lock when starting a transaction.
