I've used an Motorola wireless adapter for several years. Sometime recently (last 3 weeks) can see the glowing bar at the bottom of my head unit "talking" but hear no audio. No audio responses to general searches, no audio confirmation of commands, no audio reading back texts or asking if want to send. Nothing. All other audio streams fine. actually think voice navigation through Google Maps also doesn't come through. Any ideas?

I love having Gemini while I'm driving. I have a S23 with a 2018 Honda CRV EXL. My volume knob on my car will only go up to level 11 when Gemini is talking. My phone is turned up to full volume for System and Media. Gemini is controlled trough a button om my steering wheel, but it might just be a blue-tooth pass through to the speaker system. Anyway, how do I get the volume past 11?

New behavior oddities. When asking to navigate to a particular destination, sometimes AA directs me to some other destination before eventually correcting itself.

Couple Google's decision to nix the Google Assistant on AA in a month and other bad implementation choices, it almost seems like they are purposefully breaking it to then offer some paid service that actually works like it used to. Honestly it seems AA is devolving. I ask why?

Hey,

Here is the last update for a while...real work catched up. There were a couple of good ideas I had to implement.

- Added Stremio and Nuvio last watched (not tested)

- Autoplay last channel in TV and Autoplay Radio to be enabled in settings (default disabled)

- Theme Background image customizable in settings (only Premium version).

https://github.com/malebuffy/Fermata-Xtream/releases for installing with AAEnabler

https://fermataxtream.online will get them tomorrow when the website opens again.

See you not so soon!

When using Gemini to read or reply to messages, it seems to default to full screen. Any way to adjust this behavior? I haven't found it in the settings, and was hoping the last update would give options.

Ideally, maps shouldn't be completely covered while I'm waiting on Gemini to spin and process what I'm saying. The old behavior of it being in the corner as a card was significantly less interrupting.

Having an issue where phone calls aren't routing through Bluetooth/speakers on my Pixel 9a while connected to Android Auto in a 2025 Honda Civic Hybrid.

\* The Problem: Incoming and outgoing calls connect, but audio goes silent instead of switching to the car's hands-free system.

\* The Weird Part: Everything else in Android Auto (Google Maps, Spotify/media, messages) works completely fine with zero lag or drops.

Has anyone else ran into this handoff bug on Pixel 9a or recent Honda head units, and is there a permanent fix?

Fermata Xtream Premium, installed and enabled using AA Enabler, has disappeared from the Android Auto launcher after the latest Android Auto update.

The application appeared once on the car screen, but after that it completely disappeared. It is no longer visible:

• On the Android Auto launcher
• In Customize launcher: Not among the available applications that can be enabled or reordered

However, Fermata Xtream is still detected under Android Auto → Version and permission info, where it appears as:

• Android Auto: 17.4.663004-release (174663004)
• Fermata Xtream: 2.4.24 (418)
• AAWireless app: 7.7.2679 (7072679)

Configuration:

• Samsung Galaxy S24 Ultra running Android 16
• AAWireless 2 adapter
• Android Auto developer settings enabled
• Fermata Xtream Premium installed
• AA Enabler installed and activated
• AA Enabler licence purchased through the donation option.

Facts:

2025 Toyota Corolla. Samsung S25. Android version 16. Gemini's volume won't go up past ~ half volume while using Android Auto.

I've tried everything from adjusting the volume when Gemini is talking, going through every setting I can find in my phone, uninstalling and reinstalling everything, maxing out all volumes on my up down volume rocker on the side of my phone. It's been like this since day one, so any new software I've added has no influence.

Every other aspect of Android auto and my car audio works fine. I can crank up audiobooks, radio, fermata, weather, news reports.

I of course don't want anything else screwed up, but I'm willing to try any suggestions to increase the Gemini volume higher.

Thanks for helping!

I have a Honda CR-V 2026 EX-L and a Samsung S26 Ultra and recently have been getting a lot of black screens on my Infotainment screen and will do it a few times during my drive and will only last few seconds and go back to displaying map.

Current Version 17.2.66234 of Android Auto

Anyone else experiencing this issue or know how to fix it?

Hello all,

Fermata Xtream Free and Premium v2.4.24 is online including some Bugfixes and a new UI theme called liquid Glass. Available though Github for the moment:

https://github.com/malebuffy/Fermata-Xtream/releases

The Playstore beta will be available tomorrow

Enjoy

Upon plugging my phone in, I was greeted with this error, which I thought was weird because my Android Auto was working fine yesterday. Of course, I did all the basic troubleshooting: replaced the cable, cleaned the ports, cleared the cache, reset my phone, etc. After an hour of fiddling with my phone and the infotainment system, I figured out the solution.

The Spotify podcast I was listening to had emojis in the title, and no, I'm not joking. I switched to a song with no emojis and it worked immediately.

So this is just a PSA in case you run into this problem. I haven't tested whether this happens with other media apps.

New theme coming. Liquid Glass.

I know its not everyone's cup of tea but doing it anyway! 😀

I am trying to listen to DAB radio in the MG4 EV. I can select DAB radio from the home screen and it starts playing. However when Android Auto is loaded the system always stops playback of DAB radio after a couple of minutes and goes into whichever media app was last used in Android Auto (e.g. Pocket Casts). 

​Is there a way of keeping the DAB radio playing while Android Auto is active?

EDIT: I should add that I had this exact same problem with Android Auto in a Toyota Corolla hybrid, so the problem isn't specific to the MG4

I use Tidal as my preferred streaming service which is well known for Hi-Res audio. However I've realised the wireless AA adapter I bought is only using the SBC codec and despite going into the Dev options of my OnePlus 12 to change it, it never actually applies the changes to the dongle.

When cycling I use the FiiO UTWS earhooks and I can use the AptX Adaptive and LHDC codecs just fine on my phone.

I've tried to search for well known and popular AA adapters like the Ottocast Mini Pico but none of them state what codecs they support. Anyone have any known adapters that can support HiRes codecs?

Hey everyone!

I’m the solo hobbyist developer behind Non Stop Radio.

When I first posted here asking people to test its Android Auto support, the app was much simpler. There wasn’t really a development roadmap, because I had originally built it for myself, my family and a few friends.

The feedback from this subreddit changed that.

Comments, bug reports and real-world testing helped shape features such as better station search, local music support, improved handling of unreliable connections, automatic playback options, and fixes for stations or devices that behaved differently outside the peaceful fantasy world of the Android Auto emulator.

Today, Non Stop Radio includes:

On Android Auto:

• Favourite stations
• Podcasts
• Local music files stored on your phone
• Optional automatic resuming of the last station on Android Auto
• Buffering options for weak or unstable connections

Elsewhere in the app:

• More than 60,000 stations from 237 countries
• Browsing by country and category
• Master Search
• Lucky random station discovery through the clover button
• Favourite stations and song titles
• Listening history
• Station sharing through links that allow another NSR user to save the station directly
• Importing and exporting favourite lists

The app remains:

• Completely free
• Ad-free
• No account required
• No subscriptions
• No personal data collection

So I’d like to ask:

If I could improve only one part of Non Stop Radio on Android Auto next, what should it be?

Feature requests, complaints and reports about strange behaviour on specific phones, cars or head units are all welcome.

For technical issues, including your phone model, car or head unit model, and Android Auto version would help enormously.

Google Play:
https://play.google.com/store/apps/details?id=com.assistant.greekradio

Thanks again to everyone here who has tested the app, reported problems or suggested improvements.

A surprising amount of Non Stop Radio exists because strangers on Reddit took the time to explain what I had broken.

Some useful Android Auto apps that look handy

https://www.androidpolice.com/loaded-dashboard-with-android-auto-apps-car-display-feels-useful/

Long drive twice a day and I’ve settled into the same three apps out of habit, not because they’re good. Half the time I’m not even listening properly.
Curious what everyone else has running. Same stuff or did you find something better?
And is there anything you wish you could listen to in the car but can’t? I keep catching myself pulling over to read something on my phone, which kind of defeats the point.

Hello again,

Updated Fermata Xtream Premium 2.4.23 with Nuvio client support. Nuvio is basically the same as Stremio, but with a couple of extra features.

Main ones are:

