Fixed
Status Update
Comments
da...@gmail.com <da...@gmail.com> #2
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.
ra...@google.com <ra...@google.com>
ap...@google.com <ap...@google.com> #3
Thanks for your response.
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)
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)
Description
Version used: 2.1.0-beta01
```
If this is a bug in the library, we would appreciate if you could attach:
- Sample project to trigger the issue.
- A screenrecord or screenshots showing the issue (if UI related).