As #127 is a little overloaded and goes beyond the technical, I thought to open up this issue to gather implementation details and coordinate efforts for this.

Support for WebSockets is already present on the server, so the idea is to use WebSockets on Android as well (for now instead of a possible more suited protocol like MQTT)

@geileszeuch mentioned a guide on how to use websockets in native apps: http://www.elabs.se/blog/66-using-websockets-in-native-ios-and-android-apps

However I don't think this would be a good guide as it doesn't talk about Wake/Sleep and connection loss. This article list several issues one has to deal with in a mobile enviroment: http://dalelane.co.uk/blog/?p=1599 I believe the approach mentioned here http://stackoverflow.com/a/16602970 to be reasonable, if I find the time I will give it a try.

I guess for developing this one has to run an own server, as WS is disabled per default.

So please, if you have a question, concern or are already working on this: comment!

The colored messages are supposed to convey to the user the difference between push messages and SMS.

But the green color has confused myself, @sagischwarz, @phenx-de and literally everybody I have told to install the app.

@phenx-de and myself have had a rather extensive discussion about the whole shebang in #908.

What we came up with:

• Use orange instead of green
  • Green is widely used to indicate security aka encryption (green traffic light -> you're safe / good to go) and people are used very to it.
  • Green is already used to indicate encryption / TS users in the contact list
  • It also collides with several ideas in #741 and #910 to indicate trust
  • Orange is the only color left in the Android color scheme, apart from purple: https://developer.android.com/design/style/color.html
  • It doesn't have such a direct association as green and red have
• Use toned down colors to indicate the most likely transport for messages that aren't sent yet (#796)
  • Provides information about the most likely transport
  • Indicates that the message hasn't been send yet
• We should use color strips on a light grey message body. Either on the speakers' side or on top of the messages
  • A whole window of completely colored messages looks very playful/cartoonish
  • It improves the contrast of the gray message-delivered text and icons below the message, making it easier to read
  • Scale down the importance of the transport information to a reasonable level
• Color both the messages of sender and receiver
  • While roaming and in some countries people have to pay (a lot) for incoming texts, so knowing if it's an SMS or not is important.
  • The current implementation is inconsistent from a UX perspective.

This is what @phenx-de came up with:

Blue message sides for data and orange message sides for SMS: ____

Those are two of my own mockup sets, one with white and one with grey backgrounds. The first one doesn't have the nice new send icons because I couldn't be bothered to put them in after I made the mockups.

Colorset 1: Blue message headers for data, grey background:

Colorset 1: Orange message headers for SMS, grey background:

Colorset 2: Blue message headers for data, white background:

Colorset 2: Orange message headers for SMS, white background, encryption:

Colorset 2: Orange message headers for SMS, white background, no encryption:

Please tell us what you think ;-)

I did a quick count for several different preferences.

If I misunderstood anybody, just tell me and I'll change your vote. If you have an opinion to one of those topics and aren't listed, just answer in the thread.

The first two are about the shape of the messages only, the colors are to be discussed apart from the way we use them.

• New style messages with colored bands (colors to be discussed) on top or on the side: @lindworm, @phenx-de, @noschinl, @Anaron, @monreal, @tinloaf @maulwuff
• Old style messages but with toned down colors: @virtualritz, @0xACE, @L3st3r
• Message color should indicate encryption @virtualritz, @lindworm, @mcginty
• Message color should indicate transport method @Anaron, @Cimbali, @0xACE, @L3st3r, @backspace
• Colors should stay the same (blue and green) @Anaron, @monreal, @sagischwarz, @0xACE, @L3st3r
• Colors should change @lindworm, @phenx-de, @maulwuff

Everybody seems to like the toned down colors for sending, so at least we have one thing in common ;-)

When messaging a friend of mine via push, most messages are delayed a few hours. Background data is enabled. Sometimes messages are even not delivered at all or arrive in different order than sent. This also happens with messages other people send him, although I can exchange messages with these people without problems (delivered within a few seconds). He runs a Nexus 5 with the latest stock Google Android and is perfectly reachable via Hangouts the whole time.

Any idea how to debug this?

I was about to suggest this before reading the infamous issue 53. It is sad to see that FDroid and WhisperSystems could not work together, I truly enjoy both projects. Needless to say a google alternative is required - google more and more frequently involves itself in privacy violations. I am opening this ticket in hopes that an alternative of some sort is made.

Possibilities:

1. WhisperSystems creates it's own official FDroid repository, as did GuardianProject: https://guardianproject.info/2012/03/15/our-new-f-droid-app-repository/

2. WhisperSystems provides an APK somewhere out there for people to download with simple instructions on how to verify it's not been tampered with.

In the event this is not done users not wanting Google will have to compile it from source, which although can be done, is a major inconvenience especially to newbies. Just for reference, there seems to be a large interest in migrating away from google. e,g, the NoGAPPS project: http://forum.xda-developers.com/showthread.php?s=a7bf27eb98e3bcefb7e58fb46d09710b&t=1715375

I hope you all come up with a resolution. Thanks and keep up the great work! :)

Bug description

Cannot receive MMS from non signal users at all

Steps to reproduce

• Have non-signal user send MMS
• fails to download, retrying also fails

Attempts to fix

• everything in the troubleshooting guide https://support.signal.org/hc/en-us/articles/360007320211-MMS-Troubleshooting

Actual result: Message just says mms fails to download, click to retry Expected result: See the mms

Device info

Device: OnePlus 6T Android version: 9.0.0 Signal version: 4.32.8 Carrier: Verizon

Link to debug log

https://debuglogs.org/c4b1cd7ad755c63f96d26c173b5324b5d7125dedf51032e09e0e1715e0f52280

• [ x ] I have searched open and closed issues for duplicates
• [ x ] I am submitting a bug report for existing functionality that does not work as intended
• [ x ] I have read https://github.com/signalapp/Signal-Android/wiki/Submitting-useful-bug-reports
• [ x ] This isn't a feature request or a discussion topic

Bug description

If I have a long Chat with someone, probably multiple thousand Messages and Media in History, then the Chat gets REALLY slow. We talking about 40-50 sec for one Message to get send and it only gets slower. If you send multiple Messages after the first one, it can take up to multiple Minutes till they get send. Receiving Messages takes ~10-15 sec. Short Chats dont seem to be affected. Its the most brutal if the other Person is writing/answering at the same time as your Message sends. Signal gets really laggy, the phone gets hot and slow, till anything is sent. Not related to this, but maybe Interesting: Backups take around 3 hours to finish. Backupfile is around 7GB in Size.

Steps to reproduce

• Open Signal
• Go to Chat with long History (opening and closing that Chat is also really slow)
• Send one or Multiple Messages

Actual result: Messages take sometimes Minutes to Send. Expected result: Messages should be send almost instant, like in a fresh Chat.

Device info

Device: Galaxy S5 klte / SM-G900F and One Plus 6T Android version: 9.0 LineageOS 16 / Stock Rom Signal version: 4.68.8, persists in 4.69.6, persists in 4.70.3, persists in 4.70.5, persists in 5.8.10, solved in 5.20.4

Link to debug log

https://debuglogs.org/fff230b9173168bd607d678f019b51b7dc38c12ced3661f169c51e1968b147d8

EDIT: New Log, while sending and receiving Messages at the same time:

https://debuglogs.org/7eead199b7af5be480058d38b128f766cf4536beb0be0b4a24aa2ad962aada09

EDIT2: Now (28th Aug) the Problem is so bad, that the App gets nearly unusable. Messages take around 90 Seconds to get send. Only in that one, long Chat. As long as one Message in that Chat is sending, anything else is almost not responding and the App locks up sometimes. Even receiving Messages in that Chat is so slow, that sometimes the Person thinks i lost connection or turned off my Phone. Isnt there anything that can be done, without loosing all the History ? I used Whatsapp for some time before and had Chats with around 30-40k Messages and NEVER had any Problems like that, why is it, that Signal has such poor Performance ?

EDIT3 (4th Nov): Time to send one Message went up to ~130 secs. Pics dont always send. Just the Text under them. App is barely usable whenever i access a long Chat.

EDIT4 (Feb 2021): Changed Phone from a Galaxy S5 with Snapdragon 801 and 2GB RAM, to a One Plus 6T with Snapdragon 845 and 8GB RAM. Problem still persists, but is better thanks to more Raw Power. Chat still gets slower every Day, even tho not as noticeable anymore, probably also thanks to more power.

EDIT5 (18th Aug 2021): Problem seems resolved. Performance in a long Chat is drastically Improved with Version 5.20.4. A Message takes around 2-3 seconds now, which i consider "instant". Good Job Guys and Girls!

Probably Related #9881

• [x] I have searched open and closed issues for duplicates
• [x] I am submitting a bug report for existing functionality that does not work as intended
• [x] I have read https://github.com/signalapp/Signal-Android/wiki/Submitting-useful-bug-reports
• [x] This isn't a feature request or a discussion topic

Bug description

Unable to restore signal backup on new phone. Similar to #7637 but I don't have xposed installed. Signal stable closing without error after reading 11401 messages. Signal beta giving error message about incorrect passphrase after reading 11401 messages. I am certain the passphrase and the backup are correct as they are working fine using https://github.com/xeals/signal-back

Steps to reproduce

• copy signal backup to new phone
• open signal
• enter passphrase
• wait for messages to import

Actual result:

• Signal just closing (stable)
• Error message stating the passphrase is incorrect (beta).

Expected result: Backup is successfully restored.

Screenshots

beta error (in German due to phone language)

Device info

Device: Nokia 7 Plus Dual-Sim Android version: 9 Kernel version: 4.4.146-perf+ Signal version: Beta: 4.30.2 also tested on stable: 4.29.7

