Description
AutoMobile fails to connect to physical Android devices running Android 16 (API 36) with the following error:
Cannot get active window information from device <id>
Root Cause
Window.ts relies on imeControlTarget as the primary pattern for extracting the active window from:
adb shell dumpsys window windows
On Android 16 physical devices, the imeControlTarget field no longer appears in the output.
Additionally, the fallback patterns:
mActivityRecord
ty=BASE_APPLICATION
do not appear to be parsed successfully either.
As a result, the active window cannot be determined and the connection fails.
Reproduction
# Fails on Android 16 physical devices - returns nothing
adb -s <physical-device-id> shell dumpsys window windows | grep "imeControlTarget"
# Works on Android 14 physical devices and emulators (any API level)
adb -s <emulator-or-android-14-device-id> shell dumpsys window windows | grep "imeControlTarget"
Environment
Failing
- Physical Pixel 6a - Android 16 (API 36)
Working
- Samsung S24 - Android 14
- Emulators - API 35, API 36
Notes
- The failure occurs in the
dumpsys window windows readiness check before the accessibility service is ever used.
- The issue is isolated to the absence of
imeControlTarget in the dumpsys window windows output on Android 16 physical devices.
- Manually installed accessibility service APK (pulled from an emulator) and confirmed that
run-as com.zillow.automobile.accessibilityservice works and returns valid hierarchy data — meaning the service itself is functional on Android 16, the readiness check is the only blocker.
Potential Fix
Use the accessibility service itself for the readiness check, and fall back to dumpsys only if the accessibility service is unavailable.
Description
AutoMobile fails to connect to physical Android devices running Android 16 (API 36) with the following error:
Root Cause
Window.tsrelies onimeControlTargetas the primary pattern for extracting the active window from:On Android 16 physical devices, the
imeControlTargetfield no longer appears in the output.Additionally, the fallback patterns:
mActivityRecordty=BASE_APPLICATIONdo not appear to be parsed successfully either.
As a result, the active window cannot be determined and the connection fails.
Reproduction
Environment
Failing
Working
Notes
dumpsys window windowsreadiness check before the accessibility service is ever used.imeControlTargetin thedumpsys window windowsoutput on Android 16 physical devices.run-as com.zillow.automobile.accessibilityserviceworks and returns valid hierarchy data — meaning the service itself is functional on Android 16, the readiness check is the only blocker.Potential Fix
Use the accessibility service itself for the readiness check, and fall back to
dumpsysonly if the accessibility service is unavailable.