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? |
I do still see this some, but not on Android 11, I see on variant on 12 and another and on 13 and 14. Note, I'm audio only. |
|
@johngray1965 Even my app is audio only. After onPlaybackResumption() implementation, my Android 11 crashes have literally disappeared. I've been monitoring for the last 10 days. But there are similar crashes related to ForegroundServiceDidNotStartInTimeException on majorly Samsung's Android 14. After looking at stacktraces, logs and breadcrumbs, my speculation is that it is being caused by some dead notification of some sort. |
|
@XilinJia I tried 6.5.7 a whole ago, kept playing some audio for the last 40 mins, did not face a crash on Samsung Android 14 and AOSP Android 14. |
|
@debz-eight Some of mine may be from dead notification, but many of mine are coming in from MediaControllerButton and the app is in the background. I suppose I can work around them by playing silence. Though I'm not really sure what use case is causing this. I try to always find something to play. |
|
With Samsung devices using Android 14, have you tried hitting play after pulling up the system menu and selecting media output (your last media session should be that of your app)? That triggers the resumption route as well, and I believe might be the source of your crashes? |
I play silent audio and the biggest issue is that the media notification stays for a little while |
WhatsApp.Video.2024-09-08.at.19.48.49_e5b92c2e.mp4@kelmer44 Are you referring to this? The playback resumption seems to work fine when the app is not in background. |
Yeah that used to give me trouble when testing with Samsung devices, glad it's not your case |
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. |
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 [email protected] after filing this issue.The text was updated successfully, but these errors were encountered: