Status Update
No update yet.
Comments
ra...@google.com
ra...@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.
d....@infotech.team
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)
su...@google.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:1.0.0-alpha07
Devices/Android versions reproduced on:
java.lang.IllegalStateException: Apps may not schedule more than 100 distinct jobs
at android.os.Parcel.readException(Parcel.java:1692)
at android.os.Parcel.readException(Parcel.java:1637)
at android.app.job.IJobScheduler$Stub$Proxy.schedule(IJobScheduler.java:158)
at android.app.JobSchedulerImpl.schedule(JobSchedulerImpl.java:42)
at androidx.work.impl.background.systemjob.SystemJobScheduler.scheduleInternal(SystemJobScheduler.java:126)
at androidx.work.impl.background.systemjob.SystemJobScheduler.schedule(SystemJobScheduler.java:95)
at androidx.work.impl.Schedulers.schedule(Schedulers.java:99)
at androidx.work.impl.utils.EnqueueRunnable.scheduleWorkInBackground(EnqueueRunnable.java:114)
at androidx.work.impl.utils.EnqueueRunnable.run(EnqueueRunnable.java:86)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
at java.lang.Thread.run(Thread.java:761)
I already reported this bug multiple times but it is still not fixed. I attached sample project from my prevoious report. In our production app there is only one schedule operation(it calulculates worker tree once and schedules them all on the same thread frame) that you see in the sample app, but it still crashes.
I attached a sample project.
Run the app and press the button multiple times in a quick succession.