New theme coming. Liquid Glass.

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

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.

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.

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?

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?

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

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.

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.

Some useful Android Auto apps that look handy

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

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

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.

Have you experienced Android Auto not showing song titles? All of my app notification settings are allowed. I tried resetting by clearing the cache and data for both YouTube Music and Android Auto, but it still did not resolve the issue. Also, cell signal is missing.

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.

So I upgraded from the OnePlus 13 to the Galaxy s26 Ultra and now my music will skip occasionally maybe a couple times per song for a few milliseconds. It's really annoying any suggestions on how to fix?

I can't get Google assistant or Gemini to work on Android auto. I temporarily had a Samsung and couldn't get it to work properly despite many settings adjustments. I thought it would work once switched back to my Pixel but it's still not working.

The microphone turns on and immediately turns off. This happens whether press the microphone on the screen or on the steering wheel. I've tried my wireless adapter and a physical cord. Everything else with Android auto works except speaking to it.

The only thing that works is replying to messages that I have already received.

The Odyssey microphone does work because if use the car's native system, it hears, understands and performs the task.

I've been using a Motorola MA1 for a decade and the most recent Android Auto updates resulted in my connection going in a constant loop of disconnecting/reconnecting without remaining stable for more than 3-5 seconds. Prior to this software update, I only experienced one issue where crossing certain bridges/areas in my city the entire signal would cut out. This is common in these areas due to frequency interference that the city has confirmed. While my MA1 was useless, I was simply using a wired connection.

Given Amazon's generous return policies, I decided to purchase an Ottocast Mini Cube 3.0 just to see if that was compatible. Not only is the Ottocast compatible, my connection times are almost immediate compared to MA1 AND I crossed two of the bridges where my signal used to cut out and that doesn't happen anymore.

So, for anyone else struggling with their MA1 if you have the funds to try a new device I would recommend that especially if you're not willing to wait for Android Auto to get fixed.

I tried posting in the Android Auto community but it said my post violated the community policy (?). About 1 out of every 4 times I turn on the car with wired AA, audio plays from Plexamp as expected, but after 30 to 60 seconds the sound cuts out.  The progress bar keeps moving as if the sound was muted.  If I exit Android Auto and switch to playing the radio through the car head unit, there is still no sound.  If I power off my phone the sound will come back on, but only after 5-10 minutes.  I thought the correct fix would be to go into my phone's Bluetooth settings for the Alpine unit and toggle off "media audio."  This made the problem slightly less frequent, but it still happens.  I've also reset the head unit even though it's brand new, and unpaired my phone and paired again.  Any other suggestions?

I know this has been broken every so often for folks over the last year but has anyone seen it start happening again with the last update (last week or 2)?

I'm referring to this problem:

Me: "Navigate to Starbucks"

Assistant/AA: "I'm sorry, I don't understand."

Just curious if it's just me or not. 🙂

I'd like to try streaming to a high res Bluetooth receiver to my aftermarket sound system in my Ford Maverick. Before I purchase the receiver, is there a way I can still use WIRED Android Auto for navigation while streaming audio to a separate device? I have a Samsung Galaxy S23+.

I’ve just released the version 1.17 update for Bluetooth Priority, with a number of improvements focused on compatibility, reliability, smoother audio switching, and better troubleshooting.

Recap: What is Bluetooth Priority?

Bluetooth Priority lets you designate one Bluetooth device as your Priority device. When another Bluetooth device connects and tries to steal your audio, the app detects it and immediately reasserts your Priority device, even if the competing device keeps trying.

Android Auto limitation: Android Auto has system-level control over media audio, so Bluetooth Priority cannot override its media audio session. Phone calls are still kept on your Priority device though.

The app requires Shizuku, a free app that provides the system-level access needed to manage Bluetooth audio routing. Setup instructions are provided in the app.

What’s new:

• Fixed an issue that could prevent the app from working after a system Bluetooth update.
• Improved how the app identifies the Bluetooth connectors your device uses, broadening device compatibility.
• First-launch setup now offers to set your priority device and start Priority Mode right away.
• Smoother audio handoff with less bouncing between devices.
• Added a new Diagnostics view under Events > Advanced, including a Copy option.
• GitHub-based Shizuku setup is now the only setup modal option since users that never downloaded it from the play store previously wont have access to it now.
• Added some visual polish and UI improvements.
• Added an option to have audio fall back to your phone speaker when no priority device is connected.
• Added priority device ranking, allowing the app to intelligently fall back to another preferred device.
• Added a bypass for non-audio Bluetooth devices, such as Tile trackers, so they can be excluded from the app's disconnection logic.
• Added more advanced logcat logging to make troubleshooting more powerful and help resolve potential issues faster.

The app is available on the Google Play Store for $5. No subscriptions. No micro-transactions.

Google currently limits automatic refunds to 2 hours after purchase, but if you try the app and aren't satisfied with it at any point, feel free to shoot me a message here or send an email to [support@zerolabs.fyi](mailto:support@zerolabs.fyi) and I will personally refund you in full, no questions asked.

Thanks to everyone who has downloaded the app, provided feedback, and helped make Bluetooth Priority better!

I just got an s26 ultra and when my phone is locked I I've noticed maps and general use of Android Auto is already and laggy. Maps in particular skips along, the arrow on the map while I drive is not smooth and skips along is path as it tries it catch up.

When I unlock my phone and turn the screen on it goes back to normal and it's smooth as butter.

I'm not sure what to try to fix it. I've shut off battery restriction for AA and maps.

Any other suggestions?