Notas de versão do Android 9

Esta página resume os principais recursos da versão Android 9 e fornece links para informações adicionais. Esses resumos de recursos são organizados de acordo com a localização da documentação do recurso neste site. Consulte as atualizações do site de agosto de 2018 para obter um guia sobre movimentação e renomeação de seções.

Construir

Imagem genérica do sistema (GSI)

Uma imagem genérica do sistema (GSI) é uma imagem do sistema com configurações ajustadas para dispositivos Android. A imagem genérica do sistema (GSI) inclui detalhes sobre as diferenças entre GSIs para dispositivos lançados com Android 9 e dispositivos atualizados para Android 9.

Arquitetura

Camada de abstração de hardware (HAL)

Compatibilidade com versões anteriores da estrutura HIDL

A verificação de compatibilidade com versões anteriores da estrutura HIDL é um método para verificar a compatibilidade com versões anteriores da estrutura.

HALs disponíveis dinamicamente

HALs disponíveis dinamicamente suportam o desligamento dinâmico de subsistemas de hardware Android quando eles não estão em uso ou não são necessários.

HIDL

Bloco de memória HIDL

HIDL MemoryBlock é uma camada abstrata construída em hidl_memory , HIDL @1.0::IAllocator e HIDL @1.0::IMapper . Ele foi projetado para serviços HIDL que possuem vários blocos de memória compartilhando um único heap de memória.

Sobreposições de árvore de dispositivos

Sobreposições compactadas

O Android 9 e versões posteriores incluem suporte para sobreposições compactadas na imagem de sobreposição de blob de árvore de dispositivos (DTBO) ao usar a versão 1 do cabeçalho da tabela de árvore de dispositivos.

Atualizações de DTO

O Android 9 e versões posteriores exigem que o carregador de inicialização passe o blob da árvore de dispositivos unificados para o kernel antes de modificar as propriedades definidas nas sobreposições de árvore de dispositivos (DTOs) .

Versionamento de cabeçalho de imagem DTBO

O Android 9 e versões posteriores incluem um campo de versão no cabeçalho da imagem DTBO.

Verificação DTBO

O Android 9 e superior requer uma partição DTBO. Para adicionar nós ou fazer alterações nas propriedades no SoC DT, o bootloader deve sobrepor dinamicamente um DT específico do dispositivo sobre o SoC DT. Para obter mais informações, consulte Compilando e verificando .

Conformidade do kernel

O Android 9 e versões posteriores incluem requisitos que afetam o kernel, suas interfaces e o uso de DTBOs. Para obter mais informações, consulte estas páginas:

Fornecedor NDK

Alterações de design

Para obter informações sobre alterações de design do VNDK no Android 9 e versões posteriores, consulte estas páginas:

Verificador de ABI

A página Estabilidade da ABI descreve o verificador da interface binária do aplicativo (ABI), que garante que as alterações feitas nas bibliotecas VNDK mantenham a conformidade com a ABI.

Instantâneos VNDK

Uma imagem do sistema pode usar snapshots do VNDK para fornecer as bibliotecas VNDK corretas para imagens do fornecedor, mesmo quando as imagens do sistema e do fornecedor são criadas a partir de versões diferentes do Android.

Objeto de interface do fornecedor (objeto VINTF)

As páginas a seguir na seção Objeto de interface do fornecedor descrevem atualizações no Android 9 e versões posteriores:

Cronograma de descontinuação do HIDL

As páginas a seguir descrevem como o Android descontinua e remove HALs HIDL:

Carregador de inicialização

Partições de produto

O Android 9 e superior oferece suporte à criação de partições /product usando o sistema de compilação do Android. Anteriormente, o Android 8.x impunha a separação de componentes específicos do sistema no chip (SoC) da partição /system para a partição /vendor sem dedicar espaço para componentes específicos do OEM criados a partir do sistema de compilação do Android.

Conformidade com o motivo da inicialização canônica

A página Canonical Boot Reason descreve alterações na especificação do motivo de inicialização do bootloader no Android 9 e versões posteriores.

Sistema como root

Todos os dispositivos lançados com Android 9 e superior devem usar system-as-root , que mescla ramdisk.img em system.img (também conhecido como no-ramdisk), que por sua vez é montado como rootfs.

Controle de versão do cabeçalho da imagem de inicialização

No Android 9 e versões posteriores, o cabeçalho da imagem de inicialização contém um campo para indicar a versão do cabeçalho . O bootloader deve verificar este campo de versão e analisar o cabeçalho de acordo.

DTBO em recuperação

Para evitar falhas OTA devido a incompatibilidades entre a imagem de recuperação e a partição DTBO em dispositivos não A/B, a imagem de recuperação deve conter informações da imagem DTBO .

Mostrar

Exibir recortes

Os recortes de exibição permitem que os desenvolvedores de aplicativos criem experiências imersivas de ponta a ponta, ao mesmo tempo que permitem espaço para sensores importantes na parte frontal dos dispositivos.

Alternar sugestões

As atualizações no comportamento de rotação da tela do Android 9 e superior incluem suporte para um controle voltado ao usuário para fixar a rotação da tela em paisagem ou retrato, mesmo se a posição do dispositivo mudar.

Transições de aplicativos sincronizadas

As transições sincronizadas de aplicativos permitem novas animações de transição de aplicativos.

Classificação de texto (anteriormente TEXTCLASSIFIER)

O Android 9 e versões posteriores incluem um serviço Text Classifier , que é a maneira recomendada de implementar a classificação de texto, e uma implementação de serviço padrão.

Ampla gama de cores

O Android 9 e superior inclui suporte para ampla gama de cores, incluindo:

  • Alta faixa dinâmica (HDR)
  • Processamento de conteúdo no espaço de cores BT2020, mas não como um espaço de dados de destino final

Para usar cores de ampla gama, a pilha completa de exibição de um dispositivo (como tela, compositor de hardware, GPU) deve suportar cores de ampla gama ou formatos de buffer. Os dispositivos não são obrigados a reivindicar suporte para conteúdo de ampla gama, mesmo que o hardware o suporte. No entanto, a ampla gama de cores deve ser habilitada para aproveitar ao máximo o hardware. Para evitar uma experiência visual inconsistente, a ampla gama de cores não deve ser desativada durante o tempo de execução.

Compatibilidade

Documento de definição de compatibilidade do Android

O Documento de definição de compatibilidade do Android 9 (CDD) repete versões anteriores com atualizações para novos recursos e alterações nos requisitos para funcionalidades lançadas anteriormente.

Configurações

Melhores widgets de aplicativos

A estrutura de widget de aplicativo Android oferece maior visibilidade nas interações do usuário, especificamente quando um usuário exclui ou adiciona widgets manualmente. Esta funcionalidade vem por padrão com o Launcher3.

Os fabricantes precisam atualizar seus aplicativos de inicialização (que são fornecidos com os dispositivos) para oferecer suporte a esse recurso, caso não sejam baseados no Launcher3. Os OEMs precisam oferecer suporte ao novo campo widgetFeatures em seu inicializador padrão.

Observe que o recurso só funciona de ponta a ponta quando os inicializadores o implementam conforme o esperado. AOSP inclui um exemplo de implementação. Consulte o ID de alteração AOSP Iccd6f965fa3d61992244a365efc242122292c0ca para obter o código de exemplo fornecido.

Notificações de alteração de estado do dispositivo para instaladores de pacotes

Uma transmissão protegida do sistema pode ser enviada para aplicativos que possuem a permissão INSTALL_PACKAGES sempre que houver uma alteração em propriedades como localidade ou densidade de exibição. Os receptores podem ser cadastrados no manifesto e um processo é despertado para receber a transmissão. Isso é útil para instaladores de pacotes que desejam instalar componentes adicionais de aplicativos após tais alterações, o que é incomum, porque as alterações de configuração elegíveis para acionar esta transmissão são raras.

O código-fonte da notificação de alteração de estado do dispositivo está localizado nos seguintes locais em platform/frameworks/base :

  • api/system-current.txt
  • core/java/android/content/Intent.java
  • core/res/AndroidManifest.xml
  • services/core/java/com/android/server/am/ActivityManagerService.java

Arquitetura de informação

As alterações na arquitetura de informações do aplicativo Configurações fornecem mais funcionalidades e implementação mais fácil.

Testes

Um teste

A ferramenta de linha de comando Atest permite que você crie, instale e execute testes do Android localmente, acelerando bastante as reexecuções de testes sem exigir conhecimento das opções de linha de comando do equipamento de teste da Federação de Comércio.

Conjunto de testes de compatibilidade

Downloads de CTS

Os pacotes Compatibility Test Suite (CTS) compatíveis com Android 9 estão disponíveis na página de downloads do CTS . O código-fonte dos testes incluídos pode ser sincronizado com a tag android-cts-9.0_r1 na árvore de código aberto.

Opções CTS

Para Android 9, o CTS v2 ganha o seguinte comando e argumento :

  • run retry tenta novamente todos os testes que falharam ou não foram executados nas sessões anteriores.
  • '--shard-count fragmenta um CTS executado em um determinado número de blocos independentes, para ser executado em vários dispositivos em paralelo.

Além disso, o comando --retry-type anteriormente não documentado, foi adicionado à mesma referência de comando do console CTS v2.

Serviço de Elemento Seguro (SE)

O serviço Secure Element verifica elementos seguros suportados pela plataforma global, identificando se os dispositivos têm uma implementação SE HAL e, em caso afirmativo, quantos. Isso é usado como base para testar a API e a implementação do elemento seguro subjacente.

Caixa de fusão de sensores

A caixa de fusão de sensores é usada no teste de fusão de sensores do Camera Image Test Suite (Camera ITS) e no teste de sincronização de várias câmeras e fornece um ambiente de teste consistente para medir a precisão do carimbo de data/hora da câmera e de outros sensores para telefones Android. Consulte estas páginas para obter mais informações:

Amplo campo de visão ITS-in-a-box

O amplo campo de visão ITS-in-a-box é um sistema automatizado projetado para testar sistemas de câmeras de amplo campo de visão (WFoV) e de campo de visão regular (RFoV) no Camera ITS.

Conjunto de testes de fornecedores

Arquitetura do controlador host

A arquitetura do controlador de host Vendor Test Suite (VTS) é a arquitetura da estrutura de teste VTS integrada com seu serviço de serviço de teste baseado em nuvem.

Teste HAL com reconhecimento de nome de serviço

O teste HAL com reconhecimento de nome de serviço VTS suporta a obtenção do nome de serviço de uma determinada instância HAL com base no dispositivo no qual os testes VTS estão sendo executados.

Verificação de testabilidade HAL

A verificação de testabilidade VTS HAL inclui um método de tempo de execução para usar a configuração do dispositivo para identificar quais testes VTS devem ser ignorados para aquele dispositivo alvo.

Infraestrutura de testes automatizados

A infraestrutura de teste automatizado é uma infraestrutura VTS para testes automatizados de VTS, CTS ou outros testes em dispositivos parceiros que executam a imagem genérica do sistema (GSI) AOSP.

Depuração

Telemetria avançada

No Android, a telemetria é o processo de coleta automática de informações de uso e diagnóstico sobre o dispositivo, o sistema Android e os aplicativos. Nas versões anteriores do Android, a pilha de telemetria era limitada e não capturava as informações necessárias para identificar e resolver problemas de confiabilidade do sistema e de dispositivos ou aplicativos. Isto tornou difícil, se não impossível, identificar as causas profundas dos problemas.

O Android 9 inclui o recurso de telemetria statsd , que resolve essa deficiência coletando dados melhores com mais rapidez. statsd coleta uso de aplicativos, estatísticas de bateria e processo e travamentos. Os dados são analisados ​​e usados ​​para melhorar produtos, hardware e serviços.

Para obter mais detalhes, consulte frameworks/base/cmds/statsd/ .

Recursos de segurança

Assinatura de aplicativo

O esquema de assinatura do APK v3 oferece suporte à rotação de chaves do APK.

Suporte biométrico

O Android 9 inclui a classe pública BiometricPrompt , que os aplicativos podem usar para integrar o suporte à autenticação biométrica de maneira independente de dispositivo e modalidade. Para obter mais informações sobre como integrar sua pilha de biometria para incluir BiometricPrompt , consulte Biometria .

Análise dinâmica

O Android 9 inclui suporte para mais ferramentas de mitigação e análise de exploits .

Integridade do fluxo de controle (CFI)

A integridade do fluxo de controle (CFI) é um mecanismo de segurança que proíbe alterações no gráfico de fluxo de controle original de um binário compilado, tornando significativamente mais difícil realizar tais ataques.

Finanças do Kernel

