Como as versões anteriores, o Android 14 inclui mudanças de comportamento que podem afetar o 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 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
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
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 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
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 inicialização 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 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
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 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
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 código de carregamento dinâmico sempre que possível, já que isso aumenta muito o risco de um aplicativo ser 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
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()
.
O consentimento do usuário é necessário para cada sessão de captura da MediaProjection
For apps targeting Android 14 (API level 34) or higher, a SecurityException
is
thrown by MediaProjection#createVirtualDisplay
in either of the following
scenarios:
- Your app caches the
Intent
that is returned fromMediaProjectionManager#createScreenCaptureIntent
, and passes it multiple times toMediaProjectionManager#getMediaProjection
. - Your app invokes
MediaProjection#createVirtualDisplay
multiple times on the sameMediaProjection
instance.
Your app must ask the user to give consent before each capture session. A single
capture session is a single invocation on
MediaProjection#createVirtualDisplay
, and each MediaProjection
instance must
be used only once.
Handle configuration changes
If your app needs to invoke MediaProjection#createVirtualDisplay
to handle
configuration changes (such as the screen orientation or screen size changing),
you can follow these steps to update the VirtualDisplay
for the existing
MediaProjection
instance:
- Invoke
VirtualDisplay#resize
with the new width and height. - Provide a new
Surface
with the new width and height toVirtualDisplay#setSurface
.
Register a callback
Your app should register a callback to handle cases where the user doesn't grant
consent to continue a capture session. To do this, implement
Callback#onStop
and have your app release any related resources (such as
the VirtualDisplay
and Surface
).
If your app doesn't register this callback,
MediaProjection#createVirtualDisplay
throws an IllegalStateException
when your app invokes it.
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.