Fix torrent monitoring crashing on API 35 after 6 hours#480
Merged
LivingWithHippos merged 1 commit intoJul 7, 2026
Merged
Conversation
…ngWithHippos#403) Android 15 added a hard 6 hour rolling-24h execution limit for dataSync type foreground services. ForegroundTorrentService already had a 5 hour local timer to stop itself before hitting that limit, avoiding the crash, but once it stopped nothing ever brought it back: the service kept existing without calling stopSelf, so a later restart attempt would just try to re-enter foreground state on the same instance without ever resuming the actual polling loop, and if it still lacked enough of the 24h budget it would silently fail forever. Added the proper onTimeout() callback the system calls before the limit is reached, as a more reliable counterpart to the local timer. Both paths now call stopSelf() so the service instance is actually destroyed, and schedule a delayed WorkManager restart so monitoring resumes on its own with a cooldown instead of requiring the user to retoggle the setting or restart the app. If a restart attempt still fails because the cooldown wasn't long enough, it reschedules another one instead of giving up. Monitoring stopping because there are simply no active torrents left is unaffected and still does not trigger a restart.
LivingWithHippos
merged commit f37d7d6
into
LivingWithHippos:master
2 of 3 checks passed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ForegroundTorrentService already had a 5 hour local timer to stop itself before Android 15's
6 hour dataSync foreground service limit kicks in, avoiding the crash from the issue. But once
it stopped, nothing ever brought it back: the service never called stopSelf, so a later restart
attempt just tried to re-enter foreground state on the same instance without resuming the
actual polling loop, and if the 24 hour budget still hadn't freed up it failed silently for
good.
Added the proper onTimeout() callback the system calls right before the limit is hit, as a more
reliable counterpart to the local timer. Both paths now call stopSelf so the instance is
actually destroyed, and schedule a delayed WorkManager restart so monitoring comes back on its
own after a cooldown instead of needing the user to retoggle the setting or restart the app. If
a restart attempt still fails because the cooldown wasn't long enough, it reschedules another
one rather than giving up.
Monitoring stopping because there are simply no active torrents left is untouched and still
doesn't trigger a restart.
Closes #403