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

When using a headset or the built-in speaker on a voice call, the screen sometimes goes black as if the proximity sensor detected my face next to the screen. However, I am holding the phone at arm's length. Sometimes this behavior results in the screen turning on and off rapidly making it impossible to use another app while on the voice call.

Unfortunately, I am not yet able to reliably reproduce this issue on demand but it happens frequently enough that it is very annoying.

Steps to reproduce

• start a voice call in Signal
• switch to another Android app (e.g. Chrome)
• observe occasional screen blanking behavior

Actual result: Often, the screen will go blank as if the proximity sensor detected my face near the phone screen. This may be followed by the screen waking up. This may occur several times in a few seconds. Expected result: Ideally the proximity sensor would not be enabled for calls which use speakerphone or headsets as the user's face will not be near the screen in those cases. In any case, the screen should not go black when I'm not holding the phone to my face.

Screenshots

Picture a black screen... ;-)

Device info

Manufacturer : Google Model : Pixel 5a Android : 13, API 33 (9080065, TP1A.221105.002) App : Signal 6.6.3 (1185, 118502) (cb0e7ade141f)

Link to debug log

https://debuglogs.org/android/6.6.3/71dfcadda0af713bb3fb46061d3fa4ac3b1e68c93d5756cef2a33c4f614f8e68

I took a look at the log and while I'm not familiar with the normal behavior of this code, this flapping proximity lock and accelerometer orientation state looks suspicious to me: [6.6.3] [main ] 2023-01-06 21:51:25.140 PST D AccelerometerListener: orientation: horizontal [6.6.3] [main ] 2023-01-06 21:51:25.141 PST D LockManager: Orentation Update: 2 [6.6.3] [main ] 2023-01-06 21:51:25.144 PST D ProximityLock: Released proximity lock:false [6.6.3] [main ] 2023-01-06 21:51:25.144 PST D LockManager: Entered Lock State: FULL [6.6.3] [main ] 2023-01-06 21:51:25.298 PST D AccelerometerListener: orientation: vertical [6.6.3] [main ] 2023-01-06 21:51:25.299 PST D LockManager: Orentation Update: 1 [6.6.3] [main ] 2023-01-06 21:51:25.305 PST D LockManager: Entered Lock State: PROXIMITY [6.6.3] [main ] 2023-01-06 21:51:26.440 PST D AccelerometerListener: orientation: horizontal [6.6.3] [main ] 2023-01-06 21:51:26.440 PST D LockManager: Orentation Update: 2 [6.6.3] [main ] 2023-01-06 21:51:26.445 PST D ProximityLock: Released proximity lock:false [6.6.3] [main ] 2023-01-06 21:51:26.445 PST D LockManager: Entered Lock State: FULL [6.6.3] [main ] 2023-01-06 21:51:26.968 PST D AccelerometerListener: orientation: vertical [6.6.3] [main ] 2023-01-06 21:51:26.968 PST D LockManager: Orentation Update: 1 [6.6.3] [main ] 2023-01-06 21:51:26.973 PST D LockManager: Entered Lock State: PROXIMITY [6.6.3] [main ] 2023-01-06 21:51:27.552 PST D AccelerometerListener: orientation: horizontal [6.6.3] [main ] 2023-01-06 21:51:27.552 PST D LockManager: Orentation Update: 2 [6.6.3] [main ] 2023-01-06 21:51:27.559 PST D ProximityLock: Released proximity lock:false [6.6.3] [main ] 2023-01-06 21:51:27.559 PST D LockManager: Entered Lock State: FULL [6.6.3] [main ] 2023-01-06 21:51:29.380 PST D AccelerometerListener: orientation: vertical [6.6.3] [main ] 2023-01-06 21:51:29.380 PST D LockManager: Orentation Update: 1 [6.6.3] [main ] 2023-01-06 21:51:29.385 PST D LockManager: Entered Lock State: PROXIMITY [6.6.3] [main ] 2023-01-06 21:51:30.317 PST D AccelerometerListener: orientation: horizontal [6.6.3] [main ] 2023-01-06 21:51:30.317 PST D LockManager: Orentation Update: 2 [6.6.3] [main ] 2023-01-06 21:51:30.324 PST D ProximityLock: Released proximity lock:false [6.6.3] [main ] 2023-01-06 21:51:30.324 PST D LockManager: Entered Lock State: FULL [6.6.3] [main ] 2023-01-06 21:51:32.327 PST D AccelerometerListener: orientation: vertical [6.6.3] [main ] 2023-01-06 21:51:32.328 PST D LockManager: Orentation Update: 1 [6.6.3] [main ] 2023-01-06 21:51:32.331 PST D LockManager: Entered Lock State: PROXIMITY

