Android 16 (API 36) on Pixel 7a: API Unavaliable — bundled frida-tools 14.4.6 java.js incompatible

[Vasiliy-b]

Summary

On 10 freshly-rooted (KernelSU) Pixel 7a devices running Android 16 (google/lynx/lynx:16/CP1A.260305.018, kernel 6.1.145-android14-11), every gRPC call to lamda v9.25 returns ServiceUnavailable: API Unavaliable. The web UI on :65000 works fine (touch, terminal, screen mirror), but the Python Device(ip).server_info(), .device_info(), .execute_script(), .getprop() etc. all fail identically with API Unavaliable.

Same lamda 9.25 client + server combination works perfectly on our older Xiaomi Mi 8 fleet running Android 12.

Root cause (verified via server.log)

/data/local/tmp/server.log shows the bundled Frida agent crashing on every cycle:

libsepol.avtab_read_item: more than one specifier
libsepol.avtab_read: failed on entry 950 of 85710
Unable to load SELinux policy from the kernel: unsupported policy database format
{"type":"error","description":"Error: Unable to find copied methods in java/lang/Thread; please file a bug","stack":"...at <eval> (/internal-agent.js:1837)"}
ERROR [exception] FileNotFoundError: [Errno 2] No such file or directory

This is the well-known frida-java-bridge Android 16 ART layout incompatibility:

• Dynamic Method Offset detection for ART fails in Android 16 frida/frida-java-bridge#376 — Dynamic Method Offset detection for ART fails in Android 16
• [Android 16] Error: Unable to find copied methods in java/lang/Thread (syscall timeout) frida/frida#3658 — Error: Unable to find copied methods in java/lang/Thread
• Upstream fix landed in frida-core commit 1b908e69f3cbb62005fce8b1a4fafa48a2bc22b7 on Jan 7, 2026 (removed system_server agent dependency)

v9.25 (released Mar 22, 2026) ships frida-tools 14.4.6 in /data/server/lib/python3.9/site-packages/frida_tools-14.4.6.dist-info and frida-server 17.5.2-FIRERPA binary. Both predate the upstream fix.

What we tried

1. SELinux Permissive (setenforce 0) before lamda restart — no effect.
2. properties.local with disable-client-api=false, enhanced-stealth-mode=true, frida.enable=true — no effect.
3. Reboots, pkill -9 lamda && launch.sh — no effect.
4. pm uninstall com.google.android.art — fails (apex module, not user-uninstallable).
5. Applying sijan2/frida's patch-frida-tools.py to bridges/java.js on-device → launch.sh returns CRITICAL failed (file broken) due to lamda's integrity check.

The integrity check rejects any modification under /data/server/, so end-users can't work around this themselves.

Environment

• Devices: 10× Pixel 7a (lynx), Android 16 stock, KernelSU root
• Build: google/lynx/lynx:16/CP1A.260305.018/14887507:user/release-keys
• Kernel: 6.1.145-android14-11-gfa1d6308d1fe-ab14691759
• SDK: 36
• Lamda server: v9.25 (autorun APK from lamda-autorun.apk latest)
• Lamda Python client: 9.25 (same on Windows farm host)
• Frida server bundled: 17.5.2-FIRERPA
• frida-tools bundled: 14.4.6
• Old fleet (working): Xiaomi Mi 8 (dipper), Android 12 — same lamda 9.25 client, RPC works flawlessly.

Request

Could the next lamda release please bundle:

• frida-tools ≥ 14.5.1 (which carries the patched frida_tools/bridges/java.js with API 36 offsets), and/or
• frida-server built off the 1b908e69 frida-core commit (which side-steps getArtClassSpec via JVMTI)?

This would unblock the entire Android 16 Pixel cohort, which is becoming the default for fresh device farms after Google's Mar 2026 stable rollout.

Happy to test pre-release builds against my 10-device cohort if helpful.

[rev1si0n]

Fixed in latest 10.x version.