Как настроить ART

На этой странице рассказывается, как настроить среду выполнения Android (ART) и ее параметры компиляции. В этой статье рассматриваются такие темы, как настройка предварительной компиляции системного образа, dex2oatпараметры компиляции и компромисс между пространством системного раздела, пространством раздела данных и производительностью.

Чтобы работать с ART, ознакомьтесь с информацией о ART и Dalvik и формате исполняемых файлов Dalvik. Чтобы убедиться, что ваши приложения работают правильно, ознакомьтесь с разделом Проверка поведения приложений в среде выполнения Android (ART).

Как работает ART

В ART используется предварительная компиляция (AOT). Начиная с Android 7, ART использует гибридную комбинацию предварительной компиляции, компиляции JIT и интерпретации, а предварительная компиляция может быть основана на профиле. Сочетание всех этих режимов выполнения можно настроить. Подробнее об этом рассказывается в этом разделе. Например, устройства Pixel настроены на следующий порядок действий:

  1. Приложение изначально устанавливается с файлом метаданных DEX (.dm), распространяемым через Google Play, который содержит облачный профиль. ART AOT компилирует методы, перечисленные в облачном профиле. Если приложение установлено без файла метаданных DEX, AOT-компиляция не выполняется.
  2. При первых запусках приложения методы, не скомпилированные заранее, интерпретируются. Часто выполняемые методы JIT-компилируются. ART создает локальный профиль на основе выполнения и объединяет его с облачным профилем (если он существует).
  3. Когда устройство находится в режиме бездействия и заряжается, демон компиляции перекомпилирует приложение на основе комбинированного профиля, созданного во время первых нескольких запусков.
  4. При последующих запусках приложения ART использует артефакты, созданные демоном компиляции, которые содержат больше кода, скомпилированного заранее, чем артефакты, созданные во время первого запуска. Методы, не скомпилированные заранее, по-прежнему интерпретируются или компилируются JIT. ART обновляет профиль установки на основе выполнения, и профиль будет выбран последующими запусками демона компиляции.

ART состоит из компилятора (инструмент dex2oat) и среды выполнения (libart.so), которая загружается во время запуска. Инструмент dex2oat принимает APK-файл и создает один или несколько артефактов компиляции, которые загружаются во время выполнения. Количество файлов, их расширения и названия могут меняться в разных версиях, но в Android 8 создаются следующие файлы:

  • .vdex: содержит дополнительные метаданные, которые ускоряют проверку, иногда вместе с несжатым DEX-кодом APK.
  • .odex: содержит код, скомпилированный заранее для методов в APK.
  • .art (optional) содержит внутренние представления ART некоторых строк и классов, перечисленных в APK. Они используются для ускорения запуска приложения.

Параметры компиляции

Для ART доступны два типа параметров компиляции:

  1. Конфигурация системного ПЗУ: какой код компилируется AOT при создании образа системы.
  2. Конфигурация среды выполнения: как ART компилирует и запускает приложения на устройстве.

Фильтры компилятора

Один из основных параметров ART, позволяющих настроить эти две категории, – compiler filters. Фильтры компилятора определяют, как ART компилирует DEX-код, и передаются инструменту dex2oat. В Android 8 и более поздних версий официально поддерживаются четыре фильтра:

  • verify: выполняется только проверка DEX-кода (без AOT-компиляции).
  • quicken (Android 11 или более ранние версии). Выполняет проверку кода DEX и оптимизирует некоторые инструкции DEX для повышения производительности интерпретатора.
  • speed: выполняет проверку DEX-кода и AOT-компиляцию всех методов. Оптимизация загрузки классов не выполняется.
  • speed-profile – проверяет DEX-код, компилирует методы из профиля в режиме AOT и оптимизирует загрузку классов из профиля.

Конфигурация системного ПЗУ

Предустановленные библиотеки и приложения компилируются AOT во время создания образа системы. Этот процесс называется dexpreopt. Скомпилированные файлы можно использовать, если все зависимости остаются неизменными, в частности classpath загрузки.

