Mudanças de comportamento: apps destinados ao Android 14 ou mais recente

Como as versões anteriores, o Android 14 inclui mudanças de comportamento que podem afetar seu app. As mudanças de comportamento abaixo se aplicam exclusivamente a apps destinados ao Android 14 (nível 34 da API) ou versões mais recentes. Caso seu app seja direcionado ao Android 14 ou versões mais recentes, faça modificações para oferecer suporte a esses comportamentos de forma adequada, quando aplicável.

Consulte também a lista de mudanças de comportamento que afetam todos os apps executados no Android 14, independente da targetSdkVersion do app.

Principal recurso

Os tipos de serviço em primeiro plano são obrigatórios

如果您的应用以 Android 14（API 级别 34）或更高版本为目标平台，则必须为应用中的每项前台服务指定至少一个前台服务类型。您应该选择一个能够代表应用用例的前台服务类型。系统需要特定类型的前台服务满足特定用例。

如果应用中的用例与这些类型均不相关，强烈建议您迁移逻辑以使用 WorkManager 或用户发起的数据传输作业。

Aplicação da permissão BLUETOOTH_CONNECT no BluetoothAdapter

O Android 14 aplica a permissão BLUETOOTH_CONNECT ao chamar o Método BluetoothAdapter getProfileConnectionState() para segmentação de apps Android 14 (nível 34 da API) ou mais recente.

Esse método já exigia a permissão BLUETOOTH_CONNECT, mas ela não aplicadas. Verifique se o app declara BLUETOOTH_CONNECT no AndroidManifest.xml como mostrado no snippet a seguir e verifique se um usuário concedeu a permissão antes de chamar getProfileConnectionState.

<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />

Atualizações do OpenJDK 17

O Android 14 continua o trabalho de atualizar as principais bibliotecas do Android para se alinhar aos recursos das versões mais recentes do LTS do OpenJDK, incluindo atualizações de bibliotecas e suporte à linguagem Java 17 para desenvolvedores de apps e plataformas.

Algumas dessas mudanças podem afetar a compatibilidade do app:

  • Mudanças em expressões regulares: referências inválidas a grupos agora não são permitidas para seguir mais de perto a semântica do OpenJDK. Será possível conferir novos casos em que uma IllegalArgumentException é gerada pela classe java.util.regex.Matcher. Portanto, teste o app para áreas que usam expressões regulares. Para ativar ou desativar essa mudança durante os testes, configure a flag DISALLOW_INVALID_GROUP_REFERENCE usando as ferramentas do framework de compatibilidade.
  • Processamento de UUID: o método java.util.UUID.fromString() agora faz verificações mais rigorosas ao validar o argumento de entrada. Por isso, talvez uma IllegalArgumentException apareça durante desserialização. Para ativar ou desativar essa mudança durante os testes, configure a flag ENABLE_STRICT_VALIDATION usando as ferramentas do framework de compatibilidade.
  • Problemas com o ProGuard: em alguns casos, a adição da classe java.lang.ClassValue causará um problema se você tentar reduzir, ofuscar e otimizar o app usando o ProGuard. O problema se origina em uma biblioteca Kotlin que muda o comportamento no momento de execução, dependendo se Class.forName("java.lang.ClassValue") retorna uma classe ou não. Se o app tiver sido desenvolvido em uma versão mais antiga do ambiente de execução sem a classe java.lang.ClassValue disponível, essas otimizações poderão remover o método computeValue das classes derivadas de java.lang.ClassValue.

O JobScheduler reforça o comportamento dos callbacks e da rede

Desde a introdução, o JobScheduler espera que o app retorne de onStartJob ou onStopJob em alguns segundos. Antes do Android 14, se um job for executado por muito tempo, ele será interrompido e falhará silenciosamente. Caso o app seja direcionado ao Android 14 (nível 34 da API) ou versões mais recentes e exceder o tempo concedido na linha de execução principal, o app acionará um ANR com a mensagem de erro "Sem resposta para onStartJob" ou "Sem resposta para onStopJob".

