Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rebase #1

Merged
merged 454 commits into from
Jul 24, 2019
Merged

rebase #1

merged 454 commits into from
Jul 24, 2019

Conversation

Meteor0id
Copy link
Owner

No description provided.

alan-signal and others added 30 commits March 28, 2019 15:14
Fixes #8590
- Scale image larger within the dimensions.
- Apply a minimum dimension of 1024.
Fixes #8575
Closes #8638

Co-authored-by: Jakub Gregorek <jg@inthemeadow.net>
Exception logging tends to be race-y, so now we block and wait
for all logs to be written before continuing with the crash.
Some devices have a limit of 100 unique JobScheduler jobs.
Previously we allowed up to 1,000. Given that we just need
_some_ job running, I lowered the limit to 75 to give us
some head room.
The new JobManager stuff created a table that had an
auto-incrementing ID, which was incorrectly being backed
up and restored, causing a crash. Now we skip it on both
import and export.
It used to be that we let Android do the default behavior of
full-screening the EditText when in landscape, but honestly I
don't know who prefers that. So I've turned it off.

Fixes #8769
alan-signal and others added 29 commits July 17, 2019 14:07
This allows you to take a photo, then choose the recipients after. This
also makes it so we only upload the attachment once.
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.
Send support isn't enabled yet, but didn't want to forget about it.
Only affects people who have force-enabled revealable messages and then
gone back to a build that doesn't have it enabled.
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)
```
@Meteor0id Meteor0id merged commit 1da9ec5 into Meteor0id:master Jul 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet