feat: Android Auto Support

[lovegaoshi]

continuation of #2043 . Synced up with RNTP v4.0.0 rc07

[caustin24345]

Hi @lovegaoshi - I'm wondering if local files could be supported for an Android Auto MediaItem's iconUri. It seems like this is possible with items added to the TrackPlayer (using require('path_to_local_file')), which directly updates things like the images in the Android Auto player screen, and icons in the playback queue, but not possible for the icons in the Android Auto lists.

My understanding is the iconUri string gets mapped to the mediaDescriptionBuilder.iconUri which is used to populate the MediaItem that we see on the Android Auto screen, so in theory it should be working for any local file Uri that gets saved to a device (i.e a downloaded piece of content + image that is saved to local storage).

Have you had any experience with this in the past or during testing?

FYI - Forcing a loading indicator for an AA template is possible by temporarily sending a result of null in the onLoadChildren callback.

[lovegaoshi]

I don't think when i first made it, i made it right that it also accepts a resource id; see
lovegaoshi/KotlinAudio@7a3d90b#diff-7d05808a134fc6efdaef2d0049ac5bf23ee4367c6c2601f159b4577f6bbb29bfR205
you'd probably have to put in a uri identifier there?

[PatelPiyush04]

I'm utilizing react-native-track-player for my player implementation in a React Native app. While attempting to fetch local artwork stored at "file:///data/user/0/au.com.podcastoneaustralia.dev/files/offline/c95fee2d-5099-4ace-8c86-b00500231c2e/imageUrl.jpg", I encounter an issue where the artwork fails to load within the list and player components. Strangely, it displays perfectly fine for the queue list in Android Auto.

My understanding is the iconUri string gets mapped to the mediaDescriptionBuilder.iconUri which is used to populate the MediaItem that we see on the Android Auto screen, so in theory it should be working for any local file Uri that gets saved to a device (i.e a downloaded piece of content + image that is saved to local storage).

I'm seeking assistance to resolve this inconsistency and ensure that the local artwork loads seamlessly across all components, including the list and player interfaces within the Android Auto app.

1. media List : AndroidAutoBrowseTree

2. Player View

3. queue list: where we used ** TrackPlayer.add** it accept the require("file path")

[lovegaoshi]

its a bit more complicated than that:
the media list you are referring to uses setIconUri as per google's guidelines. https://developer.android.com/media/legacy/audio/mediabrowserservice#communicating_content_with_onloadchildren