Esse ANR pode ocorrer devido a dois cenários: 1: Há trabalho bloqueando a linha de execução principal, impedindo que os callbacks onStartJob ou onStopJob sejam executados e concluídos dentro do limite de tempo esperado. 2. O desenvolvedor está executando um trabalho de bloqueio no JobScheduler callback onStartJob ou onStopJob, impedindo que ele seja para serem concluídas dentro do limite de tempo esperado.

Para resolver o problema no 1, é necessário depurar melhor o que está bloqueando a linha de execução principal quando o ANR ocorrer, ApplicationExitInfo#getTraceInputStream() para acessar a tombstone rastrear quando o ANR ocorrer. Se você conseguir reproduzir o ANR manualmente, você pode gravar um rastro do sistema e inspecioná-lo usando Android Studio ou Perfetto para entender melhor o que está sendo executado no na linha de execução principal quando o ANR ocorre. Isso pode acontecer ao usar a API JobScheduler diretamente ou a biblioteca androidx WorkManager.

Para resolver o problema 2, considere migrar para o WorkManager, que oferece suporte para encapsulamento de qualquer processamento em onStartJob ou onStopJob em uma linha de execução assíncrona.

JobScheduler também introduz um requisito para declarar o Permissão ACCESS_NETWORK_STATE se você estiver usando setRequiredNetworkType ou setRequiredNetwork restrição. Caso o app não declare a Permissão ACCESS_NETWORK_STATE ao programar o job e estiver segmentando Android 14 ou mais recente, isso vai gerar uma SecurityException.

API Tiles launch

Para apps destinados ao Android 14 ou mais recente, O TileService#startActivityAndCollapse(Intent) foi descontinuado e agora gera uma exceção quando chamado. Se o app iniciar atividades de blocos, use TileService#startActivityAndCollapse(PendingIntent).

Privacidade

Acesso parcial a fotos e vídeos

Android 14 引入了所选照片访问权限，可让用户授权应用访问其媒体库中的特定图片和视频，而不是授予对指定类型的所有媒体的访问权限。

仅当您的应用以 Android 14（API 级别 34）或更高版本为目标平台时，才会启用此变更。如果您还没有使用照片选择器，建议您在应用中实现该选择器，以便在选择图片和视频时提供一致的体验，同时还可以加强用户隐私保护，而无需请求任何存储权限。

如果您使用存储权限维护自己的图库选择器，并且需要完全控制您的实现，请调整您的实现，以使用新的 READ_MEDIA_VISUAL_USER_SELECTED 权限。如果您的应用不使用新权限，系统会在兼容模式下运行应用。

Experiência do usuário

Notificações seguras de intent de tela cheia

Com o Android 11 (nível 30 da API), era possível que qualquer app usasse Notification.Builder.setFullScreenIntent para enviar intents de tela cheia enquanto o smartphone estava bloqueado. Era possível conceder essa permissão automaticamente na instalação do app declarando a permissão USE_FULL_SCREEN_INTENT no AndroidManifest.

As notificações de intent de tela cheia são projetadas para notificações de altíssima prioridade que exigem a atenção imediata do usuário, como uma ligação recebida ou configurações de despertador definidas pelo usuário. Para apps destinados ao Android 14 (nível 34 da API) ou versões mais recentes, os apps que podem usar essa permissão são limitados àqueles que fornecem chamadas e alarmes. A Google Play Store revoga as permissões USE_FULL_SCREEN_INTENT padrão para todos os apps que não se encaixam nesse perfil. O prazo para essas mudanças na política é 31 de maio de 2024.

Essa permissão continua ativada para apps instalados no smartphone antes da atualização para o Android 14. Os usuários podem ativar ou desativar essa permissão.

Você pode usar a nova API NotificationManager.canUseFullScreenIntent para verificar se o app tem a permissão. Caso contrário, ele poderá usar a nova intent ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT para iniciar a página de configurações em que os usuários podem conceder a permissão.

Segurança

Restrições a intents implícitas e pendentes

Em apps destinados ao Android 14 (nível 34 da API) ou versões mais recentes, o Android restringe apps do envio de intents implícitas para componentes internos do app destas maneiras:

  • Intents implícitas são entregues apenas a componentes exportados. Os apps precisam usar uma intent explícita para enviar para componentes não exportados ou marcar o componente como exportado.
  • Se um app criar uma intent pendente mutável com uma intent que especificar um componente ou pacote, o sistema gerará uma exceção.

