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 ambiente de execução do Android (ART) e as opções de compilação. Os tópicos abordados aqui incluem a configuração da pré-compilação da imagem do sistema, as opções de compilação dex2oate como trocar espaço de partição do sistema, espaço de partição de dados e desempenho.

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

Como o ART funciona

O ART usa a 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. A compilação AOT pode ser orientada a 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:

Um aplicativo é instalado inicialmente com um arquivo de metadados dex (.dm) distribuído pela Play Store, que contém um perfil de nuvem. O ART compila antecipadamente 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á realizada.
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 executados com frequência são compilados pelo JIT. O ART gera um perfil local com base na execução e o combina com o perfil da nuvem (se houver um).
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.
Nas execuções subsequentes do aplicativo, o ART usa os artefatos gerados pelo daemon de compilação, que contêm mais código compilado AOT em comparação com os gerados durante os métodos que não são compilados AOT, que ainda são interpretados ou compilados JIT. O ART atualiza a instalação do perfil com base na execução, e o perfil será escolhido por execuções subsequentes do daemon de compilação.

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

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

Opções de compilação

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

Configuração da ROM do sistema: qual código é compilado pelo AOT ao criar uma imagem do sistema.
Configuração 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 é filtros de compilador. Os filtros do compilador determinam como o ART compila o código DEX e são uma opção transmitida à ferramenta dex2oat. A partir do Android 8, há quatro filtros com suporte oficial:

verify: executa apenas a verificação do código DEX (sem compilação AOT).
quicken: (Android 11 ou versões anteriores) executa a verificação do código DEX e otimiza algumas instruções DEX para melhorar o desempenho do interpretador.
speed: executa a verificação do código DEX e compila todos os métodos com AOT. Não otimiza o carregamento de classes.
speed-profile: executa a verificação do código DEX, compila métodos AOT listados no perfil e otimiza o carregamento de classes para as classes no perfil.

Configuração da ROM do sistema

As bibliotecas e os apps pré-instalados são compilados por AOT quando uma imagem do sistema está sendo criada. Esse processo é chamado de dexpreopt. Esses arquivos compilados podem ser usados enquanto todas as dependências permanecem inalteradas, em particular o classpath de inicialização.

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

Há várias opções de build do ART disponíveis para configurar o dexpreopt. A forma de 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 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 e PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS mais adiante neste documento):
- (Android 14 e versões mais recentes) Compilado com o filtro de compilador speed-profile por padrão ou compilado com o filtro de compilador speed se um perfil não for fornecido.
- (Android 13 e versões anteriores) Compilado com o filtro do compilador speed por padrão.
Configurável pelo PRODUCT_SYSTEM_SERVER_COMPILER_FILTER (consulte mais adiante neste documento).
Apps principais específicos do produto (consulte PRODUCT_DEXPREOPT_SPEED_APPS mais adiante neste documento): compilados 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 pelo PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (mais adiante neste documento).

Opções do Makefile

WITH_DEXPREOPT

Indica se 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 dexpreopted. Esses são apps que têm include $(BUILD_PREBUILT) especificado no Android.mk. Ignorar dexpreopt de apps pré-criados que provavelmente serão atualizados pelo Google Play economizará espaço na imagem do sistema, mas aumentará o tempo de 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 versões mais recentes)

PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER especifica o filtro de compilador padrão para aplicativos dexpreopted. Esses apps são definidos em Android.bp ou têm include $(BUILD_PREBUILT) especificado no 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 for fornecido.

WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY (desde o Android 8 MR1)

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

LOCAL_DEX_PREOPT

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

LOCAL_DEX_PREOPT aceita 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 APK ou JAR. Normalmente, esse arquivo é removido, porque não é mais necessário após o dexpreopt, mas essa última opção é necessária para permitir que as assinaturas de APK de terceiros permaneçam válidas.

PRODUCT_DEX_PREOPT_BOOT_FLAGS

Transmite 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

Transmite opções para dex2oat para controlar como tudo, exceto a imagem de inicialização, é compilado.

PRODUCT_DEX_PREOPT_MODULE_CONFIGS

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

PRODUCT_DEXPREOPT_SPEED_APPS (desde o Android 8)

Lista de apps que foram identificados como essenciais para os produtos e que são desejáveis para compilação com o filtro do compilador speed. Por exemplo, apps persistentes, como o SystemUI, têm a chance de usar a compilação guiada por perfil somente na próxima reinicialização. Portanto, talvez seja melhor para o produto que esses apps sejam sempre compilados com 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)

Se é necessário incluir uma versão de depuração do ART no dispositivo. Por padrão, ele é ativado para builds userdebug e eng. Esse comportamento pode ser substituído definindo explicitamente a opção como true ou false.

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

WITH_DEXPREOPT_PIC (até o 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, na sigla em inglês). 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 pequeno impacto no tempo de execução, porque ele desativa uma otimização que aproveita o código dependente da posição. Normalmente, os dispositivos que querem economizar espaço em /data precisam 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)

Essa opção foi substituída por WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY, que também pré-otimiza 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 versões mais recentes) Se não for especificado, o filtro de compilador speed-profile será usado, ou o filtro de compilador speed será usado se um perfil não for fornecido.
(Android 13 e versões anteriores) Se não for especificado, o filtro do compilador 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 é usado, ou o filtro do compilador verify é 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

Confira a seguir as listas de JARs que são carregadas 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 de caminho de classe do servidor do sistema a essa lista. Se você não adicionar JARs de caminho de classe do servidor do sistema à lista, esses JARs não serão carregados.
(Obrigatório) PRODUCT_APEX_SYSTEM_SERVER_JARS: lista de JARs de caminho de classe do servidor do sistema entregues com o 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. Se você não adicionar JARs de caminho de classe do servidor do sistema APEX a essa lista, esses JARs não serão carregados.
(Opcional, Android 13 e versões anteriores) PRODUCT_STANDALONE_SYSTEM_SERVER_JARS: lista de JARs que o servidor do sistema carrega dinamicamente usando classloaders separados (por meio de SystemServiceManager.startServiceFromJar). Adicionar JARs do servidor do sistema independentes a esta lista não é obrigatório, mas é recomendado porque faz com que os JARs sejam compilados e, portanto, tenham uma boa performance de execução.
(obrigatório, desde o Android 13) PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS: lista de JARs enviados com o APEX que o servidor do sistema carrega dinamicamente usando classloaders separados, ou seja, por SystemServiceManager.startServiceFromJar ou declarados como <apex-system-service>. O formato é <apex name>:<jar name>. É necessário adicionar JARs de servidor do sistema APEX independentes a esta lista. A falha na adição de JARs do servidor do sistema APEX independentes a essa lista resulta em falha de inicialização.

Configuração do classpath de inicialização

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

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

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

Observação:é necessário colocar essa linha antes de herdar qualquer makefile de configuração de produto que receba o padrão de 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 somente quando o compilador JIT do ART está disponível.

dalvik.vm.usejit: se o JIT está ativado ou não.
dalvik.vm.jitinitialsize (padrão 64 KB): a capacidade inicial do cache de código. O cache de código vai fazer GC regularmente e aumentar, se necessário.
dalvik.vm.jitmaxsize (padrão de 64 MB): 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 atingir para que o método seja compilado pelo JIT. O contador de "temperatura" é uma métrica interna ao ambiente de execução. Ele inclui o número de chamadas, ramificações para trás e outros fatores.
dalvik.vm.usejitprofiles (até o Android 13): indica se os perfis JIT estão ativados. Esse valor pode ser usado mesmo que dalvik.vm.usejit seja falso. Se esse valor for falso, o filtro do compilador speed-profile não vai compilar nenhum método AOT e será equivalente a verify. Desde o Android 14, os perfis JIT são sempre ativados e não podem ser desativados.
dalvik.vm.jitprithreadweight (padrão dalvik.vm.jitthreshold / 20): o peso das "amostras" do JIT (consulte jitthreshold) para a linha de execução da 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 (padrão para dalvik.vm.jitthreshold / 10): o peso da invocação de método que faz a transição entre o código de compilação e o intérprete. Isso ajuda a garantir que os métodos envolvidos sejam compilados para minimizar as transições (que são caras).

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 da ROM do sistema acima afetam apenas dexpreopt.

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) a serem usados para 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 (consulte abaixo) a serem usados durante a inicialização para tudo, exceto imagens de inicialização.
- (Desde o Android 12) O número de linhas de execução e o conjunto de núcleos de CPU (consulte abaixo) a serem usados durante a inicialização para tudo, incluindo imagens de inicialização.
  - Especificamente, desde o Android 14, isso corresponde à classe de prioridade PRIORITY_BOOT no serviço do 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 (consulte abaixo) a serem usados para restaurar o backup da nuvem.
- (desde o Android 14) O número de linhas de execução e o conjunto de núcleos de CPU (consulte abaixo) a serem usados para tudo o que é mais sensível à latência do que o normal, incluindo a restauração do backup na nuvem.
  - Especificamente, isso corresponde à classe de prioridade PRIORITY_INTERACTIVE_FAST no serviço do ART.
