Mudanças de comportamento: apps destinados ao Android 15 ou versões mais recentes

Assim como as versões anteriores, o Android 15 inclui mudanças de comportamento que podem afetar seu app. As mudanças de comportamento a seguir se aplicam exclusivamente a apps destinados ao Android 15 ou versões mais recentes. Caso seu app seja direcionado ao Android 15 ou versões mais recentes, modifique o app 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 15, independente da targetSdkVersion do app.

Principal recurso

O Android 15 modifica ou expande vários recursos principais do sistema Android.

Mudanças nos serviços em primeiro plano

Estamos fazendo as seguintes mudanças nos serviços em primeiro plano com o Android 15.

Novo tipo de serviço em primeiro plano de processamento de mídia

O Android 15 introduz um novo tipo de serviço em primeiro plano, o mediaProcessing. Esse tipo de serviço é adequado para operações como transcodificação de arquivos de mídia. Por exemplo, um app de música pode fazer o download de um arquivo de áudio e precisar convertê-lo em um formato diferente antes de reproduzi-lo. Você pode usar um serviço em primeiro plano mediaProcessing para garantir que a conversão continue mesmo enquanto o app estiver em segundo plano.

Para mais informações sobre o tipo de serviço mediaProcessing, consulte Mudanças nos tipos de serviço em primeiro plano para o Android 15.

Restrições em BOOT_COMPLETED broadcast receivers que iniciam serviços em primeiro plano

Há novas restrições nos broadcast receivers BOOT_COMPLETED que iniciam serviços em primeiro plano. Os receptores BOOT_COMPLETED não têm permissão para iniciar estes tipos de serviços em primeiro plano:

Se um receptor BOOT_COMPLETED tentar iniciar qualquer um desses tipos de serviços em primeiro plano, o sistema vai gerar uma ForegroundServiceStartNotAllowedException.

Mudanças no momento em que os apps podem modificar o estado global do modo Não perturbe

Os apps direcionados ao Android 15 não podem mais mudar o estado ou a política global do Não perturbe em um dispositivo, seja modificando as configurações do usuário ou desativando o modo Não perturbe. Em vez disso, os apps precisam contribuir com um AutomaticZenRule, que o sistema combina em uma política global com o esquema most-restrictive-policy-wins atual. As chamadas para APIs existentes que anteriormente afetaram o estado global (setInterruptionFilter, setNotificationPolicy) resultam na criação ou atualização de um AutomaticZenRule implícito, que pode ser ativado e desativado dependendo do ciclo de chamadas dessas chamadas de API.

Essa mudança afeta apenas o comportamento observável se o app estiver chamando setInterruptionFilter(INTERRUPTION_FILTER_ALL) e espera que essa chamada desative um AutomaticZenRule que foi ativado anteriormente pelos proprietários.

Mudanças no OpenJDK 17

O Android 15 continua o trabalho de atualizar as principais bibliotecas do Android para se alinhar aos recursos das versões mais recentes do LTS do OpenJDK.

