Is UAMP's media3 branch still maintained?

[nift4]

Hi,

is https://github.com/android/uamp/tree/media3 still maintained (because last commit was quite a while ago)? Or is there another sample as comprehensive (supports phone, tablet, car, etc)?

Thanks!

[andrewlewis]

@SigmanZero Nevin, please take a look?

[tonihei]

Nevin can correct me, but I think we stopped maintaining UAMP because it's bound to be too easily out of date. The Media3 Session demo is the main demo app for everything related to session support and should showcase all the main features. Is there anything in particular you are missing from the session demo app?

[nift4]

My primary concern at this time is PackageValidator: https://github.com/android/uamp/blob/media3/common/src/main/java/com/example/android/uamp/media/PackageValidator.kt
and the associated signature list:
https://github.com/android/uamp/blob/media3/common/src/main/res/xml/allowed_media_browser_callers.xml
because those two are non-trivial to keep up to date, and just being able to copy-paste these from UAMP and having every known client to MediaLibraryService covered was helpful. Of course, something like this integrated into media3 itself would be even better.
The session demo doesn't seem to perform any validation, but I'm not sure if it's appropriate to allow any app access to the user's music through MediaBrowser (I imagine this could be misused for fingerprinting?).

[tonihei]

In Media3 there are the utils like isMediaNotificationController, isAutomotiveController and isAudioCompanionController that are also used in the demo app in onConnect to provide different capabilities than to other random callers. Is this what you are looking for?

As far as I can see, the UAMP filtering has a few more like isWearCompanionApp or isGoogleApp. Do you think it's useful to add these the Media3 as utils? In the end, it's down to your app to decide whether the browsing is open to everyone or a specific list of use cases.

The other thing done in UAMP is to verify the signatures of these apps. This seems impossible to maintain and I'm not entirely sure what the benefit is. The only way for an app the have the same package name as one of these known apps is to be side-loaded (outside of Play Store or other app stores publishing the real apps) and the real app must not be present on the system at the same time. If we decide this is useful, we could add the same checks to the util methods mentioned above, but otherwise it seems to be fine to rely on the package name.

[nift4]

As far as I can see, the UAMP filtering has a few more like isWearCompanionApp or isGoogleApp. Do you think it's useful to add these the Media3 as utils? In the end, it's down to your app to decide whether the browsing is open to everyone or a specific list of use cases.

Well, to mirror the entirety of UAMP's filtering, we'd need to:

• add (if still relevant) com.google.android.autosimulator to isAutoCompanionController
• create isWearCompanionApp, isGoogleApp and isAutomotiveAssistantApp for google apps by package name
• add isThisApp for same-UID filtering
• add isPlatformSignedApp
• add isSystemUidApp
• add isMediaContentControlPermissionHolder (hopefully with a better name, but you get the idea)
• add isSessionManagementPermittedApp to check if app has notification listener granted (like Media Controller Test would do)

That is quite a lot of methods to filter. And it's precisely why I'm concerned if the UAMP list ends up being outdated:
There is no clear indication which part of the system or Google apps does what.

For example, UAMP comments specifies that notification listener check is required for Wear OS notification controls, but it also hardcodes the Wear companion app. Meanwhile, media content control is stated to be useful for Google Assistant (and Android TV), and the Google app is also hardcoded allowed. I don't know which configuration of Assistant this refers to anyway (integrated into Google app, standalone Assistant app that used to exist a while ago or maybe even Gemini standalone app?).

I am not confident in deciding and also testing all of these configurations myself, which is why the UAMP reference was very useful.
In which exact form a media3 API would materialize is something I am not sure about.
Adding additional helper methods would be fine for me, but that depends on whether you are open to adding 8 new methods and changing one existing one - if there'll only helpers for half the usecases I still would need to hardcode some magic from UAMP in my project and would have no idea if it's up-to-date, so that would not really solve my problem. And I think UAMP has these checks for some reason, they're required for some usecase. On the other hand, if all of them are added, the fact that these usecases exist will be discoverable and developers can just pick their combination of intended usecases without worrying about whether the checks will become stale in their app code. Or maybe you have a better idea?

Regarding signature verification, I agree it doesn't really matter.

[tonihei]

isPlatformSignedApp/isSystemUidApp/isMediaContentControlPermissionHolder/isSessionManagementPermittedApp are all covered by ControllerInfo.isTrusted(). We'll discuss further what to do about the other ideas and how to maintain them.

[nift4]

I didn't know that existed ;-; thank you!
May I suggest extending isTrusted to same-UID apps (or just same app) as well? I think that would make sense, and would cut down the missing checks to just four.