MediaLibraryService throws ForegroundServiceDidNotStartInTimeException #167
Comments
|
I've also seen this in Crashlytics, although I'm myself have been unable to reproduce this. |
|
Thanks for reporting! Do you have some more context what command has been sent to the service when this happens? I'm asking because I probably have found an execution path that could cause this problem, but I can not repro this and hence I can not verify a fix. I think the reason for this could be that the pending intent of 'pause' is starting a foreground service and then does not call I will provide a fix for the case described above. However, I can't be really sure whether this is the root case of the exception above because I can't repro now. I think it may be a corner case that sends the You have already reported that this happens on Android 12. Can you let me know the |
|
So in my case, I have both target & compile SDK set to 33.
Full stacktrace: |
|
@marcbaechinger This crash is reported a lot |
|
***** EDIT ***** Hi, I reproduce the crash with media session demo app |
|
Thanks for digging some further. That give me some further data points.
Yes, indeed, these cases are always about closing the app and having only the service playing in the background. As soon as your app is in the foreground with a controller connected you are bound to the service, and you will never see such an exception.
With the default behaviour of the I still think it's the |
|
Hi @marcbaechinger, |
|
This should be fixed with this commit. Please re-open if you think you still see this issue with this commit. |
|
I'm still a little bit concerned it's not a complete fix. Seems racy, the pending intent in the notification can be clicked on after something else has just toggled this. Also do you have a test for playback stopped by suppression? I assume this will work because it's temporary and the session is still active? |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
@yschimke This issue is about a By design, the service is started by creating a controller/browser and binding to the service. The service shouldn't be started by a pending intent (not For this reason, I agree that this is about a race condition or an invalid state but elsewhere (stale notification?). I couldn't repro, because I do not understand from where a pending intent for I agree that I'm not sure that this fixes the problem, but I think it removes the If you have any way to repro this |
|
Thanks for clarifying. |
A follow up to stopping speaker playback with a Player decorator from #15. It looks like we will need to change to using playback suppression to avoid errors like #167, when we don't start a foreground service. We may not have this implemented by 1.0, but would like it in the API and it seems to be appropriate. PiperOrigin-RevId: 478835686
A follow up to stopping speaker playback with a Player decorator from androidx/media#15. It looks like we will need to change to using playback suppression to avoid errors like androidx/media#167, when we don't start a foreground service. We may not have this implemented by 1.0, but would like it in the API and it seems to be appropriate. PiperOrigin-RevId: 478835686
|
When can we expect a new release of the media3 library? |
|
We have many reports in Crashlytics of users facing this issue, however I believe it's not causing crashes (although they get reported as one), as I can see in our database that the users who face the crash can listen to the app audios and complete the full playback. We have not been able to reproduce it ourselves so far. Another annoying thing is that we get different reports in Crashlytics that are not getting grouped as the same issue, and it's spamming us with many different issues that are essentially the same. Android 12 examples:Different report, same issue: Another: And many more. Android 11 example:We have around 15 different reports of this same issue with slightly different line numbers throwing the error in the last 7 days. Do you have any insights or recommendations on what to do? |
As I said, it doesn't happen all the time. The most likely case is during construction of mediaItem/mediaSource there is some delay (due to network issue for instance), as I sometimes experience in a remote area. |
How are you doing this exactly? I am thinking of implementing the same. |
|
What I just implemented now is: Inside my PlayerService.kt, when I am creating the player instance I am using setMediaSource(1msMediaSource) followed by player.prepare(), player.playWhenReady = true and player.clearMediaItems(). If I am not doing player.clearMediaItems(), then if the user immediately starts playing anything as soon as the app opens, it is causing me IndexOutOfBoundException. Since I cannot reproduce the issue myself, I guess I'll have to test by pushing this to playstore and monitoring. |
|
My app plays live audio so locally caching is not possible. I can't rely on returning anything on the Additionally my whole pipeline is quite complex and I'd rather just rely on my regular playback pipeline rather than creating a specific one just for resumption. IMO this is why the resumption mechanism is flawed as it is right now; it assumes an app can always play stuff by resolving it locally within the playback resumption function into a list of mediaItems, but apps are sometimes more complex than that. So what I do is i call the |
|
Looks like 1.5.0 alpha01 already facilitates more control over when playback resumption happens
(I think the linked issue is unrelated BTW) https://github.com/androidx/media/releases/tag/1.5.0-alpha01 |
|
Is it an implementation issue, Samsung issue or library issue? I've improved where I can and solved some of the similar exceptions but I'm out of ideas and cannot reproduce this one: I am using It would be great to know where should I dig into... |
The stack trace shows that Above API 26 and without modifications on the Then the service is started and the play command is delivered. The service then must start playback, else a I think we need to figure out why playback does not start for the app - if you can make playback start after the
Don't think so. They are both using the same implementation. |
The first case that comes to mind - why the playback cannot start - is that there is no internet or poor connection (the content is mostly streams). Or is that case handled by the player? Otherwise - I have to think of all the cases where the playback cannot start and not only from |
The session start the service into foreground if the player state is either We are aware that the model isn't really bullet-proof for the cases when an app doesn't have a media item to play (there are various valid reasons apps may have for this). We should revisit this to make the solution more flexible (see point 3. below) but I can't give you a timeline for this I'm afraid. Steps to achieve by apps and library:
|
|
Just confirming my guess from above. When opted-in to playback resumption by adding the Hence a playback error wouldn't cause this issue. See below how the player goes into BUFFERING state which is sufficient even when we never transition into |
Yes, thank you for the confirmation. I was able to test it also and found no case. |
|
After reading many comments, what helped me almost solve the issue is playing a 0.5s silent audio inside onPlaybackResumption(). So, I have a last played audio featured that I play from inside onPlaybackResumption(). While creating mediaItems, I am adding the silent audio and followed by my own last played audio. |
|
marcbaechinger Our app has a complex pipeline where we can't rely on returning a list of items in the However we need to discern whether the call came from a play-able scenario or not in order not to have our app randomly play at random times whenever would it possible for future releases to add a flag to this method to be able to distinguish these two situations? |
|
Your understanding is correct.
In the other occasion, the media items returned by Your request seems useful to me. Not sure if the solution would be an additional boolean parameter or something else like a specific However, mind filing a separate issue to ask for that flag? |
|
Absolutely #1764 I do have further questions if I may: i have tried explicitly requesting playback in Additionally some user reports for my app complain the app starts playing at random times without necessarily being preceded by a reboot. Are there any more occasions where the MediaLibrarySession path might be called? Do some other conditions need to be met? Trying to understand the behavior here :) |
Yeah, I see. This is something we haven't anticipated apps would want to do and that's why #1764 is a valid request I think. We need some API to clarify/express whether the media items returned by At boot time, In contrast and in the case when
Not that I'm aware of. Media3 calls 1 - when a
from the above, the intended behavior that follows is: a - any browser that calls I think for b) it's either System UI or a user that intentionally requests For a) and if your app calls |
I'm getting reports of this as well. |
|
So according to last 7 days of crashlytics report, I had 150 crashes due to ForegroundServiceDidNotStartInTimeException on majorly Samsung's Android 14, 70% of them to be exact. My app is now 99.73% crash free as of now after added the code to play a silent 0.5s audio onPlaybackResumption(). |
|
@debz-eight Can you give me the Samsung models that are reported? It's all about finding why and how these Samsung devices trigger playback resumption I think. I can give it a shot again if I get such a device in my hands. |
|
@marcbaechinger These is the whole list of 150 crashes of Samsung: https://batbin.me/lavers |
|
Mostly Samsung A, G, S, F series - but that could be that there are more of these out there. There also some Sony and Xiaomis. EDIT: I can test with A55 - Android 14. But I cannot reproduce it. If anyone can please let me know of the steps. |
|
Since migrating to Media3, we’ve seen a significant increase in crashes, dropping from a 99.9% crash-free user rate to around 99.4%. Notably, we do not have a MediaButtonReceiver registered in the manifest, so this issue doesn’t seem related to playback resumption. Our implementation is quite straightforward and closely mirrors the demo app. I’ve only been able to reproduce this issue on a Samsung device running Android 11. When pausing playback and swiping the app away from the recent apps screen, the notification remains active. Interacting with the notification triggers a “silent” crash, as reported in other issues. Observations:
Questions:
Suggestions:
Any guidance on addressing this issue, or insights into future improvements, would be greatly appreciated. Thanks for your continued work on the project! |
Can you tell me what device this was exactly? I'm not sure if this is the same issue, but if we can repro this on a device, that sounds like great. So far we only have telemetry reports without knowing how to repro. I still think there may be two different issues:
That's media session not an ExoPlayer issue.
From what I understand, this issue is specific to devices of a certain vendor. I'm afraid, but when trying to get into contact with the vendor I didn't get a response. When following up I was told that I get a response soon. It seems that the vendor isn't really interested in supporting us I'm afraid. For various technical reasons, it is difficult for us to inspect OS behavior of devices from other vendors. The situation we are having with such devices is similar to what you have with Media3 - we don't know what is going on there and in contrast to Media3 we don't have the source code of the changes applied to for instance AOSP/Pixel builds where we don't see that issue. If you want to help me, then making noise at the side of the vendor would be helpful, but I'm afraid I don't know myself how to get through them. Please accept my apologies, I can understand your frustration. |
|
@marcbaechinger Thanks for the quick reply! I agree with your assessment that we are likely dealing with two separate issues here. The first issue, related to stale notifications, produced the same stack trace but was resolved by handling onTaskRemoved (as described in other issues). This workaround seems to work well for that particular case. However, the second issue (or possibly others) is still occurring frequently. Unfortunately, we haven’t been able to reproduce these crashes ourselves, which is one of the reasons I’m hesitant to try the various workarounds mentioned in this and other discussions. Looking at the crash reports, the majority of occurrences are on Samsung, Xiaomi, and Huawei devices running Android 11 and 12. Given that we can’t reproduce it on our end, I’m unsure how to proceed in contacting the vendors directly. If you—or anyone else—could provide guidance on how to reproduce these crashes reliably, that would be an incredibly helpful starting point. |
|
I have an app that has been having this error for a long time. But the problem is not solved, i have been using when click button to startService. When the service has stopped. I try to restart the Service. And I got error : Fatal Exception: android.app.ForegroundServiceDidNotStartInTimeException: Context.startForegroundService() did not then call Service.startForeground() I fixed it by calling startForeground in OnCreate in Service I looked it up and it seems like you called startForeground like me. I have not tried the above for Media library. Because I have to clone a lot of Modules to do this. Please check this. Thanks. |
|
@jackyhieu1211 Thanks for the suggestion.
The problem of From this your approach isn't really matching the problem I think. In For these reasons I think the current approach is the right thing to do:
|
I'm seeing exactly this. Same devices, same versions of Android. Always in the background. Its accounts for the vast majority of my crashes. |
So is the approach described possible with 1.5.0-beta01? |
and others
Media3 Version
1.0.0-beta02
Devices that reproduce the issue
Firebase crashlytics report these devices:
Devices that do not reproduce the issue
No response
Reproducible in the demo app?
Not tested
Reproduction steps
It's happened on some devices. I think It has related to MediaController not properly handling the service.
Expected result
not crash?
Actual result
Media
Bug Report
adb bugreportto dev.exoplayer@gmail.com after filing this issue.The text was updated successfully, but these errors were encountered: