bug(android): exact test APK hits ANR on emulator startup after live chart MVP

[xodapi]

Summary

Exact smoke-testing of the latest successful Android Test APK artifact reproduces an Android ANR immediately after startup on the emulator.

Repro artifact

• Workflow run: https://github.com/xodapi/vimit/actions/runs/28768923794
• Artifact: vimit-android-test-apk
• Zip size: 88,460,221 bytes
• APK size: 356,012,389 bytes
• APK SHA-256: e0d3af7a4d6131d8bce4cf2bb4004d7e5579f6f6d394bfd3e7e33c44f2a64f75

Environment

• Emulator: Medium Phone API 36.1
• Serial: emulator-5554
• Tooling: agent-device 0.18.3, adb 36.0.2

Steps to reproduce

1. Uninstall any existing pro.vibemod.vimit from the emulator.
2. Install vimit.apk from artifact vimit-android-test-apk.
3. Run agent-device open "Vimit" --platform android --json.
4. Run agent-device snapshot -i --platform android --json.

Actual result

• App opens into android.app.NativeActivity, but agent-device snapshot sees only the system ANR dialog with buttons Close app and Wait.
• agent-device appstate --platform android --json still reports package pro.vibemod.vimit / activity android.app.NativeActivity.
• App-specific logcat shows severe main-thread stalls after startup, including:
  • Skipped 1358 frames! The application may be doing too much work on its main thread.
  • Slow operation onPostResume since onResume, duration=3082

Expected result

Dashboard should become interactive without ANR so the smoke checklist can continue.

Notes

• Artifact contents and permissions were otherwise correct: INTERNET, VIBRATE, POST_NOTIFICATIONS.
• This was found while executing smoke-test issue test(android): smoke-test APK after live chart MVP #179.

[xodapi]

🤖 Начинаю выполнение. Агент: Codex

[xodapi]

Промежуточное расследование по Android startup ANR.

Что проверено локально на Medium Phone API 36.1 (emulator-5554):

• baseline debug APK из cargo apk build --features android-gui --target aarch64-linux-android --lib воспроизводит системный Process system isn't responding
• отключён автозапуск refresh без сохранённого key: ANR сохраняется
• убран startup POST_NOTIFICATIONS runtime request: ANR сохраняется
• Android startup без сохранённого key переведён в needs_setup flow: ANR сохраняется
• setup screen упрощён до минимального Android-specific layout: ANR сохраняется
• диагностически убран slint/renderer-software из android-gui, APK пересобран со Skia path: ANR сохраняется

Фактические наблюдения:

• agent-device open "Vimit" consistently succeeds (~14-22s startup)
• adb screencap подтверждает реальный системный ANR dialog, это не артефакт accessibility snapshot
• один из ранних прогонов показывал partially rendered setup/dashboard под ANR dialog; после минимизации setup-screen фон под dialog стал почти пустым, но сам ANR остался
• foreground activity всё время остаётся pro.vibemod.vimit/android.app.NativeActivity

Сильная гипотеза после этих проверок:

• проблема глубже layout-level и, вероятно, сидит в startup/runtime path самого Android NativeActivity/Slint integration либо в debug/test APK execution profile, а не в конкретных карточках dashboard
• имеет смысл следующей итерацией либо:
  1. снять полноценный native/thread trace для ANR, либо
  2. быстро проверить release-signed APK path на том же эмуляторе, чтобы отделить app bug от debug artifact behavior

Текущий smoke-статус: bug всё ещё воспроизводится на emulator debug APK.

[xodapi]

Ещё один важный результат: гипотеза про debug-only APK не подтвердилась.

Проверил документированный release-test path из docs/android.md:

• сгенерирован локальный target/android-signing/release-test.keystore
• release APK собран через env vars CARGO_APK_RELEASE_KEYSTORE / CARGO_APK_RELEASE_KEYSTORE_PASSWORD
• команда прошла через target/guarded-run.exe
• release APK SHA-256: 910a271f40ab68f85dfaa3797649d8d70de97fe6517987edce51e86dd961a9b2

Smoke на release-test APK (emulator-5554):

• install succeeded
• agent-device open "Vimit" --platform android --json succeeded
• adb screencap снова подтвердил системный ANR dialog Process system isn't responding
• app на скриншоте не дошёл до usable first screen

Вывод после release-test:

• это не только debug/test-artifact problem
• release-signed APK на том же эмуляторе тоже воспроизводит startup ANR
• следующая итерация должна идти в сторону startup/runtime investigation (NativeActivity / Slint Android startup path / rendering lifecycle), а не только packaging/signing/layout tweaks

[xodapi]

Ещё одно сильное сужение по #199.

Проверил отдельный минимальный AndroidProbeWindow, который стартует раньше и вообще не создаёт AppWindow до явного продолжения. Это уже не упрощение layout внутри главного окна, а отдельное крошечное окно с текстом и одной touch-area.

Результат:

• startup ANR всё равно воспроизводится
• adb screencap показывает только системный ANR dialog поверх пустого/серого фона
• значит проблема локализована уже не в dashboard/setup UI и не в конструировании AppWindow как таковом

Текущий вывод после всех локальных экспериментов:

• не autorefresh
• не runtime notification permission request
• не тяжёлый setup layout
• не renderer-software only hypothesis
• не debug-only APK
• не AppWindow tree itself

Остаётся Android bootstrap/runtime уровень для текущей связки slint + backend-android-activity-06 + NativeActivity в этом приложении/версии toolchain.

Это уже достаточное основание для следующего шага не в blind UI patches, а в отдельной ветке расследования Android runtime integration: минимальный standalone reproducer, сверка с upstream Slint Android example и/или upgrade path по Slint Android backend.

[xodapi]

Сильнейшая локализация по Android startup ANR.

Проверил no-key startup уже не через AppWindow и не через generated ui/app.slint, а через максимально близкий к документации slint::android inline probe:

• slint::android::init(app)
• tiny slint::slint! component
• single Window + single Text
• без dashboard, без setup flow, без refresh, без model data

Результат на эмуляторе:

• startup всё равно не доходит до usable first screen
• adb screencap больше не показывает даже наш фон/текст
• вместо предыдущего app-level dialog в одном из прогонов уже получен System UI isn't responding

Это очень сильный признак, что проблема лежит уже на уровне Android runtime/emulator/toolchain/Slint Android backend integration, а не в логике или layout vimit.

Практический вывод:

• для следующего шага нужен либо отдельный minimal standalone reproducer вне репозитория,
• либо сверка/запуск официального upstream Android example на этом же AVD и toolchain,
• и только после этого имеет смысл решать: чинить наш bootstrap, обновлять Slint/toolchain или заводить upstream issue.

[xodapi]

Further investigation on 2026-07-06 confirms this is not specific to Vimit app logic.

I built and ran a completely standalone Slint Android repro on the same Windows host/toolchain and the same emulator (Medium_Phone_API_36.1 / emulator-5554). The repro contains only slint::android::init(app) and a trivial Window with Hello Android text.

Results:

• Slint 1.16.1 standalone repro: app renders Hello Android, but screenshot still shows System UI isn't responding; ActivityTaskManager reports Displayed dev.slint.repro/android.app.NativeActivity ... +26s130ms.
• Slint 1.17.0 standalone repro: same outcome; screenshot again shows System UI isn't responding; ActivityTaskManager reports Displayed dev.slint.repro/android.app.NativeActivity ... +24s225ms.
• agent-device snapshot on the 1.17.0 run captured the ANR dialog directly (System UI isn't responding, buttons Close app / Wait).

This means the problem reproduces outside Vimit, outside ui/app.slint, and outside our dashboard/setup code. Upgrading from Slint 1.16.1 to 1.17.0 improves startup time a bit on this emulator but does not remove the ANR.

Conclusion for #199 right now: this looks like an Android emulator / NativeActivity / Slint backend startup issue in the current environment, not a fixable Vimit-only regression from the live chart MVP.

Local evidence saved in the worktree:

• tmp-android-screen-standalone-repro.png
• tmp-android-screen-standalone-repro-117.png

I am not opening a PR yet because I do not have a Vimit-scoped code fix to propose from this evidence.