O módulo Runtime ( com.android.runtime.release.apex
) é um módulo APEX para tempos de execução Android nativos e gerenciados. O módulo inclui os seguintes componentes:
- ARTE
- Biônico
- Biblioteca central gerenciada (nova no Android 10)
- Bibliotecas ICU
-
libnativebridge
-
libnativehelper
-
libnativeloader
O módulo Runtime é gerado durante a construção do Android e contém os artefatos de construção de seus projetos constituintes. Ele está intimamente ligado ao módulo Conscrypt ( com.android.conscrypt.apex
) e ao módulo Time Zone Data ( com.android.tzdata.apex
), também novo no Android 10.
Alterações do Android Runtime (ART)
No Android 10, o sistema de compilação ART cria o módulo Runtime em duas variantes: release e debug (contém ferramentas adicionais de diagnóstico e depuração). A versão de lançamento é instalada nas compilações do user
e a versão de depuração é instalada nas userdebug
e eng
. Quando um dispositivo é inicializado, o apexd
monta o módulo Runtime em /apex/com.android.runtime
.
No módulo, o caminho da classe de inicialização é dividido entre classes, como Managed Core Library, classes em outros módulos (como Conscrypt e Media) e classes na partição do sistema (como framework.jar
). Se um módulo for atualizado, dex2oat JIT compila classes de inicialização em módulos.
O Android 10 inclui as seguintes alterações de API:
- Uma nova API para suporte de arquivo DEX fornece uma interface estável entre o código do sistema (como o desenrolador de pilha) e o ART.
- Uma nova API é usada como uma camada de abstração de plataforma específica de ART (PAL) com o sistema. O elemento do sistema (
libartpalette-system.so
) expõe a funcionalidade do sistema dependente do ART e é acessível por meio de uma biblioteca cliente (libartpalette.so
), que carrega a biblioteca do sistema instalada no dispositivo.
O Android 10 também refatora caminhos para alguns binários ART, movendo os seguintes binários de /system/bin
para o módulo Runtime: dalvikvm
, dalvikvm32
, dalvikvm64
, dex2oat
, dexdiag
, dexdump
, dexlist
, dexoptanalyzer
, oatdump
e profman
. Para compatibilidade, o refatorador inclui links simbólicos em /system/bin
.
Mudanças biônicas
O tzcode
libc
usa dados de fuso horário fornecidos pelo módulo Runtime ( /apex/com.android.runtime/etc/tz/
) e o módulo Time Zone Data ( /apex/com.android.tzdata/etc/tz/
). tzcode
prioriza dados de atualizações de fuso horário baseadas em APK sobre atualizações de fuso horário baseadas em APEX (fornecidas pelo módulo Time Zone Data) e retorna aos dados de /system
.
libc
usa uma nova biblioteca ( libandroidicu
) em vez de libicuuc
/ libicui18n
. Para obter detalhes, consulte Managed Core Library .
Finalmente, as bibliotecas compartilhadas do Bionic e os caminhos do linker dinâmico agora são links simbólicos (aplica-se também a variantes de 64 bits). Especificamente:
-
/system/lib/libc.so
->/apex/com.android.runtime/lib/bionic/libc.so
-
/system/lib/libm.so
->/apex/com.android.runtime/lib/bionic/libm.so
-
/system/lib/libdl.so
->/apex/com.android.runtime/lib/bionic/libdl.so
-
/system/bin/linker
->/apex/com.android.runtime/bin/linker
Mudanças na sequência de inicialização
Para oferecer suporte ao módulo Runtime, o Android 10 atualiza a sequência de inicialização para o seguinte:
-
init
prepara o bootstrap e os namespaces de montagem padrão. Umtmpfs
é montado em/apex
e o tipo de propagação do ponto de montagem é definido comoprivate
. -
apexd
inicia no modo bootstrap, antes de qualquer outro processo. Ele ativa os arquivos APEX em/system/apex
e os monta no namespace de montagem de bootstrap. - Outros processos pré-
apexd
são iniciados. Esses processos estão no namespace de montagem de bootstrap e são fornecidos com bibliotecas de arquivos APEX do sistema. -
/data
montagens de/data
.init
muda para o namespace de montagem padrão e iniciaapexd
como um daemon. -
apexd
faz a varredura de /data/apex
e/system/apex
e ativa os arquivos APEX mais recentes nesses diretórios. Os arquivos APEX ativados nesta fase são montados apenas nos namespaces padrão e não são visíveis para os processos pré-apexd
.
Biblioteca central gerenciada
A Managed Core Library é uma coleção de código de baixo nível, atualizável e gerenciado ( dex
executado pelo Android Runtime), anteriormente conhecido como libcore . No Android 10, a Managed Core Library inclui vários projetos Git (além de platform/libcore/
), e o novo termo se refere à coleção de código.
A Managed Core Library é fornecida pelos módulos Runtime, Time Zone Data e Conscrypt e depende de bibliotecas nativas presentes no módulo Runtime, como libjavacore
e libandroidicu
. O código coletado vem de vários projetos Git, como libcore
, apache-xml
, boringssl
, bouncycastle
, conscrypt
, expat
, fdlibm
, icu
, okhttp
, ziparchive
e zlib
. A biblioteca é dividida entre vários arquivos .jar
no classpath de inicialização (por exemplo core-oj.jar
, core-libart.jar
, conscrypt.jar
, okhttp.jar
, bouncycastle.jar
e apache-xml.jar
); entretanto, não inclui framework.jar
ou ext.jar
.
Reembalagem de componentes
O Android 10 reempacota vários componentes ( bouncycastle/
, conscrypt/
, okhttp/
) que foram empacotados anteriormente em android.*
E com.android.*
Usando manipulação de bytecode. Esses componentes são reempacotados usando transformação de código-fonte para permitir que anotações Java sejam usadas para metadados API.
API da plataforma principal
A API da plataforma central fornece uma API de código gerenciado estável para uso pela estrutura Android, permitindo que a biblioteca central gerenciada seja atualizada garantindo que todas as dependências da estrutura sejam claramente compreendidas. A API da plataforma principal:
- Indica dependências além das APIs SDK públicas. Para obter o conteúdo da API, consulte
libcore/mmodules/core_platform_api/
. -
@libcore.api.CorePlatformApi
explicitamente o código gerenciado com@libcore.api.CorePlatformApi
. Para obter o código emlibcore/ojluni/src/
, consulte as anotações emlibcore/ojluni/annotations/mmodule/
; para todos os outros projetos, consulte os arquivos de origem principais.
O padrão do sistema de construção é usar a API da plataforma principal ao construir destinos de plataforma de origem Java (ou seja, na ausência de "sdk_version:"
em arquivos .bp
ou "LOCAL_SDK_VERSION="
em arquivos .mk
). Esse padrão garante que o código da estrutura do Android seja restrito ao uso de APIs públicas e da API da plataforma principal (sem classes de implementação). Outros valores de sdk_version
como "core_current"
e "current"
funcionam como sempre (eles permitem o uso de APIs SDK públicas apenas). O sistema de compilação também relata alterações na superfície da API da plataforma principal e evita que os destinos (fora de um pequeno conjunto de exceções) dependam dos componentes internos da biblioteca principal gerenciada.
O módulo Runtime executa verificações de acesso para campos e métodos cobertos pela API da plataforma principal. As verificações são realizadas quando o código da plataforma acessa métodos na API da plataforma principal. A propriedade do sistema persist.debug.dalvik.vm.core_platform_api_policy
controla a política em torno dessas verificações. Os valores de política válidos são enabled
, disabled
e just-warn
. Para builds de depuração e eng, a política padrão é just-warn
, que registra um aviso quando uma violação de política é detectada. Para compilações de usuário, a política padrão é disabled
e nenhuma ação é executada. O módulo Runtime também executa verificações de API da plataforma principal quando o código nativo resolve campos e métodos por meio da Java Native Interface (JNI).
O Android 10 também inclui várias mudanças para simplificar as APIs, dependências de tempo de execução e dependências de tempo de construção entre a estrutura do Android e a Managed Core Library.
O Android 10 reempacota o analisador org.kxml2
em com.android.org.kxml2
.
Bibliotecas nativas
O Android 10 refatora as bibliotecas nativas que oferecem suporte à Managed Core Library. Várias bibliotecas vinculadas dinamicamente (por exemplo, libcrypto
, libexpat
e zlib
) que foram compartilhadas anteriormente com outras partes da plataforma agora estão duplicadas para que o módulo Runtime tenha suas próprias cópias carregadas no namespace do vinculador em tempo de execução. Bibliotecas nativas vinculadas dinamicamente fornecidas pelo módulo Runtime estão em /apex/com.android.runtime/{lib,lib64}
.
Bibliotecas ICU
O módulo Runtime inclui bibliotecas ICU (ICU4C e ICU4J) e dados associados.
O Android 10 inclui libandroidicu
, uma nova biblioteca dinâmica que disponibiliza um subconjunto de funções ICU4C para o código do framework. Os símbolos do vinculador para libandroidicu
são estáveis nas versões ICU (os símbolos terminam com _android
vez de _icu-version-number
usado em libicuuc
e libicui18n
). No entanto, para compatibilidade de aplicativos, libicuuc
e libicui18n
símbolos permanecem disponíveis. Também para compatibilidade de aplicativo, o vinculador redireciona caminhos absolutos para bibliotecas ICU em chamadas dlopen (), ou seja, dlopen("/system/lib/libicuuc.so", ...)
e dlopen("/system/lib/libicui18n.so", ...)
, redirecione para as bibliotecas correspondentes em /apex/com.android.runtime/lib/
para aplicativos com targetSdkVersion < 29
.
No tempo de execução, o arquivo de dados ICU é instalado em /apex/com.android.runtime/etc/icu/
. Para compatibilidade de aplicativos, o Android 10 inclui um link simbólico do local do arquivo de dados ICU anterior ( /system/usr/icu/
) para /apex/com.android.runtime/etc/icu
.
Criptografar interações
O Android 10 move o Conscrypt, que logicamente faz parte da Managed Core Library, para seu próprio módulo APEX atualizável de forma independente. Entre os módulos Conscrypt e Runtime, uma nova superfície de API bidirecional indica dependências além das APIs SDK públicas (para obter detalhes, consulte libcore/mmodules/intracoreapi/
). Os elementos da API são anotados explicitamente com @libcore.api.IntraCoreApi
.
O sistema de construção verifica se o código do Conscrypt está restrito às APIs públicas e à API intra-core. Outras dependências da Managed Core Library no Conscrypt são baseadas em reflexão; o sistema de compilação registra essas dependências onde possível e relata todas as alterações na superfície da API.
Interações de dados de fuso horário
No Android 10, a arquitetura libcore, Runtime libcore e ICU4J / ICU4C usam dados de fuso horário fornecidos pelo módulo Runtime ( /apex/com.android.runtime/etc/tz/
) e o módulo Time Zone Data ( /apex/com.android.tzdata/etc/tz/
). Essas bibliotecas:
- Retorne aos dados de
/system
. - Priorize dados de atualizações de fuso horário baseadas em APK sobre atualizações de fuso horário baseadas em APEX (fornecidas pelo módulo Time Zone Data ).
Mudanças diversas
O Android 10 move a API AsynchronousCloseMonitor
de libnativehelper.so
para libandroidio.so
. A API é exposta por AsynchronousCloseMonitor.h
.
alterações de libnativebridge
O Android 10 move a biblioteca libnativebridge
para o módulo Runtime, já que essa biblioteca é fortemente acoplada ao libnativeloader
e às bibliotecas Bionic C que fazem parte do módulo Runtime.
alterações libnativehelper
No Android 10, o módulo Runtime disponibiliza libnativehelper
para o código do sistema e das estruturas, enquanto o código fora do módulo Runtime se vincula a uma API de stubs (apenas C) para libnativehelper
. A biblioteca libnativehelper
inclui:
- Um conjunto reduzido de classes, métodos e campos JNI em cache.
- Macros JNI aprimoradas em
platform_include/jni_macros.h
. - Novos métodos auxiliares JNI para acessar os internos das classes
java.nio.Buffer
partir do código nativo (consulte os métodos começando comjniGetNio
emlibnativehelper/include/nativehelper/JNIHelp.h
). Esses métodos são usados pelo código da estrutura.
alterações do libnativeloader
No Android 10, o módulo Runtime inclui a biblioteca libnativeloader
, que é responsável por criar namespaces de vinculador para carregadores de classes Java. Os namespaces do vinculador se aplicam às bibliotecas nativas carregadas por aplicativos Android escritos em código gerenciado. A biblioteca está intimamente ligada ao linker Bionic, que também está no módulo.
mudanças libpac
O Android 10 move o libpac
, que fornece uma API C para PacProcessor, para o módulo Runtime. A biblioteca libpac
contém um mecanismo JavaScript V8 inteiro e não deve ser usada, exceto pelo PacProcessor (um pacote e processo independentes).
Mudanças na configuração do linker
No Android 10, os namespaces do vinculador são usados para separar as dependências da biblioteca nativa dinâmica interna no módulo Runtime da plataforma e outros módulos APEX. O namespace do vinculador de runtime
é configurado para bibliotecas de módulo de tempo de execução, com links apropriados para e de outros namespaces para dependências externas.
A configuração do linker reside em /system/etc/ld.config.txt
para binários em /vendor
e /system
, e em /apex/com.android.runtime/etc/ld.config.txt
para binários no próprio módulo Runtime ( /apex/com.android.runtime/bin
).
SystemServer e mudanças na estrutura
No Android 10, o SystemServer hospeda um novo RuntimeService para relatar informações do módulo Runtime. Para visualizar essas informações, use o seguinte comando ADB:
adb shell dumpsys runtimeinfo
As informações gerenciadas pelo RuntimeService são extensíveis. Para obter o código-fonte do serviço, consulte frameworks/base/services/core/java/com/android/server/RuntimeService.java
; por exemplo, código do cliente, consulte libcore/luni/src/main/java/libcore/util/CoreLibraryDebug.java
.
O Android 10 também atualiza o processo de atualização over-the-air (OTA) para usar dex2oat
e outras ferramentas do módulo Runtime.