Uma dessas mudanças pode afetar a compatibilidade de apps destinados ao Android 15:

  • Mudanças nas APIs de formatação de string: a validação do índice de argumentos, flags, largura e precisão agora é mais rigorosa ao usar as seguintes APIs String.format() e Formatter.format():

    Por exemplo, a seguinte exceção é gerada quando um índice de argumentos de 0 é usado (%0 na string de formato):

    IllegalFormatArgumentIndexException: Illegal format argument index = 0

    Nesse caso, o problema pode ser corrigido usando um índice de argumentos de 1 (%1 na string de formato).

  • Mudanças no processamento do código de idioma: ao usar a API Locale, os códigos de idioma para hebraico, iídiche e indonésio não são mais convertidos para as formas obsoletas (hebraico: iw, iídiche: ji e indonésio: in). Ao especificar o código de idioma para uma dessas localidades, use os códigos da ISO 639-1 (hebraico: he e indonésio, iídiche: {1/indonésio: yi}id

  • Mudanças em sequências de int aleatórias: após as mudanças feitas em https://bugs.openjdk.org/Browse/JDK-8301574, os métodos Random.ints() a seguir agora retornam uma sequência de números diferente da que os métodos Random.nextInt():

    Geralmente, essa mudança não resulta em um comportamento de violação do app, mas seu código não pode esperar que a sequência gerada pelos métodos Random.ints() corresponda a Random.nextInt().

Segurança

O Android 15 inclui mudanças que promovem a segurança do sistema para ajudar a proteger apps e usuários contra apps maliciosos.

Lançamentos de atividades em segundo plano protegidas

Android 15 protects users from malicious apps and gives them more control over their devices by adding changes that prevent malicious background apps from bringing other apps to the foreground, elevating their privileges, and abusing user interaction. Background activity launches have been restricted since Android 10 (API level 29).

Block apps that don't match the top UID on the stack from launching activities

Malicious apps can launch another app's activity within the same task, then overlay themselves on top, creating the illusion of being that app. This "task hijacking" attack bypasses current background launch restrictions because it all occurs within the same visible task. To mitigate this risk, Android 15 adds a flag that blocks apps that don't match the top UID on the stack from launching activities. To opt in for all of your app's activities, update the allowCrossUidActivitySwitchFromBelow attribute in your app's AndroidManifest.xml file:

<application android:allowCrossUidActivitySwitchFromBelow="false" >

Other changes

In addition to the restriction for UID matching, these other changes are also included:

  • Change PendingIntent creators to block background activity launches by default. This helps prevent apps from accidentally creating a PendingIntent that could be abused by malicious actors.
  • Don't bring an app to the foreground unless the PendingIntent sender allows it. This change aims to prevent malicious apps from abusing the ability to start activities in the background. By default, apps are not allowed to bring the task stack to the foreground unless the creator allows background activity launch privileges or the sender has background activity launch privileges.
  • Control how the top activity of a task stack can finish its task. If the top activity finishes a task, Android will go back to whichever task was last active. Moreover, if a non-top activity finishes its task, Android will go back to the home screen; it won't block the finish of this non-top activity.
  • Prevent launching arbitrary activities from other apps into your own task. This change prevents malicious apps from phishing users by creating activities that appear to be from other apps.
  • Block non-visible windows from being considered for background activity launches. This helps prevent malicious apps from abusing background activity launches to display unwanted or malicious content to users. No newline at end of left file.

Intents mais seguras

Android 15 introduces new security measures to make intents safer and more robust. These changes are aimed at preventing potential vulnerabilities and misuse of intents that can be exploited by malicious apps. There are two main improvements to the security of intents in Android 15:

  • Match target intent-filters: Intents that target specific components must accurately match the target's intent-filter specifications. If you send an intent to launch another app's activity, the target intent component needs to align with the receiving activity's declared intent-filters.
  • Intents must have actions: Intents without an action will no longer match any intent-filters. This means that intents used to start activities or services must have a clearly defined action.

Kotlin


fun onCreate() {
    StrictMode.setVmPolicy(VmPolicy.Builder()
        .detectUnsafeIntentLaunch()
        .build()
    )
}

Java


public void onCreate() {
    StrictMode.setVmPolicy(new VmPolicy.Builder()
            .detectUnsafeIntentLaunch()
            .build());
}

Experiência do usuário e interface do sistema

O Android 15 inclui algumas mudanças que se destinam a criar uma experiência do usuário mais consistente e intuitiva.

Mudanças no encarte da janela

Há duas mudanças relacionadas às inserções de janela que serão lançadas no Android 15. Na versão Beta 1, a configuração de ponta a ponta será aplicada. Também haverá mudanças de configuração futuras, incluindo a configuração padrão das barras do sistema.

Aplicação de ponta a ponta

Os apps vão ficar de ponta a ponta por padrão em dispositivos com o Android 15 se forem destinados ao Android 15.

Um app direcionado ao Android 14 e que não está de ponta a ponta em um dispositivo Android 15.


Um app direcionado ao Android 15 e de ponta a ponta em um dispositivo Android 15. Este app usa principalmente componentes do Compose do Material 3 que aplicam encartes automaticamente. Essa tela não é afetada negativamente pela aplicação de ponta a ponta do Android 15.

Essa é uma alteração interruptiva que pode afetar negativamente a interface do app. As mudanças são as seguintes:

  • Barra de navegação da alça de gesto
    • Transparente por padrão.
    • O deslocamento inferior está desativado para que o conteúdo seja mostrado atrás da barra de navegação do sistema, a menos que encartes sejam aplicados.
    • setNavigationBarColor e R.attr#navigationBarColor foram descontinuados e não afetam a navegação por gestos.
    • setNavigationBarContrastEnforced e R.attr#navigationBarContrastEnforced continuam não tendo efeito na navegação por gestos.
  • navegação usando três botões
    • A opacidade é definida como 80% por padrão, e a cor pode corresponder ao plano de fundo da janela.
    • O deslocamento inferior é desativado para que o conteúdo seja mostrado atrás da barra de navegação do sistema, a menos que encartes sejam aplicados.
    • setNavigationBarColor e R.attr#navigationBarColor estão definidos para corresponder ao plano de fundo da janela por padrão. O segundo plano da janela precisa ser um drawable de cor para que esse padrão seja aplicado. Essa API foi descontinuada, mas continua a afetar a navegação com três botões.
    • setNavigationBarContrastEnforced e R.attr#navigationBarContrastEnforced são verdadeiros por padrão, o que adiciona um plano de fundo 80% opaco na navegação por três botões.
  • Barra de status
    • Transparente por padrão.
    • O deslocamento superior está desativado para que o conteúdo seja mostrado atrás da barra de status, a menos que encartes sejam aplicados.
    • O uso de setStatusBarColor e R.attr#statusBarColor foi descontinuado e não têm efeito no Android 15.
    • O uso de setStatusBarContrastEnforced e R.attr#statusBarContrastEnforced foi descontinuado, mas ainda tem efeito no Android 15.
  • Corte da tela
    • O layoutInDisplayCutoutMode das janelas não flutuantes precisa ser LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS. No Android 15 Beta 1, os apps falham com uma IllegalArgumentException se usarem SHORT_EDGES, NEVER ou DEFAULT (por exemplo, LAYOUT_IN_DISPLAY_CUTOUT_MODE_DEFAULT). No Android 15 Beta 2, SHORT_EDGES, NEVER e DEFAULT serão interpretados como ALWAYS para que os usuários não vejam uma barra preta causada pelo corte da tela e apareçam de ponta a ponta.

O exemplo a seguir mostra um app antes e depois do direcionamento ao Android 15, e antes e depois da aplicação de encartes.

Um app direcionado ao Android 14 e que não está de ponta a ponta em um dispositivo Android 15.
Um app direcionado ao Android 15 e que funciona de ponta a ponta em um dispositivo Android 15. No entanto, muitos elementos agora são ocultados pela barra de status, pela barra de navegação com três botões ou pelo corte da tela devido às restrições de ponta a ponta do Android 15. A interface oculta inclui a TopAppBar, FAB e itens de lista do Material 2.
Um app direcionado ao Android 15 fica de ponta a ponta em um dispositivo Android 15 e aplica encartes para que a interface não seja obstruída.

Se o app:

  • já está de ponta a ponta e aplica encartes, você não é afetado na maioria das vezes, exceto nos cenários a seguir. No entanto, mesmo que você ache que não foi afetado, recomendamos que teste o app.
    • Você tem uma janela não flutuante, como uma atividade que usa SHORT_EDGES, NEVER ou DEFAULT em vez de LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS. Se o app falhar na inicialização, isso pode ser devido à tela de apresentação. Você pode fazer upgrade da dependência core splashscreen para 1.2.0-alpha01 ou mais recente, definir window.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always ou testar com o Android 15 Beta 2 em vez do Beta 1.
    • Pode haver telas de tráfego mais baixo com interface obstruída. Verifique se essas telas menos visitadas não têm interface oculta. As telas de tráfego baixo incluem:
      • Telas de integração ou login
      • Páginas de configurações
  • não for de ponta a ponta, você provavelmente será afetado. Além dos cenários para apps que já estão de ponta a ponta, considere o seguinte:
    • Se o app usa componentes do Material 3 (androidx.compose.material3 no Compose, como TopAppBar, BottomAppBar e NavigationBar), esses componentes provavelmente não são afetados porque processam automaticamente encartes.
    • Se o app usa componentes do Material 2 (androidx.compose.material no Compose, esses componentes não processam encartes automaticamente. No entanto, você pode ter acesso aos encartes e aplicá-los manualmente. No androidx.compose.material 1.6.0 e mais recentes, use o parâmetro windowInsets para aplicar os encartes manualmente para BottomAppBar, TopAppBar, BottomNavigation e NavigationRail. Da mesma forma, use o parâmetro contentWindowInsets para Scaffold.
    • Se o app usa visualizações e componentes do Material Design (com.google.android.material, a maioria dos componentes do Material Design baseados em visualizações, como BottomNavigationView, BottomAppBar, NavigationRailView ou NavigationView) processa encartes e não exige trabalho extra. No entanto, será necessário adicionar android:fitsSystemWindows="true" se estiver usando AppBarLayout.
    • Para elementos combináveis personalizados, aplique os encartes manualmente como padding. Se o conteúdo estiver dentro de um Scaffold, você poderá consumir encartes usando os valores de padding do Scaffold. Caso contrário, aplique o padding usando uma das WindowInsets.
    • Se o app estiver usando visualizações e BottomSheet, SideSheet ou contêineres personalizados, aplique o padding usando ViewCompat.setOnApplyWindowInsetsListener. Para a RecyclerView, aplique o padding usando esse listener e adicione também clipToPadding="false".
  • precisam oferecer proteção personalizada em segundo plano para a navegação com três botões ou a barra de status, seu app precisa colocar um elemento combinável ou uma visualização atrás da barra do sistema usando WindowInsets.Type#tappableElement() para saber a altura da barra de navegação com três botões ou WindowInsets.Type#statusBars.

Consulte os guias Visualizações de borda a borda e do Edge a Edge Compose para mais considerações sobre a aplicação de encartes.

Veja a lista de APIs descontinuadas e desativadas:

  • R.attr#statusBarColor
  • R.attr#navigationBarColor
  • R.attr#navigationBarDividerColor
  • Janela#setDecorFitsSystemWindows
  • Janela#setStatusBarColor
  • Window#setStatusBarContrastEnforced
  • Janela#setNavigationBarColor
  • Janela#setNavigationBarDividerColor
  • Janela#getStatusBarColor
  • Window#getStatusBarContrastEnforced
  • Janela#getNavigationBarColor
  • Janela#getNavigationBarDividerColor

Configuração estável

Essa mudança não está disponível para teste na versão Beta 1, mas vai estar em breve.

Caso seu app seja destinado ao Android 15 ou versões mais recentes, o Configuration não vai excluir mais as barras do sistema. Se você usa o tamanho da tela na classe Configuration para o cálculo do layout, substitua-o por alternativas melhores, como ViewGroup, WindowInsets ou WindowMetricsCalculator, dependendo da sua necessidade.

Configuration está disponível desde a API 1. Normalmente, ele é recebido de Activity.onConfigurationChanged. Ela fornece informações como densidade, orientação e tamanhos da janela. Uma característica importante sobre os tamanhos de janela retornados de Configuration é que ele excluiu anteriormente as barras do sistema.

O tamanho da configuração é normalmente usado para seleção de recursos, como /res/layout-h500dp, e esse ainda é um caso de uso válido. No entanto, usá-lo para cálculo do layout sempre foi desencorajado. Se fizer isso, você deve se afastar dela agora. Substitua o uso de Configuration por algo mais adequado, dependendo do seu caso de uso.

Se você o usar para calcular o layout, use um ViewGroup adequado, como CoordinatorLayout ou ConstraintLayout. Se você o usar para determinar a altura da barra de navegação do sistema, use WindowInsets. Se você quiser saber o tamanho atual da janela do app, use computeCurrentWindowMetrics.

A lista a seguir descreve os campos afetados por essa alteração:

O atributo eleganteTextHeight adota o padrão de "true"

Em apps destinados ao Android 15, o atributo elegantTextHeight TextView se torna true por padrão, substituindo a fonte compacta usada por padrão por alguns scripts que têm métricas verticais grandes por uma mais legível. A fonte compacta foi introduzida para evitar a quebra de layouts. O Android 13 (nível 33 da API) evita muitas dessas falhas, permitindo que o layout de texto estenda a altura vertical usando o atributo fallbackLineSpacing.

No Android 15, a fonte compacta ainda permanece no sistema. Por isso, o app pode definir elegantTextHeight como false para ter o mesmo comportamento de antes, mas é provável que ela não tenha suporte em versões futuras. Portanto, se o app oferecer suporte a estes scripts: árabe, laosiano, mianmar, tâmil, gujarati, canarês, malaiala, oriá, télugo ou tailandês, teste o app definindo elegantTextHeight como true.

Comportamento de elegantTextHeight para apps destinados ao Android 14 (nível 34 da API) e versões anteriores.
Comportamento de elegantTextHeight para apps destinados ao Android 15.

A largura da TextView muda para formas de letras complexas.

Nas versões anteriores do Android, algumas fontes ou linguagens cursivas com formas complexas podem desenhar as letras na área do caractere anterior ou do próximo caractere. Em alguns casos, essas letras eram cortadas na posição inicial ou final. No Android 15 e versões mais recentes, uma TextView aloca largura para mostrar espaço suficiente para essas letras e permite que os apps solicitem mais paddings para a esquerda a fim de evitar cortes.

Como essa mudança afeta como um TextView decide a largura, a TextView aloca uma largura maior por padrão se o app for direcionado ao Android 15 ou versões mais recentes. É possível ativar ou desativar esse comportamento chamando a API setUseBoundsForWidth em TextView.

Como a adição de padding à esquerda pode causar um desalinhamento para layouts existentes, o padding não é adicionado por padrão, mesmo para apps destinados ao Android 15 ou versões mais recentes. No entanto, você pode adicionar padding extra para evitar o recorte chamando setShiftDrawingOffsetForStartOverhang.

Os exemplos abaixo mostram como essas mudanças podem melhorar o layout do texto para algumas fontes e idiomas.

Layout padrão para texto em inglês com fonte cursiva. Algumas das letras estão cortadas. Confira o XML correspondente:

<TextView
    android:fontFamily="cursive"
    android:text="java" />
Layout para o mesmo texto em inglês com largura e padding adicionais. Confira o XML correspondente:

<TextView
    android:fontFamily="cursive"
    android:text="java"
    android:useBoundsForWidth="true"
    android:shiftDrawingOffsetForStartOverhan="true" />
Layout padrão para texto em tailandês. Algumas letras estão cortadas. Confira o XML correspondente:

<TextView
    android:text="คอมพิวเตอร์" />
Layout para o mesmo texto em tailandês com largura e padding adicionais. Confira o XML correspondente:

<TextView
    android:text="คอมพิวเตอร์"
    android:useBoundsForWidth="true"
    android:shiftDrawingOffsetForStartOverhan="true" />

Altura da linha padrão com reconhecimento de localidade para EditText

In previous versions of Android, the text layout stretched the height of the text to meet the line height of the font that matched the current locale. For example, if the content was in Japanese, because the line height of the Japanese font is slightly larger than the one of a Latin font, the height of the text became slightly larger. However, despite these differences in line heights, the EditText element was sized uniformly, regardless of the locale being used, as illustrated in the following image:

Three boxes representing EditText elements that can contain text from English (en), Japanese (ja), and Burmese (my). The height of the EditText is the same, even though these languages have different line heights from each other.

For apps targeting Android 15, a minimum line height is now reserved for EditText to match the reference font for the specified Locale, as shown in the following image:

Three boxes representing EditText elements that can contain text from English (en), Japanese (ja), and Burmese (my). The height of the EditText now includes space to accommodate the default line height for these languages' fonts.

If needed, your app can restore the previous behavior by specifying the useLocalePreferredLineHeightForMinimum attribute to false, and your app can set custom minimum vertical metrics using the setMinimumFontMetrics API in Kotlin and Java.

Câmera e mídia

O Android 15 faz as seguintes mudanças no comportamento da câmera e da mídia para apps destinados ao Android 15 ou versões mais recentes.

Restrições à solicitação da seleção de áudio

Os apps direcionados ao Android 15 precisam ser o principal app ou executando um serviço em primeiro plano relacionado a áudio para solicitar a seleção de áudio. Se um app tentar solicitar a seleção quando não atender a um desses requisitos, a chamada vai retornar AUDIOFOCUS_REQUEST_FAILED.

Um serviço em primeiro plano é considerado relacionado ao áudio se o tipo dele é mediaPlayback, camera, microphone ou phoneCall.

Saiba mais sobre a seleção de áudio em Gerenciar a seleção de áudio.

Atualização das restrições não SDK

O Android 15 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 15, é possível que algumas dessas mudanças não afetem você imediatamente. No entanto, embora seja possível acessar algumas interfaces externas ao SDK dependendo do nível da API de destino, o uso de qualquer método ou campo não SDK sempre apresenta um alto risco de corromper o app.

Se você não tiver certeza se seu app usa interfaces não SDK, teste-o para descobrir. Se ele depende de interfaces não SDK, comece a planejar uma migração para alternativas SDK. No entanto, entendemos que alguns apps têm casos de uso válidos para interfaces não SDK. Caso você não encontre uma alternativa para deixar de usar uma interface não SDK em um recurso no app, solicite uma nova API pública.

e

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 15. Para saber mais sobre interfaces não SDK em geral, consulte Restrições para interfaces não SDK.