Removed Android service

[Guichaguri]

This PR removes the Android service in favor of the in-app playback.

Pros

• Fixes [Android] Crash - Not allowed to start service Intent #473
• Fixes java.lang.IllegalStateException #391
• Fixes URGENT: Trackplayer is not removed from memory when app closes #732
• Fixes [Android] App process lives on after quitting by removing app from recents #813
• Fixes Notification Button Actions causing TrackPlayer crash #812
• Fixes Context.startForegroundService() did not then call Service.startForeground() #524
• Fixes App Not Working Properly :Player-Handler using Redux for React Native v0.57.4 and react-native-track-player v 1.0.0 For Android #343
• Might fix [Android] Crash - android.app.RemoteServiceException #620
• Closer behavior of both platforms
• Possibly Expokit support

Cons

• Android may possibly kill the app while playing in order to reduce system resource usage. We'll have to figure out how frequently it happens and how to prevent that from happening.
• The player won't be able to play while the app is closed. This is a feature that is usually disabled through the stopWithApp option by the majority of the apps anyway.
• This was a big differential from other music modules, as it was closer to a native music app, but I figured that react-native doesn't work properly with services nor the community wants to work with native behavior like this.

---

As this is a big change on Android, I'd love to see testing here from all sorts of apps.

[puckey]

I would be happy to test this out on some Android phones to see how long it takes for the app to be killed.

However, I do wonder if this is the right direction. For a music player having music stop at random moments feels like a more existential issue than intermittent crashes for a small subset of users. (0.8% in our radio-player case)

Our use-case is a radio app, where I know users can listen to a station for up to 8 hours at a time - the chance that the app would be killed by the system during that time is pretty high.. and for a user it is not a nice experience to have to wonder why their music stopped playing.

Here is a related issue about background-audio on expo, where users report apps being killed after several minutes in the background: expo/expo#4850

[afkcodes]

@puckey i will love to try your radio app, also i will also be testing the online streaming. i would like to know does your app streams hls content or not as its more prominent on hls (m3u8) links

[puckey]

@ashishfeels here you go: https://play.google.com/store/apps/details?id=com.jonathanpuckey.radiogarden&hl=nl  We don't support HLS content right now, but it is on our roadmap.

[afkcodes]

@Guichaguri can we make the error reporting better. i mean the type of error we get while playing the audio. like i was trying to play an hls content and it was giving me liveBehindWindow Error , but on js side it was only giving me playback error. that will help the issue in debugging the problems.

[Guichaguri]

@ashishfeels we definitely should, but that's for another PR.

[afkcodes]

yes @Guichaguri that's just an idea as i tried to fix in my fork i don't know its correct or not but it works :P

[kyleclegg]

Happy to test this as well 👍

[samkuhn]

Sorry left a bit of a snarky message thinking this was the Expo repo lol.

This was a big differential from other music modules, as it was closer to a native music app, but I figured that react-native doesn't work properly with services nor the community wants to work with native behavior like this.

I'm not sure I agree with this and would definitely advise pushing on for full background audio. Expo has been dallying for 3 years on this subject much to everyone's dismay. I created this issue a year ago but ended up just ejecting from Expo and coding the foreground service myself following this example and video.

Our background playback has been working flawlessly since.

[puckey]

@samkuhn any chance you could delete your earlier message? It would be nice to keep the tone friendly and encouraging here..

[samkuhn]

@samkuhn any chance you could delete your earlier message? It would be nice to keep the tone friendly and encouraging here..

Yes I did delete it? I've been through the wars with Expo and I mistakenly thought that this was a pull request for that repo. I apologise.

[Guichaguri]

@samkuhn Removing the Android service doesn't mean background mode won't work anymore, it will still play while the app is open and minimized, but it will stop as soon as the app is swiped from the task list (basically the same behavior as having the old stopWithApp option enabled)

[samkuhn]

Hi Guichaguri, Wouldn't the audio intermittently cut out while minimized though? That is what I found in my experience with no foreground service running to keep the audio alive (as per ExoPlayer team recommendations).

I'd also like to apologise again for my tone this morning I totally thought this was a different repo and I've been a bit scarred with my android background audio experience there. But even so it was wrong to go in so hard and not my normal style. And definitely wasn't targeted at you @Guichaguri! Good luck with the implementation.

[Anitaislam]

open pulling

[kyleclegg]

How stable is this branch? Should we try shipping it to users from the commit and monitor? Normally I wouldn't suggest shipping from a dev branch but in this case the change addresses a background crash that's flooding our logs, so I'm looking forward to seeing if this fixes it. 🤞

[afkcodes]

@kyleclegg i am unfortunately not able to test this , but you can really test it by doing an A/B Test may be as the sample size will be quite bigger and if anything comes up up we can fix that before making the changes available to everyone. but its totally your choice. But this will helpful for devs & maintainers.

[Drazail]

@Guichaguri

We used a rather similar approach to this at the start of our development cycle, however, Android used to be very aggressive with killing the app so we decided to go with your previous implementation. and so far ( after some minor tweaks) we haven't received any crash reports related to this library in months.

If you got any free time, please checkout my fork, it may provide some context to this comment. ( all of our media endpoints are mp3 files on s3, so this has not been tested for any other media types.)

[biomancer]

Hi @Guichaguri! For us these changes would mean that we would have to stick to some old version or fork forever, as it seems as there is no way to get tracks to reliably play in background if not using service approach. As you have pointed out, it is a big differential from other music modules and it was actually the main (or even the single) reason, why we started using react-native-track-player in the first place - the other solutions just could not provide reliable background playback.

[bemnet4u]

Happy to test this.

I already set stopWithApp=true since when the user kills the app, we need to kill audio as it seams the right thing to do...so not too worried about that.

[ashokkumar88]

I am getting the following error whey trying to play a track.

com.facebook.react.bridge.ReadableNativeMap cannot be cast to com.facebook.react.bridge.JavaOnlyMap

[abdelmagied94]

@Guichaguri Is the notification capabilities still working? As mentioned in the android docs, MediaButtonReceiver needs a service to receive ACTION_MEDIA_BUTTON intents.

[dcvz]

I will close this for now.. at the moment I don't believe the future of this library should be to disable the service.

Overall this is what allows us to build applications that can work in the background and not be killed by the system.. if there's such a need in the future, we'll re-evaluate.