Além do CFI do sistema, que é ativado por padrão, o Android 9 e versões posteriores incluem suporte para integridade do fluxo de controle do kernel (CFI) .

Criptografia

Criptografia baseada em arquivo

A criptografia baseada em arquivo (FBE) foi atualizada para funcionar com armazenamento adotável . Novos dispositivos devem usar criptografia baseada em arquivos em vez de criptografia de disco completo.

Criptografia de metadados

O Android 9 e versões posteriores incluem suporte para criptografia de metadados onde há suporte de hardware. Com a criptografia de metadados, uma única chave presente no momento da inicialização usa criptografia baseada em arquivo para criptografar qualquer conteúdo não criptografado.

Armazenamento de chaves

O Android 9 e superior inclui o Keymaster 4 , que possui esses recursos.

Caixa forte

O Android 9 e versões posteriores incluem suporte para chaves do Android Keystore que são armazenadas e usadas em uma CPU fisicamente separada, desenvolvida especificamente para aplicativos de alta segurança, como um elemento seguro incorporado (SE) . StrongBox Keymaster é uma implementação do Keymaster HAL em hardware discreto e seguro. Um StrongBox possui:

  • CPU discreta
  • Armazenamento seguro integral
  • Gerador de números aleatórios verdadeiros de alta qualidade
  • Embalagem resistente a adulteração
  • Resistência do canal lateral

Importação segura de chave

Para importar com segurança uma chave para o Keymaster 4, uma chave criada fora do dispositivo é criptografada com uma especificação das autorizações que definem como a chave pode ser usada.

Suporte 3DES

Keymaster 4 inclui 3DES para compatibilidade com sistemas legados que usam 3DES.

Vinculação de versão

Para suportar a estrutura modular do Treble e quebrar a ligação de system.img a boot.img , o Keymaster 4 alterou o modelo de ligação de versão chave para ter níveis de patch separados para cada partição. Isso permite que cada partição seja atualizada de forma independente, ao mesmo tempo que fornece proteção contra reversão.

API de confirmação protegida do Android

Os dispositivos compatíveis iniciados com o Android 9 instalado oferecem aos desenvolvedores a capacidade de usar a Android Protected Confirmation API . Com esta API, os aplicativos podem usar uma instância de ConfirmationPrompt para exibir um prompt ao usuário, solicitando que ele aprove uma declaração curta. Essa declaração permite que um aplicativo reafirme que o usuário deseja concluir uma transação confidencial, como efetuar um pagamento.

SELinux

Sandbox SELinux por aplicativo

A sandbox do aplicativo tem novas proteções e casos de teste para garantir que todos os aplicativos sem privilégios direcionados ao Android 9 e superior executem sandboxes SELinux individuais.

Mudanças triplas no SELinux

As atualizações do Treble SELinux no Android 9 e superior estão documentadas em várias páginas da seção SELinux .

Inicialização do fornecedor

A inicialização do fornecedor fecha a lacuna na divisão sistema/fornecedor do Treble usando um domínio SELinux separado para executar comandos /vendor com permissões específicas do fornecedor.

Propriedades do sistema

O Android 9 impede que as propriedades do sistema sejam compartilhadas desnecessariamente entre as partições system e vendor e fornece um método para garantir a consistência entre as propriedades compartilhadas do sistema.

Testes de atributos SELinux

O Android 9 inclui novos testes em tempo de compilação que garantem que todos os arquivos em locais específicos tenham os atributos apropriados . Por exemplo, todos os arquivos em sysfs possuem o atributo sysfs_type obrigatório.

Áudio

Efeitos de áudio de alta resolução

As atualizações nos efeitos de áudio de alta resolução incluem a conversão do processamento de efeitos do formato int16 para o formato float e aumentos nas trilhas de saída simultâneas do cliente, memória máxima de cliente/servidor e total de trilhas mixadas.

Câmera

Câmeras USB externas

O Android 9 e versões posteriores oferecem suporte ao uso de câmeras USB plug-and-play (ou seja, webcams) usando a API Android Camera2 padrão e a interface HIDL da câmera.

Rastreamento de movimento

Dispositivos de câmera podem anunciar capacidade de rastreamento de movimento .

Suporte multicâmera

O suporte multicâmera inclui suporte API para dispositivos multicâmera por meio de um novo dispositivo de câmera lógica composto por dois ou mais dispositivos de câmera física apontando na mesma direção.

