briar issueshttps://code.briarproject.org/briar/briar/-/issues2019-02-21T10:34:00Zhttps://code.briarproject.org/briar/briar/-/issues/1100Setup wizard page for Samsung's power manager2019-02-21T10:34:00ZakwizgranSetup wizard page for Samsung's power managerhttps://gitlab.com/axet/android-library/blob/master/src/main/java/com/github/axet/androidlibrary/widgets/OptimizationPreferenceCompat.java
https://stackoverflow.com/questions/37205106/how-do-i-avoid-that-my-app-enters-optimization-on-sa...https://gitlab.com/axet/android-library/blob/master/src/main/java/com/github/axet/androidlibrary/widgets/OptimizationPreferenceCompat.java
https://stackoverflow.com/questions/37205106/how-do-i-avoid-that-my-app-enters-optimization-on-samsung-devices
https://stackoverflow.com/questions/34074955/android-exact-alarm-is-always-3-minutes-off/34085645#34085645
Looks like the situation is similar to Huawei - we create an intent for the power manager's whitelisting activity, and if the intent is callable, we're on an affected device. I haven't looked into whether we can detect whether we're already whitelisted.
Apparently the intent's package and class name should be:
* `"com.samsung.android.sm", "com.samsung.android.sm.ui.battery.BatteryActivity"` on Android L
* `"com.samsung.android.lool", "com.samsung.android.sm.ui.battery.BatteryActivity"` on Android N
According to one of the StackOverflow answers, keywords like "alert" and "clock" in the package name will cause the app to be automatically whitelisted. Good grief...Android 1.1akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/268Research how to deal with doze mode on Android 62019-02-21T10:34:00ZakwizgranResearch how to deal with doze mode on Android 6Android 6 has a new doze mode when the device is idle. Apps can't access the network in doze mode, except during short wakeup periods. This will kill our ability to receive messages while the device is idle. The recommended workaround is...Android 6 has a new doze mode when the device is idle. Apps can't access the network in doze mode, except during short wakeup periods. This will kill our ability to receive messages while the device is idle. The recommended workaround is to use Google Cloud Messaging, which obviously won't work for us.
We may need to prompt the user to add Briar to a whitelist. Thanks Google! Love ya!
http://developer.android.com/training/monitoring-device-state/doze-standby.htmlAndroid 1.1akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/978Add preference for using tor only when having power2019-02-21T10:34:01ZGreg TroxelAdd preference for using tor only when having power(Sorry if this is a dup; I searched but am not confident.)
I just built and installed Briar after being absent for a while. I see there's a preference for using tor never, on wifi, and on cellular. That's great for some, but doesn't a...(Sorry if this is a dup; I searched but am not confident.)
I just built and installed Briar after being absent for a while. I see there's a preference for using tor never, on wifi, and on cellular. That's great for some, but doesn't address my problem. I realize there is tension with UX and complicated config, but given that having a HS is very very costly power wise, and outbound tor is somewhat costly, I'd like to see a config for "Use Tor when not charging" that is "no, outbound only, outbound and inbound". This would probably let me start running briar, and I suspect would let others do so as well.Android 1.1Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1477Implement UX for finding out whether contacts support image attachments2019-02-21T10:34:38ZakwizgranImplement UX for finding out whether contacts support image attachmentsImplement the design from #1476 for finding out whether each contact supports image attachments.
Subtask of #1438.Implement the design from #1476 for finding out whether each contact supports image attachments.
Subtask of #1438.Android 1.3Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1497Check whether ongoing notification's priority and importance need to be incre...2019-02-21T12:41:39ZakwizgranCheck whether ongoing notification's priority and importance need to be increasedThis blog post describes some "guidelines" for a foreground service's ongoing notification:
https://android-developers.googleblog.com/2018/12/effective-foreground-services-on-android_11.html
> There are some guidelines around creating ...This blog post describes some "guidelines" for a foreground service's ongoing notification:
https://android-developers.googleblog.com/2018/12/effective-foreground-services-on-android_11.html
> There are some guidelines around creating and managing foreground services. For all API levels, a persistent notification with at least PRIORITY_LOW must be shown while the service is created. When targeting API 26+ you will also need to set the notification channel to at least IMPORTANCE_LOW.
Our ongoing notification uses PRIORITY_MIN and the channel uses IMPORTANCE_NONE. Find out whether this affects how the system treats our foreground service, especially on API 26+.
Related to #1146. Subtask of #1260.Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1273Reproducible scripted build process2019-02-27T12:09:07ZakwizgranReproducible scripted build processWrite a script that produces a reproducible APK from a fresh checkout of the repo. This should include optionally compiling the Tor binaries rather than downloading them.
Subtask of #1272.Write a script that produces a reproducible APK from a fresh checkout of the repo. This should include optionally compiling the Tor binaries rather than downloading them.
Subtask of #1272.Android 1.1Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1475Resolve issues with image attachment transitions2019-03-19T10:43:04ZTorsten GroteResolve issues with image attachment transitions* [x] Use a counter as the transition name in `AttachmentItem`.
* [x] Tapping partly covered images makes them pop up from under the cover which looks glitchy
* [ ] Under mysterious circumstances messages can overlap each other (or leave...* [x] Use a counter as the transition name in `AttachmentItem`.
* [x] Tapping partly covered images makes them pop up from under the cover which looks glitchy
* [ ] Under mysterious circumstances messages can overlap each other (or leave gaps) after a return transition to the conversation
* [x] On Moto G 4G (API 22), the exit transition still uses sliding
* [x] Fix shared element exit transition when the list position is lost (activity was stopped or made into fullscreen)
* [ ] ~~Change shared element of return transition when fullscreen view was swiped to another image when returning~~
* [x] Return transition lands slightly below thumbnail when status bar is hidden
Subtask of #1237.
![device-2018-11-28-175203](/uploads/62e4bbd7bc0af62196bc04c3d8433337/device-2018-11-28-175203.png)
![device-2018-11-28-175149](/uploads/e9f3124a919ca57370ece56e894f3ad6/device-2018-11-28-175149.png)Android 1.3Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1501Show new contacts at the top of the contact list2019-03-22T16:54:17ZTorsten GroteShow new contacts at the top of the contact listCurrently, new contacts get added to the bottom of the list. They should be at the top for better visibility.Currently, new contacts get added to the bottom of the list. They should be at the top for better visibility.Android 1.2Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1260Power management improvements2019-04-01T13:19:14ZakwizgranPower management improvementsUmbrella ticket for sponsor 1, objective 6.Umbrella ticket for sponsor 1, objective 6.https://code.briarproject.org/briar/briar/-/issues/976Dark theme2019-04-25T09:18:03ZakwizgranDark themeA user asked for a dark theme.A user asked for a dark theme.Android 1.1Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1233Design UX for adding contacts remotely2019-04-25T15:28:10ZakwizgranDesign UX for adding contacts remotelySubtask of #1230.Subtask of #1230.Android 1.2Elio Qoshielio@ura.designElio Qoshielio@ura.designhttps://code.briarproject.org/briar/briar/-/issues/1234Implement UX for adding contacts remotely2019-05-13T09:04:25ZakwizgranImplement UX for adding contacts remotelySubtask of #1230.Subtask of #1230.Android 1.2Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1537Implement contact manager methods for pending contacts2019-05-13T09:04:51ZakwizgranImplement contact manager methods for pending contactsSubtask of #1232.Subtask of #1232.Android 1.2akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1566Investigate whether equivalent public keys can damage the security of handsha...2019-05-14T11:16:36ZakwizgranInvestigate whether equivalent public keys can damage the security of handshake modeSome ECDH public keys are equivalent, in the sense that multiplying them by the same scalar produces the same point. If an attacker sends us a handshake public key that's equivalent to a contact's handshake public key, we'll fail to dete...Some ECDH public keys are equivalent, in the sense that multiplying them by the same scalar produces the same point. If an attacker sends us a handshake public key that's equivalent to a contact's handshake public key, we'll fail to detect that it's the same key (see #1565) and derive the same handshake mode transport keys. The attacker won't be able to derive the keys, but we'll use the same keys for handshaking with the contact and trying to handshake with the attacker.
This shouldn't affect confidentiality, integrity or authenticity, as we use a unique random nonce with the stream header key, but it could affect protocol obfuscation by using the same tags for sending streams to the contact and the attacker.
Work out whether this attack is possible, and if so, whether we can detect and prevent it.
Subtask of #1232.Android 1.2akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1538Generate and store handshake key pair at startup if necessary2019-05-16T13:02:40ZakwizgranGenerate and store handshake key pair at startup if necessarySubtask of #1232.Subtask of #1232.Android 1.2akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1256REST endpoint for adding and removing contacts2019-05-16T14:06:09ZakwizgranREST endpoint for adding and removing contacts* [x] adding contacts
* [x] removing contacts
Subtask of #1254.* [x] adding contacts
* [x] removing contacts
Subtask of #1254.Headless MVPTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1554Allow pending contacts to be removed any time2019-05-24T14:50:04ZTorsten GroteAllow pending contacts to be removed any timeCurrently, we only allow the user to remove pending contacts when adding them remotely failed. However, the user might want to remove them even earlier, because they changed their mind about adding this contact for example.Currently, we only allow the user to remove pending contacts when adding them remotely failed. However, the user might want to remove them even earlier, because they changed their mind about adding this contact for example.Android 1.2Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1570Add contact manager and database methods for converting a pending contact2019-06-03T14:58:45ZakwizgranAdd contact manager and database methods for converting a pending contactSubtask of #1232.Subtask of #1232.Android 1.2akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1556Add support for handshake keys to KeyManager2019-06-03T14:59:09ZakwizgranAdd support for handshake keys to KeyManagerPart of #1232.Part of #1232.Android 1.2akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1571Add rendezvous connection support to connection manager2019-06-04T14:26:56ZakwizgranAdd rendezvous connection support to connection managerSubtask of #1232.Subtask of #1232.Android 1.2akwizgranakwizgran