IllegalStateException > Not allowed to start service Intent ACTION_STOP_FOREGROUND [147249312]

Fixed

Bug

Status Update

No update yet.

Description

ha...@gmail.com

created issue #1

Jan 7, 2020 08:32AM

Component used: androidx.work:work-runtime-ktx
Version used: 2.3.0-beta01
Devices/Android versions reproduced on: Galaxy A7 (Android 9) / Galaxy S10 (Android 10)

versions.build = [
minsdk : 23,
targetsdk : 29,
buildtools: "29.0.2",
]

---

I get a crash after start using the new foreground API in 2.3.0. I'm using `CoroutineWorker` and calling `setForeground()` in its `doWork()` with a notification which has an action created by `WorkManager.getInstance(context).createCancelPendingIntent(id)`. This should stop the job when clicked.

This seemed to work fine but after releasing, it crashes for some users with the following stacktrace (on Android 10; on Android 9 the line is 1666 instead of 1687):

```
Fatal Exception: java.lang.IllegalStateException: Not allowed to start service Intent { act=ACTION_STOP_FOREGROUND cmp=de.loewen.lcsmobile/androidx.work.impl.foreground.SystemForegroundService }: app is in background uid UidRecord{da09b33 u0a309 CEM idle change:cached procs:1 proclist:29769, seq(0,0,0)}
at android.app.ContextImpl.startServiceCommon(ContextImpl.java:1687)
at android.app.ContextImpl.startService(ContextImpl.java:1632)
at android.content.ContextWrapper.startService(ContextWrapper.java:683)
at androidx.work.impl.Processor.stopForegroundService(Processor.java:303)
at androidx.work.impl.Processor.stopForeground(Processor.java:221)
at androidx.work.impl.WorkerWrapper.resolve(WorkerWrapper.java:453)
at androidx.work.impl.WorkerWrapper.setFailedAndResolve(WorkerWrapper.java:519)
at androidx.work.impl.WorkerWrapper.handleResult(WorkerWrapper.java:485)
at androidx.work.impl.WorkerWrapper.onWorkFinished(WorkerWrapper.java:343)
at androidx.work.impl.WorkerWrapper$2.run(WorkerWrapper.java:318)
at androidx.work.impl.utils.SerialExecutor$Task.run(SerialExecutor.java:91)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:919)
```

I've looked into the changelog of 2.3.0-beta02 but it doesn't seem like there's already a fix for this problem.

The stacktrace doesn't contain a line of my app, only the workmanager-library so I think its crashing after the users clicks the cancel-action on the notification.

Comments

ra...@google.com <ra...@google.com> #2Jan 7, 2020 07:03PM

https://android-review.googlesource.com/c/platform/frameworks/support/+/1092870

ra...@google.com <ra...@google.com> #3Jan 8, 2020 11:11PM

Status: Won't Fix (Obsolete)

Thank you for the quick fix.
Is there an ETA for the next release?

ha...@gmail.com <ha...@gmail.com> #4Jan 9, 2020 10:40AM

2.2.0-rc01 should be out this week.

da...@gmail.com <da...@gmail.com> #5Jan 21, 2020 10:08AM

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

commit a1957df3709a06f4e6482fb0e4d39ded4f230a70
Author: Rahul Ravikumar <rahulrav@google.com>
Date: Mon Jul 29 09:48:05 2019

Workaround NPE in PersistableBundle.getExtras().

Test: Existing unit tests pass. Ran integration test app.
Fixes:

b/138441699

Change-Id: I0b48e0009a7d83c343a3d26112b94c057470c281

M work/workmanager/src/main/java/androidx/work/impl/background/systemjob/SystemJobService.java

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

https://goto.google.com/android-sha1/a1957df3709a06f4e6482fb0e4d39ded4f230a70

da...@gmail.com <da...@gmail.com> #6Jan 21, 2020 11:51AM

