// the find
asLody/TurboDex
fast load dex in memory.
TurboDex hooks the Android runtime's DEX loading machinery at the JNI level using Cydia Substrate-style inline hooks, replacing the slow dex2oat verification path with direct memory loading. It targets developers building MultiDex apps or plugin frameworks on ART where cold DEX load times are measurably painful. The approach is genuinely clever — hook `dvmDexFileOpenPartial` equivalents so the VM skips optimization on load.
The core technique is sound: hooking the ART/Dalvik internals to bypass dex2oat at load time is the right attack on the problem. Ships prebuilt .so files for armeabi, armeabi-v7a, arm64-v8a, x86, and x86_64, which covers the practical device matrix of its era. The Java API surface is deliberately minimal — one call in `attachBaseContext` and you're done. Using MSHook (Cydia Substrate's open source hooking engine) rather than rolling a bespoke trampolining solution was a reasonable call given the complexity of ARM/Thumb instruction patching.
Last commit was April 2017 — Android has changed substantially since then. ART internals that this hooks (internal function signatures, memory layouts) shift between API levels, and there's no compatibility matrix or version guard logic visible in the source. Google Play's app security scanning has gotten far more aggressive about apps that hook ART internals; shipping this in a Play-distributed app today would likely trigger policy violations. There are no tests whatsoever — for code that patches memory at the JNI level, that's a serious gap. The actual core logic in `FastLoadDex.cpp` is opaque with no documentation on what invariants it relies on or what failure modes exist.