Android Revamp

[dcvz]

Hello everyone! 👋

After the 2.0 release, we've been working hard on the next step of getting this library on a solid foundation to be able to bring and incorporate some of the vision we have for the future.

The next thing we've been working on is a revamp of the Android part of this library. This effort has been primarily led by @mpivchev where we've rewritten the Android side of the library to be more modern and robust. For the rewrite we've settled on using Kotlin as the library's language which has allowed us to use some more modern language features, API's and overall write safer code.

We expect this rewrite to already bring some benefits: especially around the background service playback and architecture.

The work is currently in progress - this effort is currently being released as a RC

The new version should eventually be feature complete and on par with the existing version v2. We hope that some of you will give it a try and help us iron out any initial kinks. We'll update the thread once we have the first pre-release.

You can install the beta versions by doing yarn add react-native-track-player@next

==========

We'd appreciate your help testing these beta releases to find any regressions and bugs! Not everything is supported yet, but we'll slowly make our way there -- but a lot of the core functionality is there to allow testing.

Required changes
Update android/build.gradle to include:

ext {
  ...
  compileSdkVersion = 31
}
dependencies {
  ...
  classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:1.5.30"
}

What works but should be tested:

• Support for Progressive, DASH, HLS and SmoothStreaming media types
• Audio focus and unfocus
• Adding and removing tracks
• Skipping to next or previous tracks
• Playing, pausing, and stopping the player
• Seeking
• Setting volume
• Setting the speed (rating) of a track
• Setting repeat mode
• Notification and notification controls
• Player caching (beta5)
• Rating types (beta11)
• Metadata functions (beta11)
• Track duration is not calculated properly (beta11)

Reporting Issues or regressions
If you find a regression please create a bug report Issue and use the android-rewrite label.

Thank you!

[phillipcmittmann]

Im seeing the app a lot more stable than the live version.

[dcvz]

That's great! That was one of the drivers and goals of this rewrite. We've still got some stuff to fix but its great that its already looking more stable. Thanks for the testing and reports ✨

[dcvz]

Another update today! We've released beta9 which fixes some reported issues around buffer options and property accesses.

Thank you @doughsay and @phillipcmittmann for testing ❤️

[dcvz]

Thanks for your thorough testing @doughsay ! I've just published beta10 which solves the first 2 issues.
Issue number 3, is not one we will fix -- and it doesn't have a big effect on things.

[dcvz]

This was now fixed @bradleyflood. RemoteJumpForward is passing in the interval

[mmmoussa]

Seeing the following infrequent crash reports from users with rc2:

Fatal Exception: kotlin.UninitializedPropertyAccessException: lateinit property player has not been initialized
       at com.doublesymmetry.trackplayer.service.MusicService.getEvent(MusicService.kt:47)
       at com.doublesymmetry.trackplayer.module.MusicModule.getState(MusicModule.kt:547)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:372)
       at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:188)
       at com.facebook.react.bridge.queue.NativeRunnable.run(NativeRunnable.java)
       at android.os.Handler.handleCallback(Handler.java:883)
       at android.os.Handler.dispatchMessage(Handler.java:100)
       at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:27)
       at android.os.Looper.loop(Looper.java:214)
       at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:226)
       at java.lang.Thread.run(Thread.java:919)

Fatal Exception: java.lang.IllegalStateException: Not allowed to start service Intent { cmp=my.app.bundle/com.doublesymmetry.trackplayer.service.MusicService }: app is in background uid UidRecord{5e6e32e u0a314 TPSL idle change:idle|cached procs:1 seq(0,0,0)}
       at android.app.ContextImpl.startServiceCommon(ContextImpl.java:1725)
       at android.app.ContextImpl.startService(ContextImpl.java:1680)
       at android.content.ContextWrapper.startService(ContextWrapper.java:731)
       at android.content.ContextWrapper.startService(ContextWrapper.java:731)
       at com.doublesymmetry.trackplayer.module.MusicModule.setupPlayer(MusicModule.kt:219)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:372)
       at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:188)
       at com.facebook.react.bridge.queue.NativeRunnable.run(NativeRunnable.java)
       at android.os.Handler.handleCallback(Handler.java:938)
       at android.os.Handler.dispatchMessage(Handler.java:99)
       at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:27)
       at android.os.Looper.loop(Looper.java:236)
       at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:226)
       at java.lang.Thread.run(Thread.java:923)

Fatal Exception: android.app.RemoteServiceException: Context.startForegroundService() did not then call Service.startForeground(): ServiceRecord{76fb52b u0 my.app.bundle/com.doublesymmetry.trackplayer.service.MusicService}
       at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2209)
       at android.os.Handler.dispatchMessage(Handler.java:106)
       at android.os.Looper.loop(Looper.java:246)
       at android.app.ActivityThread.main(ActivityThread.java:8414)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:596)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1130)

[mpivchev]

Thanks for this. These seem like multiple crashes, and since we don't have a good lead we can't reproduce them. I don't think we've ever noticed these crashes on our end. Please keep monitoring these and provide us more info if you can, like on which devices it happens, android version, etc.

[JDMathew]

Since adding classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:1.5.30" I seem to have an issue with Android Product flavours selecting the correct resolution folders for launcher icons. Instead of it using @mitmap-<res>/... it uses the default and skips resolutions.

I have also had an issue with launching the correct intent with applicationId in my build file. The application id is set in the product flavour but it still launches with intent of the default id.

[sarike]

I fixed the launcher icon issue after I generate adaptive icons with Image Asset in Android Studio. But I don't know the root cause.

[JDMathew]

@sarike, thanks I'll try that out. Do your adaptive icons sit in mitmap or drawable and are they working with both product flavours and different resolutions?

[JDMathew]

Okay I found the issue here, the issue is that from 2.2.0 build.gradle has the dependency implementation "com.github.DoubleSymmetry:KotlinAudio:v0.1.31" and KotlinAudio uses mipmap-anydpi-v26 in its res folder which is causing any icons named ic_launcher to be overridden with the one in mipmap-anydpi-v26. I don't think kotlin-audio should be using -anydpi-v26 as it is then used as the default and other resolutions are ignored.

A fix for this is to name your launcher icons something other than ic_launcher and then updated this name in your AndroidManifest.xml. I.e:

    android:icon="@mipmap/ic_launcher_appName"
    android:roundIcon="@mipmap/ic_launcher_round_appName"

[JDMathew]

The issue with launching the correct product flavour was unrelated but can be fixed with adding the application id into your script with --appId=<PRODUCT_FLAVOUR_ID>. i.e:

react-native run-android --variant=exampleVariant --appId=com.example.dev"

[sarike]

The Promise returned by TrackPlayer.destroy(); will never be fulfilled.

    console.info('destroy');
    await TrackPlayer.destroy();
    console.info('after destroy');

'after destroy' will never be output.

[mmmoussa]

Opened #1441 to fix on iOS

[JDMathew]

TrackPlayer.setupPlayer(options: PlayerOptions) is being rejected if the player is already setup. According to the documentation this shouldn't be the case:

You should always call this function (even without any options set) before using the player to make sure everything is initialized.

If the player is already initialized, the promise will resolve instantly.

I seem to have an issue on some android devices that the player isn't always setup and thus I was calling setupPlayer again on the screen it is used. I believe this should just resolve. It might be useful to have a constant like isPlayerSetup to know if the player is setup.

[mpivchev]

We've recently discovered a pretty severe issue in how we had designed the music service for Android, which allows music tracks to be played while the app is in the background. The following problems were found:

1. The service would sometimes crash and since we prevented the service from ever completely stopping on its own, it would restart multiple times without notice. Since there wasn't an explicit reaction to these restarts, the issue was hidden away until we found out about it. I have found a way to alleviate this, and the service is much more stable now.

2. When it was time to actually stop the service, it would not unbind and stop properly, leaving the app process running when it shouldn't. The plan is to fix this, but a possible solution would take experimentation and time.

These problems were in the original Android implementation as well, and the revamp sadly brought them over, unbeknownst to us.

I'm working on this at the moment, but it will take some time, as it's a bigger problem than originally thought.

[mpivchev]

I'm using a local version of our library KotlinAudio, so it can't resolve it. I will update the branch in a bit to use the remote version. Please note that this PR is still a draft and things might be broken.

[mpivchev]

@afkcodes try again

[afkcodes]

This works Flawlessly @mpivchev is amazing. Waiting for the stable release now excited, it crashed once but the service is now getting killed with the app.

[elliotdickison]

Awesome, very excited to try this out once #1418 is done

[rpadilla6]

Looking forward to trying this out in the next rc! I was having some issues with an HLS stream getting killed when listening in background mode, but this appears to fix it 👍

[jenshandersson]

We're seeing this lateinit crash in production with rc-2.
Not sure what more I can share about it, but it seems like it can happen after reset() and add().

[JDMathew]

I have posted the following issue regarding Trackplayer.add() this issue effects the latest version as well as previous versions

[JDMathew]

There seems to be an issue with TrackPlayer.reset() resolving it's promise too quickly.

I have posted this issue on the topic. As far as I can tell it only effects the release candidate for the Android rewrite.

Might be related to the issue that @jenshandersson is seeing on production

[mpivchev]

Just FYI, a lot of the crashes recently reported might be related to this.

[nickmcmillan]

I'm seeing a lot of crashes (via Firebase Crashlytics) with the message;

Fatal Exception: android.app.ForegroundServiceDidNotStartInTimeException
Context.startForegroundService() did not then call Service.startForeground(): ServiceRecord{8610d02 u0 com.smilingmind.app/com.doublesymmetry.trackplayer.service.MusicService}

android.app.ActivityThread.throwRemoteServiceException (ActivityThread.java:2143)

FWIW, I'm initialising TrackPlayer once only at the top level of my app (with Trackplayer.setupPlayer inside a useEffect). It never gets unmounted or destroyed.

I have stopWithApp: true - not sure if that could be related?

100% of the crashes are Samsung on Android 12 (from 250+ crash events).

"react-native-track-player": "^2.2.0-rc2"
"react-native": "0.66.4" (not Expo)

[mpivchev]

Yes, that's what I think.

[JDMathew]

I also initialise on start up and had a similar issue on Samsung devices where for some reason the track player wasn't always being initialised properly but also wasn't reporting an error, then when I tried to play or add a track it would fail. I'm not sure what the underlying issue but for now I added a "catch all function" where before trying to use TrackPlayer I run a function called setupIfNecessary which checks if the player is setup and if not calls setup again.

[DennisdeWitNL]

Mind sharing the code?

[JDMathew]

Sure, so what I do is I call setupIfNecessary() inside my useEffect which only runs on component initialisation. The setupIfNecessary function checks if I can get the current track (Or any Trackplayer function that requires setup to be completed). If this throws an error then there was an issue with the trackplayer setup.

const setupIfNotInitialized = async (error) => {
  if (error.code === 'player_not_initialized') {
    await TrackPlayer.setupPlayer({})
    await updateTrackPlayerOptions()
    crashlytics().log('Needed to setup of player in AudioPlay Screen')
  }
}

async function setupIfNecessary () {
  try {
    // if app was relaunched and music was already playing, we don't setup again.
    const currentTrack = await TrackPlayer.getCurrentTrack()
    // checks null and undefined
    if (currentTrack != null) {
      return
    }
  } catch (error) {
    console.log('Failed to get track', { error })
    await setupIfNotInitialized(error)
  }
}

[DennisdeWitNL]

@JDMathew I tried this, and after adding my custom command for adding the dynamic streams (the streamURL changes, depending on which radio station was chosen), it seems it is finally working the way I intended.

