-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to start service MusicService with null: android.app.ForegroundServiceStartNotAllowedException: Service.startForeground() not allowed due to mAllowStartForeground false #2244
Comments
Looking at all the older issues related to this, it appears this issue should be fixed in |
Stack trace from BugSnag:
|
after some research I dont think this is supposed to be fixed in recent versions, really. The root cause is android disabled starting a foreground service from a background activity since 8 or 12. Because RNTP does kill the foreground service quite liberally, this quickly becomes a problem once the activity is sent to background/cached process. There are ways around it, like disabling battery optimization; but the fact the foreground service is killed and restarted is a problem itself; unlike the flutter alternative (audio_service) RNTP actually does NOT correctly link service back to activity, so it introduces another problem where closing activity may not kill service. So the options are:
I seriously doubt a real solution exists (some if logic to MS.kt L123) otherwise the flutter folks would have found it already. But no one reported a reliable way to reproduce this bug either. For example, I can force terminate the service, app goes to background, though the notification lingers; if I interact with the notification then this is an exception allowed to start foreground service, I dont really understand how this bug happens |
Great info thanks @lovegaoshi I'm going to go with your |
|
I'm seeing some absurd wakelock and cpu use duration that could be RN apps specific, as MusicService doesnt release wakelocks (headlessJsTaskService). One possible solution could be to move wakelock within: see lovegaoshi@2daba94 and lyswhut@bb80e13 though since AS moved their energy profiler to system trace, I dont know where to find wakelock profiling information anymore, if this my suspicion on the wakelock is even correct |
ive been pretty satisfied with my wakelock patch above and the barrey use, and keeping foregrounf service is veru nice. the wakelock patch needs to expose wakelock as public and makes more sense to patch after the Aa work. |
Unfortunately this did not change things for me in prod :( I'll try your wake lock fix and let you know how that goes :) |
im out of wits :/ so it has to be where it's listing foreground tasks and
its returning null..?
i cant reproduce so cant help
…On Tue, Feb 6, 2024, 8:28 PM Brad SF ***@***.***> wrote:
IMG_6948.jpeg (view on web)
<https://github.com/doublesymmetry/react-native-track-player/assets/1085976/1972cb0e-2673-40ae-9f23-c1bd537369ff>
do NOT kill foreground service like ***@***.***
<lovegaoshi@9afe35b>
Unfortunately this did not change things for me in prod :(
I'll try your wake lock fix and let you know how that goes :)
—
Reply to this email directly, view it on GitHub
<#2244 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AZMOVVUM3PZYUUZ2FMRT2ALYSL7IBAVCNFSM6AAAAABCSFD5U2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZRGI3DAOJYGY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
|
We have shipped the workaround of not killing the foreground service and found it to be effective so far. @brad-sf it is likely that you either did not apply the patch correctly or the continued issue you're seeing is from old versions that are still being used by your users. |
@mmmoussa this workaround that you mention is avaialble in the current version of the framework? or is located somewhere else? I just started to investigate this issue and I see a lot of users experiencing this behaviour. |
@mmmoussa whats this workaround? how can we fix that? |
this is the crashlytics log I have, and the function caused the crash has a remark related to #1666 |
whats ur MS.kt L125? |
Th
its caused by |
and can you reliably reproduce instead from crash logs?
…On Thu, Feb 15, 2024, 7:27 AM kyo-torstar ***@***.***> wrote:
Th
whats ur MS.kt L125? nightly is stopForeground i doubt that is the one; if
it's startForeground(EMPTY_NOTIFICATION_ID, notification) and android 14 u
can try ***@***.***
<lovegaoshi@1145e2d>
(add foreground service type to startForeground) but i doubt it helps
its caused by stopForeground(true) on L125 MusicService.kt. But tracing
backward, I find the initial call should be onStartCommand, a function
triggered by HeadlessJsTaskService. Therefore, on the frontend react
native, TrackPlayer.registerPlaybackService function call may cause the
crash.
Screenshot.2024-02-15.at.10.21.05.AM.png (view on web)
<https://github.com/doublesymmetry/react-native-track-player/assets/120053121/50930d7f-c80f-442d-b249-329617e322ee>
—
Reply to this email directly, view it on GitHub
<#2244 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AZMOVVX4KYXZDYJOZMG6ZB3YTYSMJAVCNFSM6AAAAABCSFD5U2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBWGMZDENJRG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
|
we reproduced it few times only but we could not conclude the reliable step to replicate it. It looks random that it may relate to racing conditions upon bootstrap. I modified the startup function as following:
|
I'm definitely getting LESS of this crash report since trialing the patch fix above. But yes I agree there also appears to be some remaining crashes related to a race condition because they fire immediately on app launch (according to crash logs). I'll try the above setTimeout and see if that clears all the errors. If that's the case I guess we have two issues.. one on launch and one in general usage. |
@brad-sf @lovegaoshi
To minimize the possibility of this from happening, we can do something like
This is a temp workaround, the solution should be applied at the setupPlayer function in MusicService.kt, a foreground has to be done
The Java implementation from https://reactnative.dev/docs/headless-js-android
|
But why is your app in the background state when it's starting up? unless I immediately press back when opening the app, and startService is caught in that way? |
Related to https://issuetracker.google.com/issues/307329994 ? |
possibly, but it looks like no one can reproduce it locally. This was what I thought when I was trying to reproduce the crash as I experience no crash. However, I found several crash logs related to my tests later. I think the app was crashed and was restarted when It was brought back from background / during bootstrap. |
update to potential fix: https://issuetracker.google.com/issues/307329994#comment56
|
@kyo-torstar where we will write this code? |
I have the same issue |
|
@khc196 how did you manage to get it work? |
We need to find a way to reproduce the crash. It may not be reliably to reproduce it but it should increase the chance of experiencing it. Does the crash impact the user experience or it only crashes after the app is killed manually. |
I'm not sure if it's true yet, but when I used the device care optimization widget on the home screen, the error occurred with a probability of 100%.
|
@ymkwon3 thanks for the lead! I finally saw this error with the example app, though the way reproduced I saw the error after PROCESS ENDED. so i dont think it affects UX in any way bc app is dead anyways (specifically for RN apps at least, as service cannot linger with activity being shut down. native is another story). |
@lovegaoshi @ymkwon3
i tried to turn off the notification channel and the app can still play music in the background. What is the reason behind for subscribing those notification channels? |
@kyo-torstar thanks for another lead! i think this is an expected OS behavior though that the app is killed/restarted upon removing certain permissions. any music app will close like that |
@lovegaoshi its interesting to see that, even if i turn off the notification channels, i still can play the music in the background as normal. Another test that it does not crash is by playing the music in the background before turning the notification off:
PS: I tried Spotify, i turned off the notification and there is no crash when music is on or off |
I dont think the channels actually do anything, turning them on and off have 0 effects; but turning off the notification permission (or any permission, really) will trigger an app close/restart, and this should be universal. |
@lovegaoshi I did this fix https://github.com/kyo-torstar/react-native-track-player/pull/1/files to avoid foreground notification service from starting when the app is in background. It solves the crash of turning off notification when the app is in background. |
update: after applying the fix and deploying to the production, that type of crash is finally gone. The fix references |
@kyo-torstar - seconding your success. My team shipped a change based on your fix and haven't see the error re-occur yet in our app. 👏 Awesome job hunting that down and finding a fix. |
This doesn’t exactly stop it from performing the action but it does catch the exception so it doesn’t crash the process, which is still good. Will try to read the latest messages here in the next week. |
any update? |
+1 |
unless anyone can post reproducible steps, ur +1 wont help going anywhere
except keeping this thread alive. otherwise read the thread, either keep
the service always alive or catch the exception and pretend nothing
happened.
…On Mon, Jun 24, 2024, 5:00 AM Kirillsocivka ***@***.***> wrote:
any update?
+1
—
Reply to this email directly, view it on GitHub
<#2244 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AZMOVVVYZMLB3ULFWW4EDW3ZJAC65AVCNFSM6AAAAABCSFD5U2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBWGQYDSNZVHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
|
Hi Team, I'm experiencing the same issue as mentioned in the above chat. Could you please help with this? According to the Google Console report, my app is crashing multiple times in the background. Thanks in advance! |
+1 |
…player.service.MusicService.startAndStopEmptyNotificationToAvoidANR Update MusicService.kt to FIX [4.0.1] Crash: com.doublesymmetry.trackplayer.service.MusicService.startAndStopEmptyNotificationToAvoidANR doublesymmetry#2244 (reference)
This crash still happened |
and yet no one posted REPRODUCIBLE steps u could try a full media3 migration using MediaSessionService. the service lifecycle is then handled by the media3 lib. |
@lovegaoshi it is happening to me too. It is hard to make reproducible steps, but this is happening to me using firebase with headless task (messaging().setBackgroundMessageHandler()). Basically I quit the app and send a push notification, the app is starting up in background mode. There I have RNTP library that may be firing the setup causing the issue. It is hard to make a very simple example because it would depend also in Firebase configuration. But I think this is the case, it is firing the app in background and the RNTP is trying to wake up from background. |
specifically to your issue, it might be due to there is no playback within a certain period of time (< 20 seconds) after the foreground media service (MusicService) started. From my observations (i use my own fork, this may not apply if ur using main) this is harmless, does not trigger ANR or a native crash. I can't really help anyone on main, as there are way too many workarounds in the code to patch around the ever tighter android security requirements versions after versions. I eventually completely migrated to media3 to use MediaLibraryService and left all MusicService start and stop handling to the media3 lib itself. @puckey is merging some of that migration into main. And the media3 team handled most of these service start not allowed exceptions throughout 2022-2024. I've only very occasionally observed this exception when I manually kill the service and trigger a restart, which is not really accessible via normal usage; and even with these exceptions, the service is still fully functional, its a soft one at best. with that said i dont use firebase and cant promise it works. but i do use headless start/starting up in background mode (for android auto) and it works fine. |
Describe the Bug
Daily crash reports of
Unable to start service com.doublesymmetry.trackplayer.service.MusicService with null: android.app.ForegroundServiceStartNotAllowedException: Service.startForeground() not allowed due to mAllowStartForeground false
Steps To Reproduce
Unknown. Will update if I can replicate consistently.
Code To Reproduce
NA
Replicable on Example App?
Not yet.
Environment Info:
[email protected]
How I can Help
Looking into it.
The text was updated successfully, but these errors were encountered: