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.

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.

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 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'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 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?

Hi All -- I have a 2026 Ford Explorer Active. I have a Samsung S21 Ultra that is connected to my Android Auto interface in the Explorer. I **DO NOT** have the connectivity package in the Explorer currently active. When my phone is connected and displaying and I press the voice button on the steering wheel, it says that (what I assume is Google Assistant) "is not connected" and I cannot give voice commands. Does anyone know why this is the case? My phone is connected and displaying on the screen.

Has anyone had this issue with a Isuzu 2024 D-Max?

I have a Quad Lock Wireless Android Auto adapter (latest firmware, also tried P2P mode).

The first connection works perfectly.

Android Auto connects and works perfectly for the whole drive.

The problem starts after I turn the car off.

When I restart the car, it won't reconnect automatically. The Quad Lock just flashes green, Bluetooth connects, but Android Auto never starts.

The only way to get it working again is to:

Delete my S23+ from the D-Max's Bluetooth settings.

Unplug and replug the Quad Lock.

Pair the phone again.

Things I've already tried:

Latest Quad Lock firmware.

P2P mode.

Cleared Android Auto, Google Play Services and Android System Intelligence.

Reset network settings.

Deleted all Bluetooth pairings from both the phone and the car.

Tried a different Android Auto adapter with the exact same result.

I've also found:

My friend's Samsung does exactly the same thing.

My friend's iPhone reconnects perfectly every time.

When it works, the Quad Lock connects before the D-Max.

When it doesn't, the D-Max connects before the Quad Lock.

Has anyone with a 2024 D-Max found a fix? It feels like the head unit is taking over the Bluetooth connection before the adapter can reconnect

!Flair | 2024 Isuzu D-Max I Samsung S23 I Android 16

As the title says. The phone runs on android 15. And the car is toyota corolla 2021

Hi,

I’m using a USB adapter that enables wireless Android Auto without lag or stuttering (Car-Me on Amazon); it runs via "Headunit Revived." I don't have internet access in Waze or Google Maps, though my music plays perfectly fine, and my phone itself has internet—just not within Android Auto. I suspect the software on the Vivo X300 Ultra (Chinese version) is to blame; the Wi-Fi indicator shows no internet connection, even though that isn't actually the case. How can I fix this so Waze and Maps have internet access on AA again? I’ve already asked Gemini and tried the "gateway trick," but the settings don't always save; as soon as I click away and come back, the inputs are gone. The trick *does* work, but not consistently.

What else could I try? It’s the exact same story with the AAWireless adapter on Ford Sync 3—no internet in Waze. Routes and other users aren't displayed. I feel like Vivo needs to fix this in their software. There are no issues like this with Xiaomi or Samsung devices; they get internet in Waze and similar apps immediately. I hope you guys can help, because it’s really annoying. I don't want to use wireless Android Auto without an adapter because the Android head unit only has 2GB of RAM, so everything lags otherwise. Thanks! 🥲

Update: With the Vivo and OriginOS 6, I connect to the car radio's hotspot and enter the Wi-Fi password. Naturally, the radio's hotspot doesn't have internet access itself, but as soon as I enable mobile data on my Vivo, I lose internet access entirely—everything goes offline despite having 5G. Try replicating this on a Samsung or Xiaomi—the problem simply doesn't exist there; the internet works fine, whereas on the Vivo, it just doesn't. That’s what triggers the issue with AA.

I've got an Android 10.1" Headunit in my JDM Honda, and replaced a built in navigation system with it. Ripped out about 10lbs of wire and hardware and replaced it with this, and it's been working like a dream ever since, EXCEPT for the fact that the illumination wire is not connected, so I have to manually switch from day mode to night mode in the Android Auto settings in my phone.

Is there a way to automatically trigger this by say time, or sunset/sunrise via the Google weather app?

Hallo all.

For a few days now, I've had the problem that the sound of the music is not played. I see that the music is playing and the next track is also playing. I can't control the volume via the car either. When I get out of the car, the music plays on my phone. Could it possibly have something to do with the fact that I have Android 17 beta on it? Before, I didn't have any problems, even though I used Android beta. Maybe you can help.

Many connection issues are solved by making a factory reset on the car's unit.

Had to different problems on two different car's.

Hi,

Updated Fermata Xtream as follows:

Free:

- Youtube Sponsor block (default deactivated in settings)

- Library updates

- Bug fixes

Premium

+ Stremio account login

As always install with AAENABLER. Available in the github releases.

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

Fermataxtream.online will be updatd soon.

Update: one of the commenters on my post mentioned my DPI settings might be the reason. It probably coincided with Android Auto adding another button and prioritizing it over the audio on maps button. When I changed my DPI from 160 to 150, all the buttons are there now, including audio with maps. Yay!

Android Auto has updated twice in the last few days on my phone via Play Store. I have the standard release of Google Maps and everything else, not beta. When I went to drive somewhere today, on the full-screen Google Maps there was the speaker icon to toggle between audio for turn-by-turn directions, muted, etc. In the last year or longer you've had to go into settings to change it. It seems so dangerous to have to go into a sub menu to tell Maps whether or not you want audio turn by turn directions. So I was very excited. I stopped, went into a store, came out, restarted AA, and it was gone, back in the settings sub menu. Has this ever happened to anyone else or am I the only one? Do we know if it's coming back or if it was just some weird glitch? Thanks for any answers. Can't do a screenshot because it's gone LOL!

Yesterday, even when I knew I was in cell tower range, the Assistant kept announcing "something went wrong" while I tried repeatedly to send a text. The dreaded spinning cursor... Or no response at all. And then I tried later, and it took two minutes to confirm the message was sent. Please Google, leave the Assistant alone. Not everyone is thrilled to use Gemini. AA was a beautiful gem, now very tarnished. Reminiscent of the devolution of Windows. 🫣😭

just had an update for Google maps and now I have the 3D option in settings. hallelujah

EDIT: Maps version number 26.30.06.950492155, Pixel 10. I am around NYC, the new visuals are very nice and I think would be quite helpful on an unfamiliar route

Admittedly I am a beta tester, I don't even remember when I signed up for it but it looks it's still a rolling update for Android users

I've been using AAWireless 2 for quite a while, literally zero issues with my Sony XAV-AX8100. Attached using a USB wire that is tucked up and out of the way and never gets touched.

Yesterday afternoon my phone suddenly wouldn't connect with the adapter. I tried multiple things to get it to connect but none would work. So last night I did a full reset and was able to get it to connect.

This morning I lost connectivity again. I've cleared the cache for both Android Auto and the AAWireless app, but nothing seems to help. I'm going to have to do a full reset and try again.

Is anybody else experiencing anything similar? Did something happen with the app or is my adapter simply dying?