fix(android): Allow setting grace period before stopForeground #2164
Conversation
This file contains 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
|
This will be particularly helpful in the workaround for #1845 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR adds a configurable grace period - a delay before we attempt to set our service to not be in foreground mode, allowing users a chance to do player actions that might refrain us from deciding to go out of foreground state. Defaults to five seconds.
Context:
At the moment on Android as soon as we transition back to idle/stop/error we immediately set our service as not being in the foreground state (setting yourself as not in foreground is good practice). In the use of RNTP where everyone's needs are different, a user might still want to enqueue some kind of playback action once they realize the queue is over, an error has happened, etc. For example, once a user's queue ends, they may want to create a whole new queue of related music.
Immediately setting ourselves as not in foreground state may give the OS a chance to turn off network chips, or kill the service which may result in errors if you try to do any network loading (i.e. playing a remote track) after that as happens on #2159.