GitLab

This could cause us to think push messages were actually sent with
a SIM. We also now prevent rendering SIM info on push messages in
the conversation view.

Fixes #8176

Shoutout to @aleb2000 for working on this as well!

Fixes #8151

Related to #8145

If the user has an external SD card set as their default storage
(notably on a Huawei device, like the Huawei Mate 10 Lite), then
PersistentBlobProvider will try to write a file to the SD card, but
would fail to generate a URI for it due to us missing a line in our
FileProvider setup. This just adds that missing entry.

Special thanks to @aleb2000 for digging into this!

Fixes #8144
Fixes #7726

Required for the API 26 migration.

See https://developer.android.com/about/versions/oreo/android-8.0-changes#ccn

Fixes #8180

Shoutout to @bomba1990 for fixing this around the same time as me :)

Fixes #8182

Fixes #8184

Relates to #8184

We were recreating the channels before the database upgrade. We
have to do it after.

Fixes #8174

Fixes #8147

We were hitting the transaction limit size. This change scales down
shortcut icons to be at most 300x300, which comes out to ~360kb, which
should be safely under the limit of 1mb.

Fixes #8139

We were getting an IllegalArgumentException during channel creation on
some Samsung phones. Stack trace didn't give me much more than that, so
just adding in some additional safeguards that make sense based on
reading AOSP.

We manually play the ringtone when in-thread notifications are enabled,
but we weren't using the sound specified by the channel in the system
settings. This fixes that problem by reading the NotificationChannel
setting.

We were getting a TransactionTooLargeException when giving an
EditText a very large (1.5MB+) text block. This has been resolved
by switching to a RecyclerView to show the text line-by-line. As a
side-effect, this improves scroll performance on lower-end devices.

Also, I added a button to jump to the bottom of the log because I
really wanted one :)

Fixes #8124

Previously, we were making a new copy of the entire source string after
every scrubbed substitution. In the case of our new, larger log files,
this was very slow. It's been changed so we only ever create one new
copy.

In practice, on a Moto E (2014), scrubbing a 1.5MB log went from
>4000ms to ~100ms.

Fixes #8116

Fixes #8119
Fixes #8121
Fixes #8122