Link to debug log

Working on grabbing a logcat log but struggling with it. Will add through edit. Logcat for version 4.29.7:

--------- beginning of crash
11-08 22:32:10.330  4472  6987 E AndroidRuntime: FATAL EXCEPTION: AsyncTask #3
11-08 22:32:10.330  4472  6987 E AndroidRuntime: Process: org.thoughtcrime.securesms, PID: 4472
11-08 22:32:10.330  4472  6987 E AndroidRuntime: java.lang.RuntimeException: An error occurred while executing doInBackground()
11-08 22:32:10.330  4472  6987 E AndroidRuntime: 	at android.os.AsyncTask$3.done(AsyncTask.java:354)
11-08 22:32:10.330  4472  6987 E AndroidRuntime: 	at java.util.concurrent.FutureTask.finishCompletion(FutureTask.java:383)
11-08 22:32:10.330  4472  6987 E AndroidRuntime: 	at java.util.concurrent.FutureTask.setException(FutureTask.java:252)
11-08 22:32:10.330  4472  6987 E AndroidRuntime: 	at java.util.concurrent.FutureTask.run(FutureTask.java:271)
11-08 22:32:10.330  4472  6987 E AndroidRuntime: 	at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:245)
11-08 22:32:10.330  4472  6987 E AndroidRuntime: 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
11-08 22:32:10.330  4472  6987 E AndroidRuntime: 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
11-08 22:32:10.330  4472  6987 E AndroidRuntime: 	at java.lang.Thread.run(Thread.java:764)
11-08 22:32:10.330  4472  6987 E AndroidRuntime: Caused by: java.lang.NegativeArraySizeException: -1884239691
11-08 22:32:10.330  4472  6987 E AndroidRuntime: 	at org.thoughtcrime.securesms.backup.FullBackupImporter$BackupRecordInputStream.readFrame(FullBackupImporter.java:310)
11-08 22:32:10.330  4472  6987 E AndroidRuntime: 	at org.thoughtcrime.securesms.backup.FullBackupImporter$BackupRecordInputStream.readFrame(FullBackupImporter.java:252)
11-08 22:32:10.330  4472  6987 E AndroidRuntime: 	at org.thoughtcrime.securesms.backup.FullBackupImporter.importFile(FullBackupImporter.java:81)
11-08 22:32:10.330  4472  6987 E AndroidRuntime: 	at org.thoughtcrime.securesms.RegistrationActivity$2.doInBackground(RegistrationActivity.java:394)
11-08 22:32:10.330  4472  6987 E AndroidRuntime: 	at org.thoughtcrime.securesms.RegistrationActivity$2.doInBackground(RegistrationActivity.java:386)
11-08 22:32:10.330  4472  6987 E AndroidRuntime: 	at android.os.AsyncTask$2.call(AsyncTask.java:333)
11-08 22:32:10.330  4472  6987 E AndroidRuntime: 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
11-08 22:32:10.330  4472  6987 E AndroidRuntime: 	... 4 more

logcat for version 4.30.2:

11-10 13:15:20.687 27588 31822 W RegistrationActivity: null
11-10 13:15:20.687 27588 31822 W RegistrationActivity: java.io.IOException: Bad MAC
11-10 13:15:20.687 27588 31822 W RegistrationActivity: 	at org.thoughtcrime.securesms.backup.FullBackupImporter$BackupRecordInputStream.readAttachmentTo(FullBackupImporter.java:298)
11-10 13:15:20.687 27588 31822 W RegistrationActivity: 	at org.thoughtcrime.securesms.backup.FullBackupImporter.processAttachment(FullBackupImporter.java:140)
11-10 13:15:20.687 27588 31822 W RegistrationActivity: 	at org.thoughtcrime.securesms.backup.FullBackupImporter.importFile(FullBackupImporter.java:87)
11-10 13:15:20.687 27588 31822 W RegistrationActivity: 	at org.thoughtcrime.securesms.RegistrationActivity$2.doInBackground(RegistrationActivity.java:396)
11-10 13:15:20.687 27588 31822 W RegistrationActivity: 	at org.thoughtcrime.securesms.RegistrationActivity$2.doInBackground(RegistrationActivity.java:388)
11-10 13:15:20.687 27588 31822 W RegistrationActivity: 	at android.os.AsyncTask$2.call(AsyncTask.java:333)
11-10 13:15:20.687 27588 31822 W RegistrationActivity: 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
11-10 13:15:20.687 27588 31822 W RegistrationActivity: 	at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:245)
11-10 13:15:20.687 27588 31822 W RegistrationActivity: 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
11-10 13:15:20.687 27588 31822 W RegistrationActivity: 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
11-10 13:15:20.687 27588 31822 W RegistrationActivity: 	at java.lang.Thread.run(Thread.java:764)

