O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Esta página foi traduzida pela API Cloud Translation.

Configurar ART

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

Consulte ART e Dalvik e o formato executável Dalvik para funcionar com o ART. Consulte Como verificar O comportamento do app no Android Runtime (ART) para garantir que os apps funcionem corretamente.

Como o ART funciona

O ART usa compilação antecipada (AOT, na sigla em inglês) e, a partir do Android 7, ele 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 orientada por perfil. A combinação de todos esses modos de execução configurável e será discutido nesta seção. Por exemplo, os dispositivos Pixel são configurados para siga este fluxo:

Um aplicativo é instalado inicialmente com um arquivo de metadados dex (.dm) distribuído por Play Store, que contém um perfil de nuvem. A ART AOT compila os métodos listados na nuvem perfil. Ou, se o aplicativo for instalado sem um arquivo de metadados dex, nenhuma compilação AOT será realizada.
Nas primeiras vezes que o aplicativo é executado, os métodos que não são compilados AOT são interpretados. Entre os métodos interpretados, aqueles que são executados com frequência são compilados em JIT. ARTE gera um perfil local com base na execução e o combina com o perfil da nuvem (se houver existe).
Quando o dispositivo está inativo e carregando, um daemon de compilação é executado para recompilar o aplicativo. com base no perfil combinado gerado nas primeiras execuções.
Nas execuções subsequentes do aplicativo, o ART usa os artefatos gerados pela compilação. daemon, que contêm mais códigos compilados AOT, comparados aos que foram gerados durante Métodos que não são compilados AOT ainda são interpretados ou compilados em JIT. O ART atualiza o perfil com base na execução, e o perfil será escolhido por execuções subsequentes de o daemon de compilação.

O ART é composto por um compilador (a ferramenta dex2oat) e um ambiente de execução. (libart.so) que é carregado durante a inicialização. A A ferramenta dex2oat usa um arquivo APK e gera um ou mais de artefatos de compilação que o ambiente de execução carrega. O número de arquivos, o tamanho as extensões e os nomes estão sujeitos a mudanças entre as versões, mas, a partir da do Android 8, estes arquivos são gerados:

.vdex: contém alguns metadados adicionais para acelerar a verificação, às vezes junto pelo código DEX descompactado do APK.
.odex: contém código compilado pela AOT para métodos na APK.
.art (optional) contém ART interno de algumas strings e classes listadas no APK, usadas para acelerar inicialização do app.

Opções de compilação

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

Configuração da ROM do sistema: qual código é compilado AOT ao criar um imagem do sistema operacional.
Configuração de tempo de execução: como o ART compila e executa apps em um dispositivo.

Filtros do compilador

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

verify: executa apenas a verificação de código DEX (sem compilação AOT).
quicken: executar código DEX (até o Android 11) verificação e otimizar algumas instruções DEX para obter um melhor desempenho do intérprete.
speed: executa a verificação de código DEX e a compilação AOT de todos os métodos.
speed-profile: executa a verificação de 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 apps pré-instalados são compilados AOT quando uma imagem do sistema está sendo criada. Isso chamado dexpreopt. Esses arquivos compilados são utilizáveis desde que todas as dependências permanecem inalterados, especialmente o caminho de classe da inicialização.

Observação: se o dispositivo usar módulo do sistema for atualizado, o caminho de classe da inicialização será provavelmente mudará na próxima atualização, o que torna todos os arquivos de descontinuação desatualizados e inutilizáveis.

Há várias opções de build do ART disponíveis para configurar o dexpreopt. Como configurar 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 caminho de classe de inicialização: compilado com o filtro do compilador speed-profile por padrão.
Código de servidor do sistema (consulte PRODUCT_SYSTEM_SERVER_JARS, PRODUCT_APEX_SYSTEM_SERVER_JARS, PRODUCT_STANDALONE_SYSTEM_SERVER_JARS PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS mais adiante neste documento):
- (Android 14 e mais recentes) Compilado com o speed-profile. filtro do compilador por padrão ou compilados com o filtro do compilador speed se um perfil não é fornecido.
- (Android 13 e versões anteriores) Compilado com o speed. filtro do compilador por padrão.
. Configurável até PRODUCT_SYSTEM_SERVER_COMPILER_FILTER (mais informações nesta documento).
Principais apps específicos do produto (veja PRODUCT_DEXPREOPT_SPEED_APPS mais adiante neste módulo) document): compilado com o filtro do compilador speed por padrão.
Todos os outros apps: compilados com o filtro do compilador speed-profile por padrão. ou compilados com o filtro do compilador verify se um perfil não for fornecido.
Configurável até PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (confira mais tarde nesta documento).