I noticed this problem happens much more often on Android 9 than Android 10 or Android 11. So I have debugged it using Android 9 on the Android Emulator. Now it also works fine with an old Samsung S7 Edge. At least, it seems so for now.

Thanks a ton! :)

[mpivchev]

Hi! We just released v2.2.0-RC3. It's rebased against main and includes the following changes:

• Copy doc strings to main api functions #1423
• Don't round times to integer #1427
• Fix iOS track loop crash #1434
• Add service running boolean hot fix #1452
• fix(android): move the kotlin-gradle-plugin dependency into the libra… #1446

[mmmoussa]

I just tried installing this release but am not seeing the changes that were supposed to have been included. I even deleted the package from my node modules and re-installed.

[hammadwahab12]

@mpivchev need help with this one as I am also using react-native-video
#1418

[SDuBey001]

struggling to get this running in an existing app. It looks to be a kotlin/gradle dependency issue. Can you confirm the required versions of these please. We have another integration that prevents just going to latest builds.

[ovbm]

I was able to get it running with kotlinVersion = "1.5.30" and com.android.tools.build:gradle:7.0.4

[DennisdeWitNL]

Indeed, this version is completely BROKEN and should not be used!!!

kotlin-classes/release/META-INF/react-native-webview_release.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.6.0, expected version is 1.4.0.

[austinried]

Hi, so I'm working on ironing out the kinks in my app using the latest RC3 and I've noticed that the next button disappears from the notification sometimes. I thought this was a bug at first but then I realized it happens when I'm on the last song in the queue, so it seems intentional, but can we get a way to opt out of this behavior?

It's very weird to me that it disappears altogether and then the stop button moves over to take its place, and I'd much rather have the old behavior back. If not that then at least an error that I can catch on the RemoteNext event and loop back to the first track and pause on my own.

[austinried]

Actually, I was going to say I might be able to offer a PR where it at least throws an error on next when there's nothing left in the queue, but now that I'm poking around in the code I can't seem find where this conditional hiding of the next button is, so is this actually intentional?

[mpivchev]

It's not intentional. Capability.SkipToNext should be added to capabilities AND compactCapabilities inside TrackPlayer.updateOptions so it can show both when the notification is collapsed and expanded.

 await TrackPlayer.updateOptions({
      stopWithApp: true,
      capabilities: [
        Capability.Play,
        Capability.Pause,
        Capability.SkipToNext, // should be added
        Capability.SkipToPrevious,
        Capability.Stop,
      ],
      compactCapabilities: [
        Capability.Play,
        Capability.Pause,
        Capability.SkipToNext, // should be added
      ],
    });

[austinried]

Yeah I've got it in both, and it's consistently disappearing when on the last song in the queue. Might be unrelated but I've also noticed the order of buttons changed for me from "previous, play/pause, stop, next" to "previous, play/pause, next, stop"

Here's where I set the capabilities in my app, they've been the same since before I switched to the latest RC3: https://github.com/austinried/subtracks/blob/6361168a06ab2692a7bd2123d85d53fba9821c8c/app/screens/SplashPage.tsx#L54

[austinried]

I'll file a bug for this then, since the same thing happens in the example app if you turn off repeat.

[DennisdeWitNL]

So, I noticed that when I add a track, the metadata is working perfectly on the Android Command Center, but it is showing 'unknown' at the Android home screen (lock and unlock), does anyone have this problem too? :)

[austinried]

There's an issue open for it here: #1478

[fatlinesofcode]

is there going to be an rc4 release?
we see lots of commited fixes since rc3. It doesnt seem to be possible to install the latest updates via npm we have tried npm install https://github.com/doublesymmetry/react-native-track-player.git#8a58512 --save but get errors with prepareGitDep

[mpivchev]

Since this conversation has become way too big and new comments and replies are getting hard to find, I will be closing it.
I will still try and get to the remaining unanswered posts here in the coming days.

You are still welcome to use the issue reporting with the label android-rewrite.