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

Podobnie jak w przypadku poprzednich wersji Androida, w Androidzie 15 wprowadziliśmy zmiany w działaniu, które mogą mieć wpływ na Twoją aplikację. Poniższe zmiany w działaniu dotyczą wyłącznie aplikacji kierowanych na Androida 15 lub nowszego. Jeśli Twoja aplikacja jest kierowana na Androida 15 lub nowszego, zmodyfikuj ją, aby w odpowiednich przypadkach prawidłowo obsługiwała te działania.

Zapoznaj się też z listą zmian w działaniu, które wpływają na wszystkie aplikacje działające na Androidzie 15 niezależnie od targetSdkVersion 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

W Androidzie 15 wprowadzamy następujące zmiany w usługach działających na pierwszym planie.

Zachowanie limitu czasu usługi na pierwszym planie synchronizującej dane

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 wywołuje metodę Service.onTimeout(int, int) działającej usługi (wprowadzoną w Androidzie 15). W tej chwili usługa ma kilka sekund na wywołanie metody 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 Twojej aplikacji nie działają przez łącznie 6 godzin w dowolnym okresie 24 godzin (chyba że użytkownik wejdzie w interakcję z aplikacją, resetując minutnik).
  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ę na pierwszym planie dataSync, system wygeneruje ForegroundServiceStartNotAllowedException z komunikatem o błędzie, np. „Limit czasu dla usługi działającej na pierwszym planie typu dataSync został już wyczerpany”.

Testowanie

Aby przetestować działanie aplikacji, możesz włączyć czas oczekiwania na synchronizację danych, nawet jeśli aplikacja nie jest kierowana na Androida 15 (o ile działa 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

Nowy typ usługi działającej na pierwszym planie do przetwarzania multimediów

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

Ograniczenia dotyczące odbiorników BOOT_COMPLETED uruchamiających usługi na pierwszym planie

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:

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

Ograniczenia dotyczące uruchamiania usług na pierwszym planie, gdy aplikacja ma uprawnienia SYSTEM_ALERT_WINDOW

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ć

Aplikacje kierowane na Androida 15 (poziom API 35) lub nowszego nie mogą już zmieniać globalnego stanu ani zasad trybu Nie przeszkadzać na urządzeniu (ani przez modyfikowanie ustawień użytkownika, ani przez wyłączanie trybu Nie przeszkadzać). Zamiast tego aplikacje muszą przekazać AutomaticZenRule, które system połączy w globalne zasady z dotychczasowym schematem „najbardziej restrykcyjne zasady wygrywają”. Wywołania istniejących interfejsów API, które wcześniej wpływały na stan globalny (setInterruptionFilter, setNotificationPolicy), powodują utworzenie lub zaktualizowanie niejawnego AutomaticZenRule, który jest włączany i wyłączany w zależności od cyklu wywołań tych interfejsów API.

Pamiętaj, że ta zmiana wpływa tylko na obserwowalne zachowanie, jeśli aplikacja wywołuje funkcję setInterruptionFilter(INTERRUPTION_FILTER_ALL) i oczekuje, że ta funkcja dezaktywuje AutomaticZenRule, który został wcześniej aktywowany przez właścicieli.

Zmiany w interfejsie OpenJDK API

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

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

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

    Na przykład ten wyjątek jest zgłaszany, gdy używany jest indeks argumentu 0 (%0 w ciągu formatującym):

    IllegalFormatArgumentIndexException: Illegal format argument index = 0

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

  • Zmiany typu komponentu Arrays.asList(...).toArray(): gdy używasz funkcji Arrays.asList(...).toArray(), typ komponentu wynikowej tablicy jest teraz Object, a nie typem elementów tablicy bazowej. Dlatego ten kod zgłasza wyjątek ClassCastException:

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

    W tym przypadku, aby zachować String jako typ komponentu w wynikowej tablicy, możesz użyć Collection.toArray(Object[]):

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

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

  • Zmiany w sekwencjach liczb losowych: w wyniku zmian wprowadzonych w https://bugs.openjdk.org/browse/JDK-8301574 te metodyRandom.ints() zwracają teraz inną sekwencję liczb niż metodyRandom.nextInt():

    Ta zmiana nie powinna powodować nieprawidłowego działania aplikacji, ale kod nie powinien oczekiwać, że sekwencja wygenerowana przez metody Random.ints() będzie zgodna z Random.nextInt().

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

  • Kolizja z funkcjami rozszerzeń MutableList.removeFirst() i MutableList.removeLast() w kotlin-stdlib

    Typ List w Javie jest mapowany na typ MutableList w Kotlinie. Ponieważ interfejsy API List.removeFirst() i List.removeLast() zostały wprowadzone w Androidzie 15 (poziom interfejsu API 35), kompilator Kotlina statycznie rozpoznaje wywołania funkcji, np. list.removeFirst(), jako nowe interfejsy API List zamiast jako funkcje rozszerzeń w kotlin-stdlib.

    Jeśli aplikacja zostanie ponownie skompilowana z ustawieniem compileSdk na 35 i minSdk na 34 lub niższą wartość, a następnie zostanie uruchomiona na Androidzie 14 lub starszym, wystąpi błąd środowiska wykonawczego:

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

    Istniejąca opcja NewApi lint we wtyczce Androida do obsługi Gradle może wykrywać te nowe zastosowania 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ątek środowiska wykonawczego i błędy lint, wywołania funkcji removeFirst() i removeLast() można zastąpić odpowiednio wywołaniami removeAt(0) i removeAt(list.lastIndex) w Kotlinie. Jeśli używasz Androida Studio Ladybug | 2024.1.3 lub nowszego, możesz też skorzystać z opcji szybkiej naprawy tych błędów.

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

  • Kolizja z innymi metodami w Javie

    Do istniejących typów dodaliśmy 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 zwraca błąd w czasie kompilacji. Przykład:

    Przykładowy błąd 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. Przykład:

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

Bezpieczeństwo

Android 15 zawiera zmiany, które zwiększają bezpieczeństwo systemu, aby chronić aplikacje i użytkowników przed szkodliwymi aplikacjami.

Ograniczone wersje TLS

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.

Zabezpieczone uruchamianie aktywności w tle

Android 15 chroni użytkowników przed złośliwymi aplikacjami i zapewnia im większą kontrolę nad urządzeniami. Wprowadziliśmy zmiany, które uniemożliwiają złośliwym aplikacjom działającym w tle przenoszenie innych aplikacji na pierwszy plan, podnoszenie ich uprawnień i nadużywanie interakcji z użytkownikiem. Od Androida 10 (poziom interfejsu API 29) uruchamianie aktywności w tle jest ograniczone.

Inne zmiany

  • Zmień domyślne ustawienie PendingIntent twórców na blokowanie uruchamiania aktywności w tle. Pomaga to zapobiegać przypadkowemu tworzeniu przez aplikacjePendingIntent, które mogłyby być wykorzystywane przez nieuczciwe podmioty.
  • Nie przenoś aplikacji na pierwszy plan, chyba że PendingIntentnadawca na to zezwoli. Ta zmiana ma zapobiegać nadużywaniu przez złośliwe aplikacje możliwości rozpoczynania aktywności w tle. Domyślnie aplikacje nie mogą przenosić stosu zadań na pierwszy plan, chyba że twórca zezwoli na uprawnienia do uruchamiania działań w tle lub nadawca ma uprawnienia do uruchamiania działań w tle.
  • Określa, jak najwyższa aktywność w stosie zadań może zakończyć zadanie. Jeśli aktywność na górze stosu zakończy zadanie, Android wróci do ostatniego aktywnego zadania. Jeśli aktywność niebędąca na pierwszym planie zakończy swoje zadanie, Android wró do ekranu głównego. Nie zablokuje zakończenia tej aktywności.
  • Zapobiegaj uruchamianiu dowolnych działań z innych aplikacji w swoim zadaniu. Ta zmiana uniemożliwia złośliwym aplikacjom wyłudzanie informacji od użytkowników przez tworzenie działań, które wyglądają jak działania innych aplikacji.
  • Blokowanie okien niewidocznych, aby nie były brane pod uwagę podczas uruchamiania aktywności w tle. Pomaga to zapobiegać wykorzystywaniu przez złośliwe aplikacje uruchamiania aktywności w tle do wyświetlania użytkownikom niechcianych lub szkodliwych treści.

Bezpieczniejsze zamiary

W Androidzie 15 wprowadzono StrictMode w przypadku intencji.

Aby wyświetlić szczegółowe dzienniki naruszeń zasad korzystania z Intent, wykonaj te czynności:

Kotlin

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

Java

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

Wrażenia użytkowników i interfejs systemu

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

Zmiany w oknie

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.

Edge-to-edge enforcement

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

Aplikacja kierowana na Androida 14, która nie wyświetla się bez ramki na urządzeniu z Androidem 15.


Aplikacja kierowana na Androida 15 (API na poziomie 35), która jest wyświetlana od krawędzi do krawędzi na urządzeniu z Androidem 15. Ta aplikacja korzysta głównie z komponentów Material 3 Compose, które automatycznie stosują wcięcia. Na ten ekran nie ma negatywnego wpływu wymóg wyświetlania od krawędzi do krawędzi na Androidzie 15.

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

  • Pasek nawigacyjny z uchwytem do gestów
    • Domyślnie przezroczysty.
    • Przesunięcie u dołu jest wyłączone, więc treść jest rysowana za paskiem nawigacji systemowej, chyba że zastosowano wstawki.
    • setNavigationBarColor i R.attr#navigationBarColor są przestarzałe i nie mają wpływu na nawigację przy użyciu gestów.
    • setNavigationBarContrastEnforced i R.attr#navigationBarContrastEnforced nadal nie mają wpływu na nawigację przy użyciu gestów.
  • Nawigacja przy użyciu 3 przycisków
    • Domyślnie nieprzezroczystość jest ustawiona na 80%, a kolor może być dopasowany do tła okna.
    • Dolne przesunięcie jest wyłączone, więc treść jest rysowana za paskiem nawigacji systemu, chyba że zastosowano wstawki.
    • setNavigationBarColor i R.attr#navigationBarColor są domyślnie ustawione tak, aby pasowały do tła okna. Tło okna musi być obiektem rysowalnym w postaci koloru, aby można było zastosować tę wartość domyślną. Ten interfejs API jest wycofany, ale nadal wpływa na nawigację przy użyciu 3 przycisków.
    • setNavigationBarContrastEnforced i R.attr#navigationBarContrastEnforced są domyślnie ustawione na wartość „prawda”, co powoduje dodanie 80-procentowego nieprzezroczystego tła w przypadku nawigacji przy użyciu 3 przycisków.
  • Pasek stanu
    • Domyślnie przezroczysty.
    • Górne przesunięcie jest wyłączone, więc treść jest rysowana za paskiem stanu, chyba że zastosowano wstawki.
    • setStatusBarColor i R.attr#statusBarColor są przestarzałe 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 w ekranie
    • Wartość layoutInDisplayCutoutMode w przypadku okien niepływających musi wynosić LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS. SHORT_EDGES, NEVER i DEFAULT są interpretowane jako ALWAYS, dzięki czemu użytkownicy nie widzą czarnego paska spowodowanego wycięciem w ekranie, a aplikacja jest wyświetlana od krawędzi do krawędzi.

Poniższy przykład pokazuje aplikację przed i po kierowaniu na Androida 15 (API na poziomie 35) oraz przed i po zastosowaniu odcięć. Ten przykład nie jest wyczerpujący. W Androidzie Auto może wyglądać inaczej.

Aplikacja kierowana na Androida 14, która nie wyświetla się bez ramki na urządzeniu z Androidem 15.
Aplikacja kierowana na Androida 15 (API na poziomie 35), która jest wyświetlana od krawędzi do krawędzi na urządzeniu z Androidem 15. Jednak wiele elementów jest teraz ukrytych przez pasek stanu, nawigację przy użyciu 3 przycisków lub wycięcie w ekranie ze względu na wymuszone wyświetlanie bez ramki w Androidzie 15. Ukryty interfejs obejmuje górny pasek aplikacji Material 2, pływające przyciski czynności i elementy listy.
Aplikacja kierowana na Androida 15 (poziom API 35), która zajmuje cały ekran urządzenia z Androidem 15 i stosuje wstawki, aby interfejs nie był ukryty.
Co sprawdzić, jeśli aplikacja jest już wyświetlana od krawędzi do krawędzi

Jeśli Twoja aplikacja jest już wyświetlana od krawędzi do krawędzi i stosuje wstawki, zmiany nie będą miały na nią większego wpływu, z wyjątkiem tych sytuacji: Nawet jeśli uważasz, że ten problem Cię nie dotyczy, zalecamy przetestowanie aplikacji.

  • Masz okno niepływające, 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, przyczyną może być 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ą występować ekrany o mniejszym natężeniu ruchu z zasłoniętym interfejsem. Sprawdź, czy na tych rzadziej odwiedzanych ekranach nie ma zasłoniętego interfejsu. Ekrany o mniejszym natężeniu ruchu to:
    • 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, najprawdopodobniej dotyczy Cię ta zmiana. Oprócz scenariuszy dotyczących aplikacji, które już są wyświetlane od krawędzi do krawędzi, warto wziąć pod uwagę te kwestie:

  • Jeśli Twoja aplikacja korzysta z komponentów Material 3 ( androidx.compose.material3) w Compose, takich jak TopAppBar, BottomAppBar i NavigationBar, te komponenty prawdopodobnie nie są dotknięte problemem, ponieważ automatycznie obsługują wcięcia.
  • Jeśli Twoja aplikacja korzysta z komponentów Material 2 ( androidx.compose.material) w Compose, te komponenty nie obsługują automatycznie wcięć. Możesz jednak uzyskać dostęp do wcięć i zastosować je ręcznie. W androidx.compose.material w wersji 1.6.0 i nowszych używaj parametru windowInsets, aby ręcznie zastosować wcięcia w przypadku BottomAppBar, TopAppBar, BottomNavigation i NavigationRail. Podobnie użyj parametru contentWindowInsets w przypadku 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 czy NavigationView, obsługuje wcięcia i nie wymaga dodatkowej pracy. Jeśli jednak używasz AppBarLayout, musisz dodać android:fitsSystemWindows="true".
  • W przypadku niestandardowych funkcji kompozycyjnych zastosuj wstawki ręcznie jako dopełnienie. Jeśli Twoje treści znajdują się w Scaffold, możesz używać wstawek, korzystając z Scaffoldwartości dopełnienia. W przeciwnym razie zastosuj dopełnienie za pomocą jednego z tych elementów:WindowInsets.
  • Jeśli Twoja aplikacja korzysta z widoków i kontenerów BottomSheet, SideSheet lub niestandardowych, zastosuj dopełnienie za pomocą elementu ViewCompat.setOnApplyWindowInsetsListener. W przypadku RecyclerView zastosuj dopełnienie za pomocą tego odbiornika, a także dodaj clipToPadding="false".
Co sprawdzić, jeśli aplikacja musi oferować niestandardową ochronę w tle

Jeśli aplikacja musi oferować niestandardową ochronę tła w przypadku nawigacji 3-przyciskowej lub paska stanu, powinna umieścić element kompozycyjny lub widok za paskiem systemowym, używając funkcji WindowInsets.Type#tappableElement(), aby uzyskać wysokość paska nawigacyjnego 3-przyciskowego, lub WindowInsets.Type#statusBars.

Dodatkowe materiały dotyczące wyświetlania od krawędzi do krawędzi

Dodatkowe informacje o stosowaniu wcięć znajdziesz w przewodnikach Widoki od krawędzi do krawędzi i Kompozycja od krawędzi do krawędzi.

Wycofane interfejsy API

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

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

Stable configuration

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

Configuration jest dostępny od API 1. Zwykle jest ona uzyskiwana z Activity.onConfigurationChanged. Zawiera informacje takie jak gęstość okien, orientacja i rozmiary. Ważną cechą rozmiarów okien zwracanych przez Configuration jest to, że wcześniej wykluczały one paski systemowe.

Rozmiar konfiguracji jest zwykle używany do wybierania zasobów, np. /res/layout-h500dp, i nadal jest to prawidłowy przypadek użycia. Jednak używanie go do obliczania układu zawsze było odradzane. Jeśli tak jest, odsuń się od niego. W zależności od przypadku użycia zastąp Configuration bardziej odpowiednim elementem.

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

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

Atrybut elegantTextHeight ma domyślnie wartość „true”.

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.

elegantTextHeightdla aplikacji kierowanych na Androida 14 (poziom API 34) i starszego.
elegantTextHeightzachowanie w przypadku aplikacji kierowanych na Androida 15.

Szerokość widoku TextView zmienia się w przypadku złożonych kształtów liter

In previous versions of Android, some cursive fonts or languages that have complex shaping might draw the letters in the previous or next character's area. In some cases, such letters were clipped at the beginning or ending position. Starting in Android 15, a TextView allocates width for drawing enough space for such letters and allows apps to request extra paddings to the left to prevent clipping.

Because this change affects how a TextView decides the width, TextView allocates more width by default if the app targets Android 15 (API level 35) or higher. You can enable or disable this behavior by calling the setUseBoundsForWidth API on TextView.

Because adding left padding might cause a misalignment for existing layouts, the padding is not added by default even for apps that target Android 15 or higher. However, you can add extra padding to preventing clipping by calling setShiftDrawingOffsetForStartOverhang.

The following examples show how these changes can improve text layout for some fonts and languages.

Standard layout for English text in a cursive font. Some of the letters are clipped. Here is the corresponding XML:

<TextView
    android:fontFamily="cursive"
    android:text="java" />
Layout for the same English text with additional width and padding. Here is the corresponding XML:

<TextView
    android:fontFamily="cursive"
    android:text="java"
    android:useBoundsForWidth="true"
    android:shiftDrawingOffsetForStartOverhang="true" />
Standard layout for Thai text. Some of the letters are clipped. Here is the corresponding XML:

<TextView
    android:text="คอมพิวเตอร์" />
Layout for the same Thai text with additional width and padding. Here is the corresponding XML:

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

Domyślna wysokość wiersza w widoku EditText z uwzględnieniem ustawień regionalnych

W poprzednich wersjach Androida układ tekstu rozciągał wysokość tekstu, aby dopasować ją do wysokości wiersza czcionki odpowiadającej bieżącemu ustawieniu języka. Jeśli na przykład treści były w języku japońskim, to ze względu na to, że wysokość linii czcionki japońskiej jest nieco większa niż czcionki łacińskiej, wysokość tekstu była nieco większa. Jednak pomimo tych różnic w wysokościach wierszy element EditText miał jednakowy rozmiar niezależnie od używanej lokalizacji, jak pokazano na poniższym obrazku:

Trzy pola reprezentujące elementy EditText, które mogą zawierać tekst w języku angielskim (en), japońskim (ja) i birmańskim (my). Wysokość EditText jest taka sama, mimo że te języki mają różne wysokości linii.

W przypadku aplikacji kierowanych na Androida 15 (poziom interfejsu API 35) minimalna wysokość linii jest teraz zarezerwowana dla EditText, aby pasowała do czcionki referencyjnej dla określonego języka, jak pokazano na poniższym obrazie:

Trzy pola reprezentujące elementy EditText, które mogą zawierać tekst w języku angielskim (en), japońskim (ja) i birmańskim (my). Wysokość EditText uwzględnia teraz miejsce na domyślną wysokość wiersza dla czcionek w tych językach.

W razie potrzeby aplikacja może przywrócić poprzednie działanie, ustawiając atrybut useLocalePreferredLineHeightForMinimum na false. Może też ustawić niestandardowe minimalne dane pionowe za pomocą interfejsu API setMinimumFontMetrics w językach Kotlin i Java.

Aparat i multimedia

W Androidzie 15 wprowadziliśmy te zmiany w działaniu kamery i multimediów w przypadku aplikacji kierowanych na Androida 15 lub nowszego.

Ograniczenia dotyczące żądania aktywności audio

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.

Zaktualizowane ograniczenia dotyczące pakietów SDK

Android 15 zawiera zaktualizowane listy ograniczonych interfejsów innych niż SDK, które powstały na podstawie współpracy z deweloperami Androida i najnowszych testów wewnętrznych. Zanim ograniczymy interfejsy inne niż SDK, w miarę możliwości udostępniamy publiczne alternatywy.

Jeśli Twoja aplikacja nie jest kierowana na Androida 15, niektóre z tych zmian mogą nie mieć na Ciebie natychmiastowego wpływu. Jednak chociaż aplikacja może mieć dostęp do niektórych interfejsów spoza SDK w zależności od docelowego poziomu interfejsu API, używanie dowolnej metody lub pola spoza SDK zawsze wiąże się z wysokim ryzykiem awarii aplikacji.

Jeśli nie masz pewności, czy Twoja aplikacja używa interfejsów innych niż SDK, możesz to sprawdzić, testując ją. Jeśli Twoja aplikacja korzysta z interfejsów spoza SDK, zacznij planować migrację do alternatywnych pakietów SDK. Zdajemy sobie jednak sprawę, że w przypadku niektórych aplikacji używanie interfejsów innych niż SDK jest uzasadnione. Jeśli nie możesz znaleźć alternatywy dla używania interfejsu spoza pakietu SDK w przypadku funkcji w aplikacji, poproś o nowy publiczny interfejs API.

To learn more about the changes in this release of Android, see Updates to non-SDK interface restrictions in Android 15. To learn more about non-SDK interfaces generally, see Restrictions on non-SDK interfaces.