Примечание. Если устройство получает обновления системного модуля, то при следующем обновлении, скорее всего, изменится путь к классам загрузки, из-за чего все файлы dexpreopt станут устаревшими и непригодными для использования.

Для настройки dexpreopt доступно несколько вариантов сборки ART. Настройка этих параметров зависит от доступного места для образа системы и количества предустановленных приложений. Файлы JAR и APK, скомпилированные в системное ПЗУ, можно разделить на четыре категории:

  • Код пути загрузки: компилируется с фильтром компилятора speed-profile по умолчанию.
  • Код системного сервера (см. PRODUCT_SYSTEM_SERVER_JARS, PRODUCT_APEX_SYSTEM_SERVER_JARS, PRODUCT_STANDALONE_SYSTEM_SERVER_JARS и PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS далее в этом документе):
    • (Android 14 и более поздние версии) По умолчанию компилируется с фильтром компилятора speed-profile или с фильтром компилятора speed, если профиль не предоставлен.
    • (Android 13 и более ранние версии) По умолчанию компилируется с фильтром компилятора speed.
    Настраивается с помощью PRODUCT_SYSTEM_SERVER_COMPILER_FILTER (см. ниже).
  • Основные приложения для определенных продуктов (см. PRODUCT_DEXPREOPT_SPEED_APPS ниже): по умолчанию компилируются с помощью фильтра компилятора speed.
  • Все остальные приложения: по умолчанию компилируются с фильтром speed-profile или с фильтром verify, если профиль не указан.

    Настраивается с помощью PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (см. ниже).

