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 |