Parâmetros de sessão

A implementação de parâmetros de sessão pode reduzir atrasos, permitindo que os clientes de câmera configurem ativamente um subconjunto de parâmetros de solicitação dispendiosos como parte da fase de inicialização da sessão de captura.

Produtor único, buffer de múltiplos consumidores

O transporte de buffer de câmera de produtor único e vários consumidores é um conjunto de métodos que permite aos clientes de câmera adicionar e remover superfícies de saída dinamicamente enquanto a sessão de captura está ativa e o streaming da câmera está em andamento.

Conectividade

Chamadas e mensagens

Implementar planos de dados

O Android 9 e versões posteriores oferecem suporte aprimorado para operadoras que implementam planos de dados usando as APIs SubscriptionPlan.

Aplicativos de chamadas de terceiros

O Android 9 e versões posteriores fornecem APIs que permitem que aplicativos de chamadas de terceiros (3P) processem chamadas recebidas simultâneas da operadora e tenham chamadas registradas no registro de chamadas do sistema.

Operadora

Identificação da transportadora

No Android 9, o AOSP adiciona um banco de dados de ID de operadora para ajudar na identificação da operadora . O banco de dados minimiza lógica duplicada e experiências de aplicativos fragmentadas, fornecendo uma maneira comum de identificar operadoras.

SIM

SIM incorporado (eSIM ou eUICC) é a tecnologia mais recente que permite aos usuários móveis baixar um perfil de operadora e ativar o serviço de uma operadora sem ter um cartão SIM físico. No Android 9 e versões posteriores, a estrutura do Android fornece APIs padrão para acessar o eSIM e gerenciar perfis de assinatura no eSIM. Para mais informações, veja:

Suporte multi-SIM para configurações IMS

O Android 9 e versões posteriores fornecem melhorias nas configurações do usuário para o subsistema de multimídia IP (IMS) . Você pode configurar voz over LTE (VoLTE), chamadas de vídeo e chamadas Wi-Fi por assinatura, em vez de compartilhar essas configurações em todas as assinaturas.

Transmissões de estado do SIM

No Android 9 e versões posteriores, Intent.ACTION_SIM_STATE_CHANGED está obsoleto e duas transmissões separadas para o estado do cartão e o estado do aplicativo do cartão são adicionadas, TelephonyManager.ACTION_SIM_CARD_STATE_CHANGED e TelephonyManager.ACTION_SIM_APPLICATION_STATE_CHANGED .

Com essas mudanças, os receptores que só precisam saber se um cartão está presente não precisam ouvir as alterações no estado do aplicativo, e os receptores que só precisam saber se os aplicativos do cartão estão prontos não precisam ouvir as mudanças no estado do cartão.

As duas novas transmissões são @SystemApis e não são fixas. Somente receptores com permissão READ_PRIVILEGED_PHONE_STATE podem receber as transmissões.

As intenções não são retransmitidas quando você desbloqueia o dispositivo. Os receptores que dependem de transmissões enviadas antes do desbloqueio devem usar directBootAware ou consultar o estado após o desbloqueio do usuário. Os estados podem ser consultados usando as APIs correspondentes em TelephonyManager, getSimCardState() e getSimApplicationState() .

Wi-fi

Wi-Fi da operadora

O recurso Wi-Fi da operadora permite que os dispositivos se conectem automaticamente a redes Wi-Fi implementadas pela operadora. Em áreas de grande congestionamento ou com cobertura celular mínima, como um estádio ou uma estação de trem subterrânea, o Wi-Fi da operadora ajuda a melhorar a conectividade e a aliviar o tráfego.

Randomização MAC

A randomização MAC permite que os dispositivos usem endereços MAC aleatórios ao sondar novas redes enquanto não estiverem atualmente associados a uma rede. No Android 9 e superior, uma opção de desenvolvedor pode ser habilitada para fazer com que um dispositivo use um endereço MAC aleatório ao se conectar a uma rede Wi-Fi.

Ligue o Wi-Fi automaticamente

Quando o recurso Ativar Wi-Fi automaticamente está ativado, o Wi-Fi é reativado automaticamente sempre que o dispositivo estiver próximo de uma rede Wi-Fi salva com um indicador de intensidade relativa do sinal recebido (RSSI) suficientemente alto.

Tempo de ida e volta do Wi-Fi

O tempo de ida e volta (RTT) do Wi-Fi permite que os dispositivos meçam a distância até outros dispositivos compatíveis, sejam eles pontos de acesso (APs) ou pares Wi-Fi Aware (se o Wi-Fi Aware for compatível com o dispositivo). Esse recurso é baseado no protocolo IEEE 802.11mc e permite que os aplicativos usem maior precisão e reconhecimento de localização.

Melhorias na pontuação de Wi-Fi

Modelos aprimorados de pontuação de Wi-Fi determinam com rapidez e precisão quando um dispositivo deve sair de uma rede Wi-Fi conectada ou entrar em uma nova rede Wi-Fi. Esses modelos proporcionam uma experiência confiável e contínua aos usuários, evitando lacunas na conectividade.

Revise e ajuste os valores RSSI nos recursos config.xml , especialmente os seguintes:

  • config_wifi_framework_wifi_score_bad_rssi_threshold_5GHz
  • config_wifi_framework_wifi_score_entry_rssi_threshold_5GHz
  • config_wifi_framework_wifi_score_bad_rssi_threshold_24GHz
  • config_wifi_framework_wifi_score_entry_rssi_threshold_24GHz

Simultaneidade Wi-Fi STA/AP

A simultaneidade Wi-Fi STA/AP é a capacidade dos dispositivos operarem nos modos estação (STA) e ponto de acesso (AP) simultaneamente. Para dispositivos que suportam Wi-Fi de banda dupla simultânea (DBS), isso abre recursos como não interromper o Wi-Fi STA quando um usuário deseja ativar um ponto de acesso (SoftAP).

Melhorias no WiFiStateMachine

WifiStateMachine é a classe principal usada para controlar a atividade Wi-Fi, coordenar a entrada do usuário (modos de operação: hotspot, varredura, conectar ou desligar) e controlar ações da rede Wi-Fi (como varredura ou conexão).

No Android 9 e versões posteriores, o código da estrutura Wi-Fi e a implementação de WifiStateMachine foram reprojetados, resultando em tamanho de código reduzido, lógica de controle Wi-Fi mais fácil de seguir, granularidade de controle aprimorada e maior cobertura e qualidade de testes de unidade .

Em alto nível, WifiStateMachine permite que o Wi-Fi esteja em um dos quatro estados:

  • Modo cliente (pode conectar e digitalizar)
  • Modo somente digitalização
  • Modo SoftAP (ponto de acesso Wi-Fi)
  • Desativado (Wi-Fi totalmente desligado)

Cada modo Wi-Fi possui requisitos diferentes para execução de serviços e deve ser configurado de forma consistente, tratando apenas os eventos relevantes ao seu funcionamento. A nova implementação restringe o código a eventos relacionados a esse modo, reduzindo o tempo de depuração e o risco de introdução de novos bugs devido à complexidade. Além do tratamento explícito da funcionalidade do modo, o gerenciamento de threads é tratado de maneira consistente e o uso de canais assíncronos é eliminado como mecanismo de sincronização.

Atualizações de permissão de Wi-Fi

No Android 9 e versões posteriores, a permissão do aplicativo CHANGE_WIFI_STATE está habilitada por padrão. Você pode desativar a permissão para qualquer aplicativo na página de configurações em Configurações > Aplicativos e notificações > Acesso especial a aplicativos > Controle de Wi-Fi .

Os aplicativos devem ser capazes de lidar com casos em que a permissão CHANGE_WIFI_STATE não é concedida.

Para validar esse comportamento, execute os testes roboelétricos e manuais.

Para testes manuais:

  1. Vá para Configurações > Aplicativos e notificações > Acesso especial a aplicativos > Controle de Wi-Fi .
  2. Selecione e desative a permissão do seu aplicativo.
  3. Verifique se seu aplicativo pode lidar com o cenário em que a permissão CHANGE_WIFI_STATE não é concedida.

Descontinuação do WPS

Devido a problemas de segurança, a configuração protegida de Wi-Fi (WPS) no WiFiManager está obsoleta e desativada no Android 9 e superior. No entanto, WiFiDirect ainda usa WPS no suplicante WPA.

Gráficos

Implementação

API Vulkan 1.1

O Android 9 e superior suporta a implementação da API gráfica Vulkan 1.1 .

Ferramenta WinScope para rastreamento de transição de janela