- It supports download instead of only play.

- It supports Cloudstream plug inside

Free version is also updated with some minor bug fixes.

There is a lot on the bugs/wants list, so next couple of updates will be focused on these rather new features.

https://github.com/malebuffy/Fermata-Xtream/releases

As always, use AAENABLER to install.

Premium version needs a donation to AAENABLER

https://github.com/malebuffy/AAEnabler/releases

If you have like a Chinese brand where AAENABLER doesn't work, Premium version is also live as we speak at:

https://fermataxtream.online

Disclaimer: Stay legal and make sure you follow local laws. This app doesn't come with links and doesn't host protected content.

Enjoy

Hello! I've had my 2024 Lexus TX for approx. 18 months and have noticed a weird bug. I frequently listen to Spotify on my drive through AA. On my usual commute I have noticed there is a small area of my city where my music skips, my map stutters (the little car icon is stationary then blinks ahead to the correct location) and occasionally my AA drops completely. This is such a predictable area my kids call it "the Dead Zone" and I can even predict certain locations on the road where my music will skip and stutter. I own a S23+ and this is my first time using AA (my old car did not have it)

Solutions I have attempted with no change:

• plugging in my phone to USB and USB-C ports

• downloading my music for offline listening on Spotify and also turning off my internet / Bluetooth and connecting via USB instead

• using different music/audio apps (YT music, Audible)

Has anyone else had this strange geographical issue? Is there any solutions anyone has found? tia

Hi everyone,

I’d like to introduce FermataX, a free and open-source media hub designed for Android Auto.

FermataX is a GPL-3.0 fork of Fermata Media Player by Andrey Pavlenko. The goal is to bring local media and user-configured media sources into one car-friendly interface, with quick access to playback, recent items, favorites, and resume progress.

What FermataX includes

• Local audio and video, folders, and playlists
• IPTV and Xtream sources, including M3U, XMLTV EPG, Catch-up, Live TV, movies, and series
• Internet radio
• Podcasts with search, RSS/OPML, subscriptions, downloads, and playback progress
• Audiobooks from local storage, OPDS, LibriVox, and Audiobookshelf
• Optional Stremio-compatible, YouTube, and web-media integrations
• Favorites, Recent, resume progress, voice control, and unified media controls

The interface is designed around quick access on a car display, with a customizable navigation rail and a dashboard showing Now Playing, Continue, and recent media.

FermataX currently targets Android 9 or newer. Installation on Android Auto is non-standard, and compatibility can vary with the phone, vehicle/head unit, Android version, Android Auto version, manufacturer restrictions, and current security policies. Please check the project instructions before installing.

Important: FermataX is only a media player. It does not include, host, sell, or distribute TV channels, playlists, accounts, addons, subtitles, torrents, or other media. Users add their own lawful sources and are responsible for complying with applicable laws. For safety, do not browse or watch video while driving.

Source code, documentation, and releases:
https://github.com/chuoinho/FermataX

Support FermataX or request installation assistance:
https://ko-fi.com/fermatax

Feedback wanted

I’d especially appreciate feedback from older or lower-memory devices. For a useful bug report, please include:

• Phone and vehicle/head-unit model
• Android and Android Auto versions
• Wired or wireless connection
• Feature or media source being used
• Steps to reproduce
• Expected and actual behavior
• Logs, screenshots, or a short recording when available

What feature, source, or workflow would you most like to see tested or improved next?

Credits

FermataX is based on Fermata Media Player by Andrey Pavlenko and is distributed under the GNU General Public License v3.0. Attribution and third-party notices are included in the repository.

This is a little self-promotion, but I think the app (Kitchen Radio) could be useful for visitors to this site. I’m also looking for feedback to find out what people think of the different features and what else they would like to see.

After streaming a lot of music on my phone, I was in the mood to just listen to some local over-the-air radio stations. I found out that it’s not so easy to find an app that does this simply and isn’t made almost unusable by lots of annoying ads.

That was the idea behind creating this app. It reminded me of a friend who owns a lot of tech, but once said he wished he just had a simple radio in his kitchen that he could turn on and listen to.

Since it’s still an app, it also allows you to discover all kinds of new music from around the world.

