Tempo de execução

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. Um tmpfs é montado em /apex e o tipo de propagação do ponto de montagem é definido como private .
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 inicia apexd 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.

Nota: icu/ também foi reembalado e transformado em uma versão anterior do Android.

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 em libcore/ojluni/src/ , consulte as anotações em libcore/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 com jniGetNio em libnativehelper/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.