Opções do makefile

WITH_DEXPREOPT

Define se o dex2oat é invocado no código DEX instalado na imagem do sistema. Ativado por padrão.

DONT_DEXPREOPT_PREBUILTS (Android 5 e mais recentes)

Ativar DONT_DEXPREOPT_PREBUILTS impede que os pré-criados sejam descontinuada. Estes são apps que têm include $(BUILD_PREBUILT) especificado nas Android.mk. Ignorando descontinuação de apps pré-criados que provavelmente serão atualizados pelo Google Play economiza espaço na imagem do sistema, mas aumenta o tempo de primeira inicialização. Essa opção não tem efeito em apps pré-criados definidos em Android.bp.

PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (Android 9) e superiores)

PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER especifica o filtro do compilador padrão. para aplicativos que tiveram o uso suspenso. Esses apps estão definidos em Android.bp ou têm include $(BUILD_PREBUILT) especificado nas Android.mk. Se não for especificado, o valor padrão será speed-profile ou verify se o valor não for especificado e um perfil não é fornecido.

WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY (desde o Android 8 MR1)

A ativação do WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY desativa apenas o o caminho de classe da inicialização e jars do servidor do sistema.

LOCAL_DEX_PREOPT

O expreopt também pode ser ativado ou desativado em cada aplicativo individual especificando a opção LOCAL_DEX_PREOPT na definição do módulo. Isso pode ser útil para desativar a descontinuação de apps que podem receber atualizações do Google Play, já que elas renderizariam o modelo e códigos na imagem do sistema estão obsoletos. Isso também é útil para economizar espaço em atualizações OTA de versão porque os usuários podem já ter versões mais recentes de apps no partição de dados.

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

PRODUCT_DEX_PREOPT_BOOT_FLAGS

Transmite opções para dex2oat a fim de controlar como a imagem de inicialização é compilados. Pode ser usado para especificar listas personalizadas de classes de imagem, compiladas listas de classes e filtros de compilador.

PRODUCT_DEX_PREOPT_DEFAULT_FLAGS

Passa opções para dex2oat para controlar como tudo, além do é compilada.

PRODUCT_DEX_PREOPT_MODULE_CONFIGS

Permite transmitir opções de dex2oat para um determinado e configuração do produto. Ele é definido no conjunto de dados Arquivo device.mk de $(call add-product-dex-preopt-module-config,<modules>,<option>) em que <modules> é uma lista de LOCAL_MODULE e Nomes LOCAL_PACKAGE para arquivos JAR e APK, respectivamente.

PRODUCT_DEXPREOPT_SPEED_APPS (desde o Android 8)

Lista de apps identificados como essenciais para os produtos e que podem ser compilados com o filtro do compilador speed. Para exemplo, apps persistentes, como SystemUI, podem usar compilação guiada por perfil somente na próxima reinicialização, então pode ser melhor para a para que esses apps sejam sempre compilados AOT.

PRODUCT_SYSTEM_SERVER_APPS (desde o Android 8)

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

PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD (desde o Android 8)

Define se uma versão de depuração do ART será incluída no dispositivo. Por padrão, é ativada para builds userdebug e eng. O comportamento pode ser substituído por definindo a opção como true ou false.

Por padrão, o dispositivo usa a versão que não é de depuração (libart.so). Para alternar, defina a propriedade do sistema persist.sys.dalvik.vm.lib.2 como libartd.so

WITH_DEXPREOPT_PIC (até o Android 7)

Do Android 5.1.0 ao 6.0.1, a WITH_DEXPREOPT_PIC pode ser especificada para ativar o código independente de posição (PIC, na sigla em inglês). Com isso, compilados da imagem não precisa ser reposicionado /system em /data/dalvik-cache, economizando espaço na partição de dados. No entanto, há um pequeno impacto no tempo de execução, porque desativa uma otimização que aproveita de código que depende da posição. Normalmente, dispositivos que querem economizar espaço no /data deve ativar a compilação de PIC.

No Android 7.0, a compilação de PIC era ativada por padrão.

