STICKY SystemForegroundService crashes when targeting API 34 and location permissions are removed [333957914]

In Progress

Bug

Status Update

No update yet.

Description

st...@deliveroo.co.uk

created issue #1

Apr 12, 2024 03:47PM

Component used: WorkManager, CoroutineWorker
Version used: 2.9.0
Devices/Android versions reproduced on: API 34

When we target API 34, WorkManager is crashing our application on startup if the "location" permissions are removed whilst the application is running.

Everything works fine whilst the application has the "location" permissions. When the "location" permissions are removed (whilst the application is running), the OS is killing the application (OS behaviour) and because SystemForegroundService is a STICKY service, the OS tries to restart the service which causes a security exception because the "location" permissions are no longer present.

This is a realistic user scenario which will happen many times in our production app. We can not prevent our application from crashing as this relates to the STICKY SystemForegroundService. Our application, can check the "location" permissions before scheduling the "worker", but we have no control over the user removing the "location" permissions after the "worker" has been scheduled by the WorkManager.

This behaviour only happens with WorkManager when targeting API 34 as per the restrictions documented here:

https://developer.android.com/about/versions/14/changes/fgs-types-required

Here is the crash we are seeing on application startup:

Java.lang.SecurityException: Starting FGS with type location callerApp=ProcessRecord{34bbf76 32120:com.deliveroo.driverapp.test/u0a190} targetSDK=34 requires permissions: all of the permissions allOf=true [android.permission.FOREGROUND_SERVICE_LOCATION] any of the permissions allOf=false [android.permission.ACCESS_COARSE_LOCATION, android.permission.ACCESS_FINE_LOCATION] and the app must be in the eligible state/exemptions to access the foreground only permission

We are using the WorkManager to run a CoroutineWorker which accesses the device location. We are scheduling the Worker as follows:

val request = OneTimeWorkRequest.Builder(worker.java)
.setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST)
.build()
WorkManager.getInstance(context).enqueueUniqueWork(

worker.java.name,
ExistingWorkPolicy.KEEP,
request,
)

We are specifying FOREGROUND_SERVICE_TYPE_LOCATION in the ForegroundInfo:

ForegroundInfo(ONLINE_NOTIFICATION_ID, notificationsManager.onlineNotification, ServiceInfo.FOREGROUND_SERVICE_TYPE_LOCATION)

Our Android manifest specifies the "location" foregroundServiceType:

<service
android:name="androidx.work.impl.foreground.SystemForegroundService"
android:foregroundServiceType="location"/>

As stated above, everything works fine until the user removes the "location" permissions after the "worker" has started. Then the OS kills our application and the OS tries to recover the STICKY SystemForegroundService which crashes because the app no longer as "location" permissions.

Please can you advise how we can avoid WorkManager crashing our application in the above scenario.

Comments

ra...@google.com <ra...@google.com> #2Apr 15, 2024 05:19PM

Bringing setMaxSchedulerLimit to say 49 doesn't help. Same error.

st...@deliveroo.co.uk <st...@deliveroo.co.uk> #3Apr 16, 2024 09:53AM

If you are using work-firebase then you should not be using JobScheduler directly. Can you please send us the full bug report so we can investigate ?

da...@google.com <da...@google.com> #4Apr 16, 2024 01:59PM

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.scheduleInternal(Schedulers.java:104)
at androidx.work.impl.Schedulers.schedule(Schedulers.java:73)
at androidx.work.impl.WorkerWrapper.setSucceededAndNotify(WorkerWrapper.java:393)
at androidx.work.impl.WorkerWrapper.handleResult(WorkerWrapper.java:255)
at androidx.work.impl.WorkerWrapper.run(WorkerWrapper.java:181)
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)

ra...@google.com <ra...@google.com> #5Apr 16, 2024 05:56PM

Accepted by ra...@google.com.

What do you mean I shouldn't use JobScheduler directly? Isn't work-firebase is just for <21 devices, otherwise JobScheduler always used?

Message last modified on Apr 16, 2024 06:22PM

st...@deliveroo.co.uk <st...@deliveroo.co.uk> #6Apr 17, 2024 03:25PM

I think i was confused by your previous comment. You are right, we only use work-firebase for API < 23.
JobScheduler is used for API >= 23.

This issue should have been resolved in `alpha03` and `alpha04` (we addressed different parts of the problem). If you can reproduce this on a device, then can you do:

1. adb shell dumpsys jobscheduler for your app.
2. Reboot your device.
3. After the reboot, can you re-run adb shell dumpsys jobscheduler ?

I want to check if you see any differences in the jobs created before and after the reboot.

Thanks for your patience.

st...@deliveroo.co.uk <st...@deliveroo.co.uk> #7Jul 15, 2024 09:42AM

Actually for step 2, the easier thing to do is to force stop your app. You don't need to fo a full reboot.

va...@gmail.com <va...@gmail.com> #8Jul 19, 2024 12:50PM

I don't have to to rummage through traces. Here's code snippet that sends app into a crash loop.

https://pastebin.com/NcTAnwjZ

Message last modified on Jul 19, 2024 12:51PM

da...@google.com <da...@google.com> #9Jul 24, 2024 02:01PM

I tried to reproduce this on alpha04. However, I cannot reproduce your issue.

For reference, this is what my activity looks like:

class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
findViewById<Button>(R.id.scheduler_limits_testcase1).setOnClickListener {
for (i in 1..100) {
val a1 = newWorkRequest("--- A1 ---")
val b1 = newWorkRequest("--- B1 ---")
val b2 = newWorkRequest("--- B2 ---")
val c1 = newWorkRequest("--- C1 ---")
WorkManager.getInstance()!!
.beginWith(a1).then(b1).enqueue()
WorkManager.getInstance()!!
.beginWith(a1).then(b2).enqueue()
WorkManager.getInstance()!!
.beginWith(b1, b2).then(c1).enqueue()
}

}
}

companion object {
private fun newWorkRequest(message: String): OneTimeWorkRequest {
val data = mapOf(TestWorker.KEY_MESSAGE to message).toWorkData()
return OneTimeWorkRequestBuilder<TestWorker>()
.setInputData(data)
.build()
}
}
}

This is what my Worker looks like:

class TestWorker : Worker() {
companion object {
private const val TAG = "TestWorker"
private const val MESSAGE_DEFAULT = "Default"
const val KEY_MESSAGE = "KEY_MESSAGE"
}

override fun doWork(): Result {
val message = inputData.getString(KEY_MESSAGE, MESSAGE_DEFAULT)
val random = Random()
val time = 500L + random.nextInt(300)
Log.d(TAG, "Before. $message")
Thread.sleep(time)
Log.d(TAG, "After. $message")
return Result.SUCCESS
}
}

ap...@google.com <ap...@google.com> #10Jul 25, 2024 12:03AM

Do you have another part of your codebase that is scheduling jobs with JobScheduler?

ap...@google.com <ap...@google.com> #11Jul 25, 2024 12:03AM

We have 1 job that schedules once on app start, that's it.

rw...@gmail.com <rw...@gmail.com> #12Sep 24, 2024 06:23AM

I created a sample app.

For some reason it rarely crashes on AVD Emulator(Api 27), but 100% crashes on Genymotion Api 26 and my Xiaomi Redmi 7.1.2

You can try both Activities.