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

Status notifications permanently stuck #179

Closed
haarp opened this issue May 10, 2024 · 1 comment · Fixed by #187
Closed

Status notifications permanently stuck #179

haarp opened this issue May 10, 2024 · 1 comment · Fixed by #187
Labels
bug Something isn't working

Comments

@haarp
Copy link

haarp commented May 10, 2024

Hello,

I'm using v. 2.3.2 from F-Droid. I have scheduled export activated with export being dumped to Nextcloud SAF location. Messages and Calls are enabled.

Every night when the dump finishes, the "Scheduled export executing" notification remains. I can see the calls and messages files ending up on Nextcloud, so the dump appears to finish.

This problem started after a recent upgrade, probably 2.3.1. I currently get rid of the notifications by manually disabling all notifications for the app, then re-enabling them.

Thanks!

@tmo1 tmo1 added the bug Something isn't working label May 13, 2024
@tmo1
Copy link
Owner

tmo1 commented May 13, 2024

Thanks for reporting this. I have reproduced the problem, and am working on figuring it out.

chenxiaolong added a commit to chenxiaolong/sms-ie that referenced this issue May 25, 2024
This is an ugly hack, but is necessary unless we switch to another
mechanism like AlarmManager. When the OneTimeWorkRequest is scheduled
at the end of the job execution, it delays the stopping of the
foreground service, causing the notification to stay around longer than
needed.

To prevent this, we need to schedule the next run after the androidx
work library has already performed its cleanup. To do this, we can rely
on the (documented) behavior where Android runs all services on the main
thread. We can post an event to the main thread's event loop to schedule
the next job execution.

Android's officially supported method of running periodic tasks with the
androidx work library is to use a PeriodicWorkRequest. Unfortunately,
the behavior of our jobs is unsuitable for maintaining the same user
experience. If a periodic job is scheduled with a 24 hour interval and
an initial delay to align the intervals to the proper starting time, the
job will not run when expected. Android may execute the job at a random
time within the 24 hour window.

Fixes: tmo1#179

Signed-off-by: Andrew Gunnerson <accounts+github@chiller3.com>
chenxiaolong added a commit to chenxiaolong/sms-ie that referenced this issue May 26, 2024
This is an ugly hack, but is necessary unless we switch to another
mechanism like AlarmManager. When a new job is scheduled during the
execution of a running job, the running job is treated as if it were
interrupted. The androidx work library currently does not dismiss
foreground notifications for interrupted jobs.

To prevent this, we need to schedule the next run after the androidx
work library has already processed the result of doWork(). To do this,
we can rely on the (documented) behavior where Android runs all services
on the main thread. We can post an event to the main thread's event loop
to schedule the next job execution.

Android's officially supported method of running periodic tasks with the
androidx work library is to use a PeriodicWorkRequest. Unfortunately,
the behavior of our jobs is unsuitable for maintaining the same user
experience. If a periodic job is scheduled with a 24 hour interval and
an initial delay to align the intervals to the proper starting time, the
job will not run when expected. Android may execute the job at a random
time within the 24 hour window.

Fixes: tmo1#179

Signed-off-by: Andrew Gunnerson <accounts+github@chiller3.com>
@tmo1 tmo1 closed this as completed in #187 May 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants