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
如果您的应用以 Android 14(API 级别 34)或更高版本为目标平台,则必须为应用中的每个前台服务至少指定一项前台服务类型。您应选择一个能代表应用用例的前台服务类型。系统需要特定类型的前台服务满足特定用例。
如果应用中的用例与这些类型均不相关,强烈建议您迁移逻辑以使用 WorkManager 或用户发起的数据传输作业。
Aplicação da permissão BLUETOOTH_CONNECT em BluetoothAdapter
Android 14 enforces the BLUETOOTH_CONNECT
permission when calling the
BluetoothAdapter
getProfileConnectionState()
method for apps targeting
Android 14 (API level 34) or higher.
This method already required the BLUETOOTH_CONNECT
permission, but it was not
enforced. Make sure your app declares BLUETOOTH_CONNECT
in your app's
AndroidManifest.xml
file as shown in the following snippet and check that
a user has granted the permission before calling
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
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
对于以 Android 14 及更高版本为目标平台的应用,
TileService#startActivityAndCollapse(Intent)
已弃用,现在会抛出
调用时抛出异常。如果您的应用从功能块启动 activity,请使用
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
对于以 Android 14(API 级别 34)或更高版本为目标平台的应用,Android 会通过以下方式限制应用向内部应用组件发送隐式 intent:
- 隐式 intent 只能传送到导出的组件。应用必须使用显式 intent 传送到未导出的组件,或将该组件标记为已导出。
- 如果应用通过未指定组件或软件包的 intent 创建可变待处理 intent,系统会抛出异常。
这些变更可防止恶意应用拦截意在供应用内部组件使用的隐式 intent。
例如,下面是可以在应用的清单文件中声明的 intent 过滤器:
<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>
如果应用尝试使用隐式 intent 启动此 activity,则系统会抛出 ActivityNotFoundException
异常:
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"));
如需启动非导出的 activity,应用应改用显式 intent:
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
如果您的应用以 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
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
usandoPendingIntent#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 pacoteActivityOptions
comsetPendingIntentBackgroundActivityStartMode(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 flagBIND_ALLOW_ACTIVITY_STARTS
ao chamar o métodobindService()
.
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 peloMediaProjectionManager#createScreenCaptureIntent
e o transmite várias vezes paraMediaProjectionManager#getMediaProjection
. - O app invoca
MediaProjection#createVirtualDisplay
várias vezes na mesma instância deMediaProjection
.
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:
- Invoque
VirtualDisplay#resize
com a nova largura e altura. - Forneça um novo
Surface
com a nova largura e altura paraVirtualDisplay#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.