• [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

There seems to be no way to delete an SMS group on android.

Steps to reproduce

• Create a group and add at least one SMS member.
• Search for it (since it doesn't seem to appear in the list of conversations).
• Try to delete it. Press the group and hold down.

Actual result: No menu pops up. Nothing happens. Expected result: I expected a menu option to appear that includes deleting the group.

Note, there also are no options below the members to leave the group, and there is no way to remove group members.

Device info

Device: Pixel 5a Android version: 13 Signal version: 6.6.3

…lpaperCropActivity.

Contributor checklist

• [X] I am following the Code Style Guidelines
• [X] I have tested my contribution on these devices:

• Virtual Pixel XL, Android 12

• [X] My contribution is fully baked and ready to be merged as is

Description

Replace the old SimpleProgressDialog with the new ProgressCard in WalllpaperCropActivity.java See also https://github.com/signalapp/Signal-Android/pull/10251#issuecomment-765705419

• [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 consulting the photos in landscape mode, we have the black banner at the top and bottom which reappears when we consult a new photo even if we clicked on the photo so that the black banner at the top and bottom disappears

Steps to reproduce

• Select a picture
• Put your phone in landscape mode
• the photo is displayed with the black banner at the top and bottom (the 2 red rectangles)
• Click on the photo to remove the black banner above and below
• Show next photo by swiping. The black banner at the top and bottom reappears!!!

Actual result: When looking at photos by removing the black banner at the top and bottom by clicking with your finger, they reappear when looking at the next photo. Expected result: When looking at photos by removing the banner at the top and bottom by clicking with your finger, the banners do not appear on the next photo

Screenshots

• the photo is displayed with the black banner at the top and bottom (the 2 red rectangles)
• Click on the photo to remove the black banner above and below
• Show next photo by swiping. The black banner at the top and bottom reappears!!!

Device info

Device: Samsung A51 Android version: 12 Signal version: 6.6.3

Link to debug log

No debug log. Only visual problem.

• [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

Receiving end hears their own voice when being video called from Asus Zenfone 8. This seems independent of the device of the receiving end. Happens for android and iPhone as receiver.

Steps to reproduce

• Asus Zenfone 8 video calls another user or is being called

Actual result: receiving end hears their own voice as annoying echo only on their side Expected result: receiving end hears only the voice of the caller.

Screenshots

None

Device info

Device: Asus Zenfone 8 (sake) Android version: LineageOs 19.1 Signal version: 6.6.3

Link to debug log

https://debuglogs.org/android/6.6.3/686ce20dc15d0f09ea43b777ff38cba9b34f442b722038969c30909520a448c4

• [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

Updates are not being checked unless the device is on a Wi-Fi network.

Steps to reproduce

• Install app via Android APK on Signal website.
• Disable Wi-Fi for a few weeks, leaving mobile data enabled.
• Enable Wi-Fi again.
• Notice than an update notification is presented after a few days, for a version that was published whilst Wi-Fi was off.

Actual result: No updates are presented when on mobile data. Expected result: Updates should be checked, regardless of network type.

Screenshots

None as there is nothing to show.

Device info

Device: Google Pixel 4a Android version: 13 Signal version: 6.6.3

Link to debug log

No debug log - updates are just not being checked.

I first noticed this bug when away travelling for a while - I have unlimited mobile data so never connect to a Wi-Fi network. Signal informed me that my current version was too out of date. Having to find and connect to a Wi-Fi network, just to auto-update a secure messaging app seem like an oversight. I've since purchased a mobile hotspot for the sole purpose of connecting to its Wi-Fi to "trick" Signal into auto-updating.