briar issueshttps://code.briarproject.org/briar/briar/-/issues2020-11-15T17:25:51Zhttps://code.briarproject.org/briar/briar/-/issues/1648AssertionError when creating key agreement error fragment2020-11-15T17:25:51ZakwizgranAssertionError when creating key agreement error fragment* Android version: 7.0
* Phone model: Xiaomi Redmi Note 4
* Briar version: 1.1.6 (4d26628)
* Locale: az_AZ
* User set locale: false
Stacktrace:
```
java.lang.AssertionError
at org.briarproject.briar.android.util.UiUtils.onSingle...* Android version: 7.0
* Phone model: Xiaomi Redmi Note 4
* Briar version: 1.1.6 (4d26628)
* Locale: az_AZ
* User set locale: false
Stacktrace:
```
java.lang.AssertionError
at org.briarproject.briar.android.util.UiUtils.onSingleLinkClick(UiUtils.java:200)
at org.briarproject.briar.android.keyagreement.ContactExchangeErrorFragment.onCreateView(ContactExchangeErrorFragment.java:70)
at android.support.v4.app.Fragment.performCreateView(Fragment.java:2439)
at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1460)
at android.support.v4.app.FragmentManagerImpl.moveFragmentToExpectedState(FragmentManager.java:1784)
at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1852)
at android.support.v4.app.BackStackRecord.executeOps(BackStackRecord.java:802)
at android.support.v4.app.FragmentManagerImpl.executeOps(FragmentManager.java:2625)
at android.support.v4.app.FragmentManagerImpl.executeOpsTogether(FragmentManager.java:2411)
at android.support.v4.app.FragmentManagerImpl.removeRedundantOperationsAndExecute(FragmentManager.java:2366)
at android.support.v4.app.FragmentManagerImpl.execPendingActions(FragmentManager.java:2273)
at android.support.v4.app.FragmentManagerImpl$1.run(FragmentManager.java:733)
at android.os.Handler.handleCallback(Handler.java:754)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:165)
at android.app.ActivityThread.main(ActivityThread.java:6375)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:912)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:802)
```
The assertion is that the text contains a single link. I'm guessing that the translation for az_AZ may be missing the link. Perhaps we should return silently in that case instead of throwing an error?Android 1.2Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1643Possible Controller Memory Leaks2019-11-07T16:33:48ZTorsten GrotePossible Controller Memory LeaksNot sure I understand these traces correctly, but they seem to indicate that our controllers are leaking their listeners?
```
019-10-28 15:47:18.340 D/LeakCanary: ┬
2019-10-28 15:47:18.340 D/LeakCanary: ├─ android.view.inputmethod.Input...Not sure I understand these traces correctly, but they seem to indicate that our controllers are leaking their listeners?
```
019-10-28 15:47:18.340 D/LeakCanary: ┬
2019-10-28 15:47:18.340 D/LeakCanary: ├─ android.view.inputmethod.InputMethodManager
2019-10-28 15:47:18.340 D/LeakCanary: │ Leaking: NO (InputMethodManager↓ is not leaking and a class is never leaking)
2019-10-28 15:47:18.341 D/LeakCanary: │ GC Root: System class
2019-10-28 15:47:18.341 D/LeakCanary: │ ↓ static InputMethodManager.sInstance
2019-10-28 15:47:18.341 D/LeakCanary: ├─ android.view.inputmethod.InputMethodManager
2019-10-28 15:47:18.341 D/LeakCanary: │ Leaking: NO (FabSpeedDial↓ is not leaking and InputMethodManager is a singleton)
2019-10-28 15:47:18.341 D/LeakCanary: │ ↓ InputMethodManager.mNextServedView
2019-10-28 15:47:18.341 D/LeakCanary: ├─ io.github.kobakei.materialfabspeeddial.FabSpeedDial
2019-10-28 15:47:18.341 D/LeakCanary: │ Leaking: NO (NavDrawerActivity↓ is not leaking and View attached)
2019-10-28 15:47:18.341 D/LeakCanary: │ mContext instance of org.briarproject.briar.android.navdrawer.NavDrawerActivity with mDestroyed = false
2019-10-28 15:47:18.341 D/LeakCanary: │ View.parent androidx.coordinatorlayout.widget.CoordinatorLayout attached as well
2019-10-28 15:47:18.341 D/LeakCanary: │ View#mParent is set
2019-10-28 15:47:18.341 D/LeakCanary: │ View#mAttachInfo is not null (view attached)
2019-10-28 15:47:18.341 D/LeakCanary: │ View.mWindowAttachCount = 1
2019-10-28 15:47:18.341 D/LeakCanary: │ ↓ FabSpeedDial.mContext
2019-10-28 15:47:18.341 D/LeakCanary: ├─ org.briarproject.briar.android.navdrawer.NavDrawerActivity
2019-10-28 15:47:18.341 D/LeakCanary: │ Leaking: NO (Activity#mDestroyed is false)
2019-10-28 15:47:18.341 D/LeakCanary: │ ↓ NavDrawerActivity.activityComponent
2019-10-28 15:47:18.341 D/LeakCanary: │ ~~~~~~~~~~~~~~~~~
2019-10-28 15:47:18.341 D/LeakCanary: ├─ org.briarproject.briar.android.activity.DaggerActivityComponent
2019-10-28 15:47:18.341 D/LeakCanary: │ Leaking: UNKNOWN
2019-10-28 15:47:18.341 D/LeakCanary: │ ↓ DaggerActivityComponent.provideFeedControllerProvider
2019-10-28 15:47:18.341 D/LeakCanary: │ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2019-10-28 15:47:18.341 D/LeakCanary: ├─ dagger.internal.DoubleCheck
2019-10-28 15:47:18.341 D/LeakCanary: │ Leaking: UNKNOWN
2019-10-28 15:47:18.341 D/LeakCanary: │ ↓ DoubleCheck.instance
2019-10-28 15:47:18.341 D/LeakCanary: │ ~~~~~~~~
2019-10-28 15:47:18.341 D/LeakCanary: ├─ org.briarproject.briar.android.blog.FeedControllerImpl
2019-10-28 15:47:18.341 D/LeakCanary: │ Leaking: UNKNOWN
2019-10-28 15:47:18.341 D/LeakCanary: │ ↓ FeedControllerImpl.listener
2019-10-28 15:47:18.341 D/LeakCanary: │ ~~~~~~~~
2019-10-28 15:47:18.341 D/LeakCanary: ╰→ org.briarproject.briar.android.blog.FeedFragment
2019-10-28 15:47:18.341 D/LeakCanary: Leaking: YES (Fragment#mFragmentManager is null and ObjectWatcher was watching this)
2019-10-28 15:47:18.341 D/LeakCanary: key = a5208355-72cd-4f49-80f3-3f6684261091
2019-10-28 15:47:18.341 D/LeakCanary: watchDurationMillis = 2266
2019-10-28 15:47:18.341 D/LeakCanary: retainedDurationMillis = -1
2019-10-28 15:47:18.341 D/LeakCanary: , retainedHeapByteSize=2548), ApplicationLeak(className=org.briarproject.briar.android.privategroup.list.GroupListFragment, leakTrace=
```
```
2019-10-28 15:47:18.341 D/LeakCanary: ┬
2019-10-28 15:47:18.341 D/LeakCanary: ├─ android.view.inputmethod.InputMethodManager
2019-10-28 15:47:18.341 D/LeakCanary: │ Leaking: NO (InputMethodManager↓ is not leaking and a class is never leaking)
2019-10-28 15:47:18.341 D/LeakCanary: │ GC Root: System class
2019-10-28 15:47:18.341 D/LeakCanary: │ ↓ static InputMethodManager.sInstance
2019-10-28 15:47:18.341 D/LeakCanary: ├─ android.view.inputmethod.InputMethodManager
2019-10-28 15:47:18.341 D/LeakCanary: │ Leaking: NO (FabSpeedDial↓ is not leaking and InputMethodManager is a singleton)
2019-10-28 15:47:18.341 D/LeakCanary: │ ↓ InputMethodManager.mNextServedView
2019-10-28 15:47:18.341 D/LeakCanary: ├─ io.github.kobakei.materialfabspeeddial.FabSpeedDial
2019-10-28 15:47:18.341 D/LeakCanary: │ Leaking: NO (NavDrawerActivity↓ is not leaking and View attached)
2019-10-28 15:47:18.341 D/LeakCanary: │ mContext instance of org.briarproject.briar.android.navdrawer.NavDrawerActivity with mDestroyed = false
2019-10-28 15:47:18.341 D/LeakCanary: │ View.parent androidx.coordinatorlayout.widget.CoordinatorLayout attached as well
2019-10-28 15:47:18.341 D/LeakCanary: │ View#mParent is set
2019-10-28 15:47:18.341 D/LeakCanary: │ View#mAttachInfo is not null (view attached)
2019-10-28 15:47:18.341 D/LeakCanary: │ View.mWindowAttachCount = 1
2019-10-28 15:47:18.341 D/LeakCanary: │ ↓ FabSpeedDial.mContext
2019-10-28 15:47:18.341 D/LeakCanary: ├─ org.briarproject.briar.android.navdrawer.NavDrawerActivity
2019-10-28 15:47:18.341 D/LeakCanary: │ Leaking: NO (Activity#mDestroyed is false)
2019-10-28 15:47:18.341 D/LeakCanary: │ ↓ NavDrawerActivity.activityComponent
2019-10-28 15:47:18.341 D/LeakCanary: │ ~~~~~~~~~~~~~~~~~
2019-10-28 15:47:18.341 D/LeakCanary: ├─ org.briarproject.briar.android.activity.DaggerActivityComponent
2019-10-28 15:47:18.341 D/LeakCanary: │ Leaking: UNKNOWN
2019-10-28 15:47:18.341 D/LeakCanary: │ ↓ DaggerActivityComponent.provideGroupListControllerProvider
2019-10-28 15:47:18.341 D/LeakCanary: │ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2019-10-28 15:47:18.341 D/LeakCanary: ├─ dagger.internal.DoubleCheck
2019-10-28 15:47:18.341 D/LeakCanary: │ Leaking: UNKNOWN
2019-10-28 15:47:18.341 D/LeakCanary: │ ↓ DoubleCheck.instance
2019-10-28 15:47:18.341 D/LeakCanary: │ ~~~~~~~~
2019-10-28 15:47:18.341 D/LeakCanary: ├─ org.briarproject.briar.android.privategroup.list.GroupListControllerImpl
2019-10-28 15:47:18.341 D/LeakCanary: │ Leaking: UNKNOWN
2019-10-28 15:47:18.341 D/LeakCanary: │ ↓ GroupListControllerImpl.listener
2019-10-28 15:47:18.341 D/LeakCanary: │ ~~~~~~~~
2019-10-28 15:47:18.341 D/LeakCanary: ╰→ org.briarproject.briar.android.privategroup.list.GroupListFragment
2019-10-28 15:47:18.341 D/LeakCanary: Leaking: YES (Fragment#mFragmentManager is null and ObjectWatcher was watching this)
2019-10-28 15:47:18.341 D/LeakCanary: key = dd89f2de-3b6e-40e3-9d63-2484dea5702a
2019-10-28 15:47:18.341 D/LeakCanary: watchDurationMillis = 30199
2019-10-28 15:47:18.341 D/LeakCanary: retainedDurationMillis = 25198
2019-10-28 15:47:18.341 D/LeakCanary: , retainedHeapByteSize=181665)], libraryLeaks=[])
```Android 1.2Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1634Raise target API level to 282019-10-22T15:14:15ZakwizgranRaise target API level to 28From 1 November Google Play requires all updates to target API 28 or higher. Even if 1.2 is released before 1 November it might make sense to raise the target API level for that release so we don't have to worry about it later if we need...From 1 November Google Play requires all updates to target API 28 or higher. Even if 1.2 is released before 1 November it might make sense to raise the target API level for that release so we don't have to worry about it later if we need to make an urgent bugfix release.Android 1.2akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1633Raise minimum API level to 162019-10-14T15:37:45ZakwizgranRaise minimum API level to 16Devices running API 15 account for less than 1/1000 of our active installs according to Google Play.
Removing the non-PIE 32-bit binaries for Tor and obfsproxy, which are only needed for API 15, will make room for the 64-bit PIE binarie...Devices running API 15 account for less than 1/1000 of our active installs according to Google Play.
Removing the non-PIE 32-bit binaries for Tor and obfsproxy, which are only needed for API 15, will make room for the 64-bit PIE binaries. There may also be some conditional code we can remove. One of the test devices will have to be retired. :crying_cat_face:Android 1.2Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1632Unable to re-share Shareable2019-10-14T14:29:57ZTorsten GroteUnable to re-share ShareableA leaves, sends `REMOTE_LEAVE` to B and goes into `LOCAL_LEFT` state. Now B also leaves and since it got the leave message from A, it does nothing, just moves into `START` state. Provided that A and B get access to the forum again throug...A leaves, sends `REMOTE_LEAVE` to B and goes into `LOCAL_LEFT` state. Now B also leaves and since it got the leave message from A, it does nothing, just moves into `START` state. Provided that A and B get access to the forum again through other contacts, B can still share the forum with A while A is permanently blocked from sharing it again with B, because it is stuck in the `LOCAL_LEFT` state.
https://code.briarproject.org/briar/briar/commits/shareable-re-sharing-issueAndroid 1.2Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1629Support for deleting a subset of all conversation messages2019-10-28T16:53:17ZTorsten GroteSupport for deleting a subset of all conversation messagesSubtask of #68
* [x] method to `ConversationClient` that returns a set of `MessageId`s it is responsible for
* [x] method to `ConversationClient` to delete a set of messages identified by `MessageId`
* [x] method to `ConversationManager...Subtask of #68
* [x] method to `ConversationClient` that returns a set of `MessageId`s it is responsible for
* [x] method to `ConversationClient` to delete a set of messages identified by `MessageId`
* [x] method to `ConversationManager` for deleting a set of messages identified by `MessageId`. This will intersect the IDs from the clients with IDs to be deleted and as the client to only delete this intersection
Implementation plan for deleting messages in ConversationClients builds on work done in #1627.
* parse message visibility for session's messages (true if visible in UI)
* when looping over all sessions check that all visible messages were selected for deletion, if not, do not delete sessionAndroid 1.2Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1628Multi-select conversion messages to delete2019-11-08T15:58:43ZTorsten GroteMulti-select conversion messages to deleteSubtask of #68
Add multi-selection of messages to conversation view and add a delete action for ActionMode.
If we migrated to AndroidX when working on this ticket, we could use the [androidx.recyclerview.selection](https://developer.an...Subtask of #68
Add multi-selection of messages to conversation view and add a delete action for ActionMode.
If we migrated to AndroidX when working on this ticket, we could use the [androidx.recyclerview.selection](https://developer.android.com/reference/androidx/recyclerview/selection/package-summary) library. Article: https://proandroiddev.com/a-guide-to-recyclerview-selection-3ed9f2381504Android 1.2Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1627Delete all invitation/introduction messages for completed sessions2019-10-14T12:57:58ZTorsten GroteDelete all invitation/introduction messages for completed sessionsSubtask of #68
* [x] Implement the no-ops from #1625 in the remaining `ConversationClient`s that deletes all completed sessions. A session is complete if it is in a completed state and all messages have been ACKed.
* [x] Introductio...Subtask of #68
* [x] Implement the no-ops from #1625 in the remaining `ConversationClient`s that deletes all completed sessions. A session is complete if it is in a completed state and all messages have been ACKed.
* [x] Introductions: If the session isn't in the start state or there are sent-but-unacked messages, refuse to delete the session. Otherwise delete all messages and their metadata, but leave the session storage message
* [x] Blogs/Forums: If the session has an invite available to answer, refuse to delete the session. Otherwise delete all visible messages and their metadata, but leave invisible messages and the session storage message
* [x] Private Groups: If the session has an invite available to answer, refuse to delete the session. Otherwise delete all visible messages and their metadata, but leave invisible messages and the session storage message
* [x] Update UI dialog to explain that ongoing invitations/introductions can't be deleted
Implementation plan:
* look up all the message metadata
* look up all message states
* loop over all message states and create hash set of message ids that are sent but not acked
* loop over all the message metadata finding session storage objects messages and creating session objects
* loop over it again assigning protocol messages to their sessions
* loop over all sessions: If session state is completed and all messages were ACKed, delete entire session, else remember non-deletion
* return false if at least one session could not be deletedAndroid 1.2Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1626UI for partial conversation message deletion2019-10-09T12:17:31ZTorsten GroteUI for partial conversation message deletionSubtask of #68
* [x] Add menu item for triggering deletion of all messages
* [x] Show dialog (if needed) explaining that invitation/introduction messages can't be deletedSubtask of #68
* [x] Add menu item for triggering deletion of all messages
* [x] Show dialog (if needed) explaining that invitation/introduction messages can't be deletedAndroid 1.2Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1625ConversationClient method for message deletion2019-10-07T14:45:20ZTorsten GroteConversationClient method for message deletionSubtask of #68
* [x] Add `ConversationManager` method for deleting all conversation messages which delegates to conversation clients
* [x] Add `ConversationClient` method for deleting all messages that returns true if all messages were ...Subtask of #68
* [x] Add `ConversationManager` method for deleting all conversation messages which delegates to conversation clients
* [x] Add `ConversationClient` method for deleting all messages that returns true if all messages were delete or false if not (because they are invitation/introduction messages that can't be deleted).
* [x] Add real implementation for `MessagingManager`, no-op implementations for other clients (just return false)Android 1.2Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1624Investigate whether IPv6 link-local addresses work over consumer wifi networks2020-06-30T15:22:04ZakwizgranInvestigate whether IPv6 link-local addresses work over consumer wifi networks[Meshenger](https://github.com/meshenger-app/meshenger-android/blob/master/docs/Documentation.md) uses IPv6 link-local addresses to communicate with peers on the same LAN. A device's link-local address is derived from its MAC address, so...[Meshenger](https://github.com/meshenger-app/meshenger-android/blob/master/docs/Documentation.md) uses IPv6 link-local addresses to communicate with peers on the same LAN. A device's link-local address is derived from its MAC address, so it's the same on every LAN.
If this works reliably on consumer wifi networks it would have a major advantage over our current approach: contacts that connect to a new network would be able to connect to each other immediately without first exchanging updated transport properties via some other transport.
If it works when one of the devices is providing a wifi hotspot, it might also provide an alternative to #1328.
Related to #28, #1193, #1328.Android 1.2akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1621Contact link disappears after selecting and copying on API 15-172021-02-12T13:04:27ZakwizgranContact link disappears after selecting and copying on API 15-17On the emulator running API 15-17, the user's own contact link disappears when selected, and doesn't reappear after the selection has been copied. The link reappears when the screen is rotated.
This happens with both software and hardwa...On the emulator running API 15-17, the user's own contact link disappears when selected, and doesn't reappear after the selection has been copied. The link reappears when the screen is rotated.
This happens with both software and hardware rendering, making me think it's unlikely to be an emulator bug. It doesn't happen on the emulator running API 18+. Assigning to myself to reproduce on a real device.Android 1.2IvanaIvanahttps://code.briarproject.org/briar/briar/-/issues/1612Latest version in F-Droid main repo is 1.2.102021-03-11T12:22:30ZakwizgranLatest version in F-Droid main repo is 1.2.10~~The F-Droid main repo hasn't picked up any of our releases since 1.1.6 in March.~~
~~The F-Droid build server couldn't reproduce the 1.2.9 release.~~
~~F-Droid couldn't parse the version numbers in the 1.2.11 - 1.2.13 releases.~~
F-...~~The F-Droid main repo hasn't picked up any of our releases since 1.1.6 in March.~~
~~The F-Droid build server couldn't reproduce the 1.2.9 release.~~
~~F-Droid couldn't parse the version numbers in the 1.2.11 - 1.2.13 releases.~~
F-Droid failed to reproduce the 1.2.16 build due to differences in the Tor and obfs4proxy binaries.Android 1.2akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1610Pending contact list shows "no internet connection" when empty2019-11-06T09:54:17ZakwizgranPending contact list shows "no internet connection" when emptyIf the pending contact list is opened concurrently with the last pending contact being removed (unlikely but possible - it happened to me accidentally while testing !1152) then the "no internet connection" snackbar is shown even though t...If the pending contact list is opened concurrently with the last pending contact being removed (unlikely but possible - it happened to me accidentally while testing !1152) then the "no internet connection" snackbar is shown even though the app is connected to Tor.
![device-2019-07-01-170738](/uploads/b314816dbe11b6a327f81498adafa442/device-2019-07-01-170738.png)Android 1.2Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1590IllegalStateException: Cannot invoke setValue on a background thread2019-06-18T11:58:53ZakwizgranIllegalStateException: Cannot invoke setValue on a background threadCrashed when sending a message to a new contact.
Stacktrace:
```
java.lang.IllegalStateException: Cannot invoke setValue on a background thread
at android.arch.lifecycle.LiveData.assertMainThread(LiveData.java:435)
at androi...Crashed when sending a message to a new contact.
Stacktrace:
```
java.lang.IllegalStateException: Cannot invoke setValue on a background thread
at android.arch.lifecycle.LiveData.assertMainThread(LiveData.java:435)
at android.arch.lifecycle.LiveData.setValue(LiveData.java:279)
at android.arch.lifecycle.MutableLiveData.setValue(MutableLiveData.java:33)
at org.briarproject.briar.android.attachment.AttachmentCreator.resetState(AttachmentCreator.java:183)
at org.briarproject.briar.android.attachment.AttachmentCreator.onAttachmentsSent(AttachmentCreator.java:164)
at org.briarproject.briar.android.conversation.ConversationViewModel.storeMessage(ConversationViewModel.java:295)
at org.briarproject.briar.android.conversation.ConversationViewModel.lambda$createMessage$8$ConversationViewModel(ConversationViewModel.java:286)
at org.briarproject.briar.android.conversation.-$$Lambda$ConversationViewModel$1LsoWDT2XwB7wPxBWawY1IIRFR0.run(Unknown Source:10)
at org.briarproject.bramble.TimeLoggingExecutor.lambda$execute$0$TimeLoggingExecutor(TimeLoggingExecutor.java:36)
at org.briarproject.bramble.-$$Lambda$TimeLoggingExecutor$Bqrtbsq_8LcRPoTWBOef6xh7gJg.run(Unknown Source:6)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:784)
```
This is my fault - I recommended moving the onAttachmentsSent() call to a place that's on the UI thread on my branch, forgetting that it's on the crypto executor on master.Android 1.2akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1584Race condition in IntroductionIntegrationTest2019-11-06T09:47:39ZakwizgranRace condition in IntroductionIntegrationTestIntroductionIntegrationTest sometimes fails randomly (see https://code.briarproject.org/briar/briar/-/jobs/3638). Looks like the same underlying cause as #1560.IntroductionIntegrationTest sometimes fails randomly (see https://code.briarproject.org/briar/briar/-/jobs/3638). Looks like the same underlying cause as #1560.Android 1.2Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1583Remote contact layout is too tall for small screens2019-09-27T14:58:54ZakwizgranRemote contact layout is too tall for small screensThe layouts for LinkExchangeFragment and NicknameFragment don't work well on small screens: for LinkExchangeFragment the Continue button is mostly offscreen, and for NicknameFragment the nickname field and Add Contact button are entirely...The layouts for LinkExchangeFragment and NicknameFragment don't work well on small screens: for LinkExchangeFragment the Continue button is mostly offscreen, and for NicknameFragment the nickname field and Add Contact button are entirely offscreen, making it unclear what the user's meant to do next.
Screenshots come from the Huawei Ascend Y330 (480x800 px).
![device-2019-06-08-101532](/uploads/83053a95ddee99302b91b0b79c659113/device-2019-06-08-101532.png)
![device-2019-06-08-101545](/uploads/33ff8c3896463d1be367479d956b781b/device-2019-06-08-101545.png)
Possible workarounds:
* Scroll to the bottom of each fragment when it's opened
* Remove the illustration from NicknameActivity or make it smaller
* Move the stepper to the bottom, below the button (I know we decided it was better at the top, and apart from this issue I'd prefer to keep it there)
* Divide the workflow into three steps rather than two: send link, enter link, and enter nickname (this has disadvantages for the flows where the user opens the activity by sharing a link from another app, or with a link already in the clipboard)Android 1.2Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1579Replace pending contact remove button with icon2019-06-08T09:44:58ZTorsten GroteReplace pending contact remove button with iconIt should use the same icon as the rss feeds.It should use the same icon as the rss feeds.Android 1.2Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1576IllegalStateException when sharing remote contact link2019-06-10T16:33:49ZakwizgranIllegalStateException when sharing remote contact linkThe following crash happens when sharing a remote contact link from another app while signed out:
```
java.lang.IllegalStateException
at org.briarproject.bramble.db.H2Database.createConnection(H2Database.java:94)
at org....The following crash happens when sharing a remote contact link from another app while signed out:
```
java.lang.IllegalStateException
at org.briarproject.bramble.db.H2Database.createConnection(H2Database.java:94)
at org.briarproject.bramble.db.JdbcDatabase.startTransaction(JdbcDatabase.java:547)
at org.briarproject.bramble.db.JdbcDatabase.startTransaction(JdbcDatabase.java:96)
at org.briarproject.bramble.db.DatabaseComponentImpl.startTransaction(DatabaseComponentImpl.java:160)
at org.briarproject.bramble.db.DatabaseComponentImpl.transactionWithResult(DatabaseComponentImpl.java:207)
at org.briarproject.bramble.contact.ContactManagerImpl.getHandshakeLink(ContactManagerImpl.java:138)
at org.briarproject.briar.android.contact.add.remote.AddContactViewModel.lambda$loadHandshakeLink$0$AddContactViewModel(AddContactViewModel.java:62)
```
The cause is similar to #1482: we're accessing the DB before knowing whether we're signed in.
The solution we created for #1482 requires us to defer all database work until onResume(), and check isSignedIn() before doing any database work. The fact that we've seen a second bug so soon after fixing the first may suggest that it's going to be hard to remember those constraints in every case.
Another possible workaround would be for H2Database#createConnection() to throw a DbClosedException rather than an IllegalStateException if there's no DB key.Android 1.2Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1572Transport icons use inconsistent information to determine plugin state2020-06-30T15:21:35ZakwizgranTransport icons use inconsistent information to determine plugin stateThe transport icons in the nav drawer use two sources of information to determine which transports are active: `Plugin#isRunning()` and TransportEnabled/DisabledEvents. But these sources can be inconsistent. For example, `BluetoothPlugin...The transport icons in the nav drawer use two sources of information to determine which transports are active: `Plugin#isRunning()` and TransportEnabled/DisabledEvents. But these sources can be inconsistent. For example, `BluetoothPlugin#isRunning()` returns true if the adapter is enabled, regardless of whether contact connections are enabled, but the plugin doesn't broadcast TransportEnabledEvents unless contact connections are enabled. This leads to the following bug:
* Start Briar with default settings and the Bluetooth adapter enabled
* The Bluetooth icon is active because isRunning() returns true
* Disable the Bluetooth adapter
* The Bluetooth icon is inactive because a TransportDisabledEvent was broadcast
* Re-enable the Bluetooth adapter
* The Bluetooth icon remains inactive because no TransportEnabledEvent was broadcast
Arguably the real issue here is that plugins (or the manager) should provide an isEnabled() method that follows the enabled/disabled events. This could easily be implemented in the manager, and could also be used to suppress redundant enabled/disabled events, such as those broadcast when toggling the Bluetooth adapter state without contact connections enabled.
Related to discussion of plugin states on #185.Android 1.2akwizgranakwizgran