Параметры Makefile

  • WITH_DEXPREOPT

    • Вызывается ли dex2oat для кода DEX, установленного в образе системы. Этот параметр включен по умолчанию.

  • DONT_DEXPREOPT_PREBUILTS (Android 5 и более поздние версии)

    • Если включить DONT_DEXPREOPT_PREBUILTS, то dexpreopt не будет применяться к предварительно собранным файлам. Это приложения, в Android.mk которых указано include $(BUILD_PREBUILT). Пропуск dexpreopt для встроенных приложений, которые, скорее всего, будут обновлены через Google Play, экономит место в образе системы, но увеличивает время первой загрузки. Обратите внимание, что этот параметр не влияет на предустановленные приложения, определенные в Android.bp.

  • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (Android 9 и более поздние версии)

    • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER – фильтр компилятора по умолчанию для приложений, оптимизированных с помощью dexpreopt. Эти приложения определены в Android.bp или имеют include $(BUILD_PREBUILT), указанный в их Android.mk. Если значение не указано, по умолчанию используется speed-profile или verify, если значение не указано и профиль не предоставлен.

  • WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY (начиная с Android 8 MR1)

    • Если включить WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY, dexpreopt будет выполняться только для пути к классам загрузки и JAR-файлов системного сервера.

  • LOCAL_DEX_PREOPT

    • Dexpreopt также можно включить или отключить для отдельного приложения, указав параметр LOCAL_DEX_PREOPT в определении модуля. Это может быть полезно для отключения dexpreopt приложений, которые могут сразу же получить обновления Google Play, поскольку обновления сделают код dexpreopted в образе системы устаревшим. Это также позволяет экономить место при OTA-обновлениях основных версий, поскольку у пользователей в разделе данных могут быть более новые версии приложений.

    LOCAL_DEX_PREOPT поддерживает значения true и false, которые позволяют включить или отключить dexpreopt соответственно. Кроме того, можно указать nostripping, если dexpreopt не должен удалять файл classes.dex из APK- или JAR-файла. Обычно этот файл удаляется, так как он больше не нужен после dexpreopt, но последний вариант необходим, чтобы сторонние подписи APK оставались действительными.

  • PRODUCT_DEX_PREOPT_BOOT_FLAGS

    • Передает параметры в dex2oat, чтобы управлять тем, как компилируется загрузочный образ. Его можно использовать для указания списков классов изображений, скомпилированных списков классов и фильтров компилятора.

  • PRODUCT_DEX_PREOPT_DEFAULT_FLAGS

    • Передает параметры в dex2oat, чтобы управлять компиляцией всего, кроме загрузочного образа.

  • PRODUCT_DEX_PREOPT_MODULE_CONFIGS

    • Позволяет передавать параметры dex2oat для определенного модуля и конфигурации продукта. Он задается в файле device.mk с помощью $(call add-product-dex-preopt-module-config,<modules>,<option>), где <modules> – это список названий LOCAL_MODULE и LOCAL_PACKAGE для JAR- и APK-файлов соответственно.

  • PRODUCT_DEXPREOPT_SPEED_APPS (Android 8 и более поздние версии)

    • Список приложений, которые считаются основными для продуктов и которые желательно компилировать с помощью фильтра компилятора speed. Например, постоянные приложения, такие как SystemUI, могут использовать компиляцию с учетом профиля только при следующей перезагрузке, поэтому для продукта может быть лучше, если эти приложения всегда будут компилироваться AOT.

  • PRODUCT_SYSTEM_SERVER_APPS (Android 8 и более поздние версии)

    • Список приложений, загруженных системным сервером. По умолчанию эти приложения компилируются с помощью фильтра компилятора speed.

  • PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD (начиная с Android 8)

    • Указывает, нужно ли включать отладочную версию ART на устройстве. По умолчанию эта функция включена для сборок userdebug и eng. Это поведение можно переопределить, явно задав для параметра значение true или false.

    По умолчанию устройство использует версию без отладки (libart.so). Чтобы переключиться на версию с отладкой, задайте для системного свойства persist.sys.dalvik.vm.lib.2 значение libartd.so.

  • WITH_DEXPREOPT_PIC (до Android 7)

    • В Android 5.1.0–6.0.1 можно указать WITH_DEXPREOPT_PIC, чтобы включить позиционно-независимый код (PIC). Благодаря этому скомпилированный код из образа не нужно перемещать из /system в /data/dalvik-cache, что позволяет сэкономить место в разделе данных. Однако это немного влияет на время выполнения, поскольку отключает оптимизацию, использующую позиционно-зависимый код. Как правило, устройства, которым нужно сэкономить место в /data, должны включить компиляцию PIC.

    В Android 7.0 компиляция PIC была включена по умолчанию.

  • WITH_DEXPREOPT_BOOT_IMG_ONLY (до Android 7 MR1)

    • Этот параметр был заменен на WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY, который также предварительно оптимизирует JAR-файлы системного сервера.

  • PRODUCT_SYSTEM_SERVER_COMPILER_FILTER

    • Этот параметр определяет фильтр компилятора для системного сервера.

    • (Android 14 и более поздние версии) Если не указано, используется фильтр компилятора speed-profile или speed, если профиль не предоставлен.
    • (Android 13 и более ранние версии) Если значение не указано, используется фильтр компилятора speed.
    • Если задано значение speed, используется фильтр компилятора speed.
    • Если задано значение speed-profile, используется фильтр компилятора speed-profile или verify, если профиль не указан.
    • Если задано значение verify, используется фильтр компилятора verify.

  • PRODUCT_SYSTEM_SERVER_JARS, PRODUCT_APEX_SYSTEM_SERVER_JARS, PRODUCT_STANDALONE_SYSTEM_SERVER_JARS, PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS

    • Ниже приведены списки JAR-файлов, загружаемых системным сервером. JAR-файлы компилируются с помощью фильтра компилятора, указанного в PRODUCT_SYSTEM_SERVER_COMPILER_FILTER.

    • (Обязательно) PRODUCT_SYSTEM_SERVER_JARS: список JAR-файлов пути к классам системного сервера на платформе (то есть как часть SYSTEMSERVERCLASSPATH). Добавление JAR-файлов пути к классам системного сервера в этот список обязательно. Если не добавить JAR-файлы системного сервера в список, они не будут загружены.
    • (Обязательно) PRODUCT_APEX_SYSTEM_SERVER_JARS: список JAR-файлов classpath системного сервера, поставляемых с APEX (то есть как часть SYSTEMSERVERCLASSPATH). Формат: <apex name>:<jar name>. Добавление JAR-файлов системного сервера APEX в этот список обязательно. Если не добавить JAR-файлы системного сервера APEX в этот список, они не будут загружены.
    • (Необязательный параметр для Android 13 и более ранних версий) PRODUCT_STANDALONE_SYSTEM_SERVER_JARS: список JAR-файлов, которые системный сервер загружает динамически, используя отдельные загрузчики классов (через SystemServiceManager.startServiceFromJar). Добавлять в этот список отдельные JAR-файлы системного сервера не обязательно, но настоятельно рекомендуется, поскольку это позволяет компилировать JAR-файлы и, следовательно, повысить производительность во время выполнения.
    • (обязательный элемент для Android 13 и более поздних версий) PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS: список JAR-файлов, поставляемых с APEX, которые системный сервер динамически загружает с помощью отдельных загрузчиков классов (то есть через SystemServiceManager.startServiceFromJar или объявленных как <apex-system-service>). Формат: <apex name>:<jar name>. В этот список необходимо добавить отдельные JAR-файлы системного сервера APEX. Если не добавить в этот список JAR-файлы отдельного системного сервера APEX, загрузка не удастся.

    Настройка пути к классам загрузчика

    Список предварительно загруженных классов – это список классов, которые Zygote инициализирует при запуске. Это позволяет приложениям запускаться быстрее и совместно использовать страницы в памяти, поскольку им не нужно запускать инициализаторы классов по отдельности. Файл со списком предварительно загруженных классов по умолчанию находится в каталоге frameworks/base/config/preloaded-classes и содержит список, оптимизированный для типичного использования телефона. На других устройствах, например носимых, это значение может быть другим, и его нужно будет настроить соответствующим образом. Будьте осторожны при настройке этого параметра. Если добавить слишком много классов, память будет расходоваться впустую, когда загружаются неиспользуемые классы. Если классов будет слишком мало, каждому приложению придется иметь собственную копию, что приведет к неэффективному использованию памяти.

    Пример использования (в фиде device.mk):

    PRODUCT_COPY_FILES += <filename>:system/etc/preloaded-classes

    Примечание. Эту строку необходимо разместить до того, как будут унаследованы файлы makefile конфигурации продукта, которые получают файл makefile по умолчанию из build/target/product/base.mk.

    Конфигурация среды выполнения

    Параметры JIT

    Перечисленные ниже параметры влияют на выпуски Android, только если доступен JIT-компилятор ART.

    • dalvik.vm.usejit – включена ли JIT-инициализация.
    • dalvik.vm.jitinitialsize (по умолчанию 64 КБ) – начальная емкость кеша кода. Кэш кода будет регулярно очищаться и увеличиваться при необходимости.
    • dalvik.vm.jitmaxsize (по умолчанию 64 МБ) – максимальный размер кеша кода.
    • dalvik.vm.jitthreshold (по умолчанию 10 000). Порог, который должен преодолеть счетчик "горячести" метода, чтобы метод был скомпилирован JIT. Счетчик "горячести" – это внутренняя метрика среды выполнения. в том числе количество вызовов, обратных ветвей и т. д.
    • dalvik.vm.usejitprofiles (до Android 13): включены ли профили JIT. Это правило можно использовать, даже если для правила dalvik.vm.usejit задано значение False. Обратите внимание, что если это значение равно false, фильтр компилятора speed-profile не выполняет AOT-компиляцию ни одного метода и эквивалентен verify. В Android 14 и более поздних версиях профили JIT всегда включены и их нельзя отключить.
    • dalvik.vm.jitprithreadweight (по умолчанию dalvik.vm.jitthreshold / 20) – вес "образцов" JIT (см. jitthreshold) для потока UI приложения. Используется для ускорения компиляции методов, которые напрямую влияют на удобство работы пользователей с приложением.
    • dalvik.vm.jittransitionweight (по умолчанию dalvik.vm.jitthreshold / 10): вес вызова метода, который переключается между скомпилированным кодом и интерпретатором. Это позволяет скомпилировать задействованные методы так, чтобы минимизировать переходы, которые требуют значительных ресурсов.

    Параметры Dex2oat

    Эти параметры влияют на компиляцию на устройстве (dexopt), а некоторые из них – и на dexpreopt. Параметры, описанные в разделе Конфигурация системного ПЗУ выше, влияют только на dexpreopt.

    Параметры для управления использованием ресурсов:

    • dalvik.vm.image-dex2oat-threads/dalvik.vm.image-dex2oat-cpu-set (до Android 11) – количество потоков и набор ядер ЦП (см. ниже), которые будут использоваться для загрузочных образов.
    • dalvik.vm.boot-dex2oat-threads/dalvik.vm.boot-dex2oat-cpu-set:
      • (до Android 11) Количество потоков и набор ядер ЦП (см. ниже), которые будут использоваться во время загрузки для всего, кроме загрузочных образов.
      • (начиная с Android 12) Количество потоков и набор ядер ЦП (см. ниже), которые будут использоваться во время загрузки для всего, включая загрузочные образы.
        • В Android 14 и более поздних версиях это соответствует классу приоритета PRIORITY_BOOT в ART Service.
    • dalvik.vm.restore-dex2oat-threads/dalvik.vm.restore-dex2oat-cpu-set:
      • (Android 11–13) Количество потоков и набор ядер ЦП (см. ниже), которые будут использоваться для восстановления из облачной резервной копии.
      • (на устройствах с Android 14 и более поздних версий) Количество потоков и набор ядер ЦП (см. ниже), которые будут использоваться для всех задач, более чувствительных к задержкам, чем обычно, в том числе для восстановления из облачной резервной копии.
        • В частности, это соответствует классу приоритета PRIORITY_INTERACTIVE_FAST в сервисе ART.
    • dalvik.vm.background-dex2oat-threads/ dalvik.vm.background-dex2oat-cpu-set (начиная с Android 14): количество потоков и набор ядер ЦП (см. ниже), которые будут использоваться в фоновом режиме.
      • В частности, это соответствует классу приоритета PRIORITY_BACKGROUND в сервисе ART.
    • dalvik.vm.dex2oat-threads/dalvik.vm.dex2oat-cpu-set: Количество потоков и набор ядер ЦП, которые будут использоваться для всех остальных задач.

    Набор ядер ЦП должен быть указан в виде списка идентификаторов ЦП, разделенных запятыми. Например, чтобы запустить dex2oat на ядрах ЦП 0–3, задайте следующие значения:

    dalvik.vm.dex2oat-cpu-set=0,1,2,3

    При настройке свойств сходства ЦП мы рекомендуем сопоставить соответствующее свойство для количества потоков dex2oat с количеством выбранных ЦП, чтобы избежать ненужного конфликта памяти и I/O: 

    dalvik.vm.dex2oat-cpu-set=0,1,2,3
