Chromium Code Reviews| OLD | NEW |
|---|---|
| (Empty) | |
| 1 # Incremental Install | |
| 2 | |
| 3 Incremental Install is a way of building & deploying an APK that tries to | |
| 4 minimize the time it takes to make a change and see that change running on | |
| 5 device. They work best with `is_component_build=true`, and do *not* require a | |
| 6 rooted device. | |
| 7 | |
| 8 ## Building | |
| 9 | |
| 10 **Option 1:** Add the gn arg: | |
| 11 | |
| 12 incremental_apk_by_default = true | |
|
jbudorick
2017/04/11 19:56:45
Do the indents get automatically formatted as code
agrieve
2017/04/11 20:02:53
The do :)
| |
| 13 | |
| 14 This causes all apks to be built as incremental (except for blacklisted ones). | |
| 15 | |
| 16 **Option 2:** Add `_incremental` to the apk target name. E.g.: | |
| 17 | |
| 18 ninja -C out/Debug chrome_public_apk_incremental | |
| 19 ninja -C out/Debug chrome_public_test_apk_incremental | |
| 20 | |
| 21 ## Running | |
| 22 | |
| 23 It is not enough to `adb install` them. You must use a generated wrapper script: | |
| 24 | |
| 25 out/Debug/bin/install_chrome_public_apk_incremental | |
| 26 out/Debug/bin/run_chrome_public_test_apk_incremental # Automatically sets - -fast-local-dev | |
| 27 | |
| 28 ## Caveats | |
| 29 | |
| 30 Isolated processes (on L+) are incompatible with incremental install. As a | |
| 31 work-around, you can disable isolated processes only for incremental apks using | |
| 32 gn arg: | |
| 33 | |
| 34 disable_incremental_isolated_processes = true | |
| 35 | |
| 36 # How it Works | |
| 37 | |
| 38 ## Overview | |
| 39 | |
| 40 The basic idea is to side-load .dex and .so files to `/data/local/tmp` rather | |
| 41 than bundling them in the .apk. Then, when making a change, only the changed | |
| 42 .dex / .so needs to be pushed to the device. | |
| 43 | |
| 44 Faster Builds: | |
| 45 | |
| 46 * No `final_dex` step (where all .dex files are merged into one) | |
| 47 * No need to rebuild .apk for code-only changes (but required for resources) | |
| 48 * Apks sign faster because they are smaller. | |
| 49 | |
| 50 Faster Installs: | |
| 51 | |
| 52 * The .apk is smaller, and so faster to verify. | |
| 53 * No need to run `adb install` for code-only changes. | |
| 54 * Only changed .so / .dex files are pushed. MD5s of existing on-device files | |
| 55 are cached on host computer. | |
| 56 | |
| 57 Slower Initial Runs: | |
| 58 | |
| 59 * The first time you run an incremental .apk, the `DexOpt` needs to run on all | |
| 60 .dex files. This step is normally done during `adb install`, but is done on | |
| 61 start-up for incremental apks. | |
| 62 * DexOpt results are cached, so subsequent runs are much faster | |
| 63 | |
| 64 ## The Code | |
| 65 | |
| 66 All incremental apks have the same classes.dex, which is built from: | |
| 67 | |
| 68 //build/android/incremental_install:bootstrap_java | |
| 69 | |
| 70 They also have a transformed `AndroidManifest.xml`, which overrides the the | |
| 71 main application class and any instrumentation classes so that they instead | |
| 72 point to `BootstrapApplication`. This is built by: | |
| 73 | |
| 74 //build/android/incremental_install/generate_android_manifest.py | |
| 75 | |
| 76 Wrapper scripts and install logic is contained in: | |
| 77 | |
| 78 //build/android/incremental_install/create_install_script.py | |
| 79 //build/android/incremental_install/installer.py | |
| 80 | |
| 81 Finally, GN logic for incremental apks is sprinkled throughout. | |
| OLD | NEW |