Android Auto support: app rejected due to EP-1 / EP-2

[umbertogrimaldi]

Use case

First of all, thank you for the incredible work on audio_service and just_audio. We've been successfully using both in our Flutter app to manage playback and media session integration.

We're currently implementing Android Auto support, and while the playback controls (play, pause, seek, metadata) work well with the standard MediaSessionCompat integration provided by audio_service, we're facing a blocker during the Play Console review.

❌ Issue

Our app has been rejected by Google due to Android Auto policy violations:

• EP-1: Media content is not properly exposed to Android Auto.
• EP-2: App does not provide a compliant user interface for media browsing.

✅ What works

• Playback controls and metadata updates are functioning in Android Auto.
• Notification integration and media session are behaving as expected.

Proposal

🧩 What we’d like to ask

• Is full Android Auto compliance something that is currently supported or planned in audio_service?
• If not, do you have any suggestions or planned solutions to address this issue?

Thanks again for your time and your amazing libraries!

[ryanheise]

Hi @umbertogrimaldi , thanks for your comments. I don't use Android Auto myself directly, although I know others using this plugin do use it with Android Auto successfully (which you can search for in the past issues). All that I have done on my end is to ensure that all of the relevant APIs from the Android side are exposed in some way, but I don't personally have any advice for how to use those APIs. For an app developer wishing to use Android Auto, it's a matter of reading Android's own developer documentation about Android Auto, following their guides and steps, making the appropriate edits to the appropriate XML files, and using the audio_service equivalents of the APIs Android's own guide asks you to use.

I am sure that not only users of audio_service, but also users of the Android SDK will equally run into Play Store rejections. I've heard it can be difficult to follow every instruction to the letter.

[umbertogrimaldi]

@ryanheise Thanks a lot for your reply, I really appreciate it.

I'm currently exploring how to improve Android Auto integration using audio_service, and I came across getChildren and browsableRootId in the API.

If you have a moment, could you share a bit more about the intended purpose of those methods and how they relate to exposing media content to external clients like Android Auto?

Any additional context or direction would be very helpful.

Thanks again for your time!

[ryanheise]

These correspond to the native Android APIs onLoadChildren and onGetRoot.

[umbertogrimaldi]

@ryanheise Thank You. Just Implemented these. The only thing that I'm not getting is if there is a method to update the getChildren list, if for example the audio source is changed

[ryanheise]

To understand Android Auto, what I would suggest is Googling for the same questions about the Android SDK but search for onLoadChildren instead of getChildren. These methods are the same. As mentioned above,

For an app developer wishing to use Android Auto, it's a matter of reading Android's own developer documentation about Android Auto, following their guides and steps, making the appropriate edits to the appropriate XML files, and using the audio_service equivalents of the APIs Android's own guide asks you to use.

[kcs-govindtank]

@umbertogrimaldi do you able to get your android auto supported app approved from google team ? is your app live currently with android auto support with the same audio_service package ? because we are also planning to release similar version of our app which will have android auto(flutter audio_service package based) and Car Play support (natively) but while searching i got to this issue, can you please confirm ASAP ?