We saw a worrisome log that implied there may be a situation where
there's two IncomingMessageObservers. I can't see how that would happen,
but this is a failsafe to prevent that from happening.
This was a bug that was most notable during the attachment pre-upload
process: if an attachment failed to upload, the subsequently-enqueued
PushMediaSendJob would still send. This is because the attachment jobs
were enqueued first and failed *before* we enqueued the PushMediaSendJob
as a dependency.
This will use the JobTracker to determine if a dependency already failed
at the time of enqueueing a job like this. This isn't perfect, because
the JobTracker is memory-only and has a limited buffer (currently 1000),
but in practice this should be sufficient for our use cases. I imagine
it'd only fall apart if we somehow enqueued a dependent job *much*
later, or somehow enqueued it based on a job ID that we persisted on
disk through an app restart. We don't do any of these things, currently,
and probably never should.
Also took the opportunity to patch a case where we weren't failing
dependent jobs when canceling a job, since I was giving the failure
stuff a look-over.
* Switch to a standard toolbar color.
* T r a n s p a r e n c y
* Add back a toolbar shadow.
* Some more theming
* Also fix verify identity screen.
* Hide shadow on empty conversations.
* Slightly less transparent.
When the device is in Do Not Disturb mode and a call comes in from a
system contact, the app crashes if the user has revoked the contacts
permission.
The crash occurs because in Do Not Disturb mode Signal tries to check if
the contact is starred.
On mulit-device app, after the contact color is changed, a multi-device
contact update job is triggered, which tries to access the system
avatar.
This causes a crash if the user has revoked the contacts permission.
Currently the maxInstancesForQueue limit checks the count of all jobs in a
given queue. If there are already too many jobs, the new job is discarded.
However this is not the expected behavior for the two jobs where it's used:
GroupCallPeekWorkerJob and AutomaticSessionResetJob
For both the expected behavior is that there aren't too many jobs of them
started, but that there will be at least one instance of them started.
Both of them use the same queue as the PushProcessMessageJob and the MarkerJob.
Those two jobs are often in the queue at the same time, effectively preventing
the GroupCallPeekWorkerJob and AutomaticSessionResetJob from being enqueued.
For some reason, if an EmojiTextView has a wrap content width and some other set of conditions occur, the view will not request a relayout when text changes.
This change inelegantly calls request layout more often to prevent that from happening.
