Notas da versão do Android 9

Esta página resume os principais recursos da versão do Android 9 e oferece links para outras informações. Os resumos de recursos são organizados de acordo com o local da documentação do recurso neste site. Consulte as Atualizações do site de agosto de 2018 para conferir um guia das transferências e renomeações das seções.

Build

Imagem genérica do sistema (GSI)

Trata-se de uma imagem que contém configurações ajustadas para dispositivos Android. Uma Imagem genérica do sistema (GSI) inclui detalhes sobre as diferenças entre as GSIs para dispositivos lançados com o Android 9 e aqueles que são atualizados para essa versão.

Arquitetura

Camada de abstração de hardware (HAL)

Compatibilidade de HIDL com versões anteriores do framework

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

HALs com disponibilidade dinâmica

HALs com disponibilidade dinâmica são compatíveis com o desligamento dinâmico de subsistemas de hardware do Android quando eles não estão em uso ou não são necessários.

HIDL

HIDL MemoryBlock

O HIDL MemoryBlock é uma camada abstrata criada em hidl_memory, HIDL @1.0::IAllocator e HIDL @1.0::IMapper. Ele é projetado para serviços HIDL que têm vários blocos de memória que compartilham um único heap.

Sobreposições da árvore de dispositivos

Sobreposições compactadas

O Android 9 e versões mais recentes incluem suporte ao uso de sobreposições compactadas na imagem da sobreposição de blob da árvore de dispositivos (DTBO, na sigla em inglês) ao usar a versão 1 do cabeçalho da tabela da árvore de dispositivos.

Atualizações de DTO

O Android 9 e versões mais recentes exigem que o carregador de inicialização passe o blob da árvore de dispositivos unificado para o kernel antes de modificar as propriedades definidas nas sobreposições da árvore de dispositivos (DTOs, na sigla em inglês).

Controle de versão do cabeçalho de imagem de DTBO

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

Verificação de DTBO

O Android 9 e versões mais recentes exigem uma partição de DTBO. Para adicionar nós ou fazer mudanças nas propriedades no SoC DT, o carregador de inicialização precisa sobrepor um DT específico do dispositivo sobre o SoC DT de forma dinâmica. Para ver mais informações, consulte Compilação e verificação.

Conformidade com o kernel

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

NDK do fornecedor

Mudanças de design

Para ver informações sobre as mudanças no design do VNDK no Android 9 e versões mais recentes, consulte estas páginas:

Verificador de ABI

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

Instantâneos de VNDK

Uma imagem do sistema pode usar instantâneos de VNDK para fornecer as bibliotecas de VNDK corretas para as imagens do fornecedor, mesmo quando as imagens do sistema e do fornecedor são criadas com base em versões diferentes do Android.

Objeto da interface do fornecedor (objeto VINTF, na sigla em inglês)

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

Programação de descontinuação do HIDL

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

Carregador de inicialização

Partições de produtos

O Android 9 e versões mais recentes oferecem suporte à criação de partições /product usando o sistema de compilação do Android. Anteriormente, o Android 8.x aplicava a separação de componentes específicos do system on chip (SoC) da partição /system para a partição /vendor, sem dedicar espaço para componentes específicos de OEM criados com base no sistema de compilação do Android.

Conformidade com o motivo de inicialização canônico

A página Motivo de inicialização canônico descreve as mudanças na especificação do motivo de inicialização do carregador de inicialização no Android 9 e versões mais recentes.

Sistema como raiz

Todos os dispositivos lançados com o Android 9 e versões mais recentes precisam usar o sistema como raiz, que combina ramdisk.img com system.img (também conhecido como no-ramdisk), que, por sua vez, é montado como rootfs.

Controle de versão para cabeçalho de imagem de inicialização

No Android 9 e versões mais recentes, o cabeçalho da imagem de inicialização contém um campo para indicar a versão do cabeçalho. O carregador de inicialização precisa verificar esse campo de versão e analisar o cabeçalho adequadamente.

DTBO em recuperação

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

Tela

Corte da tela

Os cortes da tela permitem que os desenvolvedores de apps criem experiências imersivas, de ponta a ponta, deixando ainda espaço para sensores importantes na parte frontal dos dispositivos.

Sugestões de rotação

As atualizações do comportamento de rotação da tela do Android 9 e versões mais recentes incluem suporte a um controle voltado ao usuário que permite fixar a rotação como paisagem ou retrato, mesmo se a posição do dispositivo mudar.

Transições de app sincronizadas

As transições de app sincronizadas possibilitam novas animações de transição de apps.

Classificação de texto (anteriormente TEXTCLASSIFIER)

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

Ampla gama de cores

O Android 9 e versões mais recentes incluem compatibilidade com uma ampla gama de cores, incluindo:

  • High Dynamic Range (HDR)
  • Processamento de conteúdo no espaço de cores BT2020, mas não como um espaço para dados de destino final

Para usar a ampla gama de cores, a pilha de exibição completa de um dispositivo (como tela, compositor de hardware, GPU) precisa ser compatível com a ampla gama de cores ou formatos de buffer. Os dispositivos não precisam declarar compatibilidade com uma ampla gama de cores, mesmo se o hardware for compatível. No entanto, a ampla gama de cores precisa ser ativada para aproveitar o hardware ao máximo. Para evitar uma experiência visual inconsistente, a ampla gama de cores não pode ser desativada durante o tempo de execução.

Compatibilidade

Documento de definição de compatibilidade do Android (CDD, na sigla em inglês)

O Documento de definição de compatibilidade do Android 9 itera as versões anteriores com atualizações de novos recursos e modificações nos requisitos da funcionalidade lançada anteriormente.

Configurações

Melhores widgets de apps

O framework de widget de apps Android oferece maior visibilidade das interações do usuário, especificamente quando um usuário exclui ou adiciona manualmente widgets. Essa funcionalidade é disponibilizada por padrão com o Launcher3.

Os fabricantes precisam atualizar os apps da tela de início deles (que são fornecidos com os dispositivos) para serem compatíveis com esse recurso, se não forem baseados no Launcher3. Os OEMs precisam oferecer compatibilidade com o novo campo widgetFeatures na tela de início padrão.

O recurso só funciona de forma completa quando é implementado como esperado pela tela de início. O AOSP inclui uma implementação de exemplo. Consulte o código de mudança do AOSP Iccd6f965fa3d61992244a365efc242122292c0ca para conferir o exemplo de código oferecido.

Notificações de mudança de estado do dispositivo para instaladores de pacotes

Uma transmissão protegida do sistema pode ser enviada para apps que têm a permissão INSTALL_PACKAGES sempre que houver uma alteração nas propriedades, como localidade ou densidade de exibição. Os receptores podem ser registrados no manifesto, e um processo será ativado para receber a transmissão. Isso é útil para instaladores de pacotes que queiram instalar outros componentes de apps mediante essas mudanças, o que é incomum, porque as modificações de configuração qualificadas para acionar essa transmissão são raras.

O código-fonte da notificação de mudança de estado do dispositivo encontra-se 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ções

As alterações na arquitetura de informações do app Config. oferecem mais funcionalidades e uma implementação mais fácil.

Testes

Atest

A ferramenta de linha de comando Atest permite que você crie, instale e execute testes do Android localmente, acelerando muito as execuções repetidas de testes, sem exigir conhecimento das opções de linha de comando do arcabouço de testes da Trade Federation.

Conjunto de teste de compatibilidade (CTS)

Downloads do CTS

Os pacotes de CTS compatíveis com o Android 9 estão disponíveis na página 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 do CTS

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

  • run retry: repete todos os testes que falharam ou não foram executados nas sessões anteriores.
  • ‘--shard-count: fragmenta uma execução do CTS em um número determinado de partes independentes para execução em vários dispositivos em paralelo.

Além disso, os comandos --retry-type anteriormente não documentados foram incluídos na mesma referência de comando do console CTS v2.

Serviço Elemento de segurança

O serviço Elemento de Segurança (SE, na sigla em inglês) confere se há elementos seguros globais com suporte à plataforma, identificando se os dispositivos têm uma implementação SE HAL e, em caso afirmativo, quantas. Ele é usado como a base para testar a API e a implementação do elemento de segurança subjacente.

Caixa de fusão do sensor

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

ITS-in-a-Box de campo de visão amplo

O ITS-in-a-box de campo de visão amplo é um sistema automático projetado para testar sistemas de câmeras de campo de visão amplo (WFoV, na sigla em inglês) e de campo de visão normal (RFoV, na sigla em inglês) no Camera ITS.

Teste de fornecedor (VTS)

Arquitetura do controlador de host

A arquitetura do controlador de host do teste de fornecedor (VTS, na sigla em inglês) é a arquitetura do framework de teste do VTS integrado ao serviço de teste baseado na nuvem.

Testes de HAL com reconhecimento de nome de serviço

Os testes VTS de HAL com reconhecimento de nome de serviço são compatíveis com a aquisição do nome do serviço de uma determinada instância da HAL com base no dispositivo em que os testes do VTS estão sendo executados.

Verificação da capacidade de teste de HAL

A Verificação VTS da capacidade de teste de HAL inclui um método de tempo de execução para usar a configuração do dispositivo para identificar quais testes de VTS serão ignorados para esse destino de dispositivo.

Infraestrutura de testes automatizada

A infraestrutura de testes automatizada é uma infraestrutura VTS para testes automatizados de VTS, CTS ou outros testes em dispositivos parceiros que executam a imagem genérica do sistema (GSI, na sigla em inglês) do AOSP.

Depuração

Telemetria avançada

No Android, a telemetria é o processo de coleta automática de informações de uso e diagnósticos sobre o dispositivo, o sistema Android e os apps. 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 a confiabilidade do sistema e os problemas de dispositivos ou apps. Isso dificultava, ou até impossibilitava, a identificação das causas-raiz dos problemas.

O Android 9 inclui o recurso de telemetria statsd, que resolve essa deficiência coletando dados melhores de forma mais rápida. statsd coleta as estatísticas do processo, bateria e uso de apps, assim como de falhas. Os dados são analisados e usados para melhorar produtos, hardware e serviços.

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

Recursos de segurança

Assinatura do aplicativo

O esquema de assinatura de APK v3 é compatível com a rotação de chaves de APK.

Compatibilidade biométrica

O Android 9 inclui a classe pública BiometricPrompt, que os apps podem usar para integrar a compatibilidade com autenticação biométrica de maneira independente de dispositivos e modalidades. Para ver mais informações sobre como integrar sua pilha de biometria para incluir o BiometricPrompt, consulte Biometria.

Análise dinâmica

O Android 9 inclui compatibilidade com mais ferramentas de análise e redução de vulnerabilidades.

Integridade do fluxo de controle (CFI)

A Integridade do fluxo de controle (CFI, na sigla em inglês) é um mecanismo de segurança que proíbe mudanças no gráfico de fluxo de controle original de um binário compilado, tornando-o significativamente mais resistente a esses ataques.

CFI de kernel

Além do CFI do sistema, que é ativado por padrão, o Android 9 e versões mais recentes incluem suporte a CFI de kernel.

Criptografia

Criptografia baseada em arquivos (FBE)

A Criptografia baseada em arquivo (FBE, na sigla em inglês) foi atualizada para funcionar com o armazenamento adotável. Os dispositivos novos devem usar a criptografia baseada em arquivo em vez da criptografia de disco completo.

Criptografia de metadados

O Android 9 e versões mais recentes oferecem suporte à criptografia de metadados nos casos em que há suporte de hardware. Com a criptografia de metadados, uma única chave presente no momento da inicialização usa a criptografia baseada em arquivos para criptografar qualquer conteúdo não criptografado.

Armazenamento de chaves

O Android 9 e versões mais recentes incluem o Keymaster 4, que apresenta os seguintes recursos:

StrongBox

