Configurar arte

Esta página discute como configurar o Android Runtime (ART) e suas opções de compilação. Os tópicos abordados aqui incluem configuração de pré-compilação da imagem do sistema, opções de compilação dex2oat e como compensar o espaço de partição do sistema, o espaço de partição de dados e o desempenho.

Veja ART e Dalvik e o formato executável Dalvik para trabalhar com ART. Consulte Verificando o comportamento do aplicativo no Android Runtime (ART) para garantir que seus aplicativos funcionem corretamente.

Como funciona a ARTE

ART usa compilação antecipada (AOT) e, a partir do Android 7, usa uma combinação híbrida de compilação AOT, compilação just-in-time (JIT) e interpretação, e a compilação AOT pode ser guiada por perfil. A combinação de todos esses modos de execução é configurável e será discutida nesta seção. Por exemplo, os dispositivos Pixel são configurados para funcionar no seguinte fluxo:

  1. Um aplicativo é inicialmente instalado com um arquivo de metadados dex ( .dm ) distribuído pela Play Store, que contém um perfil de nuvem. ART AOT compila os métodos listados no perfil da nuvem. Ou, se o aplicativo for instalado sem um arquivo de metadados dex, nenhuma compilação AOT será executada.
  2. Nas primeiras vezes que o aplicativo é executado, os métodos que não são compilados pelo AOT são interpretados. Entre os métodos interpretados, aqueles que são frequentemente executados são então compilados em JIT. O ART gera um perfil local com base na execução e o combina com o perfil da nuvem (se existir).
  3. Quando o dispositivo está ocioso e carregando, um daemon de compilação é executado para recompilar o aplicativo com base no perfil combinado gerado durante as primeiras execuções.
  4. Nas execuções subsequentes da aplicação, o ART utiliza os artefatos gerados pelo daemon de compilação, que contêm mais código compilado AOT, em comparação com aqueles que foram gerados durante. Métodos que não são compilados AOT ainda são interpretados ou compilados JIT. O ART atualiza a instalação do perfil, com base na execução, e o perfil será então obtido por execuções subsequentes do daemon de compilação.

ART compreende um compilador (a ferramenta dex2oat ) e um tempo de execução ( libart.so ) que é carregado durante a inicialização. A ferramenta dex2oat pega um arquivo APK e gera um ou mais arquivos de artefato de compilação que o tempo de execução carrega. O número de arquivos, suas extensões e nomes estão sujeitos a alterações entre as versões, mas a partir da versão do Android 8, estes arquivos são gerados:

  • .vdex : contém alguns metadados adicionais para acelerar a verificação, às vezes junto com o código DEX descompactado do APK.
  • .odex : contém código compilado AOT para métodos no APK.
  • .art (optional) contém representações internas ART de algumas strings e classes listadas no APK, usadas para acelerar a inicialização do aplicativo.

Opções de compilação

Existem duas categorias de opções de compilação para ART:

  1. Configuração da ROM do sistema: qual código é compilado pelo AOT ao construir uma imagem do sistema.
  2. Configuração de tempo de execução: como o ART compila e executa aplicativos em um dispositivo.

Filtros do compilador

Uma opção principal do ART para configurar essas duas categorias são os filtros do compilador . Os filtros do compilador orientam como o ART compila o código DEX e é uma opção passada para a ferramenta dex2oat . A partir do Android 8, existem quatro filtros oficialmente suportados:

  • verify : execute apenas a verificação do código DEX (sem compilação AOT).
  • quicken : (até Android 11) execute a verificação do código DEX e otimize algumas instruções DEX para obter melhor desempenho do intérprete.
  • speed : execute a verificação do código DEX e compile AOT todos os métodos.
  • speed-profile : executa a verificação do código DEX e os métodos de compilação AOT listados em um arquivo de perfil.

Configuração da ROM do sistema

Bibliotecas e aplicativos pré-instalados são compilados por AOT quando uma imagem do sistema está sendo construída. Este processo é chamado dexpreopt . Esses arquivos compilados são utilizáveis ​​desde que todas as dependências permaneçam inalteradas, em particular o caminho de classe de inicialização.

Nota: Se o dispositivo receber atualizações do módulo do sistema , é muito provável que o caminho de classe de inicialização mude na próxima atualização, o que torna todos os arquivos dexpreopt obsoletos e inutilizáveis.

Existem várias opções de compilação ART disponíveis para configurar o dexpreopt. A forma como você configura essas opções depende do espaço de armazenamento disponível para a imagem do sistema e do número de aplicativos pré-instalados. Os JARs/APKs compilados em uma ROM do sistema podem ser divididos em quatro categorias:

  • Código do classpath de inicialização: compilado com o filtro do compilador speed-profile por padrão.
  • Código do servidor do sistema (consulte PRODUCT_SYSTEM_SERVER_JARS , PRODUCT_APEX_SYSTEM_SERVER_JARS , PRODUCT_STANDALONE_SYSTEM_SERVER_JARS , PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS posteriormente neste documento):
    • (Android 14 e superior) Compilado com o filtro do compilador speed-profile por padrão ou compilado com o filtro do compilador de speed se um perfil não for fornecido.
    • (Android 13 e inferior) Compilado com o filtro do compilador speed por padrão.
    Configurável através de PRODUCT_SYSTEM_SERVER_COMPILER_FILTER (veja mais adiante neste documento).
  • Aplicativos principais específicos do produto (consulte PRODUCT_DEXPREOPT_SPEED_APPS posteriormente neste documento): compilados com o filtro do compilador speed por padrão.
  • Todos os outros aplicativos: compilados com o filtro do compilador de speed-profile por padrão ou compilados com o filtro do compilador verify se um perfil não for fornecido.

    Configurável através de PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (veja mais adiante neste documento).

