O Android 9 (nível 28 da API) introduz novos recursos e APIs que você pode aproveitar nos seus apps, além de novas mudanças de comportamento. Este documento fornece uma visão geral das etapas para migrar seus 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. Nessa etapa, você não usa novas APIs nem muda a
targetSdkVersiondo app, mas pequenas mudanças podem ser necessárias. - Direcionar o app para a nova plataforma, compilar com o SDK do Android 9 e
criar com os recursos do Android 9
Quando estiver tudo pronto para você aproveitar os novos recursos da plataforma, atualize sua
targetSdkVersionpara28, verifique se o app continua funcionando conforme o esperado e comece a usar as novas APIs.
Preparar um dispositivo que executa o Android 9
Se você tem um dispositivo compatível, faça o download da imagem do sistema Android 9 do fabricante. Clique aqui para ver imagens de fábrica para dispositivos Pixel. Confira aqui instruções gerais para atualizar uma imagem do sistema.
Você também fazer o download da imagem de sistema do Android 9 para o Android Emulator. Ela está listada no SDK Manager em API Android 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 no Android Studio 3.1 e versões 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 o app funcione como está no
Android 9. Como algumas mudanças na plataforma podem afetar a forma como o app se comporta,
alguns ajustes podem ser necessários, mas não é necessário usar novas APIs nem
mudar sua targetSdkVersion.
Realizar testes de compatibilidade
Na maioria das vezes, testar a compatibilidade com o Android 9 envolve o mesmo tipo de teste realizado ao se preparar para lançar seu app. Esse é um bom momento para analisar as Principais diretrizes de qualidade de apps e as Práticas recomendadas para testes.
No entanto, há outro aspecto a ser testado: o Android 9 introduz mudanças na plataforma
Android que podem afetar o comportamento do app ou corrompê-lo completamente, mesmo que você não altere
sua targetSdkVersion. Por esse motivo, é importante revisar as principais mudanças na Tabela 1 e testar todas as correções implementadas para acomodar as mudanças.
Tabela 1. Mudanças importantes que afetam todos os apps executados em dispositivos Android 9.
| Mudar | 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 por reflexão. As 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 ver uma lista mais extensa de mudanças de comportamento para todos os apps executados no Android 9, consulte o documento Mudanças de comportamento.
Atualizar a versão de destino e usar os recursos do Android P
Esta seção explica como ativar o suporte completo para o Android 9 atualizando a targetSdkVersion para 28 e adicionando novos recursos disponíveis no Android 9.
Além de oferecer novas APIs, o Android 9 introduz algumas mudanças de
comportamento quando você atualiza sua targetSdkVersion para a versão 28. Como algumas mudanças de comportamento
podem exigir mudanças no código para evitar falhas, é necessário entender primeiro como o app pode ser
afetado ao mudar o 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 app para o Android 9. Portanto, conclua essas etapas primeiro.
Obter o Android 9 SDK
Você pode obter os pacotes de SDK para criar seu app com o Android 9 usando o Android Studio 3.1 ou versão mais recente. Se você ainda não precisa dos novos recursos do Android 9 e quer apenas compilar com essa versão da plataforma, use o Android Studio 3.1. O Android Studio 3.2 é totalmente compatível com os recursos do Android 9.
Testar seu aplicativo Android 9
Com as preparações acima concluídas, você pode criar seu app e testá-lo para garantir que ele funcione corretamente quando destinado ao Android 9 (API de nível 28). Esse também é um bom momento para analisar as Diretrizes principais de qualidade de apps e as Práticas recomendadas para testes.
Quando você cria seu app com a targetSdkVersion definida como "P",
há mudanças específicas da plataforma que você precisa conhecer. Algumas
dessas mudanças podem afetar significativamente o comportamento do seu app ou até mesmo fazer com que ele seja completamente corrompido, 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 a targetSdkVersion é definida como 28.
| Mudar | Resumo |
|---|---|
| Permissão para serviços de primeiro plano | Os apps que quiserem usar serviços em primeiro plano agora precisam solicitar a permissão FOREGROUND_SERVICE primeiro. 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 gera uma SecurityException. |
| Suspensão de uso das cifras do Bouncy Castle |
O Android 9 suspende o uso de várias cifras do provedor Bouncy Castle em favor das cifras fornecidas pelo provedor Conscrypt. As chamadas para getInstance() que
solicitam ao provedor Bouncy
Castle geram erros NoSuchAlgorithmException. Para resolver o erro, não especifique um provedor em getInstance() (ou seja, solicite a implementação padrão).
|
Remoção do acesso direto ao Build.serial
|
Os apps que precisam do identificador Build.serial agora precisam solicitar a permissão READ_PHONE_STATE
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 usando WebView, CookieManager ou qualquer outra API do pacote android.webkit, ele vai 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 SELinux por app em cada diretório de dados privado do app. O acesso direto ao diretório de dados de outro app por caminho agora não é permitido. Os apps podem continuar compartilhando dados usando mecanismos de IPC, incluindo a passagem de FDs. |
Para ver uma lista mais extensa de mudanças de comportamento para apps destinados ao Android 9, consulte o documento Mudanças de comportamento.
Para explorar os novos recursos e APIs disponíveis no Android 9, consulte Recursos e APIs do Android 9.