-
-
Notifications
You must be signed in to change notification settings - Fork 35
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
Labels
bug
Something isn't working
Comments
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>
Merged
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>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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!
The text was updated successfully, but these errors were encountered: