Android 9.0: Not allowed to start service: app is in background.. after onResume()











up vote
27
down vote

favorite
12












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.










share|improve this question




















  • 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















up vote
27
down vote

favorite
12












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.










share|improve this question




















  • 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













up vote
27
down vote

favorite
12









up vote
27
down vote

favorite
12






12





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.










share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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














  • 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












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.






share|improve this answer






























    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






    share|improve this answer



















    • 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










    • @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




















    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.






    share|improve this answer























    • 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










    • 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 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










    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.






    share|improve this answer



























      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.






      share|improve this answer

























        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.






        share|improve this answer














        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.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Nov 21 at 17:23

























        answered Nov 10 at 0:49









        Ben987654

        660520




        660520
























            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






            share|improve this answer



















            • 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










            • @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

















            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






            share|improve this answer



















            • 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










            • @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















            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






            share|improve this answer














            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







            share|improve this answer














            share|improve this answer



            share|improve this answer








            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 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
















            • 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










            • @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












            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.






            share|improve this answer























            • 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










            • 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 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















            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.






            share|improve this answer























            • 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










            • 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 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













            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.






            share|improve this answer














            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.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            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 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










            • 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 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


















            • 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










            • 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 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
















            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





            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?



            Popular posts from this blog

            A CLEAN and SIMPLE way to add appendices to Table of Contents and bookmarks

            Calculate evaluation metrics using cross_val_predict sklearn

            Insert data from modal to MySQL (multiple modal on website)