Work Manager on Chinese ROMs like Xiaomi and Oppo, when under battery optimization, increase the scheduled delay of work by several hours., however, I have noticed some apps
WorkManager is intended for tasks that are deferrable—that is, not required to run immediately—and required to run reliably even if the app exits or the device restarts. For example
WorkManager is not intended for in-process background work that can safely be terminated if the app process goes away or for tasks that require immediate execution. Please review the background processing guide to see which solution meets your needs.
There are two types of work supported by WorkManager: OneTimeWorkRequest and PeriodicWorkRequest`.
So would that be responsible for keeping the app alive by the battery optimizer?
A WorkRequest for repeating work. This work executes multiple times until it is cancelled, with the first execution happening immediately or as soon as the given Constraints are met. The next execution will happen during the period interval; note that execution may be delayed because WorkManager is subject to OS battery optimizations, such as doze mode.
I also noticed, that after I force stopped that app, after 24 hours it started working again, but how is that possible?
See PeriodicWorkRequest.Builder
- Creates a PeriodicWorkRequest to run periodically once within the flex period of every interval period. See diagram below. Note that flex intervals are ignored for certain OS versions (in particular, API 23). The flex period begins at
repeatInterval - flexIntervalto the end of the interval. The repeat interval must be greater than or equal to PeriodicWorkRequest.MIN_PERIODIC_INTERVAL_MILLIS and the flex interval must be greater than or equal to PeriodicWorkRequest.MIN_PERIODIC_FLEX_MILLIS.