diff options
Diffstat (limited to 'en/devices/tech/dalvik/configure.html')
| -rw-r--r-- | en/devices/tech/dalvik/configure.html | 596 |
1 files changed, 267 insertions, 329 deletions
diff --git a/en/devices/tech/dalvik/configure.html b/en/devices/tech/dalvik/configure.html index 2018b9c5..b6868f76 100644 --- a/en/devices/tech/dalvik/configure.html +++ b/en/devices/tech/dalvik/configure.html @@ -24,9 +24,8 @@ <p>This page discusses how to configure ART and its compilation options. Topics addressed here -include configuration of pre-compilation of the system image, dex2oat compilation options at -first boot (and post-OTA), and how to trade off system partition space, data partition space, -and performance.</p> +include configuration of pre-compilation of the system image, dex2oat compilation options, +and how to trade off system partition space, data partition space, and performance.</p> <p>See <a href="http://source.android.com/devices/tech/dalvik/index.html">ART and Dalvik</a>, the <a @@ -39,105 +38,105 @@ properly.</p> <h2 id=how_art_works>How ART works</h2> -<p>ART is the new Android runtime for the Android 5.0 (Lollipop or L) release and -beyond. Dalvik is no longer available. </p> - -<p>Please note, this section merely summarizes ART’s configuration. For an -in-depth description, see the <a -href="https://www.google.com/events/io/io14videos/b750c8da-aebe-e311-b297-00155d5066d7">Android -runtime</a> presentation conducted at Google I/O 2014. </p> - -<p>ART uses ahead-of-time (AOT) compilation. This means that, at installation, dex -code is compiled to native code in OAT files, which replace Dalvik’s odex -files. This has several implications:</p> - +<p>ART uses ahead-of-time (AOT) compilation, and starting in Android 7.0 +(Nougat or N), it uses a hybrid combination of AOT, just-in-time (JIT) +compilation, and profile-guided compilation. The combination of all these +compilation modes is configurable and will be discussed in this section. As an +example, Pixel devices are configured with the following compilation flow:</p> +<ol> +<li>An application is initially installed without any AOT compilation. The + first few times the application runs, it will be interpreted, and methods + frequently executed will be JIT compiled.</li> +<li>When the device is idle and charging, a compilation daemon runs to + AOT-compile frequently used code based on a profile generated during the + first runs.</li> +<li>The next restart of an application will use the profile-guided code and + avoid doing JIT compilation at runtime for methods already compiled. Methods + that get JIT-compiled during the new runs will be added to the profile, which + will then be picked up by the compilation daemon.</li> +</ol> + +<p>ART comprises a compiler (the <code>dex2oat</code> tool) and a runtime +(<code>libart.so</code>) that is loaded for starting the Zygote. The +<code>dex2oat</code> tool takes an APK file and generates one or more +compilation artifact files that the runtime loads. The number of files, their +extensions, and names are subject to change across releases, but as of the +Android O release, the files being generated are:</p> <ul> - <li> Performance is improved over Dalvik. There is also a commensurate improvement -in power consumption measured in the lab. - <li> There is no runtime code cache. The OAT files are mapped to memory (and are -thus page-able). The RAM memory footprint for OAT files might seem larger in -terms of Proportional Set Size (PSS, or the memory shared across processes -divided evenly between the processes). But because they are pageable we have -found the system impact is improved in terms of real memory pressure effects as -the Dalvik JIT cache was not pageable. - <li> Similar to preloaded classes in the zygote, ART attempts to pre-initialize a -set of classes at compile time. This creates a ‘boot.art’ file that comprises -an image of the compacted heap of pre-initialized classes and related objects. -This file is mapped into memory upon zygote startup. While this consumes -additional storage (typically 10MB), it speeds zygote startup and creates -opportunities for the system to swap out some preloaded classes under memory -pressure. This also contributes to improved <a -href="http://source.android.com/devices/tech/config/low-ram.html">low-RAM</a> performance -for ART, since in Dalvik much of this class information would have -been stored in dirty pages in the linear alloc space. - <li> Dex file compilation uses a tool called dex2oat and takes more time than -dexopt. The increase in time varies, but 2-3x increases in compile time are not -unusual. For example, apps that typically take a second to install using dexopt -might take 2-3 seconds. - <li> OAT files are larger than odex files if full compilation is enabled. We discuss -options to mitigate this cost later in this document. +<li><code>.vdex</code>: contains the uncompressed DEX code of the + APK, with some additional metadata to speed up verification.</li> +<li><code>.odex</code>: contains AOT compiled code for methods in the + APK.</li> +<li><code>.art (optional)</code>: contains ART internal + representations of some strings and classes listed in the APK, used to speed + application startup. </li> </ul> <h2 id=compilation_options>Compilation options</h2> -<p>Dex file compilation takes more time than dexopt, which can be noticeable when -all of a user’s apps must be compiled during first boot (after factory reset or -after receiving an OTA). To reduce the amount of compilation needed, ART -supports the option of pre-optimizing libraries and applications in the system -partition. Including the pre-optimized dex files takes space in the system -image, so these options trade first boot time for system image size. Note that -OTAs are relatively infrequent and subsequent boot times should be the same -with or without pre-optimization.</p> - -<h3 id=undefined>WITH_DEXPREOPT</h3> - -<p>Pre-optimization is controlled by the build option -<code>WITH_DEXPREOPT</code>. Before the L release, this was enabled by default -in “user” builds. Starting in L, this option is opt-in and needs to be enabled -in the product configuration such as a device’s BoardConfig.mk file.</p> - -<p>Enabling <code>WITH_DEXPREOPT</code> causes everything in the system image to be -pre-optimized. If this makes the system image too large, additional options can -be specified to reduce the amount of pre-optimization. Note that all the -following build options with “PREOPT” in the name must have <code>WITH_DEXPREOPT</code> -enabled to work.</p> - -<p>Example usage (in product’s BoardConfig.mk):</p> - -<pre class="devsite-click-to-copy">WITH_DEXPREOPT := true</pre> - -<h3 id=dont_dexpreopt_prebuilts>DONT_DEXPREOPT_PREBUILTS</h3> +<p>Compilation options for ART are of two categories: +<ol> +<li>System ROM configuration: what code gets AOT-compiled when building a + system image.</li> +<li>Runtime configuration: how ART compiles and runs applications on a + device.</li> +</ol> +</p> + +<p>One core ART option to configure these two categories is <em>compiler +filters</em>. Compiler filters drive how ART compiles DEX code and is an +option passed to the <code>dex2oat</code> tool. Starting in Android O, there +are four officially supported filters:</p> +<ul> +<li><em>verify</em>: only run DEX code verification.</li> +<li><em>quicken</em>: run DEX code verification and optimize some DEX + instructions to get better interpreter performance.</li> +<li><em>speed</em>: run DEX code verification and AOT-compile all methods.</li> +<li><em>speed-profile</em>: run DEX code verification and AOT-compile methods + listed in a profile file.</li> +</ul> -<p>Enabling <code>DONT_DEXPREOPT_PREBUILTS</code> prevents the prebuilts from being -pre-optimized. These are apps that have <code>include $(BUILD_PREBUILT)</code> specified -in their Android.mk, such as Gmail. Skipping pre-optimization of prebuilt apps -that are likely to be updated via Google Play saves /system space but does add -to first boot time.</p> +<h3 id=system_rom>System ROM configuration</h3> -<p>Example usage (in product’s BoardConfig.mk):</p> +<p>There are a number of ART build options available for configuring a system +ROM. How to configure these options depends on the available storage space for +<code>/system</code> and the number of pre-installed applications. The +JARs/APKs that are compiled into a system ROM can be divided in four +categories:</p> +<ul> +<li>Boot classpath code: compiled with the <em>speed</em> compiler filter by + default.</li> +<li>System server code: compiled with the <em>speed</em> compiler filter by + default.</li> +<li>Product-specific core applications: compiled with the <em>speed</em> + compiler filter by default.</li> +<li>All other applications: compiled with the <em>quicken</em> compiler filter + by default.</li> +</ul> -<pre class="devsite-click-to-copy"> -WITH_DEXPREOPT := true -DONT_DEXPREOPT_PREBUILTS := true -</pre> +<h4 id=build_options>Makefile options</h4> +<ul> -<h3 id=with_dexpreopt_boot_img_only>WITH_DEXPREOPT_BOOT_IMG_ONLY</h3> +<li><code>WITH_DEXPREOPT</code></li> +<p> +Whether <code>dex2oat</code> is invoked on DEX code installed on the system image. Enabled by default. +</p> -<p>Enabling <code>WITH_DEXPREOPT_BOOT_IMG_ONLY</code> only pre-optimizes the -boot image, which consists of boot.art with the image classes and boot.oat with -code for the boot classpath. Enabling this saves significant /system space but -means all apps will be optimized at first boot. Typically it is better to -selectively disable app pre-optimization via -<code>DONT_DEXPREOPT_PREBUILTS</code> or add-product-dex-preopt-module-config.</p> +<li><code>DONT_DEXPREOPT_PREBUILTS</code> (since Android 5.0)</li> +<p> +Enabling <code>DONT_DEXPREOPT_PREBUILTS</code> prevents the prebuilts from being +pre-optimized. These are apps that have <code>include $(BUILD_PREBUILT)</code> +specified in their <code>Android.mk</code>, such as Gmail. Skipping +pre-optimization of prebuilt apps that are likely to be updated via Google Play +saves <code>/system</code> space but does add to first boot time. +</p> -<p>Example usage (in product’s BoardConfig.mk):</p> +<li><code>WITH_DEXPREOPT_BOOT_IMG_ONLY</code></li> -<pre class="devsite-click-to-copy"> -WITH_DEXPREOPT := true -WITH_DEXPREOPT_BOOT_IMG_ONLY := true -</pre> +<p>Enabling <code>WITH_DEXPREOPT_BOOT_IMG_ONLY</code> pre-optimizes only the +boot classpath. -<h3 id=local_dex_preopt>LOCAL_DEX_PREOPT</h3> +<li><code>LOCAL_DEX_PREOPT</code></li> <p>Pre-optimization can also be enabled or disabled on an individual app basis by specifying the <code>LOCAL_DEX_PREOPT</code> option in the module definition. @@ -148,84 +147,69 @@ version upgrade OTAs since users may already have newer versions of apps in the data partition.</p> <p><code>LOCAL_DEX_PREOPT</code> supports the values ‘true’ or ‘false’ to -enable or disable pre-optimization respectively. In addition, ‘nostripping’ can -be specified if pre-optimization should not strip the classes.dex file from the -apk or jar file. Normally this file is stripped since it’s no longer needed -after pre-optimization, but this last option is necessary to allow third-party -APK signatures to remain valid.</p> - -<p>Example usage (in app’s Android.mk):</p> - -<pre class="devsite-click-to-copy"> -LOCAL_DEX_PREOPT := false -</pre> - -<h3 id=product_dex_preopt_*>PRODUCT_DEX_PREOPT_*</h3> - -<p>Beginning post-L release in the Android Open Source Project (AOSP), a number of -flags have been added that give further control to how pre-optimization is -done. <code>PRODUCT_DEX_PREOPT_BOOT_FLAGS</code> passes options to dex2oat to control how -the boot image is compiled. It can be used to specify customized image classes -lists, compiled classes lists, and compiler filters, all of which are described -in later sections. Similarly, <code>PRODUCT_DEX_PREOPT_DEFAULT_FLAGS</code> -controls default flags to pass to dex2oat for compilation of everything besides -the boot image, namely jar and apk files.</p> - -<p><code>PRODUCT_DEX_PREOPT_MODULE_CONFIGS</code> provides the ability to pass -dex2oat options for a particular module and product configuration. It is set in -a product’s device.mk file by <code>$(call -add-product-dex-preopt-module-config,<modules>,<option>)</code> -where <modules> is a list of <code>LOCAL_MODULE</code> and -<code>LOCAL_PACKAGE</code> names for jar and apk files respectively. Through -this flag, it is possible to have fine-grained control of pre-optimization for -each dex file and a specific device. Such tuning allows /system space to be -maximally used to improve first boot time.</p> - -<p>Example usage (in product’s device.mk):</p> - -<pre class="devsite-click-to-copy"> -PRODUCT_DEX_PREOPT_DEFAULT_FLAGS := --compiler-filter=interpret-only -$(call add-product-dex-preopt-module-config,services,--compiler-filter=space) -</pre> - -<p>These flags can also be used to selectively disable pre-optimization of a -particular module or package by specifying <code>$(call -add-product-dex-preopt-module-config,<modules>,disable)</code> in a -product's device.mk file.</p> - -<p>Example usage (in product’s device.mk):</p> - -<pre class="devsite-click-to-copy"> -$(call add-product-dex-preopt-module-config,Calculator,disable) -</pre> +enable or disable pre-optimization, respectively. In addition, ‘nostripping’ can +be specified if pre-optimization should not strip the <code>classes.dex</code> +file from the APK or JAR file. Normally this file is stripped since it’s no +longer needed after pre-optimization, but this last option is necessary to +allow third-party APK signatures to remain valid.</p> + +<li><code>PRODUCT_DEX_PREOPT_BOOT_FLAGS</code></li> +<p> +Passes options to <code>dex2oat</code> to control how the boot image is +compiled. It can be used to specify customized image classes lists, compiled +classes lists, and compiler filters. +</p> + +<li><code>PRODUCT_DEX_PREOPT_DEFAULT_FLAGS</code></li> +<p> +Passes options to <code>dex2oat</code> to control how everything besides the +boot image is compiled. +</p> + +<li><code>PRODUCT_DEX_PREOPT_MODULE_CONFIGS</code></li> +<p> +Provides the ability to pass <code>dex2oat</code> options for a particular +module and product configuration. It is set in a product’s +<code>device.mk</code> file by <code>$(call add-product-dex-preopt-module-config,<modules>,<option>)</code> +where <code><modules></code> is a list of LOCAL_MODULE and LOCAL_PACKAGE names +for JAR and APK files, respectively. +</p> + +<li><code>PRODUCT_DEXPREOPT_SPEED_APPS (New in Android O)</code></li> +<p> +List of applications that have been identified as core to the products and +which are desirable to compile with the <em>speed</em> compiler filter. For +example, persistent apps such as SystemUI get a chance to use +profile-guided compilation only at the next reboot, so it may be better for the +product to have these apps always AOT-compiled. +</p> + +<li><code>PRODUCT_SYSTEM_SERVER_APPS (New in Android O)</code></li> +<p> +List of applications that are loaded by the system server. These applications +will be compiled by default with the <em>speed</em> compiler filter. +</p> + +<li><code>WITH_DEXPREOPT_PIC (Removed in Android O)</code></li> -<h2 id=other_odex>First boot installation of DEX_PREOPT files</h2> +<p>In Android 5.1.0 through Android 6.0.1, <code>WITH_DEXPREOPT_PIC</code> can +be specified to enable position-independent code (PIC). With this, compiled +code from the image doesn’t have to be relocated from /system into +/data/dalvik-cache, saving space in the data partition. However, there is a +slight runtime impact because it disables an optimization that takes advantage +of position-dependent code. Typically, devices wanting to save space in /data +should enable PIC compilation.</p> -<p>Starting in Android 7.0, devices may use two system partitions to enable -<a href="/devices/tech/ota/ab_updates.html">A/B system updates</a>. -To allow use of DEX_PREOPT while keeping the size of system partitions down and allowing -performant first boot, the preopted files can be installed in the unused second system -partition. They are then copied to the data partition on first boot.</p> +<p>In Android 7.0, PIC compilation was enabled by default.</p> -<p>Example usage (in device-common.mk):</p> +</ul> -<pre class="devsite-click-to-copy"> -PRODUCT_PACKAGES += \ - cppreopts.sh -PRODUCT_PROPERTY_OVERRIDES += \ - ro.cp_system_other_odex=1 -</pre> -<p>And in device's BoardConfig.mk:</p> -<pre class="devsite-click-to-copy"> -BOARD_USES_SYSTEM_OTHER_ODEX := true -</pre> -<p>See <a href="/devices/tech/ota/ab_updates.html#compilation">App -compilation in background</a> to optionally include the compilation script and -binaries in the system image.</p> +<h4 id=boot_classpath>Boot classpath configuration</h4> -<h2 id=preloaded_classes_list>Preloaded Classes List</h2> +<ul> +<li>Preloaded Classes List</li> <p>The preloaded classes list is a list of classes the zygote will initialize on startup. This saves each app from having to run these class initializers @@ -244,10 +228,10 @@ PRODUCT_COPY_FILES += <filename>:system/etc/preloaded-classes </pre> <p class="note"><strong>Note:</strong> This line must be placed before -inheriting any product configuration makefiles that get the default one from -build/target/product/base.mk.</p> +inheriting any product configuration makefiles that get the default one from: +<code>build/target/product/base.mk</code></p> -<h2 id=image_classes_list>Image Classes List</h2> +<li>Image Classes List</li> <p>The image classes list is a list of classes that dex2oat initializes ahead of time and stores in the boot.art file. This allows the zygote to load these @@ -256,16 +240,19 @@ for these classes itself during preloading. A key feature of this is that the pages loaded from the image and shared between processes can be clean, allowing them to be swapped out easily in low-memory situations. In L, by default the image classes list uses the same list as the preloaded classes list. Beginning -post-L in AOSP, a custom image classes list can be specified using -<code>PRODUCT_DEX_PREOPT_BOOT_FLAGS</code>.</p> +post-L in AOSP, a custom image classes list can be specified using:</p> -<p>Example usage (in product’s device.mk):</p> +<pre class="devsite-click-to-copy"> +PRODUCT_DEX_PREOPT_BOOT_FLAGS +</pre> + +<p>Example use (in product’s <code>device.mk</code>):</p> <pre class="devsite-click-to-copy"> PRODUCT_DEX_PREOPT_BOOT_FLAGS += --image-classes=<filename> </pre> -<h2 id=compiled_classes_list>Compiled Classes List</h2> +<li>Compiled Classes List</li> <p>In post-L AOSP, a subset of classes from the boot classpath can be specified to be compiled during pre-optimization using the compiled classes list. This can @@ -275,93 +262,104 @@ list will not be compiled - not even on the device - and must be interpreted, potentially affecting runtime performance. By default, dex2oat will look for a compiled classes list in $OUT/system/etc/compiled-classes, so a custom one can be copied to that location by the device.mk. A particular file location can -also be specified using <code>PRODUCT_DEX_PREOPT_BOOT_FLAGS</code>.</p> +also be specified using: -<p>Example usage (in product’s device.mk):</p> +<pre class="devsite-click-to-copy"> +PRODUCT_DEX_PREOPT_BOOT_FLAGS +</pre> + +<p>Example usage (in product’s <code>device.mk</code>):</p> <pre class="devsite-click-to-copy"> PRODUCT_COPY_FILES += <filename>:system/etc/compiled-classes </pre> <p class="note"><strong>Note:</strong> This line must be placed before -inheriting any product configuration makefiles that get the default one from -build/target/product/base.mk.</p> - -<h2 id=compiler_filters>Compiler Filters</h2> - -<p>In L, dex2oat takes a variety of --compiler-filter options to control how it -compiles. Passing in a compiler filter flag for a particular app specifies how -it’s pre-optimized. Here’s a description of each available option:</p> - -<ul> - <li><em>everything</em> - compiles almost everything, excluding class initializers and some rare -methods that are too large to be represented by the compiler’s internal -representation. - <li><em>speed</em> - compiles most methods and maximizes runtime performance, which is the -default option. - <li><em>speed-profile</em> - compiles methods passed from a profile file - through the <em>--profile-file</em> option or <em>--profile-file-fd</em> option. - <li><em>balanced</em> - attempts to get the best performance return on compilation investment. - <li><em>space</em> - compiles a limited number of methods, prioritizing storage space. - <li><em>interpret-only</em> - skips all compilation and relies on the interpreter to run code. - <li><em>verify-profile</em> - skips all compilation and only performs verification of methods passed - from a profile file through the <em>--profile-file</em> option or <em>--profile-file-fd</em> option. - <li><em>verify-none</em> - special option that skips verification and compilation, should be used only -for trusted system code. +inheriting any product configuration makefiles that get the default one from: +<code>build/target/product/base.mk</code></p> </ul> -<h2 id=with_dexpreopt_pic>WITH_DEXPREOPT_PIC</h2> - -<p>In Android 5.1.0 through Android 6.0.1, <code>WITH_DEXPREOPT_PIC</code> can -be specified to enable position-independent code (PIC). With this, compiled -code from the image doesn’t have to be relocated from /system into -/data/dalvik-cache, saving space in the data partition. However, there is a -slight runtime impact because it disables an optimization that takes advantage -of position-dependent code. Typically, devices wanting to save space in /data -should enable PIC compilation.</p> - -<p>Example usage (in product’s device.mk):</p> +<h3 id=runtime_configuration>Runtime configuration</h3> -<pre class="devsite-click-to-copy"> -WITH_DEXPREOPT := true -WITH_DEXPREOPT_PIC := true -</pre> +<h4 id=undefined>Jit options</h4> -<p>Starting in Android 7.0, PIC compilation is enabled by default.</p> +<p>The following options affect Android releases only where the ART JIT compiler +is available.</p> -<h2 id=with_art_small_mode>WITH_ART_SMALL_MODE</h2> +<ul> +<li>dalvik.vm.usejit: whether or not the JIT is enabled.</li> +<li>dalvik.vm.jitinitialsize (default 64K): the initial capacity +of the code cache. The code cache will regularly GC and increase if needed. +<li>dalvik.vm.jitmaxsize (default 64M): the maximum capacity of the code cache. +<li>dalvik.vm.jitthreshold: (default 10000) - This +is the threshold that the "hotness" counter of a method needs to pass in order +for the method to be JIT compiled. The "hotness" counter is a metric internal +to the runtime. It includes the number of calls, backward branches, and other +factors. +<li>dalvik.vm.usejitprofiles: whether or not +JIT profiles are enabled; this may be used even if dalvik.vm.usejit is false. +Note that if this is false, the compiler filter <em>speed-profile</em> does +not AOT-compile any method and is equivalent to <em>quicken</em>. +<li>dalvik.vm.jitprithreadweight (default to +dalvik.vm.jitthreshold / 20) - The weight of the JIT "samples" +(see jitthreshold) for the application UI thread. Use to speed up compilation +of methods that directly affect users experience when interacting with the +app. +<li>dalvik.vm.jittransitionweight: (default to dalvik.vm.jitthreshold / 10) +the weight of the method +invocation that transitions between compile code and interpreter. This helps +make sure the methods involved are compiled to minimize transitions (which are +expensive). +</li> +</ul> -<p>For devices with very limited space, <code>WITH_ART_SMALL_MODE</code> can be -enabled. This option compiles the boot classpath and nothing else, greatly -reducing first boot time since most compilation is skipped. It also saves on -storage because there is no compiled code for apps. However, this impacts -runtime performance since app code has to be interpreted. The impact is limited -since most performance sensitive code in the framework is still compiled, but -regressions may appear in benchmarking.</p> +<h4 id=undefined>Package manager options</h4> -<p>Example usage (in product’s device.mk):</p> +<p> +Since Android 7.0, there's a generic way to specify the level of +compilation/verification that happened at various stages. +The compilation levels can be configured via system properties +with the defaults being: +</p> -<pre class="devsite-click-to-copy"> -WITH_ART_SMALL_MODE := true -</pre> +<ul> +<li>pm.dexopt.install=quicken</li> +<p>This is the compilation filter used when installing applications through Google +Play. For faster installs, try the <em>quicken</em> compiler filter. +</p> +<li>pm.dexopt.bg-dexopt=speed-profile</li> +<p> +This is the compilation filter used when the device is idle, charging and +fully charged. Try the <em>speed-profile</em> compiler filter +to take advantage of profile-guided compilation and save on storage. +</p> +<li>pm.dexopt.boot=verify</li> +<p> +The compilation filter used after an over-the-air update. We +<strong>strongly</strong> recommend the <em>verify</em> compiler filter for this +option to avoid very long boot times. +</p> +<li>pm.dexopt.first-boot=quicken<li> +<p> +The compilation filter for the first time the device ever boots. The filter +used here will only affect the boot time after factory. We recommend the filter +<em>quicken</em> for it to avoid long times before a user gets to +use the phone for the very first time. Note that if all applications in +<code>/system</code> are already compiled with the <em>quicken</em> compiler +filter or are compiled with the <em>speed</em> or <em>speed-profile</em> +compiler filter, the <code>pm.dexopt.first-boot</code> has no effect. +</p> -<p>In future releases, this build option will be removed since it can be done with -this (in product’s device.mk):</p> +</ul> -<pre class="devsite-click-to-copy"> -PRODUCT_PROPERTY_OVERRIDES += \ - dalvik.vm.dex2oat-filter=interpret-only \ - dalvik.vm.image-dex2oat-filter=speed -</pre> +<h4 id=undefined>Dex2oat options</h4> -<h2 id=dalvik_vm_properties>dalvik.vm Properties</h2> -<p>Most dalvik.vm properties in ART are similar to Dalvik, but there are a few -additional ones as described below. Note that these options affect dex2oat +<p>Note that these options affect <code>dex2oat</code> during on-device compilation as well as during pre-optimization, whereas most of the options discussed above affect only pre-optimization.</p> -<p>To control dex2oat while it’s compiling the boot image:</p> +<p>To control <code>dex2oat</code> while it’s compiling the boot image:</p> <ul> <li>dalvik.vm.image-dex2oat-Xms: initial heap size @@ -370,7 +368,7 @@ of the options discussed above affect only pre-optimization.</p> <li>dalvik.vm.image-dex2oat-threads: number of threads to use </ul> -<p>To control dex2oat while it’s compiling everything besides the boot image:</p> +<p>To control <code>dex2oat</code> while it’s compiling everything besides the boot image:</p> <ul> <li>dalvik.vm.dex2oat-Xms: initial heap size @@ -398,125 +396,65 @@ compiling everything besides the boot image:</p> <li>dalvik.vm.dex2oat-swap: use dex2oat swap file (for low-memory devices) </ul> -<p>The options that control initial and maximum heap size for dex2oat should not -be reduced since they could limit what applications can be compiled.</p> +<p>The options that control initial and maximum heap size for +<code>dex2oat</code> should not be reduced since they could limit what +applications can be compiled.</p> -<h2 id=sample_usage>Sample Usage</h2> +<h2 id=other_odex>A/B specific configuration</h2> -<p>The goal of these compiler options is to utilize available space in the system -and data partition to reduce the amount of dex2oat that must be performed by -the device. </p> +<h3 id=undefined>ROM configuration</h3> -<p>For devices with ample system and data space, enabling dex pre-optimization is -all that is necessary. - -<p>BoardConfig.mk:</p> - -<pre class="devsite-click-to-copy"> -WITH_DEXPREOPT := true -</pre> - -<p>If this causes the system image to become too large, the next thing to try is -disabling pre-optimization of the prebuilts. - -<p>BoardConfig.mk:</p> - -<pre class="devsite-click-to-copy"> -WITH_DEXPREOPT := true -DONT_DEXPREOPT_PREBUILTS := true -</pre> - -<p>Again, if the system image is still too large, try pre-optimizing only the boot -image. - -<p>BoardConfig.mk:</p> - -<pre class="devsite-click-to-copy"> -WITH_DEXPREOPT := true -WITH_DEXPREOPT_BOOT_IMG_ONLY := true -</pre> - -<p>However, limiting to pre-optimizing only the boot-image means all apps will -have to be optimized on first boot. In order to avoid this, it is possible to -combine these high level flags with more fine-grained controls to maximize the -amount of pre-optimized apps.</p> - -<p>For instance, if disabling the pre-optimization of the prebuilts almost fits -into the system partition, compiling the boot classpath with the ‘space’ option -may make it fit. Note this compiles fewer methods in the boot classpath, -potentially interpreting more code and impacting runtime performance. - -<p>BoardConfig.mk:</p> - -<pre class="devsite-click-to-copy"> -WITH_DEXPREOPT := true -DONT_DEXPREOPT_PREBUILTS := true -</pre> - -<p>device.mk:</p> - -<pre class="devsite-click-to-copy"> -PRODUCT_DEX_PREOPT_BOOT_FLAGS := --compiler-filter=space -</pre> - -<p>If a device has very limited system partition space, it’s possible to compile a -subset of classes in the boot classpath using the compiled classes list. Boot -classpath methods that aren’t in this list will have to be interpreted, which -could affect runtime performance. +<p>Starting in Android 7.0, devices may use two system partitions to enable +<a href="/devices/tech/ota/ab_updates.html">A/B system updates</a>. +To save on the system partition size, the preopted files can be installed in +the unused second system partition. They are then copied to the data partition +on first boot.</p> -<p>BoardConfig.mk:</p> +<p>Example usage (in <code>device-common.mk</code>):</p> <pre class="devsite-click-to-copy"> -WITH_DEXPREOPT := true -WITH_DEXPREOPT_BOOT_IMG_ONLY := true +PRODUCT_PACKAGES += \ + cppreopts.sh +PRODUCT_PROPERTY_OVERRIDES += \ + ro.cp_system_other_odex=1 </pre> -<p>device.mk:</p> +<p>And in device's <code>BoardConfig.mk</code>:</p> <pre class="devsite-click-to-copy"> -PRODUCT_COPY_FILES += <filename>:system/etc/compiled-classes +BOARD_USES_SYSTEM_OTHER_ODEX := true </pre> -<p>If a device has both limited space in the system and data partitions, compiler -filter flags can be used to disable compilation of certain apps. This will save -space in both system and data, as there won’t be any compiled code, but these -apps will have to be interpreted. This example configuration would pre-optimize -the boot classpath but prevent compilation of other apps that are not -prebuilts. However, to prevent noticeable performance degradation of -system_server, the services.jar is still compiled but optimized for space. Note -that user-installed applications will still use the default compiler filter of -speed. - -<p>BoardConfig.mk:</p> +<p> +Note that boot classpath code, system server code, and product-specific core +applications always compile to the system partition. By default, all other +applications get compiled to the unused second system partition. This can be +controlled with the <code>SYSTEM_OTHER_ODEX_FILTER</code>, which has a value by +default of:</p> <pre class="devsite-click-to-copy"> -WITH_DEXPREOPT := true -DONT_DEXPREOPT_PREBUILTS := true +SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/% </pre> -<p>device.mk:</p> +<h3 id=undefined>Background dexopt OTA</h3> +<p>With A/B enabled devices, applications can be compiled in the background for +updating to the new system image. See <a +href="/devices/tech/ota/ab_updates.html#compilation">App compilation in +background</a> to optionally include the compilation script and +binaries in the system image. The compilation filter used for this compilation +is controlled with:</p> <pre class="devsite-click-to-copy"> -PRODUCT_DEX_PREOPT_DEFAULT_FLAGS := --compiler-filter=interpret-only -$(call add-product-dex-preopt-module-config,services,--compiler-filter=space) +pm.dexopt.ab-ota=speed-profile </pre> -<p>For a major version upgrade OTA, it can be useful to blacklist certain apps -from being pre-optimized since they will likely be out of date. This can be -done by specifying <code>LOCAL_DEX_PREOPT</code> (for all products) or with -<code>PRODUCT_DEX_PREOPT_MODULE_CONFIGS</code> (for a particular product). +<p> +We recommend using <em>speed-profile</em> to take advantage of profile guided +compilation and save on storage. +</p> -<p>BoardConfig.mk:</p> -<pre class="devsite-click-to-copy"> -WITH_DEXPREOPT := true -</pre> -<p>Android.mk (of blacklisted apps):</p> - -<pre class="devsite-click-to-copy"> -LOCAL_DEX_PREOPT := false -</pre> </body> </html> |