O Android 9 e versões mais recentes incluem suporte a chaves do Armazenamento de chaves do Android que são armazenadas e usadas em uma CPU fisicamente separada, criada especificamente para aplicativos de alta segurança, como um Elemento de segurança (SE, na sigla em inglês) incorporado. O StrongBox Keymaster é uma implementação de Keymaster HAL em hardware seguro discreto. Um StrongBox conta com:

  • CPU discreta
  • Armazenamento seguro integral
  • Gerador de número aleatório de alta qualidade
  • Empacotamento resistente a adulterações
  • Resistência a canal paralelo

Importação de chave segura

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

Compatibilidade com 3DES

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

Vinculação de versão

Para ser compatível com a estrutura modular do Treble e romper a vinculação de system.img com boot.img, o Keymaster 4 mudou o modelo de vinculação de versão de chave para ter níveis de patch separados para cada partição. Isso permite que cada partição seja atualizada de maneira independente, fornecendo ainda proteção contra reversão.

API Confirmação protegida pelo Android

Os dispositivos com suporte lançados com o Android 9 instalado permitem que os desenvolvedores usem a API Android Protected Confirmation. Com essa API, os aplicativos podem usar uma instância de ConfirmationPrompt para exibir uma solicitação ao usuário, solicitando que ele aprove uma breve declaração (link em inglês). Essa declaração permite que o app reafirme que o usuário quer concluir uma transação confidencial, como efetuar um pagamento.

SELinux

Sandbox SELinux por app

O Sandbox de aplicativos tem novas proteções e testes para garantir que todos os apps não privilegiados destinados ao Android 9 ou versões mais recentes executem sandboxes SELinux individuais.

Alterações no SELinux do Treble

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

Vendor init

O init do fornecedor resolve o problema da divisão do 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 partições system e vendor, além de disponibilizar um método para garantir a consistência entre propriedades compartilhadas do sistema.

Testes de atributos do SELinux

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

Áudio

Efeitos de áudio de alta resolução

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

Câmera

Câmeras USB externas

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

Registro de movimento

Os dispositivos da câmera podem anunciar o recurso de registro de movimento.

Compatibilidade com várias câmeras

A compatibilidade com várias câmeras inclui suporte à API para dispositivos com mais de uma câmera usando um novo dispositivo de câmera lógica composto por dois ou mais dispositivos de câmera física apontando para a mesma direção.

Parâmetros de sessão

A implementação de parâmetros de sessão pode reduzir os atrasos ao permitir que os clientes da 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 vários consumidores

O transporte do buffer da câmera de vários consumidores com produtor único é um conjunto de métodos que permite que os clientes da câmera incluam e removam 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

Implementação de planos de dados

O Android 9 e versões mais recentes oferecem suporte aprimorado à implementação de planos de dados pelas operadoras usando as APIs SubcriptionPlan.

Apps de chamadas de terceiros

O Android 9 e versões mais recentes oferecem APIs que permitem que apps de chamadas de terceiros (3P) processem chamadas simultâneas recebidas de operadoras e registrem chamadas no sistema.

Operadora

Identificação da operadora

No Android 9, o AOSP inclui um banco de dados de código de operadoras para ajudar na identificação delas. O banco de dados minimiza a lógica duplicada e as experiências de apps fragmentados, oferecendo uma maneira comum de identificar as operadoras.

eSIM

O chip incorporado (eSIM ou eUICC) é a tecnologia mais recente a permitir que usuários de dispositivos móveis façam o download de um perfil de operadora e ativem o serviço dela sem precisar de um chip físico. No Android 9 e versões posteriores, o framework do Android disponibiliza APIs padrão para acessar o eSIM e gerenciar perfis de assinatura nesse chip. Para mais informações, consulte estas páginas:

Compatibilidade com vários chips para configurações de IMS

O Android 9 e versões posteriores oferecem melhorias nas configurações do usuário para IP Multimedia Subsystem (IMS). Você pode configurar Voz por LTE (VoLTE), videochamadas e chamadas no Wi-Fi em cada assinatura, em vez de compartilhar essas configurações em todas as assinaturas.

Transmissões do estado do chip

No Android 9 e versões posteriores, o uso de Intent.ACTION_SIM_STATE_CHANGED foi suspenso e duas transmissões separadas para estado de cartão e estado de aplicativo de cartão foram adicionadas: TelephonyManager.ACTION_SIM_CARD_STATE_CHANGED e TelephonyManager.ACTION_SIM_APPLICATION_STATE_CHANGED.

Com essas modificações, os receptores que só precisam saber se um cartão está presente não precisam mais ouvir as mudanças de 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. Apenas receptores com a permissão READ_PRIVILEGED_PHONE_STATE podem receber as transmissões.

As intents não são retransmitidas quando você desbloqueia o dispositivo. Os receptores que dependem de transmissões enviadas antes do desbloqueio do usuário precisam usar directBootAware ou consultar o estado depois do desbloqueio. Os estados podem ser consultados utilizando as APIs correspondentes no TelephonyManager, getSimCardState() e getSimApplicationState().

Wi-Fi

Wi-Fi da operadora

O recurso Wi-Fi da operadora permite que dispositivos se conectem automaticamente a redes Wi-Fi implementadas pela operadora. Em áreas de alto 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 descarregar o tráfego.

Escolha aleatória de MAC

A escolha aleatória de MAC permite que os dispositivos usem endereços MAC aleatórios ao procurar novas redes enquanto não estão associados a uma rede. No Android 9 e versões posteriores, uma opção do desenvolvedor pode ser ativada para fazer com que um dispositivo use um endereço MAC aleatório ao se conectar a uma rede Wi-Fi.

Ativar o Wi‑Fi automaticamente

Quando o recurso Ativar o Wi-Fi automaticamente estiver ativado, o Wi-Fi será reativado automaticamente sempre que o dispositivo estiver perto de uma rede Wi-Fi salva com um indicador de intensidade de sinal recebido (RSSI, na sigla em inglês) suficientemente alto.

Tempo de retorno do Wi-Fi (RTT)

O tempo de retorno (RTT) do Wi-Fi permite que os dispositivos meçam a distância até outros dispositivos com suporte, sejam eles pontos de acesso (APs) ou outros pontos Wi-Fi Aware, se esse recurso tem suporte do dispositivo. Esse recurso, criado com base no protocolo IEEE 802.11mc, permite que os apps usem a precisão e o reconhecimento de local aprimorados.

Melhorias na classificação de Wi-Fi

Os modelos de classificação de Wi-Fi aprimorados determinam com rapidez e precisão quando um dispositivo precisa sair de uma rede Wi-Fi conectada ou se conectar a uma nova rede. Esses modelos oferecem uma experiência confiável e contínua para os usuários, evitando falhas na conectividade.

Analise e ajuste os valores de RSSI nos recursos de 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 de STA/AP Wi-Fi

A simultaneidade de STA/AP Wi-Fi é a capacidade dos dispositivos de operar nos modos Estação (STA) e Ponto de acesso (AP) simultaneamente. Para dispositivos compatíveis com Dual Band Simultaneous (DBS), esse recurso traz algumas funcionalidades, como não interromper o modo STA Wi-Fi quando um usuário quer ativar um ponto de acesso (softAP).

Melhorias no WiFiStateMachine

WifiStateMachine é a principal classe usada para controlar a atividade do Wi-Fi, coordenar a entrada do usuário (modos de operação: ponto de acesso, busca, conexão ou desativação) e controlar ações da rede Wi-Fi (por exemplo, busca ou conexão).

No Android 9 e versões posteriores, o código do framework de Wi-Fi e a implementação de WifiStateMachine foram reprojetados, resultando em um código de tamanho reduzido, uma 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 um nível elevado, o WifiStateMachine permite que o Wi-Fi esteja em um destes quatro estados:

  • Modo de cliente (pode conectar e buscar)
  • Modo somente busca
  • Modo SoftAP (ponto de acesso Wi-Fi)
  • Desativado (Wi-Fi totalmente desativado)

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

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

