Assim como nas 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 a versões mais recentes, faça modificações para oferecer suporte a esses comportamentos de forma adequada, quando aplicável.
Consulte também a lista de mudanças de comportamento que afetam todos os apps
executados no Android 15, independente da targetSdkVersion do seu app.
Principal recurso
O Android 15 modifica ou expande vários recursos principais do sistema Android.
Mudanças nos serviços em primeiro plano
We are making the following changes to foreground services with Android 15.
- Data sync foreground service timeout behavior
- New media processing foreground service type
- Restrictions on
BOOT_COMPLETEDbroadcast receivers launching foreground services - Restrictions on starting foreground services while an app holds the
SYSTEM_ALERT_WINDOWpermission
Data sync foreground service timeout behavior
O Android 15 introduz um novo comportamento de tempo limite no dataSync para apps destinados
ao Android 15 (nível 35 da API) 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 6 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(), o sistema vai gerar uma exceção interna. A
exceção é registrada no Logcat com a seguinte mensagem:
Fatal Exception: android.app.RemoteServiceException: "A foreground service of
type dataSync did not stop within its timeout: [component name]"
Para evitar problemas com essa mudança de comportamento, faça uma ou mais das seguintes ações:
- Faça com que o 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 parar o app imediatamente, o sistema vai gerar uma falha. - Os serviços
dataSyncdo app não podem ser executados por mais de 6 horas em um período de 24 horas (a menos que o usuário interaja com o app, redefinindo o timer). - Só inicie serviços em primeiro plano
dataSynccomo resultado da interação direta do usuário. Como o app está em primeiro plano quando o serviço é iniciado, ele tem seis horas completas após o app ir 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 seis horas nas últimas
24 horas, 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 esgotado para o tipo de serviço em primeiro plano
dataSync".
Teste
Para testar o comportamento do app, ative os timeouts de sincronização de dados mesmo que o app
não esteja segmentado para o Android 15, desde que esteja sendo executado em um dispositivo
Android 15. Para ativar os tempos limite, execute o comando adb:
adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name
Você também pode ajustar o período de tempo limite para facilitar o teste do comportamento
do app quando o limite for atingido. Para definir um novo período de tempo limite, execute o
seguinte comando adb:
adb shell device_config put activity_manager data_sync_fgs_timeout_duration duration-in-milliseconds
New media processing foreground service type
O Android 15 apresenta um novo tipo de serviço em primeiro plano, mediaProcessing. Esse
tipo de serviço é adequado para operações como transcodificação de arquivos de mídia. Por
exemplo, um app de mídia pode fazer o download de um arquivo de áudio e precisar convertê-lo para 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 quando o app estiver em
segundo plano.
O sistema permite que os serviços mediaProcessing de um app sejam executados por um total de 6
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). Nesse momento, o serviço tem alguns segundos para chamar
Service.stopSelf(). Se o serviço não
chamar Service.stopSelf(), o sistema vai gerar uma exceção interna. A
exceção é registrada no Logcat com a seguinte mensagem:
Fatal Exception: android.app.RemoteServiceException: "A foreground service of
type mediaProcessing did not stop within its timeout: [component name]"
Para evitar a exceção, siga um destes procedimentos:
- Faça com que o serviço implemente o novo método
Service.onTimeout(int, int). Quando o app receber o callback, chamestopSelf()dentro de alguns segundos. Se você não interromper o app imediatamente, o sistema vai gerar uma falha. - Verifique se os serviços
mediaProcessingdo app não são executados por mais de um total de seis horas em qualquer período de 24 horas, a menos que o usuário interaja com o app, redefinindo o timer. - Só inicie serviços em primeiro plano
mediaProcessingcomo resultado da interação direta do usuário. Como o app está em primeiro plano quando o serviço é iniciado, ele tem seis horas completas após o app ir 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 horas, não será possível iniciar outro serviço em primeiro plano mediaProcessing 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 mediaProcessing em primeiro plano, o sistema vai gerar
ForegroundServiceStartNotAllowedException
com uma mensagem de erro como "O limite de tempo já se esgotou para o tipo de serviço em primeiro plano
mediaProcessing".
Para mais informações sobre o tipo de serviço mediaProcessing, consulte Mudanças nos
tipos de serviço em primeiro plano do Android 15: processamento de mídia.
Teste
Para testar o comportamento do app, ative os timeouts de processamento de mídia, mesmo que
o app não seja direcionado ao Android 15 (desde que esteja sendo executado em um
dispositivo Android 15). Para ativar os tempos limite, execute o seguinte comando adb:
adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name
Você também pode ajustar o período de tempo limite para facilitar o teste do comportamento
do app quando o limite for atingido. Para definir um novo período de tempo limite, execute o
seguinte comando adb:
adb shell device_config put activity_manager media_processing_fgs_timeout_duration duration-in-milliseconds
Restrictions on BOOT_COMPLETED broadcast receivers launching foreground services
There are new restrictions on BOOT_COMPLETED broadcast receivers launching
foreground services. BOOT_COMPLETED receivers are not allowed to launch the
following types of foreground services:
dataSynccameramediaPlaybackphoneCallmediaProjectionmicrophone(this restriction has been in place formicrophonesince Android 14)
If a BOOT_COMPLETED receiver tries to launch any of those types of foreground
services, the system throws ForegroundServiceStartNotAllowedException.
Testing
To test your app's behavior, you can enable these new restrictions even if your
app is not targeting Android 15 (as long as the app is running on an Android 15
device). Run the following adb command:
adb shell am compat enable FGS_BOOT_COMPLETED_RESTRICTIONS your-package-name
To send a BOOT_COMPLETED broadcast without restarting the device,
run the following adb command:
adb shell am broadcast -a android.intent.action.BOOT_COMPLETED your-package-name
Restrictions on starting foreground services while an app holds the SYSTEM_ALERT_WINDOW permission
Previously, if an app held the SYSTEM_ALERT_WINDOW permission, it could launch
a foreground service even if the app was currently in the background (as
discussed in exemptions from background start restrictions).
If an app targets Android 15, this exemption is now narrower. The app now needs
to have the SYSTEM_ALERT_WINDOW permission and also have a visible overlay
window. That is, the app needs to first launch a
TYPE_APPLICATION_OVERLAY window and the window
needs to be visible before you start a foreground service.
If your app attempts to start a foreground service from the background without
meeting these new requirements (and it does not have some other exemption), the
system throws ForegroundServiceStartNotAllowedException.
If your app declares the SYSTEM_ALERT_WINDOW permission
and launches foreground services from the background, it may be affected by this
change. If your app gets a ForegroundServiceStartNotAllowedException, check
your app's order of operations and make sure your app already has an active
overlay window before it attempts to start a foreground service from the
background. You can check if your overlay window is currently visible
by calling View.getWindowVisibility(), or you
can override View.onWindowVisibilityChanged()
to get notified whenever the visibility changes.
Testing
To test your app's behavior, you can enable these new restrictions even if your
app is not targeting Android 15 (as long as the app is running on an Android 15
device). To enable these new restrictions on starting foreground services
from the background, run the following adb command:
adb shell am compat enable FGS_SAW_RESTRICTIONS your-package-name
Mudanças em quando os apps podem modificar o estado global do modo Não perturbe
Os apps direcionados ao Android 15 (nível 35 da API) e mais recentes não podem mais mudar o
estado global ou a política de Não perturbe (DND, na sigla em inglês) em um dispositivo, seja modificando
as configurações do usuário ou desativando o modo DND. Em vez disso, os apps precisam contribuir com um
AutomaticZenRule, que o sistema combina em uma política global com o
esquema de política mais restritiva. As chamadas para APIs que
afetam o estado global (setInterruptionFilter,
setNotificationPolicy) resultam na criação ou atualização de um
AutomaticZenRule implícito, que é ativado e desativado dependendo do ciclo de chamadas
dessas chamadas de API.
Essa mudança só afeta o comportamento observável se o app estiver chamando
setInterruptionFilter(INTERRUPTION_FILTER_ALL) e esperar que essa chamada desative uma AutomaticZenRule que foi ativada anteriormente pelos proprietários.
Mudanças na API OpenJDK
Android 15 continues the work of refreshing Android's core libraries to align with the features in the latest OpenJDK LTS releases.
Some of these changes can affect app compatibility for apps targeting Android 15 (API level 35):
Changes to string formatting APIs: Validation of argument index, flags, width, and precision are now more strict when using the following
String.format()andFormatter.format()APIs:String.format(String, Object[])String.format(Locale, String, Object[])Formatter.format(String, Object[])Formatter.format(Locale, String, Object[])
For example, the following exception is thrown when an argument index of 0 is used (
%0in the format string):IllegalFormatArgumentIndexException: Illegal format argument index = 0In this case, the issue can be fixed by using an argument index of 1 (
%1in the format string).Changes to component type of
Arrays.asList(...).toArray(): When usingArrays.asList(...).toArray(), the component type of the resulting array is now anObject—not the type of the underlying array's elements. So the following code throws aClassCastException:String[] elements = (String[]) Arrays.asList("one", "two").toArray();For this case, to preserve
Stringas the component type in the resulting array, you could useCollection.toArray(Object[])instead:String[] elements = Arrays.asList("two", "one").toArray(new String[0]);Changes to language code handling: When using the
LocaleAPI, language codes for Hebrew, Yiddish, and Indonesian are no longer converted to their obsolete forms (Hebrew:iw, Yiddish:ji, and Indonesian:in). When specifying the language code for one of these locales, use the codes from ISO 639-1 instead (Hebrew:he, Yiddish:yi, and Indonesian:id).Changes to random int sequences: Following the changes made in https://bugs.openjdk.org/browse/JDK-8301574, the following
Random.ints()methods now return a different sequence of numbers than theRandom.nextInt()methods do:Generally, this change shouldn't result in app-breaking behavior, but your code shouldn't expect the sequence generated from
Random.ints()methods to matchRandom.nextInt().
The new SequencedCollection API can affect your app's compatibility
after you update compileSdk in your app's build configuration to use
Android 15 (API level 35):
Collision with
MutableList.removeFirst()andMutableList.removeLast()extension functions inkotlin-stdlibThe
Listtype in Java is mapped to theMutableListtype in Kotlin. Because theList.removeFirst()andList.removeLast()APIs have been introduced in Android 15 (API level 35), the Kotlin compiler resolves function calls, for examplelist.removeFirst(), statically to the newListAPIs instead of to the extension functions inkotlin-stdlib.If an app is re-compiled with
compileSdkset to35andminSdkset to34or lower, and then the app is run on Android 14 and lower, a runtime error is thrown:java.lang.NoSuchMethodError: No virtual method removeFirst()Ljava/lang/Object; in class Ljava/util/ArrayList;The existing
NewApilint option in Android Gradle Plugin can catch these new API usages../gradlew lintMainActivity.kt:41: Error: Call requires API level 35 (current min is 34): java.util.List#removeFirst [NewApi] list.removeFirst()To fix the runtime exception and lint errors, the
removeFirst()andremoveLast()function calls can be replaced withremoveAt(0)andremoveAt(list.lastIndex)respectively in Kotlin. If you're using Android Studio Ladybug | 2024.1.3 or higher, it also provides a quick fix option for these errors.Consider removing
@SuppressLint("NewApi")andlintOptions { disable 'NewApi' }if the lint option has been disabled.Collision with other methods in Java
New methods have been added into the existing types, for example,
ListandDeque. These new methods might not be compatible with the methods with the same name and argument types in other interfaces and classes. In the case of a method signature collision with incompatibility, thejavaccompiler outputs a build-time error. For example:Example error 1:
javac MyList.javaMyList.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 ListExample error 2:
javac MyList.javaMyList.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 errorExample error 3:
javac MyList.javaMyList.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 errorTo fix these build errors, the class implementing these interfaces should override the method with a compatible return type. For example:
@Override public Object getFirst() { return List.super.getFirst(); }
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.
Versões TLS restritas
O Android 15 restringe o uso das versões 1.0 e 1.1 do TLS. Essas versões foram descontinuadas no Android, mas agora não são mais permitidas para apps destinados ao Android 15.
Início de atividades em segundo plano seguras
O Android 15 protege os usuários contra apps maliciosos e dá mais controle sobre os dispositivos. Isso é feito com mudanças que impedem que apps maliciosos em segundo plano tragam outros apps para o primeiro plano, elevem os privilégios e abusem da interação do usuário. O início de atividades em segundo plano está restrito desde o Android 10 (nível 29 da API).
Outras mudanças
- Mude os criadores de
PendingIntentpara bloquear as atividades em segundo plano por padrão. Isso ajuda a evitar que os apps criem acidentalmente umPendingIntentque possa ser usado indevidamente por agentes maliciosos. - Não coloque um app em primeiro plano, a menos que o remetente
PendingIntentpermita isso. Essa mudança tem como objetivo impedir que apps maliciosos abusem da capacidade de iniciar atividades em segundo plano. Por padrão, os apps não podem trazer a pilha de tarefas para o primeiro plano, a menos que o criador permita privilégios de início de atividade em segundo plano ou o remetente tenha esses privilégios. - Controlar como a atividade principal de uma pilha de tarefas pode concluir a tarefa. Se a atividade principal concluir uma tarefa, o Android voltará para a tarefa que estava ativa por último. Além disso, se uma atividade não principal concluir a tarefa, o Android voltará à tela inicial e não vai bloquear a conclusão dessa atividade não principal.
- Evite iniciar atividades arbitrárias de outros apps na sua tarefa. Essa mudança impede que apps maliciosos façam phishing com os usuários criando atividades que parecem ser de outros apps.
- Impedir que janelas não visíveis sejam consideradas para inicializações de atividades em segundo plano. Isso ajuda a impedir que apps maliciosos abusem de inícios de atividade em segundo plano para mostrar conteúdo indesejado ou malicioso aos usuários.
Intents mais seguras
Android 15 introduces StrictMode for
intents.
In order to see detailed logs about Intent usage violations, use following
method:
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 visam criar uma experiência do usuário mais consistente e intuitiva.
Mudanças no encarte da janela
There are two changes related to window insets in Android 15: edge-to-edge is enforced by default, and there are also configuration changes, such as the default configuration of system bars.
Edge-to-edge enforcement
Os apps são de ponta a ponta por padrão em dispositivos com Android 15 se o app for destinado ao Android 15 (nível 35 da API).
Essa é uma mudança incompatível que pode afetar negativamente a interface do seu app. As mudanças afetam as seguintes áreas da interface:
- Barra de navegação com alça de gestos
- Transparente por padrão.
- O deslocamento da parte de baixo está desativado, então o conteúdo é mostrado por trás da barra de navegação do sistema, a menos que encartes sejam aplicados.
setNavigationBarColoreR.attr#navigationBarColorestão descontinuados e não afetam a navegação por gestos.setNavigationBarContrastEnforcedeR.attr#navigationBarContrastEnforcedcontinuam sem efeito na navegação por gestos.
- Navegação com três botões
- Opacidade definida como 80% por padrão, com a cor possivelmente correspondendo ao plano de fundo da janela.
- Deslocamento da parte de baixo desativado para que o conteúdo seja mostrado por trás da barra de navegação do sistema, a menos que encartes sejam aplicados.
setNavigationBarColoreR.attr#navigationBarColorsão definidos 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 está descontinuada, mas continua afetando a navegação com três botões.setNavigationBarContrastEnforcedeR.attr#navigationBarContrastEnforcedsão verdadeiros por padrão, o que adiciona um plano de fundo 80% opaco na navegação com três botões.
- Barra de status
- Transparente por padrão.
- O deslocamento da parte de cima é desativado, então o conteúdo é mostrado por trás da barra de status, a menos que encartes sejam aplicados.
setStatusBarColoreR.attr#statusBarColorforam descontinuados e não têm efeito no Android 15.setStatusBarContrastEnforcedeR.attr#statusBarContrastEnforcedforam descontinuados, mas ainda têm um efeito no Android 15.
- Corte da tela
- O
layoutInDisplayCutoutModede janelas não flutuantes precisa serLAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS.SHORT_EDGES,NEVEReDEFAULTsão interpretados comoALWAYSpara que os usuários não vejam uma barra preta causada pelo corte da tela e apareçam de ponta a ponta.
- O
O exemplo a seguir mostra um app antes e depois de ser direcionado ao Android 15 (nível 35 da API) e antes e depois de aplicar encartes. Este exemplo não é abrangente e pode aparecer de maneira diferente no Android Auto.
O que verificar se o app já é de ponta a ponta
Se o app já for de ponta a ponta e aplicar encartes, você não será muito afetado, exceto nos seguintes cenários. No entanto, mesmo que você não acredite que seu app foi afetado, recomendamos que você o teste.
- Você tem uma janela não flutuante, como um
Activityque usaSHORT_EDGES,NEVERouDEFAULTem vez deLAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS. Se o app falhar ao iniciar, o problema pode ser a tela de apresentação. Você pode fazer upgrade da dependência core splashscreen para 1.2.0-alpha01 ou uma versão mais recente ou definirwindow.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always. - Pode haver telas com menos tráfego e interface obstruída. Verifique se essas telas menos visitadas não têm uma interface obstruída. As telas com menos tráfego incluem:
- Telas de onboarding ou login
- Páginas de configurações
O que verificar se o app ainda não é de ponta a ponta
Se o 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 usar componentes do Material 3 (
androidx.compose.material3) no Compose, comoTopAppBar,BottomAppBareNavigationBar, é provável que esses componentes não sejam afetados porque processam encartes automaticamente. - Se o app estiver usando componentes do Material 2 (
androidx.compose.material) no Compose, eles não vão processar encartes automaticamente. No entanto, você pode conseguir acesso aos encartes para fazer a aplicação manual. No androidx.compose.material 1.6.0 e versões mais recentes, use o parâmetrowindowInsetspara aplicar os encartes manualmente paraBottomAppBar,TopAppBar,BottomNavigationeNavigationRail. Da mesma forma, use o parâmetrocontentWindowInsetsparaScaffold. - Se o app usar views e componentes do Material
(
com.google.android.material), a maioria dos componentes do Material baseados em views, comoBottomNavigationView,BottomAppBar,NavigationRailViewouNavigationView, processa encartes e não exige mais trabalho. No entanto, você precisa 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, você poderá consumir encartes usando os valores de padding Scaffold. Caso contrário, aplique o padding usando um dosWindowInsets. - Se o app estiver usando visualizações e
BottomSheet,SideSheetou contêineres personalizados, aplique padding usandoViewCompat.setOnApplyWindowInsetsListener. ParaRecyclerView, aplique padding usando esse listener e também adicioneclipToPadding="false".
O que verificar se o app precisa oferecer proteção de segundo plano personalizada
Se o app precisar oferecer proteção de plano de fundo personalizada para a navegação com três botões ou
a barra de status, ele deverá colocar um elemento combinável ou uma visualização atrás da barra de sistema
usando WindowInsets.Type#tappableElement() para receber a altura da barra de navegação
com três botões ou WindowInsets.Type#statusBars.
Outros recursos de ponta a ponta
Consulte os guias Visualizações de ponta a ponta e Compose de ponta a ponta para mais considerações sobre a aplicação de encartes.
APIs descontinuadas
As APIs a seguir estão descontinuadas, mas não desativadas:
R.attr#enforceStatusBarContrastR.attr#navigationBarColor(para navegação com três botões, com alfa de 80%)Window#isStatusBarContrastEnforcedWindow#setNavigationBarColor(para navegação com três botões, com alfa de 80%)Window#setStatusBarContrastEnforced
As APIs a seguir estão descontinuadas e desativadas:
R.attr#navigationBarColor(para navegação por gestos)R.attr#navigationBarDividerColorR.attr#statusBarColorWindow#setDecorFitsSystemWindowsWindow#getNavigationBarColorWindow#getNavigationBarDividerColorWindow#getStatusBarColorWindow#setNavigationBarColor(para navegação por gestos)Window#setNavigationBarDividerColorWindow#setStatusBarColor
Stable configuration
Se o app for direcionado ao Android 15 (API de nível 35) ou versões mais recentes, Configuration não vai mais excluir as barras de sistema. Se você usar o tamanho da tela na classe Configuration para cálculo de layout, substitua por alternativas melhores, como um ViewGroup, WindowInsets ou WindowMetricsCalculator adequado, dependendo da sua necessidade.
O Configuration está disponível desde a API 1. Normalmente, ele é obtido de
Activity.onConfigurationChanged. Ele 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 excluía as barras de sistema.
O tamanho da configuração é usado normalmente para seleção de recursos, como
/res/layout-h500dp, e ainda é um caso de uso válido. No entanto, o uso para cálculo de layout sempre foi desencorajado. Se você estiver fazendo isso, pare agora. Substitua o uso de Configuration por algo mais adequado, dependendo do seu caso de uso.
Se você usar para calcular o layout, use um ViewGroup adequado, como
CoordinatorLayout ou ConstraintLayout. Se você usar para determinar a altura
da barra de navegação do sistema, use WindowInsets. Se quiser saber o tamanho atual
da janela do app, use computeCurrentWindowMetrics.
A lista a seguir descreve os campos afetados por essa mudança:
- Os tamanhos
Configuration.screenWidthDpescreenHeightDpnão excluem mais as barras de sistema. Configuration.smallestScreenWidthDpé afetado indiretamente por mudanças emscreenWidthDpescreenHeightDp.- O
Configuration.orientationé afetado indiretamente por mudanças noscreenWidthDpe noscreenHeightDpem dispositivos quase quadrados. Display.getSize(Point)é afetado indiretamente pelas mudanças emConfiguration. Esse recurso foi descontinuado a partir do nível 30 da API.- O
Display.getMetrics()já funciona assim desde o nível 33 da API.
O atributo "elegantTextHeight" tem como padrão o valor "true".
Em apps destinados ao Android 15 (nível 35 da API), o atributo
elegantTextHeight TextView
passa a ser true por padrão, substituindo a fonte compacta usada por padrão por alguns
scripts com métricas verticais grandes por uma que é muito 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 quebras, permitindo que o layout de texto
estique a altura vertical usando o atributo
fallbackLineSpacing.
No Android 15, a fonte compacta ainda permanece no sistema. Assim, o app pode definir
elegantTextHeight como false para ter o mesmo comportamento de antes, mas é
improvável que haja suporte a ele nas próximas versões. Portanto, se o app oferecer suporte aos
seguintes scripts: árabe, lao, birmanês, tâmil, gujarati, canarês, malaiala,
odia, télugo ou tailandês, teste o app definindo elegantTextHeight como true.
elegantTextHeight comportamento para apps destinados ao Android 14 (nível 34 da API) e versões anteriores.
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 cursivas ou linguagens que têm
modelagem complexa podiam desenhar as letras na área do caractere anterior ou seguinte.
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 desenhar espaço suficiente
para essas letras e permite que os apps solicitem mais paddings à esquerda para
evitar recortes.
Como essa mudança afeta a forma como um TextView decide a largura, o TextView
aloca mais largura por padrão se o app for destinado ao Android 15 (nível 35 da API) ou
mais recente. Para ativar ou desativar esse comportamento, chame a
API setUseBoundsForWidth em TextView.
Como adicionar o padding à esquerda pode causar um desalinhamento nos layouts atuais, ele
não é adicionado por padrão nem mesmo para apps direcionados ao Android 15 ou mais recente.
No entanto, é possível adicionar um padding extra para evitar o corte chamando
setShiftDrawingOffsetForStartOverhang.
Os exemplos a seguir mostram como essas mudanças podem melhorar o layout de texto para algumas fontes e idiomas.
<TextView android:fontFamily="cursive" android:text="java" />
<TextView android:fontFamily="cursive" android:text="java" android:useBoundsForWidth="true" android:shiftDrawingOffsetForStartOverhang="true" />
<TextView android:text="คอมพิวเตอร์" />
<TextView android:text="คอมพิวเตอร์" android:useBoundsForWidth="true" android:shiftDrawingOffsetForStartOverhang="true" />
Altura da linha padrão sensível à localidade para EditText
Nas versões anteriores do Android, o layout de texto estendia a altura do
texto para atender à altura da linha da fonte que correspondia à localidade atual. Por
exemplo, se o conteúdo estivesse em japonês, a altura da linha da fonte japonesa
seria um pouco maior do que a de uma fonte latina, e a altura do texto
ficaria um pouco maior. No entanto, apesar dessas diferenças nas alturas das linhas, o elemento
EditText foi dimensionado de maneira uniforme, independentemente
da localidade usada, conforme ilustrado na imagem a seguir:
EditText que
podem conter texto em inglês (en), japonês (ja) e birmanês (my). A
altura do EditText é a mesma, mesmo que esses idiomas
tenham alturas de linha diferentes.Para apps direcionados ao Android 15 (nível 35 da API), uma altura mínima de linha agora é
reservada para EditText para corresponder à fonte de referência da localidade especificada, conforme
mostrado na imagem a seguir:
EditText que
podem conter texto em 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 das 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 seguintes mudanças no comportamento de câmera e mídia para apps direcionados a ele ou a versões mais recentes.
Restrições ao solicitar o foco de áudio
Apps that target Android 15 (API level 35) must be the top app or running a
foreground service in order to request audio focus. If an app
attempts to request focus when it does not meet one of these requirements, the
call returns AUDIOFOCUS_REQUEST_FAILED.
You can learn more about audio focus at Manage audio focus.
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 que seu app acesse algumas interfaces não SDK dependendo do nível da API de destino do app, o uso de qualquer método ou campo não SDK sempre apresenta um alto risco de corromper o app.
Se você não souber se seu app usa interfaces não SDK, poderá testá-lo 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. Se você não encontrar uma alternativa para deixar de usar uma interface não SDK em um recurso no seu 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.