IssueTracker

I'm experiencing this same issue. I'm calling `startService()` immediately after `super.onResume()` in an Activity, and it's crashing with the same 'Not allowed to start service ... app is in background' error.

I'm assuming this is a bug, but if not - how else can we determine if the app is considered foreground/background, if not for Activity.onResume()?

Stacktrace:

Caused by java.lang.IllegalStateException: Not allowed to start service Intent { cmp=another.music.player/com.simplecity.amp_library.playback.MusicService }: app is in background uid UidRecord{6a4a9c6 u0a143 TPSL bg:+3m25s199ms idle change:cached procs:1 seq(1283,1283,1283)}
       at android.app.ContextImpl.startServiceCommon(ContextImpl.java:1577)
       at android.app.ContextImpl.startService(ContextImpl.java:1532)
       at android.content.ContextWrapper.startService(ContextWrapper.java:664)
       at android.content.ContextWrapper.startService(ContextWrapper.java:664)
       at com.simplecity.amp_library.utils.MusicServiceConnectionUtils.bindToService(SourceFile:36)
       at com.simplecity.amp_library.ui.activities.BaseActivity.bindService(SourceFile:129)
       at com.simplecity.amp_library.ui.activities.BaseActivity.onResume(SourceFile:96)
       at com.simplecity.amp_library.ui.activities.BaseCastActivity.onResume(SourceFile:50)
       at com.simplecity.amp_library.ui.activities.MainActivity.onResume(SourceFile:122)
       at android.app.Instrumentation.callActivityOnResume(Instrumentation.java:1412)
       at android.app.Activity.performResume(Activity.java:7292)
       at android.app.ActivityThread.performResumeActivity(ActivityThread.java:3776)
       at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:3816)
       at android.app.servertransaction.ResumeActivityItem.execute(ResumeActivityItem.java:51)
       at android.app.servertransaction.TransactionExecutor.executeLifecycleState(TransactionExecutor.java:145)
       at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:70)
       at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1808)
       at android.os.Handler.dispatchMessage(Handler.java:106)
       at android.os.Looper.loop(Looper.java:193)
       at android.app.ActivityThread.main(ActivityThread.java:6669)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)

Possible duplicate of https://issuetracker.google.com/issues/110237673

We have passed this to the development team and will update this issue with more information as it becomes available.

The same problem. It occurs only on Android P (only Pixels and Essential Phone).

Any new information on this? We are experiencing exactly the same thing as described here by others.

i am seeing the same issue on my App for only the pixel devices. One observation i would like to add here is that we have a log of legacy code which needs refactoring and they use "android.app.Fragment" instead of "android.support.v4.app.Fragment" and the documentation about the deprecation says "Use the Support Library Fragment for consistent behavior across all devices and access to Lifecycle."

https://developer.android.com/reference/android/app/Fragment

Can this be because of not using the support fragment?

For Sa..@gmail.com 

I'm encountering this problem in an Activity that does not use a fragment.  I'm extending AppCompatActivity so it's not that.

im having the same crash, in pixel devices and also on oneplus.
im ussing the support fragment, so is not that

I am also having this issue. I have seen it on a oneplus A6003 and a Google Pixel 2 an Google Pixel 2 XL
All running Android 9

I was able to reproduce this crash, though not with a "real user" scenario.

In our case it's our MainActivity.onResume() which calls startService().

* Force stop the app
* Turn off the device screen
* Launch the app via adb:

shell am start -n com.example.app/com.example.app.main.MainActivity

I guess this is a scenario where the app's current Activity can be in onResume() but not considered "in the foreground".

We did a fix to check that the device screen is on, before starting the service. We check PowerManager.isInteractive() ( PowerManager.isScreenOn() for <= KitKat). Unfortunately, this didn't really fix the bug for our real users, as we continue to get crash reports on Fabric. I don't know what scenario is causing this crash for them.

#4 perhaps you could consider escalating this issue? One of my apps has crashed close to 15,000 times in the last 90 days due to this error. I'm now receiving warnings from Google that my app exceeds 'bad behavior' thresholds for crashing.

We deserve to know what's being done about this issue.

For anyone who needs a fix even if it's a hack, I've essentially resolved my crash issues with this fix https://stackoverflow.com/a/53235043/2408033

I was receiving hundreds of crashes, but have only received 1 after I implemented this, so it's not a complete fix, but it's better than hundreds of crashes.

I also start facing this issue recently, for the Android Pie on production. I am starting my service in OnCreate().
Any Lead on this?

am also facing the same issue in android P, any solution for it

Starting service in onResume, getting the same crash

This crash is pretty severe. The only way to really work around this crash is to execute the startForeground call in response a direct user touch action - there seems to be no other way to really make sure the app is in the foreground, onResume and other seemingly foreground bound methods can not be relied on to be executed while the app is in the foreground state.

The issue has been addressed in future Android release.

There is a workaround to avoid application crash. Applications can get the process state in Activity.onResume() by calling ActivityManager.getRunningAppProcesses() and avoid starting Service if the importance level is lower than ActivityManager.RunningAppProcessInfo.IMPORTANCE_FOREGROUND. If the device hasn’t fully awake, activities would be paused immediately and eventually be resumed again after its fully awake.

The workaround does not sound reliable, because we are already seeing crashes in onResume. What stops system from lowering app priority between invocation of getRunningAppProcesses and startService?

@20 For some reason this was marked as duplicate of my case:
https://issuetracker.google.com/issues/110285354

Please provide a safe and easy way to do it via the support library to start a foreground service , because what you wrote now is a huge workaround that we shouldn't have to bother.
Also, it should work well with all cases of starting a service in the foreground, including from the class that extends Application. I've noticed that even on this case, an app can crash as if I " did not call Service.startForeground()"  , even though I did call it.