No Android 9 e versões posteriores, a permissão do app CHANGE_WIFI_STATE é ativada por padrão. É possível desativar a permissão para qualquer app na página de configurações em Configurações > Apps e notificações > Acesso especial a apps > Controle de Wi-Fi.

Os apps precisam conseguir processar 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. Acesse Config. > Apps e notificações > Acesso especial a apps > Controle de Wi-Fi.
  2. Selecione e desative a permissão para seu app.
  3. Verifique se o app consegue processar os casos em que a permissão CHANGE_WIFI_STATE não é concedida.

Descontinuação de WPS

Devido a problemas de segurança, o Wi-Fi Protected Setup (WPS) em WiFiManager foi suspenso e desativado no Android 9 e versões posteriores. No entanto, WiFiDirect ainda usa o WPS no suplicante de WPA.

Gráficos

Implementação

API Vulkan 1.1

O Android 9 e versões mais recentes oferecem suporte à implementação da API de gráficos Vulkan 1.1.

Ferramenta WinScope para rastreamento de transição de janela

O Android 9 e versões mais recentes incluem a ferramenta WinScope para rastrear transições de janela. O WinScope disponibiliza a infraestrutura e as ferramentas para registrar e analisar o estado do gerenciador de janelas durante e após as transições. Ele permite gravar e percorrer as transições de janela, enquanto grava todo o estado do gerenciador pertinente 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

O Áudio automotivo descreve a arquitetura de áudio para implementações Android relacionadas a automóveis.

A HAL de Redes neurais (NN, na sigla em inglês) define uma abstração dos vários aceleradores. Os drivers para esses aceleradores precisam estar em conformidade com essa HAL.

HAL veicular

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

Seleção de satélite GNSS

Ao trabalhar com as novas HALs do Sistema global de navegação por satélite (GNSS, na sigla em inglês) (v1.1 +), o framework do Android monitora as configurações do Android. Os parceiros podem modificar as configurações do Google Play Services ou outras atualizações do sistema. Essas configurações dizem à HAL do GNSS se determinados satélites não podem ser usados. Isso pode ser útil em caso de erros persistentes de satélite ou constelação GNSS, ou para reagir mais rapidamente a problemas de implementação da HAL GNSS, que podem ocorrer ao misturar constelações usando diferentes sistemas de tempo e eventos externos, como segundo bissexto e/ou rollovers do número da semana ou do dia.

Modelo de hardware de GNSS

No Android 9, a HAL de GNSS versão 1.1 ou mais recente pode transmitir informações sobre a API de hardware para a plataforma. A plataforma precisa implementar a interface IGnssCallback e passar um identificador para a HAL. A HAL de GNSS passa as informações do modelo de hardware por meio do método LocationManager#getGnssHardwareModelName(). Os fabricantes de dispositivos precisam trabalhar junto aos provedores de HAL de GNSS para disponibilizar essas informações sempre que possível.

Permissões

Atualizações de configuração de controle de acesso discricionário (DAC, na sigla em inglês)

A configuração de controle de acesso discricionário (DAC) contém atualizações para o mecanismo de códigos do Android para ampliar as funcionalidades do sistema de arquivos.

Autorização de permissões dos apps privilegiados

No Android 9 e versões posteriores, caso haja permissões que precisem ser negadas, edite o XML para usar a tag deny-permission em vez da tag permission que era usada em versões anteriores.

Dados

Melhorias na estimativa de largura de banda

O Android 9 oferece melhor compatibilidade para a estimativa de largura de banda. Os apps Android poderão criar configurações de resolução mais adequadas para videochamadas e streaming de vídeo se puderem acessar a largura de banda de dados disponível.

Em dispositivos com Android 6.0 ou versões mais recentes, um autor da chamada que queira uma estimativa da largura de banda para uma rede celular chama ConnectivityManager.requestBandwidthUpdate(), e o framework pode fornecer uma largura de banda estimada de downlink.

