Android: tao 0.35 panics with JavaException in onActivityCreate (post HOME-fix)

[oscarvalenzuelab]

Summary

After PR #7 fixes the early HOME / identities-root crash, the APK
gets further into startup but panics inside Tauri's Android JNI
bridge before the activity's UI ever attaches.

Stack

```
RustStdoutStderr: thread '' (12097) panicked at
/Users/.../tao-0.35.0/src/platform_impl/android/ndk_glue.rs:393:6:
called `Result::unwrap()` on an `Err` value: JavaException
Java_io_dnsmesh_desktop_Rust_onActivityCreate
F libc: Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid (...)
```

The `tao` crate's `unwrap()` on the JNI result swallows the actual
Java exception, so logcat doesn't tell us which Java call failed.
Activity never reaches its first frame.

Reproduction

• macOS host, Android Studio not installed (just SDK/NDK via cmdline-tools)
• AVD: Pixel 6, Android 14 (API 34, `google_apis;arm64-v8a`)
• Android System WebView: present (com.google.android.webview v113)
• Build:

```sh
cargo tauri android build --apk
apksigner sign --ks ~/.android/debug.keystore --ks-pass pass:android \
--key-pass pass:android --ks-key-alias androiddebugkey \
--out signed.apk app-universal-release-unsigned.apk
adb install -r signed.apk
adb shell am start -n io.dnsmesh.desktop/.MainActivity
```

Versions

• tauri 2.11.0
• tao 0.35.0
• wry 0.55.0
• NDK r26d (26.3.11579264)
• AGP / build-tools 34.0.0
• compileSdkVersion 36 (Tauri default), targetSdkVersion 36

Things I'd try next

1. Run with `RUST_BACKTRACE=full` set on the activity environment so
   the panic stack widens past `__rust_end_short_backtrace`.
2. `adb logcat | grep AndroidRuntime` for the Java side of the
   exception — there may be a stack trace from the JVM that isn't in
   the Rust panic output.
3. Try `google_apis_playstore` system image (different WebView
   provider) to isolate whether this is WebView-config related.
4. Pin to an older tao / Tauri to bisect (tao changed its Android
   activity bootstrap a few releases back).
5. Try `cargo tauri android dev` — its JNI debug attach may surface
   a clearer Java stack.

Why this matters

Blocks the Android client from showing its first frame. Until this is
fixed, the APK that ships with each `desktop-v*` release is install-
only — sideloads onto a device and immediately crashes.

Related: the CI APK is currently shipped unsigned (separate
follow-up — the workflow needs a debug-signing step at minimum so
sideloads at least install).

[oscarvalenzuelab]

Root cause

This is the same bug as upstream tauri-apps/tauri#15311 (and the local
manifestation of the missing-keep regression). The chain:

1. wry < 0.55.x ships a proguard-wry.pro template that keeps
   most of WryActivity's methods but is missing int getId();
2. R8 (release minification, default-on for cargo tauri android build --apk) strips the Kotlin auto-generated getId() getter
   for var id: Int = 0 because no Java/Kotlin code calls it
3. tao 0.35.0's JNI bridge calls activity.getId() at
   onActivityCreate to register the new activity in its window
   manager
4. JNI lookup fails with NoSuchMethodError, which surfaces as a
   generic JavaException
5. tao unwrap()s the result at ndk_glue.rs:393:6 → panic →
   Java_io_dnsmesh_desktop_Rust_onActivityCreate aborts → app
   crashes before its first frame

Verified end-to-end on a Pixel 6 / Android 14 emulator: with the
int getId(); keep rule applied, the app launches cleanly into the
chat shell.

Upstream fix

Already merged in wry dev as
tauri-apps/wry#1721
(landed 2026-05-04). Just adds the missing line to the
proguard-wry.pro template. Will roll into the next wry release.

Why the local fix is gnarly

cargo tauri android build --apk regenerates proguard-wry.pro
from wry's bundled template on every run, so an in-place patch
doesn't survive the next build.

Worse: Gradle's R8 task does not declare the proguard file as
a tracked input, so even if the file IS patched between builds,
incremental gradle skips re-running R8 — the APK keeps shipping
the unpatched dex.

Options to make this durable

1. Wait for the next wry release. Probably hours/days. Cleanest
   path. Once wry > 0.55.x with the fix is released and Tauri's
   transitive dep moves up, this disappears with no work on our side.
2. Cargo workspace patch to wry/dev via [patch.crates-io] in
   src-tauri/Cargo.toml. Picks up the proguard fix automatically
   on the next cargo tauri android build. Risk: pulls every other
   change in dev too, which may break compatibility.
3. Commit gen/android/ so we directly own the proguard file
   (and ~9 other generated files). Bigger maintenance surface but
   gives us full control over Android template files.
4. CI / build script wrapper that runs cargo tauri android build, patches the proguard file, wipes R8 outputs, then re-runs
   gradle's :app:assembleUniversalRelease with -x on rust tasks.
   Hacky but no source-of-truth changes.

Recommend (1) by default. Recommend (2) if we need a working APK in
release builds in the next few days and (1) hasn't shipped.

Closing this once wry > 0.55.x lands and the fix flows through.