Can you please show how to have the workaround you've suggested? Or by marking as "fixed" , you mean that the support library handles it on next version, and that on some newer Android versions it won't happen?

I start my service in onStart instead of onResume and I still get crashes. I do not want to start the service in onResume. Whats the solution to this problem?

Someone mentioned using Handler.postDelayed will work but Can someone confirm if it fixes?

    handler.postDelayed(() -> startService(PlayerActivity.this), 300);

> Can someone confirm if it fixes?

No, this does not provide full safety against crashes. Better way is to wrap startService in try-catch and use postDelayed to retry whenever IllegalStateException gets thrown (and abort that retry in onStop).

I have 2 apps that share all lifecycle coding. The 'Serial Bluetooth Terminal' app is nearly not affected by this issue, whereas roughly 10% of all Android 9 sessions for 'Serial USB Terminal' crash.

I tried postDelayed, but this didn't reduce the crashes.

As i use bindService() and startService() the service is already up with bindService() and the next thing I will probably try is delaying the startService() until some real user interaction or latest at onPause() to prevent service destruction on device rotate

I have a music streaming app, If I do not start the service then How am I suppose to play the music? Even delaying it is not the solution I can implement.

Do you guys talk about foreground service?
If so, I also have similar issues, but rarely. Sometimes it claims "Context.startForegroundService() did not then call Service.startForeground()" .

I've had this issue a lot in the past, but now it's quite rare. So it's a workaround. Not the best because I still don't know how to completely eliminate it, but it's better than nothing.

Here it is in short:

In the class that extends Application ("App.kt" in my case), I have a global variable "isInForeground", which I update as such:

    companion object {
        @JvmField
        var isInForeground: Boolean? = null

        ProcessLifecycleOwner.get().lifecycle.addObserver(object : LifecycleObserver {
            @Suppress("unused")
            @OnLifecycleEvent(Lifecycle.Event.ON_STOP)
            fun onAppBackgrounded() {
                isInForeground = false
            }

            @Suppress("unused")
            @OnLifecycleEvent(Lifecycle.Event.ON_START)
            fun onAppForegrounded() {
                isInForeground = true
            }
        })
}

And when it's time to start the service, I use this function that I've made:

        @JvmStatic
        @TargetApi(VERSION_CODES.JELLY_BEAN)
        fun startForegroundService(context: Context, intent: Intent, isSurelyInForeground: Boolean? = null) {
            if (VERSION.SDK_INT < VERSION_CODES.O || isSurelyInForeground == true) {
//                Log.d("AppLog", "startForegroundService isSurelyInForeground:$isSurelyInForeground")
                context.startService(intent)
                return
            }
            val isInForeground = if (isSurelyInForeground != null) isSurelyInForeground
            else {
                val appProcessInfo = ActivityManager.RunningAppProcessInfo()
                ActivityManager.getMyMemoryState(appProcessInfo)
                (appProcessInfo.importance == IMPORTANCE_FOREGROUND || appProcessInfo.importance == IMPORTANCE_VISIBLE)
            }
//            Log.d("AppLog", "startForegroundService isSurelyInForeground:$isSurelyInForeground isInForeground:$isInForeground")
            if (isInForeground)
                context.startService(intent)
            else context.startForegroundService(intent)
        }

For the parameter "isSurelyInForeground" I put true only if I know it's indeed in the foreground, and if I'm not sure, I put the value of the global variable "isInForeground" .

Example:

App.startForegroundService(context,intent, App.isInForeground)

I hope this can help you a bit.
Sadly as I wrote, it's not perfect, but it should reduce a lot of crashes.

> I have a music streaming app, If I do not start the service then How am I suppose to play the music?

This bug is about IllegalStateException thrown by startService (as opposite to startForegroundService). Some people want to perform short tasks in background without barraging user with notifications, so they don't want to use startForegroundService.

If you are playing music, you should switch to startForegroundService on Oreo. Music players should use foreground Services.

@28 So the thing is that if your app is already in the foreground, you don't have to set the service in the foreground using `startForegroundService`. Use something like what I did.
Notice I call `startService` instead of `startForegroundService` in this case.

#27 Thanks for sharing your solution. I'll try it in production, observe for couple of days and see how it goes...

@30 Forgot to mention :
In both onCreate and onStartCommand of the service I make it a foreground service (using startForeground).
I think I gathered all of these tips from StackOverflow, but even there I saw that people say there are still rare crashes.

I'm still having this problem with Android 11 devices, so I don't think they actually fixed it unless they were fixing things multiple versions ahead.

@32 Sadly with all measures I've got, I also sometimes (rare, but still) get crashes from users, via Crashlytics.
Sadly I have no idea how to reproduce them.
I suggest to create a new bug report here, maybe with proof that you got those crashes (from Crashlytics)

This problem is still persistent and I followed all the documentation. How can google let such a bug persist for so long. I have the following:


void onResume()
{
         Intent metronomeIntent = new Intent(this, MetronomeService.class);
        startService(metronomeIntent);
        bindService(metronomeIntent, metronomeConnection, Context.BIND_AUTO_CREATE);
}


And this every now and then throws:

java.lang.RuntimeException: Unable to resume activity {com.mypackage.myapp/com.mypackage.myapp.MainActivity}: java.lang.IllegalStateException: Not allowed to start service Intent { cmp=com.mypackage.myapp/.services.MyService}: app is in background uid UidRecord{3eccf2e u0a453 TPSL idle procs:1 proclist:26876, seq(0,0,0)}


I've tried everything!! But it's really poor showing for the app to crash like this. I get this error on Samsung phones and SDK28, 29, 30!!!!

This becomes the crash that happens the most for our application. Appreciate it if there is a official workable solution.