• [x] I have searched open and closed issues for duplicates
• [x] I am submitting a bug report for existing functionality that does not work as intended
• [x] I have read https://github.com/signalapp/Signal-Android/wiki/Submitting-useful-bug-reports
• [x] This isn't a feature request or a discussion topic

Bug description

Since a few days for me, my wife, a bunch of friends and family members on different mobile networks in Italy, Signal stopped working. As soon as the device is connected to WiFi, messages gets routed, otherwise there's no communication in or out.

A friend even tried to uninstall and reinstall signal and it didn't let him re-register, saying "no network".

This happens on a range of devices with different vendors (Samsung, Xiaomi, Huawei) Android versions (8, 9, 10 and 11) and different data and WiFi providers. The only common thing is the location (Italy) and the app version (5.27.13).

Steps to reproduce

• Send a message on Mobile Data

Actual result: Spinning icon untill connected to WiFi. No messages delivered in or out. Expected result: Messages should be delivered.

Device info

Device: Samsung, Xiaomi, Huawei (various) Android version: 8, 9, 10 and 11 Signal version: 5.27.13

Link to debug log

I attach one of the devices debug log, the errors are the same across all devices (I think the SSL handshake fails).

https://debuglogs.org/b8d5664acd597b3447f7c36a53fd91161b7420c611a149c8b2a86090220c85fb

• [x] I have searched open and closed issues for duplicates
• [x] I am submitting a bug report for existing functionality that does not work as intended
• [x] I have read https://github.com/signalapp/Signal-Android/wiki/Submitting-useful-bug-reports
• [x] This isn't a feature request or a discussion topic

Bug description

When trying to take a picture to send within Signal using a Huawei Mate 10 Pro or a Huawei P20, a black screen is displayed with the shutter button and the square in the bottom left of existing pictures, but no camera image. On pressing back to return to the chat and trying again, Signal stops being responsive.

Steps to reproduce

• Open a chat
• Try to take a photo to send

Actual result: Black screen with camera UI but no image Expected result: Camera UI with a moving image of what the camera sees

Device info

Device: Huawei Mate 10 Pro, Huawei P20 Android version: 9.1 Signal version: 4.49.13

Link to debug log

https://debuglogs.org/b6f9596c588335d29eccc0851848d75b31ad9be16ee8a06e75de96286985e662

I have:

• [x] searched open and closed issues for duplicates
• [x] read https://github.com/WhisperSystems/Signal-Android/wiki/Submitting-useful-bug-reports

Bug description

When doing an audio call on Speaker mode in the new Voice/Video call beta enabled, you can hear your own voice clearly reflected through the microphone. This causes a rather high level of annoyance as you hear your own voice, with a double round-trip time in between, making it a very sad communication companion that constantly interrupts you when you speak.

Steps to reproduce

• Enable voice calling beta
• Put both phones on speaker mode
• Pull up volume a bit
• Speak slowly and hear your own voice with a delay, routed through the aether.

Actual result: Annoyingly noise of your own voice

Expected result: Effective echo cancellation on the remote side that cancels out the noises from the speaker against the microphone.

Screenshots

Not applicable

Device info

Device 1: Fairphone 2 Device 2 Nexus 5x Android version: 7.1.1 and the current fairphone (5/6 something?) Signal version: Pass.

Link to debug log

Not applicable.

• [x] I have searched open and closed issues for duplicates
• [x] I am submitting a bug report for existing functionality that does not work as intended
• [x] I have read https://github.com/signalapp/Signal-Android/wiki/Submitting-useful-bug-reports
• [x] This isn't a feature request or a discussion topic

Bug description

My parents are having an issue where they are not receiving MMS messages. I was having this issue on Signal Beta on MY OnePlus 6t, so I uninstalled and reinstalled only to be greeted with this issue #9136 which is not a resolved or duplicate issue (@greyson-signal )

Steps to reproduce

• be in a group chat
• get a next in that group chat or
• be in a text thread
• get an mms message (ie: an image or audio file) in that text thread

Actual result: "Error downloading MMS message, tap to retry", click retry, it spins for a second and then "Error downloading MMS message, tap to retry" again ad infinitum Expected result: the MMS message downloads

Device info

Device: OnePlus 6t & Samsung Galaxy S10e Android version: Android 9 Signal version: 4.49.16 Carrier: AT&T

Link to debug log

This is the link for the debug log for my mom's S10e. That's all I could get at the time of writing this issue https://debuglogs.org/868b7a7d545287bcf96691fbeb753cf89e44384b1e4fe5b271cba972471e67e1

• [x ] I have searched open and closed issues for duplicates
• [x ] I am submitting a bug report for existing functionality that does not work as intended
• [ x] I have read https://github.com/signalapp/Signal-Android/wiki/Submitting-useful-bug-reports
• [ x] This isn't a feature request or a discussion topic

Bug description

Describe here the issue that you are experiencing. The buttons at bottom of screen are hidden/cut off when adding picture to story (see screenshot)

