briar issueshttps://code.briarproject.org/groups/briar/-/issues2023-11-08T18:00:23Zhttps://code.briarproject.org/briar/briar/-/issues/2454Honor 70 Lite is seen as offline by contacts shortly after screen turns off2023-11-08T18:00:23ZakwizgranHonor 70 Lite is seen as offline by contacts shortly after screen turns offWhen the Honor 70 Lite is connected to a contact via Tor or wifi, the contact sees the Honor going offline a short time after the Honor's screen turns off. Sometimes the connection is lost and then quickly restored, only to be lost again...When the Honor 70 Lite is connected to a contact via Tor or wifi, the contact sees the Honor going offline a short time after the Honor's screen turns off. Sometimes the connection is lost and then quickly restored, only to be lost again.
The connection is quickly restored when the Honor's screen is turned on again.
This is probably some new power management hijinks from Huawei/Honor.https://code.briarproject.org/briar/briar/-/issues/2303Power management setup doesn't work on some Huawei devices2022-04-14T11:53:29ZakwizgranPower management setup doesn't work on some Huawei devicesSome Huawei devices running Android 10 throw a SecurityException when we try to open the App Launch settings (#2270).
!1602 fixed the crash by catching the exception, but we need to update the UI so that it shows instructions for openin...Some Huawei devices running Android 10 throw a SecurityException when we try to open the App Launch settings (#2270).
!1602 fixed the crash by catching the exception, but we need to update the UI so that it shows instructions for opening the App Launch settings manually.
These instructions will involve several steps and may be hard for users to follow. Unfortunately this means on affected Huawei devices, users are unlikely to succeed in protecting Briar from being killed.
Affected devices:
* Huawei P40 Pro without Google apps
* Huawei P30 Pro
* Huawei Mate 20 X
* Huawei Mate 20
Not affected:
* Huawei Y6P
* Honor 8Ahttps://code.briarproject.org/briar/briar/-/issues/2247Always connect to the Internet while Briar is put to foreground2022-11-02T18:30:20ZNorbert 80Always connect to the Internet while Briar is put to foregroundHello all,
Users who use the setting "Connect to the Internet only when charging" have to change this setting every time they want to bring Briar online in the meantime without the charger connected. This is very annoying and inconvenie...Hello all,
Users who use the setting "Connect to the Internet only when charging" have to change this setting every time they want to bring Briar online in the meantime without the charger connected. This is very annoying and inconvenient. In addition, it generally seems senseless to have the app in the foreground while it is offline.
For these reasons, I suggest the following behaviour of Briar while "Connect to the Internet only when charging" is activated:
1. When Briar is brought to the foreground, it should automatically switch to online.
2. When Briar is brought back to the background, it should maintain the internet connection for another 3 minutes. After the 3 minutes, Briar will automatically go offline. This 3 minute delay is to avoid excessive online/offline intervals.
(This is needed for example when the user wants to share texts from another app).https://code.briarproject.org/briar/briar/-/issues/2159Power management setup instructions for Tecno phones2022-04-13T10:20:48ZakwizgranPower management setup instructions for Tecno phonesSome Tecno phones have a [padlock button in the recent apps list](https://code.briarproject.org/briar/briar/-/issues/1743#note_49393) that prevents apps from being [killed when the recent apps list is cleared](https://code.briarproject.o...Some Tecno phones have a [padlock button in the recent apps list](https://code.briarproject.org/briar/briar/-/issues/1743#note_49393) that prevents apps from being [killed when the recent apps list is cleared](https://code.briarproject.org/briar/briar/-/issues/992#note_44605). We should find out which phones have this feature and add setup instructions asking the user to lock Briar to the recent apps list.https://code.briarproject.org/briar/briar/-/issues/2132Power-save battery issues on Xiaomi MIUI 122022-06-08T15:48:17ZTorsten GrotePower-save battery issues on Xiaomi MIUI 12On my Redmi Note 10 5G device running Xiaomi MIUI 12 (Android 11), the system **doze white-listing dialog** is simply not appearing. During initial setup, pressing the obligatory button does nothing, but gives us the green check-mark. Th...On my Redmi Note 10 5G device running Xiaomi MIUI 12 (Android 11), the system **doze white-listing dialog** is simply not appearing. During initial setup, pressing the obligatory button does nothing, but gives us the green check-mark. Then after initial setup, our doze warning dialog pops up immediately, but pressing FIX also does nothing (uses same `ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS` intent).
Our special Xiaomi instructions are appearing during initial setup, but they don't apply to MIUI 12 it seems. Instead, there's a dedicated system activity we can launch and ask the user to click on "no restrictions" there.
```
adb shell am start-activity -n com.miui.powerkeeper/com.miui.powerkeeper.ui.HiddenAppsConfigActivity --es package_name org.briarproject.briar.android.debug
```
This library could either be used directly or as a knowledge source for tricks like this:
https://github.com/thelittlefireman/AppKillerManagerhttps://code.briarproject.org/briar/briar/-/issues/2010Investigate behaviour of recent apps list for various manufacturers2022-03-21T13:49:28ZakwizgranInvestigate behaviour of recent apps list for various manufacturersMany manufacturers have custom implementations of the recent apps list.
On Tecno phones, clearing the recent apps list [kills the Briar process](https://code.briarproject.org/briar/briar/-/issues/992#note_44605) unless the app is [locke...Many manufacturers have custom implementations of the recent apps list.
On Tecno phones, clearing the recent apps list [kills the Briar process](https://code.briarproject.org/briar/briar/-/issues/992#note_44605) unless the app is [locked to the recent apps list](https://code.briarproject.org/briar/briar/-/issues/1743#note_49393).
On Xiaomi/Redmi phones, [locking an app to the recent apps list](https://code.briarproject.org/briar/briar/-/issues/1743#note_49341) prevents it from being killed by the system's power manager, which would otherwise happen even without clearing the list.
For as many manufacturers as possible, find out:
1. whether clearing the recent apps list kills Briar
2. whether apps can be locked to the recent apps list
3. whether locking prevents Briar from being killed when clearing the list
4. whether locking provides any other protection (e.g. from the system's power manager)https://code.briarproject.org/briar/briar/-/issues/2008Doze broadcasts aren't received on Nokia 3.12021-08-27T11:26:27ZakwizgranDoze broadcasts aren't received on Nokia 3.1A [log](/uploads/201f05a7ef28f09973eb8767649d3687/Nokia3.1-28042021-Snooze.log) from the [Snooze app](https://code.briarproject.org/akwizgran/snooze) running on the Nokia 3.1 doesn't show any broadcasts indicating that the device entered...A [log](/uploads/201f05a7ef28f09973eb8767649d3687/Nokia3.1-28042021-Snooze.log) from the [Snooze app](https://code.briarproject.org/akwizgran/snooze) running on the Nokia 3.1 doesn't show any broadcasts indicating that the device entered or left doze mode (device idle mode), unlike ten other devices that were tested. On all devices, the app was exempt from doze, running a foreground service and holding a wake lock.
If Briar likewise doesn't receive doze broadcasts on this device then it may fail to detect that its doze exemption has been removed. We only check the exemption status if a doze broadcast has been received since the last check.
I've asked @earthlingIB to run another test on this device without the doze exemption, to see whether it's the exemption that prevents the broadcasts from being received. If that's the case then we can close this ticket, as Briar will still be able to detect if its exemption has been removed.https://code.briarproject.org/briar/briar/-/issues/2007Devices lose wifi connectivity despite doze exemption, foreground service and...2021-04-30T13:20:11ZakwizgranDevices lose wifi connectivity despite doze exemption, foreground service and wake lockTwo overnight tests with the [Snooze app](https://code.briarproject.org/akwizgran/snooze) showed that several devices lost wifi connectivity despite the app being exempt from doze, running a foreground service, and holding a wake lock th...Two overnight tests with the [Snooze app](https://code.briarproject.org/akwizgran/snooze) showed that several devices lost wifi connectivity despite the app being exempt from doze, running a foreground service, and holding a wake lock that prevented deep sleep.
The app was also holding a wifi lock with WIFI_MODE_FULL, which Briar doesn't do. But this lock mode doesn't do anything on API >= 29.
In the first test, the following devices remained connected:
* Huawei Y6P (with [app launch workaround](https://code.briarproject.org/briar/briar/-/issues/1743#note_49208)) [y6p.log](/uploads/2dd5cfe4bb10eda009a730ee4de8e101/y6p.log)
* OnePlus 5T [oneplus-5t.log](/uploads/c48918d1e5e0a722036cd5f405daa474/oneplus-5t.log)
* Pixel 2 [pixel-2.log](/uploads/8f0181a6b0f1af87dc6416197b66c011/pixel-2.log)
* Redmi Note 7 (with [app locked to recent apps list](https://code.briarproject.org/briar/briar/-/issues/1743#note_49341)) [redmi-note-7.log](/uploads/9aba6f761c71ab2667cf97867614886e/redmi-note-7.log)
* Samsung Galaxy A10s [a10s.log](/uploads/c94055f3eb545588949c83898d3a4252/a10s.log)
The following devices lost connectivity in the first test:
* Honor 8A (with app launch workaround): lost connectivity after entering doze, didn't regain it [honor-8a.log](/uploads/10f41360b4311d039d164a97dc4dc8b7/honor-8a.log)
* Nokia 1.3: lost connectivity less than 3 minutes after screen was turned off, before entering doze, didn't regain it [nokia-1.3.log](/uploads/389d09c6e9fd3acdd188042e74b516b7/nokia-1.3.log)
In the second test, the following device remained connected:
* OnePlus 5T [oneplus-5t.log](/uploads/858a6778b919f415366abf34a8d2e542/oneplus-5t.log)
* Pixel 2 [pixel-2.log](/uploads/4a28aad88ae067506334758754f9f20d/pixel-2.log)
* Redmi Note 7 (with app locked to recent apps list) [redmi-note-7.log](/uploads/8f0a28d77ed20eb6a730dbf8c865d3f9/redmi-note-7.log)
The following devices lost connectivity in the second test:
* Honor 8A (with app launch workaround): lost connectivity after entering doze, didn't regain it [honor-8a.log](/uploads/1bf7c4e52bdf49f7df59d431539d629a/honor-8a.log)
* Huawei Y6P (with app launch workaround): lost connectivity after entering doze, didn't regain it [y6p.log](/uploads/38aa2dcd249ed79fdffc861f9711c217/y6p.log)
* Nokia 1.3: lost connectiivty less than 3 minutes after the screen was turned off, didn't regain it [nokia-1.3.log](/uploads/753e516264e0db994f53bbff3324811f/nokia-1.3.log)
* Samsung Galaxy A10s: lost connectivity about 7 hours into the test, after entering and leaving doze several times, and didn't regain it [a10s.log](/uploads/51555f8d084cf872f40b369261e4deb8/a10s.log)
These findings were originally reported [here](https://code.briarproject.org/briar/briar/-/issues/1737#note_49355) and [here](https://code.briarproject.org/briar/briar/-/issues/1737#note_49362). I copied them to their own ticket because the problem is different from #1737 and affects more devices.https://code.briarproject.org/briar/briar/-/issues/1757Investigate whether LAN connections need wake locks2020-11-15T15:46:21ZakwizgranInvestigate whether LAN connections need wake locksWe've added wake locks to Bluetooth connections to ensure keepalives are sent regularly and dead connections are detected in a reasonable amount of time. Investigate whether we need to do the same for LAN connections.We've added wake locks to Bluetooth connections to ensure keepalives are sent regularly and dead connections are detected in a reasonable amount of time. Investigate whether we need to do the same for LAN connections.https://code.briarproject.org/briar/briar/-/issues/1756Investigate connectivity changes when entering/exiting sleep and doze2020-11-15T15:03:26ZakwizgranInvestigate connectivity changes when entering/exiting sleep and dozeAndroidNetworkManager makes a connectivity check when it receives a broadcast associated with entering or exiting sleep or doze (ACTION_SCREEN_ON, ACTION_SCREEN_OFF or ACTION_DEVICE_IDLE_MODE_CHANGED). A second connectivity check is sche...AndroidNetworkManager makes a connectivity check when it receives a broadcast associated with entering or exiting sleep or doze (ACTION_SCREEN_ON, ACTION_SCREEN_OFF or ACTION_DEVICE_IDLE_MODE_CHANGED). A second connectivity check is scheduled 1 minute after the broadcast, because we've sometimes seen connectivity changes shortly after entering or exiting sleep or doze.
We want to detect these delayed connectivity changes reliably, but we don't want to hold a wake lock for a full minute after every screen on/off event, and in any case that might just cause the connectivity changes to be deferred until we release the wake lock.
Investigate the circumstances under which these delayed connectivity changes happen (on various devices), find out whether our current approach detects them reliably (with and without Tor enabled), and if not, work out how to do so.https://code.briarproject.org/briar/briar/-/issues/1737Huawei P8 Lite 2017 enters device idle mode despite doze whitelisting2021-04-30T13:38:14ZakwizgranHuawei P8 Lite 2017 enters device idle mode despite doze whitelistingAfter setting up Briar as normal on the Huawei P8 Lite 2017 (Android 7.0, EMUI 5.0.1) and leaving it running for a few hours, the doze watchdog dialog was shown after unlocking the screen, indicating that the phone entered device idle mo...After setting up Briar as normal on the Huawei P8 Lite 2017 (Android 7.0, EMUI 5.0.1) and leaving it running for a few hours, the doze watchdog dialog was shown after unlocking the screen, indicating that the phone entered device idle mode despite Briar being whitelisted.
![Screenshot_20200602-214120](/uploads/8771b9bbe470ab02575ddfe0221a9656/Screenshot_20200602-214120.png)
![Screenshot_20200602-214132](/uploads/d21e2d865b68342b1a9ae4f5f9319be9/Screenshot_20200602-214132.png)
Wifi and mobile data were turned off, so there was no Tor wake lock keeping the device awake.
After tapping "fix", which prompts to add Briar to the whitelist again, I left the phone idle for more than 24 hours and didn't see the doze watchdog dialog again.
I didn't capture any logs at the time as I was running another experiment. I'll try to reproduce this when the other experiments are finished.https://code.briarproject.org/briar/briar/-/issues/1511Settings to increase polling time2021-12-13T14:13:45ZDmitry RubtsovSettings to increase polling timeSince Briar takes a lot of battery power (up to 20% of my Galaxy Note 9), I want to customize update frequency for incoming messages. I think, that it is easy and usefulSince Briar takes a lot of battery power (up to 20% of my Galaxy Note 9), I want to customize update frequency for incoming messages. I think, that it is easy and usefulhttps://code.briarproject.org/briar/briar/-/issues/1495Consider network to be disabled when entering doze without being whitelisted2020-11-15T19:17:29ZakwizgranConsider network to be disabled when entering doze without being whitelistedIf the user removes us from the doze whitelist we may lose network connectivity when entering doze.
AndroidNetworkManager should check whether we're whitelisted for doze when entering doze, and if not (which must mean the user removed u...If the user removes us from the doze whitelist we may lose network connectivity when entering doze.
AndroidNetworkManager should check whether we're whitelisted for doze when entering doze, and if not (which must mean the user removed us from the whitelist), it should consider the network to be disabled and broadcast an event so the Tor plugin can disable Tor's network connectivity.https://code.briarproject.org/briar/briar/-/issues/1458Sign-in reminder isn't shown when phone starts2020-11-15T19:35:47ZakwizgranSign-in reminder isn't shown when phone startsA user reported that the sign-in reminder isn't show when their phone starts.
While looking into power management I found that many phones restrict which apps can receive the boot completed broadcast. As with other power management rest...A user reported that the sign-in reminder isn't show when their phone starts.
While looking into power management I found that many phones restrict which apps can receive the boot completed broadcast. As with other power management restrictions, there's sometimes an intent for opening the screen where this is managed:
https://stackoverflow.com/questions/48945300/how-to-open-window-of-autostart-application-for-all-devices/48945679#48945679
https://stackoverflow.com/questions/48166206/how-to-start-power-manager-of-all-android-manufactures-to-enable-background-and#
Related to #1260, #1292.https://code.briarproject.org/briar/briar/-/issues/1292Test Briar with power management apps2020-11-16T11:01:17ZakwizgranTest Briar with power management appsTest whether Briar is killed, loses connectivity, or is listed as power-intensive by power management apps such as the following:
https://play.google.com/store/apps/details?id=com.oasisfeng.greenify
https://play.google.com/store/apps/d...Test whether Briar is killed, loses connectivity, or is listed as power-intensive by power management apps such as the following:
https://play.google.com/store/apps/details?id=com.oasisfeng.greenify
https://play.google.com/store/apps/details?id=com.avast.android.batterysaver
https://play.google.com/store/apps/details?id=com.battery.power.batterysaverhttps://code.briarproject.org/briar/briar/-/issues/1104Load messages on demand (paged/lazy)2022-05-16T19:53:45ZakwizgranLoad messages on demand (paged/lazy)If a group contains a lot of messages, it's expensive to load all the messages when the user views the group.
Some clients use metadata to avoid loading messages. Message bodies can then be loaded on demand as they become visible. But t...If a group contains a lot of messages, it's expensive to load all the messages when the user views the group.
Some clients use metadata to avoid loading messages. Message bodies can then be loaded on demand as they become visible. But this is still expensive if there are lots of messages and/or lots of metadata per message.
Ideally we'd use something like the MessageTracker to store summary information, then load the messages and/or metadata on demand.
One of the tasks here is to determine what summary information each client needs. For example, the forum client needs to know the number of unread posts above and below the viewport. It may also need to know the sort position of the first unread post above and below the viewport so it can jump to those posts.
Sort order will be relevant to any client that loads messages on demand. If we want to load messages a page at a time, the database needs to know how to sort the messages. But sort order is client-dependent. For example, the blog client may want to sort posts by date, whereas the forum client sorts them by depth-first traversal order of the reply tree.
We can capture both of these orders (and hopefully others) by adding a label to each message. From the database's point of view, the label is just an opaque string of bytes. The database sorts the labels in lexicographic order, and messages and metadata can be retrieved by their positions in the sort order. The client is reponsible for labelling messages to achieve the desired sort order.
For the blog client, the label can just be a big-endian representation of the timestamp. For the forum client, the label can be the concatenated timestamps of the post's ancestors and the post itself. These labels will sort in the same order as depth-first traversal of the tree, visiting siblings in timestamp order.
```
123
+-123/234
+-123/345
234
+-234/345
+-234/345/456
345
567
```
(This doesn't rely on the rule that a post has a higher timestamp than its parent.)
This approach wouldn't be efficient for dynamic sort orders. For example, if the forum client wanted to sort siblings by the number of upvotes, we could calculate the labels as with timestamps, but adding an upvote to a post would require relabelling the post and all its descendents.https://code.briarproject.org/briar/briar/-/issues/1089Setup Wizard page for Sony's power manager2020-11-19T13:20:26ZJulian DehmSetup Wizard page for Sony's power managerStamina mode, Sony's powersaving mode, kills Briar once the screen is turned off. This can be prevented by whitelisting Briar.
Similar to #1088 we could explain it to the user and offer to open the stamina activity.Stamina mode, Sony's powersaving mode, kills Briar once the screen is turned off. This can be prevented by whitelisting Briar.
Similar to #1088 we could explain it to the user and offer to open the stamina activity.https://code.briarproject.org/briar/briar/-/issues/1041Reduce CPU consumption2020-11-19T15:04:11ZakwizgranReduce CPU consumptionFeedback from a user: "I noticed that the app has a high CPU usage. My battery drained noticeably faster than usual, with briar running, and my OS warned me about it using a lot of CPU time."
Related to #44.Feedback from a user: "I noticed that the app has a high CPU usage. My battery drained noticeably faster than usual, with briar running, and my OS warned me about it using a lot of CPU time."
Related to #44.https://code.briarproject.org/briar/briar/-/issues/878Let contacts know that we've removed them2020-11-19T15:54:55ZakwizgranLet contacts know that we've removed themCurrently we don't tell contacts that we've removed them - we just stop connecting to them and close any connections they make to us, since we no longer recognise the tags.
The main advantage of the current approach is that we can remov...Currently we don't tell contacts that we've removed them - we just stop connecting to them and close any connections they make to us, since we no longer recognise the tags.
The main advantage of the current approach is that we can remove contacts tactfully: the contact can't necessarily tell whether we removed her or whether we just haven't signed in recently. However, if the contact sees us posting to forums, blogs or private groups, she may be able to tell that we've removed her. A second advantage is that we can immediately delete all state relating to the contact. Removing all *identifiable* state is important - it's the equivalent of forward secrecy for the social graph. But removing *all* state is just convenient.
The main disadvantage of the current approach is that the contact wastes battery and bandwidth trying to connect to us indefinitely. Depending on the transport this may expose metadata (#62). These problems will get worse over time as users accumulate defunct contacts.https://code.briarproject.org/briar/briar/-/issues/834Optionally sign out when battery is low or power saving mode is enabled2021-10-27T14:09:40ZakwizgranOptionally sign out when battery is low or power saving mode is enabledListen for power manager events (ACTION_BATTERY_LOW, ACTION_POWER_SAVE_MODE_CHANGED) and [manufacturer-specific events](http://stackoverflow.com/a/25103642) and optionally sign out if the battery is low or power saving mode is enabled an...Listen for power manager events (ACTION_BATTERY_LOW, ACTION_POWER_SAVE_MODE_CHANGED) and [manufacturer-specific events](http://stackoverflow.com/a/25103642) and optionally sign out if the battery is low or power saving mode is enabled and the user's not currently interacting with Briar.