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
O Android 14 aplica a permissão BLUETOOTH_CONNECT
ao chamar o
Método BluetoothAdapter
getProfileConnectionState()
para segmentação de apps
Android 14 (nível 34 da API) ou mais recente.
Esse método já exigia a permissão BLUETOOTH_CONNECT
, mas ela não
aplicadas. Verifique se o app declara BLUETOOTH_CONNECT
no
AndroidManifest.xml
como mostrado no snippet a seguir 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
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
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 restringe apps do envio de 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 especificar um componente ou pacote, o sistema 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
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
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
usandoPendingIntent#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 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()
, 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 flagBIND_ALLOW_ACTIVITY_STARTS
ao chamar o métodobindService()
.
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()
.
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.