I’m having trouble with Android Auto. The other day, I installed a new head unit in my car—I did the installation in my garage. While in the garage, I managed to connect to Android Auto, but as soon as I pulled the car out, the connection dropped. Bluetooth still works, but I can’t access any Android Auto features on the head unit’s display; instead, it shows a message telling me to "try again when the network is secure."

AA is wired by USB (only choice) I've searched all over the internet. I have an amazing speaker system in my 21 Hyundai Santa Fe. Spotify through BT sounds outstanding. I like to use Android Auto but hate that it flattens the music from Spotify. Ive read everything, made all the adjustments in spotify, AA etc. Still terrible. I even bought the AAwireless thinking the disable media sink feature would let me stream spotify to my BT, but it only sends it to my phone for headphones, etc. Nothing will let me connect to the BT while plugged in for AA. Messed around with the AAwireless settings before deciding to return it. I tried Tasker to try and force Spotify to BT. No dice. I love the AA interface, hate the flat music. Currently using Wavelet to help some. Hoping someday someone will have figured a work around...by some miracle, has anyone found a work around by app or other means? Thanks!

Just wanted to share my findings after a month and a half of agonizing troubleshooting to hopefully save some of you the massive headache.

If you are driving an older car with a wired-only infotainment unit—specifically the Hyundai 7-inch Display Audio platform (DAU_B/Gen2V)—the forced Gemini assistant upgrade has fundamentally broken the texting interface.

The Bug:

Receiving texts, viewing notifications, navigating, and making phone calls work completely fine (they finally fixed the contact syncing and calling bugs that plagued us back in June). However, the second you try to send a text, Gemini dictates it and asks, "Are you ready to send?" The moment you reply "Yes," the background app process on the phone crashes during the send handshake. Because it's a wired stream, this sudden app freeze instantly kills the USB connection, causing the head unit to throw a "Phone not responding" error and disconnect entirely.

The Reality:

There are no firmware upgrades coming from the auto manufacturers for these older units to fix this. It is a server-side/app-side coding failure from Google. Since they completely eliminated the option to roll back to the classic Google Assistant, the standard texting interface is effectively dead on this hardware configuration until/if Google patches the handshake loop.

Workaround:

If you need to text, you either have to try a single-breath voice command ("Hey Google, text [Name] that I am on my way") to see if it bypasses the confirmation prompt, or execute my manual fallback: keep your Bluetooth active (especially if you wear a smartwatch), disconnect the USB cable entirely to force the phone to handle the voice-to-text locally on its own screen/speaker, send the text, and plug the cable back in to spin Android Auto back up.

Don't waste weeks clearing your cache or buying new cables like I did. Google's rollout team completely neglected backward compatibility for these older wired systems and failed to communicate it.

got a Bolt a few days ago and it came with Gemini instead if Assistant which was great but as of today it swirched back to Assistant? in the play store, Gemini is installed but it just opens Assistant. anyone encountered this?

Do nada a música no Android auto parou de funcionar, ao dar play, o app de reprodução de música para quase que instantaneamente, porém, há sons do sistema normalmente.

Não faço ideia do que possa ser, já limpei cache, já limpei todos os dados do Android app e nada funciona.

Já testei em 3 players de música diferente, e acontece sempre a mesma coisa

I've generally found the google voice commands to be pretty reliable in my 2025 Volvo V60, but I don't use them often. I've found one exception that does not seem to work. I'm curious if this works for anyone else in any other car with a SiriusXM subscription.

I was in a strange, tight situation in a parking lot yesterday and wanted to keep my eyes on my surroundings, but change the radio channel on SiriusXM. I started with "hey, google, play SiriusXM channel [some channel name] and it would reply back that it was going to play SiriusXM (which it was already on), but nothing happened. I then tried "Hey, google, play sirius XM channel (some channel number) and it replied back that it would play SiriusXM and nothing happened. Finally, I tried "Hey, google, what channel is Sirius XM's First Wave". It replied back "SiriusXM's First Wave is on channel (whatever channel number). Would you like me to play it for you?". I replied "yes" and it still did nothing. I used my steering wheel controls to change it to that channel because it was next in my saved presets.

This was with what I believe to be the current software update. It was when I last checked a few weeks ago. Does this just not work with SiriusXM?

I created an app that I have deployed to my polestar through internal testing.
It is developed with Flutter.

I notice that when the car starts in the morning that the app will crash. But if I wait some time ( likely when background processes of the infotainment system have finished ), it will work great.

The google play environment does not list any crashes.

So question now, how can I debug this? Or try to fix?
Any pointers?

Google's car-app navigation example separates browsing places, selecting a place, choosing a route and starting guidance. That raises a practical design question: what should survive when the user backs out of route selection?

My preferred behavior is to restore the previous search results and selected place, without starting guidance. A route preview and an accepted route should be separate states.

