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

Assim como as versões anteriores, o Android 14 inclui mudanças de comportamento que podem afetar o app. As mudanças de comportamento a seguir 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 a versões mais recentes, faça as modificações necessárias 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

Caso o app seja direcionado ao Android 14 (nível 34 da API) ou versões mais recentes, é necessário especificar pelo menos um tipo de serviço em primeiro plano para cada serviço em primeiro plano no app. Escolha um tipo de serviço em primeiro plano que represente o caso de uso do app. O sistema espera que serviços em primeiro plano com um tipo específico atendam 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 no BluetoothAdapter

对于以 Android 14（API 级别 34）或更高版本为目标平台的应用，Android 14 会在调用 BluetoothAdapter getProfileConnectionState() 方法时强制执行 BLUETOOTH_CONNECT 权限。

此方法已需要 BLUETOOTH_CONNECT 权限，但未被强制执行。请确保您的应用在应用的 AndroidManifest.xml 文件中声明 BLUETOOTH_CONNECT（如以下代码段所示），并在调用 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 callback e o comportamento da rede

Desde a introdução, o JobScheduler espera que o app retorne da onStartJob ou da onStopJob em alguns segundos. Em versões anteriores ao Android 14, se um job for executado por muito tempo, ele será interrompido e vai falhar silenciosamente. Se o app for 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 vai acionar um ANR com a mensagem de erro "Sem resposta para onStartJob" ou "Sem resposta para onStopJob". Considere migrar para o WorkManager, que fornece suporte ao processamento assíncrono ou à migração de qualquer trabalho pesado para uma linha de execução em segundo plano.

JobScheduler também introduz um requisito para declarar a permissão ACCESS_NETWORK_STATE ao usar a restrição setRequiredNetworkType ou setRequiredNetwork. Se o app não declarar a permissão ACCESS_NETWORK_STATE ao programar o job e for direcionado ao Android 14 ou versões mais recentes, isso resultará em uma SecurityException.

API Tiles launch

Para apps destinados ao Android 14 e versões mais recentes, o TileService#startActivityAndCollapse(Intent) foi descontinuado e agora gera uma exceção quando chamado. Se o app iniciar atividades em 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 aos 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ó vai ser ativada se o app for direcionado ao Android 14 (nível 34 da API) ou versões mais recentes. 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 melhora a privacidade do usuário sem precisar solicitar permissões de armazenamento.

Se você mantém seu próprio seletor de galeria usando permissões de armazenamento e precisa ter controle total sobre a implementação, adapte a 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 o executará 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. 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 impede que os apps enviem 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 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 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

如果您的应用以 Android 14（API 级别 34）或更高版本为目标平台，并使用动态代码加载 (DCL) 功能，则必须将所有动态加载的文件标记为只读。否则，系统会抛出异常。我们建议应用尽可能避免动态加载代码，因为这样做会大大增加应用因代码注入或代码篡改而遭到入侵的风险。

如果必须动态加载代码，请使用以下方法，在动态文件（例如 DEX、JAR 或 APK 文件）打开并写入任何内容之前立即将其设为只读：

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);

处理已存在的动态加载文件

为防止系统对现有动态加载的文件抛出异常，我们建议您先删除并重新创建文件，然后再尝试在应用中重新动态加载这些文件。重新创建文件时，请按照上述指南在写入时将文件标记为只读。或者，您可以将现有文件重新标记为只读，但在这种情况下，我们强烈建议您先验证文件的完整性（例如，对照可信值检查文件的签名）以保护应用免遭恶意操作的影响。

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

Para apps destinados ao Android 14 (nível 34 da API) ou versões mais recentes, o sistema restringe ainda mais quando os apps podem iniciar atividades em segundo plano:

• Quando um app envia uma PendingIntent usando PendingIntent#send() ou métodos semelhantes, ele precisa ativar se quiser conceder à própria atividade em segundo plano privilégios de inicialização para iniciar a intent pendente. Para ativar, 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(), o app visível precisa ativar o recurso para conceder à própria atividade em segundo plano privilégios de inicialização ao 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, impedindo que apps maliciosos usem APIs para iniciar atividades interruptivas 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().

Consentimento do usuário necessário para cada sessão de captura do MediaProjection

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:

• O app armazena em cache o Intent retornado de MediaProjectionManager#createScreenCaptureIntent e o transmite várias vezes para MediaProjectionManager#getMediaProjection.
• Seu app invoca MediaProjection#createVirtualDisplay várias vezes na mesma instância de MediaProjection.

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.