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.

Observação: o Android 14 apresenta tipos de serviço em primeiro plano para casos de uso de saúde e mensagens remotas. O sistema também reserva novos tipos para serviços curtos, casos de uso especiais e isenções do sistema.

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

Android 14 将继续更新 Android 的核心库，以与最新 OpenJDK LTS 版本中的功能保持一致，包括适合应用和平台开发者的库更新和 Java 17 语言支持。

以下变更可能会影响应用兼容性：

• 对正则表达式的更改：现在，为了更严格地遵循 OpenJDK 的语义，不允许无效的组引用。您可能会看到 java.util.regex.Matcher 类抛出 IllegalArgumentException 的新情况，因此请务必测试应用中使用正则表达式的情形。如需在测试期间启用或停用此变更，请使用兼容性框架工具切换 DISALLOW_INVALID_GROUP_REFERENCE 标志。
• UUID 处理：现在，验证输入参数时，java.util.UUID.fromString() 方法会执行更严格的检查，因此您可能会在反序列化期间看到 IllegalArgumentException。如需在测试期间启用或停用此变更，请使用兼容性框架工具切换 ENABLE_STRICT_VALIDATION 标志。
• ProGuard 问题：有时，在您尝试使用 ProGuard 缩减、混淆和优化应用时，添加 java.lang.ClassValue 类会导致问题。问题源自 Kotlin 库，该库会根据 Class.forName("java.lang.ClassValue") 是否会返回类更改运行时行为。如果您的应用是根据没有 java.lang.ClassValue 类的旧版运行时开发的，则这些优化可能会将 computeValue 方法从派生自 java.lang.ClassValue 的类中移除。

O JobScheduler reforça o comportamento de callback e de 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 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

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. Em apps destinados ao Android 14 (nível 34 da API) ou mais recente, essa permissão é limitada a apps que fornecem apenas 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 conferir se o app tem a permissão. Caso ele não tenha, é possível usar a nova intent ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT para abrir 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

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

Os apps e serviços direcionados ao Android 14 (nível 34 da API) ou mais recente e 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 lançados 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 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().

É necessário ter consentimento do usuário para cada sessão de captura do MediaProjection

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 armazena em cache o Intent retornado pelo MediaProjectionManager#createScreenCaptureIntent e o transmite várias vezes para MediaProjectionManager#getMediaProjection.
• O app invoca MediaProjection#createVirtualDisplay várias vezes na mesma instância de MediaProjection.

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

Android 14 包含更新后的受限非 SDK 接口列表（基于与 Android 开发者之间的协作以及最新的内部测试）。在限制使用非 SDK 接口之前，我们会尽可能确保有可用的公开替代方案。

如果您的应用并非以 Android 14 为目标平台，其中一些变更可能不会立即对您产生影响。然而，虽然您目前仍可以使用一些非 SDK 接口（具体取决于应用的目标 API 级别），但只要您使用任何非 SDK 方法或字段，终归存在导致应用出问题的显著风险。

如果您不确定自己的应用是否使用了非 SDK 接口，则可以测试您的应用来进行确认。如果您的应用依赖于非 SDK 接口，您应该开始计划迁移到 SDK 替代方案。然而，我们知道某些应用具有使用非 SDK 接口的有效用例。如果您无法为应用中的某项功能找到使用非 SDK 接口的替代方案，应请求新的公共 API。

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.