MediaBrowserService (Android Auto & Bluetooth AVRCP) support

[OxygenCobalt]

Self-explanatory. Requires #92 so that I can mirror the queue, and internal technical reworks so that I can implement a media browser into the playback engine.

[OxygenCobalt]

Merging into #52.

[OxygenCobalt]

Reopening since #52 is not happening.

[OxygenCobalt]

Related to this, in the next release you should have access to Auxio's queue from Android Auto. Still not mutation though, as I'm still grappling with the technical aspect of that.

[OxygenCobalt]

This issue will also seemingly resolve the Wavelet issue where Auxio will show up as "null" in the notification. Can't fix it until I have a working media browser implementation.

[OxygenCobalt]

Blocked until I can fix Auxio's jank service lifecycle with #244.

[ghost]

Any update on this or any way how I can help?

I dont know any maintained FOSS music app that actually supports Android Auto (except Metro but that's basically dead aswell).

[OxygenCobalt]

Currently, I am busy with school and more prioritized functionality, given the difficulty of this change. You have two options to help out. @BabyBenefactor:

• Become a sponsor and prioritize this issue to force me to implement it as soon as possible. If you prioritize this for $8/month, I will start after Per-song album covers #342 and Make moving song in queue smoother #686, which have already been prioritized. If you prioritize this for $16/month, I will start on this first.
• If you have advanced android development knowledge, implement this yourself and PR it in. This involves a pretty drastic refactoring of Auxio's internals (See Service independence (Starting playback without opening app) #244), but I can give guidance.

[ghost]

This feature isn't something that needs prioritisation so please don't feel rushed. Since I don't think I have the sufficient coding skills to refractor this app, I won't be trying that :P
Just wanted to know the status and its good that it is on your radar.
Good luck with school!

[OxygenCobalt]

This feature isn't something that needs prioritisation so please don't feel rushed.

Prioritization would not make me have to implement it by the end of the month. It just means I will do it first, whenever I have the time. @BabyBenefactor

[gtsiam]

It may not need prioritization, but it would be much appreciated. I've been telling myself I'll do it, but I havent been able to find the time just yet.

I might still do it, so ping me if you start working on it @OxygenCobalt. In any case, mark it for prioritization.

[OxygenCobalt]

Okay, I've marked this and the required #244 as prioritized. It will be done after #342, which was prioritized earlier. A $16/month sponsor could prioritize this such that I do it first.

I am also open to contributions @gtsiam. Note that there are a lot of architectural details here, since you have to make PlaybackService operate without the assumption that the app is already in foreground. This means:

• You must merge IndexerService and PlaybackService together, which also requires handling the interaction of their lifecycles.
• You must enter a foreground state as quickly as possible, possibly through a music loading notification. Then you swap that out with a playback notification.
• You have to make sure music loading (especially responding to music changes) operates correctly in all service states. I forgot the specifics here, but I'll get to them later.

This is really general, since I've yet to map out the specifics on what needs to be fixed.

[OxygenCobalt]

Update Time!

So I've merged the two services, kind-of. What used to be the services now inherit a weird "fragment" class I made up. But they are still operating under the assumption that the app is in the foreground. The issue is that the flow might be something like:

• Music starts loading, so the service goes foreground
• Music finishes loading, so the service exits foreground
• <200ms of delay as Playback initializes
• Playback goes foreground
• Android 12+ gets angry and kills our app because gosh forbid you go background in any capacity (It's okay if you use firebase though. Because google cloud needs to hit it's quarterly revenue targets.)

And that's if there's music to be loaded and things to play. If there's neither, no foreground will occur and eventually the app is killed by the system for not starting foreground in time. As a result, I must design the service lifecycle under two hard rules:

1. Absolutely no downtime. Even if you're not doing work, hang on the last foreground notification until you're absolutely certain we can safely exit foreground without suprises. I think I can do this by basically making the service "fragments" flag if they want to foreground, background, or if it doesn't know what it wants to do yet.
2. Always assume you have basically no time to go foreground. OEMs probably play fast and loose with the foreground time limit, so I may have to start foreground with a fake notification just to satisfy the OS.

There's likely more refinement I need to do regarding this. I have some ideas on how to detect from the service's end if it was started by another part of the OS or if it was started by the app, which should allow me to switch between uptight and loose foreground behavior. Sadly I'm tied up with all the 3.4.0 bug reports, school, and a hackathon, so I'm not going to be able to do much for now.

[ghost]

Looks like great progress, thanks for your work!

[OxygenCobalt]

Minor Update: Still have no time to work. But I realized in #244 that Android may actually tolerate Auxio briefly going into the background. It could be possible that the background service restrictions only apply once. From there I can swap between background and foreground whenever I want (within reason). This'll make things a bit easier if true. I need to test though.

[OxygenCobalt]

I've started implementing this using the new service implementations provided by media3. I'm arriving at a point I'd describe as "usable" but I need to do a lot of extensions. There's also no guarantee that I'm not silently introducing lifecycle issues.

[OxygenCobalt]

External apps can now access Auxio's music library:

(This is from an app made to test this, you can find it here)

From here I need to do a full integration with android auto (requires some extra config), and then continue rounding out and making bug fixes.

[OxygenCobalt]

Introducing the first Auxio Android Auto build!

Warning:

• This is probably extremely broken since I'm can't figure out how to test it in an emulator
• You probably still need to open the app first and play some music before connecting to it on Android Auto (I'm working on that, see Service independence (Starting playback without opening app) #244. I hope it'll work)

Auxio_Canary.zip

@BabyBenefactor @gtsiam

[ghost]

Thanks for all your hard work and all the updates regarding the work - it is simply amazing to see.

I just installed the app and tested the app with a pixel 8 and it works flawlessly. I could not find any issues. Things like playback, shuffle, album/artist views, the ''extra'' tab containing things like playlists - it just works really nicely and is on the same level as other music playing apps. Heck, even the thumbnails render correctly (even in split screen view) which VLC **s up for some reason.

Now I am just a sample size of one, but I think the Android Auto part is working amazingly. Thanks again for your amazing work
@OxygenCobalt

[OxygenCobalt]

Thanks for the feedback! Can you send me some pictures of what it looks like in android auto (if possible) @BabyBenefactor? I can't test it myself and I want to make sure it "looks right".

[OxygenCobalt]

Closing this for now since it's basically "done" minus bug fixes.

[ghost]

Sure! Note that Android Auto just uses templates for apps, so apps like Spotify, VLC and Auxio all look the 'same' (minus some icons and quick action triggers)

Link to images (no need to download) https://drive.proton.me/urls/XFJHQGX7Y8#9SVlK0I2fq3a

Hope this will see final release soon, thanks again for the amazing work @OxygenCobalt

[OxygenCobalt]

This is perfect, thanks @BabyBenefactor. Overall it seems like it works well.

[ghost]

Just finished a few hour drive using my navigation app and Auxio in splitscreen continously. No crashes or hiccups at all. Voice commands also work.

I did not test the new Android-side implementation yet

[OxygenCobalt]

Okay, there will be one minor degradation: Due to a bunch of annoying internal issues, the notification cover will be stuck on it's default setting until #327. I didn't want to do this, but media3 is not really designed well for this.

[curbengh]

A feedback on how tags are shown on the gauge cluster.

Center console	Auxio	VLC
Top line	{title}	{title}
Bottom line	{artist}	{track} / {album tracks} · {artist} - {album}

Gauge cluster	Auxio	VLC
Top	{title}	{title}
Middle	Unknown	{album}
Bottom	{artist}	{track}/{album tracks} · {artist} - {album}

I think showing artist at the bottom (console+cluster) is correct. It'd be nice if Auxio can display album title on the gauge's middle line.

Screenshots

[OxygenCobalt]

This is weird @curbengh, I'm publishing all my metadata as right as far as I am aware. Will need to see what's going on with VLC.