Android 9.0: Not allowed to start service: app is in background.. after onResume()
up vote
27
down vote
favorite
I've got a music player which attempts to start a Service
in onResume()
of an Activity
. I've removed a few lines for clarity, but the code is effectively:
@Override
protected void onResume() {
super.onResume();
startService(new Intent(this, MusicService.class));
}
According to the crash logs, this is throwing an Exception on some devices running Android P:
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)
How is it possible that my app is in the background, immediately after onResume()
(and super.onResume()
) is called?
This doesn't make any sense to me. Could this be a platform bug? All 162 users affected by this crash are on Android P.
android android-service android-9.0-pie
|
show 11 more comments
up vote
27
down vote
favorite
I've got a music player which attempts to start a Service
in onResume()
of an Activity
. I've removed a few lines for clarity, but the code is effectively:
@Override
protected void onResume() {
super.onResume();
startService(new Intent(this, MusicService.class));
}
According to the crash logs, this is throwing an Exception on some devices running Android P:
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)
How is it possible that my app is in the background, immediately after onResume()
(and super.onResume()
) is called?
This doesn't make any sense to me. Could this be a platform bug? All 162 users affected by this crash are on Android P.
android android-service android-9.0-pie
5
I don't have a good answer for you but I can confirm we're seeing this as well. We've never reproduced it in-house, but similarly we're seeing it when starting the service in onResume(). I suspect this is a bug in Android P.
– kcoppock
Aug 25 at 2:51
4
OK, glad it's not just me. This issue has been reported: issuetracker.google.com/issues/113122354
– Tim Malseed
Aug 25 at 2:59
try in manifiest add process name in service tag
– Ashvin solanki
Aug 25 at 5:03
I have 3 very popular apps with the same problem. It occurs only on Android P (Pixels and Essential Phone). I hope thats a bug that will be fixed.
– Mateusz Kaflowski
Aug 29 at 10:46
2
Also, Apps that target Android 9 or higher and use foreground services must request the FOREGROUND_SERVICE permission. This is a normal permission, so the system automatically grants it to the requesting app. From developer.android.com/about/versions/pie/android-9.0-changes-28
– Access Denied
Oct 8 at 9:13
|
show 11 more comments
up vote
27
down vote
favorite
up vote
27
down vote
favorite
I've got a music player which attempts to start a Service
in onResume()
of an Activity
. I've removed a few lines for clarity, but the code is effectively:
@Override
protected void onResume() {
super.onResume();
startService(new Intent(this, MusicService.class));
}
According to the crash logs, this is throwing an Exception on some devices running Android P:
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)
How is it possible that my app is in the background, immediately after onResume()
(and super.onResume()
) is called?
This doesn't make any sense to me. Could this be a platform bug? All 162 users affected by this crash are on Android P.
android android-service android-9.0-pie
I've got a music player which attempts to start a Service
in onResume()
of an Activity
. I've removed a few lines for clarity, but the code is effectively:
@Override
protected void onResume() {
super.onResume();
startService(new Intent(this, MusicService.class));
}
According to the crash logs, this is throwing an Exception on some devices running Android P:
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)
How is it possible that my app is in the background, immediately after onResume()
(and super.onResume()
) is called?
This doesn't make any sense to me. Could this be a platform bug? All 162 users affected by this crash are on Android P.
android android-service android-9.0-pie
android android-service android-9.0-pie
edited Oct 30 at 23:31
asked Aug 25 at 2:29
Tim Malseed
3,30633153
3,30633153
5
I don't have a good answer for you but I can confirm we're seeing this as well. We've never reproduced it in-house, but similarly we're seeing it when starting the service in onResume(). I suspect this is a bug in Android P.
– kcoppock
Aug 25 at 2:51
4
OK, glad it's not just me. This issue has been reported: issuetracker.google.com/issues/113122354
– Tim Malseed
Aug 25 at 2:59
try in manifiest add process name in service tag
– Ashvin solanki
Aug 25 at 5:03
I have 3 very popular apps with the same problem. It occurs only on Android P (Pixels and Essential Phone). I hope thats a bug that will be fixed.
– Mateusz Kaflowski
Aug 29 at 10:46
2
Also, Apps that target Android 9 or higher and use foreground services must request the FOREGROUND_SERVICE permission. This is a normal permission, so the system automatically grants it to the requesting app. From developer.android.com/about/versions/pie/android-9.0-changes-28
– Access Denied
Oct 8 at 9:13
|
show 11 more comments
5
I don't have a good answer for you but I can confirm we're seeing this as well. We've never reproduced it in-house, but similarly we're seeing it when starting the service in onResume(). I suspect this is a bug in Android P.
– kcoppock
Aug 25 at 2:51
4
OK, glad it's not just me. This issue has been reported: issuetracker.google.com/issues/113122354
– Tim Malseed
Aug 25 at 2:59
try in manifiest add process name in service tag
– Ashvin solanki
Aug 25 at 5:03
I have 3 very popular apps with the same problem. It occurs only on Android P (Pixels and Essential Phone). I hope thats a bug that will be fixed.
– Mateusz Kaflowski
Aug 29 at 10:46
2
Also, Apps that target Android 9 or higher and use foreground services must request the FOREGROUND_SERVICE permission. This is a normal permission, so the system automatically grants it to the requesting app. From developer.android.com/about/versions/pie/android-9.0-changes-28
– Access Denied
Oct 8 at 9:13
5
5
I don't have a good answer for you but I can confirm we're seeing this as well. We've never reproduced it in-house, but similarly we're seeing it when starting the service in onResume(). I suspect this is a bug in Android P.
– kcoppock
Aug 25 at 2:51
I don't have a good answer for you but I can confirm we're seeing this as well. We've never reproduced it in-house, but similarly we're seeing it when starting the service in onResume(). I suspect this is a bug in Android P.
– kcoppock
Aug 25 at 2:51
4
4
OK, glad it's not just me. This issue has been reported: issuetracker.google.com/issues/113122354
– Tim Malseed
Aug 25 at 2:59
OK, glad it's not just me. This issue has been reported: issuetracker.google.com/issues/113122354
– Tim Malseed
Aug 25 at 2:59
try in manifiest add process name in service tag
– Ashvin solanki
Aug 25 at 5:03
try in manifiest add process name in service tag
– Ashvin solanki
Aug 25 at 5:03
I have 3 very popular apps with the same problem. It occurs only on Android P (Pixels and Essential Phone). I hope thats a bug that will be fixed.
– Mateusz Kaflowski
Aug 29 at 10:46
I have 3 very popular apps with the same problem. It occurs only on Android P (Pixels and Essential Phone). I hope thats a bug that will be fixed.
– Mateusz Kaflowski
Aug 29 at 10:46
2
2
Also, Apps that target Android 9 or higher and use foreground services must request the FOREGROUND_SERVICE permission. This is a normal permission, so the system automatically grants it to the requesting app. From developer.android.com/about/versions/pie/android-9.0-changes-28
– Access Denied
Oct 8 at 9:13
Also, Apps that target Android 9 or higher and use foreground services must request the FOREGROUND_SERVICE permission. This is a normal permission, so the system automatically grants it to the requesting app. From developer.android.com/about/versions/pie/android-9.0-changes-28
– Access Denied
Oct 8 at 9:13
|
show 11 more comments
3 Answers
3
active
oldest
votes
up vote
0
down vote
We're testing this out right now which so far seems to be working. Will update as we see more results
class ResumingServiceManager(val lifecycle: Lifecycle) : LifecycleObserver {
init {
lifecycle.addObserver(this)
}
val disposable: CompositeDisposable = CompositeDisposable()
fun startService(context: Context, intent: Intent) {
if (Build.VERSION.SDK_INT < Build.VERSION_CODES.O) {
context.startService(intent)
} else {
Single.just(true)
.delaySubscription(300, TimeUnit.MILLISECONDS)
.subscribeOn(AndroidSchedulers.mainThread())
.observeOn(AndroidSchedulers.mainThread())
.subscribeBy(
onSuccess = {
context.startService(intent)
}
).addTo(disposable)
}
}
@OnLifecycleEvent(Lifecycle.Event.ON_STOP)
fun stopped() {
disposable.clear()
}
@OnLifecycleEvent(Lifecycle.Event.ON_DESTROY)
fun destroy() {
lifecycle.removeObserver(this)
}
}
In onCreate()
initialize it and then anytime you want to start a service in onResume just call resumingServiceManager.startService(this, intent)
It's lifecycle aware so it will clear the disposable if it pauses cancelling the onSuccess from triggering when it might be on the way to the background with an immediate open/close.
add a comment |
up vote
-1
down vote
use
startForegroundService(intent);
instead of
startService(intent);
try this it should work
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
context.startForegroundService(intent);
} else {
context.startService(intent);
}
and in onCreate() method of your service:
startForeground(1,new Notification());
hope it work for you
1
Thanks Reza. Unfortunately this is not the correct solution. The question is about starting a service when the app is already in the foreground, in which case you do not need to callstartForegroundService()
– Tim Malseed
Nov 9 at 0:07
@Tim Malseed Sorry about that. I had the same problem by post N devices and the only solution that worked for me was this. By the way, let us know if you fix this, please. Thanks.
– Reza
Nov 9 at 7:16
add a comment |
up vote
-2
down vote
Maybe android.arch.lifecycle could be used as a workaround for this Android 9 bug?
public class MyActivity extends Activity implements LifecycleObserver {
protected void onResume() {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
if (ProcessLifecycleOwner.get().getLifecycle().getCurrentState().isAtLeast(Lifecycle.State.RESUMED)) {
startService(intent);
} else {
ProcessLifecycleOwner.get().getLifecycle().addObserver(this);
}
} else {
startService(intent);
}
}
@OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
void onEnterForeground() {
startService(intent);
ProcessLifecycleOwner.get().getLifecycle().removeObserver(this);
}
}
I've found it here.
The lifecycle observer is just responding to events triggered by the activity. So this all really amounts to just moving thestartService()
call toonStart()
. As you say though, this might be a handy workaround.
– Tim Malseed
Oct 21 at 23:36
Unfortunately I am seeing the same exception withLifecycle.State.STARTED
. I am going to tryLifecycle.State.RESUMED
and@OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
which is called afteronResume()
and see if that fixes the issue.
– MarcinLe
Oct 22 at 18:05
Thanks for sharing this workaround. Did you have any positive results when using Lifecycle.State.RESUMED and @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)?
– Renso Lohuis
Oct 29 at 10:47
I updated my app to use State.RESUMED. For a few days it was working fine, so I hoped this solves the issue, but I have just noticed another crash on android 9 again :(
– MarcinLe
Oct 30 at 11:41
Yeah, not surprised at all. Again, Arch Lifecycle events are just triggered by the lifecycle events of the underlying Fragment/Activity, so this is no different to just moving thestartService
call intoonStart()
oronResume()
or wherever, unless you account for very minuscule timing delays. Sounds like moving the call toonStart()
is not a workaround.
– Tim Malseed
Oct 30 at 23:26
add a comment |
protected by Community♦ Nov 8 at 14:05
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
We're testing this out right now which so far seems to be working. Will update as we see more results
class ResumingServiceManager(val lifecycle: Lifecycle) : LifecycleObserver {
init {
lifecycle.addObserver(this)
}
val disposable: CompositeDisposable = CompositeDisposable()
fun startService(context: Context, intent: Intent) {
if (Build.VERSION.SDK_INT < Build.VERSION_CODES.O) {
context.startService(intent)
} else {
Single.just(true)
.delaySubscription(300, TimeUnit.MILLISECONDS)
.subscribeOn(AndroidSchedulers.mainThread())
.observeOn(AndroidSchedulers.mainThread())
.subscribeBy(
onSuccess = {
context.startService(intent)
}
).addTo(disposable)
}
}
@OnLifecycleEvent(Lifecycle.Event.ON_STOP)
fun stopped() {
disposable.clear()
}
@OnLifecycleEvent(Lifecycle.Event.ON_DESTROY)
fun destroy() {
lifecycle.removeObserver(this)
}
}
In onCreate()
initialize it and then anytime you want to start a service in onResume just call resumingServiceManager.startService(this, intent)
It's lifecycle aware so it will clear the disposable if it pauses cancelling the onSuccess from triggering when it might be on the way to the background with an immediate open/close.
add a comment |
up vote
0
down vote
We're testing this out right now which so far seems to be working. Will update as we see more results
class ResumingServiceManager(val lifecycle: Lifecycle) : LifecycleObserver {
init {
lifecycle.addObserver(this)
}
val disposable: CompositeDisposable = CompositeDisposable()
fun startService(context: Context, intent: Intent) {
if (Build.VERSION.SDK_INT < Build.VERSION_CODES.O) {
context.startService(intent)
} else {
Single.just(true)
.delaySubscription(300, TimeUnit.MILLISECONDS)
.subscribeOn(AndroidSchedulers.mainThread())
.observeOn(AndroidSchedulers.mainThread())
.subscribeBy(
onSuccess = {
context.startService(intent)
}
).addTo(disposable)
}
}
@OnLifecycleEvent(Lifecycle.Event.ON_STOP)
fun stopped() {
disposable.clear()
}
@OnLifecycleEvent(Lifecycle.Event.ON_DESTROY)
fun destroy() {
lifecycle.removeObserver(this)
}
}
In onCreate()
initialize it and then anytime you want to start a service in onResume just call resumingServiceManager.startService(this, intent)
It's lifecycle aware so it will clear the disposable if it pauses cancelling the onSuccess from triggering when it might be on the way to the background with an immediate open/close.
add a comment |
up vote
0
down vote
up vote
0
down vote
We're testing this out right now which so far seems to be working. Will update as we see more results
class ResumingServiceManager(val lifecycle: Lifecycle) : LifecycleObserver {
init {
lifecycle.addObserver(this)
}
val disposable: CompositeDisposable = CompositeDisposable()
fun startService(context: Context, intent: Intent) {
if (Build.VERSION.SDK_INT < Build.VERSION_CODES.O) {
context.startService(intent)
} else {
Single.just(true)
.delaySubscription(300, TimeUnit.MILLISECONDS)
.subscribeOn(AndroidSchedulers.mainThread())
.observeOn(AndroidSchedulers.mainThread())
.subscribeBy(
onSuccess = {
context.startService(intent)
}
).addTo(disposable)
}
}
@OnLifecycleEvent(Lifecycle.Event.ON_STOP)
fun stopped() {
disposable.clear()
}
@OnLifecycleEvent(Lifecycle.Event.ON_DESTROY)
fun destroy() {
lifecycle.removeObserver(this)
}
}
In onCreate()
initialize it and then anytime you want to start a service in onResume just call resumingServiceManager.startService(this, intent)
It's lifecycle aware so it will clear the disposable if it pauses cancelling the onSuccess from triggering when it might be on the way to the background with an immediate open/close.
We're testing this out right now which so far seems to be working. Will update as we see more results
class ResumingServiceManager(val lifecycle: Lifecycle) : LifecycleObserver {
init {
lifecycle.addObserver(this)
}
val disposable: CompositeDisposable = CompositeDisposable()
fun startService(context: Context, intent: Intent) {
if (Build.VERSION.SDK_INT < Build.VERSION_CODES.O) {
context.startService(intent)
} else {
Single.just(true)
.delaySubscription(300, TimeUnit.MILLISECONDS)
.subscribeOn(AndroidSchedulers.mainThread())
.observeOn(AndroidSchedulers.mainThread())
.subscribeBy(
onSuccess = {
context.startService(intent)
}
).addTo(disposable)
}
}
@OnLifecycleEvent(Lifecycle.Event.ON_STOP)
fun stopped() {
disposable.clear()
}
@OnLifecycleEvent(Lifecycle.Event.ON_DESTROY)
fun destroy() {
lifecycle.removeObserver(this)
}
}
In onCreate()
initialize it and then anytime you want to start a service in onResume just call resumingServiceManager.startService(this, intent)
It's lifecycle aware so it will clear the disposable if it pauses cancelling the onSuccess from triggering when it might be on the way to the background with an immediate open/close.
edited Nov 21 at 17:23
answered Nov 10 at 0:49
Ben987654
660520
660520
add a comment |
add a comment |
up vote
-1
down vote
use
startForegroundService(intent);
instead of
startService(intent);
try this it should work
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
context.startForegroundService(intent);
} else {
context.startService(intent);
}
and in onCreate() method of your service:
startForeground(1,new Notification());
hope it work for you
1
Thanks Reza. Unfortunately this is not the correct solution. The question is about starting a service when the app is already in the foreground, in which case you do not need to callstartForegroundService()
– Tim Malseed
Nov 9 at 0:07
@Tim Malseed Sorry about that. I had the same problem by post N devices and the only solution that worked for me was this. By the way, let us know if you fix this, please. Thanks.
– Reza
Nov 9 at 7:16
add a comment |
up vote
-1
down vote
use
startForegroundService(intent);
instead of
startService(intent);
try this it should work
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
context.startForegroundService(intent);
} else {
context.startService(intent);
}
and in onCreate() method of your service:
startForeground(1,new Notification());
hope it work for you
1
Thanks Reza. Unfortunately this is not the correct solution. The question is about starting a service when the app is already in the foreground, in which case you do not need to callstartForegroundService()
– Tim Malseed
Nov 9 at 0:07
@Tim Malseed Sorry about that. I had the same problem by post N devices and the only solution that worked for me was this. By the way, let us know if you fix this, please. Thanks.
– Reza
Nov 9 at 7:16
add a comment |
up vote
-1
down vote
up vote
-1
down vote
use
startForegroundService(intent);
instead of
startService(intent);
try this it should work
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
context.startForegroundService(intent);
} else {
context.startService(intent);
}
and in onCreate() method of your service:
startForeground(1,new Notification());
hope it work for you
use
startForegroundService(intent);
instead of
startService(intent);
try this it should work
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
context.startForegroundService(intent);
} else {
context.startService(intent);
}
and in onCreate() method of your service:
startForeground(1,new Notification());
hope it work for you
edited Nov 8 at 12:55
answered Nov 8 at 12:48
Reza
6417
6417
1
Thanks Reza. Unfortunately this is not the correct solution. The question is about starting a service when the app is already in the foreground, in which case you do not need to callstartForegroundService()
– Tim Malseed
Nov 9 at 0:07
@Tim Malseed Sorry about that. I had the same problem by post N devices and the only solution that worked for me was this. By the way, let us know if you fix this, please. Thanks.
– Reza
Nov 9 at 7:16
add a comment |
1
Thanks Reza. Unfortunately this is not the correct solution. The question is about starting a service when the app is already in the foreground, in which case you do not need to callstartForegroundService()
– Tim Malseed
Nov 9 at 0:07
@Tim Malseed Sorry about that. I had the same problem by post N devices and the only solution that worked for me was this. By the way, let us know if you fix this, please. Thanks.
– Reza
Nov 9 at 7:16
1
1
Thanks Reza. Unfortunately this is not the correct solution. The question is about starting a service when the app is already in the foreground, in which case you do not need to call
startForegroundService()
– Tim Malseed
Nov 9 at 0:07
Thanks Reza. Unfortunately this is not the correct solution. The question is about starting a service when the app is already in the foreground, in which case you do not need to call
startForegroundService()
– Tim Malseed
Nov 9 at 0:07
@Tim Malseed Sorry about that. I had the same problem by post N devices and the only solution that worked for me was this. By the way, let us know if you fix this, please. Thanks.
– Reza
Nov 9 at 7:16
@Tim Malseed Sorry about that. I had the same problem by post N devices and the only solution that worked for me was this. By the way, let us know if you fix this, please. Thanks.
– Reza
Nov 9 at 7:16
add a comment |
up vote
-2
down vote
Maybe android.arch.lifecycle could be used as a workaround for this Android 9 bug?
public class MyActivity extends Activity implements LifecycleObserver {
protected void onResume() {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
if (ProcessLifecycleOwner.get().getLifecycle().getCurrentState().isAtLeast(Lifecycle.State.RESUMED)) {
startService(intent);
} else {
ProcessLifecycleOwner.get().getLifecycle().addObserver(this);
}
} else {
startService(intent);
}
}
@OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
void onEnterForeground() {
startService(intent);
ProcessLifecycleOwner.get().getLifecycle().removeObserver(this);
}
}
I've found it here.
The lifecycle observer is just responding to events triggered by the activity. So this all really amounts to just moving thestartService()
call toonStart()
. As you say though, this might be a handy workaround.
– Tim Malseed
Oct 21 at 23:36
Unfortunately I am seeing the same exception withLifecycle.State.STARTED
. I am going to tryLifecycle.State.RESUMED
and@OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
which is called afteronResume()
and see if that fixes the issue.
– MarcinLe
Oct 22 at 18:05
Thanks for sharing this workaround. Did you have any positive results when using Lifecycle.State.RESUMED and @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)?
– Renso Lohuis
Oct 29 at 10:47
I updated my app to use State.RESUMED. For a few days it was working fine, so I hoped this solves the issue, but I have just noticed another crash on android 9 again :(
– MarcinLe
Oct 30 at 11:41
Yeah, not surprised at all. Again, Arch Lifecycle events are just triggered by the lifecycle events of the underlying Fragment/Activity, so this is no different to just moving thestartService
call intoonStart()
oronResume()
or wherever, unless you account for very minuscule timing delays. Sounds like moving the call toonStart()
is not a workaround.
– Tim Malseed
Oct 30 at 23:26
add a comment |
up vote
-2
down vote
Maybe android.arch.lifecycle could be used as a workaround for this Android 9 bug?
public class MyActivity extends Activity implements LifecycleObserver {
protected void onResume() {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
if (ProcessLifecycleOwner.get().getLifecycle().getCurrentState().isAtLeast(Lifecycle.State.RESUMED)) {
startService(intent);
} else {
ProcessLifecycleOwner.get().getLifecycle().addObserver(this);
}
} else {
startService(intent);
}
}
@OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
void onEnterForeground() {
startService(intent);
ProcessLifecycleOwner.get().getLifecycle().removeObserver(this);
}
}
I've found it here.
The lifecycle observer is just responding to events triggered by the activity. So this all really amounts to just moving thestartService()
call toonStart()
. As you say though, this might be a handy workaround.
– Tim Malseed
Oct 21 at 23:36
Unfortunately I am seeing the same exception withLifecycle.State.STARTED
. I am going to tryLifecycle.State.RESUMED
and@OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
which is called afteronResume()
and see if that fixes the issue.
– MarcinLe
Oct 22 at 18:05
Thanks for sharing this workaround. Did you have any positive results when using Lifecycle.State.RESUMED and @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)?
– Renso Lohuis
Oct 29 at 10:47
I updated my app to use State.RESUMED. For a few days it was working fine, so I hoped this solves the issue, but I have just noticed another crash on android 9 again :(
– MarcinLe
Oct 30 at 11:41
Yeah, not surprised at all. Again, Arch Lifecycle events are just triggered by the lifecycle events of the underlying Fragment/Activity, so this is no different to just moving thestartService
call intoonStart()
oronResume()
or wherever, unless you account for very minuscule timing delays. Sounds like moving the call toonStart()
is not a workaround.
– Tim Malseed
Oct 30 at 23:26
add a comment |
up vote
-2
down vote
up vote
-2
down vote
Maybe android.arch.lifecycle could be used as a workaround for this Android 9 bug?
public class MyActivity extends Activity implements LifecycleObserver {
protected void onResume() {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
if (ProcessLifecycleOwner.get().getLifecycle().getCurrentState().isAtLeast(Lifecycle.State.RESUMED)) {
startService(intent);
} else {
ProcessLifecycleOwner.get().getLifecycle().addObserver(this);
}
} else {
startService(intent);
}
}
@OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
void onEnterForeground() {
startService(intent);
ProcessLifecycleOwner.get().getLifecycle().removeObserver(this);
}
}
I've found it here.
Maybe android.arch.lifecycle could be used as a workaround for this Android 9 bug?
public class MyActivity extends Activity implements LifecycleObserver {
protected void onResume() {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
if (ProcessLifecycleOwner.get().getLifecycle().getCurrentState().isAtLeast(Lifecycle.State.RESUMED)) {
startService(intent);
} else {
ProcessLifecycleOwner.get().getLifecycle().addObserver(this);
}
} else {
startService(intent);
}
}
@OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
void onEnterForeground() {
startService(intent);
ProcessLifecycleOwner.get().getLifecycle().removeObserver(this);
}
}
I've found it here.
edited Oct 30 at 11:31
Community♦
11
11
answered Oct 20 at 17:54
MarcinLe
15216
15216
The lifecycle observer is just responding to events triggered by the activity. So this all really amounts to just moving thestartService()
call toonStart()
. As you say though, this might be a handy workaround.
– Tim Malseed
Oct 21 at 23:36
Unfortunately I am seeing the same exception withLifecycle.State.STARTED
. I am going to tryLifecycle.State.RESUMED
and@OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
which is called afteronResume()
and see if that fixes the issue.
– MarcinLe
Oct 22 at 18:05
Thanks for sharing this workaround. Did you have any positive results when using Lifecycle.State.RESUMED and @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)?
– Renso Lohuis
Oct 29 at 10:47
I updated my app to use State.RESUMED. For a few days it was working fine, so I hoped this solves the issue, but I have just noticed another crash on android 9 again :(
– MarcinLe
Oct 30 at 11:41
Yeah, not surprised at all. Again, Arch Lifecycle events are just triggered by the lifecycle events of the underlying Fragment/Activity, so this is no different to just moving thestartService
call intoonStart()
oronResume()
or wherever, unless you account for very minuscule timing delays. Sounds like moving the call toonStart()
is not a workaround.
– Tim Malseed
Oct 30 at 23:26
add a comment |
The lifecycle observer is just responding to events triggered by the activity. So this all really amounts to just moving thestartService()
call toonStart()
. As you say though, this might be a handy workaround.
– Tim Malseed
Oct 21 at 23:36
Unfortunately I am seeing the same exception withLifecycle.State.STARTED
. I am going to tryLifecycle.State.RESUMED
and@OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
which is called afteronResume()
and see if that fixes the issue.
– MarcinLe
Oct 22 at 18:05
Thanks for sharing this workaround. Did you have any positive results when using Lifecycle.State.RESUMED and @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)?
– Renso Lohuis
Oct 29 at 10:47
I updated my app to use State.RESUMED. For a few days it was working fine, so I hoped this solves the issue, but I have just noticed another crash on android 9 again :(
– MarcinLe
Oct 30 at 11:41
Yeah, not surprised at all. Again, Arch Lifecycle events are just triggered by the lifecycle events of the underlying Fragment/Activity, so this is no different to just moving thestartService
call intoonStart()
oronResume()
or wherever, unless you account for very minuscule timing delays. Sounds like moving the call toonStart()
is not a workaround.
– Tim Malseed
Oct 30 at 23:26
The lifecycle observer is just responding to events triggered by the activity. So this all really amounts to just moving the
startService()
call to onStart()
. As you say though, this might be a handy workaround.– Tim Malseed
Oct 21 at 23:36
The lifecycle observer is just responding to events triggered by the activity. So this all really amounts to just moving the
startService()
call to onStart()
. As you say though, this might be a handy workaround.– Tim Malseed
Oct 21 at 23:36
Unfortunately I am seeing the same exception with
Lifecycle.State.STARTED
. I am going to try Lifecycle.State.RESUMED
and @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
which is called after onResume()
and see if that fixes the issue.– MarcinLe
Oct 22 at 18:05
Unfortunately I am seeing the same exception with
Lifecycle.State.STARTED
. I am going to try Lifecycle.State.RESUMED
and @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
which is called after onResume()
and see if that fixes the issue.– MarcinLe
Oct 22 at 18:05
Thanks for sharing this workaround. Did you have any positive results when using Lifecycle.State.RESUMED and @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)?
– Renso Lohuis
Oct 29 at 10:47
Thanks for sharing this workaround. Did you have any positive results when using Lifecycle.State.RESUMED and @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)?
– Renso Lohuis
Oct 29 at 10:47
I updated my app to use State.RESUMED. For a few days it was working fine, so I hoped this solves the issue, but I have just noticed another crash on android 9 again :(
– MarcinLe
Oct 30 at 11:41
I updated my app to use State.RESUMED. For a few days it was working fine, so I hoped this solves the issue, but I have just noticed another crash on android 9 again :(
– MarcinLe
Oct 30 at 11:41
Yeah, not surprised at all. Again, Arch Lifecycle events are just triggered by the lifecycle events of the underlying Fragment/Activity, so this is no different to just moving the
startService
call into onStart()
or onResume()
or wherever, unless you account for very minuscule timing delays. Sounds like moving the call to onStart()
is not a workaround.– Tim Malseed
Oct 30 at 23:26
Yeah, not surprised at all. Again, Arch Lifecycle events are just triggered by the lifecycle events of the underlying Fragment/Activity, so this is no different to just moving the
startService
call into onStart()
or onResume()
or wherever, unless you account for very minuscule timing delays. Sounds like moving the call to onStart()
is not a workaround.– Tim Malseed
Oct 30 at 23:26
add a comment |
protected by Community♦ Nov 8 at 14:05
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
5
I don't have a good answer for you but I can confirm we're seeing this as well. We've never reproduced it in-house, but similarly we're seeing it when starting the service in onResume(). I suspect this is a bug in Android P.
– kcoppock
Aug 25 at 2:51
4
OK, glad it's not just me. This issue has been reported: issuetracker.google.com/issues/113122354
– Tim Malseed
Aug 25 at 2:59
try in manifiest add process name in service tag
– Ashvin solanki
Aug 25 at 5:03
I have 3 very popular apps with the same problem. It occurs only on Android P (Pixels and Essential Phone). I hope thats a bug that will be fixed.
– Mateusz Kaflowski
Aug 29 at 10:46
2
Also, Apps that target Android 9 or higher and use foreground services must request the FOREGROUND_SERVICE permission. This is a normal permission, so the system automatically grants it to the requesting app. From developer.android.com/about/versions/pie/android-9.0-changes-28
– Access Denied
Oct 8 at 9:13