The following changes were cherrypicked through Coastguard (

https://android-build.googleplex.com/coastguard/)
Release Track: (

https://android-build.googleplex.com/coastguard/dashboard/6206758647365632/#/cherrypickHistory/all)
Created: 2019-07-29 19:41:55.445144+00:00
Changes: aosp/1092870

ra...@google.com <ra...@google.com> #7Jan 21, 2020 06:25PM

Can you reproduce this all the time ?

While I am investigating this issue on my end, a reproducible sample app would help a lot.

ra...@google.com <ra...@google.com> #8Jan 21, 2020 06:53PM

One other question I have is, in your Worker when do you call setForegroundAsync() ? Do you do this as soon as your Worker is instantiated and invoked or is there a delay ?

da...@gmail.com <da...@gmail.com> #9Jan 22, 2020 08:26AM

Hi,

no the problem doesn't happen all the time, I've seen it in crashlytics but I can't reproduce it myself in my dev environment.

The documentation talked about Worker and CoroutineWorker, said nothing about RxWorker. It looked like they both run the command as soon as they entered the background scheduler.

So I did what I though made more sense, call setForegroundAsync as soon as I subscribe to the Rx object. It shouldn't have a delay cause I do not change the scheduler later down the rx chain, inside the actual auto-sync job (see code below)

// used as a periodic work running every 1 hour
class SyncBatchWorker(appContext: Context, workerParams: WorkerParameters) :
RxWorker(appContext, workerParams) {

override fun createWork(): Single<Result> {
return autoSync() // return a Completable, inside here I do stuff like subscribeOn(Schedulers.io) or the likes
.doOnSubscribe { setupForeground() } // <----- here is where I do it, it should run right away when it is subscribed, before switching scheduler I think
.andThen(Single.just(Result.success()))
}

private fun setupForeground() {
setForegroundAsync(
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) {
ForegroundInfo(
NOTIFICATION_ID,
createSyncForegroundNotification(), // this also create the channel if needed
ServiceInfo.FOREGROUND_SERVICE_TYPE_CONNECTED_DEVICE
or ServiceInfo.FOREGROUND_SERVICE_TYPE_DATA_SYNC
)
} else {
ForegroundInfo(
NOTIFICATION_ID,
createSyncForegroundNotification(), // this also create the channel if needed
)
}
)
}

// some method omitted cause it was irrelevant for this issue (notification / channel creation and actual autosync code)
}

hope this was the right way to do it.

If I found out more about about the issue I'll drop a comment!

da...@gmail.com <da...@gmail.com> #10Jan 22, 2020 08:27AM

ups:
"I do not change the scheduler UNTIL later down the rx chain"

da...@gmail.com <da...@gmail.com> #11Jan 22, 2020 08:49AM

My rationale was this:

This is your Worker class implementation:

@WorkerThread
public abstract @NonNull Result doWork();

@Override
public final @NonNull ListenableFuture<Result> startWork() {
mFuture = SettableFuture.create();
getBackgroundExecutor().execute(new Runnable() {
@Override
public void run() {
try {
Result result = doWork();
mFuture.set(result);
} catch (Throwable throwable) {
mFuture.setException(throwable);
}

}
});
return mFuture;
}

you suggest to do the setForegroundSync right away in the `doWork()` which is called when run inside the backgroundExecutor.

This is the implementation of RxWorker:

@MainThread
public abstract @NonNull Single<Result> createWork();

@NonNull
@Override
public ListenableFuture<Result> startWork() {
mSingleFutureObserverAdapter = new SingleFutureAdapter<>();

final Scheduler scheduler = getBackgroundScheduler();
createWork()
.subscribeOn(scheduler)
// observe on WM's private thread
.observeOn(Schedulers.from(getTaskExecutor().getBackgroundExecutor()))
.subscribe(mSingleFutureObserverAdapter);
return mSingleFutureObserverAdapter.mFuture;
}

protected @NonNull Scheduler getBackgroundScheduler() {
return Schedulers.from(getBackgroundExecutor());
}

the createWork() is called in the MainThread but the subscription to the observable (Single) is performed inside the BackgroundExecutor scheduler (same as the `Worker.doWork()`) so I did it in `doOnSubscribe()`

You can picture my implementation as if it was like this:

override fun createWork(): Single<Result> {
return Completable.timer(5, TimeUnit.Minutes)
.subscribeOn(Schedulers.io())
.doOnSubscribe { setForegroundAsync(createForegroundInfo(progress)) }
.andThen(Single.just(Result.success()))
}

which with Rx should mean the execution order is:

1. subscribe inside the background executor thread
2. --> call setForegroundAsync()
3. switch scheduler to Schedulers.io()
4. execute the timer (wait 5 minutes -- probably on another scheduler but this is just an example)
5. 5 minutes pass
6. return the complete in whatever thread it was executing
7. convert it into a Single with result success
8. give back control to your code (which observe on the background executor scheduler again and do whatever is needed to clean up the job)

ra...@google.com <ra...@google.com> #12Jan 22, 2020 06:32PM

What you are doing looks correct.

STOP_FOREGROUND is only called when the Worker needs to be stopped. Something caused your Worker to be stopped, and my guess is that it happened before the call to startForegroundAsync().

One thing that might help is calling startForegroundAsync() from inside your Worker constructor. You could set that to a Notification with 0% progress for e.g.

I will try and investigate this more to see if there is something more we can do on our end to make this easier to manage.

ra...@google.com <ra...@google.com> #13Jan 22, 2020 08:31PM

Investigating this further, WorkManager prevents you from sending the STOP_FOREGROUND intent unless you have called startForegroundAsync().

da...@gmail.com <da...@gmail.com> #14Jan 22, 2020 09:03PM

I'm a bit confused, my code doesn't send the stop foreground.

I think it happens automatically when the work is done / canceled (no?).

Why would it call stop foreground if I did not call startForegroundAsync yet?

When you say i should try to call startForegroundAsync() in the constructor of my worker, do you actual mean the init { } block or inside createWork() (but directly in the method rather then in then in the rx chain)?

Thanks for your feedback!

da...@gmail.com <da...@gmail.com> #15Jan 22, 2020 09:10PM

ah, right, you said in

comment #13

that the reason can't be that I don't call startForegroundAsync in a timely fashion cause it would not try to stop otherwise. (i missread the first time).

anything I can do to help you debug?

I can't reproduce in my dev environment but maybe I can release an upgrade that gives me more information in the crashlytics log when it happens to someone.

ra...@google.com <ra...@google.com> #16Jan 22, 2020 10:16PM

More information would help a lot.

da...@gmail.com <da...@gmail.com> #17Jan 23, 2020 05:11AM

Any ways i could create more information?

I'll update to the just released 2.3.0 version today and enable debug logging for WorkManager in production.

But i doubt that log will be included with the Crashlytics report unless the user get a crash report and manually click on send feedback.

If you have any idea on what i could do to extract more informations I'll try to help.

ey...@gmail.com <ey...@gmail.com> #18Jan 26, 2020 05:39AM

I released an EOL update to an app a few days ago, and just checked my crash logs on the Play Store. 1,400 occurrences of this crash. Almost exclusively happening on Android 9 (one occurrence on Android 10), and almost exclusively Samsung devices. Didn't happen once during our QA process. Using 2.3.0

java.lang.IllegalStateException:
at android.app.ContextImpl.startServiceCommon (ContextImpl.java:1666)
at android.app.ContextImpl.startService (ContextImpl.java:1611)
at android.content.ContextWrapper.startService (ContextWrapper.java:677)
at androidx.work.impl.Processor.stopForegroundService (Processor.java:303)
at androidx.work.impl.Processor.stopForeground (Processor.java:221)
at androidx.work.impl.WorkerWrapper.resolve (WorkerWrapper.java:453)
at androidx.work.impl.WorkerWrapper.rescheduleAndResolve (WorkerWrapper.java:546)
at androidx.work.impl.WorkerWrapper.onWorkFinished (WorkerWrapper.java:348)
at androidx.work.impl.WorkerWrapper$2.run (WorkerWrapper.java:318)
at androidx.work.impl.utils.SerialExecutor$Task.run (SerialExecutor.java:91)
at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:641)
at java.lang.Thread.run (Thread.java:764)

