The crash happened because #getNextClosestEvent was called when
mmsDatabase was null, which would normally be impossible. However, it
seems implied that somehow #getNextClosestEvent was being called in the
parent constructor before the child class was fully initialized. That
would imply that the looper was called synchronously in some freak
scenario, but it's the only explanation. So I added a delay to the call
in the parent constructor.
```java
java.lang.NullPointerException:
at org.thoughtcrime.securesms.revealable.RevealableMessageManager.getNextClosestEvent (RevealableMessageManager.java:40)
at org.thoughtcrime.securesms.revealable.RevealableMessageManager.getNextClosestEvent (RevealableMessageManager.java:23)
at org.thoughtcrime.securesms.service.TimedEventManager.lambda$scheduleIfNecessary$1 (TimedEventManager.java:44)
at org.thoughtcrime.securesms.service.-$$Lambda$TimedEventManager$kZDO3F2WBQVtGx-SkAgEDt8jCeU.run (Unknown Source:2)
at android.os.Handler.handleCallback (Handler.java:873)
at android.os.Handler.dispatchMessage (Handler.java:99)
at android.os.Looper.loop (Looper.java:193)
at android.os.HandlerThread.run (HandlerThread.java:65)
```
On phones with no SIM card, if you manage to enqueue a job with a
CellServiceConstraint, the previous check we were using to check if
there was cell service could hang indefinitely on some devices.
This changes it to a fast check, which all constraints should be.
There are a handful of devices that refuse to use our AesGcmProvider,
and as a result they would crash with AssertionErrors when downloading
avatars. Still haven't found why, but for now, probably best to stop
these devices from crashing, since it puts them in a crash loop, and the
app is still usable without avatars.
There appears to be a weird bucketing thing that happens on some
devices, where if you give them a resolution that's too small, it'll
default you to some potato resolution. So we just bumped it up to
1920x1920, and that seems to be working on my swath of devices.
If you gave the class an empty file, it would get back -1 for read(),
causing it to fall forever into negative values, never escaping the
existing conditions.
The side effect of this was weird corner cases where these infinite
reads could clog up threads, causing audio recordings to get blocked
and such.
Fixes#8898
There seems to be a bad implementation of Address parcelization that
pops up in certain scenarios. We can avoid it by just excluding it
from the parcel altogether.
CameraX was initializing Camera2 API stuff on API < 21, causing
crashes at boot. To handle this, we disable the default
ContentProvider initializer and initialize things ourselves for
appropriate API levels.
Due to support library bug, onActionItemClicked can be called after finish/onDestroyActionMode so we can check for that by checking if our reference to the action mode is still valid.
Fixes#8891
