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? |
|
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? |
|
Any update on this issue. |
|
I'm working with 1.5.0-rc01 now. I was able to reproduce this locally by removing the recently played item. Once I implemented shouldStartForegroundService, I could not reproduce it locally. But I still see crashes on Android 14, and some of Android 13. On Samsung and Xiaomi devices (so far). I don't have a test device that matches those that are showing the crash. It seems to me we would expect the crash if
I've tried to find something to that I would expect to be particularly expensive to load, but I can always load and start well within the limit. But again, it only seems to happen on certain devices and I don't currently have one. Of course, you never know what the load on the users device might be. It's disappointing the number of crashes I still see in crashlytics with shouldStartForegroundService implemented. Is there something other than the cases I listed above? Perhaps there's something else in my code. Perhaps the problematic devices have a shorter timeout? Other possibilities. I am adding some additional logging so I can see if some edge cases that I don't believe should happen are in fact happening. They are basically cases where we failed to load the item, that I believe should be caught by shouldStartForegroundService. |
|
So for me this is happening when the app is has been playing in the background for an extended period of time usually around 1 hour. Once triggered the position from the player always returns the same value. im using a controller like so... ` init { looks like the controller somehow gets destroyed however Im still able to play/pause I think I need to figure a way to bind controller to prevent the os from destroying it. |
|
@Tr736 I think this is something different than
You already do the right thing with It looks like you can repro this on your device. If that's the case it would be great if you please file a new bug. If you do this best would be to do a bug report right after you see that it happened. Please upload the bug report to the new bug . If you're unable to share bug reports publicly, please send them to [email protected] using a subject in the format "Issue #1234", where "#1234" should be replaced with your issue number. Please also update the issue to indicate you’ve done this. I think we see in the logcat why the app/service was terminated. I'm interested in the entire logcat and in the output of that all we be included in the bug report. |
|
I am currently starting to write a media player app and face the same Exception. I just followed the basic guide on developer.android.com. The background service runs and starts playing but stops after a few seconds when the Exception is thrown. There is no notification appearing at all and AndroidManifest.xml: <service
android:name=".PlayerService"
android:foregroundServiceType="mediaPlayback"
android:exported="true">
<intent-filter>
<action android:name="androidx.media3.session.MediaSessionService"/>
</intent-filter>
</service>PlayerService.java private ExoPlayer player;
private MediaSession mediaSession;
@Override
public void onCreate() {
super.onCreate();
startPlayer();
}
@Nullable
@Override
public MediaSession onGetSession(MediaSession.ControllerInfo controllerInfo) {
return mediaSession;
}
@Override
public void onDestroy() {
super.onDestroy();
if (player != null) {
player.release();
player = null;
}
if (mediaSession != null) {
mediaSession.release();
mediaSession = null;
}
stopSelf();
}
private void startPlayer() {
player = new ExoPlayer.Builder(this).build();
mediaSession = new MediaSession.Builder(this, player)
.build();
MediaItem item = MediaItem.fromUri("/sdcard/test123.mp3");
player.setMediaItem(item);
player.prepare();
player.play();
}MainActivity.java @Override
protected void onResume() {
super.onResume();
/* getting storage permission here (omitted) */
Intent serviceIntent = new Intent(this, PlayerService.class);
ContextCompat.startForegroundService(this, serviceIntent);
}So I got this very simple basic setup by following the guide and it is still crashing even on the emulator :x What is wrong with that? |
|
You should build a |
So I have faced somewhat of a similar thing where my controller is getting destroyed after the user is in paused state for extended period of time. I have solved this issue by doing the below: I have a single source for initialization of my controller and I have made the function to initialize the controller public. So whenever the user is trying to play something, I check if the controller is connected or null, if so, I re-initialize the controller, else I use the existing controller instance to do the necessary. So whenever my controller is disconnected or killed, I just re-initialize it. I don't know if its the correct way or not but it works. Perhaps @marcbaechinger can provide some insights on this. |
|
My app has been getting this issue (noticed from time to time). From the documentation, I can't figure out a solution. Google Play Console complains about this. But it's amazing to see this issue standing here for over 2 years and many people suffering on the same problem. Would I get more comfort just by visiting this page to find company? Anyone looking to reproduce this, feel free to check out my open-source Youtube/podcast app Podcini: https://github.com/XilinJia/Podcini, currently being launched on Google Play. |
Yeah, I agree we should close this issue. If you need support, please start a new issue where you describe what you are facing or then add some more information. Saying |
To me, this is an in-fighting between media3 and Android, and we app developers are unfortunately caught in the middle. My app just uses MediaLibraryService and a MediaController according to what has been described, so I expect media3 to settle down any Android complaints, but apparently that's not what's happening. And my issue doesn't appear unique from the large list of issues reported here. I'm not sure how to report anything new. |
|
@XilinJia Thanks for your opinion. If you want us to look into your issue, please file a new issue and explain it in terms of the output of your app (like bugreport). Thanks. |
|
I'm closing this issue. It doesn't work anymore as it has grown too big. As a general advise on this issue:
If you haven't enabled playback resumption and you see that an OEM device is starting the service either way, please file a new bug report and describe how the OS starts the service. If you think you are still affected by a Thanks to everyone who helped us with this issue and contributed to make the service more robust on all available API levels, OEM devices and in the many use cases apps use the service. You helped us to make Media3 better. That's very much appreciated. Thank you! ♥︎ |
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: