WebAssembly in Android Apps — Do WASM Dream of JNI?
summary
Compiles the OpenJPEG JP2K decoder to WebAssembly and packages it as jp2k-decoder-android, then runs it inside the Jetpack JavaScript Engine sandbox on Android to contain, not eliminate, native-vulnerability blast radius. Measures practical trade-offs for embedding WASM payloads in APKs: Base64 increases size to ~133%, Base85 shrinks to ~88% but adds CPU cost, and a custom 32,768-char encoding reaches ~106% with very slow decode. Uses Binder IPC with a 1 MB message limit and a file-descriptor/pipe workaround; recommends using Jetpack JSE 1.1.0’s MessagePort API for true byte-array roundtrips.
AI-written summary · about
chapters (15)
- 0:00Introduction
- 1:13JPEG2000 processing challenges
- 5:12WebAssembly basics on Android
- 7:20OpenJPEG with WebAssembly
- 8:05Running WASM on Android steps
- 13:48Isolated execution with JS engine
- 16:55WebAssembly versus JNI
- 18:21Data transfer challenges
- 21:11Encoding method comparison
- 27:39Optimal encoding conclusion
- 28:00JS engine 1.1.0 features
- 30:28Graceful degradation importance
- 33:26Multi-layer security
- 35:55WASM and JNI future roles
- 36:40Summary
related talks
44mWebAssembly and the Future of the JVM Ecosystem
28mWeb Assembly for Java Developers
50mWebAssembly and the Future of the JVM Ecosystem
38mWebAssembly at Google
31mThe Future of Write Once, Run Anywhere: From Java to WebAssembly
30mSupercharge Your Java Apps with WebAssembly
35mModern Sandboxing: Using Web Assembly in Java
50mWeb Assembly