O Android 9 (API de nível 28) introduz novos recursos e APIs que que você pode aproveitar nos seus aplicativos, além de novas mudanças de comportamento. Este documento oferece uma visão geral das etapas para migrar os apps para o Android 9 em duas fases principais:
- Garantir a compatibilidade básica com o Android 9
Verifique se seu aplicativo funciona perfeitamente na nova versão da plataforma. No momento, você não usa novas APIs nem muda a
targetSdkVersion, mas pequenas mudanças podem ser necessárias. - Direcionar para a nova plataforma, compilar com o SDK do Android 9 e
criar com recursos do Android 9
Quando estiver pronto para aproveitar os novos recursos do na plataforma, atualize a
targetSdkVersionpara28, verifique se o app continua para funcionar como esperado e, em seguida, começar a usar as novas APIs.
Preparar um dispositivo que executa o Android 9
Se você tiver um dispositivo compatível, obtenha a imagem do sistema Android 9 para seu dispositivo com o fabricante. Clique aqui para conferir imagens de fábrica para dispositivos Pixel. Instruções gerais para como atualizar uma imagem do sistema estão aqui.
Você também fazer o download da imagem de sistema do Android 9 para o Android Emulator. Ela está listada no SDK Manager em Android API 28 como Google APIs Intel x86 Atom System Image.
Observação:a imagem do sistema do emulador do Android 9 está disponível para download em Android Studio 3.1 e mais recentes O Android Studio 3.2 oferece compatibilidade máxima. Para ver mais informações, consulte Instalar o SDK do Android 9.
Garantir a compatibilidade com o Android 9
O objetivo é garantir que seu app funcione como está em
Android 9. Como algumas mudanças na plataforma podem afetar o comportamento do app,
alguns ajustes podem ser necessários, mas você não precisa usar novas APIs ou
mude o targetSdkVersion.
Realizar testes de compatibilidade
Na maioria dos casos, testar a compatibilidade com o Android 9 envolve o mesmo tipo de teste que você realiza ao se preparar para lançar o app. Esse é um bom momento para analisar as Principais diretrizes de qualidade do app e as Práticas recomendadas para testes.
No entanto, há outro aspecto a ser testado: o Android 9 traz mudanças na plataforma
Android que podem afetar o comportamento do app ou corrompê-lo totalmente, mesmo que você não mude
o targetSdkVersion. Por isso, é importante dar uma olhada nas principais mudanças
na tabela 1 e testar as possíveis soluções que você implementar para se adequar a elas.
Tabela 1. Principais mudanças que afetam todos os apps em execução em dispositivos Android 9.
| Mudança | Resumo |
|---|---|
| Restrições para interfaces que não são SDK |
O acesso a interfaces não SDK específicas agora está bloqueado, seja o acesso direto, via
JNI ou via reflexão. Tentativas de acessar interfaces restritas geram erros como
NoSuchFieldException e NoSuchMethodException.
Consulte Restrições
para interfaces que não são SDK para mais detalhes.
|
| Remoção do provedor Crypto |
A partir do Android 9, o provedor Crypto JCA foi removido. Chamadas
para SecureRandom.getInstance("SHA1PRNG", "Crypto")
vão gerar NoSuchProviderException.
|
| Decodificador UTF-8 mais rígido | No Android 9, o decodificador UTF-8 para a linguagem Java está mais rígido e segue o padrão Unicode. |
| Acesso à câmera, ao microfone e aos sensores bloqueado para aplicativos ociosos | Enquanto aplicativos estão ociosos, eles não podem mais acessar a câmera, o microfone nem os sensores do SensorManager. |
Para uma lista mais extensa de mudanças de comportamento para todos os apps executados no Android 9, consulte o documento Alterações de comportamento.
Atualizar a versão de destino e usar os recursos do Android P
Esta seção explica como ativar o suporte total para o Android 9
atualizando o targetSdkVersion para 28
e adicionando novos recursos disponíveis no Android 9.
Além de oferecer novas APIs, o Android 9 introduz alguns comportamentos
muda quando você atualiza a targetSdkVersion para 28. Como algumas mudanças de comportamento
exigir alterações no código para evitar falhas. Primeiro é preciso entender como o app pode
afetadas quando você mudar a targetSdkVersion analisando todas as mudanças de comportamento para apps destinados ao Android 9.
Observação: as etapas descritas acima para garantir a compatibilidade da plataforma são um pré-requisito para direcionar o aplicativo para o Android 9. Portanto, não deixe de concluir essas etapas primeiro.
Obter o Android 9 SDK
É possível acessar os pacotes de SDK para criar seu app com o Android 9 usando o Android Studio 3.1 ou uma versão mais recente. Se você ainda não precisa dos novos recursos do Android 9 e quer apenas compilar com eles versão da plataforma, use o Android Studio 3.1. O Android Studio 3.2 oferece suporte completo para recursos do Android 9.
Testar seu aplicativo Android 9
Com os preparativos acima concluídos, você pode criar seu aplicativo e testar para garantir que ele funcione corretamente ao ser direcionado ao Android 9. (nível 28 da API). Esse é outro bom momento para analisar App principal diretrizes de qualidade e Melhores práticas Práticas para testes (em inglês).
Quando você cria seu app com a targetSdkVersion definida como P,
há mudanças específicas da plataforma que você precisa conhecer. Alguns
essas mudanças podem afetar significativamente o comportamento do aplicativo
corromper seu aplicativo completamente, mesmo que você não implemente novos
recursos no Android 9.
A tabela 2 fornece uma lista dessas mudanças com links para obter mais informações.
Tabela 2. Principais mudanças que afetam os apps
quando targetSdkVersion está definido como 28.
| Mudança | Resumo |
|---|---|
| Permissão para serviços de primeiro plano | Os apps que querem usar serviços em primeiro plano agora precisam solicitar primeiro a permissão FOREGROUND_SERVICE. Essa é uma permissão normal, portanto, o sistema a concede automaticamente ao app solicitante. Iniciar um serviço em primeiro plano sem a permissão aciona uma SecurityException. |
| Suspensão de uso das cifras do Bouncy Castle |
O Android 9 suspendeu o uso de diversas cifras do provedor Bouncy Castle em favor das
fornecidas pelo provedor Conscrypt. Chamadas para getInstance() que
solicitam o provedor Bouncy
Castle geram erros NoSuchAlgorithmException. Para resolver os erros, não
especificar um provedor em getInstance() (ou seja, solicitar a implementação padrão).
|
Remoção do acesso direto a Build.serial
|
Apps que precisam do identificador Build.serial agora precisam solicitar o READ_PHONE_STATE
permissão e usar o novo método Build.getSerial() adicionado no Android 9.
|
| Proibido compartilhar o diretório de dados WebView | Aplicativos não mais podem compartilhar um só diretório de dados WebView entre processos. Se o app tiver mais de um processo que utiliza WebView, CookieManager ou qualquer outra API no pacote android.webkit, ele falhará quando o segundo processo chamar um método WebView. |
| Acesso ao diretório de dados do aplicativo bloqueado por SELinux | O sistema aplica sandboxes SELinux por app com restrições de SELinux por app no diretório de dados particulares de cada app. O acesso direto ao diretório de dados de outro app por caminho agora está desativado. Os aplicativos podem continuar compartilhando dados usando mecanismos de IPC, incluindo passando FDs. |
Para uma lista mais extensa de mudanças de comportamento para apps destinados ao Android 9, consulte o documento Mudanças de comportamento.
Para conhecer os novos recursos e APIs disponíveis no Android 9, consulte Recursos e APIs do Android 9.