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 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 Tiles launch
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
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 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
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
Em apps destinados ao Android 14 (nível 34 da API) ou mais recentes, o sistema restringe ainda mais a permissão para que os apps iniciem atividades em segundo plano:
- Quando um app envia um
PendingIntent
usandoPendingIntent#send()
ou métodos semelhantes, o app precisa ativar se quiser conceder à própria atividade em segundo plano privilégios de inicialização para iniciar o 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 ativar o recurso, o app deve incluir o a sinalizaçãoBIND_ALLOW_ACTIVITY_STARTS
ao chamar obindService()
.
Essas mudanças ampliam o conjunto atual de restrições para proteger os usuários impedindo que apps maliciosos usem APIs para iniciar atividades disruptivas as atividades 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
对于以 Android 14(API 级别 34)或更高版本为目标平台的应用,在以下任一情况下,MediaProjection#createVirtualDisplay
会抛出 SecurityException
:
- 您的应用会缓存从
MediaProjectionManager#createScreenCaptureIntent
返回的Intent
,并将其多次传递给MediaProjectionManager#getMediaProjection
。 - 您的应用在同一
MediaProjection
实例上多次调用MediaProjection#createVirtualDisplay
。
您的应用必须在每次捕获会话之前征求用户同意。单次拍摄会话是指对 MediaProjection#createVirtualDisplay
的单次调用,且每个 MediaProjection
实例只能使用一次。
处理配置变更
如果您的应用需要调用 MediaProjection#createVirtualDisplay
来处理配置更改(例如屏幕方向或屏幕尺寸更改),您可以按照以下步骤更新现有 MediaProjection
实例的 VirtualDisplay
:
- 使用新的宽度和高度调用
VirtualDisplay#resize
。 - 为
VirtualDisplay#setSurface
提供具有新宽度和高度的新Surface
。
注册回调
您的应用应注册一个回调,以处理用户不同意继续拍摄会话的情况。为此,请实现 Callback#onStop
并让您的应用发布所有相关资源(例如 VirtualDisplay
和 Surface
)。
如果您的应用未注册此回调,MediaProjection#createVirtualDisplay
会在应用调用此回调时抛出 IllegalStateException
。
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.