dalvik.vm.background-dex2oat-threads/ dalvik.vm.background-dex2oat-cpu-set (a partir do Android 14): o número de linhas de execução e o conjunto de núcleos de CPU (consulte abaixo) a serem usados em segundo plano.
- Especificamente, isso corresponde à classe de prioridade PRIORITY_BACKGROUND no serviço do 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 tudo o mais.

Um conjunto de núcleos de CPU precisa 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 a 3, defina:

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

Ao definir as propriedades de afinidade de CPU, recomendamos que você corresponda à propriedade correspondente para o número de linhas de execução dex2oat para corresponder ao número de CPUs selecionadas para evitar a contenção de E/S e de memória desnecessária:

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 a Camada de abstração do cgroup).

Os perfis de tarefas com suporte são:

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

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 inicial da pilha para imagens de inicialização.
dalvik.vm.image-dex2oat-Xmx: tamanho máximo do heap para imagens de inicialização.
dalvik.vm.dex2oat-Xms: tamanho inicial do heap para todo o resto.
dalvik.vm.dex2oat-Xmx: tamanho máximo da pilha para todo o restante.

As opções que controlam o tamanho inicial e máximo do heap para dex2oat não podem ser reduzidas, porque elas podem limitar quais 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 filtro compiler para imagens de inicialização é sempre speed-profile e não pode ser alterado.
dalvik.vm.systemservercompilerfilter (a partir do 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 filtro do compilador para todo o restante.
pm.dexopt.<reason> (a partir do Android 7): o filtro do compilador para todo o resto. Consulte Configuração do serviço do ART para o Android 14 e versões mais recentes 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 (a partir do Android 7.1): tamanho mínimo total 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 um arquivo de troca para dex2oat. Isso pode ajudar a evitar falhas de falta de memória. Mesmo que essa opção esteja ativada, o dex2oat só vai 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 mudanças.
dalvik.vm.ps-min-first-save-ms (a partir do Android 12): o tempo mínimo de espera antes que o ambiente de execução gere um perfil do aplicativo na primeira vez que ele é iniciado.
dalvik.vm.ps-min-save-period-ms (a partir do 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): indica 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 nova compilação. Aplicável apenas à compilação guiada por perfil (speed-profile), normalmente durante a dexopt em segundo plano. Há também um limite mínimo de 50 novas classes, além do limite de porcentagem, e ele 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 nova compilação. Aplicável apenas à compilação guiada por perfil (speed-profile), normalmente durante a dexopt em segundo plano. Há também um limite mínimo de 100 novos métodos, além do limite de porcentagem, e ele não é configurável.
dalvik.vm.dex2oat-max-image-block-size (desde o 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 modo que nenhum bloco seja maior que o tamanho máximo.
dalvik.vm.dex2oat-resolve-startup-strings (desde o Android 10) (padrão: true) Se definido como "true", faz com que o dex2oat resolva todas as strings const que são referenciadas em métodos marcados como "startup" no perfil.
debug.generate-debug-info (padrão: false) Indica se é necessário gerar informações de depuração para depuração nativa, como informações de desdobramento de pilha, símbolos ELF e seções de anões.
dalvik.vm.dex2oat-minidebuginfo (desde o Android 9) (padrão: true) Indica se é necessário gerar ou não a quantidade mínima de informações de depuração compactadas por 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 do 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é-selecionados podem ser instalados na segunda partição do sistema não utilizada. Em seguida, 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 classpath de inicialização, o código do servidor do sistema e os apps principais específicos do produto sempre são compilados para a partição do sistema. Por padrão, todos os outros apps são compilados na segunda partição do sistema não utilizada. Isso pode ser controlado com o SYSTEM_OTHER_ODEX_FILTER, que tem um valor padrão de:

SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%

Dexopt OTA em segundo plano

Em dispositivos com A/B ativado, os aplicativos podem ser compilados em segundo plano antes da reinicialização com a nova imagem do sistema. Consulte Compilação de apps 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 essa compilação é controlado com:

pm.dexopt.ab-ota=speed-profile

Recomendamos o uso de speed-profile para aproveitar a compilação guiada por perfil e economizar no armazenamento.

Opções da JDWP

A criação de linhas de execução do protocolo de depuração Java com fio (JDWP, na sigla em inglês) em builds userdebug é controlada pela propriedade do sistema persist.debug.dalvik.vm.jdwp.enabled. Por padrão, essa propriedade não é definida e as linhas de execução do JDWP são criadas apenas para apps depuráveis. Para ativar as linhas de execução JDWP para apps depuráveis e não depuráveis, defina persist.debug.dalvik.vm.jdwp.enabled como 1. O dispositivo precisa ser reinicializado para que as mudanças 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. Ela só permite que um depurador seja anexado ao processo.