briar issueshttps://code.briarproject.org/briar/briar/-/issues2022-08-05T13:38:01Zhttps://code.briarproject.org/briar/briar/-/issues/2292Mailbox download worker for a contact's mailbox2022-08-05T13:38:01ZakwizgranMailbox download worker for a contact's mailboxWhen a contact is assigned to a contact's mailbox for download, the mailbox client (#2289) creates a download worker. The worker is destroyed when the contact is unassigned for download or the client is destroyed.
The worker keeps a ref...When a contact is assigned to a contact's mailbox for download, the mailbox client (#2289) creates a download worker. The worker is destroyed when the contact is unassigned for download or the client is destroyed.
The worker keeps a reference to its current API task, if any, so the task can be cancelled when the worker is destroyed.
The worker's lifecycle is:
1. Check connectivity
2. Download and delete all files from the inbox
3. Wait until our hidden service has been reachable for at least the overlap duration
4. Download and delete all files from the inbox again, in case any arrived during the overlap period
The worker can be in the following states:
* Waiting for connectivity check
* First download
* Waiting for hidden service
* Second download
* Destroyed
When the worker is created:
* Set the current state to "waiting for connectivity check"
* Call the client's connectivity check method
When the worker is destroyed:
* Set the current state to "destroyed"
* Cancel the current API task, if any
When a connectivity check succeeds:
* If the current state is "waiting for connectivity check":
* Set the current state to "first download"
* Start a list-inbox task
When a list-inbox tasks succeeds:
* If the current state is "first download" or "second download":
* If there are files in the inbox:
* Sort the files by timestamp
* Start a download-file task for the first file (#2232)
* Else if the current state is "first download":
* Set the current state to "waiting for hidden service"
When a download-file task succeeds:
* Pass the local file's path to the mailbox plugin to get a transport connection reader
* Decorate the transport connection reader to handle disposal
* Pass the decorated transport connection reader to the connection manager
* Data will be read from the local file asynchronously
* If the current state is "first download" or "second download":
* Start a delete-file task for the current file (#2233)
When the transport connection reader is disposed of:
* Delete the local file
When a delete-file task succeeds or tolerably fails:
* If the current state is "first download" or "second download":
* If there are more files to download:
* Start a download-file task for the next file
* Else:
* Start a list-inbox task
When an event indicates that the hidden service has been reachable for at least the overlap duration:
* If the current state is "waiting for hidden service":
* Set the current state to "second download"
* Start a list-inbox taskMailbox: Manage mailbox connectionsakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/2291Mailbox upload worker2022-08-05T14:19:56ZakwizgranMailbox upload workerThe upload worker implementation is shared between the client for our own mailbox (#2290) and the client for a contact's mailbox (#2289). The worker's lifecycle is managed by the mailbox client, which in turn is managed by the mailbox cl...The upload worker implementation is shared between the client for our own mailbox (#2290) and the client for a contact's mailbox (#2289). The worker's lifecycle is managed by the mailbox client, which in turn is managed by the mailbox client manager (#2228).
Each upload worker is associated with a contact that has been assigned to a mailbox for upload. When a contact is reassigned to a different mailbox for upload, the old worker is destroyed and a new worker is created.
The worker can be in the following states:
* Checking for data to send
* Waiting for data to send
* Waiting for connectivity check
* Writing and uploading
* Destroyed
When the worker is created:
* Set the current state to "checking for data to send"
* Check for data to send
When the worker is destroyed:
* Set the current state to "destroyed"
* Cancel the current upload task, if any
To check for data to send:
* Load the time when data will next be ready to send to the contact
* If data is ready to send now:
* Set the current state to "waiting for connectivity check"
* Call the client's connectivity check method
* Else:
* Set the current state to "waiting for data to send"
* Schedule a wakeup task for the time when data will next be ready to send
When an event indicates that new data may be ready to send:
* If the current state is "waiting for data to send":
* Cancel the wakeup task
* Set the current state to "checking for data to send"
* Check for data to upload
When a wakeup task runs:
* If the current state is "waiting for data to send":
* Set the current state to "checking for data to send"
* Check for data to upload
When a connectivity check succeeds:
* If the current state is "waiting for connectivity check":
* Set the current state to "writing and uploading"
* Write and upload a file
To write and upload a file:
* Create a temporary file in the upload directory
* Pass the file's path to the mailbox plugin to get a transport connection writer
* Decorate the transport connection writer to handle disposal
* Create a deferred send handler
* Pass the decorated transport connection writer and the deferred send handler to the connection manager
* Data will be written to the file asynchronously
* The IDs of any sent/acked messages will be recorded by the deferred send handler
When the transport connection writer is disposed of:
* If the write succeeded:
* Start an upload task to upload the file to the mailbox (#2231)
* Else:
* Delete the file
* Set the current state to "checking for data to send"
* Check for data to send
When an upload task succeeds:
* Retrieve the sent/acked message IDs from the deferred send handler
* Mark the messages as sent/acked
* Delete the file
* Set the current state to "checking for data to send"
* Check for data to send
When an upload task is cancelled:
* Delete the fileMailbox: Manage mailbox connectionsakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/2290Mailbox client for our own mailbox2022-08-12T12:44:40ZakwizgranMailbox client for our own mailboxMailbox clients for communicating with our own mailbox and contacts' mailboxes are managed by a singleton mailbox client manager (#2228).
This ticket covers the client for communicating with our own mailbox. Some code will be shared wit...Mailbox clients for communicating with our own mailbox and contacts' mailboxes are managed by a singleton mailbox client manager (#2228).
This ticket covers the client for communicating with our own mailbox. Some code will be shared with the client for communicating with a contact's mailbox (#2289). The shared code is covered by #2229.
The client's connectivity check will use #2170.
* At any given time the client has zero or more contacts assigned for upload and zero or more contacts assigned for download
* Each contact assigned for upload has its own upload worker
* The client has a single download worker that's shared by all contacts assigned for download
* The client also has a single contact list worker
When the client is created:
* Create and start the contact list worker (#2294)
When the client is destroyed:
* Do all the stuff the superclass does when it's destroyed
* Destroy the contact list worker
When a contact is assigned for upload:
* Create and start the contact's upload worker (#2291)
When a contact is deassigned for upload:
* Destroy the contact's upload worker
When a contact is assigned for download:
* If this is the only contact assigned for download:
* Create and start the shared download worker (#2293)
When a contact is deassigned for download:
* If there are no more contacts assigned for download:
* Destroy the shared download workerMailbox: Manage mailbox connectionsakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/2289Mailbox client for a contact's mailbox2022-07-13T11:07:36ZakwizgranMailbox client for a contact's mailboxMailbox clients for communicating with our own mailbox and contacts' mailboxes are managed by a singleton mailbox client manager (#2228).
This ticket covers the client for communicating with a contact's mailbox. Some code will be shared...Mailbox clients for communicating with our own mailbox and contacts' mailboxes are managed by a singleton mailbox client manager (#2228).
This ticket covers the client for communicating with a contact's mailbox. Some code will be shared with the client for communicating with our own mailbox (#2290). The shared code is covered by #2229.
The client's connectivity check will use #2186.
* The client always has one contact assigned for upload
* At any given time the client may have one contact assigned for download, depending on whether we have our own mailbox
When the client is created:
* Create and start the upload worker (#2291)
When a contact is assigned for download:
* Create and start the download worker (#2292)
When a contact is deassigned for download:
* Destroy the download workerMailbox: Manage mailbox connectionshttps://code.briarproject.org/briar/briar/-/issues/2286Connection problem (TOR Bridges)2022-07-13T11:19:13ZUlyan ChesnokovConnection problem (TOR Bridges)Since Briar uses Tor to connect in case it is blocked (e.g. in Russia), it is necessary to use TOR bridges. With a regular connection Briar cannot get them and therefore does not allow chatting or adding new contacts over the Internet. P...Since Briar uses Tor to connect in case it is blocked (e.g. in Russia), it is necessary to use TOR bridges. With a regular connection Briar cannot get them and therefore does not allow chatting or adding new contacts over the Internet. Please add the ability to manually input Tor bridges.https://code.briarproject.org/briar/briar/-/issues/2285Find out whether GeoIP file is needed2022-07-18T10:27:54ZakwizgranFind out whether GeoIP file is neededIf Tor doesn't use the GeoIP file by default and we're not using any options that require it, we could reduce the size of the APK by removing it.If Tor doesn't use the GeoIP file by default and we're not using any options that require it, we could reduce the size of the APK by removing it.Android 1.4https://code.briarproject.org/briar/briar/-/issues/2284Crash in TorControlConnection#handleEvent()2022-06-06T13:14:05ZakwizgranCrash in TorControlConnection#handleEvent()While testing Briar with some extra Tor controller events, I got a crash from TorControlConnection#handleEvent(). The crash was due to the ReplyLine not containing any spaces, causing String#substring(int, int) at TorControlConnection.ja...While testing Briar with some extra Tor controller events, I got a crash from TorControlConnection#handleEvent(). The crash was due to the ReplyLine not containing any spaces, causing String#substring(int, int) at TorControlConnection.java line 218 to throw an exception when -1 was passed as the length of the substring.
So far I haven't been able to reproduce the crash. The extra events I enabled were GUARD, NS, TRANSPORT_LAUNCHED and STATUS_GENERAL. I suspect that the STATUS_GENERAL event [DIR_ALL_UNREACHABLE](https://gitlab.torproject.org/tpo/core/torspec/-/blob/ec77ae643f3e47bea0292d125a51f8786bf33fb9/control-spec.txt#L2866) would reproduce the bug but I haven't persuaded Tor to broadcast it (again).
Once the bug can be reproduced a ticket should be opened against jtorctl.Android 1.4akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/2280NPE in RemovableDriveTaskImpl2022-04-20T14:54:14ZakwizgranNPE in RemovableDriveTaskImpl* Android version: 9
* Phone model: Huawei POT-LX1
* Briar version: 1.4.5 (4df523a)
* User feedback: "Doesn't work without internet."
Log:
```
03-01 07:20:01.142 I/BriarApplicationImpl: Created
03-01 07:20:01.187 I/BaseActivity: Creatin...* Android version: 9
* Phone model: Huawei POT-LX1
* Briar version: 1.4.5 (4df523a)
* User feedback: "Doesn't work without internet."
Log:
```
03-01 07:20:01.142 I/BriarApplicationImpl: Created
03-01 07:20:01.187 I/BaseActivity: Creating RemovableDriveActivity
03-01 07:20:01.244 I/BaseActivity: Starting RemovableDriveActivity
03-01 07:20:01.322 I/BaseActivity: Resuming RemovableDriveActivity
03-01 07:20:01.322 I/BriarActivity: Not signed in, launching StartupActivity
03-01 07:20:01.340 I/BaseActivity: Pausing RemovableDriveActivity
```
Stacktrace:
```
java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.Class java.lang.Object.getClass()' on a null object reference
at org.briarproject.bramble.api.nullsafety.NullSafety.requireNonNull(NullSafety.java:12)
at org.briarproject.bramble.plugin.file.RemovableDriveTaskImpl.getPlugin(RemovableDriveTaskImpl.java:78)
at org.briarproject.bramble.plugin.file.RemovableDriveReaderTask.run(RemovableDriveReaderTask.java:38)
at java.util.concurrent.ThreadPoolExecutor.processTask(ThreadPoolExecutor.java:1187)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:784)
```
Looks like the crash happened when relaunching the app from the recent apps list after it was killed with RemovableDriveActivity open.Android 1.4akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/2277ActivityNotFoundException for GET_CONTENT intent2022-05-16T13:59:16ZakwizgranActivityNotFoundException for GET_CONTENT intentLooks similar to #2214 and #2097.
* Android version: 11
* Phone model: Samsung SM-A125F (a12nnxx)
* Briar version: 1.4.1 (6517f3f)
Stacktrace:
```
android.content.ActivityNotFoundException: No Activity found to handle Intent { act=andr...Looks similar to #2214 and #2097.
* Android version: 11
* Phone model: Samsung SM-A125F (a12nnxx)
* Briar version: 1.4.1 (6517f3f)
Stacktrace:
```
android.content.ActivityNotFoundException: No Activity found to handle Intent { act=android.intent.action.GET_CONTENT cat=[android.intent.category.OPENABLE] typ=image/* (has extras) }
at android.app.Instrumentation.checkStartActivityResult(Instrumentation.java:2080)
at android.app.Instrumentation.execStartActivity(Instrumentation.java:1727)
at android.app.Activity.startActivityForResult(Activity.java:5377)
at androidx.activity.ComponentActivity.startActivityForResult(ComponentActivity.java:574)
at androidx.core.app.ActivityCompat.startActivityForResult(ActivityCompat.java:234)
at androidx.activity.ComponentActivity$2.onLaunch(ComponentActivity.java:208)
at androidx.activity.result.ActivityResultRegistry$2.launch(ActivityResultRegistry.java:166)
at androidx.fragment.app.Fragment$9.launch(Fragment.java:3510)
at androidx.activity.result.ActivityResultLauncher.launch(ActivityResultLauncher.java:47)
at org.briarproject.briar.android.settings.SettingsFragment.lambda$onCreatePreferences$0(SettingsFragment.java:66)
at org.briarproject.briar.android.settings.SettingsFragment.lambda$onCreatePreferences$0$SettingsFragment(Unknown Source:0)
at org.briarproject.briar.android.settings.-$$Lambda$SettingsFragment$aLVt4dIN9PUOagzsIXcpqTymkBo.onPreferenceClick(Unknown Source:2)
at androidx.preference.Preference.performClick(Preference.java:1184)
at androidx.preference.Preference.performClick(Preference.java:1166)
at androidx.preference.Preference$1.onClick(Preference.java:181)
at android.view.View.performClick(View.java:8160)
at android.view.View.performClickInternal(View.java:8137)
at android.view.View.access$3700(View.java:888)
at android.view.View$PerformClick.run(View.java:30236)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:246)
at android.app.ActivityThread.main(ActivityThread.java:8528)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:602)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1130)
```Android 1.4akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/2273SecurityException when reading from removable drive2022-04-20T14:53:56ZakwizgranSecurityException when reading from removable drive* Android version: 10
* Phone model: Redmi M2006C3LG (dandelion_global)
* Briar version: 1.4.4 (36670a8)
Stacktrace:
```
java.lang.SecurityException: org.briarproject.briar.android has no access to content://media/external/audio/media/4...* Android version: 10
* Phone model: Redmi M2006C3LG (dandelion_global)
* Briar version: 1.4.4 (36670a8)
Stacktrace:
```
java.lang.SecurityException: org.briarproject.briar.android has no access to content://media/external/audio/media/436
at android.os.Parcel.createException(Parcel.java:2074)
at android.os.Parcel.readException(Parcel.java:2042)
at android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:188)
at android.database.DatabaseUtils.readExceptionWithFileNotFoundExceptionFromParcel(DatabaseUtils.java:151)
at android.content.ContentProviderProxy.openTypedAssetFile(ContentProviderNative.java:705)
at android.content.ContentResolver.openTypedAssetFileDescriptor(ContentResolver.java:1700)
at android.content.ContentResolver.openAssetFileDescriptor(ContentResolver.java:1516)
at android.content.ContentResolver.openInputStream(ContentResolver.java:1200)
at org.briarproject.bramble.plugin.file.AndroidRemovableDrivePlugin.openInputStream(AndroidRemovableDrivePlugin.java:35)
at org.briarproject.bramble.plugin.file.AbstractRemovableDrivePlugin.createReader(AbstractRemovableDrivePlugin.java:110)
at org.briarproject.bramble.plugin.file.RemovableDriveReaderTask.run(RemovableDriveReaderTask.java:38)
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:919)
```Android 1.4akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/2272NPE at application startup2022-06-13T14:48:19ZakwizgranNPE at application startupThis bug was recorded by Google Play. The crash happens at injection time, possibly before our own crash reporter is initialised.
* Android version: 11
* Phone models: Motorola Moto G Power, Redmi Note 8 Pro, OnePlus Nord N10 5G, Xiaomi...This bug was recorded by Google Play. The crash happens at injection time, possibly before our own crash reporter is initialised.
* Android version: 11
* Phone models: Motorola Moto G Power, Redmi Note 8 Pro, OnePlus Nord N10 5G, Xiaomi Mi A3, OnePlus 7
* Briar versions: 1.4.3, 1.4.4 (Google Play)
Stacktrace:
```
java.lang.RuntimeException:
at android.app.ActivityThread.handleBindApplication (ActivityThread.java:7029)
at android.app.ActivityThread.access$1700 (ActivityThread.java:274)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:2098)
at android.os.Handler.dispatchMessage (Handler.java:106)
at android.os.Looper.loop (Looper.java:233)
at android.app.ActivityThread.main (ActivityThread.java:8063)
at java.lang.reflect.Method.invoke (Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:631)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:978)
Caused by: java.lang.NullPointerException:
at java.net.NetworkInterface.getAll (NetworkInterface.java:498)
at java.net.NetworkInterface.getNetworkInterfaces (NetworkInterface.java:398)
at org.briarproject.bramble.system.AbstractSecureRandomProvider.writeToEntropyPool (AbstractSecureRandomProvider.java:28)
at org.briarproject.bramble.system.AndroidSecureRandomProvider.writeToEntropyPool (AndroidSecureRandomProvider.java:41)
at org.briarproject.bramble.system.UnixSecureRandomProvider.writeSeed (UnixSecureRandomProvider.java:49)
at org.briarproject.bramble.system.AndroidSecureRandomProvider.writeSeed (AndroidSecureRandomProvider.java:64)
at org.briarproject.bramble.system.UnixSecureRandomProvider.getProvider (UnixSecureRandomProvider.java:41)
at org.briarproject.bramble.crypto.CryptoComponentImpl.<init> (CryptoComponentImpl.java:83)
at org.briarproject.bramble.crypto.CryptoModule.provideCryptoComponent (CryptoModule.java:32)
at org.briarproject.bramble.crypto.CryptoModule_ProvideCryptoComponentFactory.provideCryptoComponent (CryptoModule_ProvideCryptoComponentFactory.java:42)
at org.briarproject.bramble.crypto.CryptoModule_ProvideCryptoComponentFactory.get (CryptoModule_ProvideCryptoComponentFactory.java:31)
at org.briarproject.bramble.crypto.CryptoModule_ProvideCryptoComponentFactory.get (CryptoModule_ProvideCryptoComponentFactory.java:10)
at dagger.internal.DoubleCheck.get (DoubleCheck.java:47)
at org.briarproject.bramble.sync.MessageFactoryImpl_Factory.get (MessageFactoryImpl_Factory.java:21)
at org.briarproject.bramble.sync.MessageFactoryImpl_Factory.get (MessageFactoryImpl_Factory.java:8)
at org.briarproject.bramble.sync.SyncModule_ProvideMessageFactoryFactory.get (SyncModule_ProvideMessageFactoryFactory.java:26)
at org.briarproject.bramble.sync.SyncModule_ProvideMessageFactoryFactory.get (SyncModule_ProvideMessageFactoryFactory.java:9)
at org.briarproject.bramble.db.DatabaseModule_ProvideDatabaseFactory.get (DatabaseModule_ProvideDatabaseFactory.java:36)
at org.briarproject.bramble.db.DatabaseModule_ProvideDatabaseFactory.get (DatabaseModule_ProvideDatabaseFactory.java:12)
at dagger.internal.DoubleCheck.get (DoubleCheck.java:47)
at org.briarproject.bramble.db.DatabaseModule_ProvideDatabaseComponentFactory.get (DatabaseModule_ProvideDatabaseComponentFactory.java:40)
at org.briarproject.bramble.db.DatabaseModule_ProvideDatabaseComponentFactory.get (DatabaseModule_ProvideDatabaseComponentFactory.java:13)
at dagger.internal.DoubleCheck.get (DoubleCheck.java:47)
at org.briarproject.bramble.lifecycle.LifecycleManagerImpl_Factory.get (LifecycleManagerImpl_Factory.java:30)
at org.briarproject.bramble.lifecycle.LifecycleManagerImpl_Factory.get (LifecycleManagerImpl_Factory.java:10)
at org.briarproject.bramble.lifecycle.LifecycleModule_ProvideLifecycleManagerFactory.get (LifecycleModule_ProvideLifecycleManagerFactory.java:26)
at org.briarproject.bramble.lifecycle.LifecycleModule_ProvideLifecycleManagerFactory.get (LifecycleModule_ProvideLifecycleManagerFactory.java:9)
at dagger.internal.DoubleCheck.get (DoubleCheck.java:47)
at org.briarproject.bramble.cleanup.CleanupModule_ProvideCleanupManagerFactory.get (CleanupModule_ProvideCleanupManagerFactory.java:35)
at org.briarproject.bramble.cleanup.CleanupModule_ProvideCleanupManagerFactory.get (CleanupModule_ProvideCleanupManagerFactory.java:11)
at dagger.internal.DoubleCheck.get (DoubleCheck.java:47)
at org.briarproject.briar.android.DaggerAndroidComponent.injectEagerSingletons (DaggerAndroidComponent.java:2556)
at org.briarproject.briar.android.DaggerAndroidComponent.inject (DaggerAndroidComponent.java:2066)
at org.briarproject.bramble.BrambleCoreEagerSingletons$Helper.injectEagerSingletons (BrambleCoreEagerSingletons.java:48)
at org.briarproject.briar.android.BriarApplicationImpl.createApplicationComponent (BriarApplicationImpl.java:97)
at org.briarproject.briar.android.BriarApplicationImpl.onCreate (BriarApplicationImpl.java:64)
at android.app.Instrumentation.callApplicationOnCreate (Instrumentation.java:1208)
at android.app.ActivityThread.handleBindApplication (ActivityThread.java:7024)
```
This looks like a framework bug that we could work around by catching the exception.Android 1.4akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/2270Crash during power management setup on Huawei device2022-04-13T10:20:05ZakwizgranCrash during power management setup on Huawei deviceA user reported that Briar crashes during power management setup on a Huawei device. It's not clear whether the crash happened when requesting doze exemption or when opening the battery settings screen (or perhaps even the protected apps...A user reported that Briar crashes during power management setup on a Huawei device. It's not clear whether the crash happened when requesting doze exemption or when opening the battery settings screen (or perhaps even the protected apps list, if it was an old phone).
https://quietplace.xyz/notes/8xa865dc3rAndroid 1.4akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/2269Use full camera preview when scanning QR codes2022-06-30T10:05:14ZakwizgranUse full camera preview when scanning QR codesThe QR code scanner only uses the upper half of the camera preview, as this is the only part that's visible when adding contacts in person. However, when pairing a mailbox the whole preview is visible, so the QR code may fail to scan if ...The QR code scanner only uses the upper half of the camera preview, as this is the only part that's visible when adding contacts in person. However, when pairing a mailbox the whole preview is visible, so the QR code may fail to scan if positioned in the middle of the preview.
We should either add a flag to control whether the whole preview is used, or (if testing on bad device combinations allows this), use the whole preview in both cases.
An example of a bad device combination is the Huawei Ascend Y330 showing the QR code and the Moto E3 scanning it.Mailbox: PairingDaniel LublinDaniel Lublinhttps://code.briarproject.org/briar/briar/-/issues/2268new Option: allow to use your device as an connecting node.2022-02-26T13:09:51ZVladislavnew Option: allow to use your device as an connecting node.When main issue is missing a way to communicate and privacy become not so important.
Could briar have an option (to be able to activate it in emergency situation) when anyone in a range could send message to a known (inaccessible) conta...When main issue is missing a way to communicate and privacy become not so important.
Could briar have an option (to be able to activate it in emergency situation) when anyone in a range could send message to a known (inaccessible) contact, through the phone that has this option active.
To work like WiFi-repeater.
So multiple device with this option enabled could allow to interconnect people for a small city.
Alternatives: FireChat
Use case: Internet, landline, mobile networks are down or blocked, inaccessible. Ex.: being in a bunker, subway, tunnel, during the war or blackouts.
Briar could be a solution.https://code.briarproject.org/briar/briar/-/issues/2267Broadcast event when recording connection status of own mailbox2022-04-01T11:18:01ZakwizgranBroadcast event when recording connection status of own mailboxMailbox: Status UI for Briar appDaniel LublinDaniel Lublinhttps://code.briarproject.org/briar/briar/-/issues/2266Check for API/behaviour changes in Android 13 that could affect Briar2023-07-03T11:21:13ZTorsten GroteCheck for API/behaviour changes in Android 13 that could affect Briar* https://developer.android.com/about/versions/13/behavior-changes-13
* https://blog.esper.io/android-13-deep-dive/
* https://commonsware.com/blog/2022/02/12/random-musings-android-13-dp1.html
* https://commonsware.com/blog/2022/03/19/ra...* https://developer.android.com/about/versions/13/behavior-changes-13
* https://blog.esper.io/android-13-deep-dive/
* https://commonsware.com/blog/2022/02/12/random-musings-android-13-dp1.html
* https://commonsware.com/blog/2022/03/19/random-musings-android-13-dp2.html
Changes that may affect us:
* [Low power standby](https://developer.android.com/reference/android/os/PowerManager.html#isLowPowerStandbyEnabled()) is a new power saving mode (apparently distinct from doze, light doze and power save mode) in which apps with foreground services lose network access and their wake locks are ignored. It's not clear whether doze exemption affects this mode. We should look for ADB commands that can be used to test this mode
* [Light idle mode](https://developer.android.com/reference/android/os/PowerManager#isDeviceLightIdleMode()) has also been added to the PowerManager API, although this may just be exposing the "light doze" mode that was [added in Android 7](https://developer.android.com/about/versions/nougat/android-7.0-changes#doze)
* [Apps are placed in the "restricted" app standby bucket](https://developer.android.com/about/versions/13/changes/battery#restricted-bucket) if they "drain a significant amount of device battery during a 24-hour period". This is likely to apply to Briar and Briar Mailbox. Apps are also placed in the "restricted" bucket if the user doesn't interact with them for 8 days. This is very likely to apply to Briar Mailbox and may also apply to Briar. Running a foreground service isn't enough to meet definition of "interaction" being used here. The [docs for app standby buckets](https://developer.android.com/topic/performance/appstandby#buckets) say "Apps that are on the Doze exemption list are exempted from the App Standby Bucket-based restrictions." We should test whether this remains true for the new restrictions. We should also add code to [log which bucket we're in](https://developer.android.com/reference/android/app/usage/UsageStatsManager#getAppStandbyBucket()) periodically
* [Apps need to ask permission to show notifications](https://developer.android.com/about/versions/13/changes/notification-permission) - if the app doesn't target API 33 then the permission prompt will be shown automatically when the notification channels are created, which in Briar's case happens after signing in
* The new [foreground services task manager](https://developer.android.com/about/versions/13/changes/fgs-manager) enables the user to stop foreground services. Stopping an app in this way is [roughly equivalent](https://developer.android.com/about/versions/13/changes/fgs-manager#compare-swipe-up-force-stop) to force-stopping the app, but just different enough to make sure we'll have to test both workflows. Related to #2010
* [New rules for intent filters](https://developer.android.com/about/versions/13/behavior-changes-13#security) could affect our use of intents to open other apps (such as manufacturer-specific power management apps). These rules apply if the app receiving the intent targets API 33 or higher, so it could take a while for any effects to be noticeable
Article: https://medium.com/androiddevelopers/making-sense-of-intent-filters-in-android-13-8f6656903dde
* We should check whether the [`RECEIVER_NOT_EXPORTED`](https://developer.android.com/reference/android/content/Context.html#RECEIVER_NOT_EXPORTED) flag is relevant to us (all our BroadcastReceivers are used for receiving system broadcasts)
* [`NEARBY_WIFI_DEVICES`](https://developer.android.com/reference/android/Manifest.permission#NEARBY_WIFI_DEVICES) permission - this replaces `ACCESS_FINE_LOCATION` for some wifi APIs. We should use the new permission and find out whether location services still need to be enabled for these APIs to work
* If the user places an app in the "restricted" state for background battery usage (which AFAICT is [unrelated](https://developer.android.com/topic/performance/power/power-details) to the "restricted" app standby bucket) then the app [can't run foreground services, schedule alarms or run jobs](https://developer.android.com/about/versions/13/changes/battery#restricted-background-battery-usage). If the app targets API 33 then it can't receive `ACTION_BOOT_COMPLETED` broadcasts either, which we use for the sign-in reminder
* [System notification for long-running foreground services](https://developer.android.com/about/versions/13/changes/battery#system-notification-long-running-fgs) ("APP is running in the background for a long time. Tap to review") - as CommonsWare says, the obvious response from developers is to add `FOREGROUND_SERVICE_TYPE_MEDIA_PLAYBACK` or `FOREGROUND_SERVICE_TYPE_LOCATION`, and the obvious response from Google is to restrict those flags in the next update
* [System notification for excessive background battery usage](https://developer.android.com/about/versions/13/changes/battery#system-notification-battery-usage) - the docs say this notification will be shown after our foreground service finishes, ie after the user signs out, which may cause confusion
* I'm sure [TARE](https://blog.esper.io/android-13-deep-dive/#tare) will produce great value for users and won't just be the equivalent of adding a dice roll to every attempt to queue a job or schedule an alarm. We should keep it in mind when debugging alarm issues
* [Apps can release unused permissions](https://developer.android.com/about/versions/13/features#developer-downgradable-permissions) - this looks useful for privacy-conscious users but some care will be needed to integrate this into our app lifecycle, as the system kills the app asynchronously at some point after the API is called
* There's a [new AndroidX API for implementing in-app language pickers](https://developer.android.com/about/versions/13/features/app-languages#api-impl), which is great. The user can also pick a per-app language [through the system settings app](https://developer.android.com/about/versions/13/features/app-languages#app-language-settings), in which case "The list of available languages might not reflect the languages that your app supports". This will need testing
* There's a new API for [opting out of screenshots in the recent apps list](https://developer.android.com/reference/android/app/Activity.html#setRecentsScreenshotEnabled(boolean)) without preventing the user from taking screenshots. This may be useful if it doesn't open some other horrendous information leak
* [SystemClock#currentNetworkTimeClock()](https://developer.android.com/reference/android/os/SystemClock.html#currentNetworkTimeClock()) may be useful for diagnosing whether clock sync issues are due to misconfiguration or [NTP tampering](https://gitlab.torproject.org/tpo/core/tor/-/issues/26359)
* Apps with the `ACCESS_FINE_LOCATION` permission are [exempt from most of the power management changes in Android 13](https://developer.android.com/about/versions/13/changes/battery#exemptions), as are media players that are actively playing media. Perhaps Google thinks media players and navigation apps (or exercise trackers?) should be allowed to run in the background, which would be consistent with the apparent intent of previous loopholesTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/2265Replace ETA with max latency in retransmission logic2022-03-29T13:12:39ZakwizgranReplace ETA with max latency in retransmission logicThe sync protocol allows a message to be retransmitted if either the message's send time (also called expiry time in the database code) has been reached, or if the message's ETA via the currently available transport would be earlier than...The sync protocol allows a message to be retransmitted if either the message's send time (also called expiry time in the database code) has been reached, or if the message's ETA via the currently available transport would be earlier than the ETA of the previous copy. The ETA is based on the max latency of the transport.
This second (ETA) condition is met when the previous copy was sent via a higher-latency transport and a lower-latency transport is now available. But this logic has a weird edge case: immediately after sending a message via a higher-latency transport, the message can be sent via a lower-latency transport, as intended. But as the ETA of the first copy approaches, the message stops being sendable via the lower-latency transport.
This edge case is unlikely to matter when the lower latency is a tiny fraction of the higher latency (eg 30 seconds for Tor vs 28 days for removable drives). But it may become important when the lower latency is a significant fraction of the higher latency (eg 14 days for mailboxes vs 28 days for removable drives).
To remove the edge case we should store the max latency of the transport rather than the ETA, and allow the message to be retransmitted if either the send time has been reached (as now), or if the max latency of the currently available transport is less than the max latency of the transport used for the previous copy. This will require a DB migration.MailboxDaniel LublinDaniel Lublinhttps://code.briarproject.org/briar/briar/-/issues/2264change my nickname2022-02-25T14:59:41ZRoman Beslikme@beroal.in.uachange my nicknameI want to change my nickname after creating an account, but I don't see an option for this. However, I can change my avatar.I want to change my nickname after creating an account, but I don't see an option for this. However, I can change my avatar.https://code.briarproject.org/briar/briar/-/issues/2261Include mailbox API version in local and remote mailbox properties2022-05-16T13:59:41ZakwizgranInclude mailbox API version in local and remote mailbox propertiesDepends on https://code.briarproject.org/briar/briar/-/issues/2298Depends on https://code.briarproject.org/briar/briar/-/issues/2298Mailbox: Sync mailbox propertiesDaniel LublinDaniel Lublinhttps://code.briarproject.org/briar/briar/-/issues/2259Migrate to Tor 0.4.52022-04-19T11:26:19ZakwizgranMigrate to Tor 0.4.5Tor 0.3.5.18 is the last release in the 0.3.5 LTS series. The new LTS series is 0.4.5. Updating to the new series will require more testing than our usual updates, and may require changes to tor-reproducer.
https://gitlab.torproject.org...Tor 0.3.5.18 is the last release in the 0.3.5 LTS series. The new LTS series is 0.4.5. Updating to the new series will require more testing than our usual updates, and may require changes to tor-reproducer.
https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/CoreTorReleasesAndroid 1.4Torsten GroteTorsten Grote