Galaxy S9 (starqltesq) 339 23.2%
Galaxy Note9 (crownqltesq) 221 15.1%
Galaxy S9+ (star2qltesq) 203 13.9%
Galaxy S8 (dreamqltesq) 169 11.6%
Galaxy Note8 (greatqlte) 106 7.3%
Galaxy S8+ (dream2qltesq) 103 7.1%
Galaxy A50 (a50) 74 5.1%
Galaxy A20 (a20p) 32 2.2%
Galaxy A10e (a10e) 27 1.8%
Galaxy J3 V (j3topeltevzw) 27 1.8%
Galaxy S10+ (beyond2q) 16 1.1%
Galaxy J7 Refine (j7topeltespr) 14 1.0%
Galaxy A6 (a6eltespr) 13 0.9%
Galaxy S9 (starqlteue) 13 0.9%
Galaxy S8 Active (cruiserlteatt) 12 0.8%
Galaxy S8 (dreamqlteue) 12 0.8%
Galaxy A70 (a70q) 10 0.7%
Galaxy A20 (a20) 10 0.7%
Galaxy J7 Star (j7topltetmo) 8 0.5%
Galaxy J3 Orbit (j3topltetfntmo) 7 0.5%
Others 44 3.0%

ra...@google.com <ra...@google.com> #19Jan 26, 2020 09:35PM