Essas mudanças impedem que apps maliciosos interceptem intents implícitas destinadas ao uso de componentes internos de um app.

Confira um filtro de intent que pode ser declarado no arquivo de manifesto do app:

<activity
    android:name=".AppActivity"
    android:exported="false">
    <intent-filter>
        <action android:name="com.example.action.APP_ACTION" />
        <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</activity>

Se o app tentar iniciar essa atividade usando uma intent implícita, uma exceção será gerada:

Kotlin

// Throws an exception when targeting Android 14.
context.startActivity(Intent("com.example.action.APP_ACTION"))

Java

// Throws an exception when targeting Android 14.
context.startActivity(new Intent("com.example.action.APP_ACTION"));

Para iniciar a atividade não exportada, o app precisa usar uma intent explícita:

Kotlin

// This makes the intent explicit.
val explicitIntent =
        Intent("com.example.action.APP_ACTION")
explicitIntent.apply {
    package = context.packageName
}
context.startActivity(explicitIntent)

Java

// This makes the intent explicit.
Intent explicitIntent =
        new Intent("com.example.action.APP_ACTION")
explicitIntent.setPackage(context.getPackageName());
context.startActivity(explicitIntent);

Os broadcast receivers registrados no ambiente de execução precisam especificar o comportamento de exportação

Os apps e serviços direcionados ao Android 14 (nível 34 da API) ou versões mais recentes que usam receptores registrados pelo contexto precisam especificar uma flag para indicar se o receptor precisa ou não ser exportado para todos os outros apps no dispositivo: RECEIVER_EXPORTED ou RECEIVER_NOT_EXPORTED, respectivamente. Esse requisito ajuda a proteger os apps contra vulnerabilidades de segurança usando os recursos desses receptores introduzidos no Android 13.

Exceção para receptores que recebem apenas transmissões do sistema

Se o app estiver registrando um receptor apenas para transmissões do sistema usando métodos Context#registerReceiver, como Context#registerReceiver(), ele não precisará especificar uma flag ao registrar o receptor.

Carregamento mais seguro de código dinâmico

Se o app for direcionado ao Android 14 (nível 34 da API) ou versões mais recentes e usar código dinâmico carregando (DCL), todos os arquivos carregados dinamicamente precisam ser marcados como somente leitura. Caso contrário, o sistema vai gerar uma exceção. Recomendamos que os apps evitem código de carregamento dinâmico sempre que possível, já que isso aumenta muito o risco de um aplicativo ser por injeção ou adulteração de código.

Se você precisar carregar código dinamicamente, use a seguinte abordagem para definir o arquivo carregado dessa forma (como um arquivo DEX, JAR ou APK) como somente leitura assim que ele for aberto e antes de qualquer conteúdo ser programado:

Kotlin

val jar = File("DYNAMICALLY_LOADED_FILE.jar")
val os = FileOutputStream(jar)
os.use {
    // Set the file to read-only first to prevent race conditions
    jar.setReadOnly()
    // Then write the actual file content
}
val cl = PathClassLoader(jar, parentClassLoader)

Java

File jar = new File("DYNAMICALLY_LOADED_FILE.jar");
try (FileOutputStream os = new FileOutputStream(jar)) {
    // Set the file to read-only first to prevent race conditions
    jar.setReadOnly();
    // Then write the actual file content
} catch (IOException e) { ... }
PathClassLoader cl = new PathClassLoader(jar, parentClassLoader);

Processar arquivos carregados dinamicamente que já existem

Para evitar que exceções sejam geradas para arquivos carregados dinamicamente já existentes, recomendamos excluir e recriar os arquivos antes de tentar carregá-los dessa forma no app. Ao recriar os arquivos, siga as orientações anteriores para marcá-los como somente leitura no momento da gravação. Como alternativa, rotule novamente os arquivos existentes como somente leitura, mas, nesse caso, recomendamos verificar a integridade dos arquivos primeiro, comparando a assinatura do arquivo com um valor confiável, por exemplo, para ajudar a proteger seu app contra ações maliciosas.