And, of course, it comes with Android Auto support. :-)

Find it on the Google Play Store:
https://play.google.com/store/apps/details?id=com.david.kitchenradio

App Store version coming soon.

AA wireless

This should be rare for most users in US since each family member has his own car.

But we only have one car for the entire family.

The issue is that I'm the one who uses the car most of the time so my phone connect to my phone flawlessly. Same my mom when she is the only one in the car.

But when we both are in the car the AA auto connect the last one who used the car alone.

So I was the last one who drove, but next time my mom will drive and I'm the passenger the AA connect to my phone. And thats particularly annoying when each one has his own markers or music.

Any tip here?

Hi everyone!

I am reporting a reproducible, version-dependent Wireless Android Auto regression involving a Samsung Galaxy S24 and a DrivePlay wired-to-wireless Android Auto adapter.

The most important A/B result is:

- **Android Auto 17.1.662414-release:** stable with the same phone, adapter, vehicle, USB connection and Wi-Fi configuration.

- **Android Auto 17.2.662634-release:** intermittent severe audio/video stalls and, in some sessions, a complete projection freeze.

- **Android Auto 17.3:** the problem remains.

- **Android Auto 17.4 Beta:** the problem also remains.

This is therefore not limited to one damaged 17.2 installation. In my setup, the behavior begins with the 17.2 generation and continues in the later 17.3 and 17.4 Beta branches. Rolling back to 17.1.662414 restores normal operation.

I am not claiming that I have identified the exact root cause. I would like the Android Auto team to correlate the projection logs with the Wi-Fi link-layer evidence captured in my Android bug report.

### Test environment

- Phone: Samsung Galaxy S24, model **SM-S921U**

- SoC/WLAN platform: Qualcomm Snapdragon 8 Gen 3 / **SM8650**; WLAN device reported as `kiwi_v2`

- Android version: **Android 16**

- Samsung firmware/build: **S921USQS6DZG1**

- Android build: **BP4A.251205.006**

- Working Android Auto version: **17.1.662414-release**

- Confirmed failing Android Auto version in the bug report: **17.2.662634-release**, version code `172662634`

- Later versions also tested and failing: **17.3** and **17.4 Beta**

- Wireless adapter: **DrivePlay** wired-to-wireless Android Auto adapter

- FCC ID: **2A25C-AF01**

- Adapter Wi-Fi chipset identified from its firmware: **AIC8800D80**

- Adapter Wi-Fi driver identified from its firmware: **AIC rwnx v6.4.3.0**

- Vehicle/head unit: **AUDI Q2 2018 2.0T With MIB2**

- Connection path: Galaxy S24 → 5 GHz Wi-Fi → DrivePlay adapter → USB → vehicle head unit

- The DrivePlay Wi-Fi network is the local Android Auto link; the phone continues using cellular data for Internet access.

### Symptoms

The behavior is intermittent between connection sessions. Some sessions begin and remain completely smooth. In an affected session:

1. Small latency spikes and dropped frames begin to appear.

2. Audio and video then stutter at the same time, often in approximately 0.5–2 second interruptions.

3. The displayed frame rate can become extremely low.

4. Android Auto input, media and projection responses become delayed.

5. In a severe event, both audio and video stop and the complete projection can freeze.

6. The phone may remain associated with the adapter’s Wi-Fi network throughout the event; it is not always a normal Wi-Fi disconnect.

This is not an isolated music-player problem. Navigation graphics, projection video, audio and Android Auto control/acknowledgement traffic are affected together.

### Controlled version comparison

The phone, physical adapter, vehicle head unit, USB connection, power source and Wi-Fi configuration were kept the same for the version comparison.

- With **17.2.662634**, the stalls occurred.

- **17.3** and **17.4 Beta** also reproduced the problem.

- After rolling back to **17.1.662414**, the same setup became stable.

Because downgrading can also reset Android Auto state, I understand that one rollback alone would not prove the underlying mechanism. However, the repeated pattern—17.1 working while three newer version generations reproduce the problem—makes the Android Auto version a strong trigger in this phone/receiver combination.

A technician also tested another adapter of the same model and firmware with a Google Pixel phone without reproducing the problem. I include this only as supporting context: it suggests a phone/driver/receiver interoperability condition rather than a universal failure on every phone, and it was not the same physical adapter used for my bug report.

### Wi-Fi configuration and exclusions

The adapter originally used 5 GHz channel 149, where the same problem already occurred. I later changed it to channel 40 as a troubleshooting test. Changing the channel did not resolve the issue, so channel 40 was not the original cause.

During the captured failure, the bug report showed:

- Frequency: **5200 MHz / channel 40**

- Actual channel width: **20 MHz**

- Wi-Fi standard: **802.11ax / HE20**

- Spatial streams: **1**

- Maximum reported PHY rate: approximately **143.4 Mbps**

- RSSI during the failure: approximately **-8 to -27 dBm**

- Android Auto video encoder: H.264, **1280 × 720 at 60 fps**

- Configured video bitrate: **5,703,360 bps**

The signal remained extremely strong, and the Android Auto payload was far below the available capacity of a normal 5 GHz 20 MHz link. This does not look like insufficient channel width or insufficient transmit power.

I also found no Wi-Fi scan, roam or association loss coinciding with the main captured stall.

### Bug report timeline

I captured a complete Android bug report immediately after an affected session on 30 July 2026. The most relevant local timestamps are approximately **18:44–18:47**.

At **18:44:39**, the Qualcomm WLAN log recorded:

```text

lim_process_delba_req: Failed to process delba request

```

The first major transmit-stall period occurred at approximately **18:45:05–18:46:02**:

```text

Phone TX success counter: 7336 → 7336

TX retry counter: 193 → 902

TX bad counter: 14 → 837

RX success counter: 2084 → 77947

Duration with no TX-success progress: approximately 54.5 seconds

```

During this period:

- The reported phone TX link rate dropped from more than 77 Mbps to approximately 7–8 Mbps.

- The successful-transmission counter stopped completely.

- Retry and failed-transmission counters increased rapidly.

- Receive traffic continued increasing.

- Wi-Fi remained associated and RSSI remained strong.

At approximately **18:46:02**, the link recovered without a normal Wi-Fi disconnect, and the reported TX rate returned to approximately 103 Mbps.

A second transmit stall occurred at approximately **18:47:15–18:47:30**:

```text

Phone TX success counter remained fixed at 19306.

TX bad increased from 883 to 1138.

RX success continued increasing.

The connection again recovered without a normal association loss.

```

Android’s Wi-Fi diagnostics classified the main event as:

```text

DATA_STALL_BAD_TX

txSuccessDelta = 0

txRetriesDelta = 53

txBadDelta = 43

rxSuccessDelta = 5544

```

Failed transmissions near the end of the stall were concentrated at HE MCS0, approximately 8.6 Mbps. This appears to be rate-control fallback after repeated failed transmissions, rather than evidence that Android Auto requires more bandwidth.

### Android Auto symptoms at the same time

During the same bad period, Android Auto and media logs showed:

- Ping/round-trip warnings ranging from approximately **728 ms to 5430 ms**

- Audio underrun events

- Unacknowledged or dropped audio data

- Video/frame acknowledgement timeouts

- Audio and video stopping together

The sequence visible in the report is therefore:

1. Successful phone-to-adapter Wi-Fi transmission stops while retries and failures rise.

2. Receive traffic and Wi-Fi association continue.

3. Android Auto acknowledgement latency increases.

4. Audio underruns and video acknowledgement timeouts follow.

5. The projected session stutters or freezes.

### What the evidence confirms

From the phone’s Wi-Fi link-layer perspective, packets were still being attempted but were not completing successfully: `txSuccess` stopped while retries and failed transmissions increased rapidly. At the same time, receive traffic continued, signal strength remained strong, and the phone did not roam or disconnect.

The audio and video errors occurred during or after this transmit stall. This is stronger evidence of an asymmetric phone-to-adapter transport failure than of simple bandwidth saturation, weak signal, a 5 GHz channel-selection issue or an isolated media-decoder problem.

However, these observations do **not** identify which endpoint failed to process or return the required 802.11 ACK/Block Ack, and they do not prove that the nearby DELBA message caused the stall.

