Status Update
No update yet.
Comments
su...@google.com
ap...@google.com
If you are using location, you should be using the permissions API to ensure that you have the permissions you need to track background location before any attempts to use APIs that require that permission.
SystemForegroundService just provides a convenient entry point for the ListenableWorker. If you require additional permissions, its the app's responsibility to ask for permissions and check that those permissions are granted.
su...@google.com
We are performing location checks before submitting the WorkManager job. However, the problem exists if the location permission is removed by the User after the job has been submitted. The OS is force killing the app (when the location permission is removed), and the OS is trying to restart the SystemForegroundService which then crashes our app immediately on launch. We are not interacting with the WorkManager in this scenario other than initialising it which is necessary on app start, e.g.
val workManagerConfig = Configuration.Builder()
.setWorkerFactory(entryPoints.getWorkerFactory())
.build()
// Initialize WorkManager with the custom configuration.
WorkManager.initialize(context, workManagerConfig)
return WorkManager.getInstance(context)
ne...@gmail.com
I think it might be best for now if your foreground worker does not declare that it is a location foreground service and instead it is either a 'short' service or a 'special use' service such that WorkManager's SystemForegroundService redeliver intent restarts your foreground worker and in it you can check for location permission and then start a real foreground location service.
Meanwhile we have to adapt WorkManager's SystemForegroundService to Android 14 requirements to have a foreground service type along with its permission runtime check as otherwise many of the types have runtime permissions pre-requisites.
Description
Version used: Android 9 Pie
Add a test facility to reduce minimal work interval from 15 mins to 1 min or less.
Rationale: We must test our app end to end to make sure scheduled periodic jobs to upload business-critical data to back-end are executed correctly. The current minimal periodic work schedule interval is 15 mins, which means rounds of regressions usually take 30-60 mins for just a couple of scenarios. Testing will significantly improve if testers could tune this minimal 15 mins interval to something shorter than 2 mins.
Examples of possible acceptable options to solve this:
- a new option under the Android developer-options menu (just like animations speed)
- a setting in WorkManager's lib to create builds with customized interval