briar issueshttps://code.briarproject.org/groups/briar/-/issues2017-12-18T07:40:22Zhttps://code.briarproject.org/briar/briar/-/issues/906Tapjacking vulnerability2017-12-18T07:40:22ZakwizgranTapjacking vulnerabilityBriar is vulnerable to tapjacking attacks, where the user interacts with Briar while she believes she's interacting with another app. This can be used to delete the user's account, for example.
Proof-of-concept:
https://cure53.de/exc...Briar is vulnerable to tapjacking attacks, where the user interacts with Briar while she believes she's interacting with another app. This can be used to delete the user's account, for example.
Proof-of-concept:
https://cure53.de/exchange/792346243678/Tapjacking_PoC2.zipMilestone GJulian DehmJulian Dehmhttps://code.briarproject.org/briar/briar/-/issues/905Move Testing constants into Gradle2017-12-18T07:40:22ZErnir ErlingssonMove Testing constants into GradleOne could argue that having to remember to set the `TESTING` flag to false, before releasing versions for a production, is a security flaw in itself.
There's a better way: we should use gradle to set the flag depending if we're using a ...One could argue that having to remember to set the `TESTING` flag to false, before releasing versions for a production, is a security flaw in itself.
There's a better way: we should use gradle to set the flag depending if we're using a debug or release version.Milestone GJulian DehmJulian Dehmhttps://code.briarproject.org/briar/briar/-/issues/904Briar doesn't shut down if Tor has crashed2017-07-31T13:10:54ZakwizgranBriar doesn't shut down if Tor has crashedIf the Tor process crashes, Briar waits forever for the control port shutdown command to complete. It should eventually time out so that Briar doesn't need to be force stopped.If the Tor process crashes, Briar waits forever for the control port shutdown command to complete. It should eventually time out so that Briar doesn't need to be force stopped.Android Beta 1Julian DehmJulian Dehmhttps://code.briarproject.org/briar/briar/-/issues/903Tor crashing on Android 7 after first run2017-12-18T07:40:22ZJulian DehmTor crashing on Android 7 after first runAfter the first run of briar (if a tor circuit was established), almost any subsequent run crashes tor / libc for me. This happens both on my Lineage 14.1 phone and the emulator (with sdk 25).
Here's the log (I added the function name...After the first run of briar (if a tor circuit was established), almost any subsequent run crashes tor / libc for me. This happens both on my Lineage 14.1 phone and the emulator (with sdk 25).
Here's the log (I added the function names in french quotation marks for the tor binary in the backtrace (the last column)) :
````
LineageOS Version: '14.1-20170225-UNOFFICIAL-i9305'
Build fingerprint: 'samsung/m3xx/m3:4.4.4/KTU84P/I9305XXUFPB1:user/release-keys'
Revision: '0'
ABI: 'arm'
pid: 9222, tid: 9222, name: tor >>> /data/user/0/org.briarproject.briar/app_tor/tor <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4f4f4ad8
r0 befff748 r1 58b517d0 r2 410ec1c0 r3 befff754
r4 befff754 r5 4f4f4ad8 r6 00003918 r7 40e40500
r8 00000000 r9 00000000 sl 00000000 fp befff744
ip 4018f85c sp befff6e8 lr 401523c7 pc 40153bb8 cpsr 200f0030
d0 74657320746f6e20 d1 0000000000000000
d2 0000000000000000 d3 0000000000000000
d4 52414d4d55532072 d5 656e6e6f43223d59
d6 6f7420676e697463 d7 726f542065687420
d8 0000000000000000 d9 0000000000000000
d10 0000000000000000 d11 0000000000000000
d12 0000000000000000 d13 0000000000000000
d14 0000000000000000 d15 0000000000000000
d16 0000000000000000 d17 0000000000000000
d18 0000000001f66130 d19 0000000001881b68
d20 0000000000000000 d21 0000000000000000
d22 0000000000000000 d23 0000000000000000
d24 3f36c051b8f0af77 d25 3fa0842100000000
d26 3fdb6db6db6fabff d27 0000000000000000
d28 0000000000000000 d29 0000000000000000
d30 0000000000000000 d31 0000000000000000
scr 80000010
backtrace:
03-01 13:17:37.145 5444-5444/? A/DEBUG: #00 pc 0004cbb8 /system/lib/libc.so (timesub+35)
03-01 13:17:37.145 5444-5444/? A/DEBUG: #01 pc 0004b3c3 /system/lib/libc.so (gmtime_r+22)
03-01 13:17:37.145 5444-5444/? A/DEBUG: #02 pc 001fe300 /data/data/org.briarproject.briar/app_tor/tor <gmtime_r@plt>
03-01 13:17:37.145 5444-5444/? A/DEBUG: #03 pc 00212794 /data/data/org.briarproject.briar/app_tor/tor <tor_gmtime_r>
03-01 13:17:37.145 5444-5444/? A/DEBUG: #04 pc 0007d3f0 /data/data/org.briarproject.briar/app_tor/tor <format_iso_time>
03-01 13:17:37.145 5444-5444/? A/DEBUG: #05 pc 0007ebe8 /data/data/org.briarproject.briar/app_tor/tor <dump_microdescriptor>
03-01 13:17:37.145 5444-5444/? A/DEBUG: #06 pc 0007e3a0 /data/data/org.briarproject.briar/app_tor/tor <microdesc_cache_rebuild>
03-01 13:17:37.145 5444-5444/? A/DEBUG: #07 pc 0007d5e4 /data/data/org.briarproject.briar/app_tor/tor <get_microdesc_cache>
03-01 13:17:37.145 5444-5444/? A/DEBUG: #08 pc 000886ac /data/data/org.briarproject.briar/app_tor/tor <get_microdesc_cache>
03-01 13:17:37.145 5444-5444/? A/DEBUG: #09 pc 0008527c /data/data/org.briarproject.briar/app_tor/tor <nodelist_set_consensus>
03-01 13:17:37.145 5444-5444/? A/DEBUG: #10 pc 000804b0 /data/data/org.briarproject.briar/app_tor/tor <networkstatus_set_current_consensus>
03-01 13:17:37.145 5444-5444/? A/DEBUG: #11 pc 00076db8 /data/data/org.briarproject.briar/app_tor/tor <router_reload_consensus_>
03-01 13:17:37.145 5444-5444/? A/DEBUG: #12 pc 0007c3b4 /data/data/org.briarproject.briar/app_tor/tor <do_main_loop>
03-01 13:17:37.145 5444-5444/? A/DEBUG: #13 pc 000713b8 /data/data/org.briarproject.briar/app_tor/tor <tor_main>
03-01 13:17:37.145 5444-5444/? A/DEBUG: #14 pc 00016ca1 /system/lib/libc.so (__libc_init+48)
03-01 13:17:37.145 5444-5444/? A/DEBUG: #15 pc 00071358 /data/data/org.briarproject.briar/app_tor/tor <libc_init>
````
I also uploaded a tombstone https://code.briarproject.org/goapunk/briar/raw/fileStorage/tombstone_00.
Steps to reproduce:
1. Install and run Briar
2. Wait until tor established a circuit
3. Log out / Close Briar
4. Start Briar
5. Check the log (don't filter for Briar, check the unfiltered logcat)
Once tor crashed you need to close Briar through settings->apps->briar-> force closeMilestone GJulian DehmJulian Dehmhttps://code.briarproject.org/briar/briar/-/issues/902Improve key binding in introduction protocol2018-03-29T12:53:22ZakwizgranImprove key binding in introduction protocolThe introduction protocol provides the following guarantees:
* Each introducee knows that the ephemeral and identity public keys she received are owned by the other introducee
* Each introducee knows that the ephemeral and identity p...The introduction protocol provides the following guarantees:
* Each introducee knows that the ephemeral and identity public keys she received are owned by the other introducee
* Each introducee knows that the ephemeral and identity public keys she received were used by the other introducee in the same run of the protocol - in other words it binds each introducee's ephemeral key pair to the same introducee's identity key pair and vice versa
* Each introducee knows that the ephemeral public key she received was used by the other introducee in the current run of the protocol - in other words it binds the introducees' ephemeral key pairs to each other
Unlike the contact exchange protocol, the introduction protocol does not verify the personal identity of the other introducee. The other introducee may be a persona presented by the introducer as part of a man-in-the-middle attack. However, the introduction protocol guarantees that if an introducee later verifies that a person owns the identity public key she received, that person also owns the ephemeral public key she received, and no man-in-the-middle attack took place.
To achieve this, each introducee uses her identity key pair to sign a nonce derived from the ephemeral shared secret, and authenticates her identity key pair using a symmetric key derived from the ephemeral shared secret.
Each introducee knows that the nonce she received is fresh, as it depends on her own ephemeral key pair, so the nonce itself proves that the other introducee owns the ephemeral public key received by the first introducee, while the signature proves that the other introducee owns the identity public key received by the first introducee.
The nonce is unique to this combination of ephemeral key pairs, so the signature represents a claim by the owner of the received identity public key that she took part in a protocol run involving both ephemeral key pairs. Authenticating the identity public key with a symmetric key derived from the ephemeral shared secret represents a claim by the owner of the received ephemeral public keys that she took part in a protocol run involving both ephemeral key pairs and the identity key pair.
As far as I can tell, this construction is secure and achieves what we need, but it's unnecessarily convoluted. The binding and proof of ownership that's achieved by signing nonces could be achieved more straightforwardly by signing public keys:
* Each introducee signs both introducees' ephemeral public keys and timestamps using her identity key pair
* Each introducee authenticates both introducees' identity public keys, ephemeral public keys and timestamps, using a symmetric key derived from the ephemeral shared secret
If we're not concerned with deniability, each introducee can sign both introducees' identity public keys, ephemeral public keys and timestamps. But as far as I can see, we get all the assurance we need without doing this.
Related to #901.Android 1.0https://code.briarproject.org/briar/briar/-/issues/900Simplify Sharing Client State Machine2017-12-18T07:40:22ZTorsten GroteSimplify Sharing Client State MachineOld State Machine
![old](https://code.briarproject.org/akwizgran/briar/uploads/7c45438c6f90e96422d8c8bff7275dcc/state-machine-2.png)
New State Machine
![new](https://code.briarproject.org/akwizgran/briar/uploads/a38c6a152df9d9ee3d76d2263...Old State Machine
![old](https://code.briarproject.org/akwizgran/briar/uploads/7c45438c6f90e96422d8c8bff7275dcc/state-machine-2.png)
New State Machine
![new](https://code.briarproject.org/akwizgran/briar/uploads/a38c6a152df9d9ee3d76d2263d05e3f1/state-machine-3.png)
In addition, the [error state should be eliminated](/akwizgran/briar/issues/721#note_18410). If an error occurs, we send an abort message, clean up the external state (for example, unshare the group), and return to the start state (with the abort message's ID as the previous message ID). If we get an abort message, we clean up the external state and return to the start state. We don't send an abort message in response, otherwise we'd get into a loop.Milestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/899Forum subtitle is not updated when contact joins/leaves2019-02-27T10:24:27ZakwizgranForum subtitle is not updated when contact joins/leavesThe sharing information in the forum subtitle isn't updated when the number of contacts the forum is shared with changes due to a contact joining or leaving the forum.The sharing information in the forum subtitle isn't updated when the number of contacts the forum is shared with changes due to a contact joining or leaving the forum.https://code.briarproject.org/briar/briar/-/issues/898Invitations to our own blog should be rejected2020-11-20T11:22:52ZakwizgranInvitations to our own blog should be rejectedThe validator or delivery hook should check whether an invite message refers to our own blog, and if so, consider it invalid.The validator or delivery hook should check whether an invite message refers to our own blog, and if so, consider it invalid.https://code.briarproject.org/briar/briar/-/issues/897Reply button of received forum post doesn't work after using scroll button2019-02-27T10:32:40ZakwizgranReply button of received forum post doesn't work after using scroll buttonSteps to reproduce:
* Create a forum with a screenful of posts, shared between devices A and B
* Write a new top-level post on device A
* When the post is received on device B, use the scroll button to show it
* Try to reply to the post ...Steps to reproduce:
* Create a forum with a screenful of posts, shared between devices A and B
* Write a new top-level post on device A
* When the post is received on device B, use the scroll button to show it
* Try to reply to the post on device B - the reply button doesn't work
If I scroll to the post manually rather than using the scroll button, the reply button works. The reply button works on device A (where the post was written). It can be made to work on device B by touching the reply button on another post, backing out, then touching the reply button on the new post.https://code.briarproject.org/briar/briar/-/issues/896Use dependencies to deliver transport property updates in order2017-12-15T13:08:23ZakwizgranUse dependencies to deliver transport property updates in orderThis will allow us to remove the buggy message queue.This will allow us to remove the buggy message queue.https://code.briarproject.org/briar/briar/-/issues/894Remember list position and restore it2017-12-18T07:40:22ZTorsten GroteRemember list position and restore itOne of the testers moved a conversation from a forum discussion (that was supposed to be for more people) to a private conversation, because "forums are hard to read". When asked for more details and he said that you have to scroll down ...One of the testers moved a conversation from a forum discussion (that was supposed to be for more people) to a private conversation, because "forums are hard to read". When asked for more details and he said that you have to scroll down every time to the last message, so you have to real all the thread again and again like in a non-quoted email thread.
He said that it would help immensely, if Briar would remember the last message you had read and show it again when you re-enter the forum.
So this ticket is about remembering the list position and then restoring it when the screen is rotated or the user re-enters the list.
There are several list positions we could restore depending on which list is concerned:
* just the last known scrolling position before the list was left
* the position of the message that was marked as read last
* the position of the message that was marked as read first when the conversation was enteredAndroid Beta 1https://code.briarproject.org/briar/briar/-/issues/893Introduction can fail if pressing ACCEPT two times2017-12-18T07:40:22ZTorsten GroteIntroduction can fail if pressing ACCEPT two timesWhen a phone is to slow to update the invitation message, and the user impatiently presses ACCEPT again, the introduction gets aborted:
```
01-04 11:24:17.048 I/IntroduceeEngine: Sending accept response in state AWAIT_RESPONSES
01-04 11...When a phone is to slow to update the invitation message, and the user impatiently presses ACCEPT again, the introduction gets aborted:
```
01-04 11:24:17.048 I/IntroduceeEngine: Sending accept response in state AWAIT_RESPONSES
01-04 11:24:17.048 I/IntroduceeEngine: Moving on to state AWAIT_REMOTE_RESPONSE
01-04 11:24:17.118 I/MessageQueueManagerImpl: Sending message with position 7
01-04 11:24:17.438 I/ConversationActivity: Marking read took 19 ms
01-04 11:24:17.878 I/DuplexOutgoingSession: Generated offer: true
01-04 11:24:17.878 I/DuplexOutgoingSession: Sent offer
01-04 11:24:18.348 I/ConversationActivity: Loading messages took 462 ms
01-04 11:24:18.428 I/DuplexOutgoingSession: Generated request: true
01-04 11:24:18.428 I/DuplexOutgoingSession: Sent request
01-04 11:24:18.438 W/ConnectionManagerImpl: java.net.SocketTimeoutException
java.net.SocketTimeoutException
at java.net.PlainSocketImpl.read(PlainSocketImpl.java:491)
at java.net.PlainSocketImpl.access$000(PlainSocketImpl.java:46)
at java.net.PlainSocketImpl$PlainSocketInputStream.read(PlainSocketImpl.java:240)
at org.briarproject.bramble.crypto.StreamDecrypterImpl.readFrame(StreamDecrypterImpl.java:70)
at org.briarproject.bramble.transport.StreamReaderImpl.readFrame(StreamReaderImpl.java:63)
at org.briarproject.bramble.transport.StreamReaderImpl.read(StreamReaderImpl.java:51)
at org.briarproject.bramble.sync.RecordReaderImpl.readRecord(RecordReaderImpl.java:59)
at org.briarproject.bramble.sync.RecordReaderImpl.eof(RecordReaderImpl.java:100)
at org.briarproject.bramble.sync.IncomingSession.run(IncomingSession.java:65)
at org.briarproject.bramble.plugin.ConnectionManagerImpl$ManageIncomingDuplexConnection.run(ConnectionManagerImpl.java:278)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
at java.lang.Thread.run(Thread.java:856)
01-04 11:24:18.438 I/ConnectionRegistryImpl: Incoming connection unregistered: org.briarproject.bramble.tor
01-04 11:24:18.438 I/ConnectionRegistryImpl: Contact disconnected
01-04 11:24:19.298 I/DuplexOutgoingSession: Generated offer: false
01-04 11:24:19.438 I/DuplexOutgoingSession: Generated request: false
01-04 11:24:19.618 W/IntroduceeEngine: Error: Invalid action in state AWAIT_REMOTE_RESPONSE
01-04 11:24:19.618 W/IntroduceeEngine: Aborting protocol session in state AWAIT_REMOTE_RESPONSE
```Milestone GTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/892Separate RSS posts from personal blog posts2017-12-18T07:40:22ZakwizgranSeparate RSS posts from personal blog postsThis is an umbrella ticket for discussing how to separate RSS posts from personal blog posts in order to solve some of the issues testers have reported with RSS feeds, such as #796 and #866.
Questions raise by @grote on #476:
> The cur...This is an umbrella ticket for discussing how to separate RSS posts from personal blog posts in order to solve some of the issues testers have reported with RSS feeds, such as #796 and #866.
Questions raise by @grote on #476:
> The current descriptor is a BdfList of `author_name (string), author_public_key (raw)`. Questions coming to mind are:
> * Do we tie RSS blogs to one author in the same way?
> * Will they use the same descriptor format, or can they use a different one depending on the flag?
> * Should we use an (int) as a flag to be able to add different blog types later or a (boolean)?
> * Do we add a title field to the descriptor?
> * Or should there maybe be a dedicated RSS client with a different client ID that inherits from the blog client?Android Beta 1Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/891Introduction requests/responses never get ACKed2017-12-18T07:40:22ZTorsten GroteIntroduction requests/responses never get ACKedIt looks like that in private conversations all messages except actual private messages, never get ACKed. There is only ever one checkbox for forum/blog and introduction messages even if the message has been delivered on the other end. L...It looks like that in private conversations all messages except actual private messages, never get ACKed. There is only ever one checkbox for forum/blog and introduction messages even if the message has been delivered on the other end. Leaving and re-entering the conversation doesn't help.
```
01-03 16:36:03.864 I/DuplexOutgoingSession: Generated ack: true
01-03 16:36:03.864 I/DuplexOutgoingSession: Sent ack
01-03 16:36:03.914 I/DuplexOutgoingSession: Generated ack: false
01-03 16:36:03.964 I/DuplexOutgoingSession: Generated ack: false
01-03 16:36:04.024 I/DuplexOutgoingSession: Generated ack: false
01-03 16:36:04.024 I/DuplexOutgoingSession: Generated ack: false
01-03 16:36:04.404 I/DuplexOutgoingSession: Generated ack: false
01-03 16:36:04.444 I/DuplexOutgoingSession: Generated ack: false
01-03 16:36:04.504 I/DuplexOutgoingSession: Generated ack: false
01-03 16:36:04.504 I/DuplexOutgoingSession: Generated ack: false
01-03 16:36:04.504 I/DuplexOutgoingSession: Generated ack: false
01-03 16:36:04.504 I/DuplexOutgoingSession: Generated ack: false
01-03 16:36:04.504 I/DuplexOutgoingSession: Generated ack: false
01-03 16:36:04.504 I/DuplexOutgoingSession: Generated ack: false
01-03 16:36:04.514 I/DuplexOutgoingSession: Generated ack: false
01-03 16:36:04.514 I/DuplexOutgoingSession: Generated ack: false
01-03 16:36:04.514 I/DuplexOutgoingSession: Generated ack: false
01-03 16:36:04.514 I/DuplexOutgoingSession: Generated ack: false
01-03 16:36:04.964 I/ConversationActivity: Messages sent
01-03 16:36:04.964 I/DuplexOutgoingSession: Generated batch: true
01-03 16:36:04.984 I/DuplexOutgoingSession: Sent batch
01-03 16:36:05.454 I/DuplexOutgoingSession: Generated batch: false
01-03 16:36:05.994 I/ConversationActivity: Messages acked
```Milestone GTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/890Introduction protocol fails for one introducee2017-12-15T13:05:13ZTorsten GroteIntroduction protocol fails for one introduceeLooks like we better rewrite the introduction client: Tried an introduction, both introducees accepted, contact was added for one, but not the other.
I could reproduce this by triggering an abort with #893. When the first response ca...Looks like we better rewrite the introduction client: Tried an introduction, both introducees accepted, contact was added for one, but not the other.
I could reproduce this by triggering an abort with #893. When the first response came in already, the second introduce accepts and sends the ACK directly. Then the introduce accepts taps ACCEPT again which aborts the session, so the contact will not be added. However, the first introducee already received response and ACK and added the contact unilaterally.
What is worse, when aborting the second introducee fail deleting the inactive contact which prevents that contact from ever being added in the future. Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/889Wrong item is selected in nav drawer after touching notification2017-12-18T07:40:22ZakwizgranWrong item is selected in nav drawer after touching notificationSteps to reproduce:
* Select 'contacts' from the nav drawer
* A contact writes a blog post
* Touch the notification, which opens the combined blog feed
* Open the nav drawer - 'contacts' is selectedSteps to reproduce:
* Select 'contacts' from the nav drawer
* A contact writes a blog post
* Touch the notification, which opens the combined blog feed
* Open the nav drawer - 'contacts' is selectedMilestone FJulian DehmJulian Dehmhttps://code.briarproject.org/briar/briar/-/issues/888Use consistent language for forum posts2018-12-19T12:25:32ZakwizgranUse consistent language for forum postsPosts should be called posts in the UI, not entries or items.Posts should be called posts in the UI, not entries or items.https://code.briarproject.org/briar/briar/-/issues/885Lan transport properties can exceed the maximum length.2017-12-18T07:40:22ZJulian DehmLan transport properties can exceed the maximum length.The ipPort field used in the lan plugin contains a list of recent IP:port pairs which can hold up to 5 IPs. Each entry is about 11-21 chars long and therefore the overall size can exceed the `MAX_PROPERTY_LENGTH` of 100 (e.g. 21 * 5 =...The ipPort field used in the lan plugin contains a list of recent IP:port pairs which can hold up to 5 IPs. Each entry is about 11-21 chars long and therefore the overall size can exceed the `MAX_PROPERTY_LENGTH` of 100 (e.g. 21 * 5 = 105). Once the limit is reached contact exchanges always fail:
`12-29 15:00:51.233 3748-5490/org.briarproject.briar W/ContactExchangeTaskImpl: org.briarproject.bramble.api.FormatException
org.briarproject.bramble.api.FormatException at org.briarproject.bramble.data.BdfReaderImpl.readString(BdfReaderImpl.java:257) at
org.briarproject.bramble.contact.ContactExchangeTaskImpl.receiveTransportProperties(ContactExchangeTaskImpl.java:292) at
org.briarproject.bramble.contact.ContactExchangeTaskImpl.run(ContactExchangeTaskImpl.java:174)`Milestone GJulian DehmJulian Dehmhttps://code.briarproject.org/briar/briar/-/issues/884ConversationItems sometimes not displayed or loaded properly2018-11-20T17:35:26ZJulian DehmConversationItems sometimes not displayed or loaded properlyWhen opening a conversation sometimes incoming messages are not displayed properly.
The size of the "box" holding the message changes randomly, sometimes it's too small (cutting most or even all of it's content), sometimes it's too b...When opening a conversation sometimes incoming messages are not displayed properly.
The size of the "box" holding the message changes randomly, sometimes it's too small (cutting most or even all of it's content), sometimes it's too big. The same message was displayed with different wrong sizes.
Examples:
1. The frame is too big (there is **no** newline or anything - I had this one also with the complete content cut)
<img src="https://code.briarproject.org/goapunk/briar/raw/fileStorage/screens/884/conversationItem1.png" width="15%" height="15%" >
2. Part of the message cut because the frame is too small
<img src="https://code.briarproject.org/goapunk/briar/raw/fileStorage/screens/884/conversationItem2.png" width="15%" height="15%" >
3. Part of the messages cut
<img src="https://code.briarproject.org/goapunk/briar/raw/fileStorage/screens/884/conversationItem3a.png" width="15%" height="15%" >
4. Messages from 3 shown correctly
<img src="https://code.briarproject.org/goapunk/briar/raw/fileStorage/screens/884/conversationItem3b.png" width="15%" height="15%" >
(I removed everything else from the images out of privacy reasons)
If you scroll the incorrect item out of view and back in it's being displayed correctly.
Steps to reproduce:
1. Enter a conversation
2. Lock and unlock screen repeatedly until you find a bugged incoming message.Milestone GJulian DehmJulian Dehmhttps://code.briarproject.org/briar/briar/-/issues/883AudioManager memory leak2017-12-18T07:40:22ZakwizgranAudioManager memory leak@goapunk reported a memory leak on the Nexus S caused by the AudioManager. We don't use the AudioManager directly, but ViewRootImpl uses it to play click sounds, and the AudioManager gets a reference to the view's context. It seems that ...@goapunk reported a memory leak on the Nexus S caused by the AudioManager. We don't use the AudioManager directly, but ViewRootImpl uses it to play click sounds, and the AudioManager gets a reference to the view's context. It seems that if the AudioManager isn't properly released, the context is leaked.
This has been fixed in AOSP by changing the AudioManager to keep a reference to the application context:
https://android-review.googlesource.com/#/c/140481/
A workaround is available for older versions that uses the application context to retrieve the AudioManager:
https://gist.github.com/jankovd/891d96f476f7a9ce24e2
We should be able to incorporate the workaround into BaseActivity.