O Android 9 (nível de API 28) introduz novos recursos e APIs que podem ser utilizados em seus aplicativos, além de mudanças de comportamento. Este documento oferece uma visão geral das etapas para migrar os aplicativos 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 precisa usar novas APIs nem mudar a
targetSdkVersiondo aplicativo, mas algumas pequenas mudanças podem ser necessárias. - Direcionar para a nova plataforma, compilar o Android 9 SDK e compilar com os recursos do Android 9
Quando estiver tudo pronto para você desfrutar dos novos recursos da plataforma, atualize
targetSdkVersionpara28, verifique se o aplicativo continua funcionando normalmente e depois comece a usar as novas APIs.
Preparar um dispositivo que executa o Android 9
Se você tem um dispositivo compatível, obtenha a imagem do sistema Android 9 para seu dispositivo com o fabricante Clique aqui para obter imagens de fábrica para dispositivos Pixel. Instruções gerais para implantar uma imagem de sistema manualmente podem ser encontradas aqui.
Você também fazer o download da imagem de sistema do Android 9 para o Android Emulator. Ela pode ser encontrada no SDK Manager, na seção Android 9, com o nome de Google APIs Intel x86 Atom System Image.
Observação: A imagem de sistema para emulador do Android 9 está disponível para download no Android Studio 3.1 e em versões posteriores; o Android Studio 3.2 proporciona a compatibilidade máxima. Para obter mais informações, consulte Obter o SDK do Android 9.
Garantir a compatibilidade com o Android 9
O objetivo é garantir que seu aplicativo funcione da mesma forma no Android 9. Como algumas mudanças da plataforma podem afetar o comportamento do aplicativo, pode ser necessário fazer alguns ajustes, mas não é obrigatório usar novas APIs nem alterar targetSdkVersion.
Realizar testes de compatibilidade
Para a maior parte, testar a compatibilidade com o Android 9 envolve o mesmo tipo de testes que se realiza ao preparar o aplicativo para o lançamento. Essa é uma boa hora de rever as Orientações fundamentais de qualidade dos aplicativos e as Práticas recomendadas para testes.
Porém, há um outro aspecto nos testes: O Android 9 insere alterações na plataforma Android que podem afetar o comportamento do aplicativo ou corrompê-lo totalmente, mesmo que você não altere 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 aplicativos executados em dispositivos Android 9.
| Mudança | Resumo |
|---|---|
| Restrições para interfaces não SDK |
O acesso a interfaces não SDK específicas agora está bloqueado, seja o acesso direto, via JNI ou via reflexo. Tentativas de acessar interfaces restritas geram erros como NoSuchFieldException e NoSuchMethodException. Consulte Restrições para interfaces não SDK para obter detalhes.
|
| Remoção do provedor Crypto |
A partir do Android 9, o provedor Crypto JCA foi removido. Chamadas para SecureRandom.getInstance("SHA1PRNG", "Crypto") acionam 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 obter uma lista mais extensa de mudanças de comportamento para todos os aplicativos 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 total para o Android 9 ao atualizar a targetSdkVersion para 28 e adicionar os 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 28. Como algumas dessas mudanças podem exigir mudanças no código para evitar falhas, primeiro entenda como o aplicativo pode ser afetado quando mudar a targetSdkVersion lendo todas as mudanças de comportamento para aplicativos direcionados 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 executar essas etapas primeiro.
Obter o Android 9 SDK
Você pode obter os pacotes de SDK para compilar o aplicativo com o Android 9 usando o Android Studio 3.1 ou uma versão posterior. Se ainda não precisar dos novos recursos do Android 9 e quiser apenas compilar para essa versão da plataforma, você poderá usar o Android Studio 3.1. O Android Studio 3.2 oferece total suporte para os recursos do Android 9.
Para configurar qualquer uma dessas versões do Android Studio, siga as etapas documentadas em Configurar o SDK do Preview.
Testar seu aplicativo Android 9
Com as preparações acima concluídas, você pode compilar o aplicativo e testá-lo para garantir que ele funcione corretamente ao ser direcionado ao Android 9 (nível de API 28). Essa também é uma boa hora de rever as Orientações fundamentais de qualidade dos aplicativos e as Práticas recomendadas para testes.
Quando compilar o aplicativo com 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 aplicativo ou até corromper o aplicativo completamente, mesmo que você não implemente os novos recursos do 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 aplicativos quando targetSdkVersion é definida como “28".
| Mudança | Resumo |
|---|---|
| Permissão para serviços de primeiro plano | Aplicativos que desejam usar serviços de primeiro plano agora devem solicitar primeiro a permissão FOREGROUND_SERVICE. Essa é uma permissão normal, portanto, o sistema a concede automaticamente ao aplicativo que fez a solicitação. Iniciar um serviço de 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 cifras fornecidas pelo provedor Conscrypt. 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
|
Aplicativos que precisam do identificador Build.serial agora devem 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 aplicativo tiver mais de um processo que utiliza WebView, CookieManager ou qualquer outra API do 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 aplicativo com restrições de SELinux por aplicativo no diretório de dados privados de cada aplicativo. O acesso direto ao diretório de dados de outro aplicativo por meio do caminho agora está proibido. Os aplicativos podem continuar a compartilhar dados usando mecanismos de IPC, incluindo a passagem de FDs. |
Para obter uma lista mais extensa de mudanças de comportamento para os aplicativos direcionados 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.