Incremental Install is a way of building & deploying an APK that tries to minimize the time it takes to make a change and see that change running on device. They work best with
is_component_build=true, and do not require a rooted device.
Option 1: Add the gn arg:
incremental_apk_by_default = true
This causes all apks to be built as incremental (except for blacklisted ones).
Option 2: Add
_incremental to the apk target name. E.g.:
ninja -C out/Debug chrome_public_apk_incremental ninja -C out/Debug chrome_public_test_apk_incremental
It is not enough to
adb install them. You must use a generated wrapper script:
out/Debug/bin/install_chrome_public_apk_incremental out/Debug/bin/run_chrome_public_test_apk_incremental # Automatically sets --fast-local-dev
Isolated processes (on L+) are incompatible with incremental install. As a work-around, you can disable isolated processes only for incremental apks using gn arg:
disable_incremental_isolated_processes = true
The basic idea is to side-load .dex and .so files to
/data/local/tmp rather than bundling them in the .apk. Then, when making a change, only the changed .dex / .so needs to be pushed to the device.
final_dexstep (where all .dex files are merged into one)
adb installfor code-only changes.
Slower Initial Runs:
DexOptneeds to run on all .dex files. This step is normally done during
adb install, but is done on start-up for incremental apks.
All incremental apks have the same classes.dex, which is built from:
They also have a transformed
AndroidManifest.xml, which overrides the the main application class and any instrumentation classes so that they instead point to
BootstrapApplication. This is built by:
Wrapper scripts and install logic is contained in:
Finally, GN logic for incremental apks is sprinkled throughout.