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

Como nas versões anteriores, o Android 14 inclui mudanças de comportamento que podem afetar seu app. As mudanças de comportamento a seguir se aplicam exclusivamente a apps que segmentam o Android 14 (nível 34 da API) ou versões mais recentes. Caso seu app seja direcionado ao Android 14 ou a 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

Se o app for destinado ao Android 14 (nível 34 da API) ou mais recente, ele precisará especificar pelo menos um tipo de serviço em primeiro plano para cada serviço em primeiro plano. Escolha um tipo que represente o caso de uso do app. O sistema espera que serviços em primeiro plano com um tipo específico satisfaça um caso de uso específico.

Se um caso de uso no app não estiver associado a nenhum desses tipos, é recomendável migrar a lógica para usar o WorkManager ou jobs de transferência de dados iniciados pelo usuário.

Aplicação da permissão BLUETOOTH_CONNECT em BluetoothAdapter

O Android 14 aplica a permissão BLUETOOTH_CONNECT ao chamar o método BluetoothAdapter getProfileConnectionState() para apps destinados ao Android 14 (nível 34 da API) ou versões mais recentes.

Esse método já exigia a permissão BLUETOOTH_CONNECT, mas ela não foi aplicada. Verifique se o app declara BLUETOOTH_CONNECT no arquivo AndroidManifest.xml, conforme mostrado no snippet abaixo, 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 de callback e de rede

Since its introduction, JobScheduler expects your app to return from onStartJob or onStopJob within a few seconds. Prior to Android 14, if a job runs too long, the job is stopped and fails silently. If your app targets Android 14 (API level 34) or higher and exceeds the granted time on the main thread, the app triggers an ANR with the error message "No response to onStartJob" or "No response to onStopJob".

This ANR may be a result of 2 scenarios: 1. There is work blocking the main thread, preventing the callbacks onStartJob or onStopJob from executing and completing within the expected time limit. 2. The developer is running blocking work within the JobScheduler callback onStartJob or onStopJob, preventing the callback from completing within the expected time limit.

To address #1, you will need to further debug what is blocking the main thread when the ANR occurs, you can do this using ApplicationExitInfo#getTraceInputStream() to get the tombstone trace when the ANR occurs. If you're able to manually reproduce the ANR, you can record a system trace and inspect the trace using either Android Studio or Perfetto to better understand what is running on the main thread when the ANR occurs. Note that this can happen when using JobScheduler API directly or using the androidx library WorkManager.

To address #2, consider migrating to WorkManager, which provides support for wrapping any processing in onStartJob or onStopJob in an asynchronous thread.

JobScheduler also introduces a requirement to declare the ACCESS_NETWORK_STATE permission if using setRequiredNetworkType or setRequiredNetwork constraint. If your app does not declare the ACCESS_NETWORK_STATE permission when scheduling the job and is targeting Android 14 or higher, it will result in a SecurityException.

API de lançamento de blocos

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

O Android 14 apresenta o acesso a fotos selecionadas, que permite que os usuários concedam a apps acesso a imagens e vídeos específicos na biblioteca, em vez de conceder acesso a todas as mídias de um determinado tipo.

Essa mudança só será ativada se o app for destinado ao Android 14 (nível 34 da API) ou mais recente. Se você ainda não usa o seletor de fotos, recomendamos implementá-lo no app para oferecer uma experiência consistente de seleção de imagens e vídeos que também melhore a privacidade do usuário sem precisar solicitar nenhuma permissão de armazenamento.

Se você mantiver seu próprio seletor de galeria usando permissões de armazenamento e precisar manter o controle total sobre a implementação, adapte sua implementação para usar a nova permissão READ_MEDIA_VISUAL_USER_SELECTED. Se o app não usar a nova permissão, o sistema vai executá-lo em um modo de compatibilidade.

Experiência do usuário

Notificações seguras de intent de tela cheia

With Android 11 (API level 30), it was possible for any app to use Notification.Builder.setFullScreenIntent to send full-screen intents while the phone is locked. You could auto-grant this on app install by declaring USE_FULL_SCREEN_INTENT permission in the AndroidManifest.

Full-screen intent notifications are designed for extremely high-priority notifications demanding the user's immediate attention, such as an incoming phone call or alarm clock settings configured by the user. For apps targeting Android 14 (API level 34) or higher, apps that are allowed to use this permission are limited to those that provide calling and alarms only. The Google Play Store revokes default USE_FULL_SCREEN_INTENT permissions for any apps that don't fit this profile. The deadline for these policy changes is May 31, 2024.

This permission remains enabled for apps installed on the phone before the user updates to Android 14. Users can turn this permission on and off.

You can use the new API NotificationManager.canUseFullScreenIntent to check if your app has the permission; if not, your app can use the new intent ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT to launch the settings page where users can grant the permission.

Segurança

Restrições a intents implícitas e pendentes

Para apps destinados ao Android 14 (nível 34 da API) ou mais recentes, o Android impede que intents implícitas sejam enviadas para componentes internos do app das seguintes 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 não especifica um componente ou pacote, o sistema vai 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 ActivityNotFoundException será gerada:

Kotlin

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

Java

// Throws an ActivityNotFoundException 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

Apps and services that target Android 14 (API level 34) or higher and use context-registered receivers are required to specify a flag to indicate whether or not the receiver should be exported to all other apps on the device: either RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED, respectively. This requirement helps protect apps from security vulnerabilities by leveraging the features for these receivers introduced in Android 13.

Exception for receivers that receive only system broadcasts

If your app is registering a receiver only for system broadcasts through Context#registerReceiver methods, such as Context#registerReceiver(), then it shouldn't specify a flag when registering the receiver.

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 carregar código dinamicamente sempre que possível, porque isso aumenta muito o risco de comprometimento do app 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 recente, o sistema restringe ainda mais a permissão para que os apps iniciem atividades em segundo plano:

  • Quando um app envia uma PendingIntent usando PendingIntent#send() ou métodos semelhantes, ele precisa ativar um recurso para conceder à própria atividade em segundo plano os privilégios de inicialização para iniciar a 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 isso, o app precisa incluir a flag BIND_ALLOW_ACTIVITY_STARTS ao chamar o método bindService().

Essas mudanças ampliam o conjunto existente de restrições para proteger os usuários. Elas impedem que apps maliciosos usem APIs para iniciar atividades que causam interrupções em segundo plano.

Travessia de caminhos de arquivo ZIP

Em apps destinados ao Android 14 (nível 34 da API) ou mais recente, o Android evita a vulnerabilidade da travessia de caminhos de arquivo ZIP da seguinte forma: ZipFile(String) e ZipInputStream.getNextEntry() geram uma ZipException quando os nomes dos arquivos ZIP tê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 mais recente, uma SecurityException é gerada por MediaProjection#createVirtualDisplay em um dos seguintes cenários:

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

Gerenciar mudanças de configuração

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

  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 concede consentimento para continuar uma sessão de captura. Para fazer isso, implemente Callback#onStop e faça o app liberar todos os recursos relacionados, como VirtualDisplay e Surface.

Se o app não registrar esse callback, MediaProjection#createVirtualDisplay vai gerar uma IllegalStateException quando o app 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.