Steps to reproduce

• goto storys
• touch camera button
• touch pictures/gallery button (bottom right)
• choose a picture and touch button ">" (bottom right)
• that reproduce the bug

Actual result: Describe here what happens after you run the steps above (i.e. the buggy behaviour) the screen schows the bicture and cut off buttons Expected result: Describe here what should happen after you run the steps above (i.e. what would be the correct behaviour) show full buttons

Screenshots

Device info

Device: Samsung Galaxy A51 Android version: 13 Signal version: 6.5.6

Link to debug log

https://debuglogs.org/android/6.5.6/ce28497bef8c1207f89f42f71e92f18b716619a4754d60711d6abb155c6c3c67

• [ x ] I have searched open and closed issues for duplicates
• [ x ] I am submitting a bug report for existing functionality that does not work as intended
• [ x ] I have read https://github.com/signalapp/Signal-Android/wiki/Submitting-useful-bug-reports
• [ x ] This isn't a feature request or a discussion topic

Bug description

During the verification of the safety number, the feedback provided by the app is displayed by either a red X or a green hook which is displayed for about 1-2 seconds before it disappears. Most of the screen stays the same and it is not at all clear to a user if the verification was successful or not after the response x or hook has disappeared. The app shows a small text "UserX is verified" but it displays the unverified message in the same text as well, which is in both cases displayed in the same color and size as the rest of the text on the screen, making it very easy to overlook.

To emphasize:

When verifying the safety number, the user may be holding both phones and trying to read the QR code one phone with the camera of the other. With the attention switching between the two phones, possibly holding them at different angles as well to get the camera to capture the code, it is very easy to miss the 2 second verification feedback.

I have gone through the safety number verification process several times in the past days and despite using this process several times a year and being a signal user for years, I misinterpreted the feedback message as well when it failed and only noticed the mistake by chance. The other users who I showed the verification process to all failed to understand that the process failed as well.

Part of the problem is how the process usually works:

The user tries to capture the QR code and when it is read, the reading phone provides the 2 second feedback which is normally "successful" which makes the user hit the mark as verified button. Even as someone who does this several times a year, I did not remember or pay attention to what color the feedback needs to be and while holding two phones, I hit the verified button as a response to the verification feedback (red X), because why read the feedback message again? After all its always been successful when there is a feedback and never failed before. Unfortunately, one of the phones was offline and the safety number of the other contact had changed, which is why it failed in this example.

This is the first time a safety number verification failed for me and it was not at all clear to that it did. Only when I verified the number again on the second phone did I notice the 2 second failed message by chance, checked the second phone again and noticed that I had just marked the safety code as verified even though it failed to verify.

For the average user who rarely uses this feature at all, this is even more confusing. To the person I was showing the verification process to, it was a very bad example as well and even more confusing.

Steps to reproduce

• Go through the safety number verification process after the safety number has changed while one of the phones was offline
• The verification will fail but the feedback message will disappear quickly and the verification screen will show no clear indicator of the result

Actual result: Describe here what happens after you run the steps above (i.e. the buggy behavior) The verification will fail but the safety number screen will mostly look the same with the difference of the verification message, which is easy to overlook since it is only 1% of the screen with lots of text around that looks the same.

Expected result: Describe here what should happen after you run the steps above (i.e. what would be the correct behavior)

A failed verification should give a very clear user feedback, like displaying the full screen bright red and sounding a clear error message alert. After a failed safety number attempt, the feed back should very clearly display an error message instead of looking the same as always.

Screenshots

left is unverified, right is verified. (Please note that this is an example image and I had to manually edit the verified message since I do not have the affected phone with me to make a screenshot.)

As shown in the example (mock) screenshot, the difference between verified and unverified is easy to miss.

Device info