Opções de makefile

  • WITH_DEXPREOPT

    • Se dex2oat é invocado no código DEX instalado na imagem do sistema. Habilitado por padrão.

  • DONT_DEXPREOPT_PREBUILTS (Android 5 e superior)

    • Ativar DONT_DEXPREOPT_PREBUILTS evita que os pré-construídos sejam dexpreoptados. Esses são aplicativos que include $(BUILD_PREBUILT) especificados em seu Android.mk . Ignorar o dexpreopt de aplicativos pré-construídos que provavelmente serão atualizados por meio do Google Play economiza espaço na imagem do sistema, mas aumenta o tempo de primeira inicialização. Observe que esta opção não tem efeito em aplicativos pré-construídos definidos em Android.bp .

  • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (Android 9 e superior)

    • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER especifica o filtro do compilador padrão para aplicativos dexpreoptados. Esses aplicativos são definidos em Android.bp ou include $(BUILD_PREBUILT) especificado em seu Android.mk . Se não for especificado, o valor padrão será speed-profile ou verify se o valor não é especificado e um perfil não é fornecido.

  • WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY (desde Android 8 MR1)

    • A ativação WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY dexpreopts apenas o caminho de classe de inicialização e os jars do servidor do sistema.

  • LOCAL_DEX_PREOPT

    • O Dexpreopt também pode ser ativado ou desativado em um aplicativo individual, especificando a opção LOCAL_DEX_PREOPT na definição do módulo. Isso pode ser útil para desativar o dexpreopt de aplicativos que podem receber atualizações imediatas do Google Play, pois as atualizações tornariam obsoleto o código dexpreoptado na imagem do sistema. Isso também é útil para economizar espaço em OTAs de atualização de versão principal, porque os usuários podem já ter versões mais recentes de aplicativos na partição de dados.

    LOCAL_DEX_PREOPT suporta os valores true ou false para ativar ou desativar o dexpreopt, respectivamente. Além disso, nostripping pode ser especificado se o dexpreopt não deve remover o arquivo classes.dex do arquivo APK ou JAR. Normalmente, esse arquivo é removido, pois não é mais necessário após o dexpreopt, mas esta última opção é necessária para permitir que assinaturas APK de terceiros permaneçam válidas.

  • PRODUCT_DEX_PREOPT_BOOT_FLAGS

    • Passa opções para dex2oat para controlar como a imagem de inicialização é compilada. Ele pode ser usado para especificar listas de classes de imagens personalizadas, listas de classes compiladas e filtros do compilador.

  • PRODUCT_DEX_PREOPT_DEFAULT_FLAGS

    • Passa opções para dex2oat para controlar como tudo além da imagem de inicialização é compilado.

  • PRODUCT_DEX_PREOPT_MODULE_CONFIGS

    • Fornece a capacidade de passar opções dex2oat para um módulo específico e configuração de produto. É definido no arquivo device.mk de um produto por $(call add-product-dex-preopt-module-config,<modules>,<option>) onde <modules> é uma lista de nomes LOCAL_MODULE e LOCAL_PACKAGE para arquivos JAR e APK , respectivamente.

  • PRODUCT_DEXPREOPT_SPEED_APPS (desde Android 8)

    • Lista de aplicativos que foram identificados como essenciais para os produtos e que devem ser compilados com o filtro do compilador speed . Por exemplo, aplicativos persistentes como SystemUI têm a chance de usar a compilação guiada por perfil apenas na próxima reinicialização, portanto, pode ser melhor para o produto ter esses aplicativos sempre compilados por AOT.

  • PRODUCT_SYSTEM_SERVER_APPS (desde Android 8)

    • Lista de aplicativos carregados pelo servidor do sistema. Esses aplicativos são compilados por padrão com o filtro do compilador de speed .

  • PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD (desde Android 8)

    • Se deve incluir uma versão de depuração do ART no dispositivo. Por padrão, isso está habilitado para compilações userdebug e eng. O comportamento pode ser substituído definindo explicitamente a opção como true ou false .

    Por padrão, o dispositivo usa a versão não debugada ( libart.so ). Para mudar, defina a propriedade do sistema persist.sys.dalvik.vm.lib.2 como libartd.so .

  • WITH_DEXPREOPT_PIC (até Android 7)

    • No Android 5.1.0 até o Android 6.0.1, WITH_DEXPREOPT_PIC pode ser especificado para ativar o código independente de posição (PIC). Com isso, o código compilado da imagem não precisa ser realocado de /system para /data/dalvik-cache , economizando espaço na partição de dados. No entanto, há um leve impacto no tempo de execução porque desativa uma otimização que aproveita o código dependente da posição. Normalmente, os dispositivos que desejam economizar espaço em /data devem habilitar a compilação PIC.

    No Android 7.0, a compilação PIC estava habilitada por padrão.

  • WITH_DEXPREOPT_BOOT_IMG_ONLY (até Android 7 MR1)

    • Esta opção foi substituída por WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY que também pré-opta os JARs do servidor do sistema.

  • PRODUCT_SYSTEM_SERVER_COMPILER_FILTER

    • Esta opção especifica o filtro do compilador para o servidor do sistema.

    • (Android 14 e superior) Se não for especificado, o filtro do compilador speed-profile será usado ou o filtro do compilador speed será usado se um perfil não for fornecido.
    • (Android 13 e inferior) Se não for especificado, o filtro do compilador de speed será usado.
    • Se definido como speed , o filtro do compilador speed será usado.
    • Se definido como speed-profile , o filtro do compilador speed-profile será usado ou o filtro do compilador verify será usado se um perfil não for fornecido.
    • Se definido como verify , o filtro do compilador verify será usado.

  • PRODUCT_SYSTEM_SERVER_JARS , PRODUCT_APEX_SYSTEM_SERVER_JARS , PRODUCT_STANDALONE_SYSTEM_SERVER_JARS , PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS

    • A seguir estão listas de JARs carregados pelo servidor do sistema. Os JARs são compilados com o filtro do compilador especificado por PRODUCT_SYSTEM_SERVER_COMPILER_FILTER

    • (Obrigatório) PRODUCT_SYSTEM_SERVER_JARS : Lista de JARs de caminho de classe do servidor do sistema na plataforma (ou seja, como parte de SYSTEMSERVERCLASSPATH ). É necessário adicionar JARs do caminho de classe do servidor do sistema a esta lista. A falha ao incluir JARs do caminho de classe do servidor do sistema na lista resulta no não carregamento desses JARs.
    • (Obrigatório) PRODUCT_APEX_SYSTEM_SERVER_JARS : Lista de JARs de caminho de classe do servidor do sistema entregues com APEX (ou seja, como parte de SYSTEMSERVERCLASSPATH ). O formato é <apex name>:<jar name> . É necessário adicionar JARs de caminho de classe do servidor do sistema APEX a esta lista. A falha ao adicionar JARs de caminho de classe do servidor do sistema APEX a esta lista resulta no não carregamento desses JARs.
    • (Opcional, Android 13 e versões anteriores) PRODUCT_STANDALONE_SYSTEM_SERVER_JARS : lista de JARs que o servidor do sistema carrega dinamicamente usando carregadores de classe separados (por meio de SystemServiceManager.startServiceFromJar ). A adição de JARs de servidores de sistema independentes a esta lista não é necessária, mas é altamente recomendada porque torna os JARs compilados e, portanto, tem um bom desempenho de tempo de execução.
    • (obrigatório, desde Android 13) PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS : lista de JARs entregues com APEX que o servidor do sistema carrega dinamicamente usando carregadores de classe separados (ou seja, por meio de SystemServiceManager.startServiceFromJar ou declarados como <apex-system-service> ). O formato é <apex name>:<jar name> . É necessário adicionar JARs de servidor do sistema APEX autônomo a esta lista. A falha ao adicionar JARs do servidor do sistema APEX independente a esta lista resulta em falha de inicialização.

    Configuração do caminho de classe de inicialização

    A lista de classes pré-carregadas é uma lista de classes que o Zygote inicializa na inicialização. Isso evita que cada aplicativo tenha que executar esses inicializadores de classe separadamente, permitindo que eles sejam inicializados mais rapidamente e compartilhem páginas na memória. O arquivo de lista de classes pré-carregadas está localizado em frameworks/base/config/preloaded-classes por padrão e contém uma lista ajustada para uso típico do telefone. Isso pode ser diferente para outros dispositivos, como wearables, e deve ser ajustado de acordo. Tenha cuidado ao ajustar isso; adicionar muitas classes desperdiça memória quando classes não utilizadas são carregadas. Adicionar poucas classes força cada aplicativo a ter sua própria cópia, o que novamente desperdiça memória.

    Exemplo de uso (no produto device.mk ):

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

    Nota: Você deve colocar esta linha antes de herdar quaisquer makefiles de configuração de produto que obtenham o padrão de build/target/product/base.mk .

    Configuração de tempo de execução

    Opções JIT

    As opções a seguir afetam as versões do Android somente onde o compilador ART JIT está disponível.

    • dalvik.vm.usejit : Se o JIT está habilitado ou não.
    • dalvik.vm.jitinitialsize (padrão 64K): A capacidade inicial do cache de código. O cache de código fará GC regularmente e aumentará, se necessário.
    • dalvik.vm.jitmaxsize (padrão 64M): A capacidade máxima do cache de código.
    • dalvik.vm.jitthreshold (padrão 10000): O limite que o contador de "hotness" de um método precisa passar para que o método seja compilado por JIT. O contador "hotness" é uma métrica interna ao tempo de execução. Inclui o número de chamadas, ramificações reversas e outros fatores.
    • dalvik.vm.usejitprofiles (até Android 13): se os perfis JIT estão habilitados ou não; isso pode ser usado mesmo se dalvik.vm.usejit for falso. Observe que se isso for falso, o speed-profile do filtro do compilador não compila AOT nenhum método e é equivalente a verify . Desde o Android 14, os perfis JIT estão sempre ativados e não podem ser desativados.
    • dalvik.vm.jitprithreadweight (padrão para dalvik.vm.jitthreshold / 20): O peso das "amostras" JIT (consulte jitthreshold) para o thread de UI do aplicativo. Use para acelerar a compilação de métodos que afetam diretamente a experiência do usuário ao interagir com o aplicativo.
    • dalvik.vm.jittransitionweight (padrão para dalvik.vm.jitthreshold / 10): O peso da invocação do método que faz a transição entre o código de compilação e o interpretador. Isso ajuda a garantir que os métodos envolvidos sejam compilados para minimizar as transições (que são caras).

    Opções Dex2oat

    Essas opções afetam a compilação no dispositivo (também conhecida como dexopt ), e algumas delas também afetam o dexpreopt, enquanto as opções discutidas na seção de configuração da ROM do sistema acima afetam apenas o dexpreopt.

    Opções para controlar o uso de recursos:

    • dalvik.vm.image-dex2oat-threads / dalvik.vm.image-dex2oat-cpu-set (até Android 11): O número de threads e o conjunto de núcleos de CPU (veja abaixo) a serem usados ​​para imagens de inicialização.
    • dalvik.vm.boot-dex2oat-threads / dalvik.vm.boot-dex2oat-cpu-set :
      • (até Android 11) O número de threads e o conjunto de núcleos de CPU (veja abaixo) a serem usados ​​durante o tempo de inicialização para tudo, exceto imagens de inicialização.
      • (desde Android 12) O número de threads e o conjunto de núcleos de CPU (veja abaixo) para usar durante a inicialização para tudo, incluindo imagens de inicialização.
        • Especificamente, desde o Android 14, isso corresponde à classe de prioridade PRIORITY_BOOT no ART Service.
    • dalvik.vm.restore-dex2oat-threads / dalvik.vm.restore-dex2oat-cpu-set :
      • (desde Android 11 até Android 13) O número de threads e o conjunto de núcleos de CPU (veja abaixo) a serem usados ​​para restaurar do backup na nuvem.
      • (desde Android 14) O número de threads e o conjunto de núcleos de CPU (veja abaixo) a serem usados ​​para tudo que é mais sensível à latência do que o normal, incluindo restauração de backup na nuvem.
        • Especificamente, isto corresponde à classe de prioridade PRIORITY_INTERACTIVE_FAST no ART Service.
    • dalvik.vm.background-dex2oat-threads / dalvik.vm.background-dex2oat-cpu-set (desde Android 14): O número de threads e o conjunto de núcleos de CPU (veja abaixo) para usar em segundo plano.
      • Especificamente, isto corresponde à classe de prioridade PRIORITY_BACKGROUND no ART Service.
    • dalvik.vm.dex2oat-threads / dalvik.vm.dex2oat-cpu-set : O número de threads e o conjunto de núcleos de CPU a serem usados ​​para todo o resto.

    Um conjunto de núcleos de CPU deve ser especificado como uma lista de IDs de CPU separados por vírgulas. Por exemplo, para executar em dex2oat nos núcleos de CPU 0-3, defina:

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

    Ao definir as propriedades de afinidade da CPU, recomendamos combinar a propriedade correspondente para o número de threads dex2oat para corresponder ao número de CPUs selecionadas para evitar memória desnecessária e contenção de E/S:

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

    Além das propriedades do sistema acima, você também pode usar perfis de tarefa para controlar o uso de recursos do dex2oat (consulte Camada de abstração Cgroup ).

    Os perfis de tarefas suportados são:

    • Dex2OatBackground (desde Android 14) (por padrão herda Dex2OatBootComplete ): Controla os recursos a serem usados ​​em segundo plano.
      • Especificamente, isto corresponde à classe de prioridade PRIORITY_BACKGROUND no ART Service.
    • Dex2OatBootComplete :
      • (até Android 13) Controla o recurso a ser usado para tudo após a inicialização.
      • (desde Android 14) Controla o recurso a ser usado para tudo após a inicialização e não em segundo plano.
        • Especificamente, isto corresponde à classe de prioridade PRIORITY_INTERACTIVE_FAST e PRIORITY_INTERACTIVE no ART Service.

    Quando as propriedades do sistema e os perfis de tarefas são especificados, ambos entram em vigor.

    Opções para controlar o tamanho do heap:

    • dalvik.vm.image-dex2oat-Xms : Tamanho de heap inicial para imagens de inicialização.
    • dalvik.vm.image-dex2oat-Xmx : Tamanho máximo de heap para imagens de inicialização.
    • dalvik.vm.dex2oat-Xms : Tamanho de heap inicial para todo o resto.
    • dalvik.vm.dex2oat-Xmx : Tamanho máximo de heap para todo o resto.

    As opções que controlam o tamanho de heap inicial e máximo para dex2oat não devem ser reduzidas, pois podem limitar quais aplicativos podem ser compilados.

    Opções para controlar o filtro do compilador:

    • dalvik.vm.image-dex2oat-filter (até Android 11): O filtro do compilador para imagens de inicialização. Desde o Android 12, o filtro do compilador para imagens de inicialização é sempre speed-profile e não pode ser alterado.
    • dalvik.vm.systemservercompilerfilter (desde Android 13): O filtro do compilador para o servidor do sistema. Consulte PRODUCT_SYSTEM_SERVER_COMPILER_FILTER .
    • dalvik.vm.systemuicompilerfilter (desde Android 13): O filtro do compilador para o pacote System UI.
    • dalvik.vm.dex2oat-filter (até Android 6): O filtro do compilador para todo o resto.
    • pm.dexopt.<reason> (desde Android 7): O filtro do compilador para todo o resto. Consulte Configuração do serviço ART para Android 14 e superior ou Configuração do gerenciador de pacotes para Android 13 e inferior.

    Outras opções para controlar a compilação de tudo que não seja imagens de inicialização:

    • dalvik.vm.dex2oat-very-large (desde Android 7.1): tamanho mínimo total do arquivo dex em bytes para desativar a compilação AOT.
    • dalvik.vm.dex2oat-swap (desde Android 7.1) (padrão: true): Permite usar um arquivo de troca para dex2oat. Isso pode ajudar a evitar falhas de falta de memória. Observe que mesmo que esta opção esteja ativada, o dex2oat usará apenas um arquivo de troca sob certas condições, como quando o número de arquivos dex for grande e as condições estiverem sujeitas a alterações.
    • dalvik.vm.ps-min-first-save-ms (desde Android 12): O tempo mínimo de espera antes que o tempo de execução gere um perfil do aplicativo, na primeira vez que o aplicativo for iniciado.
    • dalvik.vm.ps-min-save-period-ms (desde Android 12): O tempo mínimo de espera antes de atualizar o perfil do aplicativo.
    • dalvik.vm.dex2oat64.enabled (desde Android 11) (padrão: false): se deve usar a versão de 64 bits do dex2oat.
    • dalvik.vm.bgdexopt.new-classes-percent (desde Android 12) (padrão: 20): a porcentagem mínima, entre 0 e 100, de novas classes em um perfil para acionar uma recompilação. Aplicável apenas à compilação guiada por perfil ( speed-profile ), normalmente durante o dexopt em segundo plano. Observe que também há um limite de pelo menos 50 novas classes além do limite percentual, e ele não é configurável.
    • dalvik.vm.bgdexopt.new-methods-percent (desde Android 12) (padrão: 20): a porcentagem mínima, entre 0 e 100, de novos métodos em um perfil para acionar uma recompilação. Aplicável apenas à compilação guiada por perfil ( speed-profile ), normalmente durante o dexopt em segundo plano. Observe que também há um limite de pelo menos 100 novos métodos além do limite percentual e não é configurável.
    • dalvik.vm.dex2oat-max-image-block-size (desde Android 10) (padrão: 524288) Tamanho máximo de bloco sólido para imagens compactadas. Uma imagem grande é dividida em um conjunto de blocos sólidos de forma que nenhum bloco seja maior que o tamanho máximo.
    • dalvik.vm.dex2oat-resolve-startup-strings (desde Android 10) (padrão: true) Se verdadeiro, faz com que dex2oat resolva todas as strings const referenciadas a partir de métodos marcados como "inicialização" no perfil.
    • debug.generate-debug-info (padrão: false) Se deve ou não gerar informações de depuração para depuração nativa, como informações de desenrolamento de pilha, símbolos ELF e seções anãs.
    • dalvik.vm.dex2oat-minidebuginfo (desde Android 9) (padrão: true) Se deve ou não gerar a quantidade mínima de informações de depuração compactadas por LZMA necessárias para imprimir backtraces.

    Opções de serviço ART

    Desde o Android 14, a compilação AOT no dispositivo para aplicativos (também conhecida como dexopt) é feita pelo ART Service. Para obter informações sobre como configurar o Serviço ART, consulte Configuração do Serviço ART .

    Opções do gerenciador de pacotes

    Antes do Android 14, a compilação AOT para aplicativos no dispositivo (também conhecida como dexopt) era feita pelo gerenciador de pacotes. Para obter informações sobre como configurar o gerenciador de pacotes para dexopt, consulte Configuração do gerenciador de pacotes .

    Configuração específica A/B

    Configuração de ROM

    A partir do Android 7.0, os dispositivos podem usar duas partições do sistema para ativar atualizações A/B do sistema . Para economizar no tamanho da partição do sistema, os arquivos pré-optados podem ser instalados na segunda partição do sistema não utilizada. Eles são então copiados para a partição de dados na primeira inicialização.

    Exemplo de uso (em device-common.mk ):

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

    E no BoardConfig.mk do dispositivo:

    BOARD_USES_SYSTEM_OTHER_ODEX := true

    Observe que o código do caminho de classe de inicialização, o código do servidor do sistema e os aplicativos principais específicos do produto sempre são compilados na partição do sistema. Por padrão, todos os outros aplicativos são compilados na segunda partição do sistema não utilizada. Isso pode ser controlado com SYSTEM_OTHER_ODEX_FILTER , que tem um valor padrão de:

    SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%

    Dexopt OTA de fundo

    Em dispositivos habilitados para A/B, os aplicativos podem ser compilados em segundo plano antes da reinicialização com a nova imagem do sistema. Consulte Compilação de aplicativos em segundo plano para incluir opcionalmente o script de compilação e os binários na imagem do sistema. O filtro de compilação usado para esta compilação é controlado com:

    pm.dexopt.ab-ota=speed-profile

    Recomendamos o uso speed-profile para aproveitar as vantagens da compilação guiada por perfil e economizar armazenamento.

    Opções JDWP

    A criação de threads Java Debug Wire Protocol (JDWP) em compilações userdebug é controlada por meio da propriedade de sistema persist.debug.dalvik.vm.jdwp.enabled . Por padrão, essa propriedade não está definida e os threads JDWP são criados apenas para aplicativos depuráveis. Para ativar threads JDWP para aplicativos depuráveis ​​e não depuráveis, defina persist.debug.dalvik.vm.jdwp.enabled como 1 . O dispositivo deve ser reinicializado para que as alterações na propriedade tenham efeito.

    Para depurar um aplicativo não depurável em uma compilação userdebug, habilite o JDWP executando o seguinte comando:

      adb shell setprop persist.debug.dalvik.vm.jdwp.enabled 1
  adb reboot
    Para dispositivos que executam o Android 13 e versões anteriores, o tempo de execução cria threads JDWP para aplicativos depuráveis ​​e não depuráveis ​​em builds userdebug. Isso significa que é possível anexar um depurador ou criar perfil de qualquer aplicativo em compilações userdebug.