dalvik.vm.dex2oat-threads=4

    Помимо системных свойств, описанных выше, вы также можете использовать профили задач, чтобы контролировать использование ресурсов dex2oat (см. уровень абстракции Cgroup).

    Поддерживаются следующие профили задач:

    • Dex2OatBackground (начиная с Android 14) (по умолчанию наследует Dex2OatBootComplete): управляет ресурсами, которые используются в фоновом режиме.
      • В частности, это соответствует классу приоритета PRIORITY_BACKGROUND в сервисе ART.
    • Dex2OatBootComplete:
      • (До Android 13.) Управляет ресурсом, который используется для всего после загрузки.
      • (начиная с Android 14) Управляет ресурсом, который будет использоваться для всех задач после загрузки, а не в фоновом режиме.
        • В частности, это соответствует классам приоритета PRIORITY_INTERACTIVE_FAST и PRIORITY_INTERACTIVE в сервисе ART.

    Если указаны и системные свойства, и профили задач, будут действовать и те, и другие.

    Параметры для управления размером кучи:

    • dalvik.vm.image-dex2oat-Xms – начальный размер кучи для загрузочных образов.
    • dalvik.vm.image-dex2oat-Xmx – максимальный размер кучи для загрузочных образов.
    • dalvik.vm.dex2oat-Xms: начальный размер кучи для всего остального.
    • dalvik.vm.dex2oat-Xmx – максимальный размер кучи для всего остального.

    Не следует уменьшать значения параметров, которые управляют начальным и максимальным размером кучи для dex2oat, поскольку это может ограничить возможности компиляции приложений.

    Варианты управления фильтром компилятора:

    • dalvik.vm.image-dex2oat-filter (до Android 11): Фильтр компилятора для загрузочных образов. В Android 12 и более поздних версиях фильтр компилятора для загрузочных образов всегда имеет значение speed-profile и не может быть изменен.
    • dalvik.vm.systemservercompilerfilter (начиная с Android 13) – фильтр компилятора для системного сервера. Подробнее: PRODUCT_SYSTEM_SERVER_COMPILER_FILTER.
    • dalvik.vm.systemuicompilerfilter (начиная с Android 13) – фильтр компилятора для пакета интерфейса системы.
    • dalvik.vm.dex2oat-filter (до Android 6) – фильтр компилятора для всего остального.
    • pm.dexopt.<reason> (начиная с Android 7): Фильтр компилятора для всего остального. Подробнее о настройке сервиса ART для Android 14 и более поздних версий и настройке менеджера пакетов для Android 13 и более ранних версий…

    Другие варианты управления компиляцией всего, кроме загрузочных образов:

    • dalvik.vm.dex2oat-very-large (начиная с Android 7.1): минимальный общий размер DEX-файла в байтах, при котором отключается компиляция AOT.
    • dalvik.vm.dex2oat-swap (начиная с Android 7.1; по умолчанию – true): разрешает использовать файл подкачки для dex2oat. Это поможет избежать сбоев из-за нехватки памяти. Обратите внимание, что даже если этот параметр включен, dex2oat будет использовать файл подкачки только при определенных условиях, например когда файлов dex много. Условия могут меняться.
    • dalvik.vm.ps-min-first-save-ms (начиная с Android 12): минимальное время ожидания, прежде чем среда выполнения создаст профиль приложения при первом запуске.
    • dalvik.vm.ps-min-save-period-ms (начиная с Android 12): минимальное время ожидания перед обновлением профиля приложения.
    • dalvik.vm.dex2oat64.enabled (начиная с Android 11) (по умолчанию: false): использовать ли 64-разрядную версию dex2oat.
    • dalvik.vm.bgdexopt.new-classes-percent (начиная с Android 12) (по умолчанию: 20): минимальный процент новых классов в профиле (от 0 до 100), при котором запускается повторная компиляция. Применяется только к компиляции с учетом профиля (speed-profile), обычно во время фоновой оптимизации DEX. Обратите внимание, что помимо процентного порога также существует порог в 50 новых курсов. Его нельзя изменить.
    • dalvik.vm.bgdexopt.new-methods-percent (начиная с Android 12) (по умолчанию: 20): минимальный процент (от 0 до 100) новых методов в профиле, при котором запускается повторная компиляция. Применяется только к компиляции с учетом профиля (speed-profile), обычно во время фоновой оптимизации DEX. Обратите внимание, что помимо порогового значения в процентах существует также пороговое значение не менее 100 новых методов, и его нельзя настроить.
    • dalvik.vm.dex2oat-max-image-block-size (начиная с Android 10) (по умолчанию: 524288) Максимальный размер сплошного блока для сжатых изображений. Большое изображение разбивается на несколько блоков, размер каждого из которых не превышает максимальный.
    • dalvik.vm.dex2oat-resolve-startup-strings (начиная с Android 10) (по умолчанию: true) Если установлено значение true, dex2oat разрешает все константные строки, на которые ссылаются методы, помеченные в профиле как startup.
    • debug.generate-debug-info (по умолчанию: false) Указывает, нужно ли создавать сведения для отладки для отладки нативных приложений, например информацию о раскрутке стека, символы ELF и разделы DWARF.
    • dalvik.vm.dex2oat-minidebuginfo (начиная с Android 9) (по умолчанию: true) Указывает, нужно ли генерировать минимальный объем сжатых по алгоритму LZMA сведений для отладки, необходимых для вывода трассировки стека.

    Варианты использования ART

    В Android 14 компиляция AOT для приложений на устройстве (также известная как dexopt) выполняется сервисом ART. Информацию о настройке ART Service можно найти в разделе Конфигурация ART Service.

    Варианты менеджера пакетов

    До Android 14 компиляция AOT на устройстве для приложений (также известная как dexopt) выполнялась менеджером пакетов. Информацию о том, как настроить менеджер пакетов для dexopt, можно найти в разделе Настройка менеджера пакетов.

    Конфигурация для A/B-тестирования

    Конфигурация ROM

    Начиная с Android 7.0 на устройствах могут использоваться два системных раздела, чтобы обеспечить обновление системы A/B. Чтобы сэкономить место в системном разделе, предварительно оптимизированные файлы можно установить в неиспользуемый второй системный раздел. Затем они копируются в раздел данных при первой загрузке.

    Пример использования (в device-common.mk):

    PRODUCT_PACKAGES += \
     cppreopts.sh