O Android 9 e superior inclui a ferramenta WinScope para rastrear transições de janelas. WinScope fornece infraestrutura e ferramentas para registrar e analisar o estado do gerenciador de janelas durante e após as transições. Ele permite gravar e percorrer transições de janelas, enquanto grava todos os estados pertinentes do gerenciador de janelas em um arquivo de rastreamento. Você pode usar esses dados para reproduzir e percorrer a transição.

O código-fonte da ferramenta WinScope está localizado em platform/development/tools/winscope .

Interação

Áudio automotivo

Automotive Audio descreve a arquitetura de áudio para implementações Android relacionadas ao setor automotivo.

O HAL de Redes Neurais (NN) define uma abstração dos vários aceleradores. Os drivers para esses aceleradores devem estar em conformidade com esta HAL.

Veículo HAL

Propriedades do Veículo descreve alterações na interface HAL do veículo.

Seleção de satélite GNSS

Ao trabalhar com novos HALs (v1.1+) do sistema global de navegação por satélite (GNSS), o Android Framework monitora as configurações do Android. Os parceiros podem alterar as configurações do Google Play Services ou de outras atualizações do sistema. Estas configurações informam ao GNSS HAL se determinados satélites GNSS não devem ser usados. Isso pode ser útil no caso de erros persistentes de satélite ou constelação GNSS, ou para reagir mais rapidamente a problemas de implementação HAL GNSS que podem ocorrer ao misturar constelações usando diferentes sistemas de tempo e eventos externos, como substituições de números de segundos bissextos, de dias ou de semanas. .

Modelo de hardware GNSS

No Android 9, o GNSS HAL versão 1.1 ou superior pode passar informações sobre a API de hardware para a plataforma. A plataforma precisa implementar a interface IGnssCallback e passar um identificador para o HAL. O GNSS HAL passa as informações do modelo de hardware por meio do método LocationManager#getGnssHardwareModelName() . Os fabricantes de dispositivos devem trabalhar com seus fornecedores de GNSS HAL para fornecer essas informações sempre que possível.

Permissões

Configurando atualizações de controle de acesso discricionário

A configuração do controle de acesso discricionário (DAC) contém atualizações no mecanismo Android IDs (AIDs) para estender os recursos do sistema de arquivos.

Listando permissões de aplicativos privilegiados

No Android 9 e versões posteriores, se houver permissões que devam ser negadas, edite o XML para usar a tag deny-permission em vez da tag permission usada nas versões anteriores.

Dados

Melhorias na estimativa de largura de banda

O Android 9 oferece suporte aprimorado para estimativa de largura de banda. Os aplicativos Android podem fazer configurações de resolução mais apropriadas para chamadas de vídeo e streaming de vídeo se puderem acessar a largura de banda de dados disponível.

Em dispositivos com Android 6.0 ou superior, um chamador que deseja uma estimativa de largura de banda para uma rede celular chama ConnectivityManager.requestBandwidthUpdate() , e a estrutura pode fornecer uma largura de banda de downlink estimada.

Mas em dispositivos rodando 9 ou superior, o retorno de chamada onCapabilitiesChanged() é acionado automaticamente quando há uma mudança significativa na largura de banda estimada, e chamar requestBandwidthUpdate() é autônomo; os getLinkDownstreamBandwidthKbps() e getLinkUpstreamBandwidthKbps() associados são preenchidos com informações atualizadas fornecidas pela camada física.

Além disso, os dispositivos podem verificar as larguras de banda das células LTE via ServiceState.getCellBandwidths() . Isso permite que os aplicativos determinem quanta largura de banda (frequência) está disponível em uma determinada célula. As informações de largura de banda da célula estão disponíveis através de um menu oculto para que os testadores de campo possam verificar as informações mais atuais.

Monitoramento de tráfego eBPF

A ferramenta de tráfego de rede eBPF usa uma combinação de implementação de kernel e espaço de usuário para monitorar o uso da rede em um dispositivo desde a última inicialização do dispositivo. Esta ferramenta fornece funcionalidades adicionais, como marcação de soquete, separação de tráfego de primeiro/segundo plano e firewall por UID para bloquear o acesso de aplicativos à rede, dependendo do estado do dispositivo.

Restaurar para APIs inferiores

