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.
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.