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
Android 15 引入了一种新的前台服务类型,即 mediaProcessing
。此服务类型适用于对媒体文件进行转码等操作。例如,媒体应用可能会下载音频文件,并需要将其转换为其他格式才能播放。您可以使用 mediaProcessing
前台服务,确保即使应用在后台运行时转换也会继续。
系统允许应用的 mediaProcessing
服务在 24 小时内共运行 6 小时,之后系统会调用正在运行的服务的 Service.onTimeout(int, int)
方法(在 Android 15 中引入)。此时,该服务有几秒钟时间来调用 Service.stopSelf()
。如果服务未调用 Service.stopSelf()
,系统会抛出内部异常。系统会在 Logcat 中记录异常,并显示以下消息:
Fatal Exception: android.app.RemoteServiceException: "A foreground service of
type mediaProcessing did not stop within its timeout: [component name]"
为避免出现异常,您可以执行以下操作之一:
- 让您的服务实现新的
Service.onTimeout(int, int)
方法。当应用收到回调时,请务必在几秒钟内调用stopSelf()
。(如果您不立即停止应用,系统会生成故障。) - 确保应用的
mediaProcessing
服务在任何 24 小时内的运行时间都不超过 6 小时(除非用户与应用互动并重置计时器)。 - 仅通过直接的用户互动来启动
mediaProcessing
前台服务;由于您的应用在服务启动时位于前台,因此服务会在应用进入后台后的 6 小时内完整运行。 - 请使用替代 API(例如 WorkManager),而不是使用
mediaProcessing
前台服务。
如果您的应用的 mediaProcessing
前台服务在过去 24 天内运行了 6 个小时,除非用户将您的应用调到前台(这会重置计时器),否则您无法启动其他 mediaProcessing
前台服务。如果您尝试启动另一个 mediaProcessing
前台服务,系统会抛出 ForegroundServiceStartNotAllowedException
,并显示类似“Time limit already exhausted for the service type mediaProcessing”之类的错误消息。
如需详细了解 mediaProcessing
服务类型,请参阅 Android 15 前台服务类型的变更:媒体处理。
测试
如需测试应用的行为,即使您的应用并非以 Android 15 为目标平台(只要该应用在 Android 15 设备上运行),您也可以启用媒体处理超时。如需启用超时功能,请运行以下 adb
命令:
adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name
您还可以调整超时期限,更轻松地测试应用在达到此限制时的行为。如需设置新的超时期限,请运行以下 adb
命令:
adb shell device_config put activity_manager media_processing_fgs_timeout_duration duration-in-milliseconds
Restrições em BOOT_COMPLETED
broadcast receivers que iniciam serviços em primeiro plano
针对启动前台服务的 BOOT_COMPLETED
广播接收器存在新的限制。BOOT_COMPLETED
接收器不能启动以下类型的前台服务:
dataSync
camera
mediaPlayback
phoneCall
mediaProjection
microphone
(从 Android 14 开始,系统针对microphone
实施了此限制)
如果 BOOT_COMPLETED
接收器尝试启动任何此类前台服务,系统会抛出 ForegroundServiceStartNotAllowedException
。
Restrições para iniciar serviços em primeiro plano enquanto um app tem a permissão SYSTEM_ALERT_WINDOW
以前,如果应用拥有 SYSTEM_ALERT_WINDOW
权限,那么即使该应用当前在后台运行,它也可以启动前台服务(如不受后台启动限制的豁免中所述)。
如果应用以 Android 15 为目标平台,此豁免范围现在会更严格。该应用现在需要具有 SYSTEM_ALERT_WINDOW
权限,并且还具有可见的叠加窗口。也就是说,在您启动前台服务之前,应用需要先启动 TYPE_APPLICATION_OVERLAY
窗口,并且该窗口必须处于可见状态。
如果您的应用尝试在不满足这些新要求的情况下从后台启动前台服务(并且没有其他某些豁免),系统会抛出 ForegroundServiceStartNotAllowedException
。
如果您的应用声明 SYSTEM_ALERT_WINDOW
权限并从后台启动前台服务,则可能会受到此项变更的影响。如果您的应用收到 ForegroundServiceStartNotAllowedException
,请检查应用的操作顺序,并确保应用在尝试从后台启动前台服务之前已具备有效的叠加窗口。您可以通过调用 View.getWindowVisibility()
检查叠加层窗口当前是否可见,也可以替换 View.onWindowVisibilityChanged()
,以便在可见性发生变化时收到通知。
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 na API OpenJDK
O Android 15 continua atualizando as principais bibliotecas 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 (nível 35 da API):
Mudanças nas APIs de formatação de string: a validação do índice, das flags, da largura e da precisão do argumento 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 exceção a seguir é gerada quando um índice de argumento 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 argumento 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 agora é 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 às 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 de ISO 639-1 (hebraico:yi
1 e indonésio).he
id
Mudanças em sequências int aleatórias: após as mudanças feitas em https://bugs.openjdk.org/browse/JDK-8301574 (link em inglês), os seguintes métodos
Random.ints()
agora retornam uma sequência de números diferente da que os métodosRandom.nextInt()
fazem:Geralmente, essa mudança não resulta em comportamentos corrompidos no app, mas seu código não espera que a sequência gerada pelos métodos
Random.ints()
corresponda aRandom.nextInt()
.
A nova API SequencedCollection
pode afetar a compatibilidade do app
depois que você atualizar o compileSdk
na configuração do build do app para usar o
Android 15 (nível 35 da API):
Colisão com as funções de extensão
MutableList.removeFirst()
eMutableList.removeLast()
emkotlin-stdlib
O tipo
List
(link em inglês) em Java é mapeado para o tipoMutableList
em Kotlin. Como as APIsList.removeFirst()
eList.removeLast()
foram introduzidas no Android 15 (nível 35 da API), o compilador Kotlin resolve chamadas de função, por exemplo,list.removeFirst()
, estaticamente para as novas APIsList
em vez de para as funções de extensão emkotlin-stdlib
.Se um app for recompilado com
compileSdk
definido como35
eminSdk
definido como34
ou anterior e, em seguida, o app for executado no Android 14 e versões anteriores, um erro de execução será gerado:java.lang.NoSuchMethodError: No virtual method removeFirst()Ljava/lang/Object; in class Ljava/util/ArrayList;
A opção de lint
NewApi
existente no Plug-in do Android para Gradle pode capturar esses novos usos da API../gradlew lint
MainActivity.kt:41: Error: Call requires API level 35 (current min is 34): java.util.List#removeFirst [NewApi] list.removeFirst()Para corrigir a exceção de execução e os erros de lint, as chamadas de função
removeFirst()
eremoveLast()
podem ser substituídas porremoveAt(0)
eremoveAt(list.lastIndex)
, respectivamente no Kotlin. Se você está usando o Android Studio Ladybug | 2024.1.3 ou mais recente, ela também fornece uma opção de correção rápida para esses erros.Considere remover
@SuppressLint("NewApi")
elintOptions { disable 'NewApi' }
se a opção de lint tiver sido desativada.Colisão com outros métodos em Java
Novos métodos foram adicionados aos tipos existentes, por exemplo,
List
eDeque
. Esses novos métodos podem não ser compatíveis com os métodos com o mesmo nome e tipos de argumento em outras interfaces e classes. No caso de uma colisão de assinatura de método com incompatibilidade, o compiladorjavac
gera um erro de tempo de build. Por exemplo:Exemplo de erro 1:
javac MyList.java
MyList.java:135: error: removeLast() in MyList cannot implement removeLast() in List public void removeLast() { ^ return type void is not compatible with Object where E is a type-variable: E extends Object declared in interface ListExemplo de erro 2:
javac MyList.java
MyList.java:7: error: types Deque<Object> and List<Object> are incompatible; public class MyList implements List<Object>, Deque<Object> { both define reversed(), but with unrelated return types 1 errorExemplo de erro 3:
javac MyList.java
MyList.java:43: error: types List<E#1> and MyInterface<E#2> are incompatible; public static class MyList implements List<Object>, MyInterface<Object> { class MyList inherits unrelated defaults for getFirst() from types List and MyInterface where E#1,E#2 are type-variables: E#1 extends Object declared in interface List E#2 extends Object declared in interface MyInterface 1 errorPara corrigir esses erros de build, a classe que implementa essas interfaces precisa substituir o método por um tipo de retorno compatível. Por exemplo:
@Override public Object getFirst() { return List.super.getLast(); }
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
Android 15 通过添加变更来防止恶意后台应用将其他应用带到前台、提升其权限和滥用用户互动,从而保护用户免受恶意应用的侵害,并使用户能够更好地控制其设备。从 Android 10(API 级别 29)开始,后台 activity 启动已受到限制。
阻止与堆栈中顶部 UID 不匹配的应用启动 activity
恶意应用可以在同一任务内启动另一个应用的 activity,然后叠加在上面,制造出作为该应用的错觉。这种“任务劫持”攻击绕过了当前的后台启动限制,因为它都发生在同一可见任务内。为了降低这种风险,Android 15 添加了一个标志,用于阻止与堆栈上的顶级 UID 不匹配的应用启动 activity。如需选择启用应用的所有 activity,请更新应用的 AndroidManifest.xml
文件中的 allowCrossUidActivitySwitchFromBelow
属性:
<application android:allowCrossUidActivitySwitchFromBelow="false" >
如果满足以下所有条件,则新的安全措施就会生效:
- 执行启动的应用以 Android 15 为目标平台。
- 任务堆栈顶部的应用以 Android 15 为目标平台。
- 所有可见的活动均已启用新版保护措施
如果启用了安全措施,应用如果完成自己的任务,可能会返回主屏幕,而不是返回上一个可见的应用。
其他变更
除了 UID 匹配的限制之外,还包含以下其他更改:
- 将
PendingIntent
创建者更改为默认阻止后台 activity 启动。这有助于防止应用意外创建可能会被恶意操作者滥用的PendingIntent
。 - 请勿将应用置于前台,除非
PendingIntent
发送者允许该应用。此变更旨在防止恶意应用滥用在后台启动 activity 的功能。默认情况下,不允许应用将任务堆栈置于前台,除非创建者允许后台 activity 启动特权或发送者具有后台 activity 启动特权。 - 控制任务堆栈的顶层 activity 完成其任务的方式。如果顶层 activity 完成某项任务,Android 会返回到上次处于活动状态的任务。此外,如果非顶层 activity 完成其任务,Android 将返回主屏幕;它不会阻止此非顶部 activity 的完成。
- 防止将其他应用中的任意 activity 启动到您自己的任务中。这项变更会通过创建看似来自其他应用的活动,防止恶意应用向用户进行钓鱼式攻击。
- 阻止系统考虑将不可见窗口用于后台 activity 启动。这有助于防止恶意应用滥用后台 activity 启动来向用户显示不受欢迎或恶意内容。
Intents mais seguras
Android 15 引入了新的安全措施,使 intent 更加安全可靠。这些变更旨在防止潜在漏洞和被恶意应用利用的 intent 滥用。Android 15 中对 intent 的安全性进行了两项主要改进:
- 匹配目标 intent 过滤器:定位特定组件的 intent 必须准确匹配目标的 intent 过滤器规范。如果您通过发送 intent 来启动其他应用的 activity,则目标 intent 组件需要与接收 activity 声明的 intent 过滤器保持一致。
- intent 必须具有操作:没有操作的 intent 将不再与任何 intent 过滤器匹配。这意味着,用于启动 activity 或服务的 intent 必须具有明确定义的操作。
- 待处理 intent:待处理 intent 的创建者被视为封装 intent 的发送者,而非待处理 intent 的发送者
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, se o app for destinados ao Android 15 (nível 35 da API).
![](https://developer.android.google.cn/static/about/versions/15/images/edge-to-edge-1.png?authuser=5&hl=pt)
Essa é uma mudança interruptiva que pode afetar negativamente a interface do app. O as mudanças afetam as seguintes áreas da interface:
- Barra de navegação da alça de gestos
- Transparente por padrão.
- O deslocamento inferior está desativado para que o conteúdo fique atrás da navegação do sistema a menos que encartes sejam aplicados.
setNavigationBarColor
eR.attr#navigationBarColor
estão descontinuada e não afetam a navegação por gestos.setNavigationBarContrastEnforced
eR.attr#navigationBarContrastEnforced
continuam não tendo efeito sobre e navegação por gestos.
- Navegação com três botões
- Opacidade definida como 80% por padrão, com cores possivelmente correspondentes à janela plano de fundo.
- 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
estão definida para corresponder ao plano de fundo da janela por padrão. O plano de fundo da janela precisa ser um drawable de cor para que esse padrão seja aplicado. Essa API é descontinuado, mas continua afetando a navegação com três botões.setNavigationBarContrastEnforced
eR.attr#navigationBarContrastEnforced
é verdadeiro por padrão, o que adiciona uma Plano de fundo 80% opaco na navegação com três botões.
- Barra de status
- Transparente por padrão.
- O deslocamento superior está desabilitado para que o conteúdo fique atrás da barra de status, a menos que encartes são aplicados.
setStatusBarColor
eR.attr#statusBarColor
estão descontinuados e não afetam o Android 15.setStatusBarContrastEnforced
eR.attr#statusBarContrastEnforced
foram descontinuados, mas ainda têm uma 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 interpretadas comoALWAYS
para que os usuários não vejam um ícone gerada pelo corte da tela e aparecem de ponta a ponta.
O exemplo a seguir mostra um app antes e depois da segmentação. Android 15 (nível 35 da API) e antes e depois de aplicar encartes.
![](https://developer.android.google.cn/static/about/versions/15/images/edge-to-edge-4.png?authuser=5&hl=pt)
![](https://developer.android.google.cn/static/about/versions/15/images/edge-to-edge-6.png?authuser=5&hl=pt)
![](https://developer.android.google.cn/static/about/versions/15/images/edge-to-edge-2.png?authuser=5&hl=pt)
O que verificar se o app já está de ponta a ponta
Se o app já está de ponta a ponta e aplica encartes, você está não são afetadas, exceto nos casos a seguir. No entanto, mesmo se você achar você não é 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 falhar na inicialização, pode ser devido à tela de apresentação. É possível fazer o upgrade do nível dependência da tela de apresentação para 1.2.0-alpha01 ou posterior ou definawindow.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always
. - Pode haver telas de menor tráfego com interface obstruída. Confirme estas
telas menos visitadas não têm 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. Em além dos cenários para aplicativos que já são de ponta a ponta, você deve considere o seguinte:
- Se o app usa componentes do Material 3 (
androidx.compose.material3
) no Compose, comoTopAppBar
.BottomAppBar
eNavigationBar
, esses componentes provavelmente não porque elas lidam automaticamente com encartes. - Se o app usar componentes do Material 2 (
androidx.compose.material
) no Compose, esses componentes não processam encartes automaticamente. No entanto, você tem acesso aos encartes e aplicá-las manualmente. No androidx.compose.material 1.6.0 Depois, use o parâmetrowindowInsets
para aplicar os encartes manualmente aosBottomAppBar
eTopAppBar
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 materiais baseados em visualizações. Componentes comoBottomNavigationView
,BottomAppBar
NavigationRailView
ouNavigationView
lidam com encartes e não exigem nenhum trabalho adicional. No entanto, você precisa adicionarandroid:fitsSystemWindows="true"
se estiver usandoAppBarLayout
. - Para elementos combináveis personalizados, aplique os encartes manualmente como padding. Se as
o conteúdo está em um
Scaffold
, é possível consumir encartes usando oScaffold
valores de padding. Caso contrário, aplique o padding usando um dosWindowInsets
. - Se o app usa visualizações e
BottomSheet
,SideSheet
ou contêineres, aplique o padding usandoViewCompat.setOnApplyWindowInsetsListener
. ParaRecyclerView
, aplique padding usando esse listener e também adicioneclipToPadding="false"
.
O que verificar se o app precisa oferecer proteção personalizada em segundo plano
Se o app precisar oferecer proteção de segundo plano personalizada para navegação com três botões ou
a barra de status, seu app precisa posicionar um elemento combinável ou uma visualização atrás da barra de sistema.
usando WindowInsets.Type#tappableElement()
para acessar o botão de três botões
altura da barra de navegação ou WindowInsets.Type#statusBars
.
Outros recursos de ponta a ponta
Consulte as Visualizações de ponta a ponta e Composição de borda a borda para considerações adicionais 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 o app seja destinado ao Android 15 (nível 35 da API) ou versões mais recentes, Configuration
não
exclui por mais as barras do sistema. Se você usar o tamanho da tela no
Configuration
para o cálculo de layout, você deve substituí-la por uma melhor
alternativas, como um ViewGroup
, WindowInsets
ou
WindowMetricsCalculator
, dependendo das suas necessidades.
Configuration
está disponível desde a API 1. Normalmente é obtido do
Activity.onConfigurationChanged
: Ele fornece informações como a densidade da janela,
orientação e tamanhos. Uma característica importante dos tamanhos de janela
retornado de Configuration
é a exclusão prévia das 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 de layout sempre foi desencorajado. Se fizer isso, avance para a
se afastar disso agora. Substitua o uso de Configuration
por algo
mais adequados de acordo com o caso de uso.
Se você usá-lo para calcular o layout, use um ViewGroup
apropriado, como
CoordinatorLayout
ou ConstraintLayout
. Se você usá-lo 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 estão mais disponíveis exclua as barras do sistema. - O
Configuration.smallestScreenWidthDp
é afetado indiretamente pelas mudanças. parascreenWidthDp
escreenHeightDp
. - O
Configuration.orientation
é afetado indiretamente pelas mudanças feitas emscreenWidthDp
escreenHeightDp
em dispositivos quase quadrados. Display.getSize(Point)
é indiretamente afetada pelas mudanças emConfiguration
. Ele foi descontinuado no nível 30 da API.Display.getMetrics()
já funciona assim desde o nível 33 da API.
O atributo eleganteTextHeight assume o padrão como verdadeiro
对于以 Android 15 为目标平台的应用,elegantTextHeight
TextView
属性默认变为 true
,将默认使用的紧凑字体替换为一些具有较大垂直指标的脚本,并且这种字体更易于阅读。紧凑字体的引入是为了防止破坏布局;Android 13(API 级别 33)允许文本布局利用 fallbackLineSpacing
属性拉伸垂直高度,以防止许多此类破坏。
在 Android 15 中,紧凑字体仍保留在系统中,因此您的应用可以将 elegantTextHeight
设置为 false
,以获得与之前相同的行为,但即将在未来版本中提供支持。因此,如果您的应用支持以下文字:阿拉伯语、老挝语、缅甸、泰米尔语、古吉拉特语、卡纳达语、马拉雅拉姆语、奥里亚语、泰卢固语或泰语,请将 elegantTextHeight
设置为 true
,以测试应用。
![](https://developer.android.google.cn/static/about/versions/15/images/elegant-text-height-before.png?authuser=5&hl=pt)
elegantTextHeight
行为。![](https://developer.android.google.cn/static/about/versions/15/images/elegant-text-height-after.png?authuser=5&hl=pt)
elegantTextHeight
行为。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.
![](https://developer.android.google.cn/static/about/versions/15/images/cursive-clipped.png?authuser=5&hl=pt)
<TextView android:fontFamily="cursive" android:text="java" />
![](https://developer.android.google.cn/static/about/versions/15/images/cursive-noclipping.png?authuser=5&hl=pt)
<TextView android:fontFamily="cursive" android:text="java" android:useBoundsForWidth="true" android:shiftDrawingOffsetForStartOverhang="true" />
![](https://developer.android.google.cn/static/about/versions/15/images/thai-clipped.png?authuser=5&hl=pt)
<TextView android:text="คอมพิวเตอร์" />
![](https://developer.android.google.cn/static/about/versions/15/images/thai-noclipping.png?authuser=5&hl=pt)
<TextView android:text="คอมพิวเตอร์" android:useBoundsForWidth="true" android:shiftDrawingOffsetForStartOverhang="true" />
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:
![](https://developer.android.google.cn/static/about/versions/15/images/locale-aware-line-height-before.png?authuser=5&hl=pt)
EditText
que
podem conter texto do inglês (en), japonês (ja) e birmanês (my). A
altura do EditText
é a mesma, embora esses idiomas
tenham alturas de linha diferentes.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:
![](https://developer.android.google.cn/static/about/versions/15/images/locale-aware-line-height-after.png?authuser=5&hl=pt)
EditText
que
podem conter texto do inglês (en), japonês (ja) e birmanês (my). A
altura do EditText
agora inclui espaço para acomodar a
altura da linha padrão para as fontes desses idiomas.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 ou executar um
serviço em primeiro plano 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 retornará AUDIOFOCUS_REQUEST_FAILED
.
Saiba mais sobre a seleção de áudio em Gerenciar seleção de áudio.
Atualização das restrições não SDK
O Android 15 inclui listas atualizadas de recursos não SDK restritos interfaces baseadas na colaboração com desenvolvedores Android e nos recursos para testes internos. 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, algumas destas mudanças pode não afetá-lo imediatamente. No entanto, embora seja possível acessar algumas interfaces externas ao SDK dependendo do nível desejado da API do app, é possível usar qualquer ou campo sempre apresenta um alto risco de corromper o aplicativo.
Se você não souber se o app usa interfaces externas ao SDK, será possível teste seu app para descobrir. Caso seu app dependa de ambientes externos interfaces, comece a planejar uma migração para alternativas de SDK. No entanto, entendemos que alguns aplicativos têm casos de uso válidos para o uso externas ao SDK. Se você não encontrar uma alternativa ao uso de um SDK para um recurso no seu app, você precisa solicitar 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.