WAI
Status Update
No update yet.
Comments
ad...@google.com
We have passed this to the development team and will update this issue with more information as it becomes available.
ch...@smartdata.net
I have a similar issue. For some reason even though I call startForeground() from onCreate() it still crashes, but only on Android 8.0. It works fine on 8.1. Here is my code:
@Override
public void onCreate() {
super.onCreate();
if (CoreHelper.apiLevel() >= Build.VERSION_CODE.O) {
final Context ctx = MyApplication.getinstance().getApplicationContext();
final NotificationCompat.Builder builder = NotificationHelper.getInstance().getNotificationBuilder(ctx);
final Notification n = builder.setLocalOnly(true)
.setVisibility(Notification.VISIBILITY_PRIVATE)
.setCategory(Notification.CATEGORY_SERVICE)
.setPriority(NotificationCompat.PRIORITY_MIN)
.build();
MyApplicationLogger.writeTraceEntry(TAG, "Starting foreground service and passing notification: " + n.toString());
startForeground(3, n);
}
MyApplicationLogger.writeTraceEntry(TAG, "Service started!");
}
When I start the service on 8.0 I see *BOTH* of the above messages in the log but then 5 seconds later, I still get android.app.RemoteServiceException: Context.startForegroundService() did not then call Service.startForeground().
Again, the same code running on 8.1 does not produce this behavior. Unfortunately, we have over 1,100 users running 8.0.
@Override
public void onCreate() {
super.onCreate();
if (CoreHelper.apiLevel() >= Build.VERSION_CODE.O) {
final Context ctx = MyApplication.getinstance().getApplicationContext();
final NotificationCompat.Builder builder = NotificationHelper.getInstance().getNotificationBuilder(ctx);
final Notification n = builder.setLocalOnly(true)
.setVisibility(Notification.VISIBILITY_PRIVATE)
.setCategory(Notification.CATEGORY_SERVICE)
.setPriority(NotificationCompat.PRIORITY_MIN)
.build();
MyApplicationLogger.writeTraceEntry(TAG, "Starting foreground service and passing notification: " + n.toString());
startForeground(3, n);
}
MyApplicationLogger.writeTraceEntry(TAG, "Service started!");
}
When I start the service on 8.0 I see *BOTH* of the above messages in the log but then 5 seconds later, I still get android.app.RemoteServiceException: Context.startForegroundService() did not then call Service.startForeground().
Again, the same code running on 8.1 does not produce this behavior. Unfortunately, we have over 1,100 users running 8.0.
ch...@smartdata.net
I should mention in the above code, my getNotificationBuilder() method creates a NotificationCompat.Builder with a NotificationChannel and calls setSmallIcon(R.drawable.ic_dialog_info) and setOnlyAlertOnce(true) on the builder before returning it.
ch...@smartdata.net
Nope. I was wrong. It happens in API 27 (Android 8.1) as well.
ch...@smartdata.net
Ok. I fixed it but I didn't realize the behavior. I had to add the same logic to the service's onStartCommand() as well. The app will sometimes attempt to start a service that is already running. No big deal since when that happens, it doesn't create a new instance of the service, it just calls into the existing service if it is already running via the onStartCommand(). What I didn't realize was that was that if you call startForegroundService() on a service that has already been created [even though it already called startForeground() from onCreate() once], you have to call startForeground() *again* from onStartCommand().
su...@swiggy.in
Even I am facing the same issue. If stopService() is called before startForeground it crashes. Is this yet fixed?
pv...@swooby.com
Any update on this?
I've got clients actively crashing because of this, and I don't want to have to hack my code to delay all service stops by X seconds (ANR timeout).
I've got clients actively crashing because of this, and I don't want to have to hack my code to delay all service stops by X seconds (ANR timeout).
ch...@smartdata.net
All of my attempts to work around this failed. Until there is a fix, I've changed our project to target API 25 for now. Its the only solution I see in order to get our app to production on time.
da...@gmail.com
Not 100% reproducible but for majority of the notifications we are seeing the ANR.
onReceive of BroadcastReceiver class fires startForegroundService and service class calls startForeground in onStartCommand.
Is there any suggested flow for notifications? Or we need to go back to target sdk 25
onReceive of BroadcastReceiver class fires startForegroundService and service class calls startForeground in onStartCommand.
Is there any suggested flow for notifications? Or we need to go back to target sdk 25
[Deleted User] <[Deleted User]>
I am facing same issue and after spending time found a solutons you can try below code. If your using Service then put this code in onCreate else your using Intent Service then put this code in onHandleIntent.
if (Build.VERSION.SDK_INT >= 26) {
String CHANNEL_ID = "my_app";
NotificationChannel channel = new NotificationChannel(CHANNEL_ID,
"MyApp", NotificationManager.IMPORTANCE_DEFAULT);
((NotificationManager) getSystemService(Context.NOTIFICATION_SERVICE)).createNotificationChannel(channel);
Notification notification = new NotificationCompat.Builder(this, CHANNEL_ID)
.setContentTitle("")
.setContentText("").build();
startForeground(1, notification);
}
if (Build.VERSION.SDK_INT >= 26) {
String CHANNEL_ID = "my_app";
NotificationChannel channel = new NotificationChannel(CHANNEL_ID,
"MyApp", NotificationManager.IMPORTANCE_DEFAULT);
((NotificationManager) getSystemService(Context.NOTIFICATION_SERVICE)).createNotificationChannel(channel);
Notification notification = new NotificationCompat.Builder(this, CHANNEL_ID)
.setContentTitle("")
.setContentText("").build();
startForeground(1, notification);
}
pv...@swooby.com
Google's silence on this issue is deafening.
My app used to get 80 crashes a day due to this bug.
I reverted the code to use Context.startService(...) instead of Context.startForegroundService(...).
My app now *only* gets 10 crashes a day due to "Not allowed to start service Intent ...: app is in background".
The above recommended solutions do not work for my use case.
I am no longer willing to accept 10 crashes per day, so my only solution now is to revert back to a compileSdkVersion/targetSdkVersion of 25, which requires rolling back support library to v25.4.0 (which will probably never see any future patches).
All of this, including the silence, is pretty ridiculous.
My app used to get 80 crashes a day due to this bug.
I reverted the code to use Context.startService(...) instead of Context.startForegroundService(...).
My app now *only* gets 10 crashes a day due to "Not allowed to start service Intent ...: app is in background".
The above recommended solutions do not work for my use case.
I am no longer willing to accept 10 crashes per day, so my only solution now is to revert back to a compileSdkVersion/targetSdkVersion of 25, which requires rolling back support library to v25.4.0 (which will probably never see any future patches).
All of this, including the silence, is pretty ridiculous.
ch...@smartdata.net
That is what we had to do. We use compileSdkVersion 27 so we can still use support library 27.0.2 (can't use the latest because of this bug: https://issuetracker.google.com/issues/73981395 ) and targetSdkVersion 25. Couldn't hold off release any longer and the number of crashes we were getting was horrendous. We are still getting crashes but only a fraction by comparison.
pv...@swooby.com
#13, are you only calling Context.startService, or do you still call Context.startForegroundService for SDK_INT >= 26?
What crashes are you still getting? I would expect that you are still getting "Not allowed to start service Intent ...: app is in background", which is my current situation since I commented out my call(s) to startForegroundService due to this bug/crash/issue/feature.
What crashes are you still getting? I would expect that you are still getting "Not allowed to start service Intent ...: app is in background", which is my current situation since I commented out my call(s) to startForegroundService due to this bug/crash/issue/feature.
st...@yahoo.com
After your excellent comment about the flows above (#6) - i.e. with suggestion that after initial startService()/startForegroundService(), one still needs to do startForeground() in not only onStartCommand(), but also onCreate() (in fact in both - not just one or the other).
But in (#9) you were saying that did not fix the issue - and still getting crash reports.
Were you able to get the crashes on your devices as well - or it is a rare event that you could only see in the user crash reports (which makes it harder to debug) ?
Is it possible that some code flow paths are leading to startForeground() not being called ? For example you are toing stopService() before code has opportunity to do a startForeground() - as outlined in this thread:
Context.startForegroundService() did not then call Service.startForeground()
Is it possible some of the crash reports are from issues related to BOOT_COMPLETED handling in Oreo (also being problematic).
Are there any devices reporting this error which are pre-Oreo (I saw one comment on stackoverflow which suggested they were seeing on some Nougat version also) ?
pc...@gmail.com
I am also seeing this crash in crashlytics. I am following the documentation for every call of startForegroundService I am calling startForeground in onStartCommand method. It seems there is OS bug regarding this. I am not able to reproduce this issue, but I can see many crashes on Fabric for this. Can someone look into it please.
st...@yahoo.com
This is a good thread where Ian Lake of Google explains it this way - basically once you do startForegroundService(), you have to do startForeground(). And if you cannot do startForeground() in your Service, then you better do that type of checking in your Broadcast Receiver etc. instead - so that you only start Service when are sure will do startForeground() there.
This means that even if you do stopSelf() in the Service, you have to have done startForeground() ahead of that - which would seem like a waste (i.e. setting up notification and calling startForeground() with that).
This means all program flows have to be examined to ensure that once you do onStartCommand() you never wind up not having done startForeground(). Perhaps this is what causes the rare occurrence of crashes (which are not observable while testing yourself, but do show up on Google Analytics etc.).
Some stackoverflow threads suggest a workaround - where even if you do stopSelf(), you do startForeground() just before that:
https://stackoverflow.com/questions/47337857/context-startforegroundservice-did-not-then-call-service-startforeground-eve
This means that even if you do stopSelf() in the Service, you have to have done startForeground() ahead of that - which would seem like a waste (i.e. setting up notification and calling startForeground() with that).
This means all program flows have to be examined to ensure that once you do onStartCommand() you never wind up not having done startForeground(). Perhaps this is what causes the rare occurrence of crashes (which are not observable while testing yourself, but do show up on Google Analytics etc.).
Some stackoverflow threads suggest a workaround - where even if you do stopSelf(), you do startForeground() just before that:
st...@yahoo.com
Sorry, forgot to paste the link for this:
>This is a good thread where Ian Lake of Google explains it this way - basically once you do startForegroundService(), you have to do startForeground(). And if you cannot do startForeground() in your Service, then you better do that type of checking in your Broadcast Receiver etc. instead - so that you only start Service when are sure will do startForeground() there.
Here it is:
https://plus.google.com/116630648530850689477/posts/L2rn4T6SAJ5
>This is a good thread where Ian Lake of Google explains it this way - basically once you do startForegroundService(), you have to do startForeground(). And if you cannot do startForeground() in your Service, then you better do that type of checking in your Broadcast Receiver etc. instead - so that you only start Service when are sure will do startForeground() there.
Here it is:
pc...@gmail.com
This is not the case with me. I am not calling stopself at all anywhere. Also it is not reproducible it is just seen in crash reports happening with few customers. And I am calling startFroreground in onStartCommand so that is also not concern.
So what I think is happening here is sometime due to busy CPU, after calling startFroregroundService; onStartCommand is being called 5 or more seconds later. It as per design.
But if it is not guaranteed that onStartCommand will be called within 5 seconds then there is no point of having this condition.
Now one solution I am going to try is remove startFroregroundService calls and use messenger to communicate with service, perhaps this will aloow me to reduce crash rates.
So what I think is happening here is sometime due to busy CPU, after calling startFroregroundService; onStartCommand is being called 5 or more seconds later. It as per design.
But if it is not guaranteed that onStartCommand will be called within 5 seconds then there is no point of having this condition.
Now one solution I am going to try is remove startFroregroundService calls and use messenger to communicate with service, perhaps this will aloow me to reduce crash rates.
va...@gmail.com
Same here. We are still having this crash, though all the advised approaches here and on stackOverflow are implemented. The issue is still reproducible.
// starting the service
if (VERSION.SDK_INT >= VERSION_CODES.O) {
context.startForegroundService(intent())
} else {
context.startService(intent())
}
// the Service onStart callback
override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
if (VERSION.SDK_INT >= VERSION_CODES.O) {
startForeground(-1, getNotification())
}
return super.onStartCommand(intent, flags, startId)
}
// starting the service
if (VERSION.SDK_INT >= VERSION_CODES.O) {
context.startForegroundService(intent())
} else {
context.startService(intent())
}
// the Service onStart callback
override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
if (VERSION.SDK_INT >= VERSION_CODES.O) {
startForeground(-1, getNotification())
}
return super.onStartCommand(intent, flags, startId)
}
va...@crunchyroll.com
Same here. We are still having this crash, though all the advised approaches here and on stackOverflow are implemented. The issue is still reproducible.
// starting the service
if (VERSION.SDK_INT >= VERSION_CODES.O) {
context.startForegroundService(intent())
} else {
context.startService(intent())
}
// the Service onStart callback
override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
if (VERSION.SDK_INT >= VERSION_CODES.O) {
startForeground(-1, getNotification())
}
return super.onStartCommand(intent, flags, startId)
}
// starting the service
if (VERSION.SDK_INT >= VERSION_CODES.O) {
context.startForegroundService(intent())
} else {
context.startService(intent())
}
// the Service onStart callback
override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
if (VERSION.SDK_INT >= VERSION_CODES.O) {
startForeground(-1, getNotification())
}
return super.onStartCommand(intent, flags, startId)
}
se...@gmail.com
I have the same issue. What I've done is do all my start and stop service calls via a service manager class. The manager waits for a foreground service to be foregrounded before stopping it. To check that, it calls ActivityManager.getRunningServices() and checks the RunningServiceInfo.foreground flag. Once this changes, it calls stop, unless some other component called start again. It works for now except when I'm debugging and stop at breakpoints, it sometimes crashes.
[Deleted User] <[Deleted User]>
pv...@swooby.com
#23, Maybe that works your use case, but looking at the code for JobService.java (https://android.googlesource.com/platform/frameworks/base.git/+/master/core/java/android/app/job/JobService.java ) I don't see how that would make any difference for my use case, and it requires me to implement onStartJob and onStopJob, which doesn't make any sense for my purposes.
my...@gmail.com
I also have the crashes with IntentService that started by using alarms (AlarmManager). StartForeground() (with the proper notification channel) in onCreate() and onHandleIntent() reduce number of crashes, but number of crashes and affected users still to big for to use in the production.
[Deleted User] <[Deleted User]>
I have updated my OP repo with a possible user[dev]-side workaround.
All I really do is delay stopService by the ANR timeout, and cancel the delay if the service is restarted again.
This might suffice for my needs, but it does mean that the service will always take 5 seconds to stop.
Boo!
I will also be trying a "Bound Service" to see if that eliminates the need for this hack.
All I really do is delay stopService by the ANR timeout, and cancel the delay if the service is restarted again.
This might suffice for my needs, but it does mean that the service will always take 5 seconds to stop.
Boo!
I will also be trying a "Bound Service" to see if that eliminates the need for this hack.
pv...@swooby.com
I have refactored my code to use a "Bound Service", which as a Bound Service this issue seems to be moot/irrelevant.
https://github.com/paulpv/ForegroundServiceAPI26/compare/repro...bound?expand=1
So, perhaps folks that are running in to this bug could work around it by refactoring their code to use a Bound Service instead.
The refactor itself is not too difficult, but it may require non-trivial changes to your own surrounding business logic code.
So, perhaps folks that are running in to this bug could work around it by refactoring their code to use a Bound Service instead.
The refactor itself is not too difficult, but it may require non-trivial changes to your own surrounding business logic code.
to...@gmail.com
Since another issue was marked as duplicated for this one.
If a service is started with Context.startForegroundService it have to call startForeground even if it stop instantly and before the ANR time.
This was validated by Ian Lake and Framework team.
Documentation is missleading and I asked for a very long time that they update ithttps://issuetracker.google.com/issues/64142050 but well :)
But as some others have reported here there's some real issues where you correctly do everything and there's still ANRs with Intent Services. (https://issuetracker.google.com/issues/78678417 )
Fun part is that I discussed about that with Wojtek Kaliciński from Google at a conference and he said he was absolutely not aware of this issue :)
So let's hope one day information does spread correctly.
If a service is started with Context.startForegroundService it have to call startForeground even if it stop instantly and before the ANR time.
This was validated by Ian Lake and Framework team.
Documentation is missleading and I asked for a very long time that they update it
But as some others have reported here there's some real issues where you correctly do everything and there's still ANRs with Intent Services. (
Fun part is that I discussed about that with Wojtek Kaliciński from Google at a conference and he said he was absolutely not aware of this issue :)
So let's hope one day information does spread correctly.
eg...@crunchyroll.com
We have encountered this crash when the app attempts to start the service multiple times in a short period of time. We have "fixed" it by debouncing these attempts.
to...@gmail.com
How did you achieve the debouncing?
My issue is that I have to keep a legacy Intent Service that is used by other apps as a public API so not sure I can do anything about that except break the API for all consumers and use something else :(
My issue is that I have to keep a legacy Intent Service that is used by other apps as a public API so not sure I can do anything about that except break the API for all consumers and use something else :(
vl...@gtempaccount.com
Any updates or official answer on this issue ?
le...@gmail.com
I'm getting hundreds of ANR and Crash reports because of this specific issue. What I think is that somehow Android OS queues the services (globally from other apps) or threads and our Service is not getting called within 5 seconds.
pc...@gmail.com
This issue is not fixed on Android P as well. I can see same crash from android P.
pc...@gmail.com
Please do not carry this bug to android P as well. If it is too hard too fix then deprecate these apis or remove ANR interval. This is too annoying to have, it gives so many crashes.
ct...@google.com
This is not a framework bug; it's intentional. If the app starts a service instance with startForegroundService(), it *must* transition that service instance to the foreground state and show the notification. If the service instance is stopped before startForeground() is called on it, that promise is unfulfilled: this is a bug in the app.
Re #31, publishing a Service that other apps can start directly is fundamentally unsafe. You can mitigate that a bit by treating *all* start actions of that service as requiring startForeground(), though obviously that may not be what you had in mind.
Re #31, publishing a Service that other apps can start directly is fundamentally unsafe. You can mitigate that a bit by treating *all* start actions of that service as requiring startForeground(), though obviously that may not be what you had in mind.
pc...@gmail.com
No no man, u r wrong everytime I start service (just to Avoid your confusuon I have only one service in my app) in one of the first Code i call start foregoround. So you can say whatever you want but reality is there is an issue and whole world is facing this.. so either correct it or bolck few things in P to avoid it. Its very bad to continue witb it I am hetting so many such ctashes on Pixel 2 i thoughy atleast you will fix on P then there is something wrong witb you. If you Say starr foregrond should be called within 5 seconds then you have to call onstartcommand very soo if you are not able to then its Your failure. And do not put such restrictions if you are Not able to handle it gracefully. There are millions of app developers affected by it so take your atepa carefully. You havr messed up witb this in oreo but i do not want you to cobtinue this shit in P.. and I am already getting crash reports on P so there is very definitavely something wrong witb you and this is not just with me if you read othera developers commenta. So already you have made a mistake in O do not continur in P
Hi
Hi
pc...@gmail.com
Man you are still not getting it we call startFeofegrounfservice in on service first step is to call staryForeground still such issues are happening. So plz correct it or change ur documentation it has affected so many developers not just me
pc...@gmail.com
This is a framework bug. If so someone calls startForegroundservice.. n u
declare it anr even if in first line of onstartcommand that app os calling
startForeground then whose fault is this. So Google can you please stop
bragging and really start working on real issuea if you want to be
everywhere. Its very bad behaviour..
On Fri 25 May, 2018, 11:40 PM , <buganizer-system@google.com> wrote:
declare it anr even if in first line of onstartcommand that app os calling
startForeground then whose fault is this. So Google can you please stop
bragging and really start working on real issuea if you want to be
everywhere. Its very bad behaviour..
On Fri 25 May, 2018, 11:40 PM , <buganizer-system@google.com> wrote:
to...@gmail.com
#36 this start to look like a deaf discussion.
I'm well aware of the issue and do everything correctly seehttps://issuetracker.google.com/issues/78678417 and take time to talk to Wojtek Kaliciński (A known Googler) to have more details that I gave him in private.
The main post is indeed a known issue but doc is not clear enough, I did ask for update of the docs since monthshttps://issuetracker.google.com/issues/64142050 but it was never made leading to the root issue posted here.
For non native English speakers "promise" and "before it start" and very far from must in all cases....
So as tried to explained to multiple times to Googlers. there's false issues reported by users because of incomplete documentation but there's a real issue with ANR even when doing everything correctly.
So please take time to see Wojtek Kaliciński and actually try to believe that not all devs are dumb and that sometimes there's issues at OS level ;)
I'm well aware of the issue and do everything correctly see
The main post is indeed a known issue but doc is not clear enough, I did ask for update of the docs since months
For non native English speakers "promise" and "before it start" and very far from must in all cases....
So as tried to explained to multiple times to Googlers. there's false issues reported by users because of incomplete documentation but there's a real issue with ANR even when doing everything correctly.
So please take time to see Wojtek Kaliciński and actually try to believe that not all devs are dumb and that sometimes there's issues at OS level ;)
pv...@swooby.com
Whoever #36 is, give us a break.
We are following the docs.
It *is* a framework bug.
Please fix it. Pretty please. With a cherry on top.
I've moved on my converting my code to use a bindService.
The problem still persists for those that can't, especially if they are working with legacy services that they cannot bind to.
We are following the docs.
It *is* a framework bug.
Please fix it. Pretty please. With a cherry on top.
I've moved on my converting my code to use a bindService.
The problem still persists for those that can't, especially if they are working with legacy services that they cannot bind to.
ch...@smartdata.net
Like most people here... My services call startForeground as the first thing in does in both onCreate() and onStartCommand() and yet.... we still get crash reports. They are intermittent and inconsistent, but they are still happening. Lots of them. Its not like the app has some delay while its busy doing other stuff before it finally gets around to calling startForeground(). It is the VERY FIRST thing we do. The whole idea is to try and beat the clock so that we can avoid this whole nonsense. Look, I get what you are trying to do, but the issue the rest of us are facing is that out in the world, this doesn't actually work well in practice. Why would it take 5 seconds or longer to call startForegound() if its the first thing we do inside those methods? I would argue that despite us making that call as early as possible, either there is some flaw where the system doesn't get signaled in time after the fact - or - like a previous poster indicated, these things are somehow getting queued and not started in time. That's just a guess on my part (admittedly) but *something* is causing this to happen. If it really isn't getting the signal from our code in time, then I would have to ask what is taking startForeground() so long to execute? Because we most certainly are calling it.
pc...@gmail.com
If I call startForegroundservice and in first line of onstartCommand of service I call startForeground still I am getting this issue.. it is not reproducible on my end but I am getting hell crash numbers for it. So I think there is an iasue on Google framework side and as I read on internet I am not alone. As I see already more than enough people have reported about this.. if yoh cannot guarantee that onstartCommand will bea called within ANR time frame of calling startForeground then i dont know how you can implement this restriction.
pc...@gmail.com
Seems they have no idea about whats going on. Its hell bad of them they harasses us on O and are going to do on P and beuty is they do not have any clue what they are doing.. its highly unexpected from Google.
st...@googlemail.com
Since last release of our App, we getting this ANR error a lot from Sony Android 8 Devices. After reading this thread, I can believe that Google still says it's not a bug thing if so many people have to issue.
ni...@shipwell.com
I'm also still seeing reproducible cases where this crash happens as soon as the service is started. Google does not seem to think this is an issue for some reason and is not spending the time to look further into this. I guess we'll need to continue opening tickets since this one is most likely no longer being monitored.
pv...@swooby.com
And those won't be monitored either.
This bug has a clear repro.
Without seeing/knowing the code, there has got to be some stupid timer that starts when "Context.startForegroundService(...)" is called and ONLY stops when "Service.startForeground(...)" is called.
There are many code paths that will need to cancel any timer started by startForegroundService, the most obvious being startForegroundService (in the case of multiple calls) and stopService (in the case before startForeground can be called).
This bug has a clear repro.
Without seeing/knowing the code, there has got to be some stupid timer that starts when "Context.startForegroundService(...)" is called and ONLY stops when "Service.startForeground(...)" is called.
There are many code paths that will need to cancel any timer started by startForegroundService, the most obvious being startForegroundService (in the case of multiple calls) and stopService (in the case before startForeground can be called).
[Deleted User] <[Deleted User]>
Just another voice in agreement -- this looks to us to be a framework bug that no local code change can correct. We are not stopping the service (IntentService in this case) ourself. Tho, we were only calling startForeground() in onHandleIntent, will try doing so in all of onCreate(), onStart(), and onHandleIntent(), and report back after it is deployed.
The issue is exposed via crash reporting. Interesting note, out of tens of thousands of users, here are the only platforms reporting the crashes:
Devices 100% Google
Pixel 2 XL 40%
Pixel 2 28%
Pixel 23%
Pixel XL 9%
The issue is exposed via crash reporting. Interesting note, out of tens of thousands of users, here are the only platforms reporting the crashes:
Devices 100% Google
Pixel 2 XL 40%
Pixel 2 28%
Pixel 23%
Pixel XL 9%
[Deleted User] <[Deleted User]>
Please note that onHandleIntent() is probably the wrong place to be calling startForeground(), as there is no guarantee that it will be called right away. Instead, you should call startForeground() from onStartCommand() instead. (Waiting until the message is processed by the Handler may be too long.)
onCreate() is most likely incorrect as well, unless you're certain that it will be called every time your intent is started by a startForegroundService() call.
It also is not necessary to call startForegroundService from code that is already running in the foreground -- for example, when you're calling from a service that is already in the foreground, you can just use startService() instead of startForegroundService(), and avoid the need for an additional notification, etc.
Although there does appear to be some evidence that a framework issue may exist, I suspect it is not to blame for **all** of these crash reports some of you are having.
onCreate() is most likely incorrect as well, unless you're certain that it will be called every time your intent is started by a startForegroundService() call.
It also is not necessary to call startForegroundService from code that is already running in the foreground -- for example, when you're calling from a service that is already in the foreground, you can just use startService() instead of startForegroundService(), and avoid the need for an additional notification, etc.
Although there does appear to be some evidence that a framework issue may exist, I suspect it is not to blame for **all** of these crash reports some of you are having.
zx...@gmail.com
Facing same issue here.
Calling context.startForegroundService from App widget and the very first thing I do in BOTH onCreate and onStartCommand is startForeground a notification with non-zero ID. And I had checked all possibilities I swear the only place where stopSelf is called is faaaaaaaaaaaar away from onCreate and onStartCommand.
I have nearly 10k active daily users and receive over 100 of this crash every day, all from 26 and 27 devices. And #37 told us that 28 still carries this issue because googler refuse to even understand that it is their fault. #36, man, seriously, IF FRAMEWORK CAN NOT GUARANTEE STARTING SERVICE WITHIN 5 SECONDS, WHY IN HELL YOU CRASH IT WITHOUT CHECKING IF YOU HAVE GOT YOUR OWN JOB DONE?
Calling context.startForegroundService from App widget and the very first thing I do in BOTH onCreate and onStartCommand is startForeground a notification with non-zero ID. And I had checked all possibilities I swear the only place where stopSelf is called is faaaaaaaaaaaar away from onCreate and onStartCommand.
I have nearly 10k active daily users and receive over 100 of this crash every day, all from 26 and 27 devices. And #37 told us that 28 still carries this issue because googler refuse to even understand that it is their fault. #36, man, seriously, IF FRAMEWORK CAN NOT GUARANTEE STARTING SERVICE WITHIN 5 SECONDS, WHY IN HELL YOU CRASH IT WITHOUT CHECKING IF YOU HAVE GOT YOUR OWN JOB DONE?
ma...@marcardar.com
Someone should start a new issue which specifically states in the title that startForeground is being called at the earliest opportunity. Preferably with a sample project.
to...@gmail.com
You mean like https://issuetracker.google.com/issues/78678417 that was closed as duplicate to this one ? :)
I tried to continue my conversation with the Googler on Twitter to have this reopened but he have now vanished and no more answers. So I guess they just don't care and we'll have to live with this.
How different from Google IO where they say we values devs, devs feedback is important, and all the bla bla bla.
I tried to continue my conversation with the Googler on Twitter to have this reopened but he have now vanished and no more answers. So I guess they just don't care and we'll have to live with this.
How different from Google IO where they say we values devs, devs feedback is important, and all the bla bla bla.
ma...@marcardar.com
That was opened (and closed) long before this one was marked as Won't Fix. I suspect it's a waste of time posting here. Just suggesting to try again and be even more explicit than just saying "even if it did".
pv...@swooby.com
#52: I worked at Google from 2005 to 2009; if only you knew how true this was back then and I have no reason to believe isn't still.
I'm the OP.
Then the 30+ of us that have stared this issue should consider this just a conversation as to how we can open the next one so that they will accept it.
I opened this bug with code reproducing a variant of the problem.
I don't know how I could have made it more clear.
How can we made the next bug we open be the one they take?
I'm the OP.
Then the 30+ of us that have stared this issue should consider this just a conversation as to how we can open the next one so that they will accept it.
I opened this bug with code reproducing a variant of the problem.
I don't know how I could have made it more clear.
How can we made the next bug we open be the one they take?
pv...@swooby.com
FYI, I have emailed my former co-workers that are still @google to see if they can help and/or pass on for us a message to anyone they know on the Android team.
ct...@google.com
FYI, there are a couple of different scenarios that lead to the same outcome here.
The outright semantic issue, that it's simply an error to kick something off with startForegroundService() but neglect to actually transition it to foreground via startForeground(), is just that: a semantic issue. That's treated as an app bug, intentionally. Stopping the service before transitioning it to foreground is an app error. That was the crux of the OP, and is why this issue has been marked "working as intended."
However, there are also questions about *spurious* detection of this problem. That's *is* being treated as a genuine problem, though it's being tracked separately from this particular bug tracker issue. We aren't deaf to the complaint.
The outright semantic issue, that it's simply an error to kick something off with startForegroundService() but neglect to actually transition it to foreground via startForeground(), is just that: a semantic issue. That's treated as an app bug, intentionally. Stopping the service before transitioning it to foreground is an app error. That was the crux of the OP, and is why this issue has been marked "working as intended."
However, there are also questions about *spurious* detection of this problem. That's *is* being treated as a genuine problem, though it's being tracked separately from this particular bug tracker issue. We aren't deaf to the complaint.
pv...@swooby.com
ct...@google.com, thank you very much for responding.
Respectfully, it is infeasible to expect app developers to have 100% deterministic control of the timing of when Context.stopService(...) is called in an app.
Other threads may be calling it on a non-deterministic behavior, especially for apps that frequently update their single "ONGOING" notification w/ text/status updates.
If an app calls Context.startForegroundService to update the notification and then needs to immediately update the notification text again, it is completely reasonable to and just might be calling Context.stopService before calling Context.startForegroundService a second or more time.
Context.stopService *MUST* cancel any and all timers that were started in Context.startForegroundService.
Thank you for responding and acknowledging that Google is treating this as a genuine problem.
Can you please cite the particular bug that you are tracking so that I can watch it and not spam any other closed bugs or open duplicate bugs to get attention on this issue?
Thank you.
Respectfully, it is infeasible to expect app developers to have 100% deterministic control of the timing of when Context.stopService(...) is called in an app.
Other threads may be calling it on a non-deterministic behavior, especially for apps that frequently update their single "ONGOING" notification w/ text/status updates.
If an app calls Context.startForegroundService to update the notification and then needs to immediately update the notification text again, it is completely reasonable to and just might be calling Context.stopService before calling Context.startForegroundService a second or more time.
Context.stopService *MUST* cancel any and all timers that were started in Context.startForegroundService.
Thank you for responding and acknowledging that Google is treating this as a genuine problem.
Can you please cite the particular bug that you are tracking so that I can watch it and not spam any other closed bugs or open duplicate bugs to get attention on this issue?
Thank you.
pv...@swooby.com
Specific to this issue,
This seems like faulty logic to me and should not be a decision that the Android OS makes.
There are many legitimate reasons why a Context.serviceStop(...) may be called before Service.onCreate() or Service.onStartCommand(...) have a chance to be called and themselves call the required Service.startForeground(...).
Perhaps the service receives an intent with an extras payload that decides inside onCreate or onStartCommand to show or not show the notification or even just call stopSelf!
In this case, requiring the service to always call Service.startForeground after Context.startForegroundService is called means that the service needs to pass a dummy/throwaway notification to Service.startForeground(...) and cannot call stopSelf.
It is infeasible to require every app call to Context.startForegroundService(...) to be paired with a call to Service.startForeground(...).
Whoever thought this was a good idea needs to seriously reconsider reverting this whole concept/requirement.
This seems like faulty logic to me and should not be a decision that the Android OS makes.
There are many legitimate reasons why a Context.serviceStop(...) may be called before Service.onCreate() or Service.onStartCommand(...) have a chance to be called and themselves call the required Service.startForeground(...).
Perhaps the service receives an intent with an extras payload that decides inside onCreate or onStartCommand to show or not show the notification or even just call stopSelf!
In this case, requiring the service to always call Service.startForeground after Context.startForegroundService is called means that the service needs to pass a dummy/throwaway notification to Service.startForeground(...) and cannot call stopSelf.
It is infeasible to require every app call to Context.startForegroundService(...) to be paired with a call to Service.startForeground(...).
Whoever thought this was a good idea needs to seriously reconsider reverting this whole concept/requirement.
ar...@gmail.com
Do we need android.permission.FOREGROUND_SERVICE this permission in Oreo version for foreground services?
sa...@gmail.com
getting this crash in samsung 8.0 only. please update with the solution
bz...@gmail.com
3 months since the issue was reported? and no fix? no workaround?
pv...@swooby.com
#61 this bug/issue is dead, but ct...@google.com did comment here on 6/5 "That's *is* being treated as a genuine problem, though it's being tracked separately from this particular bug tracker issue. We aren't deaf to the complaint."
No response on what particular issue they *are* tracking, so only they know.
Translucency is apparently a myth.
No response on what particular issue they *are* tracking, so only they know.
Translucency is apparently a myth.
bz...@gmail.com
#62 In my case, it's the widget that does not work anymore with startservice. I'm investigating since several days other ways to workaround the issue but this is really painful.
If I am in a dead end for my widget, do you recommend to open a new case?
or is it to be ignored again?
I think that you should rephrase: backward compatibility is a myth :)
If I am in a dead end for my widget, do you recommend to open a new case?
or is it to be ignored again?
I think that you should rephrase: backward compatibility is a myth :)
pv...@swooby.com
#63 is it at all possible that you can rewrite your code to use Context.bindService?
At first I was skeptical that this would be difficult, but after doing this 3-4 times it is pretty dead simple to convert over to a bound service and does not have any of this limitation/rules.
Simply expose a binding context that returns the service instance, and then in ServiceConnection.onServiceConnected save a reference to that service instance, and finally whenever you want to show the notification just call startForeground on that instance.
*Tomorrow* I will rewrite my sample code athttps://github.com/paulpv/ForegroundServiceAPI26/blob/bound/app/src/main/java/com/github/paulpv/foregroundserviceapi26/ to show how to do it slightly simpler than my current code.
At first I was skeptical that this would be difficult, but after doing this 3-4 times it is pretty dead simple to convert over to a bound service and does not have any of this limitation/rules.
Simply expose a binding context that returns the service instance, and then in ServiceConnection.onServiceConnected save a reference to that service instance, and finally whenever you want to show the notification just call startForeground on that instance.
*Tomorrow* I will rewrite my sample code at
bz...@gmail.com
#64 :) it would be really helpful.
I have a widget with multiple broadcast receiver.
Adding a dummy Notification with startforeground really helps.
I have 2 problems so far:
-starting a service associated to a button
-starting an alarm manager
My code works perfectly until N.
I have a widget with multiple broadcast receiver.
Adding a dummy Notification with startforeground really helps.
I have 2 problems so far:
-starting a service associated to a button
-starting an alarm manager
My code works perfectly until N.
pv...@swooby.com
My mucho simplified code has been pushed to https://github.com/paulpv/ForegroundServiceAPI26/tree/bound/app/src/main/java/com/github/paulpv/foregroundserviceapi26 (note the "bound" branch).
All you need is to bindService when your app starts up and save a reference to that bound service instance.
Your service is already started so you no longer need to call Context.startService just to call Service.startForeground.
Just call startForeground directly using the reference to your bound service instance.
If you do a lot of other work in your existing/legacy service code then just move all of your code out of your Service's onCreate/onStartCommand methods in to separate methods and then just call those methods directly via the reference to your bound service instance.
All you need is to bindService when your app starts up and save a reference to that bound service instance.
Your service is already started so you no longer need to call Context.startService just to call Service.startForeground.
Just call startForeground directly using the reference to your bound service instance.
If you do a lot of other work in your existing/legacy service code then just move all of your code out of your Service's onCreate/onStartCommand methods in to separate methods and then just call those methods directly via the reference to your bound service instance.
vk...@gmail.com
#67 Thanks a lot, didn't notice that this restrictions doesn't impact bound services!
But startForeground() didn't work with bound service in my case, I was needed to start and bind it...
Anyway, I just made simple notification in a separate group, and looks like it works the same way so far.
But startForeground() didn't work with bound service in my case, I was needed to start and bind it...
Anyway, I just made simple notification in a separate group, and looks like it works the same way so far.
ct...@google.com
It is formally invalid to call startForeground() on a service instance that has not been "started". From the docs:
"If your service is started (running through Context.startService(Intent)), then also make this service run in the foreground....
Note that calling this method does not put the service in the started state itself, even though the name sounds like it. You must always call ContextWrapper.startService(Intent) first...."
[or startForegroundService(), of course]
"If your service is started (running through Context.startService(Intent)), then also make this service run in the foreground....
Note that calling this method does not put the service in the started state itself, even though the name sounds like it. You must always call ContextWrapper.startService(Intent) first...."
[or startForegroundService(), of course]
pv...@swooby.com
#69 (ct...@google.com), that is an excellent point.
For now startForeground seems to be working for me on a bound service, but I can see AOSP deciding to change things to make this not work so that it matches the documentation instead of actually making developer's lives easier by stopping this incessant moving the line in the sand so that we can easily create foreground services as needed for our apps and without bugs.
Arguably, none of the changes over time that AOSP has made to lock down foreground services have helped or stopped whatever problem they were intended to solve.
Pretty please, with a cherry on top, just allow us to easily make foreground services without any blocking bugs!
Starting a timer in "Context.startForegroundService" and *only* stopped in "Service.startForeground" is ridiculous.
Whatever timer that is started in "Context.startForegroundService" needs to also be stopped in all exit/stop points of a Service, especially "Context.stopService" and Service.stopSelf".
That one change will fix a lot if not most of these problems.
For now startForeground seems to be working for me on a bound service, but I can see AOSP deciding to change things to make this not work so that it matches the documentation instead of actually making developer's lives easier by stopping this incessant moving the line in the sand so that we can easily create foreground services as needed for our apps and without bugs.
Arguably, none of the changes over time that AOSP has made to lock down foreground services have helped or stopped whatever problem they were intended to solve.
Pretty please, with a cherry on top, just allow us to easily make foreground services without any blocking bugs!
Starting a timer in "Context.startForegroundService" and *only* stopped in "Service.startForeground" is ridiculous.
Whatever timer that is started in "Context.startForegroundService" needs to also be stopped in all exit/stop points of a Service, especially "Context.stopService" and Service.stopSelf".
That one change will fix a lot if not most of these problems.
[Deleted User] <[Deleted User]>
re: #49, in response to #48; app is now live to tens of thousands of users, version that is now calling startForeground() in all of onCreate(), onStart(), and onHandleIntent(); still seeing the crash.
is there a non-closed issue on this where I should be reporting it instead?
is there a non-closed issue on this where I should be reporting it instead?
to...@gmail.com
They close other issues as duplicates, they have an internal issue but we'll never know :)
And will discover when P is out if they did something or not, that's the Google way ;) Like they ask you for P to report the internal things you use, then forget a part of them in the grey list but no more answers on the issue so you are on your own to deal with the breaking :)
The issue can be multiple cause but one is known for sure, the ANR timer starts when the caller calls, so if the system is busy and start your app 9.5 seconds after the call, your app have 0,5 second to fully initialize and call startforeground ;)
And will discover when P is out if they did something or not, that's the Google way ;) Like they ask you for P to report the internal things you use, then forget a part of them in the grey list but no more answers on the issue so you are on your own to deal with the breaking :)
The issue can be multiple cause but one is known for sure, the ANR timer starts when the caller calls, so if the system is busy and start your app 9.5 seconds after the call, your app have 0,5 second to fully initialize and call startforeground ;)
la...@livinideas.com
I have also encountered this issue right now. Any progress on this from Googlers? This is annoying.
[Deleted User] <[Deleted User]>
AOSP has acknowledged there is at least one issue here but this issue and all related are closed and we don't have visibility in to any internal issues.
The net effect is "crickets" to us.
This is an "Android 26" issue, not an "Android P" issue, so there should be at least one public visible issue that we can reference, but there is not.
Highly unimpressed. :/
The net effect is "crickets" to us.
This is an "Android 26" issue, not an "Android P" issue, so there should be at least one public visible issue that we can reference, but there is not.
Highly unimpressed. :/
[Deleted User] <[Deleted User]>
Got the same issue report today on Samsung SM-J600G running Android 8.0.0. The app was in background & the device isn't rooted.
I'm calling startForeground() in onStartCommand() of the service. The issue is not faced by all the Oreo users we have (only 1 so far).
Stack trace:
Fatal Exception: android.app.RemoteServiceException: Context.startForegroundService() did not then call Service.startForeground()
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1881)
at android.os.Handler.dispatchMessage(Handler.java:105)
at android.os.Looper.loop(Looper.java:164)
at android.app.ActivityThread.main(ActivityThread.java:6944)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:327)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1374)
I'm calling startForeground() in onStartCommand() of the service. The issue is not faced by all the Oreo users we have (only 1 so far).
Stack trace:
Fatal Exception: android.app.RemoteServiceException: Context.startForegroundService() did not then call Service.startForeground()
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1881)
at android.os.Handler.dispatchMessage(Handler.java:105)
at android.os.Looper.loop(Looper.java:164)
at android.app.ActivityThread.main(ActivityThread.java:6944)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:327)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1374)
ru...@gmail.com
Was facing the same issue after migration of the project to API 27.
But for now, this weird crash has gone away.
What was causing the issue:
- I was starting the Service by calling the ContextCompat.startForegroundService(Context context, Intent intent)
Here is what this method does under the hood:
if (Build.VERSION.SDK_INT >= 26) {
context.startForegroundService(intent);
} else {
// Pre-O behavior.
context.startService(intent);
}
As you see - nothing special here. Just checks the SDK version and calls appropriate method. But wait a second!
This is the only way to start your Service if you're running Oreo and above
[At least, Google says. Otherwise exception will be thrown!]
As described in the documentation - exception will be thrown if we did not attach a notification by calling Service.startForeground().
To do so system gives us up to 5 seconds. If we don't - ANR - and then crash of the app.
Now, back to the ContextCompat.startForegroundService(Context context, Intent intent)
If you call this method (actually it calls Context.startForegroundService(intent)) which means that you 100% must attach the notification in your Service!
What I've done to fix this issue:
- In my case I was running a Service just with
Intent myIntent = new Intent(context, MyService.class);
intent.setAction("SomeAction");
to only handle this action in Service and stop the Service immediately when action will be handled, which, in my case,
takes not about 5 seconds, just milliseconds.
And then, was starting the service by ContextCompat.startForegroundService(context, myIntent)
But, by calling this method the crash has been throwing every single time.
So, I've changed starting of the Service
from ContextCompat.startForegroundService(context, myIntent)
to context.startService(myIntent) and the issue has gone away.
But my biggest surprise was that by calling context.startService(myIntent) on Oreo system does not produce an Exception!
Please, correct me if I am wrong, but by going this way we should not be able to start any Service on Android >= Oreo!
Unfortunately I am not sure if this fix will help you, but, at least, you may try.
But for now, this weird crash has gone away.
What was causing the issue:
- I was starting the Service by calling the ContextCompat.startForegroundService(Context context, Intent intent)
Here is what this method does under the hood:
if (Build.VERSION.SDK_INT >= 26) {
context.startForegroundService(intent);
} else {
// Pre-O behavior.
context.startService(intent);
}
As you see - nothing special here. Just checks the SDK version and calls appropriate method. But wait a second!
This is the only way to start your Service if you're running Oreo and above
[At least, Google says. Otherwise exception will be thrown!]
As described in the documentation - exception will be thrown if we did not attach a notification by calling Service.startForeground().
To do so system gives us up to 5 seconds. If we don't - ANR - and then crash of the app.
Now, back to the ContextCompat.startForegroundService(Context context, Intent intent)
If you call this method (actually it calls Context.startForegroundService(intent)) which means that you 100% must attach the notification in your Service!
What I've done to fix this issue:
- In my case I was running a Service just with
Intent myIntent = new Intent(context, MyService.class);
intent.setAction("SomeAction");
to only handle this action in Service and stop the Service immediately when action will be handled, which, in my case,
takes not about 5 seconds, just milliseconds.
And then, was starting the service by ContextCompat.startForegroundService(context, myIntent)
But, by calling this method the crash has been throwing every single time.
So, I've changed starting of the Service
from ContextCompat.startForegroundService(context, myIntent)
to context.startService(myIntent) and the issue has gone away.
But my biggest surprise was that by calling context.startService(myIntent) on Oreo system does not produce an Exception!
Please, correct me if I am wrong, but by going this way we should not be able to start any Service on Android >= Oreo!
Unfortunately I am not sure if this fix will help you, but, at least, you may try.
[Deleted User] <[Deleted User]>
> This is the only way to start your Service if you're running Oreo and above
No, that is incorrect.
Of course you can still start a service with context.startService() on Oreo, if that context is in the foreground.
It will only fail if the call occurs when that context is in the background.
> As described in the documentation - exception will be thrown if we did not attach a notification by calling Service.startForeground().
That is only true WHEN using context.startForegroundService, which you only need to do IF you need to be able to start the service from the background.
If your app is running in the foreground, you can call startService the same as before.
And you can also call startForeground() from any service without first calling startForegroundService(), to make the service remain in the foreground. Same as before!
The only time startForegroundService() is required, is as step 1 of launching a service into the foreground *from the background*. (Step 2 is calling startForeground() which must be done within 5 seconds or the ANR will occur.)
If you need to launch a foreground service from a point where your app might not have foreground status, THEN you need to use startForegroundService() on Oreo, and THEN that service will need to fulfill the contract by calling startForeground() from a place that is guaranteed to be executed soon enough.
Much of this discussion has had very little to do with the issue originally brought forward, which is unfortunately being clouded by devs who seem to lack a fundamental grasp of what they're working on.
No, that is incorrect.
Of course you can still start a service with context.startService() on Oreo, if that context is in the foreground.
It will only fail if the call occurs when that context is in the background.
> As described in the documentation - exception will be thrown if we did not attach a notification by calling Service.startForeground().
That is only true WHEN using context.startForegroundService, which you only need to do IF you need to be able to start the service from the background.
If your app is running in the foreground, you can call startService the same as before.
And you can also call startForeground() from any service without first calling startForegroundService(), to make the service remain in the foreground. Same as before!
The only time startForegroundService() is required, is as step 1 of launching a service into the foreground *from the background*. (Step 2 is calling startForeground() which must be done within 5 seconds or the ANR will occur.)
If you need to launch a foreground service from a point where your app might not have foreground status, THEN you need to use startForegroundService() on Oreo, and THEN that service will need to fulfill the contract by calling startForeground() from a place that is guaranteed to be executed soon enough.
Much of this discussion has had very little to do with the issue originally brought forward, which is unfortunately being clouded by devs who seem to lack a fundamental grasp of what they're working on.
jy...@gmail.com
Referring to #76
This may avoid crash but the notifications are not getting generated anymore.
In order for notifications to be created, you need to run it in foreground for Oreo onwards.
So, it doesnt fix the code.
AM i missing anything?
This may avoid crash but the notifications are not getting generated anymore.
In order for notifications to be created, you need to run it in foreground for Oreo onwards.
So, it doesnt fix the code.
AM i missing anything?
pv...@swooby.com
#78, what "this" are you referring to?
Are you referring to my "bind" workaround example, or something else?
I am seeing notifications just fine in my "bind" workaround example.
(although, as mentioned elsewhere in this thread, the documentation says that "Service.startForeground" should only be called on "started" services, so I suspect that it is only a matter of time before AOSP makes another change that breaks my bind workaround).
The problem with the true statement that you only need to call "startForegroundService" when your app is in the background should be obvious.
There is zero simple reliable OS provided API to know if you app is in the foreground.
Whatever test the startService is doing to know that the app is not in foreground is not available to us developers.
So, developers now need to hand roll their own solution to detect if their app is in the foreground (ex: add your Activity to a collection in onStart, and remove in onStop).
By our logic may be different from the OS startService logic, so we may test that we do or don't need to call Context.startService or Context.startForegroundService, and Context.startService may disagree.
So then we may just want to call Context.startService, and if that throws a known exception then call Context.startForegroundService.
All of these added layers upon layers upon layers of code all to allow the OS to prevent apps from abusing foreground services is ridiculous.
Some developers or PMs working on this area in AOSP are seriously not grounded in reality.
It would be like mandating that an automobile is not allowed to move until the seatbelt is buckled around every occupant.
There are tons of ways to get around any mandate, so the next version adds stricter mandates that still have some workarounds, so the next version adds even stricter mandates that *still* have workarounds.
The end result is a car that is a pain in the ass and zero fun to drive...and yet creative people can still find some way(s) to work around the mandate, although most of them are pissed off that they had to resort to just drastic workarounds.
Just let us simply and easily create foreground services like we always have!
:/
Are you referring to my "bind" workaround example, or something else?
I am seeing notifications just fine in my "bind" workaround example.
(although, as mentioned elsewhere in this thread, the documentation says that "Service.startForeground" should only be called on "started" services, so I suspect that it is only a matter of time before AOSP makes another change that breaks my bind workaround).
The problem with the true statement that you only need to call "startForegroundService" when your app is in the background should be obvious.
There is zero simple reliable OS provided API to know if you app is in the foreground.
Whatever test the startService is doing to know that the app is not in foreground is not available to us developers.
So, developers now need to hand roll their own solution to detect if their app is in the foreground (ex: add your Activity to a collection in onStart, and remove in onStop).
By our logic may be different from the OS startService logic, so we may test that we do or don't need to call Context.startService or Context.startForegroundService, and Context.startService may disagree.
So then we may just want to call Context.startService, and if that throws a known exception then call Context.startForegroundService.
All of these added layers upon layers upon layers of code all to allow the OS to prevent apps from abusing foreground services is ridiculous.
Some developers or PMs working on this area in AOSP are seriously not grounded in reality.
It would be like mandating that an automobile is not allowed to move until the seatbelt is buckled around every occupant.
There are tons of ways to get around any mandate, so the next version adds stricter mandates that still have some workarounds, so the next version adds even stricter mandates that *still* have workarounds.
The end result is a car that is a pain in the ass and zero fun to drive...and yet creative people can still find some way(s) to work around the mandate, although most of them are pissed off that they had to resort to just drastic workarounds.
Just let us simply and easily create foreground services like we always have!
:/
go...@gmail.com
Interestingly my app does not call startForegroundService at all (only uses startService or bindService), yet my dashboard is full of these ANRs. Not exactly sure how to fix that one
pv...@swooby.com
#80, If your app targets API O/26 and above and you call Context.startService(...) when your app is in the background then it will throw IllegalStateException.
Example:
java.lang.IllegalStateException: Not allowed to start service Intent { cmp=my.app.tt/com.my.service }: app is in background uid UidRecord{90372b1 u0a136 CEM idle procs:1 seq(0,0,0)}
You have to call Context.startForegroundService(...) to keep from throwing that exception, and then your service has to call Service.startForeground(...) within ANR seconds in order to not throw android.app.RemoteServiceException: Context.startForegroundService() did not then call Service.startForeground()
Example:
java.lang.IllegalStateException: Not allowed to start service Intent { cmp=
You have to call Context.startForegroundService(...) to keep from throwing that exception, and then your service has to call Service.startForeground(...) within ANR seconds in order to not throw android.app.RemoteServiceException: Context.startForegroundService() did not then call Service.startForeground()
go...@gmail.com
#81 my app is still targeting 22 and the specific error im seeing for the ANR is "Context.startForegroundService() did not then call Service.startForeground". I've never experienced the issue myself but see tons of ANRs reported in the play console
pv...@swooby.com
#82, double check your compileSdkVersion and targetSdkVersion; I would think that Exception would be impossible if targeting less than 26.
ct...@google.com
#82, I'm also shocked if you're seeing that specific error with an apk whose targetSdkVersion is less than 26. Legacy apps have startForegroundService() treated as an ordinary startService(), and as a consequence are also not required to call startForeground() from that service.
go...@gmail.com
Context.startForegroundService() did not then call Service.startForeground()
Today, 6:57 AM on app version 95253
Sony Xperia XZ1 (SOV36), Android 8.0
Type Version code API levels Target SDK
APK 95253 21+ 22
Image straight from my dev console showing the ANRs and my target levels:https://imgur.com/a/IbhUfv8
Today, 6:57 AM on app version 95253
Sony Xperia XZ1 (SOV36), Android 8.0
Type Version code API levels Target SDK
APK 95253 21+ 22
Image straight from my dev console showing the ANRs and my target levels:
go...@gmail.com
#84 its especially shocking seeing as i dont even call startForegroundService in my code
pv...@swooby.com
go...@gmail.com: What is your compileSdkVersion and your targetSdkVersion in your build.gradle file?
Are you using support/appcompat?
If you use any third party libraries it is possible the may be overriding this.
Are you using support/appcompat?
If you use any third party libraries it is possible the may be overriding this.
go...@gmail.com
#87 nothing is overriding it. if the were it should show up in the play console when it reports the target sdk... and anything over 22 requires the whole permission changes which this version of my app has not implemented.. so i would have ran into tons of issues if the targetsdk was bumped up by a dependency
compileSdkVersion 26
buildToolsVersion '27.0.3'
defaultConfig {
applicationId "gonemad.gmmp"
minSdkVersion 21
targetSdkVersion 22
versionCode 253
versionName "2.2.11"
renderscriptTargetApi 21
whole list of dependencies:
compile 'com.google.android.gms:play-services-cast:11.0.4'
compile 'com.android.support:support-v4:26.0.0'
compile 'com.android.support:mediarouter-v7:26.0.0'
compile 'com.android.support:appcompat-v7:26.0.0'
compile 'com.koushikdutta.async:androidasync:2.+'
compile 'de.greenrobot:eventbus:2.4.0'
compile 'com.jakewharton:butterknife:6.0.+'
compile 'com.github.bumptech.glide:glide:3.7.0'
compile 'com.sothree.slidinguppanel:library:2.+'
compile 'com.github.machinarius:preferencefragment:0.1.1'
compile 'com.rengwuxian.materialedittext:library:1.8.2'
compile 'com.squareup.okhttp:okhttp:2.5.0'
compileSdkVersion 26
buildToolsVersion '27.0.3'
defaultConfig {
applicationId "gonemad.gmmp"
minSdkVersion 21
targetSdkVersion 22
versionCode 253
versionName "2.2.11"
renderscriptTargetApi 21
whole list of dependencies:
compile 'com.google.android.gms:play-services-cast:11.0.4'
compile 'com.android.support:support-v4:26.0.0'
compile 'com.android.support:mediarouter-v7:26.0.0'
compile 'com.android.support:appcompat-v7:26.0.0'
compile 'com.koushikdutta.async:androidasync:2.+'
compile 'de.greenrobot:eventbus:2.4.0'
compile 'com.jakewharton:butterknife:6.0.+'
compile 'com.github.bumptech.glide:glide:3.7.0'
compile 'com.sothree.slidinguppanel:library:2.+'
compile 'com.github.machinarius:preferencefragment:0.1.1'
compile 'com.rengwuxian.materialedittext:library:1.8.2'
compile 'com.squareup.okhttp:okhttp:2.5.0'
ma...@marcardar.com
Unrelated, but you should be able to remove this since it's no longer needed:
buildToolsVersion '27.0.3'
buildToolsVersion '27.0.3'
go...@gmail.com
are you not able to specify the version of the build tools you use? or will it automatically use the latest you have installed
[Deleted User] <[Deleted User]>
Got the same issue in Xiaomi (Mi A1) running Android 8.0.0
Stack trace:
Fatal Exception: android.app.RemoteServiceException: Context.startForegroundService() did not then call Service.startForeground()
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1780)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:172)
at android.app.ActivityThread.main(ActivityThread.java:6590)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807)
I have used following code:
A. in Gradle
---------------------------------------------------------------------------------------------------------------------------
android {
compileSdkVersion 27
buildToolsVersion '27.0.3'
defaultConfig {
applicationId 'com.dummy'
minSdkVersion 21
targetSdkVersion 27
versionCode 130
multiDexEnabled true
versionName "2.30"
//testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}
buildTypes {
release {
// todo: use for showing log into release apk
initWith(buildTypes.debug)
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.release
}
debug {
initWith(buildTypes.debug)
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
preprod {
initWith(buildTypes.debug)
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
useLibrary 'org.apache.http.legacy'
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_7
targetCompatibility JavaVersion.VERSION_1_7
}
}
android {
packagingOptions {
exclude 'META-INF/DEPENDENCIES'
exclude 'META-INF/NOTICE'
exclude 'META-INF/LICENSE'
exclude 'META-INF/LICENSE.txt'
exclude 'META-INF/NOTICE.txt'
}
lintOptions {
abortOnError false
}
dexOptions {
preDexLibraries = false
javaMaxHeapSize "4g"
}
buildTypes {
debug {
//TODO: use for start debug app or not ... for start debug place "true" otherwise "false"
debuggable true
}
}
}
dependencies {
implementation('org.apache.httpcomponents:httpmime:4.3.6') {
exclude module: "httpclient"
}
implementation('org.apache.httpcomponents:httpcore:4.+') {
exclude module: "httpclient"
}
implementation('com.crashlytics.sdk.android:crashlytics:2.9.2@aar') {
transitive = true;
}
implementation('io.branch.sdk.android:library:2.+') {
exclude module: 'answers-shim'
}
implementation 'se.emilsjolander:stickylistheaders:2.7.0'
implementation 'com.android.support:design:27.1.1'
implementation 'com.android.support:cardview-v7:27.1.1'
implementation 'com.android.support:appcompat-v7:27.1.1'
implementation 'com.android.support:support-vector-drawable:27.1.1'
implementation 'com.android.support:customtabs:27.1.1'
implementation 'com.android.support:recyclerview-v7:27.1.1'
implementation 'com.android.support:support-v4:27.1.1'
implementation 'com.twitter.sdk.android:twitter-core:3.1.1'
implementation 'com.twitter.sdk.android:tweet-ui:3.1.1'
implementation 'com.twitter.sdk.android:tweet-composer:3.1.1'
implementation 'com.twitter.sdk.android:twitter-mopub:3.1.1'
implementation 'com.google.android.gms:play-services-location:15.0.0'
implementation 'com.google.android.gms:play-services-maps:15.0.0'
implementation 'com.google.android.gms:play-services-fitness:15.0.0'
implementation 'com.google.android.gms:play-services-analytics:15.0.0'
implementation 'com.google.android.gms:play-services-auth:15.0.0'
implementation 'com.google.firebase:firebase-auth:15.0.0'
implementation 'com.google.firebase:firebase-messaging:15.0.2'
implementation('com.facebook.android:facebook-android-sdk:4.32.0') {
exclude group: 'com.android.support', module: 'support-v4'
exclude group: 'com.android.support', module: 'appcompat-v7'
exclude group: 'com.android.support', module: 'cardview-v7'
exclude group: 'com.android.support', module: 'customtabs'
exclude group: 'com.android.support', module: 'support-v4'
}
implementation 'com.android.volley:volley:1.1.0'
implementation 'com.google.code.gson:gson:2.8.2'
implementation 'de.hdodenhof:circleimageview:2.1.0'
implementation 'com.android.support:multidex:1.0.3'
implementation 'com.android.support.constraint:constraint-layout:1.1.0'
implementation 'com.github.scottyab:showhidepasswordedittext:0.8'
implementation 'io.branch.sdk.android:library:2.17.1'
implementation 'com.bugfender.sdk:android:1.+'
implementation 'com.github.jd-alexander:LikeButton:0.2.3'
implementation 'com.github.freshdesk:freshchat-android:1.1.1'
implementation 'com.squareup.picasso:picasso:2.5.2'
implementation 'com.soundcloud.android:android-crop:1.0.1@aar'
implementation 'com.razorpay:checkout:1.4.1'
implementation files('libs/YouTubeAndroidPlayerApi.jar')
implementation 'com.github.bumptech.glide:glide:4.6.1'
annotationProcessor 'com.github.bumptech.glide:compiler:4.6.1'
implementation files('libs/PGSDK_V2.1.jar')
implementation 'com.androidadvance:topsnackbar:1.1.1'
implementation 'it.sephiroth.android.library.targettooltip:target-tooltip-library:1.3.15'
implementation 'com.jakewharton:butterknife:8.8.1'
annotationProcessor 'com.jakewharton:butterknife-compiler:8.8.1'
implementation 'io.reactivex.rxjava2:rxjava:2.1.13'
implementation 'io.reactivex.rxjava2:rxandroid:2.0.2'
implementation 'com.squareup.retrofit2:retrofit:2.4.0'
implementation 'com.squareup.retrofit2:converter-gson:2.4.0'
implementation 'com.squareup.retrofit2:retrofit-adapters:2.4.0'
implementation 'com.jakewharton.retrofit:retrofit2-rxjava2-adapter:1.0.0'
implementation project(path: ':myTracksLib')
implementation 'com.google.protobuf:protobuf-java:2.6.1'
implementation 'com.flyco.dialog:FlycoDialog_Lib:1.3.2@aar'
implementation project(':myTracksLib')
implementation 'com.github.PhilJay:MPAndroidChart:v3.0.3'
implementation 'io.supercharge:shimmerlayout:2.1.0'
}
---------------------------------------------------------------------------------------------------------------------------
B. in Class
--------------------------------------------------------------------------------------------------------------------------
if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.O){
getApplicationContext().startForegroundService(new Intent(getApplicationContext(), DummyService.class));
}
else{
getApplicationContext().startService(new Intent(getApplicationContext(), DummyService.class));
}
----------------------------------------------------------------------------------------------------------------------------
C. in manifest
-----------------------------------------------------------------------------------------------------------------------------
<service
android:name=".Services.DummyService"
android:exported="false" />
--------------------------------------------------------------------------------------------------------------------------------
Stack trace:
Fatal Exception: android.app.RemoteServiceException: Context.startForegroundService() did not then call Service.startForeground()
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1780)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:172)
at android.app.ActivityThread.main(ActivityThread.java:6590)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807)
I have used following code:
A. in Gradle
---------------------------------------------------------------------------------------------------------------------------
android {
compileSdkVersion 27
buildToolsVersion '27.0.3'
defaultConfig {
applicationId 'com.dummy'
minSdkVersion 21
targetSdkVersion 27
versionCode 130
multiDexEnabled true
versionName "2.30"
//testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}
buildTypes {
release {
// todo: use for showing log into release apk
initWith(buildTypes.debug)
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.release
}
debug {
initWith(buildTypes.debug)
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
preprod {
initWith(buildTypes.debug)
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
useLibrary 'org.apache.http.legacy'
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_7
targetCompatibility JavaVersion.VERSION_1_7
}
}
android {
packagingOptions {
exclude 'META-INF/DEPENDENCIES'
exclude 'META-INF/NOTICE'
exclude 'META-INF/LICENSE'
exclude 'META-INF/LICENSE.txt'
exclude 'META-INF/NOTICE.txt'
}
lintOptions {
abortOnError false
}
dexOptions {
preDexLibraries = false
javaMaxHeapSize "4g"
}
buildTypes {
debug {
//TODO: use for start debug app or not ... for start debug place "true" otherwise "false"
debuggable true
}
}
}
dependencies {
implementation('org.apache.httpcomponents:httpmime:4.3.6') {
exclude module: "httpclient"
}
implementation('org.apache.httpcomponents:httpcore:4.+') {
exclude module: "httpclient"
}
implementation('com.crashlytics.sdk.android:crashlytics:2.9.2@aar') {
transitive = true;
}
implementation('io.branch.sdk.android:library:2.+') {
exclude module: 'answers-shim'
}
implementation 'se.emilsjolander:stickylistheaders:2.7.0'
implementation 'com.android.support:design:27.1.1'
implementation 'com.android.support:cardview-v7:27.1.1'
implementation 'com.android.support:appcompat-v7:27.1.1'
implementation 'com.android.support:support-vector-drawable:27.1.1'
implementation 'com.android.support:customtabs:27.1.1'
implementation 'com.android.support:recyclerview-v7:27.1.1'
implementation 'com.android.support:support-v4:27.1.1'
implementation 'com.twitter.sdk.android:twitter-core:3.1.1'
implementation 'com.twitter.sdk.android:tweet-ui:3.1.1'
implementation 'com.twitter.sdk.android:tweet-composer:3.1.1'
implementation 'com.twitter.sdk.android:twitter-mopub:3.1.1'
implementation 'com.google.android.gms:play-services-location:15.0.0'
implementation 'com.google.android.gms:play-services-maps:15.0.0'
implementation 'com.google.android.gms:play-services-fitness:15.0.0'
implementation 'com.google.android.gms:play-services-analytics:15.0.0'
implementation 'com.google.android.gms:play-services-auth:15.0.0'
implementation 'com.google.firebase:firebase-auth:15.0.0'
implementation 'com.google.firebase:firebase-messaging:15.0.2'
implementation('com.facebook.android:facebook-android-sdk:4.32.0') {
exclude group: 'com.android.support', module: 'support-v4'
exclude group: 'com.android.support', module: 'appcompat-v7'
exclude group: 'com.android.support', module: 'cardview-v7'
exclude group: 'com.android.support', module: 'customtabs'
exclude group: 'com.android.support', module: 'support-v4'
}
implementation 'com.android.volley:volley:1.1.0'
implementation 'com.google.code.gson:gson:2.8.2'
implementation 'de.hdodenhof:circleimageview:2.1.0'
implementation 'com.android.support:multidex:1.0.3'
implementation 'com.android.support.constraint:constraint-layout:1.1.0'
implementation 'com.github.scottyab:showhidepasswordedittext:0.8'
implementation 'io.branch.sdk.android:library:2.17.1'
implementation 'com.bugfender.sdk:android:1.+'
implementation 'com.github.jd-alexander:LikeButton:0.2.3'
implementation 'com.github.freshdesk:freshchat-android:1.1.1'
implementation 'com.squareup.picasso:picasso:2.5.2'
implementation 'com.soundcloud.android:android-crop:1.0.1@aar'
implementation 'com.razorpay:checkout:1.4.1'
implementation files('libs/YouTubeAndroidPlayerApi.jar')
implementation 'com.github.bumptech.glide:glide:4.6.1'
annotationProcessor 'com.github.bumptech.glide:compiler:4.6.1'
implementation files('libs/PGSDK_V2.1.jar')
implementation 'com.androidadvance:topsnackbar:1.1.1'
implementation 'it.sephiroth.android.library.targettooltip:target-tooltip-library:1.3.15'
implementation 'com.jakewharton:butterknife:8.8.1'
annotationProcessor 'com.jakewharton:butterknife-compiler:8.8.1'
implementation 'io.reactivex.rxjava2:rxjava:2.1.13'
implementation 'io.reactivex.rxjava2:rxandroid:2.0.2'
implementation 'com.squareup.retrofit2:retrofit:2.4.0'
implementation 'com.squareup.retrofit2:converter-gson:2.4.0'
implementation 'com.squareup.retrofit2:retrofit-adapters:2.4.0'
implementation 'com.jakewharton.retrofit:retrofit2-rxjava2-adapter:1.0.0'
implementation project(path: ':myTracksLib')
implementation 'com.google.protobuf:protobuf-java:2.6.1'
implementation 'com.flyco.dialog:FlycoDialog_Lib:1.3.2@aar'
implementation project(':myTracksLib')
implementation 'com.github.PhilJay:MPAndroidChart:v3.0.3'
implementation 'io.supercharge:shimmerlayout:2.1.0'
}
---------------------------------------------------------------------------------------------------------------------------
B. in Class
--------------------------------------------------------------------------------------------------------------------------
if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.O){
getApplicationContext().startForegroundService(new Intent(getApplicationContext(), DummyService.class));
}
else{
getApplicationContext().startService(new Intent(getApplicationContext(), DummyService.class));
}
----------------------------------------------------------------------------------------------------------------------------
C. in manifest
-----------------------------------------------------------------------------------------------------------------------------
<service
android:name=".Services.DummyService"
android:exported="false" />
--------------------------------------------------------------------------------------------------------------------------------
ra...@gmail.com
+1 I have noticed this issue on Android P as well. It's quite random though.
pu...@gmail.com
I'm also seeing a few of these crashes, happening only on Android P and mostly Pixel XL 2 (but not only). No Oreo device produces this crash whatsoever.
So there is something broken on P, with that clever timebomb kicking it when it should not, for incomprehensible reasons. I have tried to reprod it in the Android Pie emulator to no avail.
So there is something broken on P, with that clever timebomb kicking it when it should not, for incomprehensible reasons. I have tried to reprod it in the Android Pie emulator to no avail.
lb...@gmail.com
Guys this issue is closed. In order to report to Google about this again, you have to create a new issue:
https://issuetracker.google.com/issues/new
pu...@gmail.com
Ah indeed this is closed. There are zillions startForegroundService() issues opened already so no need to open new a one.
If anything, startForegroundService() is really a "feature" that is too clever for its own good and when it causes an unobvious crash, there is no way to understand what exactly caused that crash.
If anything, startForegroundService() is really a "feature" that is too clever for its own good and when it causes an unobvious crash, there is no way to understand what exactly caused that crash.
jm...@gmail.com
Consider starring https://issuetracker.google.com/issues/113759464 which proposes an alternate implementation for startForegroundService that is more compatible with existing apps.
to...@gmail.com
At least the documentation is completely bad :-(
/**
* Similar to {@link #startService(Intent)}, but with an implicit promise that the
* Service will call {@link android.app.Service#startForeground(int, android.app.Notification)
* startForeground(int, android.app.Notification)} once it begins running. The service is given
* an amount of time comparable to the ANR interval to do this, otherwise the system
* will automatically stop the service and declare the app ANR.
*
* <p>Unlike the ordinary {@link #startService(Intent)}, this method can be used
* at any time, regardless of whether the app hosting the service is in a foreground
* state.
*
* @param service Identifies the service to be started. The Intent must be
* fully explicit (supplying a component name). Additional values
* may be included in the Intent extras to supply arguments along with
* this specific start call.
*
* @return If the service is being started or is already running, the
* {@link ComponentName} of the actual service that was started is
* returned; else if the service does not exist null is returned.
*
* @throws SecurityException If the caller does not have permission to access the service
* or the service can not be found.
*
* @see #stopService
* @see android.app.Service#startForeground(int, android.app.Notification)
*/
@Nullable
public abstract ComponentName startForegroundService(Intent service);
And it real workd it crash immediatelly, instead of "The service is given an amount of time comparable to the ANR interval to do this, otherwise the system will automatically stop the service and declare the app ANR."
/**
* Similar to {@link #startService(Intent)}, but with an implicit promise that the
* Service will call {@link android.app.Service#startForeground(int, android.app.Notification)
* startForeground(int, android.app.Notification)} once it begins running. The service is given
* an amount of time comparable to the ANR interval to do this, otherwise the system
* will automatically stop the service and declare the app ANR.
*
* <p>Unlike the ordinary {@link #startService(Intent)}, this method can be used
* at any time, regardless of whether the app hosting the service is in a foreground
* state.
*
* @param service Identifies the service to be started. The Intent must be
* fully explicit (supplying a component name). Additional values
* may be included in the Intent extras to supply arguments along with
* this specific start call.
*
* @return If the service is being started or is already running, the
* {@link ComponentName} of the actual service that was started is
* returned; else if the service does not exist null is returned.
*
* @throws SecurityException If the caller does not have permission to access the service
* or the service can not be found.
*
* @see #stopService
* @see android.app.Service#startForeground(int, android.app.Notification)
*/
@Nullable
public abstract ComponentName startForegroundService(Intent service);
And it real workd it crash immediatelly, instead of "The service is given an amount of time comparable to the ANR interval to do this, otherwise the system will automatically stop the service and declare the app ANR."
ra...@gmail.com
Is SDK 28 changing anything here?
de...@observation.org
As a lot of people -including myself- have this proplem: please reopen and solve it!
[Deleted User] <[Deleted User]>
Taking into account that serializing calls to start/stop may help with this issue, what you think about following service wrapper?
class ForegroundService : Service() {
companion object {
fun start(context: Context, notificationId: Int, notification: Notification) {
ContextCompat.startForegroundService(context, context.serviceIntent())
context.bindToService { startForeground(notificationId, notification) }
}
fun stop(context: Context) {
context.bindToService { stopSelf() }
}
private fun Context.serviceIntent() = Intent(this, ForegroundService::class.java)
private fun Context.bindToService(block: ForegroundService.() -> Unit) {
val connection = object : ServiceConnection {
override fun onServiceConnected(name: ComponentName, binder: IBinder) {
block((binder as DirectBinder).service)
unbindService(this)
}
override fun onServiceDisconnected(name: ComponentName) = kotlin.Unit
}
bindService(serviceIntent(), connection, Context.BIND_AUTO_CREATE)
}
}
override fun onStartCommand(intent: Intent?, flags: Int, startId: Int) = Service.START_NOT_STICKY
override fun onBind(intent: Intent?) = DirectBinder(this)
class DirectBinder(val service: ForegroundService) : Binder()
}
class ForegroundService : Service() {
companion object {
fun start(context: Context, notificationId: Int, notification: Notification) {
ContextCompat.startForegroundService(context, context.serviceIntent())
context.bindToService { startForeground(notificationId, notification) }
}
fun stop(context: Context) {
context.bindToService { stopSelf() }
}
private fun Context.serviceIntent() = Intent(this, ForegroundService::class.java)
private fun Context.bindToService(block: ForegroundService.() -> Unit) {
val connection = object : ServiceConnection {
override fun onServiceConnected(name: ComponentName, binder: IBinder) {
block((binder as DirectBinder).service)
unbindService(this)
}
override fun onServiceDisconnected(name: ComponentName) = kotlin.Unit
}
bindService(serviceIntent(), connection, Context.BIND_AUTO_CREATE)
}
}
override fun onStartCommand(intent: Intent?, flags: Int, startId: Int) = Service.START_NOT_STICKY
override fun onBind(intent: Intent?) = DirectBinder(this)
class DirectBinder(val service: ForegroundService) : Binder()
}
vo...@gmail.com
Encountered the same problem here. Do anyone have any workarounds to fix this?
Thanks,
-Young
Thanks,
-Young
so...@gmail.com
I just stopped using a service and am now using an ExecutorService instead, which ended up working for my needs
he...@gmail.com
I have a work around for this problem. I have verified this fix in my own app(300K+ DAU), which can reduce at least 95% of this kind of crash, but still cannot 100% avoid this problem.
This problem happens even when you ensure to call startForeground() just after service started as Google documented. It may be because the service creation and initialization process already cost more than 5 seconds in many scenarios, then no matter when and where you call startForeground() method, this crash is unavoidable.
My solution is to ensure that startForeground() will be executed within 5 seconds after startForegroundService() method, no matter how long your service need to be created and initialized. Please go to stackoverflow to see the detailed code examples.
https://stackoverflow.com/questions/44425584/context-startforegroundservice-did-not-then-call-service-startforeground/53286232#53286232
Hope this helps in your project. Good luck.
This problem happens even when you ensure to call startForeground() just after service started as Google documented. It may be because the service creation and initialization process already cost more than 5 seconds in many scenarios, then no matter when and where you call startForeground() method, this crash is unavoidable.
My solution is to ensure that startForeground() will be executed within 5 seconds after startForegroundService() method, no matter how long your service need to be created and initialized. Please go to stackoverflow to see the detailed code examples.
Hope this helps in your project. Good luck.
yo...@terralogic.com
@he...@gmail.com: Thanks much for your code sharing. So along with your code spinet, do we need to put the following code in the Service.onCreate() and Service.onStartCommand()?
@Override
public void onCreate() {
super.onCreate();
int NOTIFICATION_ID = (int) (System.currentTimeMillis()%10000);
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
startForeground(NOTIFICATION_ID, new Notification.Builder(this).build());
}
}
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
super.onStartCommand(intent, flags, startId);
int NOTIFICATION_ID = (int) (System.currentTimeMillis()%10000);
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
startForeground(NOTIFICATION_ID, new Notification.Builder(this).build());
}
}
Thanks,
@Override
public void onCreate() {
super.onCreate();
int NOTIFICATION_ID = (int) (System.currentTimeMillis()%10000);
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
startForeground(NOTIFICATION_ID, new Notification.Builder(this).build());
}
}
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
super.onStartCommand(intent, flags, startId);
int NOTIFICATION_ID = (int) (System.currentTimeMillis()%10000);
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
startForeground(NOTIFICATION_ID, new Notification.Builder(this).build());
}
}
Thanks,
he...@gmail.com
No, you do not need to put following code in the Service.onCreate() and Service.onStartCommand(), they will not be called if the service cost more than 5 seconds to start. In my example code, startForeground() is called in forceForeground() method just after startForegroundService() method.
yo...@terralogic.com
Many thanks to he...@gmail.com for your being available to response. It is really helpful.
ro...@googlemail.com
I was seeing this crash *a lot* even though all code paths would trigger startForeground(). It seemed like calling startForeground() as early as in onCreate() did help a bit. However, I realized that my service often gets the job done very quickly. So I believe that in my case the real issue was that the service was stopping too quickly instead of starting foreground too late. So for Android O+ I removed the call to stopSelf() and instead let the system destroy the service normally after it's been idle for a minute. Every single crash went away: https://stackoverflow.com/a/53402038/467650
ma...@marcardar.com
#107 please can you create a sample project demonstrating this and create a new issue (since it won't be picked up here)?
[Deleted User] <[Deleted User]>
I found out that if we stop a service immediately after starting it, the method bringDownServiceLocked of ActiveServices.java is called before onCreate() of your foreground service. As you can see it checks the flag fgRequired which has to be reset to false by the service when we call startForeground(...) in it's onCreate(). Since onCreate() was not called yet, the flag is still true so the crash happens.
private final void bringDownServiceLocked(ServiceRecord r) {
...
if (r.fgRequired) {
Slog.w(TAG_SERVICE, "Bringing down service while still waiting for start foreground: "
+ r);
r.fgRequired = false;
r.fgWaiting = false;
mAm.mAppOpsService.finishOperation(AppOpsManager.getToken(mAm.mAppOpsService),
AppOpsManager.OP_START_FOREGROUND, r.appInfo.uid, r.packageName);
mAm.mHandler.removeMessages(
ActivityManagerService.SERVICE_FOREGROUND_TIMEOUT_MSG, r);
if (r.app != null) {
Message msg = mAm.mHandler.obtainMessage(
ActivityManagerService.SERVICE_FOREGROUND_CRASH_MSG);
msg.obj =r.app ;
msg.getData().putCharSequence(
ActivityManagerService.SERVICE_RECORD_KEY, r.toString());
mAm.mHandler.sendMessage(msg);
}
}
...
}
For more details and a workaround please check my SO answer:https://stackoverflow.com/a/53428900/1552622 .
private final void bringDownServiceLocked(ServiceRecord r) {
...
if (r.fgRequired) {
Slog.w(TAG_SERVICE, "Bringing down service while still waiting for start foreground: "
+ r);
r.fgRequired = false;
r.fgWaiting = false;
mAm.mAppOpsService.finishOperation(AppOpsManager.getToken(mAm.mAppOpsService),
AppOpsManager.OP_START_FOREGROUND, r.appInfo.uid, r.packageName);
mAm.mHandler.removeMessages(
ActivityManagerService.SERVICE_FOREGROUND_TIMEOUT_MSG, r);
if (
Message msg = mAm.mHandler.obtainMessage(
ActivityManagerService.SERVICE_FOREGROUND_CRASH_MSG);
msg.obj =
msg.getData().putCharSequence(
ActivityManagerService.SERVICE_RECORD_KEY, r.toString());
mAm.mHandler.sendMessage(msg);
}
}
...
}
For more details and a workaround please check my SO answer:
[Deleted User] <[Deleted User]>
delete
km...@lyft.com
This issue tracker has reports of our same issue. Comments that include "5 seconds" usually describe the issue. Here are some 19, 33, 37, 42, 50, 72, 103
From our breadcrumbs, it takes over 5 seconds for Android to start a foreground service.
...
27s before crash context.startForegroundService(new Intent(context, AppService.class));
21s before crash AppService onCreate
21s before crash AppService startForeground(notificationId, notification)
21s before crash AppService onStartCommand
android.app.RemoteServiceException: Context.startForegroundService() did not then call Service.startForeground()
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1881)
at android.os.Handler.dispatchMessage(Handler.java:105)
…
Foreground services are not a good way to declare new ANR exceptions. Issues unrelated to foreground services should not crash foreground services.
From our breadcrumbs, it takes over 5 seconds for Android to start a foreground service.
...
27s before crash context.startForegroundService(new Intent(context, AppService.class));
21s before crash AppService onCreate
21s before crash AppService startForeground(notificationId, notification)
21s before crash AppService onStartCommand
android.app.RemoteServiceException: Context.startForegroundService() did not then call Service.startForeground()
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1881)
at android.os.Handler.dispatchMessage(Handler.java:105)
…
Foreground services are not a good way to declare new ANR exceptions. Issues unrelated to foreground services should not crash foreground services.
[Deleted User] <[Deleted User]>
so, there's a solution to this; you need to make sure you don't call stop before they potentially long-delayed startForeground.
https://proandroiddev.com/pitfalls-of-a-foreground-service-lifecycle-59f014c6a125
ww...@gmail.com
I implemented everything nicely and I'm only seeing crashes in Android 8.0 running Samsung devices, not sure the reason why, is it Samsung fault or Android 8.0.
For other devices and other OS, I didn't see any crash.
I am attaching a screenshot for reference from Crashlytics (Firebase)
For other devices and other OS, I didn't see any crash.
I am attaching a screenshot for reference from Crashlytics (Firebase)
gb...@gmail.com
Same. I'm also facing the issue only on Samsung 8.0 devices.
ra...@comprovei.com
Tried all the solutions, still happening on android 8 devices. Specially in Samsung and Moto G 6.
pv...@swooby.com
Great fix! Who cares if it doesn't work on 50% of all of the devices in use out there?
Google/Android: Get your shit together, pretty please!
Fix issues like this and your god damn horrible Bluetooth/BLE stack!
Google/Android: Get your shit together, pretty please!
Fix issues like this and your god damn horrible Bluetooth/BLE stack!
a1...@gmail.com
It still happening on the device which version >= AndroidO.
mi...@onfleet.com
"After having same issue with same phones, I have made few changes and the crashes were gone. I am not sure what made the trick, but I am guessing that calling
startForeground in both onCreate and onStartCommand. I am not sure why that is needed if service is already started and everything was called properly in onCreate.
Other changes:
- Changing serviceId to some low number (1-10)
- Calling startFororegroundService less often through a singleton synchronous class (this was implemented before with the crashes to prevent stopping service before it started with a callback from onStartCommand, but now it also filters calls if service already started).
- using START_REDELIVER_INTENT (shouldn't affect anything)
The issue has been happening on the mentioned phones just for some users, so I suspect it is related to some new update from Samsung and will eventually be fixed"
wa...@gmail.com
Unfortunately this issue is still not resolved on variety of devices running Android 8.1 or 9.0 even when I have the majority of solutions already implemented.
ar...@gmail.com
Ok, something I noticed on this that might help a few others too. This is strictly from testing to see if I could figure out how to fix the occurrences I am seeing. For simplicity sake, let's say I have a method that calls this from the presenter.
context.startForegroundService(new Intent(context, TaskQueueExecutorService.class));
try {
Thread.sleep(10000);
} catch (InterruptedException e) {
e.printStackTrace();
}
This will crash with the same error. The Service will NOT start until the method is complete, therefore no onCreate() in the service.
So even if you update the UI off the main thread, IF you have anything that might hold up that method after it, it won't start on time and give you the dreaded Foreground Error. In my case we were loading some things onto a queue and each called startForegroundService, but some logic was involved with each. So if the logic took too long to finish that method, crash time. The old startService just ignored it and went on it's way and since we called it each time, the next round would finish up.
This left me wondering, if I called the service from a thread in the background, could it not be fully bound on the start and run immediately, so I started experimenting. Even though this does NOT start it immediately, it does not crash.
new Handler(Looper.getMainLooper()).post(new Runnable() {
public void run() {
context.startForegroundService(new Intent(context, TaskQueueExecutorService.class));
try {
Thread.sleep(10000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
});
I will not pretend to know why it does not crash. Maybe it does not allow the Service to get killed before it starts?
context.startForegroundService(new Intent(context, TaskQueueExecutorService.class));
try {
Thread.sleep(10000);
} catch (InterruptedException e) {
e.printStackTrace();
}
This will crash with the same error. The Service will NOT start until the method is complete, therefore no onCreate() in the service.
So even if you update the UI off the main thread, IF you have anything that might hold up that method after it, it won't start on time and give you the dreaded Foreground Error. In my case we were loading some things onto a queue and each called startForegroundService, but some logic was involved with each. So if the logic took too long to finish that method, crash time. The old startService just ignored it and went on it's way and since we called it each time, the next round would finish up.
This left me wondering, if I called the service from a thread in the background, could it not be fully bound on the start and run immediately, so I started experimenting. Even though this does NOT start it immediately, it does not crash.
new Handler(Looper.getMainLooper()).post(new Runnable() {
public void run() {
context.startForegroundService(new Intent(context, TaskQueueExecutorService.class));
try {
Thread.sleep(10000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
});
I will not pretend to know why it does not crash. Maybe it does not allow the Service to get killed before it starts?
pu...@gmail.com
I discovered there's more to it than just calling startForeground() "in time" in the Service's onCreate():
Even if you call startForeground() as the first statement of onCreate(), if your onCreate() takes more than 5s to run (for whatever reason, including some initialization operations that take an unusual amount
of time possibly only in some scenarios or devices), you will get the dreaded error.
I have a clear crash report that shows this for one my user where the service onCreate() takes nearly 9s (instead of the usual < 2s) for an obscure reason.
Even if you call startForeground() as the first statement of onCreate(), if your onCreate() takes more than 5s to run (for whatever reason, including some initialization operations that take an unusual amount
of time possibly only in some scenarios or devices), you will get the dreaded error.
I have a clear crash report that shows this for one my user where the service onCreate() takes nearly 9s (instead of the usual < 2s) for an obscure reason.
da...@gmail.com
I did quite exhaustive testing and found 2 situations where this can happen and your Service onCreate / onStartCommand won't be called in time.
1) If you have a foreground service that restarts itself (START_STICKY) and the application is killing in the background by the OS (due to low memory, low battery or other reasons). The process will be recreated again, but you will get the "did not then call Service.startForeground" if your Application.onCreate() hasn't finished within about 4.8 seconds. Your Service onCreate/onStartCommand will be only called after Application.onCreate(), so you have no chance to promote the service into foreground. You must make sure that your Application.onCreate will never take more than 5 seconds to finish.
How to test: Add a Thread.sleep(5000) into your application.onCreate(), launch the app, put it into background (hit HOME) and kill the process from AS. Now wait for the Service/Process to relaunch and observe crash (100% reproduce rate).
How to fix: profile your application.onCreate and make sure it's quick (or delay work after onCreate).
2) You can also kill the process while application.onCreate is in execution and it will trigger the same error, but this should not happen during regular use.
1) If you have a foreground service that restarts itself (START_STICKY) and the application is killing in the background by the OS (due to low memory, low battery or other reasons). The process will be recreated again, but you will get the "did not then call Service.startForeground" if your Application.onCreate() hasn't finished within about 4.8 seconds. Your Service onCreate/onStartCommand will be only called after Application.onCreate(), so you have no chance to promote the service into foreground. You must make sure that your Application.onCreate will never take more than 5 seconds to finish.
How to test: Add a Thread.sleep(5000) into your application.onCreate(), launch the app, put it into background (hit HOME) and kill the process from AS. Now wait for the Service/Process to relaunch and observe crash (100% reproduce rate).
How to fix: profile your application.onCreate and make sure it's quick (or delay work after onCreate).
2) You can also kill the process while application.onCreate is in execution and it will trigger the same error, but this should not happen during regular use.
pu...@gmail.com
I wonder how many of these corner case they are.
In my app I have an exit button (don't ask) that exits the app cleanly.
In that exit flow, a foreground service that runs for the lifetime of the app is stopped with stopService() resulting in onDestroy() is called on the Service.
Fine. But I have a few unexplained "Context.startForegroundService() did not then call Service.startForeground()" happening immediately after the service has been destroyed,
thrown in the main thread Looper. The only workaround I found for this issue, is to call System.exit() in the Service's onDestroy(), so whatever is later throwing that Exception has never a chance to run.
I'm still clueless how this can be happening as the Service in question has been started and startForeground() called in time.
In my app I have an exit button (don't ask) that exits the app cleanly.
In that exit flow, a foreground service that runs for the lifetime of the app is stopped with stopService() resulting in onDestroy() is called on the Service.
Fine. But I have a few unexplained "Context.startForegroundService() did not then call Service.startForeground()" happening immediately after the service has been destroyed,
thrown in the main thread Looper. The only workaround I found for this issue, is to call System.exit() in the Service's onDestroy(), so whatever is later throwing that Exception has never a chance to run.
I'm still clueless how this can be happening as the Service in question has been started and startForeground() called in time.
pu...@gmail.com
startForegroundService() has to be one of the worse API ever created.
I still have crash reports and after re-reading this thread for the nth time, re-reading the Android docs and Service lifecycle again and again, re-read my code and spent (again) and afternoon trying to understand it...
I still have zero clue in which scenario this crash happen.
A user has contacted me and he can reproduce it semi-reliably but I've been absolutly unable to reproduce it on my test device.
This issue is maddening. I'll stop there.
I still have crash reports and after re-reading this thread for the nth time, re-reading the Android docs and Service lifecycle again and again, re-read my code and spent (again) and afternoon trying to understand it...
I still have zero clue in which scenario this crash happen.
A user has contacted me and he can reproduce it semi-reliably but I've been absolutly unable to reproduce it on my test device.
This issue is maddening. I'll stop there.
ma...@gmail.com
Calling this "Intended Behavior, Won't Fix" is very Google.
This api is so broken, I don't know why we even bother.
This api is so broken, I don't know why we even bother.
bo...@gmail.com
I have same problem event without explicit startForegroundService() calling, in my app I have only startService() and then if need inside service it calls startForeground(). But in some devices I see ANR with Context.startForegroundService() did not then call Service.startForeground.
I believe system re-create for some reason service and if it was marked before inside as foreground by Service.startForeground system thinking that startForegroundService() has been called to start it before?!
I believe system re-create for some reason service and if it was marked before inside as foreground by Service.startForeground system thinking that startForegroundService() has been called to start it before?!
kr...@gmail.com
How can a fatal crash because of changes in the framework become 'intended behavior'? It seems that the Android ecosystem has grown to the point where Google just doesn't care about developers anymore.
em...@gmail.com
Has this problem been fixed yet? It leads so many crash.
se...@gmail.com
al...@gmail.com
I also observe the same issue. Seems that the service isn't started quick enough and the app doesn't even have a chance to call the startForeground() method.
ni...@gmail.com
Also observing the same issue on Huawei devices running Android 9
th...@gmail.com
Is it solved? How is it going now?
I got this exception in about 0.04% crash rate, even if in 5 seconds. you can see one of my custom logs by firebase crashlytics:
my firebase crashlytics custom log when crash occurs, 06:59:36 shows startForegroundService and 06:59:37 shows startForegroundFullOs:
# Crashlytics - Custom logs
# Application: com.***.***
# Platform: android
# Version: v1.1.5 (28)
# Issue: 307965107a8c83a894765f0f39ecf0b0
# Session: 5E408ED7026C0001144DADD100F1E758_DNE_0_v2
# Date: Mon Feb 10 2020 06:59:00 GMT+0800 (CST)
0 | Mon Feb 10 2020 06:59:36 GMT+0800 (CST) | D/ContextUtil startForegroundService
1 | Mon Feb 10 2020 06:59:37 GMT+0800 (CST) | D/SleepSamplingService onCreate
2 | Mon Feb 10 2020 06:59:37 GMT+0800 (CST) | D/SleepSamplingService startForegroundFullOs
3 | Mon Feb 10 2020 06:59:37 GMT+0800 (CST) | D/SleepSamplingService startForegroundFullOs
4 | Mon Feb 10 2020 06:59:42 GMT+0800 (CST) | D/AlarmForegroundService onCreate
5 | Mon Feb 10 2020 06:59:42 GMT+0800 (CST) | D/AlarmForegroundService startForegroundFullOs
6 | Mon Feb 10 2020 06:59:42 GMT+0800 (CST) | D/AlarmForegroundService startForegroundFullOs
7 | Mon Feb 10 2020 06:59:42 GMT+0800 (CST) | D/AlarmForegroundService startForegroundFullOs
8 | Mon Feb 10 2020 06:59:43 GMT+0800 (CST) | D/AlarmService cancelNotification, tag = AlarmForegroundService
9 | Mon Feb 10 2020 06:59:43 GMT+0800 (CST) | D/ContextUtil startForegroundService
10 | Mon Feb 10 2020 06:59:43 GMT+0800 (CST) | D/AlarmForegroundService onDestroy
I got this exception in about 0.04% crash rate, even if in 5 seconds. you can see one of my custom logs by firebase crashlytics:
my firebase crashlytics custom log when crash occurs, 06:59:36 shows startForegroundService and 06:59:37 shows startForegroundFullOs:
# Crashlytics - Custom logs
# Application: com.***.***
# Platform: android
# Version: v1.1.5 (28)
# Issue: 307965107a8c83a894765f0f39ecf0b0
# Session: 5E408ED7026C0001144DADD100F1E758_DNE_0_v2
# Date: Mon Feb 10 2020 06:59:00 GMT+0800 (CST)
0 | Mon Feb 10 2020 06:59:36 GMT+0800 (CST) | D/ContextUtil startForegroundService
1 | Mon Feb 10 2020 06:59:37 GMT+0800 (CST) | D/SleepSamplingService onCreate
2 | Mon Feb 10 2020 06:59:37 GMT+0800 (CST) | D/SleepSamplingService startForegroundFullOs
3 | Mon Feb 10 2020 06:59:37 GMT+0800 (CST) | D/SleepSamplingService startForegroundFullOs
4 | Mon Feb 10 2020 06:59:42 GMT+0800 (CST) | D/AlarmForegroundService onCreate
5 | Mon Feb 10 2020 06:59:42 GMT+0800 (CST) | D/AlarmForegroundService startForegroundFullOs
6 | Mon Feb 10 2020 06:59:42 GMT+0800 (CST) | D/AlarmForegroundService startForegroundFullOs
7 | Mon Feb 10 2020 06:59:42 GMT+0800 (CST) | D/AlarmForegroundService startForegroundFullOs
8 | Mon Feb 10 2020 06:59:43 GMT+0800 (CST) | D/AlarmService cancelNotification, tag = AlarmForegroundService
9 | Mon Feb 10 2020 06:59:43 GMT+0800 (CST) | D/ContextUtil startForegroundService
10 | Mon Feb 10 2020 06:59:43 GMT+0800 (CST) | D/AlarmForegroundService onDestroy
th...@gmail.com
another log:
# Crashlytics - Custom logs
# Application: com.***.***
# Platform: android
# Version: v1.1.5 (28)
# Issue: 307965107a8c83a894765f0f39ecf0b0
# Session: 5E3C7D4401E500016644003F47E5ADCB_DNE_0_v2
# Date: Fri Feb 07 2020 04:55:37 GMT+0800 (CST)
0 | Fri Feb 07 2020 04:55:37 GMT+0800 (CST) | D/ContextUtil startForegroundService
1 | Fri Feb 07 2020 04:55:37 GMT+0800 (CST) | D/SplashActivity onCreate
2 | Fri Feb 07 2020 04:55:37 GMT+0800 (CST) | Splash_Show
3 | Fri Feb 07 2020 04:55:43 GMT+0800 (CST) | D/AlarmForegroundService onCreate
4 | Fri Feb 07 2020 04:55:43 GMT+0800 (CST) | D/AlarmForegroundService startForegroundFullOs
5 | Fri Feb 07 2020 04:55:44 GMT+0800 (CST) | D/AlarmForegroundService startForegroundFullOs
6 | Fri Feb 07 2020 04:55:44 GMT+0800 (CST) | D/AlarmForegroundService startForegroundFullOs
7 | Fri Feb 07 2020 04:55:44 GMT+0800 (CST) | D/SplashActivity onDestroy
8 | Fri Feb 07 2020 04:55:44 GMT+0800 (CST) | D/SplashActivity onCreate
9 | Fri Feb 07 2020 04:55:44 GMT+0800 (CST) | Ad_Result_Request
10 | Fri Feb 07 2020 04:55:44 GMT+0800 (CST) | D/AlarmService cancelNotification, tag = AlarmForegroundService
# Crashlytics - Custom logs
# Application: com.***.***
# Platform: android
# Version: v1.1.5 (28)
# Issue: 307965107a8c83a894765f0f39ecf0b0
# Session: 5E3C7D4401E500016644003F47E5ADCB_DNE_0_v2
# Date: Fri Feb 07 2020 04:55:37 GMT+0800 (CST)
0 | Fri Feb 07 2020 04:55:37 GMT+0800 (CST) | D/ContextUtil startForegroundService
1 | Fri Feb 07 2020 04:55:37 GMT+0800 (CST) | D/SplashActivity onCreate
2 | Fri Feb 07 2020 04:55:37 GMT+0800 (CST) | Splash_Show
3 | Fri Feb 07 2020 04:55:43 GMT+0800 (CST) | D/AlarmForegroundService onCreate
4 | Fri Feb 07 2020 04:55:43 GMT+0800 (CST) | D/AlarmForegroundService startForegroundFullOs
5 | Fri Feb 07 2020 04:55:44 GMT+0800 (CST) | D/AlarmForegroundService startForegroundFullOs
6 | Fri Feb 07 2020 04:55:44 GMT+0800 (CST) | D/AlarmForegroundService startForegroundFullOs
7 | Fri Feb 07 2020 04:55:44 GMT+0800 (CST) | D/SplashActivity onDestroy
8 | Fri Feb 07 2020 04:55:44 GMT+0800 (CST) | D/SplashActivity onCreate
9 | Fri Feb 07 2020 04:55:44 GMT+0800 (CST) | Ad_Result_Request
10 | Fri Feb 07 2020 04:55:44 GMT+0800 (CST) | D/AlarmService cancelNotification, tag = AlarmForegroundService
ct...@google.com
This typically means that your app is routinely stalling its main thread doing other work while the foreground service start is pending. (Broadcast handling without goAsync() is one example.) That would indicate an app bug: it's unsafe to use the main looper thread for any work that might take several seconds to complete.
For example, see #133:
0 | Fri Feb 07 2020 04:55:37 GMT+0800 (CST) | D/ContextUtil startForegroundService
1 | Fri Feb 07 2020 04:55:37 GMT+0800 (CST) | D/SplashActivity onCreate
2 | Fri Feb 07 2020 04:55:37 GMT+0800 (CST) | Splash_Show
3 | Fri Feb 07 2020 04:55:43 GMT+0800 (CST) | D/AlarmForegroundService onCreate
4 | Fri Feb 07 2020 04:55:43 GMT+0800 (CST) | D/AlarmForegroundService startForegroundFullOs
I'm guessing this is on Android 8 (O) -- the timeout was raised to 10 seconds in Android 9 (P). Six seconds from startForegroundService() to the service actually being instantiated implies that something is inappropriately monopolizing the main looper thread. In particular, what is going on between Splash_Show and the service instance being created? That's deeply suspicious.
Re #126: "I have same problem event without explicit startForegroundService() calling, in my app I have only startService() and then if need inside service it calls startForeground(). But in some devices I see ANR with Context.startForegroundService() did not then call Service.startForeground."
This cannot happen in Android as delivered to AOSP: the "...did not then call Service.startForeground" timeout is *only* engaged in response to a call to startForegroundService(). What OEM / product / version of Android are you seeing this on?
For example, see #133:
0 | Fri Feb 07 2020 04:55:37 GMT+0800 (CST) | D/ContextUtil startForegroundService
1 | Fri Feb 07 2020 04:55:37 GMT+0800 (CST) | D/SplashActivity onCreate
2 | Fri Feb 07 2020 04:55:37 GMT+0800 (CST) | Splash_Show
3 | Fri Feb 07 2020 04:55:43 GMT+0800 (CST) | D/AlarmForegroundService onCreate
4 | Fri Feb 07 2020 04:55:43 GMT+0800 (CST) | D/AlarmForegroundService startForegroundFullOs
I'm guessing this is on Android 8 (O) -- the timeout was raised to 10 seconds in Android 9 (P). Six seconds from startForegroundService() to the service actually being instantiated implies that something is inappropriately monopolizing the main looper thread. In particular, what is going on between Splash_Show and the service instance being created? That's deeply suspicious.
Re #126: "I have same problem event without explicit startForegroundService() calling, in my app I have only startService() and then if need inside service it calls startForeground(). But in some devices I see ANR with Context.startForegroundService() did not then call Service.startForeground."
This cannot happen in Android as delivered to AOSP: the "...did not then call Service.startForeground" timeout is *only* engaged in response to a call to startForegroundService(). What OEM / product / version of Android are you seeing this on?
to...@gmail.com
#134 ct....@google are there any changes made to Android 11 about that since communication have been stopped here on the internal bug.
I still have "Context.startForegroundService() did not then call Service.startForeground()" with my application not even yet started (Attached stack trace on Android 9 / Nokia 5.1)
My application should not be counted as an ANR for the system not able to properly start the application in time. For external calls, time should start from the end of the application.onCreate() return at least.
"main" prio=5 tid=1 Native | group="main" sCount=1 dsCount=0 flags=1 obj=0x74401b48 self=0x7b34014c00 | sysTid=22258 nice=0 cgrp=default sched=0/0 handle=0x7bba84b548 | state=R schedstat=( 429207992 365816403 2448 ) utm=5 stm=37 core=2 HZ=100 | stack=0x7ff4246000-0x7ff4248000 stackSize=8MB | held mutexes= #00 pc 0000000000032d04 /system/lib64/libandroidfw.so (android::ResTable_config::copyFromDtoH(android::ResTable_config const&)+12) #01 pc 0000000000024064 /system/lib64/libandroidfw.so (android::AssetManager2::RebuildFilterList()+276) #02 pc 0000000000023984 /system/lib64/libandroidfw.so (android::AssetManager2::SetApkAssets(std::__1::vector<android::ApkAssets const*, std::__1::allocator<android::ApkAssets const*>> const&, bool)+60) #03 pc 000000000012c9bc /system/lib64/libandroid_runtime.so (android::NativeSetApkAssets(_JNIEnv*, _jclass*, long, _jobjectArray*, unsigned char)+332) at android.content.res.AssetManager.nativeSetApkAssets (Native method) at android.content.res.AssetManager.access$300 (AssetManager.java:57) at android.content.res.AssetManager$Builder.build (AssetManager.java:145) at android.app.ResourcesManager.createAssetManager (ResourcesManager.java:411) at android.app.ResourcesManager.createResourcesImpl (ResourcesManager.java:490) at android.app.ResourcesManager.getOrCreateResources (ResourcesManager.java:787)
- locked <0x0d35c7d2> (a android.app.ResourcesManager) at android.app.ResourcesManager.getResources (ResourcesManager.java:853) at android.app.LoadedApk.getResources (LoadedApk.java:1029) at android.app.ContextImpl.createAppContext (ContextImpl.java:2346) at android.app.ActivityThread.handleBindApplication (ActivityThread.java:5789) at android.app.ActivityThread.access$1200 (ActivityThread.java:208) at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1680) at android.os.Handler.dispatchMessage (Handler.java:106) at android.os.Looper.loop (Looper.java:193) at android.app.ActivityThread.main (ActivityThread.java:6715) at java.lang.reflect.Method.invoke (Native method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:493) at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:911)
ct...@google.com
Timeouts never rely on in-app milestones or execution behavior, because that is manipulable by the app.
The unfortunate short answer here is that if your app takes 10 seconds to launch, that is its own problem, and needs to be addressed to make sure your app is responsive.
Also, if you're launching directly into the startForegroundService() lifecycle flow, it means you're using a foreground-service PendingIntent to do that. You have alternatives that will let you launch & pay the cost of your heavy static init prior to the startForegroundService() call: in particular, a broadcast PendingIntent trigger rather than an immediate fg service start.
The unfortunate short answer here is that if your app takes 10 seconds to launch, that is its own problem, and needs to be addressed to make sure your app is responsive.
Also, if you're launching directly into the startForegroundService() lifecycle flow, it means you're using a foreground-service PendingIntent to do that. You have alternatives that will let you launch & pay the cost of your heavy static init prior to the startForegroundService() call: in particular, a broadcast PendingIntent trigger rather than an immediate fg service start.
to...@gmail.com
You miss read the stack trace :) My application is fast to start and overly optimised, the ANR occurs before even reaching my code or Application.onCreate() (FTR I'm under 0,01% ANR rate on Play Console)
In this case my application is publishing a stable API that is based on that service to be used from other applications and has been since more than 6 years now (the API, the app is 8), I have no willing to break all the unknown consumers because Android have decided to put timeouts on things that are out of controls of devs.
ct...@google.com
The question re your stack trace is "what have you done in your apk that has caused resource initialization to take 10 seconds....?"
to...@gmail.com
It would be funny if your mail did not ended up with @Google.com :)
I have done nothing as I said the application is highly optimized and Play Console does confirm that I'm better in all vitals than most of the Play Store. (
This is just how Android works on constrained devices that can have disk queue saturated. If you are not aware of those basics issues when reaching millions devices then maybe it's normal this issue is still not properly addressed.
ct...@google.com
Ah, are you seeing this specifically on a particular product/hardware demographic? That's good info -- can you share some details?
to...@gmail.com
It's quite rare but happens on many different low end to medium end devices. I do not see demographics in Play Console and I've stopped using firebase (And even with it AFAIK ANR are not reported) Play console only have 60 days history and any slight variation leads to another line without a way to export to consolidate the data so it's not easy and as it's 100% out of my control I did not tried to do that consolidation job.
Another kind of reasons is
"main" prio=5 tid=1 Native
| group="main" sCount=1 dsCount=0 obj=0x76d898d0 self=0x789fea1a00
| sysTid=9391 nice=0 cgrp=default sched=0/0 handle=0x78a3e82a98
| state=S schedstat=( 79785939 414062 349 ) utm=6 stm=1 core=3 HZ=100
| stack=0x7fc95fb000-0x7fc95fd000 stackSize=8MB
| held mutexes=
at java.io.UnixFileSystem.canonicalize0 (Native method)
at java.io.UnixFileSystem.canonicalize (UnixFileSystem.java:147)
at java.io.File.getCanonicalPath (File.java:586)
at java.io.File.getCanonicalFile (File.java:611)
at androidx.core.content.FileProvider.b (FileProvider.java:33)
at androidx.core.content.FileProvider.a (FileProvider.java:20)
- locked <0x0e2e93d5> (a java.util.HashMap)
at androidx.core.content.FileProvider.attachInfo (FileProvider.java:4)
at android.app.ActivityThread.installProvider (ActivityThread.java:6197)
at android.app.ActivityThread.installContentProviders (ActivityThread.java:5715)
at android.app.ActivityThread.handleBindApplication (ActivityThread.java:5636)
at android.app.ActivityThread.-wrap2 (ActivityThread.java)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1637)
at android.os.Handler.dispatchMessage (Handler.java:105)
at android.os.Looper.loop (Looper.java:156)
at android.app.ActivityThread.main (ActivityThread.java:6517)
at java.lang.reflect.Method.invoke! (Native method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:942)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:832)
did report to AndroidX but was told that if I can't reproduce on a pixel then no one cares and issue was closed. But that one is internal to the app so can be considered an app problem.
The other issue clearly is not under control and in all cases this proves that on constrained devices a very large part or all of the allowed time to call startForeground can be consumed before even reaching the application. While those timeouts sounds reasonable when calling the service from the own application process, some better handling should be done when it's from pending intents and app is not running (Widgets, other applications, ...)
ne...@gmail.com
Let me just jump in quickly to highlight a demographic I've been seeing it on:
- 5,9 % Samsung Galaxy S10
- 3,7 % Huawei P30 Lite
- 3,7 % Samsung Galaxy S9 (starqltesq)
- 3,4 % Samsung A70
- 3,2 % Samsung Galaxy S9 (starlte)
- 2,9 % Samsung Galaxy A30
..And the rest are still mostly Samsung devices with the occasional Huawei. Definitely a trend there. Also only devices with Android 8.1 and up, none with 8. This data comes from the Play Console, where it does register as crash as well as an ANR, but the crash doesn't have a stack trace and it took me a while to figure out that it really was the same thing. Fabric/Firebase does register the crash with a stack trace that makes sense, and according to that, it's 100% high-end Samsung devices.
And btw I'm absolutely positive this issue has nothing to do with an application doing a lot of work while starting.
ct...@google.com
I agree -- especially with that incidence demographic. That's a strong suggestion that at bottom this could well be a bug introduced by Samsung in modifying the Android framework for those devices. :(
ma...@marcardar.com
Shouldn't the CTS cover this?
to...@gmail.com
Let's not mix everything, the slow resources loading is certainly not Samsung only my last reports are Nokia and Pixel 1.
I have no idea where the give numbers comes from and what they represent so let's not build theories on out of context numbers.
sl...@gmail.com
another log even startForegroundService(08:31:10) and startForegroundFullOs(08:31:10) called in 5s:
# Crashlytics - Custom logs
# Application: com.mypackage.aio
# Platform: android
# Version: v1.1.8 (36)
# Issue: 0f763b81d15b3b03db0d4f77036de274
# Session: 5E66DF7702EB00011651253E32EBDA26_DNE_0_v2
# Date: Tue Mar 10 2020 09:43:00 GMT+0800 (中国标准时间)
0 | Tue Mar 10 2020 08:29:43 GMT+0800 (中国标准时间) | D/SplashActivity onCreate 1
1 | Tue Mar 10 2020 08:29:46 GMT+0800 (中国标准时间) | D/SplashActivity onDestroy 0
2 | Tue Mar 10 2020 08:29:50 GMT+0800 (中国标准时间) | Guide2_New_Show
3 | Tue Mar 10 2020 08:29:51 GMT+0800 (中国标准时间) | Guide3_New_Show
4 | Tue Mar 10 2020 08:29:56 GMT+0800 (中国标准时间) | Guide2_New_Show
5 | Tue Mar 10 2020 08:29:57 GMT+0800 (中国标准时间) | Guide1_New_Show
6 | Tue Mar 10 2020 08:30:41 GMT+0800 (中国标准时间) | D/SplashActivity onCreate 1
7 | Tue Mar 10 2020 08:30:42 GMT+0800 (中国标准时间) | Splash_Show
8 | Tue Mar 10 2020 08:30:42 GMT+0800 (中国标准时间) | Ad_Result_Request
9 | Tue Mar 10 2020 08:30:42 GMT+0800 (中国标准时间) | screen_view
10 | Tue Mar 10 2020 08:30:44 GMT+0800 (中国标准时间) | D/VipGuideActivity onCreate 2
11 | Tue Mar 10 2020 08:30:44 GMT+0800 (中国标准时间) | Guide_Special_Show
12 | Tue Mar 10 2020 08:30:44 GMT+0800 (中国标准时间) | screen_view
13 | Tue Mar 10 2020 08:30:44 GMT+0800 (中国标准时间) | D/SplashActivity onDestroy 1
14 | Tue Mar 10 2020 08:30:45 GMT+0800 (中国标准时间) | Guide_Special_btnSubscribe
15 | Tue Mar 10 2020 08:30:45 GMT+0800 (中国标准时间) | D/RxView onClick, deltaClickTime = 1583800246092
16 | Tue Mar 10 2020 08:30:45 GMT+0800 (中国标准时间) | screen_view
17 | Tue Mar 10 2020 08:30:48 GMT+0800 (中国标准时间) | Guide_Special_Profail
18 | Tue Mar 10 2020 08:30:48 GMT+0800 (中国标准时间) | screen_view
19 | Tue Mar 10 2020 08:30:50 GMT+0800 (中国标准时间) | D/RxView onClick, deltaClickTime = 1583800250962
20 | Tue Mar 10 2020 08:30:50 GMT+0800 (中国标准时间) | Guide_Special_btnSkip
21 | Tue Mar 10 2020 08:30:50 GMT+0800 (中国标准时间) | D/MainActivity onCreate 2
22 | Tue Mar 10 2020 08:30:50 GMT+0800 (中国标准时间) | D/SleepFragment R.drawable.sleep_drink_selector = 7f08014c
23 | Tue Mar 10 2020 08:30:50 GMT+0800 (中国标准时间) | screen_view
24 | Tue Mar 10 2020 08:30:50 GMT+0800 (中国标准时间) | D/VolumeSampleDbHelper get
25 | Tue Mar 10 2020 08:30:50 GMT+0800 (中国标准时间) | Sleep_Show
26 | Tue Mar 10 2020 08:30:51 GMT+0800 (中国标准时间) | screen_view
27 | Tue Mar 10 2020 08:30:51 GMT+0800 (中国标准时间) | D/VipGuideActivity onDestroy 1
28 | Tue Mar 10 2020 08:30:55 GMT+0800 (中国标准时间) | screen_view
29 | Tue Mar 10 2020 08:30:58 GMT+0800 (中国标准时间) | Records_noData_Show
30 | Tue Mar 10 2020 08:30:58 GMT+0800 (中国标准时间) | Ad_Records_Request
31 | Tue Mar 10 2020 08:30:58 GMT+0800 (中国标准时间) | Records_Show
32 | Tue Mar 10 2020 08:30:59 GMT+0800 (中国标准时间) | More_Show
33 | Tue Mar 10 2020 08:31:00 GMT+0800 (中国标准时间) | Sleep_Show
34 | Tue Mar 10 2020 08:31:01 GMT+0800 (中国标准时间) | Sleep_btnAlcohol
35 | Tue Mar 10 2020 08:31:02 GMT+0800 (中国标准时间) | Sleep_btnAlcohol
36 | Tue Mar 10 2020 08:31:02 GMT+0800 (中国标准时间) | Sleep_btnAteLate
37 | Tue Mar 10 2020 08:31:03 GMT+0800 (中国标准时间) | Sleep_btnAteLate
38 | Tue Mar 10 2020 08:31:05 GMT+0800 (中国标准时间) | Sleep_btnCaffeine
39 | Tue Mar 10 2020 08:31:05 GMT+0800 (中国标准时间) | Sleep_btnCaffeine
40 | Tue Mar 10 2020 08:31:06 GMT+0800 (中国标准时间) | D/RxView onClick, deltaClickTime = 1583800266779
41 | Tue Mar 10 2020 08:31:06 GMT+0800 (中国标准时间) | Sleep_btnStartSleep
42 | Tue Mar 10 2020 08:31:06 GMT+0800 (中国标准时间) | Ad_Result_Request
43 | Tue Mar 10 2020 08:31:06 GMT+0800 (中国标准时间) | Sleep_Guide3_Show
44 | Tue Mar 10 2020 08:31:06 GMT+0800 (中国标准时间) | screen_view
45 | Tue Mar 10 2020 08:31:10 GMT+0800 (中国标准时间) | Ad_Records_Request
46 | Tue Mar 10 2020 08:31:10 GMT+0800 (中国标准时间) | screen_view
47 | Tue Mar 10 2020 08:31:10 GMT+0800 (中国标准时间) | D/SleepingActivity onCreate 2
48 | Tue Mar 10 2020 08:31:10 GMT+0800 (中国标准时间) | D/ContextUtil startForegroundService, com.mypackage.control.SleepSamplingService
49 | Tue Mar 10 2020 08:31:10 GMT+0800 (中国标准时间) | Sleep_AccelGuide_Show
50 | Tue Mar 10 2020 08:31:10 GMT+0800 (中国标准时间) | D/SleepSamplingService onCreate
51 | Tue Mar 10 2020 08:31:10 GMT+0800 (中国标准时间) | screen_view
52 | Tue Mar 10 2020 08:31:10 GMT+0800 (中国标准时间) | D/SleepSamplingService startForegroundFullOs
53 | Tue Mar 10 2020 08:31:10 GMT+0800 (中国标准时间) | D/SleepSamplingService startForegroundFullOs
54 | Tue Mar 10 2020 08:31:10 GMT+0800 (中国标准时间) | D/SleepingActivity onKeyDown keyCode=4
55 | Tue Mar 10 2020 08:31:10 GMT+0800 (中国标准时间) | D/SleepSamplingService onDestroy
56 | Tue Mar 10 2020 08:31:10 GMT+0800 (中国标准时间) | D/Mp3DbHelper get
57 | Tue Mar 10 2020 08:31:10 GMT+0800 (中国标准时间) | Ad_Records_Request
58 | Tue Mar 10 2020 08:31:10 GMT+0800 (中国标准时间) | screen_view
59 | Tue Mar 10 2020 08:31:11 GMT+0800 (中国标准时间) | D/SleepingActivity onDestroy 1
# Crashlytics - Custom logs
# Application: com.mypackage.aio
# Platform: android
# Version: v1.1.8 (36)
# Issue: 0f763b81d15b3b03db0d4f77036de274
# Session: 5E66DF7702EB00011651253E32EBDA26_DNE_0_v2
# Date: Tue Mar 10 2020 09:43:00 GMT+0800 (中国标准时间)
0 | Tue Mar 10 2020 08:29:43 GMT+0800 (中国标准时间) | D/SplashActivity onCreate 1
1 | Tue Mar 10 2020 08:29:46 GMT+0800 (中国标准时间) | D/SplashActivity onDestroy 0
2 | Tue Mar 10 2020 08:29:50 GMT+0800 (中国标准时间) | Guide2_New_Show
3 | Tue Mar 10 2020 08:29:51 GMT+0800 (中国标准时间) | Guide3_New_Show
4 | Tue Mar 10 2020 08:29:56 GMT+0800 (中国标准时间) | Guide2_New_Show
5 | Tue Mar 10 2020 08:29:57 GMT+0800 (中国标准时间) | Guide1_New_Show
6 | Tue Mar 10 2020 08:30:41 GMT+0800 (中国标准时间) | D/SplashActivity onCreate 1
7 | Tue Mar 10 2020 08:30:42 GMT+0800 (中国标准时间) | Splash_Show
8 | Tue Mar 10 2020 08:30:42 GMT+0800 (中国标准时间) | Ad_Result_Request
9 | Tue Mar 10 2020 08:30:42 GMT+0800 (中国标准时间) | screen_view
10 | Tue Mar 10 2020 08:30:44 GMT+0800 (中国标准时间) | D/VipGuideActivity onCreate 2
11 | Tue Mar 10 2020 08:30:44 GMT+0800 (中国标准时间) | Guide_Special_Show
12 | Tue Mar 10 2020 08:30:44 GMT+0800 (中国标准时间) | screen_view
13 | Tue Mar 10 2020 08:30:44 GMT+0800 (中国标准时间) | D/SplashActivity onDestroy 1
14 | Tue Mar 10 2020 08:30:45 GMT+0800 (中国标准时间) | Guide_Special_btnSubscribe
15 | Tue Mar 10 2020 08:30:45 GMT+0800 (中国标准时间) | D/RxView onClick, deltaClickTime = 1583800246092
16 | Tue Mar 10 2020 08:30:45 GMT+0800 (中国标准时间) | screen_view
17 | Tue Mar 10 2020 08:30:48 GMT+0800 (中国标准时间) | Guide_Special_Profail
18 | Tue Mar 10 2020 08:30:48 GMT+0800 (中国标准时间) | screen_view
19 | Tue Mar 10 2020 08:30:50 GMT+0800 (中国标准时间) | D/RxView onClick, deltaClickTime = 1583800250962
20 | Tue Mar 10 2020 08:30:50 GMT+0800 (中国标准时间) | Guide_Special_btnSkip
21 | Tue Mar 10 2020 08:30:50 GMT+0800 (中国标准时间) | D/MainActivity onCreate 2
22 | Tue Mar 10 2020 08:30:50 GMT+0800 (中国标准时间) | D/SleepFragment R.drawable.sleep_drink_selector = 7f08014c
23 | Tue Mar 10 2020 08:30:50 GMT+0800 (中国标准时间) | screen_view
24 | Tue Mar 10 2020 08:30:50 GMT+0800 (中国标准时间) | D/VolumeSampleDbHelper get
25 | Tue Mar 10 2020 08:30:50 GMT+0800 (中国标准时间) | Sleep_Show
26 | Tue Mar 10 2020 08:30:51 GMT+0800 (中国标准时间) | screen_view
27 | Tue Mar 10 2020 08:30:51 GMT+0800 (中国标准时间) | D/VipGuideActivity onDestroy 1
28 | Tue Mar 10 2020 08:30:55 GMT+0800 (中国标准时间) | screen_view
29 | Tue Mar 10 2020 08:30:58 GMT+0800 (中国标准时间) | Records_noData_Show
30 | Tue Mar 10 2020 08:30:58 GMT+0800 (中国标准时间) | Ad_Records_Request
31 | Tue Mar 10 2020 08:30:58 GMT+0800 (中国标准时间) | Records_Show
32 | Tue Mar 10 2020 08:30:59 GMT+0800 (中国标准时间) | More_Show
33 | Tue Mar 10 2020 08:31:00 GMT+0800 (中国标准时间) | Sleep_Show
34 | Tue Mar 10 2020 08:31:01 GMT+0800 (中国标准时间) | Sleep_btnAlcohol
35 | Tue Mar 10 2020 08:31:02 GMT+0800 (中国标准时间) | Sleep_btnAlcohol
36 | Tue Mar 10 2020 08:31:02 GMT+0800 (中国标准时间) | Sleep_btnAteLate
37 | Tue Mar 10 2020 08:31:03 GMT+0800 (中国标准时间) | Sleep_btnAteLate
38 | Tue Mar 10 2020 08:31:05 GMT+0800 (中国标准时间) | Sleep_btnCaffeine
39 | Tue Mar 10 2020 08:31:05 GMT+0800 (中国标准时间) | Sleep_btnCaffeine
40 | Tue Mar 10 2020 08:31:06 GMT+0800 (中国标准时间) | D/RxView onClick, deltaClickTime = 1583800266779
41 | Tue Mar 10 2020 08:31:06 GMT+0800 (中国标准时间) | Sleep_btnStartSleep
42 | Tue Mar 10 2020 08:31:06 GMT+0800 (中国标准时间) | Ad_Result_Request
43 | Tue Mar 10 2020 08:31:06 GMT+0800 (中国标准时间) | Sleep_Guide3_Show
44 | Tue Mar 10 2020 08:31:06 GMT+0800 (中国标准时间) | screen_view
45 | Tue Mar 10 2020 08:31:10 GMT+0800 (中国标准时间) | Ad_Records_Request
46 | Tue Mar 10 2020 08:31:10 GMT+0800 (中国标准时间) | screen_view
47 | Tue Mar 10 2020 08:31:10 GMT+0800 (中国标准时间) | D/SleepingActivity onCreate 2
48 | Tue Mar 10 2020 08:31:10 GMT+0800 (中国标准时间) | D/ContextUtil startForegroundService, com.mypackage.control.SleepSamplingService
49 | Tue Mar 10 2020 08:31:10 GMT+0800 (中国标准时间) | Sleep_AccelGuide_Show
50 | Tue Mar 10 2020 08:31:10 GMT+0800 (中国标准时间) | D/SleepSamplingService onCreate
51 | Tue Mar 10 2020 08:31:10 GMT+0800 (中国标准时间) | screen_view
52 | Tue Mar 10 2020 08:31:10 GMT+0800 (中国标准时间) | D/SleepSamplingService startForegroundFullOs
53 | Tue Mar 10 2020 08:31:10 GMT+0800 (中国标准时间) | D/SleepSamplingService startForegroundFullOs
54 | Tue Mar 10 2020 08:31:10 GMT+0800 (中国标准时间) | D/SleepingActivity onKeyDown keyCode=4
55 | Tue Mar 10 2020 08:31:10 GMT+0800 (中国标准时间) | D/SleepSamplingService onDestroy
56 | Tue Mar 10 2020 08:31:10 GMT+0800 (中国标准时间) | D/Mp3DbHelper get
57 | Tue Mar 10 2020 08:31:10 GMT+0800 (中国标准时间) | Ad_Records_Request
58 | Tue Mar 10 2020 08:31:10 GMT+0800 (中国标准时间) | screen_view
59 | Tue Mar 10 2020 08:31:11 GMT+0800 (中国标准时间) | D/SleepingActivity onDestroy 1
ne...@gmail.com
"Let's not mix everything, the slow resources loading is certainly not Samsung only my last reports are Nokia and Pixel 1.
I have no idea where the give numbers comes from and what they represent so let's not build theories on out of context numbers."
Will all due respect: lol.
The provided numbers come from the Google Play console. Should be quite the reliable source. They are most definitely not out of context and this "theory" is very much proven. Slow resources loading is unrelated (could have a similar effect but I highly doubt that's what most people experience), this most definitely is a bug that happens almost exclusively on Samsung devices.
to...@gmail.com
So you confirm that your numbers are 100% unrelated to the sub discussion that was occurring? I talked about that loading ressources issues, he ask ME the demographics about them and you jumped in with now confirmed unrelated numbers without telling about what they where related :)
So thanks for the actual lol ;) There's a dozens reasons why this ANR can occurs, you do not give the full stack trace about the possible reason that is maybe something you do on that cause a problem on Samsung, I do not have this issue on Samsung and I have more than 500 000 MAU. So give the full stack trace for a common ANR cause that occurs only on Samsung and maybe there will be some valuable info for you ;)
ne...@gmail.com
Wow okay, I actually did not notice you are the same person as the one who was sharing the stack traces and explaining how their app does NOT take more than five seconds to prepare. Or did I misunderstand that? Because now it sounds like you're arguing with yourself and that's just really confusing.
Anyway, I said "Let me just jump in quickly to highlight a demographic I've been seeing it on", "it" being the issue at hand in general, not necessarily related to resources. Where it would appear we were in agreement before that this issue just happens, regardless of resources loading. That's what was being explained, wasn't it?
Also I believe I did provide a stack trace quite some time ago, and if I didn't, it might be because it looks exactly the same as all the stack traces given here before. There is no new valuable information available. Btw congrats on your 500k, I have 200k with dozens to low hundreds of these ANRs every day (or crashes, I honestly don't know what really happens on the device other what Firebase/Google Play gives me, which is two different information that share the same numbers) and they rarely happen on anything other than Samsung. Though the Huawei there sure is interesting, and I've seen some Nokias too I believe, which would suggest that the problem is in fact not completely Samsung's fault, which is why it's a thread here, isn't it. But I still believe that the fact that Samsung is the main culprit can help with solving this issue and should not be discarded, which is what I felt your earlier comment suggested.
to...@gmail.com
This is a conversation, so order of things matters, I report a specific case about resources, the guy ask for demographic for that specific issue, I said I have not you jump, in saying here's demographics, so in an normal world this means you are referring to the actual running conversation :)
You have never posted in this thread with any stack trace or ANR dump, and actually no one have posted a full ANR report except me, just pasting the error
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1768)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:164)
at android.app.ActivityThread.main(ActivityThread.java:6494)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807)
Is not a full stack trace / ANR dumps with all the running threads and what is really happening.
So again, no there's no generic Samsung issue as Samsung is as many others my most active devices and I do extensively rely on startForeground.
Provide a proper ANR trace with all threads and I'll assure you there's plenty of different reasons for the crash / ANR. How the system report the crash via sending a message is the same and that's what that small logcat extract shows. This is not the cause this is the consequence.
TL;DR an ANR dump and a logcat error log are very different and without the proper ANR dumps your numbers represent absolutely nothing. Yes there's Samsung issues that can be workarounded with media session for example. So if you play with those on main thread during that call you can trigger this ANR, but this is not something Google can fix, it's Samsung bug and there's workarounds. So provide the full ANR dumps and I'm pretty sure I'll have some history about them and workarounds.
For the record a screenshot of the Vitals for that app, as you can see there's no ANR lines because I managed to remove nearly all of them and the remaining are like the one I posted here.
ne...@gmail.com
Well then I misunderstood the question (and it really wasn't that clear as to what demographic they mean, or if they mean to be specific), so to clarify, I have provided what I believe to be the demographic for the general error. To add to my claims, I'm sure I'm not the first to mention it's mostly Samsung here or in other threads. Yet again you are discarding that information as irrelevant. I'm simply saying there is a probable connection.
"Yes there's Samsung issues that can be workarounded with media session for example." - please elaborate, I have zero idea what you mean by this.
So what exactly is an ANR dump and how do I provide it? Where do I get one? Naturally that stack trace you mention is useless, which is what I said as well. But the only information I have is what Google Play Console tells me and I don't see a way to export that or if it even is what you're asking for. To me, it looks like it doesn't really hold a lot of information either.
to...@gmail.com
See attached images :) Not very hidden.
And I'm not dismissing what you say about Samsung just that it's irrelevant information without the ANR dump. You are probably doing something that trigger an issue on Samsung, but this is not a general issue on Samsung that everybody face as proven.
un...@gmail.com
Hi ya'll,
I found this thread super useful. I also saw that it was especially common on Samsung devices out in the field. And I think it has allowed me to construct a workaround that completely hides this problem. I'm posting it here in case it is useful for my sister/brother android devs ;-).
I think for many usecases people are calling startForegroundService in a BOOT_COMPLETE receiver (in my case so I can start talking to a bluetooth device). Unfortunately that first 30 seconds or so of an Android boot is a very busy time - with lots of threads starting and running. It is completely plausible that if you try to start your service that early , your service will start running and then end up blocked for a long time (because of some thread outside of your control) and you'll hit that dreaded timeout.
My workaround is to use the new WorkManager to push my service start later - about 1 minute later. After the phone isn't so hot with everyone else starting up. Here's the code I used:
https://github.com/meshtastic/Meshtastic-Android/blob/407a38594f67c81d0e18f6a30298b9e8e75231ea/app/src/main/java/com/geeksville/mesh/service/MeshService.kt#L72-L102
I found this thread super useful. I also saw that it was especially common on Samsung devices out in the field. And I think it has allowed me to construct a workaround that completely hides this problem. I'm posting it here in case it is useful for my sister/brother android devs ;-).
I think for many usecases people are calling startForegroundService in a BOOT_COMPLETE receiver (in my case so I can start talking to a bluetooth device). Unfortunately that first 30 seconds or so of an Android boot is a very busy time - with lots of threads starting and running. It is completely plausible that if you try to start your service that early , your service will start running and then end up blocked for a long time (because of some thread outside of your control) and you'll hit that dreaded timeout.
My workaround is to use the new WorkManager to push my service start later - about 1 minute later. After the phone isn't so hot with everyone else starting up. Here's the code I used:
ph...@gmail.com
Make service run on different process and you get rid of all these Crashlytics logs related to startForegroundService
ne...@gmail.com
That is not true, my services have always ran on a different process and the issue still remains.
kl...@gmail.com
Wanted to +1 this thread, I'm seeing this issue with slower phones, and I also call StartForeground first thing on create..
mi...@gmail.com
Hi guys,
I am facing this issue in my app since 1 year. I tried a lot of solutions to solve this problem. But only 1 solution that actually worked and was my mistake is:
1) After starting service in onCreate i was calling stopSelf() before calling startForeground() of service. Make sure you don't do this. It mostly happens when your app run in service completely and you have given a button to user to turn off and on so in actual it's service that starts and stops. So make sure after turn on you put some delay before you turn it off maybe delay on button clicks.
But this solution didn't solved all the crashes and i am still getting these crashes mostly on Samsung and Huawei devices with android version 8.1 only.
Now i read a
Thanks
I am facing this issue in my app since 1 year. I tried a lot of solutions to solve this problem. But only 1 solution that actually worked and was my mistake is:
1) After starting service in onCreate i was calling stopSelf() before calling startForeground() of service. Make sure you don't do this. It mostly happens when your app run in service completely and you have given a button to user to turn off and on so in actual it's service that starts and stops. So make sure after turn on you put some delay before you turn it off maybe delay on button clicks.
But this solution didn't solved all the crashes and i am still getting these crashes mostly on Samsung and Huawei devices with android version 8.1 only.
Now i read a
Thanks
ht...@gmail.com
Hi,
none of the suggestions worked for us - we still got a lot of exceptions logged in Play console vitals (though lower number with all the suggestions applied). I guess, even if the app does everything right, sometimes device may be in state when it struggles to process everything in time and you get more than 5s between startForegroundService and service.startForeground calls.
What's worked for us was a complete startForegroundService call removal from the project. Instead, context.bindService + startService + service.startForeground approach is now used and that finally resolved the issue (you can do that combination where you previously did startForegroundService).
Thanks!
none of the suggestions worked for us - we still got a lot of exceptions logged in Play console vitals (though lower number with all the suggestions applied). I guess, even if the app does everything right, sometimes device may be in state when it struggles to process everything in time and you get more than 5s between startForegroundService and service.startForeground calls.
What's worked for us was a complete startForegroundService call removal from the project. Instead, context.bindService + startService + service.startForeground approach is now used and that finally resolved the issue (you can do that combination where you previously did startForegroundService).
Thanks!
wa...@gmail.com
OK，I fixed it. postDelay Context.stopService(...) at least 10ms in some phone is effective.
ma...@gmail.com
IS this issue fixed
mi...@gmail.com
Tried a lot of stuff inspired by this thread and stackoverflow thread. Still getting this ANR a lot.
ai...@gmail.com
Suggestion from
ey...@gmail.com
Hi, i have a lot of research about your suggestion from
ey...@gmail.com
Hi, i have a lot of research about your suggestion from
ma...@gmail.com
Comment has been deleted.
lu...@gmail.com
Thanks the
1. startService in the onStart of Main Activity, so we can keep the service running. If don't call it, after the activity stopped, the service is unbinded, it will be killed even if it is set as foreground service.
I start the service in onStart not onCreate, because the service may be destroyed, then the saving service instance in Acivity will be invalid. Such as there is a quit action in the notification, the service can be killed by the action and the activity is still paused. Users may resume the activity than re-create the App.
2. bindService following the startService in the onStart, so can get an instance of service.
3. Unbind the service in the onStop of Main activity.
4. write a function in the service which calls Service::startForeground, use the service instance which get from the binded in the activity to replace the Context.startForegroundService
I think the Context.startService should offer a ServiceConnection param as optional, so apps can pass it to get the service instance directly. the bindService with create flag can not meet all requirements. the service instance from BindService will be lost in some cases.
1. startService in the onStart of Main Activity, so we can keep the service running. If don't call it, after the activity stopped, the service is unbinded, it will be killed even if it is set as foreground service.
I start the service in onStart not onCreate, because the service may be destroyed, then the saving service instance in Acivity will be invalid. Such as there is a quit action in the notification, the service can be killed by the action and the activity is still paused. Users may resume the activity than re-create the App.
2. bindService following the startService in the onStart, so can get an instance of service.
3. Unbind the service in the onStop of Main activity.
4. write a function in the service which calls Service::startForeground, use the service instance which get from the binded in the activity to replace the Context.startForegroundService
I think the Context.startService should offer a ServiceConnection param as optional, so apps can pass it to get the service instance directly. the bindService with create flag can not meet all requirements. the service instance from BindService will be lost in some cases.
pv...@swooby.com
I am the OP.
Sad that 3.5 years and 197 stars later this "closed won't fix, intended" issue that Google essentially created in a vacuum for no valid reason still affects devs and their users that Google refuses to acknowledge and fix.
But that still may not help code where it is not possible to bind to the [especially to a legacy/unbindable 3rd party] service.
Good luck out there fellow coders!
Sad that 3.5 years and 197 stars later this "closed won't fix, intended" issue that Google essentially created in a vacuum for no valid reason still affects devs and their users that Google refuses to acknowledge and fix.
But that still may not help code where it is not possible to bind to the [especially to a legacy/unbindable 3rd party] service.
Good luck out there fellow coders!
49...@qq.com
Oh，Shit! Why leave the problem to developers？It leads so many crash!If someone has a simple solution, please let me know, thank you！
a....@mastertraining.it
News?
mu...@gmail.com
I am facing same issue. kindly guide me thanks in advance.
Context.startForegroundService() did not then call Service.startForeground
ch...@gmail.com
Hey .! Is there any update yet on this ??
Context.startForegroundService() did not then call Service.startForeground(): ServiceRecord{7996535
Context.startForegroundService() did not then call Service.startForeground(): ServiceRecord{7996535
en...@gmail.com
this ticket was opened on Mar 22, 2018, and we still don't have a solution. I just want to use a service without a crash :(
kr...@gmail.com
j'ai le meme problème, ou est google ? depuis 2018
ku...@gmail.com
up!
[Deleted User] <[Deleted User]>
Same issue. Context.startForegroundService() did not then call Service.startForeground(). Happens on Android 10 and 11.
he...@gmail.com
Comment has been deleted.
me...@gmail.com
up, the same issue
sa...@pocketfm.com
same issue
gu...@gmail.com
Still getting this error mostly on Android 11 and 12 devices, already done the multiple solutions available on the internet
1) Started the service as background service and after binding the service we are marking service as foreground by calling startForeground
2) added a delay while stopping the service so that service can be marked to foreground before stopping itself.
3) Calling startForegroundService from handler and posting it on main looper
nothing worked, can we please check the root cause of this issue ?
1) Started the service as background service and after binding the service we are marking service as foreground by calling startForeground
2) added a delay while stopping the service so that service can be marked to foreground before stopping itself.
3) Calling startForegroundService from handler and posting it on main looper
nothing worked, can we please check the root cause of this issue ?
mh...@gmail.com
I read all comment and didn't find any proper solution till now. In my case this issue is only occurring on android 11 devices only and most of them are Samsung devices. I have 10 users and 500 events in just 5 days (App: Music Player) on google play console If Any one find solution then let me know. Thank you in advance...
pv...@swooby.com
Re #182, is there any way for you to convert to use a bound service? Those seem immune from this 4.5 year old timeout "feature".
re...@gmail.com
This issue is OLD and it's still not fixed?!
I have tried several work-arounds including those mentioned in this thread but none of them worked. Even ContextCompat.startForegroundService() crashes on some Android versions.
What did work for me is to, first, attempt to start the service as a background service, then, if that fails, start it as a foreground service:
fun startService(context: Context) {
val intent = Intent(context, MyService::class.java)
// Try to start it as a background service first.
val started = try {
context.startService(intent)
true
} catch (e: Throwable) {
e.printStackTrace()
false
}
// If that fails, try to start it as a foreground service.
if (!started) {
try {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
context.startForegroundService(intent)
}
} catch (e: Throwable) {
e.printStackTrace()
}
}
}
Then, in MyService's onStartCommand() and onCreate() methods, I elevate the service to foreground by calling startForeground(), passing the needed notification.
override fun onCreate() {
super.onCreate()
startForeground(NOTIFICATION_ID, myNotification)
// ...
}
override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
startForeground(NOTIFICATION_ID, myNotification)
// ...
return super.onStartCommand(intent, flags, startId)
}
I've tested this on Android 9, 10 and 12 and so far, hadn't had an issue yet. But then again, I only have these 3 devices.
he...@gmail.com
Comment has been deleted.
bi...@gmail.com
mark, wait google fix the OLD bug
li...@gmail.com
If this is not a framework bug, could any framework developer of Google show some RIGHT code？ We will use the RIGHT code in our projects to see whether the bug exits?
zi...@gmail.com
I don't know why my service call onStartCommand, then call onDestroy in 100ms,I do not call stopService or stopSelf.
06-08 11:44:59.105 [I] 3699 [null] 1 [main] [AAAAAService]: onStartCommand
06-08 11:44:59.237 [I] 3699 [null] 1 [main] [AAAAAService]: onDestroy
06-08 11:45:05.428 [E] 3699 [null] 1 [main] [Crash]: android.app.RemoteServiceException: Context.startForegroundService() did not then call Service.startForeground()
06-08 11:44:59.105 [I] 3699 [null] 1 [main] [AAAAAService]: onStartCommand
06-08 11:44:59.237 [I] 3699 [null] 1 [main] [AAAAAService]: onDestroy
06-08 11:45:05.428 [E] 3699 [null] 1 [main] [Crash]: android.app.RemoteServiceException: Context.startForegroundService() did not then call Service.startForeground()
mu...@gmail.com
in my case, this issue fixed by using stopService() instead of stopForegroundService()
here's the different
- stopService(intent): This method is used to stop a service that was started using the startService(intent) method. It stops the service regardless of whether it was started as a foreground service or a background service. When you call stopService(intent), the service's onDestroy() method will be called, allowing you to perform any necessary cleanup or resource release.
- stopForegroundService(notifid): This method is specifically used to stop a foreground service that was started using the startForeground(id, notification) method. A foreground service is a type of service that displays a persistent notification to the user, indicating that the service is running. By calling stopForegroundService(notifid), you are telling the system to remove the service's foreground status and notification. However, the service itself will continue to run in the background unless you also call stopSelf() or stopService(intent).
here's the different
- stopService(intent): This method is used to stop a service that was started using the startService(intent) method. It stops the service regardless of whether it was started as a foreground service or a background service. When you call stopService(intent), the service's onDestroy() method will be called, allowing you to perform any necessary cleanup or resource release.
- stopForegroundService(notifid): This method is specifically used to stop a foreground service that was started using the startForeground(id, notification) method. A foreground service is a type of service that displays a persistent notification to the user, indicating that the service is running. By calling stopForegroundService(notifid), you are telling the system to remove the service's foreground status and notification. However, the service itself will continue to run in the background unless you also call stopSelf() or stopService(intent).
pa...@outlook.com
It's pathetic how Android just takes a dump on major issues like these and leaves us hanging with their utter incompetence.
re...@gmail.com
Is there any update? Plan to address this issue?
he...@gmail.com
dont use startForegroundService() to start service , in onCreate() to use startForeground()
use this method ,can ignore 5s limit
use this method ,can ignore 5s limit
Description
STEPS:
1) call Context.startForegroundService(...)
2) before Service.startForeground(...) is called, call Context.stopService(...)
EXPECTED:
App doesn't crash
ACTUAL:
android.app.RemoteServiceException: Context.startForegroundService() did not then call Service.startForeground()
-Android build
OPM1.171019.021
-Please provide sample project or apk to reproduce the issue.
NOTE: Use of postDelayed is intentional to repro bug
-Logcat output
03-21 16:03:44.647 5385-5385/com.github.paulpv.foregroundserviceapi26 D/MainService: +onCreate()
03-21 16:03:44.647 5385-5385/com.github.paulpv.foregroundserviceapi26 D/MainService: -onCreate()
03-21 16:03:44.648 5385-5385/com.github.paulpv.foregroundserviceapi26 D/MainService: +onStartCommand(...)
03-21 16:03:44.651 5385-5385/com.github.paulpv.foregroundserviceapi26 D/MainService: -onStartCommand(...)
03-21 16:03:45.127 5385-5385/com.github.paulpv.foregroundserviceapi26 D/MainService: +onDestroy()
03-21 16:03:45.128 5385-5385/com.github.paulpv.foregroundserviceapi26 D/MainService: -onDestroy()
03-21 16:03:45.129 5385-5385/com.github.paulpv.foregroundserviceapi26 D/AndroidRuntime: Shutting down VM
03-21 16:03:45.132 5385-5385/com.github.paulpv.foregroundserviceapi26 E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.github.paulpv.foregroundserviceapi26, PID: 5385
android.app.RemoteServiceException: Context.startForegroundService() did not then call Service.startForeground()
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1768)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:164)
at android.app.ActivityThread.main(ActivityThread.java:6494)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807)
-Android bug report
Attached