Thanks. One thing that is clear in your stack traces, is that WorkManager was attempting to reschedule the Worker. Let me continue investigating along those lines.

da...@gmail.com <da...@gmail.com> #20Jan 27, 2020 08:18AM

Isn't It rescheduling because it's a periodic work? Mine is a periodic work.

But it looks like it is failing in the "resolve" part, so the reschedule should have been completed successfully.

ra...@google.com <ra...@google.com> Jan 27, 2020 06:39PM

Status: New (reopened)

an...@google.com <an...@google.com> #21Jan 27, 2020 09:46PM

The following changes were cherrypicked through Coastguard (

https://android-build.googleplex.com/coastguard/)
Release Track: (

https://android-build.googleplex.com/coastguard/dashboard/6206758647365632/#/history/all)
Created: 2020-01-27 21:44:37.758305+00:00
Changes: aosp/1218539

ra...@google.com <ra...@google.com> #22Jan 28, 2020 12:27AM

Marked as fixed, reassigned to ra...@google.com.

https://android-review.googlesource.com/c/platform/frameworks/support/+/1218539/ makes improvements to how WorkManager manages notification lifecycles.

WorkManager 2.3.1 should have this fix.

ha...@gmail.com <ha...@gmail.com> #23Jan 28, 2020 06:39AM

Is there any ETA for 2.3.1 yet?

ra...@google.com <ra...@google.com> #24Jan 28, 2020 06:37PM

We are looking at the first week of February.

ey...@gmail.com <ey...@gmail.com> #25Jan 31, 2020 06:39PM

Any way to get a snapshot or alpha build? I'm up to 6.5k crashes in the past 7 days. I can't roll back because it was an EOL update, and I can't remove WorkManager because it was needed for EOL behavior.

ra...@google.com <ra...@google.com> #26Jan 31, 2020 06:44PM

You can try a snapshot build by doing the following:


repositories {
    google()
    maven { url 'https://ci.android.com/builds/submitted/6171913/androidx_snapshot/latest/repository/' }
}

dependencies {
  implementation "androidx.work:work-runtime:2.4.0-SNAPSHOT"
}

ey...@gmail.com <ey...@gmail.com> #27Feb 2, 2020 01:40AM

Got this on the snapshot. Almost 1,000 in the past 24 hours.

Fatal Exception: java.lang.IllegalStateException: Not allowed to start service Intent { act=ACTION_STOP_FOREGROUND cmp=com.myapp/androidx.work.impl.foreground.SystemForegroundService }: app is in background uid UidRecord{c03e72d u0a293 CEM bg:+15m4s172ms idle change:cached procs:1 proclist:3231, seq(0,0,0)} at android.app.ContextImpl.startServiceCommon(ContextImpl.java:1666) at android.app.ContextImpl.startService(ContextImpl.java:1611) at android.content.ContextWrapper.startService(ContextWrapper.java:677) at androidx.work.impl.Processor.stopForegroundService(Processor.java:303) at androidx.work.impl.Processor.stopForeground(Processor.java:221) at androidx.work.impl.WorkerWrapper.resolve(WorkerWrapper.java:453) at androidx.work.impl.WorkerWrapper.rescheduleAndResolve(WorkerWrapper.java:546) at androidx.work.impl.WorkerWrapper.onWorkFinished(WorkerWrapper.java:348) at androidx.work.impl.WorkerWrapper$2.run(WorkerWrapper.java:318) at androidx.work.impl.utils.SerialExecutor$Task.run(SerialExecutor.java:91) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.lang.Thread.run(Thread.java:764)

ra...@google.com <ra...@google.com> #28Feb 3, 2020 04:59PM

Can you reproduce this locally at all ?

I am going to need a lot more information, to figure out what might be going on.

ey...@gmail.com <ey...@gmail.com> #29Feb 3, 2020 06:26PM

I haven't seen it once locally. Any ideas on what I can try to do to get it to happen?

My use case is setting a recurring work that goes off every hour, and retrieves a location, and uploads it to a server. If the response is a 401 then I cancel the worker. I've tested all those scenarios multiple times.

ra...@google.com <ra...@google.com> #30Feb 3, 2020 06:50PM

I am not exactly sure. While there is nothing wrong with your approach; rather than structure your work as a PeriodicWorkRequest you might want to try doing something like:

Enqueue a OneTimeWorkRequest which can do one of:

Enqueue a copy of the same work request with an initialDelay of your period if you get a response that is not an HTTP 401.
No-op if you get an HTTP 401.

That might be a much simpler way of managing this.

ey...@gmail.com <ey...@gmail.com> #31Feb 5, 2020 06:37PM

Unfortunately we had to unpublish the app today, so I can't test anything further. But it seems like this bug is not fixed, at least in the 2.4.0-SNAPSHOT build.

ra...@google.com <ra...@google.com> #32Feb 5, 2020 06:53PM

I made another change: https://android-review.googlesource.com/c/platform/frameworks/support/+/1226295

It should land soon. Unfortunately won't be in the 2.3.1 release. This is not strictly necessary from an API perspective, but anecdotally this seems to be required for some OEMs.

ey...@gmail.com <ey...@gmail.com> #33Feb 5, 2020 07:53PM

This may also be relevant if you haven't seen it - https://issuetracker.google.com/issues/76112072

Basically if you start a foreground service you must call startForeground or the app will crash. If you stop the service before startForeground is called then the app will still crash.

ra...@google.com <ra...@google.com> #34Feb 5, 2020 08:09PM

That part, is clear.

There is anecdotal evidence that a popular OEM requires you to call startForeground() as part of the first onStartCommand() callback when using ContextCompat.startForeground(...).

ey...@gmail.com <ey...@gmail.com> #35Feb 5, 2020 08:46PM

I have had similar issues with that OEM in another app, even though I call startForeground in onCreate and in every onStartCommand...

da...@gmail.com <da...@gmail.com> #36Feb 5, 2020 10:10PM

This might be a stupid question...

We receive the crash in Crashlytics.

But does the user actually notice the bug? A popup saying the app crashed out of nowhere?

And does the crash affects in any way the rescheduling of the periodic work or the app functionality? How?

Bonus: is there something that us, as developers, can do in our apps to help you debug the issue? Even if it requires a snapshot version with some kind of logging + non-fatal exception sent to Crashlytics just before the startService that cause the crash, just to help you debug.

ra...@google.com <ra...@google.com> #37Feb 5, 2020 10:18PM

The good news is the user won't see this at all (its a background crash).
No, it does not affect the app in any meaningful way. Because WorkManager has its own source of truth. Also, in this particular case your app process crashed while we were asking the foreground Service to stop. Presumably, everything that the app wanted to do was already completed.

For being able to provide more information - what is really useful to us for cases like this which is hard to reproduce is WorkManagers internal logs. You can override the Logger used by WorkManager by using: https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:work/workmanager/src/main/java/androidx/work/Logger.java;l=44

This is a @Restricted API, however you can @Suppress it. We might have a better API going forward, but it should be easy for you to change (if we do something i.e.)

ra...@google.com <ra...@google.com> #38Feb 7, 2020 03:41PM

We made more changes to obviate the need for the ACTION_STOP_FOREGROUND intent itself. So you want to give this a go, you can try using:

repositories {
    google()
    maven { url 'https://ci.android.com/builds/submitted/6188671/androidx_snapshot/latest/repository/' }
}

dependencies {
  implementation "androidx.work:work-runtime:2.4.0-SNAPSHOT"
}

ra...@google.com <ra...@google.com> #39Feb 19, 2020 01:26AM

My apologies, it looks like the artifacts were not generated for that build. I have verified that this one works:

https://ci.android.com/builds/submitted/6217200/androidx_snapshot/latest/repository/

repositories {
    google()
    maven { url 'https://ci.android.com/builds/submitted/6217200/androidx_snapshot/latest/repository/' }
}

dependencies {
  implementation "androidx.work:work-runtime:2.4.0-SNAPSHOT"
}

ha...@gmail.com <ha...@gmail.com> #40Feb 24, 2020 09:26AM

Can someone confirm that it's now fixed with 2.4.0? When will this release be available in the stable channel?.

This issue here is marked as "fixed" so it should be working now?!

ra...@google.com <ra...@google.com> #41Feb 24, 2020 05:08PM

The fix also landed in version 2.3.2.

pa...@gmail.com <pa...@gmail.com> #42Oct 25, 2022 08:48AM

I am using workManager v2.7.1 and I am seeing this error locally and really often when I started to use

setForegroundAsync(foregroundInfo) because of android 12 restrictions on foreground services.

Unable to stop foreground service android.app.BackgroundServiceStartNotAllowedException: Not allowed to start service Intent { act=ACTION_STOP_FOREGROUND cmp=com.xx.xx/androidx.work.impl.foreground.SystemForegroundService }: app is in background uid UidRecord{3b1d726 u0a271 LAST bg:+2m45s924ms idle change:idle|procstate procs:0 seq(2348929,2348732)} at android.app.ContextImpl.startServiceCommon(ContextImpl.java:1908) at android.app.ContextImpl.startService(ContextImpl.java:1864) at android.content.ContextWrapper.startService(ContextWrapper.java:817) at androidx.work.impl.Processor.stopForegroundService(Processor.java:318) at androidx.work.impl.Processor.stopForeground(Processor.java:224) at androidx.work.impl.WorkerWrapper.resolve(WorkerWrapper.java:460) at androidx.work.impl.WorkerWrapper.resetPeriodicAndResolve(WorkerWrapper.java:571) at androidx.work.impl.WorkerWrapper.handleResult(WorkerWrapper.java:475) at androidx.work.impl.WorkerWrapper.onWorkFinished(WorkerWrapper.java:354) at androidx.work.impl.WorkerWrapper$2.run(WorkerWrapper.java:331) at androidx.work.impl.utils.SerialExecutor$Task.run(SerialExecutor.java:91) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1137) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637) at java.lang.Thread.run(Thread.java:1012)

