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 oferece 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 fase, você não usa novas APIs nem muda a
targetSdkVersiondo app, mas pequenas mudanças podem ser necessárias. - Direcionar 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ê tiver um dispositivo compatível, consiga a 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. Ele está no SDK Manager, em API do 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 aqui é garantir que seu app funcione no estado em que se encontra
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 ou
mudar sua 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 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 totalmente, mesmo que você não mude
a 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. Principais mudanças 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 os detalhes em Restrições para interfaces que não são SDK.
|
| 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 uma 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 a targetSdkVersion para a versão 28. Como algumas mudanças de comportamento
podem exigir mudanças de código para evitar falhas, primeiro é necessário entender como o app pode ser
afetado ao 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 app ao Android 9. Portanto, siga essas etapas primeiro.
Obter o Android 9 SDK
Você pode fazer o download dos pacotes de SDK para criar seu app com o Android 9 usando o Android Studio 3.1 ou versões mais recentes. Se você ainda não precisa dos novos recursos do Android 9 e quer compilar apenas nessa versão da plataforma, pode usar o Android Studio 3.1. O Android Studio 3.2 oferece suporte completo aos 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 ao ser destinado ao Android 9 (API de nível 28). Esse também é um bom momento para analisar as principais diretrizes de qualidade de apps e as práticas recomendadas para testes.
Ao criar seu app com o targetSdkVersion definido 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 corromper o app 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 a targetSdkVersion é definida como 28.
| Mudar | Resumo |
|---|---|
| Permissão para serviços de primeiro plano | Os apps que querem 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 descontinua várias cifras do provedor Bouncy Castle em favor das
fornecidas pelo provedor Conscrypt. As chamadas para getInstance() que
solicitam o provedor Bouncy
Castle geram erros NoSuchAlgorithmException. Para resolver os erros, 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 da 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 no diretório de dados particular de cada 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, inclusive pela 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.