Mais restrições para o início de atividades em segundo plano

Em apps destinados ao Android 14 (nível 34 da API) ou mais recentes, o sistema restringe ainda mais a permissão para que os apps iniciem atividades em segundo plano:

  • Quando um app envia um PendingIntent usando PendingIntent#send() ou métodos semelhantes, o app precisa ativar se quiser conceder à própria atividade em segundo plano privilégios de inicialização para iniciar o intent pendente. Para ativar o recurso, o app precisa transmitir um pacote ActivityOptions com setPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED).
  • Quando um app visível vincula um serviço de outro app que está em segundo plano usando o método bindService(), ele precisa ativar um recurso para conceder às próprias atividades em segundo plano os privilégios de inicialização do serviço vinculado. Para ativar o recurso, o app deve incluir o a sinalização BIND_ALLOW_ACTIVITY_STARTS ao chamar o bindService().

Essas mudanças ampliam o conjunto atual de restrições para proteger os usuários impedindo que apps maliciosos usem APIs para iniciar atividades disruptivas as atividades em segundo plano.

Travessia de caminhos de arquivo ZIP

Em apps destinados ao Android 14 (nível 34 da API) ou versões mais recentes, o Android evita a vulnerabilidade de travessia de caminho ZIP da seguinte maneira: ZipFile(String) e ZipInputStream.getNextEntry() geram uma ZipException se os nomes de entrada dos arquivos ZIP contêm ".." ou começam com "/".

Os apps podem desativar essa validação chamando dalvik.system.ZipPathValidator.clearCallback().

Para apps destinados ao Android 14 (nível 34 da API) ou versões mais recentes, uma SecurityException é gerada por MediaProjection#createVirtualDisplay em um dos seguintes cenários:

Seu app precisa pedir o consentimento do usuário antes de cada sessão de captura. Uma única sessão de captura é uma invocação única em MediaProjection#createVirtualDisplay, e cada instância de MediaProjection precisa ser usada apenas uma vez.

Processar mudanças de configuração

Se o app precisar invocar MediaProjection#createVirtualDisplay para processar mudanças de configuração, como mudança de orientação ou tamanho da tela, siga estas etapas para atualizar o VirtualDisplay da instância MediaProjection já existente:

  1. Invoque VirtualDisplay#resize com a nova largura e altura.
  2. Forneça um novo Surface com a nova largura e altura para VirtualDisplay#setSurface.

Registrar um callback

Seu app precisa registrar um callback para processar casos em que o usuário não dá consentimento para continuar uma sessão de captura. Para fazer isso, implemente Callback#onStop e faça com que o app libere todos os recursos relacionados, como VirtualDisplay e Surface.

Se o app não registrar esse callback, o MediaProjection#createVirtualDisplay vai gerar uma IllegalStateException quando o invocar.

Atualização das restrições não SDK

O Android 14 inclui listas atualizadas de interfaces não SDK restritas com base na colaboração com desenvolvedores Android e nos testes internos mais recentes. Antes de restringirmos interfaces não SDK, sempre que possível, garantimos que haja alternativas públicas disponíveis.

Caso seu app não seja destinado ao Android 14, é possível que algumas dessas mudanças não afetem você imediatamente. No entanto, embora atualmente seja possível usar algumas interfaces não SDK (dependendo do nível da API de destino do app), o uso de qualquer método ou campo não SDK sempre apresenta um alto risco de corromper o app.

Se você não sabe se o app usa interfaces não SDK, é possível testá-lo para descobrir. Se ele depende de interfaces não SDK, planeje uma migração para alternativas SDK. No entanto, entendemos que alguns apps têm casos de uso válidos para interfaces não SDK. Se você não encontrar uma alternativa para deixar de usar uma interface não SDK em um recurso no app, solicite uma nova API pública.

Para saber mais sobre as mudanças dessa versão do Android, consulte Atualizações para restrições de interfaces não SDK no Android 14. Para saber mais sobre interfaces não SDK em geral, consulte Restrições para interfaces não SDK.