the player view you are referring to uses specifically lovegaoshi/KotlinAudio@7a3d90b
(see discussion: #1984 (reply in thread))
I have no idea what the queue list uses, but it should be exoplayer's item.

so you're looking at onLoadChildren, NotificationManager, and exoplayer's internal queue - I guess I'm not surprised only the internal queue behaves if some of them has to fail.

If I did setIconUri correctly, then I believe this is a better question to google/media3; however the way we used this, exoplayer2, is depreciated and I doubt google will give you an answer. Otherwise you're welcome to poke around yourself

[andreknieriem]

Hi there. I've testet your version and it is working great. Do you have a hint for long lists? For example a list of all albums/tracks or all tracks in a playlist? Is there a "ScrollToEnd" Event to fetch more items?

[lovegaoshi]

hi! i rememebr seeing an implementation of infinite scrolling on android auto but i didnt save it. also for your consideration it is quite bad ux to scroll that far on a mot that responsive hud, its recommended to use voice search i dont think aa registers any scrolling events on googles guidelines but youre welcome to look. it up.

…

On Thu, Apr 18, 2024, 5:20 AM Andre Rinas ***@***.***> wrote: Hi there. I've testet your version and it is working great. Do you have a hint for long lists? For example a list of all albums/tracks or all tracks in a playlist? Is there a "ScrollToEnd" Event to fetch more items? — Reply to this email directly, view it on GitHub <#2094 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZMOVVXPD4J7CBSZ33RY6BLY563BNAVCNFSM6AAAAAA3OM3BA2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRTG4ZTMMJQG4> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[michele-ruocco]

Hi @lovegaoshi,
I thank you for the great work you are doing for the whole community.

Have you had a chance to check and understand how to handle an Android Auto startup from closed app?

Also, I would like to point out that development for Android Automotive OS (AOSP) is growing rapidly. https://developers.google.com/cars/design/automotive-os

Could this be a launching point to support it?

The big challenge here is that Android Automotive is an operating system and platform running directly on the in-vehicle hardware supporting development as for Android Auto but no primary Activity is available.

[lovegaoshi]

hi!
see https://github.com/doublesymmetry/react-native-track-player/pull/2094/files#diff-1d541f5b0b5ea040825889f05cb7e342bfe8d0b64177561b49dc819a0804ee36R63
as for AOSP IMO its a pretty remote system that only very few models use. and NO this is not a launching point to support AOSP bc AA and AOSP are completely different. also i personally have a camry so i dont have any interest.

[gavrichards]

Do you think this is ever likely to be merged into the main branch? Have the maintainers shared what their reluctance is, or is it just a case of needing time to review?

[dcvz]

Do you think this is ever likely to be merged into the main branch? Have the maintainers shared what their reluctance is, or is it just a case of needing time to review?

My hope has always been to get this in -- the reluctance has been about the need for the main project to eventually update to using media3 for Android audio playback. There are some adjustments I'm envisioning will need to happen here, and as stretched out as I am, I am fearful of getting this in before then and then being responsible for also maintaining this behaviour after migration.

I understand though that this has been waiting for a while and am sorry for that.

[lovegaoshi]

well, this pr does blatantly copy headlessJsTaskService from the rn repo... so it locks rn versions. its quite destructive but imo also have other good uses, like properly implrmrnting the wakelock but also if u had the chance to follow the newarch pr, meta currently isnt supporting headless with newarch + bridgeless on rn0. 74. this is gonna be difficult to maintain for sure. also bout the ?media3 migration - there is an easy way that doesn't change much (though its gonna be heavier on my side tl migrate to MediaLibraryService) and one that needs an android rewrite. either way im still maintaining this fork since my app depends on it.

…

On Tue, Apr 30, 2024, 5:07 AM David Chavez ***@***.***> wrote: Do you think this is ever likely to be merged into the main branch? Have the maintainers shared what their reluctance is, or is it just a case of needing time to review? My hope has always been to get this in -- the reluctance has been about the need for the main project to eventually update to using media3 for Android audio playback. There are some adjustments I'm envisioning will need to happen here, and as stretched out as I am, I am fearful of getting this in before then and then being responsible for also maintaining this behaviour after migration. I understand though that this has been waiting for a while and am sorry for that. — Reply to this email directly, view it on GitHub <#2094 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZMOVVR5QOQSOK3VPATNH5LY76CRFAVCNFSM6AAAAAA3OM3BA2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBVGE2TOMJZGU> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[andreknieriem]

Hi @lovegaoshi . I've maybe found a bug. There is no "subtitle"/artists on my headunit. I've tried the default artist for trackplayer and a subtitle too. But none of them is showing up. Any advice?

[lovegaoshi]

i dont think RNTP track has a subtitle property - u could try mapping all artist to subtitle and see if that works

[andreknieriem]

i dont think RNTP track has a subtitle property - u could try mapping all artist to subtitle and see if that works

So you don't have a subtitle too in your android auto headunit?

Here I am missing Linkin Park as artist. In my list views it is showing up:

Of course I tried to set subtitle on my now playing item but it doesn't work. Any idea?

[lovegaoshi]

how exactly did u map/use subtitle?
eg if u map artist to subtitle like this lovegaoshi/KotlinAudio@aefe6d8
it would work:

which works the same if u set the mediaItem's subtitle as well

[andreknieriem]

Thanks for your answer, but I don't get it.
I have a playlist like this with 1 track for example

[
  {
    id: 11,
    title: "More the victim"
    subtitle: "Linkin Park",
    artist: "Linkin Park",
    url: "https://url.com/lp.mp3",
    duration: 200,
    artwork: "cover.jpg"
  }
]

This works all in my app on my phone with trackplayer. It shows everywhere in the notification and so on. On my android auto it doesn't show the artist. You see I tried setting both artist and subtitle, but that didn't change anything. Now I tried your latest version with implementation 'com.github.lovegaoshi:KotlinAudio:v2.0.0-aa23' as dependency but it says, that there is no version aa23 in jitpack.io.

[lovegaoshi]

should be built now? https://jitpack.io/com/github/lovegaoshi/KotlinAudio/v2.0.0-aa23/build.log

…

On Thu, May 16, 2024, 9:23 PM Andre Rinas ***@***.***> wrote: Thanks for your answer, but I don't get it. I have a playlist like this with 1 track for example [ { id: 11, title: "More the victim" subtitle: "Linkin Park", artist: "Linkin Park", url: "https://url.com/lp.mp3", duration: 200, artwork: "cover.jpg" } ] This works all in my app on my phone with trackplayer. It shows everywhere in the notification and so on. On my android auto it doesn't show the artist. You see I tried setting both artist and subtitle, but that didn't change anything. Now I tried your latest version with implementation 'com.github.lovegaoshi:KotlinAudio:v2.0.0-aa23' as dependency but it says, that there is no version aa23 in jitpack.io. — Reply to this email directly, view it on GitHub <#2094 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZMOVVXBHKBHILV5BW2XGHDZCWA4JAVCNFSM6AAAAAA3OM3BA2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJWGU4TOOJQHE> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[KestasVenslauskas]

Wanted to try this out but can't get past this error:
Failed to resolve: com.github.lovegaoshi:KotlinAudio:v2.0.0-aa23

[lovegaoshi]

can u not build? bc i can

or ur network/jitpack is not stable rn

[KestasVenslauskas]

can u not build? bc i can or ur network/jitpack is not stable rn

Yes it was just an issue with jitpack being down probably. Now it works

[lovegaoshi]

edit about album art on AA:

I originally enabled album art via lovegaoshi/KotlinAudio@7a3d90b but google's guidelines seem to contradict with that. nevertheless however RNTP is currently set up (for ex https://github.com/lovegaoshi/react-native-track-player/blob/6f634594f24aa1974b2c8cdc6848b8b349cccdf0/android/src/main/java/com/doublesymmetry/kotlinaudio/notification/NotificationManager.kt#L389) for remote urls it works great, but for local uris (file:///) and embedded covers within local media files it wont work.

for local uris while I do not have a use and no rigorous tests yet, I believe converting the file:/// uri to a content:// one, as specified in the google guidelines, would work. u can see how i did this via a fileProvider: lovegaoshi/azusa-player-mobile#449

for embedded covers (which I worked on for the past few days) this has to be first resolved and written to a file, then load the content:// uri as in the google guidelines. I tried with both ffmpeg and MediaMetadataRetriever, opted for the latter in the end for simplicity. commit is here: lovegaoshi@6f63459

the specific implementation I have does have a drawback taht the local file is written in the /Pictures folder. you might be able to write to cache using File() then convert to content:// with a fileProvider, but I chose the simplicity of MediaStore and can deal with this drawback.