cottongin/Android-247-Radio
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
master
Android-247-Radio/chat-summaries/2026-03-18_10-00-android-auto-testing.md
cottongin 5105794120 docs: add Android Auto testing summary and ignore apkm files 
Documents all DHU testing attempts, root causes for failures (DHU v2.0
protocol incompatibility with AA v16+), and lessons learned. Adds
*.apkm to .gitignore to avoid accidentally committing large APK bundles.

Made-with: Cursor
2026-03-18 10:19:59 -04:00

4.7 KiB
Raw Permalink Blame History

Android Auto Testing Attempts & Lessons Learned

Date: 2026-03-18
Context: Follow-up to the Media3 / Android Auto migration session. All implementation was already complete and verified via dumpsys media_session. This session focused entirely on visually verifying the Android Auto browse tree using the Desktop Head Unit (DHU).

What Was Already Confirmed Working

Before any testing attempts, adb shell dumpsys media_session confirmed:

  • RadioPlaybackService registered under both androidx.media3.session.MediaLibraryService and android.media.browse.MediaBrowserService intent filters
  • Media session active (state=3 / playing)
  • ICY metadata visible to the OS (e.g. "Deep Shit Pt.3, Black Soyls")
  • Custom "Live" action (Seek to Live) present in the session
  • Media button receiver correctly configured

Testing Attempts

1. Android Auto APK on API 28 Emulator (emulator-5554)

  • Installed Android Auto v15.6 (x86_64 split) — failed: emulator is arm64-v8a, ABI mismatch
  • Installed Android Auto v16.3 (arm64-v8a split) — succeeded
  • Enabled developer mode by tapping Version 10× in AA settings
  • Wrote gearhead_config.xml directly via adb root to persist developer mode
  • Start head unit server appeared in overflow menu and was activated
  • Port 5277 confirmed listening via /proc/net/tcp6
  • DHU launched, connected ([I]: connected), then immediately disconnected
  • Root cause: DHU v2.0 (released 2022) uses protocol version 1.7; Android Auto v16.3 (2025) requires a newer protocol version. Google has not released a DHU update since 2022.

2. Android Auto APK on API 36 Play Store Emulator (emulator-5556)

  • Android Auto v16.3 installed successfully (arm64-v8a)
  • Could not enable developer mode via adb root — production build, root denied
  • Enabled developer mode via UI (tapped Version 10×, confirmed dialog)
  • Start head unit server appeared in overflow, tapped it
  • Port 5277 never opened — AA silently refused to start HUS
  • Root cause: Android Auto v16.3 requires a signed-in Google account to start the head unit server. The Play Store emulator could not complete Google sign-in due to captcha blocking on emulators.

3. Physical Lenovo Tablet (HA26DKYS, Android 15)

  • Android Auto v16.3 installed via adb install-multiple — succeeded
  • Radio app installed via adb install
  • Developer mode already enabled, "Unknown sources" already checked
  • Head unit server started manually — port 5277 confirmed listening
  • adb forward tcp:5277 tcp:5277 established
  • DHU launched, connected, then immediately disconnected
  • Root cause: Same protocol version mismatch as attempt 1. DHU v2.0 is incompatible with Android Auto v16.3 regardless of device.

4. Head Unit Reloaded (SELF MODE) on Tablet

  • App gb.xxy.hr (Head Unit Reloaded) already installed on tablet
  • SELF MODE is intended to run Android Auto's car UI locally on the same device
  • App crashed on SELF MODE tap — likely incompatibility with Android 15 or the sideloaded AA version
  • No further investigation pursued

Lessons Learned

  1. DHU v2.0 is effectively end-of-life for modern Android Auto. Google stopped updating the DHU via SDK Manager after the 2022 release. Android Auto v16.x uses a newer protocol that DHU v2.0 cannot negotiate. The only confirmed-working approach from a March 7, 2026 blog post uses the same DHU method — meaning even the community has no working solution for newer AA versions.

  2. Android Auto requires a signed-in Google account to start the head unit server on modern versions. This makes purely emulator-based testing (without Google Play sign-in) impossible for v16+.

  3. Android Automotive OS emulator is a different product. AAOS emulator (available via SDK Manager) tests built-in car OS apps, not phone-projection Android Auto apps. It does not help test MediaBrowserService integrations.

  4. dumpsys media_session is reliable validation for MediaBrowserService. The OS-level session dump confirms registration, state, metadata, and custom commands are all correctly exposed — which is exactly what Android Auto reads. Visual DHU testing adds UI confidence but is not required to verify the integration is correct.

  5. APKM bundles are ZIP archives. APKMirror's .apkm files can be extracted with unzip and installed with adb install-multiple, selecting the correct architecture (arm64_v8a), density (xxhdpi), and language (en) splits for the target device.

Current Status

All implementation is complete and functionally verified. Visual Android Auto UI testing requires either:

  • A physical car head unit running Android Auto
  • Google releasing a DHU update compatible with Android Auto v16+
Reference in New Issue View Git Blame Copy Permalink