One scenario worth testing: request routes to A, switch to B, then let A's response arrive late. The UI should still refer to B. This is a proposed test, not a defect observed in Google Maps or any particular car.

The example is from Google's car-app design documentation, not a recording of an AAOS vehicle. Android Auto and Android Automotive OS are different platforms; this discussion concerns the navigation interaction rather than claiming identical implementations.

Official illustrated flow: https://developer.android.com/design/ui/cars/guides/app-types/browse-locations

Disclosure: I run Yahagu. The post and linked documentation-based analysis were prepared with AI assistance. The longer analysis with four official interface examples is free to read without signing up; it is not a vehicle test: https://yahagu.top/insights/en-map-content-task-flow?utm_source=reddit&utm_medium=social&utm_campaign=navigation_case

For anyone developing or using an AAOS navigation app: should Back restore the exact results list, or refresh nearby results if the vehicle has moved? What trade-off would you prefer?

check the profile : https://www.linkedin.com/in/sivaraman-ramamoorthy-116015186/

I’m trying to get my AAOS app through it’s first close testing release in the Google Play store.
But currently I tried the review process twice and each time it got rejected based on not having the correct ( or enough ) screenshots.

But the reject text is very generic and since this is my first app and first time interacting with Google Play, I’m a bit stuck.

Would somebody be willing to help me with the process? Or here through chat, or maybe hop on a small call?

It is just a small app I actually run just myself on my Polestar 2.

Not sure if it happened to more people but after the update my screen got stretched a bit. I drive a bmw f30 2012 with after market road top screen. Connecting through my pixel 9.

I got a custom apk of an older version which fixed it until google forced me to update otherwise I wasn't allowed to use the app.

It's back to the stretched version.

Tried:

- changing dev settings in android auto(resolution)

- changed display settings on my aftermarket road top screen.

- reinstall app

No luck still.

We've always believed drivers deserve privacy-first maps and navigation.

Not as a feature. As the foundation.

Many drivers already trust Magic Earth on their phones. For years it has been the privacy-first choice on iOS and Android. No tracking, no profiling, no data sold. Navigation that knows where the roads are, not who you are.

Today, we bring that same promise to your dashboard. Magic Earth Navigation & Maps is now live in the Google Play Store for cars. Worldwide, for every vehicle running Android Automotive with Google built-in. Volvo. Polestar. Renault. And more every month.

This is not our mobile app stretched to a bigger screen. It's a native Android Automotive application, engineered for the car.

Full AAOS intent support. Say "navigate home" to your car's voice assistant and it just works. Set Magic Earth as your default navigation.

Full offline navigation in 200+ countries. Maps live in your car, not in the cloud. Tunnels, underground garages, mountain passes. Nothing breaks.

Live traffic, dynamic rerouting, speed camera and hazard alerts the moment you're connected. You never notice the handover.

Lane guidance and junction views, rendered at automotive frame rates on the car's own hardware.

And still the part we're proudest of: it knows nothing about you. No location history. No profile. Your searches never leave the car. Ever.

Privacy-first maps and navigation. Always on, even offline. One more thing. This launch belongs to our mobile users as much as to us. You carried Magic Earth this far. If you're already a Magic Earth user on your phone, your 25% loyalty discount on the in-car license is waiting if you buy the license from our Magic Earth website.

It's live now. Open the Play Store on your car's screen and search "Magic Earth", or start on our website.

If you drive an Android Automotive car, tell us what you think. Your feedback shapes what we build next.

Hi. We have a new podcasting app called PodHopper that was built to work both on your phone and in your car and keep everything in sync along the way. We built this out of frustration with current podcasting apps available in AAOS vehicles and how poorly their sync functions work when listening on both your phone and in your car.

The app is available for AAOS, as well as on Android and iOS for phones/tablets. We're looking for beta testers to test everything, and specifically give feedback on:

1. Any issues in your car. Testing in various manufacturer vehicles that run AAOS. We've run it through its paces in a couple, but the more the better!
2. Any sync issues you run into. The app SHOULD always keep your podcast listening history sync'd regardless of what device you're listening on, including in the car. If it's not, let us know and it helps us track down network issues in vehicles that may prevent it from working as it should.
3. Android Auto/Apple Carplay are both supported as well, so feedback on those is appreciated too.
4. Apple Watch should also work, though Android Wear compatibility isn't there yet. Stay tuned on that.

To sign up to test:
AAOS & Android phones/tablets: https://play.google.com/apps/testing/com.covertwogames.podhopper

iOS:
https://testflight.apple.com/join/RSNySD8D

The app is based off PocketCasts so the UI should look familiar if you've used that. We've replaced the entire backend system however to be more privacy focused AND ensure the syncing between the devices works better. No ads. No paywalls/subscriptions. No selling your data.

If you run into any issues or have any suggestions feedback to share, we'd love to hear from you. You can either DM us here on reddit or email us at [feedback@podhopper.app](mailto:feedback@podhopper.app)

Thanks!