Device: Pixel 6a Android version: 13 (latest version as of yesterday, don't have the phone on me to check the full version) Signal version: 6.6.3

This was tested with two phones, one of which was an IPhone

Device: IPhone 13 IOS version: 16.2 Signal version: 6.6

Link to debug log

The same issue exists on IOS https://github.com/signalapp/Signal-iOS/issues/5512

• [x] I have searched open and closed issues for duplicates
• [x] I am submitting a bug report for existing functionality that does not work as intended
• [x] I have read https://github.com/signalapp/Signal-Android/wiki/Submitting-useful-bug-reports
• [x] This isn't a feature request or a discussion topic

Bug description

Animated GIFs seem to crash the ShareViewModel.

12-26 12:33:22.546  3668  4017 I MediaProvider: Open with lower FS for /storage/emulated/0/animated.gif. Uid: 10163
12-26 12:33:22.568 23243 23243 W ShareViewModel: Could not load share data.
12-26 12:33:22.568 23243 23243 W ShareViewModel: java.lang.IllegalArgumentException: You must call this method on a background thread
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at com.bumptech.glide.util.Util.assertBackgroundThread(Util.java:179)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at com.bumptech.glide.request.RequestFutureTarget.doGet(RequestFutureTarget.java:192)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at com.bumptech.glide.request.RequestFutureTarget.get(RequestFutureTarget.java:130)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at org.thoughtcrime.securesms.util.MediaUtil.getDimensions(MediaUtil.java:176)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at org.thoughtcrime.securesms.sharing.v2.ShareRepository.resolve(ShareRepository.kt:98)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at org.thoughtcrime.securesms.sharing.v2.ShareRepository.resolve$lambda$0(ShareRepository.kt:34)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at org.thoughtcrime.securesms.sharing.v2.ShareRepository.$r8$lambda$59FUd3Wrt32CeFEPd92_5j51EHM(Unknown Source:0)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at org.thoughtcrime.securesms.sharing.v2.ShareRepository$$ExternalSyntheticLambda0.call(Unknown Source:4)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at io.reactivex.rxjava3.internal.operators.single.SingleFromCallable.subscribeActual(SingleFromCallable.java:43)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at io.reactivex.rxjava3.core.Single.subscribe(Single.java:4813)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at io.reactivex.rxjava3.core.Single.subscribe(Single.java:4799)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at io.reactivex.rxjava3.kotlin.SubscribersKt.subscribeBy(subscribers.kt:61)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at org.thoughtcrime.securesms.sharing.v2.ShareViewModel.<init>(ShareViewModel.kt:33)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at org.thoughtcrime.securesms.sharing.v2.ShareViewModel$Factory.create(ShareViewModel.kt:88)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at androidx.lifecycle.ViewModelProvider$Factory$-CC.$default$create(ViewModelProvider.kt:83)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at org.thoughtcrime.securesms.sharing.v2.ShareViewModel$Factory.create(Unknown Source:0)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at androidx.lifecycle.ViewModelProvider.get(ViewModelProvider.kt:187)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at androidx.lifecycle.ViewModelProvider.get(ViewModelProvider.kt:153)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at androidx.lifecycle.ViewModelLazy.getValue(ViewModelLazy.kt:53)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at androidx.lifecycle.ViewModelLazy.getValue(ViewModelLazy.kt:35)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at org.thoughtcrime.securesms.sharing.v2.ShareActivity.getViewModel(ShareActivity.kt:49)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at org.thoughtcrime.securesms.sharing.v2.ShareActivity.onCreate(ShareActivity.kt:86)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at org.thoughtcrime.securesms.PassphraseRequiredActivity.onCreate(PassphraseRequiredActivity.java:77)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at android.app.Activity.performCreate(Activity.java:8352)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at android.app.Activity.performCreate(Activity.java:8331)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1422)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3627)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3783)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:101)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:135)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:95)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2308)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at android.os.Handler.dispatchMessage(Handler.java:106)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at android.os.Looper.loopOnce(Looper.java:201)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at android.os.Looper.loop(Looper.java:288)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at android.app.ActivityThread.main(ActivityThread.java:7878)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at java.lang.reflect.Method.invoke(Native Method)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at com.android.internal.os.ExecInit.main(ExecInit.java:49)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at com.android.internal.os.RuntimeInit.nativeFinishInit(Native Method)
12-26 12:33:22.568 23243 23243 W ShareViewModel: 	at com.android.internal.os.RuntimeInit.main(RuntimeInit.java:355)

Steps to reproduce

• Open system gallery
• Select animated GIF
• Try to share with Signal

It's not perfectly reproducible for me. Generally this happens when selecting multiple items including an animated GIF.

Actual result: Signal receives the GIF and shares it. Expected result: Signal opens and then immediately closes again making it impossible to share the GIF this way.

Screenshots

Device info

Device: Google Pixel 4a Android version: 13 (TQ1A.221205.011.2022122000) Signal version: 6.6.3

Link to debug log

• [x] I have searched open and closed issues for duplicates
• [x] I am submitting a bug report for existing functionality that does not work as intended
• [x] I have read https://github.com/signalapp/Signal-Android/wiki/Submitting-useful-bug-reports
• [x] This isn't a feature request or a discussion topic

Bug description

When sharing multiple items from the gallery, the entire batch often fails at an unknown point.