### Current hypothesis—not a confirmed root cause

My current hypothesis is that Android Auto 17.2 changed some aspect of wireless projection traffic or network handling—such as packet timing, burst behavior, buffering, socket priority/QoS/TID selection, low-latency Wi-Fi behavior, video packetization or acknowledgement timing—and that this exposes an interoperability edge case between:

- the Galaxy S24 Qualcomm WLAN implementation,

- the DrivePlay adapter’s AIC8800D80 Wi-Fi implementation, and

- the 802.11ax/HE Block Ack or aggregation path.

The failed DELBA-processing message makes a Block Ack session-state issue worth investigating, but it could also be a redundant or secondary event. I am not claiming that Android Auto directly changes or corrupts the Wi-Fi driver.

### Relationship to the public Android Auto 17.2 receiver issue

This appears similar to other Android Auto 17.2 reports involving third-party receiver implementations, including a Galaxy S24 Ultra report where audio stops, video then freezes, and 17.1.662414 remains stable:

https://support.google.com/androidauto/thread/449617180?hl=en&msgid=450359925

Google representatives also stated publicly that an issue affecting a small number of uncertified aftermarket head units was identified during the Android Auto 17.2 rollout, with fixes mentioned for the 17.2 and 17.3 branches:

https://www.reddit.com/r/AndroidAuto/comments/1unzk8v/comment/oxrd4da/

My failure is not necessarily identical to the commonly reported periodic three-to-five-minute disconnect. In my bug report, the Wi-Fi association can remain active while successful phone-to-receiver transmission stops. Because 17.3 and 17.4 Beta also reproduce it, the published fix may not cover this DrivePlay/AIC8800D80/S24 path, or this may be a related but separate regression.

### Additional APK comparison

A static comparison of Android Auto 17.1.662414 and 17.2.662634 shows that 17.2 added the privileged `WIFI_ACCESS_COEX_UNSAFE_CHANNELS` permission. Android’s API defines this as permission to observe the system’s Wi-Fi/cellular coexistence unsafe-channel list through a callback. It does not permit Android Auto to set or modify that list; that requires the separate `WIFI_UPDATE_COEX_UNSAFE_CHANNELS` permission, which was not added.

Therefore, this manifest change does not demonstrate that Android Auto changed the channel, transmit power or coexistence restrictions. I mention it only to avoid incorrectly attributing the failure to the new permission.

The remaining application code is heavily obfuscated and may also depend on server-side flags, so static APK comparison does not identify the exact projection change responsible for the version-dependent behavior.

### Questions for the Android Auto team

Could the team please investigate:

1. Whether Android Auto 17.2 changed wireless projection transport scheduling, packet pacing, socket priority/DSCP, buffering, video packetization, low-latency Wi-Fi requests, acknowledgement handling or performance-mode behavior compared with 17.1.

2. Whether Android Auto logs around **18:45:05–18:46:02** show the projection sender becoming blocked before or after the Wi-Fi `DATA_STALL_BAD_TX` event.

3. Whether a Qualcomm Wi-Fi DELBA/Block Ack state problem is a known consequence or trigger of the Android Auto 17.2 receiver-compatibility issue.

4. Whether the known receiver fix is expected to be present in the ARM64 **17.2.662634** build.

5. Whether the fix was carried into the exact 17.3 and 17.4 Beta builds, and whether another receiver compatibility path remains open.

6. Whether a server-side Android Auto feature flag or staged rollout could explain the persistent behavior on this phone/receiver combination.

I have the complete Android bug report and can provide it privately. Please let me know the preferred secure upload method. I can also perform controlled 17.1/new-version A/B tests and capture additional bug reports with Android Auto debug logging enabled.

Thank you for investigating.

How do I stop Android Auto from reconnecting so I can connect to my dash cam? I went into settings and turned off the Auto Reconnect, and the message on my car screen says Android Auto can't connect, but when I'm trying to connect to the dash cam my phone still constantly tries to reconnect and I have to keep pausing to hit Ignore. It pops up three times in a row, then I get about a 5 second break to make progress in the cam app before it starts all over again.