WITH_DEXPREOPT_BOOT_IMG_ONLY (até o 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

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

(Android 14 e versões mais recentes) Se não for especificada, a speed-profile o filtro do compilador é usado ou o filtro do compilador speed é usado se um perfil não for fornecidas.
(Android 13 e versões anteriores) Se não for especificado, o compilador speed é usado.
Se definido como speed, o filtro do compilador speed vai ser usado.
Se definido como speed-profile, o filtro do compilador speed-profile vai ser usado. ou o filtro do compilador verify vai ser usado se um perfil não for fornecido.
Se definido como verify, o filtro do compilador verify vai ser usado.

PRODUCT_SYSTEM_SERVER_JARS, PRODUCT_APEX_SYSTEM_SERVER_JARS. PRODUCT_STANDALONE_SYSTEM_SERVER_JARS, PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS

Veja a seguir listas de JARs que são 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 do caminho de classe do servidor do sistema ativados a plataforma, ou seja, como parte de SYSTEMSERVERCLASSPATH. Adicionando servidor do sistema Os JARs de caminho de classe dessa lista são obrigatórios. Falha ao adicionar JARs do caminho de classe do servidor do sistema à lista faz com que esses JARs não sejam carregados.
(Obrigatório) PRODUCT_APEX_SYSTEM_SERVER_JARS: lista de JARs do caminho de classe do servidor do sistema entregue com APEX (ou seja, como parte de SYSTEMSERVERCLASSPATH). O formato é <apex name>:<jar name> Adicionar JARs do caminho de classe do servidor do sistema APEX ao esta lista é obrigatória. A falha em adicionar JARs do caminho de classe do servidor do sistema APEX a esta lista resulta em esses JARs não sejam carregados.
(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 SystemServiceManager.startServiceFromJar). Adicionar JARs do servidor do sistema autônomos essa lista não é necessária, mas é altamente recomendada porque ela torna os JARs compilados e tenham um bom desempenho de execução.
(obrigatório, desde o 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 (que usando SystemServiceManager.startServiceFromJar ou declarados como <apex-system-service>). O formato é <apex name>:<jar name>. Adicionando JARs autônomos do servidor do sistema APEX ao esta lista é obrigatória. A falha em adicionar JARs autônomos do servidor do sistema APEX a esta lista resulta em falha na inicialização.

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

A lista de classes pré-carregadas é uma lista de classes em que o Zigoto inicializa inicialização. Isso evita que cada aplicativo tenha que executar esses inicializadores de classe. separadamente, permitindo que elas iniciem mais rapidamente e compartilhem páginas na memória. A o arquivo da lista de classes pré-carregadas está localizado em frameworks/base/config/preloaded-classes por padrão e contém uma lista ajustada para o uso típico de telefones. Isso pode ser diferente para outros dispositivos, como wearables, e devem ser ajustados de maneira adequada. Cuidado ao fazer esse ajuste. adicionar muitas classes desperdiças na memória quando classes não usadas são carregadas. Adicionar poucas classes força cada app a precisa ter a própria cópia, o que desperdiça memória.

Exemplo de uso (no device.mk do produto):

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

Observação: você deve colocar esta linha antes herdarem makefiles de configuração de produto que recebam o padrão build/target/product/base.mk

Configuração do ambiente de execução

Opções de JIT

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

dalvik.vm.usejit: se o JIT está ativado ou não.
dalvik.vm.jitinitialsize (padrão 64K): a capacidade inicial do cache de código. O cache de código vai coletar dados 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 10.000): O limite em que a temperatura de um método precisa passar para para o método ser compilado em JIT. A "quente calor" é uma métrica interna ao ambiente de execução. Inclui o número de chamadas, ramificações inversas e outros fatores
dalvik.vm.usejitprofiles (até o Android 13): se ou e não os perfis JIT estão ativados. ela poderá ser usada mesmo que dalvik.vm.usejit seja falso. Se esse valor for falso, o filtro do compilador speed-profile fará não faz compilação AOT de nenhum método e é equivalente a verify. Como No Android 14, os perfis JIT estão sempre ativados e não podem ser desativados.
dalvik.vm.jitprithreadweight (o padrão é dalvik.vm.jitthreshold / 20): o peso das "amostras" do JIT (consulte jitthreshold) para o thread de interface do aplicativo. Use para acelerar a compilação de métodos que afetam diretamente a experiência dos usuários ao interagir com o app.
dalvik.vm.jittransitionweight (o padrão é dalvik.vm.jitthreshold / 10): O peso do método que transita entre o código de compilação e o intérprete. Isso ajuda os métodos envolvidos são compilados para minimizar as transições (que são caro).

Opções do Dex2oat

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

Opções para controlar o uso de recursos:

dalvik.vm.image-dex2oat-threads/dalvik.vm.image-dex2oat-cpu-set (até o Android 11): o número de linhas de execução e o conjunto de núcleos de CPU. Consulte abaixo) para usar nas imagens de inicialização.
dalvik.vm.boot-dex2oat-threads/dalvik.vm.boot-dex2oat-cpu-set:
- (até o Android 11) O número de linhas de execução e o conjunto de núcleos de CPU (veja abaixo) para usar durante o tempo de inicialização para tudo menos as imagens de inicialização.
- (desde o Android 12) O número de linhas de execução e o conjunto de núcleos de CPU (confira abaixo) para usar durante o tempo de inicialização para tudo, inclusive imagens de inicialização.
  - Especificamente, desde o Android 14, isso corresponde ao classe de prioridade PRIORITY_BOOT no serviço ART.
