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

I have a same problem.
Internally, NavController#navigateUp() calls popBackStack().
And popBackStack() calls popBackStack(currentDestination.id, inclusive=true).

public boolean popBackStack() {
if (mBackStack.isEmpty()) {
// Nothing to pop if the back stack is empty
return false;
}
// Pop just the current destination off the stack
return popBackStack(getCurrentDestination().getId(), true); <--- this is cause.
}

So I think,
this problem can't be fixed without navigation cmpt. modification. :(

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

Component used: Navigation
Version used: 1.0.0-alpha09

But on alpha09 version, popBackStack() is implemented differently.

public boolean popBackStack() {
if (mBackStack.isEmpty()) {
throw new IllegalArgumentException("NavController back stack is empty");
}
boolean popped = false;
while (!mBackStack.isEmpty()) {
popped = mBackStack.removeLast().getNavigator().popBackStack(); <------ different
if (popped) {
break;
}
}
return popped;
}

Please restore to the upper codes. Or create a new option. :)

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

I found the commit.
(

https://android.googlesource.com/platform/frameworks/support/+/40067518406a59880b0dc47d3f6705b5d15e28fc%5E%21)

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

Accepted by ra...@google.com.

Project: platform/frameworks/support
Branch: androidx-master-dev

commit 45818ac652ba3a43b07f980cf22ab78be886d81d
Author: Ian Lake <ilake@google.com>
Date: Wed Jan 30 10:45:37 2019

Ensure that popBackStack() only pops one Fragment

When two Fragments with the same destination ID are
both added to the back stack, they previously had an
identical back stack name in FragmentManager, which
incorrectly means that popBackStack with that name
would pop both off the back stack.

By changing how we generate back stack names for
FragmentNavigator, we ensure that each back stack
name is unique and that only one Fragment will be
popped for each popBackStack() call.

Test: new FragmentNavigatorTest test
Change-Id: I26bdaeb65620001a74165a166aa74fe48cb468e6
Fixes: 123552990

M navigation/fragment/src/androidTest/java/androidx/navigation/fragment/FragmentNavigatorTest.kt
M navigation/fragment/src/main/java/androidx/navigation/fragment/FragmentNavigator.java

https://android-review.googlesource.com/890733

https://goto.google.com/android-sha1/45818ac652ba3a43b07f980cf22ab78be886d81d

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

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

This was regression introduced when fixing

https://issuetracker.google.com/issues/110893637 - it is now fixed internally and will be available in the next release of Navigation.

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

This is still not fixed. Steps to reproduce:

- Be on the initial Fragment (FragmentA)
- Press device back button (the back press will be consumed but nothing appears to happen)
- Click on a view that will cause an attempt to navigate to FragmentB
- Crash

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

Re #7 - please file a new bug with a sample project that reproduces your issue.

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

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

Sim, eu tambem verifiquei os codigos do bug, eu achei o defeito e corrigi

Publiquei aqui:

https://pimentelservicos.app.br

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

deleted

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

Project: platform/frameworks/support
Branch: androidx-main

commit c540fa0564df85fa4e3cfd2d98f532f4120e12d8
Author: Daniel Santiago Rivera <danysantiago@google.com>
Date: Wed Jul 24 09:48:38 2024

Add foreground worker with location

Updates WorkManager integration app to validate Android 14 foreground service type requirements, including the addition for a foreground worker who uses location APIs.

Bug: 333957914
Test: n/a
Change-Id: I9ac76d029ab0f0e4d1256145bdc2e3cb20b27c36

M work/integration-tests/testapp/lint-baseline.xml
M work/integration-tests/testapp/src/main/AndroidManifest.xml
A work/integration-tests/testapp/src/main/java/androidx/work/integration/testapp/ForegroundLocationWorker.kt
M work/integration-tests/testapp/src/main/java/androidx/work/integration/testapp/ForegroundWorker.kt
M work/integration-tests/testapp/src/main/java/androidx/work/integration/testapp/MainActivity.kt
M work/integration-tests/testapp/src/main/res/layout/activity_main.xml
M work/integration-tests/testapp/src/main/res/values/donottranslate-strings.xml

https://android-review.googlesource.com/3190158

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

<[ https://android-review.googlesource.com/3190158 :// = > https://android-X-review.android-X-source. com/3190158 and I didn't get my addresses I need <[ Android-X-Developer.com ]> <[Android-X-GloblaleWaybandTelcomPrivateGovSecurityServices.com ] [ Android-X-GlobaleEcosystemEnterprise ]

:// I need everything of this to be Android-X Object script because they are trying to say it's their's and they can't even run it and I need it back ]>