12-26 11:57:40.267 23243 23302 W AttachmentTable: null
12-26 11:57:40.267 23243 23302 W AttachmentTable: java.io.FileNotFoundException: /data/user/0/org.thoughtcrime.securesms/app_parts/part2978291222329552006.mms: open failed: ENOENT (No such file or directory)
12-26 11:57:40.267 23243 23302 W AttachmentTable: 	at libcore.io.IoBridge.open(IoBridge.java:574)
12-26 11:57:40.267 23243 23302 W AttachmentTable: 	at java.io.FileInputStream.<init>(FileInputStream.java:160)
12-26 11:57:40.267 23243 23302 W AttachmentTable: 	at org.thoughtcrime.securesms.crypto.ModernDecryptingPartInputStream.createFor(ModernDecryptingPartInputStream.java:28)
12-26 11:57:40.267 23243 23302 W AttachmentTable: 	at org.thoughtcrime.securesms.database.AttachmentTable.getDataStream(AttachmentTable.java:1060)
12-26 11:57:40.267 23243 23302 W AttachmentTable: 	at org.thoughtcrime.securesms.database.AttachmentTable.getAttachmentStream(AttachmentTable.java:212)
12-26 11:57:40.267 23243 23302 W AttachmentTable: 	at org.thoughtcrime.securesms.mms.PartAuthority.getAttachmentStream(PartAuthority.java:74)
12-26 11:57:40.267 23243 23302 W AttachmentTable: 	at org.thoughtcrime.securesms.jobs.AttachmentUploadJob.getAttachmentFor(AttachmentUploadJob.java:192)
12-26 11:57:40.267 23243 23302 W AttachmentTable: 	at org.thoughtcrime.securesms.jobs.AttachmentUploadJob.onRun(AttachmentUploadJob.java:145)
12-26 11:57:40.267 23243 23302 W AttachmentTable: 	at org.thoughtcrime.securesms.jobs.BaseJob.run(BaseJob.java:32)
12-26 11:57:40.267 23243 23302 W AttachmentTable: 	at org.thoughtcrime.securesms.jobmanager.JobRunner.run(JobRunner.java:86)
12-26 11:57:40.267 23243 23302 W AttachmentTable: 	at org.thoughtcrime.securesms.jobmanager.JobRunner.run(JobRunner.java:49)
12-26 11:57:40.267 23243 23302 W AttachmentTable: Caused by: android.system.ErrnoException: open failed: ENOENT (No such file or directory)
12-26 11:57:40.267 23243 23302 W AttachmentTable: 	at libcore.io.Linux.open(Native Method)
12-26 11:57:40.267 23243 23302 W AttachmentTable: 	at libcore.io.ForwardingOs.open(ForwardingOs.java:563)
12-26 11:57:40.267 23243 23302 W AttachmentTable: 	at libcore.io.BlockGuardOs.open(BlockGuardOs.java:274)
12-26 11:57:40.267 23243 23302 W AttachmentTable: 	at libcore.io.ForwardingOs.open(ForwardingOs.java:563)
12-26 11:57:40.267 23243 23302 W AttachmentTable: 	at android.app.ActivityThread$AndroidOs.open(ActivityThread.java:7764)
12-26 11:57:40.267 23243 23302 W AttachmentTable: 	at libcore.io.IoBridge.open(IoBridge.java:560)
12-26 11:57:40.267 23243 23302 W AttachmentTable: 	... 10 more
12-26 11:57:40.268 23243 23302 W BaseJob : [JOB::b194f969-761a-4160-a4ec-dd9e36889c24][AttachmentUploadJob] Encountered a failing exception. (Time Since Submission: 866 ms, Lifespan: 86400000 ms, Run Attempt: 1/Unlimited, Queue: null)
12-26 11:57:40.268 23243 23302 W BaseJob : org.thoughtcrime.securesms.jobs.AttachmentUploadJob$InvalidAttachmentException: java.io.IOException: No stream for: AttachmentId::(12310, 1672051155940)
12-26 11:57:40.268 23243 23302 W BaseJob : 	at org.thoughtcrime.securesms.jobs.AttachmentUploadJob.getAttachmentFor(AttachmentUploadJob.java:221)
12-26 11:57:40.268 23243 23302 W BaseJob : 	at org.thoughtcrime.securesms.jobs.AttachmentUploadJob.onRun(AttachmentUploadJob.java:145)
12-26 11:57:40.268 23243 23302 W BaseJob : 	at org.thoughtcrime.securesms.jobs.BaseJob.run(BaseJob.java:32)
12-26 11:57:40.268 23243 23302 W BaseJob : 	at org.thoughtcrime.securesms.jobmanager.JobRunner.run(JobRunner.java:86)
12-26 11:57:40.268 23243 23302 W BaseJob : 	at org.thoughtcrime.securesms.jobmanager.JobRunner.run(JobRunner.java:49)
12-26 11:57:40.268 23243 23302 W BaseJob : Caused by: java.io.IOException: No stream for: AttachmentId::(12310, 1672051155940)
12-26 11:57:40.268 23243 23302 W BaseJob : 	at org.thoughtcrime.securesms.database.AttachmentTable.getAttachmentStream(AttachmentTable.java:214)
12-26 11:57:40.268 23243 23302 W BaseJob : 	at org.thoughtcrime.securesms.mms.PartAuthority.getAttachmentStream(PartAuthority.java:74)
12-26 11:57:40.268 23243 23302 W BaseJob : 	at org.thoughtcrime.securesms.jobs.AttachmentUploadJob.getAttachmentFor(AttachmentUploadJob.java:192)
12-26 11:57:40.268 23243 23302 W BaseJob : 	... 4 more
12-26 11:57:40.268 23243 23302 W BaseJob : Caused by: java.io.FileNotFoundException: /data/user/0/org.thoughtcrime.securesms/app_parts/part2978291222329552006.mms: open failed: ENOENT (No such file or directory)
12-26 11:57:40.268 23243 23302 W BaseJob : 	at libcore.io.IoBridge.open(IoBridge.java:574)
12-26 11:57:40.268 23243 23302 W BaseJob : 	at java.io.FileInputStream.<init>(FileInputStream.java:160)
12-26 11:57:40.268 23243 23302 W BaseJob : 	at org.thoughtcrime.securesms.crypto.ModernDecryptingPartInputStream.createFor(ModernDecryptingPartInputStream.java:28)
12-26 11:57:40.268 23243 23302 W BaseJob : 	at org.thoughtcrime.securesms.database.AttachmentTable.getDataStream(AttachmentTable.java:1060)
12-26 11:57:40.268 23243 23302 W BaseJob : 	at org.thoughtcrime.securesms.database.AttachmentTable.getAttachmentStream(AttachmentTable.java:212)
12-26 11:57:40.268 23243 23302 W BaseJob : 	... 6 more
12-26 11:57:40.268 23243 23302 W BaseJob : Caused by: android.system.ErrnoException: open failed: ENOENT (No such file or directory)
12-26 11:57:40.268 23243 23302 W BaseJob : 	at libcore.io.Linux.open(Native Method)
12-26 11:57:40.268 23243 23302 W BaseJob : 	at libcore.io.ForwardingOs.open(ForwardingOs.java:563)
12-26 11:57:40.268 23243 23302 W BaseJob : 	at libcore.io.BlockGuardOs.open(BlockGuardOs.java:274)
12-26 11:57:40.268 23243 23302 W BaseJob : 	at libcore.io.ForwardingOs.open(ForwardingOs.java:563)
12-26 11:57:40.268 23243 23302 W BaseJob : 	at android.app.ActivityThread$AndroidOs.open(ActivityThread.java:7764)
12-26 11:57:40.268 23243 23302 W BaseJob : 	at libcore.io.IoBridge.open(IoBridge.java:560)
12-26 11:57:40.268 23243 23302 W BaseJob : 	... 10 more