No entanto, em dispositivos com o Android 9 ou versões mais recentes, o callback onCapabilitiesChanged() é acionado automaticamente quando há uma mudança significativa na largura de banda estimada, e chamar requestBandwidthUpdate() não traz nenhum benefício. 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 da rede LTE usando ServiceState.getCellBandwidths(). Isso permite que os aplicativos determinem quanto de largura de banda (frequência) está disponível em uma determinada rede. As informações de largura de banda da rede celular estão disponíveis por meio 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 kernel e implementação de espaço do usuário para monitorar o uso de rede no dispositivo desde a última inicialização do aparelho. Ela oferece outras funcionalidades, como inclusão de tag em soquetes, separação de tráfego em primeiro e segundo plano e firewall por UID para impedir que apps acessem a rede, dependendo do estado do dispositivo.

Restaurar para APIs anteriores

Os dispositivos agora podem realizar restaurações de versões futuras do sistema operacional. Isso é especialmente útil quando os usuários fazem upgrade dos smartphones, mas depois os perdem ou quebram.

Se um OEM modificar os agentes de backup para qualquer pacote do sistema (android, sistema, configurações), esses agentes precisarão gerenciar a restauração de conjuntos de backups feitos em versões posteriores da plataforma sem apresentar falhas e com a restauração de pelo menos alguns dados.

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

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

Esse recurso permite realizar restaurações do sistema de versões futuras da plataforma, mas é esperado que os dados restaurados não estejam completos. As instruções a seguir se aplicam aos seguintes agentes de backup:

  • O PackageManagerBackupAgent oferece suporte a versões futuras dos dados de backup usando o controle de versões de formato. Essas extensões precisam ser compatíveis com o código de restauração atual ou seguir as instruções da classe, o que inclui o aumento das constantes adequadas.

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

  • SettingsBackupAgent especifica restoreAnyVersion = true no Android 9 e versões posteriores. Há suporte parcial nos validadores. Uma configuração pode ser restaurada de uma versão mais recente da API caso exista um validador no SO de destino. A inclusão de qualquer configuração precisa ser acompanhada pelo próprio validador. Verifique a classe para ver detalhes.

  • Qualquer agente de backup personalizado incluído na ROM precisa aumentar o código de versão sempre que uma mudança incompatível é feita no formato de dados de backup, e garantir restoreAnyVersion = false (o padrão) se o agente não estiver preparado para processar dados de backup de uma versão futura do código.

Empresa

Melhorias de perfil gerenciado

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

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

Health 2.0

O Android 9 e versões posteriores incluem a HAL 2.0 android.hardware.health, uma atualização importante da versão da HAL health@1.0. Para ver mais informações, consulte estas páginas:

Armazenamento em cache de APK

O Android 9 e versões posteriores incluem uma solução de armazenamento em cache de APK para a instalação rápida de apps pré-carregados em dispositivos compatíveis com partições A/B. Os OEMs podem alocar pré-carregamentos e os apps favoritos no cache do APK armazenado na partição B, que normalmente fica vazia, em novos dispositivos com particionamento A/B, sem afetar o espaço de dados do usuário.

Otimização guiada pelo perfil (PGO)

O Android 9 e versões mais recentes oferecem suporte ao uso da otimização guiada por perfil (PGO, na sigla em inglês) do Clang em módulos Android nativos com regras de criação de diagramas.

Registro de gravação antecipada (WAL)

Um modo especial de SQLiteDatabase chamado registro de gravação de antecipada de compatibilidade (WAL, na sigla em inglês) 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 Otimização dos tempos de inicialização.

Energia

Restrições de segundo plano

O Android 9 e versões posteriores incluem restrições de segundo plano que permitem aos usuários restringir apps que possam estar drenando a energia da bateria. O sistema também pode sugerir a desativação de apps que estejam afetando negativamente a integridade do dispositivo.

Dispositivos sem bateria

O Android 9 lida de forma mais elegante com dispositivos sem bateria do que as versões anteriores. Ele remove o código de dispositivos sem bateria que, por padrão, presumiam que uma bateria estava presente, estava carregada em 100% e apresentava boa integridade com uma leitura normal de temperatura no termistor.