Como as versões anteriores, o Android 15 inclui mudanças de comportamento que podem afetar seu app. As mudanças de comportamento abaixo se aplicam exclusivamente a apps destinados ao Android 15 ou versões mais recentes. Caso o app seja destinado 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
Comportamento de tempo limite do serviço em primeiro plano da sincronização de dados
O Android 15 introduz um novo comportamento de tempo limite da dataSync
para apps destinados ao
Android 15 ou versões mais recentes. Esse comportamento também se aplica ao novo tipo
de serviço em primeiro plano mediaProcessing
.
O sistema permite que os serviços dataSync
de um app sejam executados por um total de seis horas
em um período de 24 horas. Depois disso, o sistema chama o método
Service.onTimeout(int, int)
do serviço em execução (introduzido no Android
15). No momento, o serviço tem alguns segundos para chamar
Service.stopSelf()
. Quando Service.onTimeout()
é chamado, o
serviço não é mais considerado um serviço em primeiro plano. Se o serviço não
chamar Service.stopSelf()
, ocorrerá uma falha com esta mensagem de erro: "Um
serviço em primeiro plano de
<fgs_type> não foi interrompido dentro do tempo limite:
<component_name>". Na versão Beta 2, a mensagem de falha é mostrada como um
ANR, mas em uma versão Beta futura, essa mensagem de falha vai gerar uma exceção
personalizada.
Para evitar problemas com essa mudança de comportamento, siga um ou mais dos seguintes procedimentos:
- Faça com que seu serviço implemente o novo método
Service.onTimeout(int, int)
. Quando o app receber o callback, chamestopSelf()
em alguns segundos. Se você não interromper o app imediatamente, o sistema vai gerar uma falha. - Confira se os serviços
dataSync
do app não são executados por mais de 6 horas em qualquer período de 24 horas, a menos que o usuário interaja com o app, reiniciando o timer. - Inicie serviços em primeiro plano
dataSync
somente como resultado da interação direta do usuário. Como seu app está em primeiro plano quando o serviço é iniciado, seu serviço tem todas as seis horas após a migração para o segundo plano. - Em vez de usar um serviço em primeiro plano
dataSync
, use uma API alternativa.
Se os serviços em primeiro plano dataSync
do app tiverem sido executados por 6 horas nas últimas
24, não será possível iniciar outro serviço em primeiro plano dataSync
a menos que o usuário
tenha trazido o app para o primeiro plano, o que redefine o timer. Se você tentar
iniciar outro serviço em primeiro plano dataSync
, o sistema vai gerar
ForegroundServiceStartNotAllowedException
com uma mensagem de erro como "O limite de tempo já foi atingido para o tipo de serviço
em primeiro plano dataSync".
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.
O sistema permite que os serviços mediaProcessing
de um app sejam executados por um total de seis
horas em um período de 24 horas. Depois disso, o sistema chama o método
Service.onTimeout(int, int)
do serviço em execução (introduzido no Android
15). No momento, o serviço tem alguns segundos para chamar
Service.stopSelf()
. Se o serviço não
chamar Service.stopSelf()
, vai ocorrer uma falha com esta mensagem de erro: "Um
serviço em primeiro plano de <fgs_type> não foi interrompido dentro do tempo limite:
<component_name>". Na versão Beta 2, a mensagem de falha é mostrada como um
ANR, mas em uma versão Beta futura, essa mensagem de falha vai gerar uma exceção
personalizada.
Para evitar um ANR, siga um destes procedimentos:
- Faça com que seu serviço implemente o novo método
Service.onTimeout(int, int)
. Quando o app receber o callback, chamestopSelf()
em alguns segundos. Se você não interromper o app imediatamente, o sistema vai gerar uma falha. - Confira se os serviços
mediaProcessing
do app não são executados por mais de 6 horas em qualquer período de 24 horas, a menos que o usuário interaja com o app, reiniciando o timer. - Inicie serviços em primeiro plano
mediaProcessing
somente como resultado da interação direta do usuário. Como seu app está em primeiro plano quando o serviço é iniciado, seu serviço tem todas as seis horas após a migração para o segundo plano. - Em vez de usar um serviço em primeiro plano
mediaProcessing
, use uma API alternativa, como o WorkManager.
Se os serviços em primeiro plano mediaProcessing
do app tiverem sido executados por 6 horas nas
últimas 24, não será possível iniciar outro serviço em primeiro plano mediaProcessing
, a menos que
o usuário tenha levado o app ao primeiro plano, o que redefine o timer. Se você
tentar iniciar outro serviço em primeiro plano mediaProcessing
, o sistema vai gerar
ForegroundServiceStartNotAllowedException
com uma mensagem de erro como "O limite de tempo já foi esgotado para o tipo de serviço
em primeiro plano media Processing".
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: processamento de mídia.
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
.
Restrições para iniciar serviços em primeiro plano enquanto um app tem a permissão SYSTEM_ALERT_WINDOW
Antes, se um app tivesse a permissão SYSTEM_ALERT_WINDOW
, ele poderia iniciar
um serviço em primeiro plano mesmo que estivesse em segundo plano, conforme
discutido em isenções de restrições de inicialização em segundo plano.
Se um app for direcionado ao Android 15, essa isenção será mais restrita. O app agora precisa
ter a permissão SYSTEM_ALERT_WINDOW
e também uma janela de sobreposição
visível. Ou seja, o app precisa iniciar primeiro uma
janela TYPE_APPLICATION_OVERLAY
e ela
precisa estar visível antes de você iniciar um serviço em primeiro plano.
Se o app tentar iniciar um serviço em primeiro plano em segundo plano sem
atender a esses novos requisitos (e não tiver outra isenção), o
sistema vai gerar uma ForegroundServiceStartNotAllowedException
.
Se o app declarar a permissão SYSTEM_ALERT_WINDOW
e iniciar serviços em primeiro plano em segundo plano, ele poderá ser afetado por essa
mudança. Se o app receber uma ForegroundServiceStartNotAllowedException
, verifique
a ordem de operações dele e se ele já tem uma janela de sobreposição
ativa antes de tentar iniciar um serviço em primeiro plano em
segundo plano. Chame View.getWindowVisibility()
para conferir se a janela de sobreposição está visível
ou modifique View.onWindowVisibilityChanged()
para receber uma notificação sempre que a visibilidade mudar.
Mudanças na possibilidade de os apps modificarem 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()
eFormatter.format()
:String.format(String, Object[])
String.format(Locale, String, Object[])
Formatter.format(String, Object[])
Formatter.format(Locale, String, Object[])
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 tipo de componente de
Arrays.asList(...).toArray()
: ao usarArrays.asList(...).toArray()
, o tipo de componente da matriz resultante é umObject
, e não o tipo dos elementos da matriz. Portanto, o código abaixo gera umaClassCastException
:String[] elements = (String[]) Arrays.asList("one", "two").toArray();
Nesse caso, para preservar
String
como o tipo de componente na matriz resultante, useCollection.toArray(Object[])
:String[] elements = Arrays.asList("two", "one").toArray(new String[0]);
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étodosRandom.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 aRandom.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.
Inicializações de atividades seguras em segundo plano
O Android 15 protege os usuários contra apps maliciosos e oferece mais controle sobre os dispositivos, adicionando mudanças que impedem que apps maliciosos em segundo plano tragam outros apps para o primeiro plano, elevem privilégios e abusem da interação do usuário. As inicializações de atividades em segundo plano foram restritas desde o Android 10 (nível 29 da API).
Impedir que apps que não correspondam ao UID superior da pilha iniciem atividades
Apps maliciosos podem iniciar a atividade de outro app na mesma tarefa e
se sobrepor a si mesmos, criando a ilusão de ser esse app. Esse ataque de
invasão de tarefas ignora as restrições atuais de inicialização em segundo plano, porque tudo
ocorre na mesma tarefa visível. Para mitigar esse risco, o Android 15 adiciona uma
flag que impede que apps que não correspondam ao UID principal da pilha iniciem
atividades. Para ativar todas as atividades do seu app, atualize o atributo
allowCrossUidActivitySwitchFromBelow
no arquivo AndroidManifest.xml
do app:
<application android:allowCrossUidActivitySwitchFromBelow="false" >
As novas medidas de segurança estarão ativas se todas as condições a seguir forem verdadeiras:
- O app que executa o lançamento é destinado ao Android 15.
- O app na parte de cima da pilha de tarefas é destinado ao Android 15.
- Todas as atividades visíveis ativaram as novas proteções
Se as medidas de segurança estiverem ativadas, os apps poderão retornar à página inicial, em vez do último app visível, se concluírem a própria tarefa.
Outras mudanças
Além da restrição para a correspondência de UID, essas outras mudanças também estão incluídas:
- Mude os criadores de
PendingIntent
para bloquear inicializações de atividades em segundo plano por padrão. Isso ajuda a evitar que os apps criem acidentalmente umaPendingIntent
que possa ser abusada por agentes maliciosos. - Não coloque um app em primeiro plano, a menos que o remetente
PendingIntent
permita. Essa mudança tem como objetivo evitar que apps maliciosos abusem da capacidade de iniciar atividades em segundo plano. Por padrão, os apps não podem levar a pilha de tarefas para o primeiro plano, a menos que o criador permita privilégios de inicialização de atividades em segundo plano ou se o remetente tiver privilégios de inicialização de atividades em segundo plano. - Controlar como a atividade principal de uma pilha de tarefas pode concluir a tarefa. Se a atividade principal terminar uma tarefa, o Android voltará para a tarefa que esteve ativa pela última vez. Além disso, se uma atividade não principal concluir a tarefa, o Android vai voltar para a tela inicial. Isso não vai bloquear o término dessa atividade não superior.
- Evite a inicialização de atividades arbitrárias de outros apps na sua própria tarefa. Essa mudança impede que apps maliciosos usem o phishing, criando atividades que parecem ser de outros apps.
- Impede que janelas não visíveis sejam consideradas para inicializações de atividades em segundo plano. Isso ajuda a evitar que apps maliciosos usem lançamentos de atividades em segundo plano para mostrar conteúdo indesejado ou malicioso aos usuários.
Intents mais seguras
O Android 15 apresenta novas medidas de segurança para tornar as intents mais seguras e robustas. Essas alterações têm como objetivo evitar possíveis vulnerabilidades e o uso indevido de intents que podem ser exploradas por apps maliciosos. Há duas melhorias principais na segurança das intents no Android 15:
- Corresponder aos filtros de intent de destino:as intents que segmentam componentes específicos precisam corresponder com precisão às especificações do filtro de intent do destino. Se você enviar uma intent para iniciar a atividade de outro app, o componente da intent de destino precisará estar alinhado aos filtros de intent declarados da atividade de recebimento.
- Intents precisam ter ações:intents que não tenham uma ação não vão mais corresponder a nenhum filtro de intent. Isso significa que as intents usadas para iniciar atividades ou serviços precisam ter uma ação claramente definida.
- Intents pendentes:o criador da intent pendente é tratado como o remetente da intent delimitada, não como o remetente da intent pendente.
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 têm como objetivo criar uma experiência do usuário mais consistente e intuitiva.
Mudanças no encarte da janela
Há duas mudanças relacionadas a encartes de janela no Android 15: de ponta a ponta é aplicada por padrão, e também há mudanças de configuração, como a configuração padrão das barras do sistema.
Aplicação de ponta a ponta
Por padrão, os apps são exibidos de ponta a ponta em dispositivos com o Android 15, caso sejam destinados ao Android 15 (nível 35 da API).
Essa é uma mudança interruptiva que pode afetar negativamente a interface do app. As mudanças afetam estas áreas da interface:
- Barra de navegação da alça de gestos
- Transparente por padrão.
- O deslocamento inferior é desativado para que o conteúdo fique atrás da barra de navegação do sistema, a menos que os 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 afetando a navegação por gestos.
- Navegação com três botões
- Opacidade definida como 80% por padrão, com cores possivelmente correspondentes ao plano de fundo da janela.
- Deslocamento inferior desativado para que o conteúdo fique atrás da barra de navegação do sistema, a menos que encartes sejam aplicados.
setNavigationBarColor
eR.attr#navigationBarColor
são definidos para corresponder ao segundo plano 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 afetando 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 opaco à navegação com três botões.
- Barra de status
- Transparente por padrão.
- O deslocamento superior está desativado para que o conteúdo fique atrás da barra de status, a menos que encartes sejam aplicados.
setStatusBarColor
eR.attr#statusBarColor
foram descontinuados e não têm efeito no Android 15.setStatusBarContrastEnforced
eR.attr#statusBarContrastEnforced
foram descontinuados, mas ainda têm efeito no Android 15.
- Corte da tela
layoutInDisplayCutoutMode
das janelas não flutuantes precisam serLAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS
.SHORT_EDGES
,NEVER
eDEFAULT
são interpretados comoALWAYS
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 abaixo mostra um app antes e depois de ser direcionado ao Android 15 (nível 35 da API), além de antes e depois de aplicar encartes.
O que verificar se o app já está de ponta a ponta
Se o app já estiver de ponta a ponta e aplicar encartes, você na maioria das vezes não será afetado, exceto nos cenários a seguir. No entanto, mesmo que você acredite que não será afetado, recomendamos testar o app.
- Você tem uma janela não flutuante, como uma
Activity
que usaSHORT_EDGES
,NEVER
ouDEFAULT
em vez deLAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS
. Se o app falha na inicialização, isso pode ser devido à tela de apresentação. É possível fazer upgrade da dependência da tela de apresentação principal para 1.2.0-alpha01 ou uma versão mais recente ou definirwindow.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always
. - Pode haver telas de menor tráfego com interface obstruída. Verifique se essas
telas menos visitadas não têm uma interface obstruída. Telas com menos tráfego incluem:
- Telas de integração ou login
- Páginas de configurações
O que verificar se o app ainda não está de ponta a ponta
Se seu app ainda não estiver de ponta a ponta, é provável que você seja afetado. Além dos cenários para apps que já são de ponta a ponta, considere o seguinte:
- Se o app usa componentes do Material 3 (
androidx.compose.material3
) no Compose, comoTopAppBar
,BottomAppBar
eNavigationBar
, esses componentes provavelmente não são afetados porque processam encartes automaticamente. - Caso seu app use componentes do Material 2 (
androidx.compose.material
) no Compose, esses componentes não processam encartes automaticamente. No entanto, é possível ter acesso aos encartes e aplicá-los manualmente. No androidx.compose.material 1.6.0 e mais recentes, use o parâmetrowindowInsets
para aplicar os encartes manualmente aBottomAppBar
,TopAppBar
,BottomNavigation
eNavigationRail
. Da mesma forma, use o parâmetrocontentWindowInsets
paraScaffold
. - Caso seu app use visualizações e componentes do Material Design
(
com.google.android.material
), a maioria dos componentes do Material baseados em visualizações, comoBottomNavigationView
,BottomAppBar
,NavigationRailView
ouNavigationView
, processa encartes e não exige mais trabalho. No entanto, é necessário adicionarandroid:fitsSystemWindows="true"
se estiver usandoAppBarLayout
. - Para elementos combináveis personalizados, aplique os encartes manualmente como padding. Se o
conteúdo estiver em um
Scaffold
, será possível consumir encartes usando os valores de preenchimento deScaffold
. Caso contrário, aplique o padding usando uma dasWindowInsets
. - Se o app usa visualizações e contêineres
BottomSheet
,SideSheet
ou personalizados, aplique o padding usandoViewCompat.setOnApplyWindowInsetsListener
. ParaRecyclerView
, aplique o padding usando esse listener e também adicioneclipToPadding="false"
.
O que verificar se o app precisa oferecer proteção personalizada em segundo plano
Caso seu app precise oferecer proteção personalizada em segundo plano para a navegação com três botões ou
a barra de status, posicione um elemento combinável ou uma visualização atrás da barra de sistema
usando WindowInsets.Type#tappableElement()
para conferir a altura
da barra de navegação de três botões ou WindowInsets.Type#statusBars
.
Outros recursos de ponta a ponta
Consulte os guias Visualizações de borda a borda e Edge Compose para conferir mais considerações sobre a aplicação de encartes.
APIs descontinuadas
As seguintes APIs foram descontinuadas:
R.attr#enforceStatusBarContrast
R.attr#navigationBarColor
R.attr#navigationBarDividerColor
R.attr#statusBarColor
Window#getNavigationBarColor
Window#getNavigationBarDividerColor
Window#getStatusBarColor
Window#isStatusBarContrastEnforced
Window#setDecorFitsSystemWindows
Window#setNavigationBarColor
Window#setNavigationBarDividerColor
Window#setStatusBarColor
Window#setStatusBarContrastEnforced
Configuração estável
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ê usá-lo 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 emConfiguration
. Isso 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 assume o padrão como verdadeiro
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
.
Mudanças na largura da TextView em formas de letra 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.
Altura da linha padrão com reconhecimento de localidade para EditText
Nas versões anteriores do Android, o layout do texto aumentava a altura do
texto para ficar de acordo com a altura da linha da fonte correspondente à localidade atual. Por
exemplo, se o conteúdo estava em japonês, como a altura da linha da fonte
japonês é um pouco maior do que a da fonte latina, a altura do texto
ficou um pouco maior. No entanto, apesar dessas diferenças na altura das linhas, o
elemento EditText
foi dimensionado de maneira uniforme, independente
da localidade usada, conforme ilustrado na imagem abaixo:
Para apps destinados ao Android 15, uma altura mínima de linha agora é reservada para
EditText
para corresponder à fonte de referência da localidade especificada, conforme mostrado na
imagem abaixo:
Se necessário, o app pode restaurar o comportamento anterior especificando o atributo
useLocalePreferredLineHeightForMinimum
para false
e definir métricas verticais mínimas personalizadas usando a API
setMinimumFontMetrics
em Kotlin e Java.
Câmera e mídia
O Android 15 faz as mudanças abaixo no comportamento de câmera e 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.
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.