Os dispositivos agora podem restaurar versões futuras do sistema operacional. Isso é especialmente útil quando os usuários atualizaram seus telefones, mas os perderam ou quebraram.

Se um OEM modificar os agentes de backup para qualquer um dos pacotes do sistema (Android, sistema, configurações), esses agentes deverão cuidar da restauração de conjuntos de backups que foram feitos em versões superiores da plataforma sem travar e restaurar pelo menos alguns dados.

Considere usar um validador para verificar valores inválidos de um determinado dado de backup e restaurar apenas dados válidos, como em core/java/android/provider/SettingsValidators.java .

O recurso está ativado por padrão. O suporte do SettingsBackupAgent para restauração de versões futuras pode ser desativado por meio de Settings.Global.OVERRIDE_SETTINGS_PROVIDER_RESTORE_ANY_VERSION . Nenhuma implementação adicional é necessária, a menos que o fabricante do dispositivo estenda um dos agentes de backup incluídos na ROM (ou adicione um agente personalizado).

Este recurso permite restaurações do sistema a partir de versões futuras da plataforma; entretanto, é razoável esperar que os dados restaurados não estejam completos. As instruções a seguir se aplicam aos seguintes agentes de backup:

  • PackageManagerBackupAgent oferece suporte a versões futuras dos dados de backup por meio de controle de versão de formato; as extensões aqui devem ser compatíveis com o código de restauração atual ou seguir as instruções da classe, que incluem alterar as constantes adequadas.

  • SystemBackupAgent especifica restoreAnyVersion = false no Android 9 e versões posteriores. Não oferece suporte à restauração de versões superiores da API.

  • SettingsBackupAgent especifica restoreAnyVersion = true no Android 9 e versões posteriores. Existe suporte parcial por meio de validadores. Uma configuração pode ser restaurada de uma versão de API superior se existir um validador para ela no sistema operacional de destino. A adição de qualquer configuração deve ser acompanhada do seu validador. Verifique a aula para obter detalhes.

  • Qualquer agente de backup personalizado incluído na ROM deve aumentar seu código de versão sempre que uma alteração incompatível for feita no formato dos dados de backup e garantir que restoreAnyVersion = false (o padrão) se seu agente não estiver preparado para lidar com dados de backup de uma versão futura do seu código.

Empreendimento

Melhorias no perfil gerenciado

As alterações de UX para perfis gerenciados facilitam a identificação, o acesso e o controle do perfil gerenciado pelos usuários.

Pausar OTAs

Um novo @SystemApi permite que os proprietários de dispositivos pausem indefinidamente as atualizações OTA , incluindo atualizações de segurança.

Desempenho

Saúde 2.0

O Android 9 e superior inclui android.hardware.health HAL 2.0, uma atualização de versão principal do health@1.0 HAL. Para mais informações consulte estas páginas:

Solução de cache de APK

O Android 9 e superior inclui uma solução de cache APK para instalação rápida de aplicativos pré-carregados em um dispositivo compatível com partições A/B. Os OEMs podem colocar pré-carregamentos e aplicativos populares no cache APK armazenados principalmente na partição B vazia em novos dispositivos particionados A/B sem afetar qualquer espaço de dados voltado para o usuário.

Otimização guiada por perfil

O Android 9 e versões posteriores oferecem suporte ao uso da otimização guiada por perfil (PGO) do Clang em módulos Android nativos que possuem regras de criação de blueprint.

Registro de gravação antecipada

Um modo especial de SQLiteDatabase chamado registro de gravação antecipada de compatibilidade (WAL) permite que um banco de dados use journal_mode=WAL enquanto mantém no máximo uma conexão por banco de dados.

Tempos de inicialização

O Android 9 altera a otimização do tempo de inicialização conforme descrito em Otimizando tempos de inicialização .

Poder

Restrições de segundo plano

O Android 9 e superior inclui restrições de segundo plano que permitem aos usuários restringir aplicativos que podem estar esgotando a energia da bateria. O sistema também pode sugerir a desativação de aplicativos que estão afetando negativamente a saúde de um dispositivo.

Dispositivos sem bateria

O Android 9 lida com dispositivos sem bateria com mais elegância do que nas versões anteriores. O Android 9 remove o código para dispositivos sem bateria que presumiam por padrão que a bateria estava presente, carregada a 100% e em boas condições com uma leitura de temperatura normal em seu termistor.