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
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.
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 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
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 classejava.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 flagDISALLOW_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 umaIllegalArgumentException
apareça durante desserialização. Para ativar ou desativar essa mudança durante os testes, configure a flagENABLE_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 seClass.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 classejava.lang.ClassValue
disponível, essas otimizações poderão remover o métodocomputeValue
das classes derivadas dejava.lang.ClassValue
.
O JobScheduler reforça o comportamento dos callbacks e 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
Android 14 引入了所选照片访问权限,可让用户授权应用访问其媒体库中的特定图片和视频,而不是授予对指定类型的所有媒体的访问权限。
仅当您的应用以 Android 14(API 级别 34)或更高版本为目标平台时,才会启用此变更。如果您还没有使用照片选择器,建议您在应用中实现该选择器,以便在选择图片和视频时提供一致的体验,同时还可以加强用户隐私保护,而无需请求任何存储权限。
如果您使用存储权限维护自己的图库选择器,并且需要完全控制您的实现,请调整您的实现,以使用新的 READ_MEDIA_VISUAL_USER_SELECTED
权限。如果您的应用不使用新权限,系统会在兼容模式下运行应用。
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
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
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
如果您的应用以 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
For apps targeting Android 14 (API level 34) or higher, the system further restricts when apps are allowed to start activities from the background:
- When an app sends a
PendingIntent
usingPendingIntent#send()
or similar methods, the app must opt in if it wants to grant its own background activity launch privileges to start the pending intent. To opt in, the app should pass anActivityOptions
bundle withsetPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED)
. - When a visible app binds a service of another app that's in the background
using the
bindService()
method, the visible app must now opt in if it wants to grant its own background activity launch privileges to the bound service. To opt in, the app should include theBIND_ALLOW_ACTIVITY_STARTS
flag when calling thebindService()
method.
These changes expand the existing set of restrictions to protect users by preventing malicious apps from abusing APIs to start disruptive activities from the background.
Travessia de caminhos de arquivo ZIP
For apps targeting Android 14 (API level 34) or higher, Android prevents the Zip
Path Traversal Vulnerability in the following way:
ZipFile(String)
and
ZipInputStream.getNextEntry()
throws a
ZipException
if zip file entry names contain ".." or start
with "/".
Apps can opt-out from this validation by calling
dalvik.system.ZipPathValidator.clearCallback()
.
O consentimento do usuário é necessário para cada sessão de captura da 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 deMediaProjectionManager#createScreenCaptureIntent
e o transmite várias vezes paraMediaProjectionManager#getMediaProjection
. - Seu app invoca
MediaProjection#createVirtualDisplay
várias vezes na mesma instância deMediaProjection
.
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:
- 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 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.