Como nas versões anteriores, o Android 14 inclui mudanças de comportamento que podem afetar seu app. As seguintes mudanças de comportamento se aplicam exclusivamente a apps destinados ao Android 14 (nível 34 da API) ou mais recente. 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 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
Android 14 continues the work of refreshing Android's core libraries to align with the features in the latest OpenJDK LTS releases, including both library updates and Java 17 language support for app and platform developers.
A few of these changes can affect app compatibility:
- Changes to regular expressions: Invalid group references are now
disallowed to more closely follow the semantics of OpenJDK. You might see
new cases where an
IllegalArgumentException
is thrown by thejava.util.regex.Matcher
class, so make sure to test your app for areas that use regular expressions. To enable or disable this change while testing, toggle theDISALLOW_INVALID_GROUP_REFERENCE
flag using the compatibility framework tools. - UUID handling: The
java.util.UUID.fromString()
method now does more strict checks when validating the input argument, so you might see anIllegalArgumentException
during deserialization. To enable or disable this change while testing, toggle theENABLE_STRICT_VALIDATION
flag using the compatibility framework tools. - ProGuard issues: In some cases, the addition of the
java.lang.ClassValue
class causes an issue if you try to shrink, obfuscate, and optimize your app using ProGuard. The problem originates with a Kotlin library that changes runtime behaviour based on whetherClass.forName("java.lang.ClassValue")
returns a class or not. If your app was developed against an older version of the runtime without thejava.lang.ClassValue
class available, then these optimizations might remove thecomputeValue
method from classes derived fromjava.lang.ClassValue
.
O JobScheduler reforça o callback e o comportamento da 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 inicialização de blocos
For apps targeting 14 and higher,
TileService#startActivityAndCollapse(Intent)
is deprecated and now throws
an exception when called. If your app launches activities from tiles, use
TileService#startActivityAndCollapse(PendingIntent)
instead.
Privacidade
Acesso parcial a fotos e vídeos
Android 14 introduces Selected Photos Access, which allows users to grant apps access to specific images and videos in their library, rather than granting access to all media of a given type.
This change is only enabled if your app targets Android 14 (API level 34) or higher. If you don't use the photo picker yet, we recommend implementing it in your app to provide a consistent experience for selecting images and videos that also enhances user privacy without having to request any storage permissions.
If you maintain your own gallery picker using storage permissions and need to
maintain full control over your implementation, adapt your implementation
to use the new READ_MEDIA_VISUAL_USER_SELECTED
permission. If your app
doesn't use the new permission, the system runs your app in a compatibility
mode.
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
For apps targeting Android 14 (API level 34) or higher, Android restricts apps from sending implicit intents to internal app components in the following ways:
- Implicit intents are only delivered to exported components. Apps must either use an explicit intent to deliver to unexported components, or mark the component as exported.
- If an app creates a mutable pending intent with an intent that doesn't specify a component or package, the system throws an exception.
These changes prevent malicious apps from intercepting implicit intents that are intended for use by an app's internal components.
For example, here is an intent filter that could be declared in your app's manifest file:
<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>
If your app tried to launch this activity using an implicit intent, an
ActivityNotFoundException
exception would be thrown:
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"));
To launch the non-exported activity, your app should use an explicit intent instead:
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 mais recente e usar o carregamento de código dinâmico (DCL, na sigla em inglês), todos os arquivos carregados dinamicamente precisarão 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
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 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.
To learn more about the changes in this release of Android, see Updates to non-SDK interface restrictions in Android 14. To learn more about non-SDK interfaces generally, see Restrictions on non-SDK interfaces.