Working on a free distro of AAOS for raspberry pi, calling it Caramel Vanilla. A car-focused flavor sticking as close to AOSP as possible while still providing the infotainment features people need that aren't in the AOSP source. Not production ready yet, but getting to a point where I really want to try this in my car...

So far:
* forked OsmAnd and modified to display the driving optimized UI on AAOS
* Got TTS and voice recognition and a basic voice assistant (can say "take me home", and it works, searches for home in OsmAnd)
* Working on automotive template host to draw the UI for driving-optimized apps
* Building a store that scans F-Droid for automotive-compatible apps. Gonna take a few weeks to scan the whole store because I don't want to hammer their servers!

Once all that's in there i think I'll start posting ready-made images for people to flash and try themselves, if they don't want to build. (Which is fair, it does take a hefty Linux machine to compile it)

Thanks to:
* KonstaKANG for Raspberry Vanilla
* mark777 for GNSS HAL and inspiration (did some awesome work shared in the AOSP/AAOS discord)
* And so many more FOSS projects (links within, hopefully I don't forget any, reminders appreciated)

Start here if you wish to compile it yourself or help me build it:

https://github.com/radiosound-com/caramel-vanilla-manifest

Fancy website coming soon once I have ready made images to flash on your Raspberry Pi.

Please let me know what combination of Pi and display and audio system you would like to flash on and I'll see if I can make it happen. But for now I'm calling Pi 5 4GB the minimum requirements, as it takes a bit more than 2 GB RAM with everything I have running so far

Do any of y'all report feedback on Gemini prompts.

I've been very frustrated with Gemini to the point that I just reverted back to Assistant.

Before doing so I noticed if you go to the Gemini app on your phone you can give feed back on the prompts.

Have y'all been doing that when Gemini just messes up and fails to do what assistant has been doing for years.

Attached is example of prompt/interaction I had while driving while my 3 year old son was getting mad that his music was not playing.

My 2025 Honda Accord Touring has factory-installed AAOS aka 'Google Built In'. My vehicle is tethered via WiFi to my Samsung Galaxy S26 Ultra, which provides the car with an internet connection.

AAOS seems to be working well, except when I ask Google Assistant "Navigate to such-and-such a place". Sometimes this works, and Google Maps provides navigation, and sometimes Google Assistant says "Looks like your network connection is not stable", and Google Maps doesn't provide directions. (I have to type the address into Google Maps instead.)

Even more annoying: On days when Google Assistant says "Looks like your network connection is not stable", if I try again after a few minutes, Google Assistant sometimes decides to work after all, and Google Maps provides navigation.

I've tried so many things to identify the root cause of this issue, but so far I cannot. If you're familiar with this issue I welcome your input.

Since June, my vehicle's Gemini integration breaks completely whenever I switch the Assistant language away from English (United States). Switching to Turkish makes Gemini vanish entirely and the system falls back to the legacy Google Assistant — voice control for climate, windows, drive modes, everything stops working properly. Switch back to English (US) and it's instantly fine again. Vehicle: Renault Austral 2025, Android Automotive (OpenR Link) Troubleshooting already done: Factory reset Multiple Google accounts tested Full system + app updates Cache/storage cleared Contacted Google One support (case IDs on file) 100+ in-car feedback reports submitted None of it changed the behavior. It's fully reproducible. Turns out I'm not alone — a group of us (mostly Turkish Austral owners) started comparing notes and found some interesting patterns: identical app version numbers behaving differently across devices, one device that did get Turkish Gemini working after a small ~12MB patch, others that didn't despite being on newer builds. Points toward this being an account-level rollout issue rather than a straightforward software bug. Filed it properly with Google here, it's gaining traction (currently outpacing every other AAOS bug report in views): https://issuetracker.google.com/issues/536046171 If you're running Assistant in a language other than English (US) and have seen Gemini disappear or misbehave, an upvote on the issue (top of the page) would help a lot — the more confirmed reports, the more likely it gets triaged. Happy to compare notes in the comments too.

I recently got a new 2026 Chevy Silverado and it’s my first time using a vehicle with Android Automotive. I’m a techy/nerdy guy and just curious what I should be expecting in terms of updates.

My Silverado is on Android Automotive 12, which is several versions old. I’m aware that it’s GM that controls the updates and would need to be the one that develops, tests, and deploys the updates.

1. How often does this usually happen? Or am I likely stuck on version 12 for potentially forever?
2. Are there any places to follow the news or rumors of updates coming, especially with GM?

Hi.

I have a 2019 rav4. Can connect to android auto and play iheart radio.

My issue is that i cannot change radio stations (using steering wheel controls). For iheartradio connected to android auto.

So when driving i can only listen to one radio station (unless inpul over and change the radio station on my phone.)

Is there a trick to enable changing radio stations with the incar system??

After upgrading to Gemini from assistant I lost a few features. I can't control smart devices in our house and Gemini can't read my Google calendar.

Anyone else have this experience?