Converts the splash screen to XML format
Removes all programatic calls that modify the layout and uses the XML
resource instead.
See merge request !123
This commit introduces an abstract `BaseContactListAdapter` which provides
most of the adapter logic. The original `ContactListAdapter` extends it to
show date and online status of the contacts.
The new `ContactChooserAdapter` which is used for introductions extends
the `ContactListAdapter` and adds logic for graying out contacts from
different identities than the currently used one.
A new `ContactSelectorAdapter` extends the `BaseContactListAdapter` and
allows to select multiple contacts. It offers a method to return a
collection of all selected `ContactId`s.
This commit also sneaks in an animation when the 'Share Forum' button
is clicked.
Closes#292
Move create forum post and share forum buttons in action bar
According to the designs in #305, the 'create forum post' and 'share forum' buttons will go into the in action bar.
In the spirit of keeping MRs small and to avoid conflicts with #306, I did this first and independently of future work.
This also introduces constants for the `GROUP_ID`, `FORUM_NAME` and `MIN_TIMESTAMP` as they were used for the two buttons.
Closes#313
See merge request !150
Remove avatar code and layout from ConversationActivity and ConversationAdapter
Please note that I have not been able to test this MR on an actual device as I have none at the moment :(
Closes#293
See merge request !148
Show relevant introduction decline responses in the conversation
* If the user has already declined, we don't show that the other
introducee has declined as well. The backend doesn't have that information, so
this is compatible with the principle of showing what we know.
* If the user has already accepted or hasn't yet responded, we now show the
decline response in the private conversation with the introducer. If
the user hasn't yet responded, we hide the accept/decline buttons
in the introduction request message.
Please note that I do not have three devices at the moment to test this MR in its entirety in practice. I created another test which is hopefully sufficient to ensure that the modifications are correct.
Closes#295
See merge request !149
* If the user has already declined, we don't show that the other
introducee has declined as well. The backend doesn't have that information, so
this is compatible with the principle of showing what we know.
* If the user has already accepted or hasn't yet responded, we show the
decline response in the private conversation with the introducer. If
the user hasn't yet responded, we hide the accept/decline buttons
in the introduction request message.
Messages an introducee receives in a `FINISHED` state are now being
ignored and deleted.
Closes#295
* 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
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.
@color/briar_text_primary is used in a lot of places other than the settings screen - if we want to use grey text in the settings screen we'll need to find another way.
Also fixed some misspelled resource names and included the colours from the Briar palette in color.xml.
Transport properties client. #229
This branch moves support for exchanging transport properties from the sync layer to the client layer.
Local properties are stored in an unshared group. When a contact is added, the latest local properties are copied into a group shared with the contact. Whenever the local properties are updated, they're copied into the groups shared with all contacts.
The transport update messages include a unique device ID that prevents collisions between local and remote messages, and will be used in future for multi-device support.
See merge request !80
This commit renames identicons to avatars in field names, and uses an ImageView
derivative to show the identicons, which should make implementing #214 easier.
Support for Destructive Panic Actions
This MR is based on and requires !52.
More details are available in the commit message.
All known issues have now been fixed by new upstream releases.
See merge request !54
PanicKit does distinguish between two kinds of panic responses:
* default responses such as logging out which are non-destructive and
do not require user interaction, so that the basics work without
configuration
* destructive responses such as deleting user data. These require
some sort of authentication to make sure they are not triggered
by malicious apps
The second type of responses is implemented with this commit.
Authentication is done by comparing the package name
which is very weak. It requires the user to opt-in to
destructive responses and to configure from which app
to receive those (since there might be many different panic
trigger apps).
While possible to uninstall an app and install one with the same
package name afterwards, this always triggers notifications to
the user (if the attacker does not have root access).
Still that is no sufficient security for Briar's requirements,
so that TrustedIntents are used as well to make sure that the
app sending the destructive trigger is signed by a signing key
that we specified before. Currently, that is the one from the
GuardianProject and from IilabEngineering who does the Amnesty
International Panic App.
The responsibility of checking that the panic TRIGGER is
legitimate lies with the app responding to the trigger, so Briar
in this case. This commit checks whether the TRIGGER comes from
a trusted app before performing destructive actions,
but does perform the default action even when triggered from
untrusted apps.
Closes#210
Transport properties manager facade, key manager refactoring. #112
Refactoring for #112: decouple the invitation and plugin code from the database with a TransportPropertiesManager facade (which will become a BSP client), and move some key management logic from the invitation code to the KeyManager. Update the integration tests to use the new FooManager facades.
See merge request !49