Message last modified on Oct 25, 2022 09:05AM

ha...@gmail.com <ha...@gmail.com> #43Mar 30, 2023 10:02AM

i am too impacted with the same exception. My job is one time request which completes successfully, however in the end this exception is thrown no idea why, note that i am executing setForegroundAsync right at the beginning of doWork Method

he...@gmail.com <he...@gmail.com> #44May 3, 2023 07:01PM

Also getting the same error from doWork expedited CoroutineWorker method if App in background.

Unable to stop foreground service
android.app.BackgroundServiceStartNotAllowedException: Not allowed to start service Intent { act=ACTION_STOP_FOREGROUND cmp=com.example.example/androidx.work.impl.foreground.SystemForegroundService }: app is in background uid UidRecord{1248515 u0a294 TRNB bg:+1m39s883ms idle change:uncached procs:0 seq(0,0,0)}
                                                                                                    	at android.app.ContextImpl.startServiceCommon(ContextImpl.java:1862)
                                                                                                    	at android.app.ContextImpl.startService(ContextImpl.java:1818)
                                                                                                    	at android.content.ContextWrapper.startService(ContextWrapper.java:776)
                                                                                                    	at androidx.work.impl.Processor.stopForegroundService(Processor.java:318)
                                                                                                    	at androidx.work.impl.Processor.stopForeground(Processor.java:224)
                                                                                                    	at androidx.work.impl.WorkerWrapper.resolve(WorkerWrapper.java:460)
                                                                                                    	at androidx.work.impl.WorkerWrapper.setSucceededAndResolve(WorkerWrapper.java:600)
                                                                                                    	at androidx.work.impl.WorkerWrapper.handleResult(WorkerWrapper.java:477)
                                                                                                    	at androidx.work.impl.WorkerWrapper.onWorkFinished(WorkerWrapper.java:354)
                                                                                                    	at androidx.work.impl.WorkerWrapper$2.run(WorkerWrapper.java:331)
                                                                                                    	at androidx.work.impl.utils.SerialExecutor$Task.run(SerialExecutor.java:91)

Only service is setForeground method using:

if (Build.VERSION.SDK_INT > Build.VERSION_CODES.R) {
                setForegroundAsync(createForegroundInfo())
        } else setForeground(createForegroundInfo())

doWork is uploading Room data and images.

Message last modified on May 3, 2023 07:10PM