Zmiany w działaniu: aplikacje kierowane na Androida 15 lub nowszego

Podobnie jak w przypadku poprzednich wersji, Android 15 zawiera zmiany działania, które mogą mieć wpływ na Twoją aplikację. Poniższe zmiany działania dotyczą wyłącznie aplikacji kierowanych na Androida 15 lub nowszego. Jeśli Twoja aplikacja jest kierowana na Androida 15 lub nowszego, musisz ją odpowiednio zmodyfikować, aby obsługiwała te funkcje (w stosownych przypadkach).

Zapoznaj się też z listą zmian zachowania, które wpływają na wszystkie aplikacje działające na Androidzie 15, niezależnie od targetSdkVersion Twojej aplikacji.

Główna funkcja

Android 15 modyfikuje lub rozszerza różne podstawowe funkcje systemu Android.

Zmiany w usługach działających na pierwszym planie

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_COMPLETED broadcast receivers launching foreground services
• Restrictions on starting foreground services while an app holds the SYSTEM_ALERT_WINDOW permission

Data sync foreground service timeout behavior

Android 15 wprowadza nowe zachowanie dotyczące limitu czasu w przypadku dataSync w aplikacjach kierowanych na Androida 15 (poziom interfejsu API 35) lub nowszego. Takie zachowanie dotyczy też nowego mediaProcessingtypu usługi działającej na pierwszym planie.

System zezwala na działanie usług dataSync aplikacji przez łącznie 6 godzin w ciągu 24 godzin, po czym system wywołuje metodę Service.onTimeout(int, int) (wprowadzoną w Androidzie 15). Obecnie usługa ma kilka sekund na wywołanie funkcji Service.stopSelf(). Gdy wywołana zostanie usługa Service.onTimeout(), nie będzie ona już usługą na pierwszym planie. Jeśli usługa nie wywołuje funkcji Service.stopSelf(), system zgłasza wewnętrzny wyjątek. Wyjątek jest rejestrowany w Logcat z tym komunikatem:

Fatal Exception: android.app.RemoteServiceException: "A foreground service of
type dataSync did not stop within its timeout: [component name]"

Aby uniknąć problemów związanych z tą zmianą zachowania, możesz wykonać co najmniej jedną z tych czynności:

1. Zaimplementuj nową metodę Service.onTimeout(int, int) w swojej usłudze. Gdy aplikacja otrzyma połączenie zwrotne, w ciągu kilku sekund zadzwoń pod numer stopSelf(). Jeśli nie zatrzymasz aplikacji od razu, system wygeneruje błąd.
2. Upewnij się, że usługi dataSync w aplikacji nie działają dłużej niż 6 godzin w ciągu 24 godzin (chyba że użytkownik wchodzi w interakcję z aplikacją, resetując timer).
3. Uruchamiaj dataSync usługi na pierwszym planie wyłącznie w wyniku bezpośredniej interakcji z użytkownikiem. Ponieważ aplikacja znajduje się na pierwszym planie w momencie uruchomienia usługi, usługa ma pełne 6 godzin od uruchomienia w tle.
4. Zamiast usługi na pierwszym planie dataSync użyj alternatywnego interfejsu API.

Jeśli w ciągu ostatnich 24 godzin usługi dataSync na pierwszym planie Twojej aplikacji działały przez 6 godzin, nie możesz uruchomić innej usługi dataSync na pierwszym planie chyba że użytkownik przełączył aplikację na pierwszy plan (co spowoduje zresetowanie minutnika). Jeśli spróbujesz uruchomić inną usługę dataSync na pierwszym planie, system wyświetli komunikat o błędzie, np. „Czas limitu został już wyczerpany dla usługi na pierwszym planie typu dataSync”.ForegroundServiceStartNotAllowedException

Testowanie

Aby przetestować działanie aplikacji, możesz włączyć limity czasu synchronizacji danych, nawet jeśli aplikacja nie jest kierowana na Androida 15 (o ile jest uruchomiona na urządzeniu z Androidem 15). Aby włączyć limity czasu, uruchom to polecenie adb:

adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name

Możesz też dostosować limit czasu oczekiwania, aby łatwiej testować działanie aplikacji po osiągnięciu limitu. Aby ustawić nowy okres oczekiwania, uruchom to polecenie adb:

adb shell device_config put activity_manager data_sync_fgs_timeout_duration duration-in-milliseconds

New media processing foreground service type

Android 15 introduces a new foreground service type, mediaProcessing. This service type is appropriate for operations like transcoding media files. For example, a media app might download an audio file and need to convert it to a different format before playing it. You can use a mediaProcessing foreground service to make sure the conversion continues even while the app is in the background.

The system permits an app's mediaProcessing services to run for a total of 6 hours in a 24-hour period, after which the system calls the running service's Service.onTimeout(int, int) method (introduced in Android 15). At this time, the service has a few seconds to call Service.stopSelf(). If the service does not call Service.stopSelf(), the system throws an internal exception. The exception is logged in Logcat with the following message:

Fatal Exception: android.app.RemoteServiceException: "A foreground service of
type mediaProcessing did not stop within its timeout: [component name]"

To avoid having the exception, you can do one of the following:

1. Have your service implement the new Service.onTimeout(int, int) method. When your app receives the callback, make sure to call stopSelf() within a few seconds. (If you don't stop the app right away, the system generates a failure.)
2. Make sure your app's mediaProcessing services don't run for more than a total of 6 hours in any 24-hour period (unless the user interacts with the app, resetting the timer).
3. Only start mediaProcessing foreground services as a result of direct user interaction; since your app is in the foreground when the service starts, your service has the full six hours after the app goes to the background.
4. Instead of using a mediaProcessing foreground service, use an alternative API, like WorkManager.

If your app's mediaProcessing foreground services have run for 6 hours in the last 24, you cannot start another mediaProcessing foreground service unless the user has brought your app to the foreground (which resets the timer). If you try to start another mediaProcessing foreground service, the system throws ForegroundServiceStartNotAllowedException with an error message like "Time limit already exhausted for foreground service type mediaProcessing".

For more information about the mediaProcessing service type, see Changes to foreground service types for Android 15: Media processing.

Testing

To test your app's behavior, you can enable media processing timeouts even if your app is not targeting Android 15 (as long as the app is running on an Android 15 device). To enable timeouts, run the following adb command:

adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name

You can also adjust the timeout period, to make it easier to test how your app behaves when the limit is reached. To set a new timeout period, run the following adb command:

adb shell device_config put activity_manager media_processing_fgs_timeout_duration duration-in-milliseconds

Restrictions on BOOT_COMPLETED broadcast receivers launching foreground services

Wprowadziliśmy nowe ograniczenia dotyczące odbiorników BOOT_COMPLETED usług działających na pierwszym planie. Odbiorcy BOOT_COMPLETED nie mogą uruchamiać modułu te typy usług na pierwszym planie:

• dataSync
• camera
• mediaPlayback
• phoneCall
• mediaProjection
• microphone (to ograniczenie obowiązuje w przypadku microphone od Androida 14)

Jeśli odbiornik BOOT_COMPLETED próbuje uruchomić którykolwiek z tych typów działania na pierwszym planie usług, system wywołuje ForegroundServiceStartNotAllowedException.

Testowanie

Aby przetestować działanie aplikacji, możesz włączyć te nowe ograniczenia, nawet jeśli aplikacja nie jest kierowana na Androida 15 (o ile jest ona uruchomiona na urządzeniu z Androidem 15). Uruchom to polecenie adb:

adb shell am compat enable FGS_BOOT_COMPLETED_RESTRICTIONS your-package-name

Aby wysłać komunikat typu BOOT_COMPLETED bez ponownego uruchamiania urządzenia: uruchom to polecenie adb:

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

Zmiany dotyczące tego, kiedy aplikacje mogą modyfikować globalny stan trybu Nie przeszkadzać

Apps that target Android 15 (API level 35) and higher can no longer change the global state or policy of Do Not Disturb (DND) on a device (either by modifying user settings, or turning off DND mode). Instead, apps must contribute an AutomaticZenRule, which the system combines into a global policy with the existing most-restrictive-policy-wins scheme. Calls to existing APIs that previously affected global state (setInterruptionFilter, setNotificationPolicy) result in the creation or update of an implicit AutomaticZenRule, which is toggled on and off depending on the call-cycle of those API calls.

Note that this change only affects observable behavior if the app is calling setInterruptionFilter(INTERRUPTION_FILTER_ALL) and expects that call to deactivate an AutomaticZenRule that was previously activated by their owners.

Zmiany w interfejsie OpenJDK API

Android 15 kontynuuje odświeżanie podstawowych bibliotek Androida, aby dostosować je do funkcji w najnowszych wersjach OpenJDK LTS.

Niektóre z tych zmian mogą mieć wpływ na zgodność aplikacji kierowanych na Androida 15 (poziom interfejsu API 35):

• Zmiany w interfejsach API do formatowania ciągów znaków: weryfikacja indeksu argumentu, flag, szerokości i dokładności jest teraz bardziej rygorystyczna podczas korzystania z tych interfejsów API: String.format() i Formatter.format():

  • String.format(String, Object[])
  • String.format(Locale, String, Object[])
  • Formatter.format(String, Object[])
  • Formatter.format(Locale, String, Object[])

  Na przykład gdy użyjesz indeksu argumentu 0 (%0 w formatowaniu ciągu znaków), zostanie rzucone to wyjątku:

  IllegalFormatArgumentIndexException: Illegal format argument index = 0
  

  W takim przypadku problem można rozwiązać, używając indeksu argumentu 1 (%1) w wierszu formatu.

• Zmiany typu komponentu Arrays.asList(...).toArray(): gdy używasz funkcji Arrays.asList(...).toArray(), typ komponentu powstałego tablicy jest teraz Object, a nie typ elementów podrzędnej tablicy. Ten kod powoduje wyjątek ClassCastException:

  String[] elements = (String[]) Arrays.asList("one", "two").toArray();
  

  W tym przypadku, aby zachować wartość String jako typ komponentu w wynikającym z niego tablicy, możesz użyć elementu Collection.toArray(Object[]):

  String[] elements = Arrays.asList("two", "one").toArray(new String[0]);
  

• Zmiany w obsługiwaniu kodu języka: gdy używasz interfejsu API Locale, kody języka hebrajskiego, jidysz i indonezyjskiego nie są już konwertowane na ich przestarzałe formy (hebr.: iw, jidysz: ji, indonezyjski: in). Podczas określania kodu języka dla jednego z tych języków użyj kodów z ISO 639-1 (hebr.: he, jidysz: yi, indonezyjski: id).

• Zmiany w losowych sekwencjach liczb całkowitych: po zmianach wprowadzonych w https://bugs.openjdk.org/browse/JDK-8301574 metody Random.ints() zwracają teraz inną sekwencję liczb niż metody Random.nextInt():

  • Random.ints(long)
  • Random.ints(long, int, int)
  • Random.ints(int, int)
  • Random.ints()

  Zwykle ta zmiana nie powinna powodować nieprawidłowego działania aplikacji, ale kod nie powinien zakładać, że sekwencja wygenerowana z metod Random.ints() będzie pasować do Random.nextInt().

Nowy interfejs API SequencedCollection może wpłynąć na zgodność aplikacji po zaktualnieniu compileSdk w konfiguracji kompilacji aplikacji, aby używać Androida 15 (poziom API 35):

• Konflikt z funkcjami rozszerzenia MutableList.removeFirst() i MutableList.removeLast() w pliku kotlin-stdlib

  Typ List w języku Java jest mapowany na typ MutableList w Kotlinie. Interfejsy List.removeFirst() i List.removeLast() zostały wprowadzone w Androidzie 15 (poziom interfejsu API 35), dlatego kompilator Kotlina rozwiązuje wywołania funkcji, np. list.removeFirst(), statycznie do nowych interfejsów List, a nie do funkcji rozszerzeń w kotlin-stdlib.

  Jeśli aplikacja zostanie ponownie skompilowana z wartością compileSdk równą 35, a wartością minSdk równą 34 lub niższą, a następnie zostanie uruchomiona na Androidzie 14 lub starszym, wystąpi błąd czasu wykonywania:

  java.lang.NoSuchMethodError: No virtual method
  removeFirst()Ljava/lang/Object; in class Ljava/util/ArrayList;
  

  Istniejąca opcja NewApi wtyczki Androida do obsługi Gradle może wykrywać te nowe użycia interfejsu API.

  ./gradlew lint
  
  MainActivity.kt:41: Error: Call requires API level 35 (current min is 34): java.util.List#removeFirst [NewApi]
        list.removeFirst()
  

  Aby naprawić wyjątki czasu wykonywania i błędy lint, możesz zastąpić wywołania funkcji removeFirst() i removeLast() odpowiednio wywołaniami removeAt(0) i removeAt(list.lastIndex) w Kotlinie. Jeśli używasz Android Studio Ladybug | 2024.1.3 lub nowszej wersji, możesz też szybko naprawić te błędy.

  Jeśli opcja sprawdzania kodu została wyłączona, rozważ usunięcie @SuppressLint("NewApi") i lintOptions { disable 'NewApi' }.

• Konflikt z innymi metodami w języku Java

  Do dotychczasowych typów dodano nowe metody, np. List i Deque. Te nowe metody mogą być niezgodne z metodami o tej samej nazwie i typach argumentów w innych interfejsach i klasach. W przypadku kolizji sygnatury metody z niezgodnością kompilator javac generuje błąd w czasie kompilacji. Przykład:

  Przykład błędu 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 List
  

  Przykładowy błąd 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 error
  

  Przykładowy błąd 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 error
  

  Aby naprawić te błędy kompilacji, klasa implementująca te interfejsy powinna zastąpić metodę zgodnym typem zwracanym. Na przykład:

  @Override
  public Object getFirst() {
      return List.super.getFirst();
  }
  

Bezpieczeństwo

Android 15 zawiera zmiany, które poprawiają bezpieczeństwo systemu i chronią aplikacje oraz użytkowników przed złośliwymi aplikacjami.

Wersje TLS z ograniczeniami

Android 15 ogranicza użycie TLS w wersjach 1.0 i 1.1. Te wersje zostały wcześniej wycofane w Androidzie, ale teraz są niedozwolone w przypadku aplikacji kierowanych na Androida 15.

Uruchamianie zabezpieczonej aktywności w tle

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

Other changes

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

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

Bezpieczniejsze zamiary

Android 15 wprowadza nowe opcjonalne środki bezpieczeństwa, które zwiększają bezpieczeństwo i stabilność intencji. Te zmiany mają na celu zapobieganie potencjalnym luk w zabezpieczeniach i niewłaściwemu wykorzystywaniu intencji, które mogą być wykorzystywane przez złośliwe aplikacje. W Androidzie 15 wprowadziliśmy 2 główne ulepszenia dotyczące bezpieczeństwa intencji:

• Pasowanie do docelowych filtrów intencji: intencje kierowane na konkretne komponenty muszą dokładnie odpowiadać specyfikacji filtrów intencji docelowych. Jeśli wysyłasz intencję, aby uruchomić działanie innej aplikacji, docelowy komponent intencji musi być zgodny z deklarowanymi filtrami intencji działania odbierającego.
• Intencje muszą mieć działania: intencje bez działania nie będą już pasować do żadnych filtrów intencji. Oznacza to, że intencje używane do uruchamiania działań lub usług muszą mieć wyraźnie zdefiniowane działanie.

Aby sprawdzić, jak Twoja aplikacja reaguje na te zmiany, użyj w niej metody StrictMode. Aby wyświetlić szczegółowe dzienniki dotyczące naruszeń zasad Intent, dodaj tę metodę:

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

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

Wrażenia użytkownika i interfejs systemu

Android 15 zawiera kilka zmian, które mają na celu zapewnienie bardziej spójnego i intuicyjnego interfejsu.

Zmiany w oknach wstawnych

W Androidzie 15 wprowadzono 2 zmiany związane z współrzędnymi okna: domyślnie wymuszono tryb pełnoekranowy, a także wprowadzono zmiany konfiguracji, takie jak domyślna konfiguracja pasków systemowych.

Egzekwowanie treści od krawędzi do krawędzi

Aplikacje są domyślnie wyświetlane bez ramki na urządzeniach z Androidem 15, jeśli są kierowane na Androida 15 (poziom API 35).

Jest to zmiana powodująca przerwanie działania, która może negatywnie wpłynąć na interfejs aplikacji. Zmiany dotyczą tych obszarów interfejsu:

• Pasek nawigacyjny z uchwytem gestów
  • Domyślnie przezroczysty.
  • Odsunięcie od dołu jest wyłączone, więc treści są wyświetlane za paskiem nawigacji systemu, chyba że zastosowano wstawki.
  • setNavigationBarColor i R.attr#navigationBarColor są przestarzałe i nie wpływają na nawigację przy użyciu gestów.
  • setNavigationBarContrastEnforced i R.attr#navigationBarContrastEnforced nadal nie mają wpływu na nawigację za pomocą gestów.
• Nawigacja przy użyciu 3 przycisków
  • Domyślnie ustawiona jest przezroczystość na poziomie 80%, a kolor może być dopasowany do tła okna.
  • Odsunięcie od dołu jest wyłączone, więc treści są wyświetlane za paskiem nawigacji systemu, chyba że zastosowano wstawki.
  • Domyślnie kolory setNavigationBarColor i R.attr#navigationBarColor są dopasowywane do tła okna. Aby można było zastosować tę wartość domyślną, tło okna musi być obiektem rysowalnym koloru. Ten interfejs API został wycofany, ale nadal wpływa na nawigację z 3 przyciskami.
  • setNavigationBarContrastEnforced i R.attr#navigationBarContrastEnforced są domyślnie ustawione na wartość true, co oznacza, że w nawigacji z 3 przyciskami będzie widoczne 80% przezroczystego tła.
• Pasek stanu
  • Domyślnie przezroczysty.
  • Odsunięcie w górę jest wyłączone, więc treści są wyświetlane za paskiem stanu, chyba że zastosowano wgłębienia.
  • setStatusBarColor i R.attr#statusBarColor są wycofane i nie mają wpływu na Androida 15.
  • setStatusBarContrastEnforced i R.attr#statusBarContrastEnforced są wycofane, ale nadal mają wpływ na Androida 15.
• Wycięcie na wyświetlaczu
  • layoutInDisplayCutoutMode nieruchomych okien musi być LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS. SHORT_EDGES, NEVER i DEFAULT są interpretowane jako ALWAYS, aby użytkownicy nie widzieli czarnego paska spowodowanego wycięciem w ekranie.

Ten przykład pokazuje aplikację przed i po kierowaniu na Androida 15 (poziom API 35) oraz przed i po zastosowaniu odcięć.

Co sprawdzić, jeśli aplikacja jest już w trybie edge-to-edge

Jeśli Twoja aplikacja jest już wyświetlana od krawędzi do krawędzi i zawiera wstawione elementy, zmiany nie będą miały większego wpływu na Twoją aplikację, z wyjątkiem tych scenariuszy. Jednak nawet jeśli uważasz, że problem Cię nie dotyczy, zalecamy przetestowanie aplikacji.

• Masz okno nieprzesuwające się, np. Activity, które używa SHORT_EDGES, NEVER lub DEFAULT zamiast LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS. Jeśli aplikacja ulega awarii przy uruchamianiu, może to być spowodowane przez ekran powitalny. Możesz uaktualnić zależność core splashscreen do wersji 1.2.0-alpha01 lub nowszej albo ustawić window.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always.
• Mogą się pojawić ekrany o mniejszym natężeniu ruchu z zasłoniętym interfejsem. Sprawdź, czy te ekrany, które są rzadziej odwiedzane, nie mają zasłoniętego interfejsu. Ekrany o mniejszym natężeniu ruchu to m.in.:
  • ekrany wprowadzające lub logowania,
  • Strony ustawień

Co sprawdzić, jeśli aplikacja nie jest jeszcze wyświetlana od krawędzi do krawędzi

Jeśli Twoja aplikacja nie jest jeszcze wyświetlana od krawędzi do krawędzi, prawdopodobnie dotyczy Cię ta zmiana. Oprócz scenariuszy dotyczących aplikacji, które są już wyświetlane w trybie edge-to-edge, należy wziąć pod uwagę te kwestie:

• Jeśli Twoja aplikacja korzysta z komponentów Material 3 (androidx.compose.material3) w komponencie kompozytorskim, takich jak TopAppBar, BottomAppBar i NavigationBar, te komponenty prawdopodobnie nie są dotknięte, ponieważ automatycznie obsługują wstawione elementy.
• Jeśli Twoja aplikacja korzysta w Compose z komponentów Material 2 (androidx.compose.material), te komponenty nie będą automatycznie obsługiwać wstawień. Możesz jednak uzyskać dostęp do wstawionych elementów i zastosować je ręcznie. W androidx.compose.material 1.6.0 i nowszych użyj parametru windowInsets, aby ręcznie zastosować wcięcia dla BottomAppBar, TopAppBar, BottomNavigation i NavigationRail. Podobnie użyj parametru contentWindowInsets w przypadku atrybutu Scaffold.
• Jeśli Twoja aplikacja korzysta z widoków i komponentów Material Design (com.google.android.material), większość komponentów Material Design opartych na widokach, takich jak BottomNavigationView, BottomAppBar, NavigationRailView lub NavigationView, obsługuje wbudowane elementy i nie wymaga dodatkowych działań. Jeśli używasz AppBarLayout, musisz jednak dodać android:fitsSystemWindows="true".
• W przypadku niestandardowych komponentów zastosuj wstawione elementy ręcznie jako wypełnienie. Jeśli Twój content znajduje się w Scaffold, możesz używać wstawionych elementów, korzystając z wartości wypełnienia Scaffold. W przeciwnym razie zastosuj wypełnienie za pomocą jednej z opcji WindowInsets.
• Jeśli Twoja aplikacja używa widoków i kontenerów BottomSheet, SideSheet lub niestandardowych, zastosuj wypełnienie za pomocą elementu ViewCompat.setOnApplyWindowInsetsListener. W przypadku RecyclerView zastosuj wypełnienie za pomocą tego listenera i dodaj clipToPadding="false".

Co sprawdzić, jeśli aplikacja musi zapewniać niestandardową ochronę w tle

Jeśli Twoja aplikacja musi zapewniać niestandardową ochronę w tle w przypadku nawigacji z 3 przyciskami lub paska stanu, powinna umieszczać komponenty lub widoki za pomocą WindowInsets.Type#tappableElement(), aby uzyskać wysokość paska nawigacji z 3 przyciskami lub WindowInsets.Type#statusBars.

Dodatkowe materiały dotyczące edge-to-edge

Więcej informacji o ramkach w trybie pełnoekranowym znajdziesz w przewodnikach Wyświetlanie w ramce pełnoekranowej i Tworzenie treści w ramce pełnoekranowej.

Wycofane interfejsy API

Te interfejsy API są przestarzałe, ale nie zostały wyłączone:

• R.attr#enforceStatusBarContrast
• R.attr#navigationBarColor (nawigacja przy użyciu 3 przycisków z 80% alfa)
• Window#isStatusBarContrastEnforced
• Window#setNavigationBarColor (nawigacja przy użyciu 3 przycisków, przezroczystość 80%)
• Window#setStatusBarContrastEnforced

Te interfejsy API są wycofane i wyłączone:

• R.attr#navigationBarColor (do nawigacji przy użyciu gestów)
• R.attr#navigationBarDividerColor
• R.attr#statusBarColor
• Window#setDecorFitsSystemWindows
• Window#getNavigationBarColor
• Window#getNavigationBarDividerColor
• Window#getStatusBarColor
• Window#setNavigationBarColor (do nawigacji przy użyciu gestów)
• Window#setNavigationBarDividerColor
• Window#setStatusBarColor

Stabilna konfiguracja

Jeśli Twoja aplikacja jest kierowana na Androida 15 (poziom API 35) lub nowszego, Configurationnie wyklucza już pasków systemowych. Jeśli do obliczenia układu używasz rozmiaru ekranu w klasie Configuration, zastąp go lepszymi alternatywami, takimi jak ViewGroup, WindowInsets lub WindowMetricsCalculator, w zależności od potrzeb.

Interfejs Configuration jest dostępny od wersji API 1. Zwykle jest ona uzyskiwana z Activity.onConfigurationChanged. Zawiera on informacje o gęstości okna, orientacji i rozmiarach. Jedną z ważnych cech rozmiarów okien zwracanych przez funkcję Configuration jest to, że wcześniej wykluczano paski systemu.

Rozmiar konfiguracji jest zwykle używany do wyboru zasobów, np. /res/layout-h500dp, i nadal jest to ważny przypadek użycia. Nie zalecamy jednak używania go do obliczania układu. Jeśli tak, odejdź od niego. W zależności od przypadku użycia Configuration należy zastąpić czymś bardziej odpowiednim.

Jeśli używasz go do obliczania układu, użyj odpowiedniej wartości ViewGroup, np. CoordinatorLayout lub ConstraintLayout. Jeśli używasz go do określenia wysokości paska nawigacyjnego systemu, użyj WindowInsets. Jeśli chcesz sprawdzić bieżący rozmiar okna aplikacji, użyj computeCurrentWindowMetrics.

Poniżej znajdziesz listę pól, których dotyczy ta zmiana:

• Rozmiary Configuration.screenWidthDp i screenHeightDp nie wykluczają już pasków systemu.
• Zmiany w usługach screenWidthDp i screenHeightDp mają pośredni wpływ na usługę Configuration.smallestScreenWidthDp.
• Configuration.orientation jest pośrednio dotknięty zmianami w funkcjach screenWidthDp i screenHeightDp na urządzeniach z ekranem zbliżonym do kwadratu.
• Display.getSize(Point) jest pośrednio dotknięty zmianami w Configuration. Został on wycofany od poziomu interfejsu API 30.
• Display.getMetrics() działa w ten sposób od poziomu API 33.

Wartość domyślna atrybutu elegantTextHeight to Prawda.

W przypadku aplikacji przeznaczonych na Androida 15 (poziom interfejsu API 35) atrybut elegantTextHeight TextView domyślnie staje się true, co zastępuje czcionkę kompaktową używaną domyślnie w niektórych skryptach, które mają duże wymiary pionowe, czcionką o znacznie lepszej czytelności. Czcionka kompaktowa została wprowadzona, aby zapobiec rozmieszczaniu elementów układu. Android 13 (poziom interfejsu API 33) zapobiega wielu takim problemom, ponieważ pozwala na rozciąganie wysokości układu tekstu za pomocą atrybutu fallbackLineSpacing.

W Androidzie 15 czcionka kompaktowa nadal pozostaje w systemie, więc aplikacja może ustawić wartość elegantTextHeight na false, aby uzyskać takie samo działanie jak wcześniej, ale jest mało prawdopodobne, aby była obsługiwana w przyszłych wersjach. Jeśli Twoja aplikacja obsługuje te pismo: arabski, kannada, oriya, tamilski, telugu, gudżarati, malajalam, birmański, gudźarati, kannada, malajalam, oriya, telugu lub tajski, przetestuj ją, ustawiając wartość elegantTextHeight na true.

Zmiany szerokości TextView w przypadku złożonych kształtów liter

W poprzednich wersjach Androida niektóre czcionki kursywe lub języki ze złożonym kształtem mogą rysować litery w obszarze poprzedniego lub następnego znaku. Zdarzało się, że takie litery były obcinane na początku lub na końcu. Od Androida 15 TextView przydziela wystarczającą ilość miejsca na wyświetlenie takich liter, a aplikacje mogą prosić o dodatkowe wypełnienie po lewej stronie, aby zapobiec przycięciu.

Ta zmiana wpływa na sposób określania szerokości przez TextView, więc TextView domyślnie przydziela więcej szerokości, jeśli aplikacja jest kierowana na Androida 15 (poziom API 35) lub nowszego. Możesz włączyć lub wyłączyć tę funkcję, wywołując interfejs API setUseBoundsForWidth w komponencie TextView.

Dodanie dopełnienia z lewej strony może spowodować niewłaściwe ułożenie istniejących układów, dlatego dopełnienie nie jest dodawane domyślnie nawet w przypadku aplikacji kierowanych na Androida 15 lub nowszego. Możesz jednak dodać dodatkowy margines, aby zapobiec przycięciu, wywołując funkcję setShiftDrawingOffsetForStartOverhang.

W poniższych przykładach pokazujemy, jak te zmiany mogą poprawić układ tekstu w przypadku niektórych czcionek i języków.

Standardowy układ angielskiej czcionki zapisanej kursywą. Niektóre litery są przycięte. Oto odpowiedni kod XML:

<TextView
    android:fontFamily="cursive"
    android:text="java" />

Układ tego samego tekstu w języku angielskim z dodatkową szerokością i odstępem. Oto odpowiedni kod XML:

<TextView
    android:fontFamily="cursive"
    android:text="java"
    android:useBoundsForWidth="true"
    android:shiftDrawingOffsetForStartOverhang="true" />

Standardowy układ tekstu tajskiego. Niektóre litery są przycięte. Oto odpowiedni kod XML:

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

Układ tego samego tekstu w języku tajskim z dodatkową szerokością i dopełnieniem. Oto odpowiedni kod XML:

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

Domyślna wysokość wiersza EditText uwzględniająca lokalizację

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

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

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

Aparat i multimedia

W Androidzie 15 wprowadzono następujące zmiany zachowania aparatu i multimediów w aplikacjach kierowanych na Androida 15 lub nowszego.

Ograniczenia dotyczące prośby o skupienie się na dźwięku

Aplikacje kierowane na Androida 15 (poziom API 35) muszą być aplikacjami na pierwszym planie lub usługami na pierwszym planie, aby poprosić o uzyskanie kontroli nad dźwiękiem. Jeśli aplikacja próbuje poprosić o skupienie uwagi, gdy nie spełnia jednego z tych wymagań, wywołanie zwraca AUDIOFOCUS_REQUEST_FAILED.

Więcej informacji o fokusowaniu dźwięku znajdziesz w artykule Zarządzanie fokusem dźwięku.

Zaktualizowane ograniczenia inne niż związane z pakietem SDK

Android 15 includes updated lists of restricted non-SDK interfaces based on collaboration with Android developers and the latest internal testing. Whenever possible, we make sure that public alternatives are available before we restrict non-SDK interfaces.

If your app does not target Android 15, some of these changes might not immediately affect you. However, while it's possible for your app to access some non-SDK interfaces depending on your app's target API level, using any non-SDK method or field always carries a high risk of breaking your app.

If you are unsure if your app uses non-SDK interfaces, you can test your app to find out. If your app relies on non-SDK interfaces, you should begin planning a migration to SDK alternatives. Nevertheless, we understand that some apps have valid use cases for using non-SDK interfaces. If you can't find an alternative to using a non-SDK interface for a feature in your app, you should request a new public API.

Więcej informacji o zmianach w tej wersji Androida znajdziesz w artykule Zmiany ograniczeń interfejsu niebędącego interfejsem SDK w Androidzie 15. Więcej informacji o interfejsach innych niż SDK znajdziesz w artykule Ograniczenia interfejsów innych niż SDK.