dalvik.vm.restore-dex2oat-threads/dalvik.vm.restore-dex2oat-cpu-set:
- (desde o Android 11 até o Android 13) O número de linhas de execução e o conjunto de núcleos de CPU (confira abaixo) a serem usados para restaurar da nuvem backup.
- (desde o Android 14) O número de linhas de execução e o conjunto de núcleos de CPU (veja abaixo) para usar para tudo o que é mais sensível à latência do que o normal, incluindo a partir do backup na nuvem.
  - Especificamente, corresponde à classe de prioridade PRIORITY_INTERACTIVE_FAST no serviço ART.
dalvik.vm.background-dex2oat-threads/ dalvik.vm.background-dex2oat-cpu-set (desde o Android 14): o número de linhas de execução e o conjunto de núcleos de CPU. Consulte abaixo) para usar em segundo plano.
- Especificamente, ela corresponde à classe de prioridade PRIORITY_BACKGROUND em Serviço ART.
dalvik.vm.dex2oat-threads/dalvik.vm.dex2oat-cpu-set: O número de linhas de execução e o conjunto de núcleos de CPU a serem usados para todo o restante.

Um conjunto de núcleos de CPU precisa ser especificado como uma lista de IDs de CPU separada por vírgulas. Por exemplo, para executar no 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 fazer a correspondência da propriedade correspondente para o número de linhas de execução dex2oat para corresponder ao número de CPUs selecionadas para evitar memória e E/S desnecessárias contenção:

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

Além das propriedades do sistema acima, também é possível usar perfis de tarefas para controlar o uso de recursos do dex2oat (consulte Camada de abstração Cgroup).

Os perfis de tarefas compatíveis são:

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

Quando as propriedades do sistema e os perfis de tarefa são especificados, ambos têm efeito.

Opções para controlar o tamanho da 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 restante.
dalvik.vm.dex2oat-Xmx: tamanho máximo de heap para todo o restante.

As opções que controlam o tamanho de heap inicial e máximo para dex2oat não deve ser reduzido, porque pode limitar o que aplicativos podem ser compilados.

Opções para controlar o filtro do compilador:

dalvik.vm.image-dex2oat-filter (até o Android 11): O filtro do compilador para imagens de inicialização. Desde o Android 12, o compilador o filtro de imagens de inicialização é sempre speed-profile e não pode ser alterado.
dalvik.vm.systemservercompilerfilter (desde o Android 13): O filtro do compilador para o servidor do sistema. Consulte PRODUCT_SYSTEM_SERVER_COMPILER_FILTER.
dalvik.vm.systemuicompilerfilter (desde o Android 13): O filtro do compilador para o pacote da interface do sistema.
dalvik.vm.dex2oat-filter (até o Android 6): O compilador filtra todo o restante.
pm.dexopt.<reason> (desde o Android 7): O compilador filtra todo o restante. Consulte Configurações de serviço ART para Android 14 e superior ou Configuração do Gerenciador de Pacotes para Android 13 e versões anteriores.

Outras opções para controlar a compilação de tudo, exceto imagens de inicialização:

