briar issueshttps://code.briarproject.org/groups/briar/-/issues2021-12-21T23:12:35Zhttps://code.briarproject.org/briar/briar/-/issues/1589Use consistent scroll behaviour across the app2021-12-21T23:12:35ZakwizgranUse consistent scroll behaviour across the appFollowing the discussion on #713 and other tickets listed below, let's use consistent scroll behaviour across the app.
Related to #713, #872, #1073, #1192, #1200, #1361, #1337, #1467, #1493.Following the discussion on #713 and other tickets listed below, let's use consistent scroll behaviour across the app.
Related to #713, #872, #1073, #1192, #1200, #1361, #1337, #1467, #1493.https://code.briarproject.org/briar/briar/-/issues/1582Pending contact snackbar and add contact FAB are sometimes displaced2022-04-19T11:29:51ZakwizgranPending contact snackbar and add contact FAB are sometimes displacedThe pending contact snackbar sometimes appears in the wrong place, with a blank space below it and overlapping the FAB. After the snackbar is hidden, the FAB doesn't always return to the right position.
![device-2019-06-07-162517](/uplo...The pending contact snackbar sometimes appears in the wrong place, with a blank space below it and overlapping the FAB. After the snackbar is hidden, the FAB doesn't always return to the right position.
![device-2019-06-07-162517](/uploads/9109a6a1d3e0fbeccdb1e25d1c5796b7/device-2019-06-07-162517.png)
![device-2019-06-07-162537](/uploads/01cc37afca368254ff312281f3f8d992/device-2019-06-07-162537.png)
I've seen the first problem on the Huawei Ascend Y330 (Android 4.2.2) and the Vivo Y11 (Android 4.4.4). I've seen the second problem on those phones and also the Honor 8A (Android 9).https://code.briarproject.org/briar/briar/-/issues/1581Add pending contact via ENTER or IME action2020-11-15T18:20:32ZTorsten GroteAdd pending contact via ENTER or IME actionWhen entering the nickname for a pending contact pressing enter or the Go IME action in the soft keyboard should be equivalent to pressing the button.When entering the nickname for a pending contact pressing enter or the Go IME action in the soft keyboard should be equivalent to pressing the button.https://code.briarproject.org/briar/briar/-/issues/1574Consider separating the package structures for bramble-java and bramble-core2020-11-15T18:21:38ZiwakehConsider separating the package structures for bramble-java and bramble-coreConsider using a separate package for ```bramble-java``` (e.g. ```org.briarproject.bramble.java.*```)
Currently, ```bramble-java``` provides the same packages as ```bramble-core```.
Some ```bramble-java``` classes extend package-private...Consider using a separate package for ```bramble-java``` (e.g. ```org.briarproject.bramble.java.*```)
Currently, ```bramble-java``` provides the same packages as ```bramble-core```.
Some ```bramble-java``` classes extend package-private classes from ```bramble-core``` (mostly in bluetooth). Hmm ....
When briar is going to use java >= 9 and provides modules this needs to be addressed anyway.
(I believe briar should be around for many, many new java versions to come ;-)https://code.briarproject.org/briar/briar/-/issues/1569Connection manager could fail to close connection2020-11-15T18:24:37ZakwizgranConnection manager could fail to close connectionWhen the connection manager disposes of the incoming side of a duplex connection, it interrupts the outgoing sync session (if any) so the outgoing session can finish cleanly. If this happens before the outgoing session is created, it won...When the connection manager disposes of the incoming side of a duplex connection, it interrupts the outgoing sync session (if any) so the outgoing session can finish cleanly. If this happens before the outgoing session is created, it won't be interrupted.
If the incoming side of the connection is being disposed of because of an exception then the transport connection will be closed, so the outgoing session should eventually catch an exception when it tries to write to the connection. But if the incoming side of the connection is being disposed of because the end of the stream was reached then the transport connection will be left half-open, so the outgoing session could keep running indefinitely. This might also happen in the case of an exception if there's nothing to send and the transport doesn't require keepalives, which is the case for Bluetooth.
This could result in a dangling connection that's only usable in one direction. As far as I can tell it won't prevent a new connection from being made, or cause issues like !921, because the registration and unregistration of duplex connections is based on the lifetime of the incoming session, not the outgoing session.
The opposite can also happen: if the connection manager disposes of the outgoing side of the connection before the incoming session is created, the incoming session won't be interrupted. This can only happen if an exception has been thrown (in which case the transport connection will be closed, which *should* cause the incoming session to catch an exception eventually), or if the outgoing session has finished cleanly, which only happens if it's interrupted due to the incoming side of the connection being disposed of. So the only possible cause of a bug like !921 in this case would be if closing the connection didn't cause the incoming session to catch an exception (flaky Bluetooth stacks, I'm looking at you).
Labelling this as a bug because it's unintended behaviour, although it's not clear if we need to fix it.https://code.briarproject.org/briar/briar/-/issues/1568Test the effects of dormant mode when operating as a Tor client2020-11-15T18:26:32ZakwizgranTest the effects of dormant mode when operating as a Tor clientTest whether a Briar peer that's not running a hidden service or holding a wake lock can operate as a Tor client (i.e. connect to contacts' hidden services and fetch RSS feeds), and whether this is affected by Tor's dormant mode.Test whether a Briar peer that's not running a hidden service or holding a wake lock can operate as a Tor client (i.e. connect to contacts' hidden services and fetch RSS feeds), and whether this is affected by Tor's dormant mode.https://code.briarproject.org/briar/briar/-/issues/1563DozeView disappears when rotating screen after whitelisting Briar2020-11-15T18:27:59ZakwizgranDozeView disappears when rotating screen after whitelisting BriarSteps to reproduce:
* Use a device with Android 6+
* Ensure Briar isn't whitelisted for doze
* Create a new account
* In the power management setup screen, tap "Allow Connections" and accept the dialog
* Rotate the screen
* Expected: The...Steps to reproduce:
* Use a device with Android 6+
* Ensure Briar isn't whitelisted for doze
* Create a new account
* In the power management setup screen, tap "Allow Connections" and accept the dialog
* Rotate the screen
* Expected: The layout stays the same
* Actual: The "Allow Connections" button (with its check mark and help button) disappears
* Use the back button to return to the password setup screen
* Expected: The layout is the same as before
* Actual: The "Next" button changes to "Create Account"
The unexpected layout changes happen because we re-check whether we're whitelisted.
If the fragment instances are retained across rotations, perhaps the password and doze fragments could remember the whitelisting state when they were first created, and use that to control the text of the password fragment's "Next" / "Create Account" button and the visibilty of DozeView, so that they stay the same after we're whitelisted, while using the current whitelisting state to show/hide the "Allow Connections" button's check mark and enable/disable the power management fragment's "Create Account" button, which are the bits that are supposed to change when we're whitelisted.https://code.briarproject.org/briar/briar/-/issues/1559Avoid using third parties' resources for testing and maybe enable offline tes...2020-11-15T18:28:22ZiwakehAvoid using third parties' resources for testing and maybe enable offline testing```testFeedImportAndRemoval``` uses a third party blog feed for testing.
1) Maybe, rather use briar's own resources instead of Schneier's blog, e.g. simply supply a static test feed on briarproject's server or use https://code.briarproj...```testFeedImportAndRemoval``` uses a third party blog feed for testing.
1) Maybe, rather use briar's own resources instead of Schneier's blog, e.g. simply supply a static test feed on briarproject's server or use https://code.briarproject.org/briar/briar.atom.
2) This way of testing will fail when the testing machine is offline, which is not the aim of the test. So, avoiding internet access here might be a better solution and would also support to introduce test cases for feed content that could trip briar functionality.https://code.briarproject.org/briar/briar/-/issues/1558ViewModelModule is breaking package encapsulation2021-04-30T13:38:33ZTorsten GroteViewModelModule is breaking package encapsulationThe ViewModelModule is breaking package encapsulation. Let's refactor the ViewModel bindings into the respective packages and cleaning them up.The ViewModelModule is breaking package encapsulation. Let's refactor the ViewModel bindings into the respective packages and cleaning them up.https://code.briarproject.org/briar/briar/-/issues/1555Factor out BriarActionBarActivity for ActionBar handling2020-11-15T18:31:40ZTorsten GroteFactor out BriarActionBarActivity for ActionBar handlingFrom https://code.briarproject.org/briar/briar/merge_requests/1035#note_36028
Push action bar handling code up into a BriarActionBarActivity and make current activities using it inherit it.
```java
ActionBar ab = getSupportActionBar();...From https://code.briarproject.org/briar/briar/merge_requests/1035#note_36028
Push action bar handling code up into a BriarActionBarActivity and make current activities using it inherit it.
```java
ActionBar ab = getSupportActionBar();
if (ab != null) {
ab.setDisplayHomeAsUpEnabled(true);
}
```
`onOptionsItemSelected()`https://code.briarproject.org/briar/briar/-/issues/1553Option to revert screen filter setting2020-11-15T18:32:09ZakwizgranOption to revert screen filter settingA user asked for the ability to revert the decision to allow certain apps to draw on top of Briar.A user asked for the ability to revert the decision to allow certain apps to draw on top of Briar.https://code.briarproject.org/briar/briar/-/issues/1544AMOLED dark theme2021-09-23T12:30:59ZakwizgranAMOLED dark themeA user asked for an AMOLED dark theme (i.e. based on pure black).
Related to #976.A user asked for an AMOLED dark theme (i.e. based on pure black).
Related to #976.https://code.briarproject.org/briar/briar/-/issues/1543Make sign-in reminder more prominent2020-11-15T18:50:15ZakwizgranMake sign-in reminder more prominentUser feedback: "Please consider making the sign-in notification more prominent after restart. Sometimes I forget I'm not signed in for hours or even days, a more visible reminder would really help. Splash page after restart maybe?"
Poss...User feedback: "Please consider making the sign-in notification more prominent after restart. Sometimes I forget I'm not signed in for hours or even days, a more visible reminder would really help. Splash page after restart maybe?"
Possibly related to #1458.https://code.briarproject.org/briar/briar/-/issues/1539Retrieving the onion address of a specific contact2020-11-15T18:54:25ZalexRetrieving the onion address of a specific contactHello;
This is more a question than an issue, and it will help many others develop this app.
I was looking for very long hours, for the onion address of the target contact when sending a message.
I followed the 'createMessage()' method ...Hello;
This is more a question than an issue, and it will help many others develop this app.
I was looking for very long hours, for the onion address of the target contact when sending a message.
I followed the 'createMessage()' method and it's usage/declaration but found no clue .
I/WE will be very grateful if you show us the location of these onion addresses to where the packets are sent to;
and how to retrieve them.
Thank you for your time , and again, this is gonna help us develop new features and finally commit them.https://code.briarproject.org/briar/briar/-/issues/1533support Netguard2020-11-15T18:55:42Zbillfromisletasupport NetguardIssue #1284 and #1400 make it clear that users have trouble trusting whether Briar is not leaking on the clearnet. It raises some questions:
* what happens if Orbot is not installed?
* how does Briar work if Tor is enabled and also Net...Issue #1284 and #1400 make it clear that users have trouble trusting whether Briar is not leaking on the clearnet. It raises some questions:
* what happens if Orbot is not installed?
* how does Briar work if Tor is enabled and also Netguard is using transparent proxying to force Briar packets over Tor? On a desktop system, such a scenario would break because the app would be trying to connect to 127.0.0.1:9050 on the WAN. But on Android it functions, which seems to imply that Netguard is being bypassed.
Netguard's *lockdown mode* does not work on Briar apparently because Netguard is being bypassed. If Briar supported a non-Tor configuration, then users could use Netguard to force it over Tor and automatically have more confidence that there are likely no leaks. Although I don't know if netguard and orbot can handle whatever onion addressing Briar uses.https://code.briarproject.org/briar/briar/-/issues/1531Update threat model document2020-11-15T18:57:13ZakwizgranUpdate threat model documentThe [threat model document](https://code.briarproject.org/briar/briar/wikis/threat-model) on the wiki is out of date, and it doesn't mention the goal of concealing the fact that Briar is being used. The document should be updated.The [threat model document](https://code.briarproject.org/briar/briar/wikis/threat-model) on the wiki is out of date, and it doesn't mention the goal of concealing the fact that Briar is being used. The document should be updated.CleopatraCleopatrahttps://code.briarproject.org/briar/briar/-/issues/1525IllegalThreadStateException when starting contact exchange task2021-11-04T11:03:43ZakwizgranIllegalThreadStateException when starting contact exchange task* Android version: 8.1.0
* Briar version: 1.1.5 (8f4c3c4)
* Phone model: OnePlus A0001 (bacon)
* User feedback: "Tried to connect @ 35C3 during the event."
Stacktrace:
```
java.lang.IllegalThreadStateException
at java.lang.Threa...* Android version: 8.1.0
* Briar version: 1.1.5 (8f4c3c4)
* Phone model: OnePlus A0001 (bacon)
* User feedback: "Tried to connect @ 35C3 during the event."
Stacktrace:
```
java.lang.IllegalThreadStateException
at java.lang.Thread.start(Thread.java:724)
at org.briarproject.bramble.contact.ContactExchangeTaskImpl.startExchange(ContactExchangeTaskImpl.java:113)
at org.briarproject.briar.android.keyagreement.ContactExchangeActivity.lambda$startContactExchange$0(ContactExchangeActivity.java:66)
at org.briarproject.briar.android.keyagreement.-$$Lambda$ContactExchangeActivity$fyog59L3yYwzJYBvp0hzYrpHYRo.run(Unknown Source:4)
at org.briarproject.briar.android.controller.DbControllerImpl.lambda$runOnDbThread$0(DbControllerImpl.java:35)
at org.briarproject.briar.android.controller.-$$Lambda$DbControllerImpl$SwC9ndeQwlnMM-VN8yvqCJG1ESc.run(Unknown Source:4)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
at java.lang.Thread.run(Thread.java:764)
```
This exception is thrown if start() is called when the thread isn't in the initial state. A couple of guesses about how this could have happened:
* A ContactExchangeTask instance was reused across multiple contacts
* A ContactExchangeActivity instance received multiple KeyAgreementFinishedEvents, possibly relating to different contacts, each of which cause it to start its ContactExchangeTask
Assigning to myself as I'm refactoring this code for remote contacts.Android 1.4https://code.briarproject.org/briar/briar/-/issues/1524DeadSystemException2022-07-13T14:58:33ZakwizgranDeadSystemException* Android version: 8.1.0
* Briar version: "N/A" (perhaps the package manager is unavailable?)
* Phone model: Motorola Moto G4 Plus (lineage_athene)
Stacktrace:
```
android.os.DeadSystemException
at android.os.PowerManager$WakeLo...* Android version: 8.1.0
* Briar version: "N/A" (perhaps the package manager is unavailable?)
* Phone model: Motorola Moto G4 Plus (lineage_athene)
Stacktrace:
```
android.os.DeadSystemException
at android.os.PowerManager$WakeLock.release(PowerManager.java:1463)
at android.os.PowerManager$WakeLock$1.run(PowerManager.java:1328)
at android.os.Handler.handleCallback(Handler.java:790)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:164)
at android.app.ActivityThread.main(ActivityThread.java:6494)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:440)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807)
```
[Docs](https://developer.android.com/reference/android/os/DeadSystemException.html) for this exception:
> The core Android system has died and is going through a runtime restart. All running apps will be promptly killed.
[This thread](https://groups.google.com/forum/#!topic/android-platform/VVHA6-eRB3c) explains that a runtime restart is a form of soft reboot.
Doesn't look like there's anything we can do here. Creating this ticket for documentation only.https://code.briarproject.org/briar/briar/-/issues/1523RuntimeException: Camera is being used after Camera.release() was called2021-03-24T16:26:51ZakwizgranRuntimeException: Camera is being used after Camera.release() was called* Android version: 6.0.1
* Briar version: 1.1.5 (8f4c3c4)
* Phone models: Samsung GT-I9100 and GT-I9300 (m0xx)
* User feedback: "I could not scan other device. They could scan me. I have Replicant 6.003."
Stacktrace:
```
java.lang.Runti...* Android version: 6.0.1
* Briar version: 1.1.5 (8f4c3c4)
* Phone models: Samsung GT-I9100 and GT-I9300 (m0xx)
* User feedback: "I could not scan other device. They could scan me. I have Replicant 6.003."
Stacktrace:
```
java.lang.RuntimeException: Camera is being used after Camera.release() was called
at android.hardware.Camera.native_getParameters(Native Method)
at android.hardware.Camera.getParameters(Camera.java:1999)
at android.hardware.Camera$EventHandler.handleMessage(Camera.java:1152)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:148)
at android.app.ActivityThread.main(ActivityThread.java:5461)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)
```
We have four reports of this crash, one on the GT-I9100 (running Replicant) and three on the GT-I9300 (probably also running Replicant, as it's the same Android version as the GT-I9100, and the version's too high to be a factory ROM).
This looks like a Replicant bug: camera calls are being made asynchronously. I'll report it upstream. I'm not adding it to the current milestone as there doesn't seem to be anything we can do.https://code.briarproject.org/briar/briar/-/issues/1521Cannot resolve symbol R after build2020-11-15T19:06:59ZnicedeveloperCannot resolve symbol R after buildI'm also encountering "can not resolve symbol R" error
import org.briarproject.briar.R; , where R is in redI'm also encountering "can not resolve symbol R" error
import org.briarproject.briar.R; , where R is in red