Настроить АРТ

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

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

Как работает АРТ

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

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

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

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

Варианты компиляции

Существует две категории вариантов компиляции ART:

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

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

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

  • verify : запускать только проверку кода DEX (без компиляции AOT).
  • quicken : (до Android 11) запустите проверку кода DEX и оптимизируйте некоторые инструкции DEX, чтобы повысить производительность интерпретатора.
  • speed : запустить проверку кода DEX и AOT-компилировать все методы.
  • speed-profile : Запустите проверку кода DEX и методы компиляции AOT, перечисленные в файле профиля.

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

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

Примечание. Если устройство получает обновления системного модуля , то путь к классам загрузки, скорее всего, изменится в следующем обновлении, в результате чего все файлы 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 предотвращает декспреоптацию готовых сборок. Это приложения, в которых include $(BUILD_PREBUILT) в их Android.mk . Пропуск 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, поскольку обновления сделают код dexpreopt в образе системы устаревшим. Это также полезно для экономии места при обновлении основных версий 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-файлы пути к классам системного сервера в список, эти JAR-файлы не будут загружены.
    • (Обязательно) PRODUCT_APEX_SYSTEM_SERVER_JARS : список JAR-файлов пути к классам системного сервера, поставляемых с APEX (то есть как часть SYSTEMSERVERCLASSPATH ). Формат: <apex name>:<jar name> . Добавление JAR-файлов пути к классам системного сервера APEX в этот список является обязательным. Если не добавить JAR-файлы пути к классам системного сервера APEX в этот список, эти JAR-файлы не будут загружены.
    • (Необязательно, 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
    

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

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

    JIT-варианты

    Следующие параметры влияют только на выпуски Android, в которых доступен компилятор ART JIT.

    • dalvik.vm.usejit : включен или нет JIT.
    • dalvik.vm.jitinitialsize (по умолчанию 64 КБ): начальная емкость кэша кода. Кэш кода будет регулярно GC и увеличиваться при необходимости.
    • dalvik.vm.jitmaxsize (по умолчанию 64 МБ): максимальная емкость кэша кода.
    • dalvik.vm.jitthreshold (по умолчанию 10000): Порог, который должен пройти счетчик «жаркости» метода, чтобы метод мог быть скомпилирован JIT. Счетчик «жаркости» — это метрика, внутренняя для среды выполнения. Он включает в себя количество вызовов, обратных ветвей и другие факторы.
    • dalvik.vm.usejitprofiles (до Android 13): включены или нет профили JIT; это можно использовать, даже если dalvik.vm.usejit имеет значение false. Обратите внимание: если это значение неверно, speed-profile фильтра компилятора не компилирует AOT ни одного метода и эквивалентен verify . Начиная с Android 14, профили JIT всегда включены и не могут быть отключены.
    • dalvik.vm.jitprithreadweight (по умолчанию dalvik.vm.jitthreshold / 20): вес «выборок» JIT (см. jitthreshold) для потока пользовательского интерфейса приложения. Используйте для ускорения компиляции методов, которые напрямую влияют на взаимодействие пользователей с приложением.
    • 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.
    • dalvik.vm.restore-dex2oat-threads / dalvik.vm.restore-dex2oat-cpu-set :
      • (начиная с Android 11 до Android 13) Количество потоков и набор ядер ЦП (см. ниже), которые будут использоваться для восстановления из облачной резервной копии.
      • (начиная с Android 14) Количество потоков и набор ядер ЦП (см. ниже), которые будут использоваться для всего, что более чувствительно к задержке, чем обычно, включая восстановление из облачной резервной копии.
        • В частности, это соответствует классу приоритета PRIORITY_INTERACTIVE_FAST в ART Service.
    • 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 с количеством выбранных ЦП, чтобы избежать ненужной памяти и конфликтов ввода-вывода:

    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 Service.

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

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

    • 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 ), обычно во время фоновой dexopt. Обратите внимание, что помимо процентного порога существует также пороговое значение не менее 50 новых классов, и его нельзя настроить.
    • dalvik.vm.bgdexopt.new-methods-percent (начиная с Android 12) (по умолчанию: 20): минимальный процент от 0 до 100 новых методов в профиле для запуска перекомпиляции. Применимо только к компиляции на основе профиля ( speed-profile ), обычно во время фоновой dexopt. Обратите внимание, что помимо процентного порога существует также пороговое значение не менее 100 новых методов, и его нельзя настроить.
    • dalvik.vm.dex2oat-max-image-block-size (начиная с Android 10) (по умолчанию: 524288) Максимальный размер сплошного блока для сжатых изображений. Большое изображение разбивается на набор сплошных блоков, так что ни один блок не превышает максимальный размер.
    • dalvik.vm.dex2oat-resolve-startup-strings (начиная с Android 10) (по умолчанию: true). Если true, dex2oat разрешает все константные строки, на которые ссылаются методы, помеченные в профиле как «запуск».
    • debug.generate-debug-info (по умолчанию: false) Следует ли генерировать отладочную информацию для собственной отладки, такую ​​как информация о развертывании стека, символы ELF и карликовые разделы.
    • dalvik.vm.dex2oat-minidebuginfo (начиная с Android 9) (по умолчанию: true) Определяет, генерировать ли минимальный объем отладочной информации, сжатой LZMA, необходимой для печати обратных трассировок.

    Варианты обслуживания АРТ

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

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

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

    Специальная конфигурация A/B

    Конфигурация ПЗУ

    Начиная с 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/%
    

    Фоновый OTA-дексопт

    На устройствах с поддержкой 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 можно подключить отладчик или профилировать любое приложение.