lovegaoshi

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...

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:...

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...

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,...

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 https://github.com/lovegaoshi/react-native-track-player/commit/1145e2da93647cab93bf118cbf22177433fbe642 (add foreground service type to startForeground)...

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...

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? it...

youd wrap startAndStopEmptyNotificationToAvoidANR() https://github.com/lovegaoshi/react-native-track-player/commit/95c26d92815c1f9d55b0c401e1fd4244e2f98c77 but why is this (service killed n restarted due to oom) related to crush on **app start**? has anyone done log intent before app crash?

duplicate of https://github.com/doublesymmetry/react-native-track-player/issues/2184 try disabling battery optimization

this is a UX improvement set by google since android12. as much as youd like to call this a dev problem unfortunately there aint many options other than listed here:...