Steps to reproduce

• Press (+) next to the message field
• Select Gallery
• Select multiple items and press send

Actual result: All items are sent without problems. Expected result: "Send failed" and a red exclamation mark appears. The items are not sent.

Screenshots

Device info

Device: Google Pixel 4a Android version: 13 (TQ1A.221205.011.2022122000) Signal version: 6.6.3

Link to debug log

• [x] I have searched open and closed issues for duplicates. This is similar, but not quite
• [x] I am submitting a bug report for existing functionality that does not work as intended
• [x] I have read https://github.com/signalapp/Signal-Android/wiki/Submitting-useful-bug-reports
• [x] This isn't a feature request or a discussion topic

Bug description

Old phone and new phone can't discover eachother when attempting to transfer account. Although the transfer guide is followed.

Steps to reproduce

• Have old phone with Signal account
• get new phone, install signal
• follow steps to transfer account:
• clear out wifi direct, enable location and bluetooth, connect to same wifi network, tap continue

Actual result: Devices fail to discover eachother.

Expected result: Devices discover eachother and account transfers smoothly.

Device info

Old Device: Motorola Moto G8plus Android version: QPIS30.28-Q3-28-26-4-1-7 Signal version: 6.5.6

New Device: Samsung Galaxy S9 Android version: SQ3A.220705.004 Signal version: 6.3.6

Link to debug log

Old https://debuglogs.org/android/6.5.6/241f4e7e3d8ac5b978a144c6fcbc28861d4746c46e364866d13fdf507807b770

New https://debuglogs.org/android/6.3.6/d0695c9885035db5239f52cc4dc971475c066d35a08eea6d8485da7da75f3104

• [X] I have searched open and closed issues for duplicates
• [X] I am submitting a bug report for existing functionality that does not work as intended
• [X] I have read https://github.com/signalapp/Signal-Android/wiki/Submitting-useful-bug-reports
• [X] This isn't a feature request or a discussion topic

Bug description

8K videos cannot be displayed while cropping

Steps to reproduce

• 8K video is captured by selecting the phone camera.
• The captured video is selected from the Attachment menu.
• The video cannot be displayed. Sometimes it can display the cropping screen and view the video, and sometimes it cannot crop and display the video.

Actual result: The video cannot be displayed. Expected result: Videos must be viewable.

Screenshots

Device info

Device: Samsung Galaxy S22 Android version: 12.0.0 Signal version: 6.2.4

Link to debug log

https://debuglogs.org/android/6.2.4/6395a608e0be85dac1d39361bdf72cdbbb737db27fef2cc1f23484ea2d04f851