dalvik.vm.dex2oat-very-large (desde o Android 7.1): tamanho total mínimo do arquivo dex em bytes para desativar a compilação AOT.
dalvik.vm.dex2oat-swap (desde o Android 7.1) (padrão: true): permite usar uma troca. para dex2oat. Isso pode ajudar a evitar falhas de falta de memória. Mesmo que essa opção seja ativado, o dex2oat só usará um arquivo de troca em determinadas condições, como quando o número de arquivos dex é grande e as condições estão sujeitas a alterações.
dalvik.vm.ps-min-first-save-ms (desde o Android 12): o tempo mínimo de espera antes que o ambiente de execução gere um perfil do aplicativo, pela primeira vez o aplicativo é iniciado.
dalvik.vm.ps-min-save-period-ms (desde o Android 12): o tempo mínimo de espera antes de atualizar o perfil do aplicativo.
dalvik.vm.dex2oat64.enabled (desde o Android 11) (padrão: false): Define se a versão de 64 bits do dex2oat será usada.
dalvik.vm.bgdexopt.new-classes-percent (desde o 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 dexopt em segundo plano. Também há um limite de pelo menos 50 novas classes, além de o limite percentual e não é configurável.
dalvik.vm.bgdexopt.new-methods-percent (desde o 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 dexopt em segundo plano. Também há um limite de pelo menos 100 novos métodos, além de ao limite percentual e não será configurável.
dalvik.vm.dex2oat-max-image-block-size (desde o Android 10) (padrão: 524288) Tamanho máximo do bloco sólido para imagens compactadas. Uma imagem grande é dividida em um conjunto de blocos de modo que nenhum bloco seja maior que o tamanho máximo.
dalvik.vm.dex2oat-resolve-startup-strings (desde o Android 10) (padrão: verdadeiro) Se verdadeiro, faz com que dex2oat resolva todas as const-strings referenciadas em métodos marcados como “inicialização” no perfil.
debug.generate-debug-info (padrão: falso) Se as informações de depuração devem ser geradas ou não para depuração nativa, como liberação de pilha informações de objetos, símbolos de ELF e seções de anões.
dalvik.vm.dex2oat-minidebuginfo (desde o Android 9) (padrão: true) Gerar ou não uma quantidade mínima de informações de depuração comprimidas em LZMA necessárias para imprimir backtraces.

Opções de serviço do ART

Configuração do serviço ART

Opções do gerenciador de pacotes

Configuração do gerenciador de pacotes

Configuração específica A/B

Configuração da ROM

A partir do Android 7.0, os dispositivos podem usar duas partições do sistema para ativar Atualizações do sistema A/B. Para economizar no tamanho da partição do sistema, os arquivos pré-aprovados podem ser instalados em a segunda partição do sistema não utilizada. Eles sã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

O código do caminho de classe de inicialização, o código do servidor do sistema e o código do os apps sempre são compilados na partição do sistema. Por padrão, todos os outros os apps são compilados para a segunda partição do sistema não utilizada. Isso pode ser controlado por SYSTEM_OTHER_ODEX_FILTER, que tem um valor de padrão de:

SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%

Dexopt OTA em segundo plano

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

pm.dexopt.ab-ota=speed-profile

Recomendamos o uso de speed-profile para aproveitar as vantagens das orientações por perfil compilação e economizar espaço de armazenamento.

Opções do JDWP

A criação de encadeamentos do protocolo de depuração Java com fio (JDWP, na sigla em inglês) em builds userdebug é controlada pelo persist.debug.dalvik.vm.jdwp.enabled. Por padrão, essa propriedade não está definida e as linhas de execução JDWP são criadas apenas para aplicativos depuráveis. Para ativar as linhas de execução JDWP para ambos apps depuráveis e não depuráveis, defina persist.debug.dalvik.vm.jdwp.enabled. para 1. O dispositivo precisa ser reiniciado para que as alterações na propriedade entrem em vigor.

Para depurar um app não depurável em um build userdebug, ative o JDWP executando o seguinte: comando:

  adb shell setprop persist.debug.dalvik.vm.jdwp.enabled 1
  adb reboot

Observação:definir a propriedade persist.debug.dalvik.vm.jdwp.enabled como 1 não torna os apps depuráveis, só permite que um depurador seja anexado ao de desenvolvimento de software.