PRODUCT_PROPERTY_OVERRIDES += \
     ro.cp_system_other_odex=1

    И в BoardConfig.mk устройства:

    BOARD_USES_SYSTEM_OTHER_ODEX := true

    Обратите внимание, что код загрузочного пути классов, код системного сервера и код основных приложений, относящихся к определенному продукту, всегда компилируются в системный раздел. По умолчанию все остальные приложения компилируются в неиспользуемый второй системный раздел. Это можно контролировать с помощью свойства SYSTEM_OTHER_ODEX_FILTER, которое по умолчанию имеет следующее значение:

    SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%

    Фоновая оптимизация DEX-файлов при обновлении по беспроводной сети

    На устройствах с поддержкой A/B приложения могут компилироваться в фоновом режиме до перезагрузки с новым образом системы. Чтобы включить скрипт компиляции и двоичные файлы в образ системы, ознакомьтесь с разделом Компиляция приложения в фоновом режиме. Фильтр компиляции, используемый для этой компиляции, контролируется с помощью:

    pm.dexopt.ab-ota=speed-profile

    Рекомендуем использовать speed-profile, чтобы воспользоваться преимуществами компиляции на основе профиля и сэкономить место в хранилище.

    Параметры JDWP

    Создание потоков Java Debug Wire Protocol (JDWP) в сборках userdebug контролируется с помощью системного свойства persist.debug.dalvik.vm.jdwp.enabled. По умолчанию это свойство не задано, и потоки JDWP создаются только для приложений, которые можно отлаживать. Чтобы включить потоки JDWP для приложений, доступных и недоступных для отладки, задайте для параметра persist.debug.dalvik.vm.jdwp.enabled значение 1. Чтобы изменения вступили в силу, устройство необходимо перезагрузить.

    Чтобы отладить неотлаживаемое приложение в сборке userdebug, включите JDWP, выполнив следующую команду:

      adb shell setprop persist.debug.dalvik.vm.jdwp.enabled 1
  adb reboot
    На устройствах с Android 13 и более ранних версий среда выполнения создает потоки JDWP для приложений с возможностью отладки и без нее в отладочных сборках. Это означает, что к любой сборке userdebug можно подключить отладчик или профилировщик.