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 para processamento de mídia
- Restrições em
BOOT_COMPLETED
broadcast receivers que iniciam serviços em primeiro plano
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:
dataSync
camera
mediaPlayback
phoneCall
mediaProjection
microphone
(essa restrição está em vigor paramicrophone
desde o Android 14)
Se um receptor BOOT_COMPLETED
tentar iniciar qualquer um desses tipos de serviços
em primeiro plano, o sistema vai gerar uma ForegroundServiceStartNotAllowedException
.
Experiência do usuário
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.
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
eR.attr#navigationBarColor
foram descontinuados e não afetam a navegação por gestos.setNavigationBarContrastEnforced
eR.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
eR.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
eR.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
eR.attr#statusBarColor
foi descontinuado e não têm efeito no Android 15. - O uso de
setStatusBarContrastEnforced
eR.attr#statusBarContrastEnforced
foi descontinuado, mas ainda tem efeito no Android 15.
- Corte da tela
- O
layoutInDisplayCutoutMode
das janelas não flutuantes precisa serLAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS
. Caso contrário, os apps vão falhar com uma IllegalArgumentException. ALWAYS é a única opção permitida para que os usuários não vejam uma barra preta causada pelo corte da tela no modo paisagem e, portanto, apareça de borda a borda.
- O
O exemplo a seguir mostra um app antes e depois do direcionamento ao Android 15, e antes e depois da aplicação de encartes.
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.
- O app falha porque você tem uma janela não flutuante, como uma atividade
que usa
SHORT_EDGES, NEVER
ouDEFAULT
em vez deLAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS
. Se o app falhar na inicialização, isso pode ocorrer devido à tela de apresentação. Até que uma correção esteja disponível, definawindow.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always
. - 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
- O app falha porque você tem uma janela não flutuante, como uma atividade
que usa
- 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
eNavigationBar
), 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
eNavigationRail
. Da mesma forma, use o parâmetrocontentWindowInsets
paraScaffold
. - 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
ouNavigationView
) processa encartes e não exige trabalho extra. No entanto, será necessário adicionarandroid:fitsSystemWindows="true"
se estiver usandoAppBarLayout
. - 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émclipToPadding="false"
.
- Se o app usa componentes do Material 3 (androidx.compose.material3 no
Compose, como
- 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 ouWindowInsets.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:
- Os tamanhos
Configuration.screenWidthDp
escreenHeightDp
não excluem mais as barras do sistema. Configuration.smallestScreenWidthDp
é afetado indiretamente pelas mudanças emscreenWidthDp
escreenHeightDp
.- A
Configuration.orientation
é indiretamente afetada por mudanças emscreenWidthDp
escreenHeightDp
em dispositivos quase quadrados. Display.getSize(Point)
é afetado indiretamente pelas mudanças na configuração. Ele foi descontinuado no nível 30 da API e mais recentes.- O
Display.getMetrics()
já funciona dessa forma desde o nível 33 da API.
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
.
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.
ePara 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.