briar issueshttps://code.briarproject.org/briar/briar/-/issues2023-03-15T12:30:45Zhttps://code.briarproject.org/briar/briar/-/issues/2412Research UWB integration2023-03-15T12:30:45ZVladislavResearch UWB integrationResearch possibility of integration Ultra-Wideband technology.
Find out its strengths and the opportunities it can provide.
Possibilities of combining Bluetooth and UWB.Research possibility of integration Ultra-Wideband technology.
Find out its strengths and the opportunities it can provide.
Possibilities of combining Bluetooth and UWB.https://code.briarproject.org/briar/briar/-/issues/2395Check for Bluetooth timeout setting on stock Android 132023-02-01T14:36:46ZakwizgranCheck for Bluetooth timeout setting on stock Android 13CalyxOS 4.3.0 (based on Android 13) has a "Bluetooth timeout" setting that automatically turns off Bluetooth if no devices are connected for a configurable amount of time (the timeout can also be disabled). This setting could prevent Bri...CalyxOS 4.3.0 (based on Android 13) has a "Bluetooth timeout" setting that automatically turns off Bluetooth if no devices are connected for a configurable amount of time (the timeout can also be disabled). This setting could prevent Briar from connecting to contacts via Bluetooth if the timeout period elapsed with no contact connections.
We should check whether this setting exists upstream (stock Android 13) and whether a timeout is enabled by default.https://code.briarproject.org/briar/briar/-/issues/2383WIP Graphics not displayed in landscape orientation2022-11-08T12:48:58ZIvanaWIP Graphics not displayed in landscape orientationWorkflow: create new nearby contact
Documenting everything workflow by workflow.. will attach the docs when done.. this is a WIP ticketWorkflow: create new nearby contact
Documenting everything workflow by workflow.. will attach the docs when done.. this is a WIP tickethttps://code.briarproject.org/briar/briar/-/issues/2318Crash on HTC One M9 when switching between the briar app and the settings ap...2023-01-25T17:23:06ZIvanaCrash on HTC One M9 when switching between the briar app and the settings app in the foregroundSteps to reproduce
- Install Briar and create a user account
- user is asked to "allow connections" (ie allow battery optimisation to be switched off)
- before tapping the "allow connections" button, go to settings app and verify that...Steps to reproduce
- Install Briar and create a user account
- user is asked to "allow connections" (ie allow battery optimisation to be switched off)
- before tapping the "allow connections" button, go to settings app and verify that the battery optimisation is 'on' (although probabky not relevant for this crash)
- then bring briar app back into the foreground tap the "allow connections"
- go to settings
- bring briar back into the foreground -> crash.
This as reproduced 2 times on HTC One M9 (android 7) and it doesn't have when the user performs the same steps with mailbox app.
Logfiles are attached
@akwizgran analysed and here are his comments (from MM)
looks like this is the stacktrace of the crash:
org.briarproject.briar.android.account.SetupActivity}: java.lang.RuntimeException: Parcel android.os.Parcel@7c94038: Unmarshalling unknown type code 6881391 at offset 684
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2729)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2790)
at android.app.ActivityThread.-wrap12(ActivityThread.java)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1505)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:173)
at android.app.ActivityThread.main(ActivityThread.java:6523)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:938)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:828)
Caused by: java.lang.RuntimeException: Parcel android.os.Parcel@7c94038: Unmarshalling unknown type code 6881391 at offset 684
at android.os.Parcel.readValue(Parcel.java:2452)
at android.os.Parcel.readSparseArrayInternal(Parcel.java:2807)
at android.os.Parcel.readSparseArray(Parcel.java:2076)
at android.os.Parcel.readValue(Parcel.java:2430)
at android.os.Parcel.readArrayMapInternal(Parcel.java:2726)
at android.os.BaseBundle.unparcel(BaseBundle.java:269)
at android.os.Bundle.getSparseParcelableArray(Bundle.java:910)
at androidx.fragment.app.FragmentStateManager.restoreState(FragmentStateManager.java:405)
at androidx.fragment.app.FragmentManager.restoreSaveState(FragmentManager.java:2735)
at androidx.fragment.app.FragmentController.restoreSaveState(FragmentController.java:198)
at androidx.fragment.app.FragmentActivity$2.onContextAvailable(FragmentActivity.java:149)
at androidx.activity.contextaware.ContextAwareHelper.dispatchOnContextAvailable(ContextAwareHelper.java:99)
at androidx.activity.ComponentActivity.onCreate(ComponentActivity.java:297)
at androidx.fragment.app.FragmentActivity.onCreate(FragmentActivity.java:273)
at androidx.appcompat.app.AppCompatActivity.onCreate(AppCompatActivity.java:115)
at org.briarproject.briar.android.activity.BaseActivity.onCreate(BaseActivity.java:92)
at org.briarproject.briar.android.account.SetupActivity.onCreate(SetupActivity.java:52)
at android.app.Activity.performCreate(Activity.java:6673)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1136)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2682)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2790)
at android.app.ActivityThread.-wrap12(ActivityThread.java)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1505)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:173)
at android.app.ActivityThread.main(ActivityThread.java:6523)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:938)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:828) [Briar_crash_11_May_2022_reproduced.txt](/uploads/ddad5db164d4d61b49a3ac11b70d9394/Briar_crash_11_May_2022_reproduced.txt)
[Briar_crash_11_May_2022.txt](/uploads/920b2d55e162d999725a2f03d704348a/Briar_crash_11_May_2022.txt)https://code.briarproject.org/briar/briar/-/issues/2310Option to allow screenshots2022-10-27T21:39:31ZFlyingP1g FlyingP1gOption to allow screenshotsSometimes users like to make screenshots, to share information quickly.
A simple slider should work. I do not think this option will have too many negative consequences.Sometimes users like to make screenshots, to share information quickly.
A simple slider should work. I do not think this option will have too many negative consequences.https://code.briarproject.org/briar/briar/-/issues/2308Emoji button doesn't work on Android 42023-03-22T12:47:53ZakwizgranEmoji button doesn't work on Android 4* Android version: 4.1.2
* Phone model: Samsung GT-I8260 (arubaslimssxx)
* Briar version: 1.4.5 (4df523a)
* User feedback: "I would like to inform you about the emoji icon which does nothing. It does not show the emoji selection box and ...* Android version: 4.1.2
* Phone model: Samsung GT-I8260 (arubaslimssxx)
* Briar version: 1.4.5 (4df523a)
* User feedback: "I would like to inform you about the emoji icon which does nothing. It does not show the emoji selection box and therefore it is not possible to send any emoji."
I can reproduce this on my API 16 test device (Samsung Galaxy Ace 2).https://code.briarproject.org/briar/briar/-/issues/2252Password screen when setting up the account on new account - shows password w...2022-01-13T13:39:04ZIvanaPassword screen when setting up the account on new account - shows password when it should be hidden and the other way aroundSteps to execute
- Install briar debug on a device (I sued Pixel 2)
- Enter a nickname into the Nickname field when asked
- On the next screen type in the password
Expected results
- Password should be visible when they 'eye' icon is ...Steps to execute
- Install briar debug on a device (I sued Pixel 2)
- Enter a nickname into the Nickname field when asked
- On the next screen type in the password
Expected results
- Password should be visible when they 'eye' icon is on, and hidden when the 'eye' icon is crossed
Actual results
- Password behaves the other way around, it shows when the 'eye' icon is crossed, and it is masked when the 'eye' icon is not crossed.
- Screenshot attached
![device-2022-01-13-141405](/uploads/a1566f1ae139000bf68707d26a224089/device-2022-01-13-141405.png)https://code.briarproject.org/briar/briar/-/issues/2226Error handling for mailbox uploads2022-04-19T16:11:45ZakwizgranError handling for mailbox uploadsWhen communicating via mailboxes, the max latency and thus the retransmission interval are long, so we need to be careful about any circumstances that could cause messages to be lost.
On the sender side, if an error (such as an IO error...When communicating via mailboxes, the max latency and thus the retransmission interval are long, so we need to be careful about any circumstances that could cause messages to be lost.
On the sender side, if an error (such as an IO error, app shutdown, app crash or device crash) occurs while we're writing messages and acks to a file, we need to ensure that those messages and acks can be sent again after recovering from the error.
We can do this by generating a unique ID for the sync session and recording the IDs of any messages sent or acked in that session. This state can be deleted when the session completes successfully. At the next startup, if we find this session state in the DB we know that the session didn't complete successfully, so we mark the messages and acks as unsent.
We also need to handle errors that occur after the file has been created but before it's been uploaded. We can do this by storing the contact ID and filename in the DB before starting the session and removing them when the upload completes successfully (#2230). Next time we come online, if we find any upload state in the DB we know that the corresponding uploads didn't complete successfully, so we queue the files for upload. We should use the DB for this, rather storing the files in a separate upload directory per contact, to avoid leaking metadata to the filesystem about which uploads are destined for which contacts.
We should store the contact ID and filename before starting the sync session, so that there's no gap where the DB doesn't contain a record of the incomplete session/upload. If a crash happens during the session we may end up marking the messages and acks in the session as unsent as well as queueing the (possibly incomplete) file for upload. This is acceptable - the receiver should be able to handle the (possibly incomplete) file and another file containing the same messages and acks. Similarly, if the upload completes successfully but a crash happens before we remove the contact ID and filename from the DB, it's acceptable to upload the file again at the next startup, as the receiver should be able to handle the duplicate file.
It's still possible for the file to be lost after a successful upload, but losses beyond that point are handled by different mechanisms (#2191, #2192, #2225).
Depends on #2230.Mailbox: Manage mailbox connectionsakwizgranakwizgran2022-01-03https://code.briarproject.org/briar/briar/-/issues/2184Update mailbox properties when adding a contact to the mailbox2022-04-01T13:19:23ZakwizgranUpdate mailbox properties when adding a contact to the mailboxDepends on #2181, #2183.Depends on #2181, #2183.Mailbox: Sync mailbox propertieshttps://code.briarproject.org/briar/briar/-/issues/1953Dialog about "Disappearing messages changed" for image only messages2021-03-08T12:27:51ZSebastianDialog about "Disappearing messages changed" for image only messages![issue](/uploads/8e8d903d76bddc993f68dfc1af183ae6/issue.png)
The "Disappearing messages changed" appears although it shouldn't.
Steps to reproduce:
1. open a fresh, empty conversation
2. enable disappearing messages
3. (optional: send...![issue](/uploads/8e8d903d76bddc993f68dfc1af183ae6/issue.png)
The "Disappearing messages changed" appears although it shouldn't.
Steps to reproduce:
1. open a fresh, empty conversation
2. enable disappearing messages
3. (optional: send a text message and notice that the dialog does not appear)
4. send an image message (without text) and see the dialog appear
It doesn't work just once, it works repeatedly and also after sending more text-only or image-with-text messagesSelf-destructing messagesTorsten GroteTorsten Grote2021-01-31https://code.briarproject.org/briar/briar/-/issues/1810Download RSS feeds from mailbox2022-11-17T14:30:25ZakwizgranDownload RSS feeds from mailboxWrite backend code for downloading RSS feeds offered by the mailbox, parsing the feeds and creating Briar blog posts for any new feed items.
Only feeds the user has subscribed to (see #1809) should be downloaded.
Depends on #1804.Write backend code for downloading RSS feeds offered by the mailbox, parsing the feeds and creating Briar blog posts for any new feed items.
Only feeds the user has subscribed to (see #1809) should be downloaded.
Depends on #1804.RSS import2022-10-31https://code.briarproject.org/briar/briar/-/issues/1809Subscribe to RSS feeds offered by mailbox2022-11-17T14:30:38ZakwizgranSubscribe to RSS feeds offered by mailboxDesign and implement a UI and backend for viewing the list of RSS feeds offered by the user's mailbox and subscribing to feeds.
Depends on #1804.Design and implement a UI and backend for viewing the list of RSS feeds offered by the user's mailbox and subscribing to feeds.
Depends on #1804.RSS import2022-10-31https://code.briarproject.org/briar/briar/-/issues/1712Detect Bluetooth connection limit2022-02-25T15:09:28ZakwizgranDetect Bluetooth connection limitDifferent devices can support different numbers of simultaneous Bluetooth connections. Since we don't have a way to determine a priori how many connections a given device can support, we should try to detect the device's limit and stay b...Different devices can support different numbers of simultaneous Bluetooth connections. Since we don't have a way to determine a priori how many connections a given device can support, we should try to detect the device's limit and stay below it.
Related to #1130.akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1705NPE when sending private message2020-02-12T14:27:12ZakwizgranNPE when sending private message* Android version: 8.0.0
* Phone model: Lenovo K520 (seoul)
* Briar version: 1.2.4 (no commit hash, custom package name)
Stacktrace:
```
java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.String java.lang.String...* Android version: 8.0.0
* Phone model: Lenovo K520 (seoul)
* Briar version: 1.2.4 (no commit hash, custom package name)
Stacktrace:
```
java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.String java.lang.String.replace(java.lang.CharSequence, java.lang.CharSequence)' on a null object reference
at org.briarproject.briar.android.view.TextAttachmentController.onSendEvent(TextAttachmentController.java:107)
at org.briarproject.briar.android.view.TextSendController.lambda$new$0$TextSendController(TextSendController.java:37)
at org.briarproject.briar.android.view.-$$Lambda$TextSendController$10Be2Hyuh5TqgqEmcNIq7rn_c-c.onClick(Unknown Source:2)
at android.view.View.performClick(View.java:6256)
at android.view.View$PerformClick.run(View.java:24701)
at android.os.Handler.handleCallback(Handler.java:789)
at android.os.Handler.dispatchMessage(Handler.java:98)
at android.os.Looper.loop(Looper.java:164)
at android.app.ActivityThread.main(ActivityThread.java:6653)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:240)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:770)
```
This is a custom build, so the bug may not exist on master.https://code.briarproject.org/briar/briar/-/issues/1663Android 11 Scoped Storage - Android future completely Google dependent (centr...2019-11-13T10:13:34ZGhost UserAndroid 11 Scoped Storage - Android future completely Google dependent (centralization)I read some details (Scoped Storage) about what should come in Android Q (Android 10), but was aborted first and will be introduced with Android 11.
Why Google lies to the users and what the honest developers have to say about it and ha...I read some details (Scoped Storage) about what should come in Android Q (Android 10), but was aborted first and will be introduced with Android 11.
Why Google lies to the users and what the honest developers have to say about it and have recognized it correctly.
https://www.xda-developers.com/android-q-storage-access-framework-scoped-storage/
> Google touts the security and privacy benefits of this change, but technically speaking, there is no improvement. Apps have had the ability to privately store files since Android 1.0, and almost all apps make use of this capability. When you grant an app access to the root directory of your storage via SAF, it can read, write, and send any file it wants to its nefarious developer in the exact same fashion it could when you granted an app access to storage in Pie.
> The only “security improvement” comes about because it’s now a more arduous process for a user to do this. Unless of course an app only wants to steal your most personal information, like photos and videos you’ve taken, for which Google has added an alternative access solution which uses a simple pop-up click-yes security dialog.
> It is not known what benefits Google hopes to achieve with this change. The official stated reason in the Android Q beta documentation is to “give users more control over their files and to limit file clutter.” Scoped storage, in its present form, is a new limitation of what the user is allowed to do, not an extension of their control. The claim of reducing clutter may be somewhat valid, but only because the change reduces the ability to use files at all. And “clutter” is increased when you consider the problem of some apps now having to duplicate files to work with them.
> If Google is truly concerned about giving users more control over files and clutter, they should architect a solution that directly addresses that, rather than falsely branding the current Android Q design as such an improvement. The simplest answer would be to let users decide if they want an app to have scoped or general filesystem access, using the extant storage permission request dialog. If there is a particular concern for users making poor decisions here, it’s certainly possible to make that dialog more prominent and require additional user interaction to approve an app for full access.
> The answer to how Android can give users more control of their files is to actually give users more control, not to take it away and fundamentally constrain the capabilities of the Android platform.
What do we see here?
The developers knew exactly how to really improve it for the users and the added value behind it.
Why does Google lie and want to include it in Android Q even though it's not an improvement? Google wants to limit Android even further, just like Apple does with their iOS system and products that use this system e.g. iPhone.
Google is pursuing the same goals as Apple and Microsoft in the final stages. Building a centralized system. No more control by users or developers, only server dependent.
The problem that most Android or Linux developers have known about for a long time and therefore do not develop apps for centralized systems. But the consumers don't know it yet or don't see the interrelations and that's a problem.
Since Google is able to integrate it into Android 11, they will try again and again in the future to make the Android platform similar to the Apple platform.
What many do not know Google does these steps in small steps. So it always starts first.
Only in a few years one sees the effects. Apps can only be installed from the Google Play Store. Everything else goes only by an software which one sends to Google, in order to get a permission, so that the App can be installed. No offline setup/use possible anymore! Android devices can only be set up and used via Internet activation at some point (as with iPhone).
We have to act otherwise we will be more and more controlled by global corporations that only pursue their own interests (centralization, control, economic growth, fake security problems to limit the operating system, more market power, etc).
But the cause is in reality the consumers. The majority currently believe that Google, Apple, etc... are on the users' side. No, that's not true. It's just an illusion to distract.
The fact is that without the users' money, corporations like Google cannot exist. The decision is always ours!
We millions of users can spend more money in independent systems, hardware, software. We users can support even more independent developers. It's really possible. Don't forget!https://code.briarproject.org/briar/briar/-/issues/16626. The Briar apk name should contain the version number in the name as well2019-11-13T10:09:26ZGhost User6. The Briar apk name should contain the version number in the name as wellDownload the Briar app for Android here: https://briarproject.org/apk/briar.apk
In the name is no version number. it's just: **briar.apk**
Perhaps more details should be added to better organize your apk library faster and more accurat...Download the Briar app for Android here: https://briarproject.org/apk/briar.apk
In the name is no version number. it's just: **briar.apk**
Perhaps more details should be added to better organize your apk library faster and more accurately.
Like this, for example: **Briar v1.2.4.apk** or **Briar-1.2.4.apk**https://code.briarproject.org/briar/briar/-/issues/1611"Add contact at a distance" share action is available in 1.1 releases2019-11-06T09:48:24Zakwizgran"Add contact at a distance" share action is available in 1.1 releasesThe remote contact feature is accessible in recent releases from the 1.1 series via the "add contact at a distance" share action.The remote contact feature is accessible in recent releases from the 1.1 series via the "add contact at a distance" share action.Android 1.1https://code.briarproject.org/briar/briar/-/issues/1599[headless] obsolete dependency integrity assertion2019-08-14T14:22:42Ziwakeh[headless] obsolete dependency integrity assertion[Line 61](https://code.briarproject.org/briar/briar/blob/master/briar-headless/witness.gradle#L61) in briar-headless/witness.gradle seems redundant.[Line 61](https://code.briarproject.org/briar/briar/blob/master/briar-headless/witness.gradle#L61) in briar-headless/witness.gradle seems redundant.https://code.briarproject.org/briar/briar/-/issues/1575exclude the redundant rome-utils jar from being packaged2019-08-20T09:03:04Ziwakehexclude the redundant rome-utils jar from being packagedPlease, see comment below.Please, see comment below.https://code.briarproject.org/briar/briar/-/issues/1546Support Bluetooth discovery for connecting to contacts2022-01-26T13:50:35ZakwizgranSupport Bluetooth discovery for connecting to contactsOn Android 8+ apps don't have access to the device's own Bluetooth address, so we can't share our address with contacts. When adding contacts we use discovery to work around this (#1147). Users have reported that Bluetooth works when add...On Android 8+ apps don't have access to the device's own Bluetooth address, so we can't share our address with contacts. When adding contacts we use discovery to work around this (#1147). Users have reported that Bluetooth works when adding contacts, but not when subsequently trying to communicate.
Learning our Bluetooth address from contacts would raise some tricky security and privacy issues, such as revealing to existing contacts, by adding a Bluetooth address to our transport properties, that we've just added a contact via Bluetooth.
After adding a contact we could store the contact's address for subsequent connection attempts, but that would only let us connect to contacts who were added via Bluetooth. To let us connect to any nearby contact we need to make the device discoverable and perform discovery.
Making the device temporarily discoverable requires user confirmation each time. Making the device permanently discoverable has privacy implications, and doesn't work on all devices (e.g. the Sony Xperia Tipo). Discovering nearby devices may require a lot of power and may interfere with wifi (#699). BLE discovery uses less power and doesn't require user confirmation, but not all devices can be discovered via BLE (#303).
A possible solution would be to make the device temporarily discoverable, and perform discovery, when the user enables the Bluetooth transport (#185). Then we could provide some way of manually triggering discovery, such as a "nearby contacts" tab with a "scan" button. This would limit the discoverability window, and the battery and interference impact of running discovery, to periods when the user had explicitly shown an interest in connecting to nearby contacts. Confirmation dialogs would only be shown in response to user actions.
This falls short of the goal of effortless connectivity, but it may be the best we can achieve within the constraints of the platform.