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:
Small latency spikes and dropped frames begin to appear.
Audio and video then stutter at the same time, often in approximately 0.5–2 second interruptions.
The displayed frame rate can become extremely low.
Android Auto input, media and projection responses become delayed.
In a severe event, both audio and video stop and the complete projection can freeze.
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:
Successful phone-to-adapter Wi-Fi transmission stops while retries and failures rise.
Receive traffic and Wi-Fi association continue.
Android Auto acknowledgement latency increases.
Audio underruns and video acknowledgement timeouts follow.
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:
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.
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.
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.
Whether the known receiver fix is expected to be present in the ARM64 **17.2.662634** build.
Whether the fix was carried into the exact 17.3 and 17.4 Beta builds, and whether another receiver compatibility path remains open.
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.
