Status Update
Comments
hu...@google.com <hu...@google.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.
hu...@google.com <hu...@google.com>
ja...@google.com <ja...@google.com> #3
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)
mr...@gmail.com <mr...@gmail.com> #4
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.
da...@google.com <da...@google.com>
da...@google.com <da...@google.com> #5
Sorry, I just re-read the changes for Android 14, and for this to work elegantly, we will need to change the implementation of SystemForegroundService
to do the right thing.
Will try to land this in the next WorkManager release.
Description
Developers can generate unit test coverage report and device test coverage report. At the moment, these two are separate reports.
In order to generate a single report, developers write their own build logic (https://github.com/android/nowinandroid/blob/8bf51cfae361ed8d82500d0f63890662a8e7a28c/build-logic/convention/src/main/kotlin/com/google/samples/apps/nowinandroid/Jacoco.kt#L51 ). E.g.: