An APK ships Dalvik bytecode (classes.dex), not machine code. On first launch the Android Runtime (ART) must verify each class it touches (the Verification of ... took 143.934ms warnings of Reading and Filtering Logcat), then interpret the bytecode, while a JIT compiler gradually compiles hot methods. Only later, while the phone idles and charges, does dex2oat compile ahead of time the methods a profile marks as hot. Until then every cold start pays the interpreter's price. ART's compiler filter records how far a package got, and adb shell cmd package compile -m <filter> -f <package> forces one, which makes the effect measurable. Five cold starts of BookNest's release build per filter, timed with adb shell am start -W:
| Compiler filter | What is compiled | TotalTime, median of 5 |
|---|---|---|
| verify | Nothing: verified bytecode, interpreted and JIT | 3,420 ms |
| speed-profile | Methods listed in the app's profile | 2,531 ms |
| speed | Every method | 2,585 ms |
A fresh install from Google Play 1 starts near the first row, and Play's cloud profiles, aggregated from early users, take days to reach a new version. Compiling everything (speed) was no faster here than compiling the right methods, and it costs install time and storage. A baseline profile is the list of right methods, shipped inside the APK as assets/dexopt/baseline.prof and applied by dex2oat at install time, so the first launch already runs the speed-profile row.
BookNest's release APK had that file (11,734 bytes) before this section wrote a line of profile: AGP merges the profiles that libraries such as Compose 234 ship for their own code. That, plus what the JIT had recorded during the five verify runs, is what speed-profile compiled. The debug APK had none, and 18 separate dex files. Missing was BookNest's own code, which the next subsection profiles; Google reports gains of about 30% from the first launch.