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

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

Zapoznaj się też z listą zmian w zachowaniu, które mają wpływ 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

We are making the following changes to foreground services with Android 15.

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 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

New media processing foreground service type

W Androidzie 15 wprowadziliśmy nowy typ usługi na pierwszym planie: mediaProcessing. Ten typ usługi jest odpowiedni do operacji takich jak transkodowanie plików multimedialnych. Na przykład aplikacja multimedialna może pobrać plik audio i przed odtworzeniem musi przekonwertować go na inny format. Możesz użyć usługi mediaProcessing na pierwszym planie, aby mieć pewność, że konwersja będzie kontynuowana nawet wtedy, gdy aplikacja będzie działać w tle.

System zezwala na działanie usług mediaProcessing aplikacji przez łącznie 6 godzin w okresie 24 godzin. Po tym czasie system wywołuje metodę Service.onTimeout(int, int) (wprowadzoną w Androidzie 15). Obecnie usługa ma kilka sekund na wywołanie funkcji Service.stopSelf(). Jeśli usługa nie wywołuje funkcji Service.stopSelf(), system zgłasza wewnętrzny wyjątek. Wyjątek jest logowany w Logcat z tym komunikatem:

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

Aby uniknąć wyjątku, wykonaj 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 mediaProcessing 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ą, zresetowując w ten sposób timer).
  3. Uruchamiaj usługi na pierwszym planie mediaProcessing tylko w wyniku bezpośredniej interakcji z użytkownikiem. Ponieważ aplikacja jest na pierwszym planie, gdy usługa się uruchamia, ma ona 6 godzin na działanie po przejściu aplikacji w tło.
  4. Zamiast usługi na pierwszym planie mediaProcessing użyj alternatywnego interfejsu API, takiego jak WorkManager.

Jeśli w ciągu ostatnich 24 godzin usługi mediaProcessing na pierwszym planie aplikacji działały przez 6 godzin, nie możesz uruchomić innej usługi mediaProcessing 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ę działającą na pierwszym planie mediaProcessing, system wyświetli komunikat o błędzie podobny do „Czas limitu usługi działającej na pierwszym planie typu mediaProcessing został już wykorzystany”.ForegroundServiceStartNotAllowedException

Więcej informacji o typie usługi mediaProcessing znajdziesz w artykule Zmiany w typach usług na pierwszym planie w Androidzie 15: przetwarzanie multimediów.

Testowanie

Aby przetestować działanie aplikacji, możesz włączyć limity czasu przetwarzania multimediów, 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ć czas 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 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:

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

Wcześniej, jeśli aplikacja miała uprawnienia SYSTEM_ALERT_WINDOW, mogła uruchomić usługę na pierwszym planie, nawet jeśli była w tej chwili uruchomiona w tle (jak opisano w wyjątkach od ograniczeń dotyczących uruchamiania w tle).

Jeśli aplikacja jest kierowana na Androida 15, wykluczenie jest teraz bardziej precyzyjne. Aplikacja musi mieć teraz uprawnienia SYSTEM_ALERT_WINDOW, a także mieć widoczne okno nakładki. Oznacza to, że aplikacja musi najpierw uruchomić okno TYPE_APPLICATION_OVERLAY i to okno musi być widoczne, zanim uruchomisz usługę na pierwszym planie.

Jeśli aplikacja próbuje uruchomić usługę działającą na pierwszym planie w tle bez spełnienia tych nowych wymagań (i nie ma żadnych innych wyjątków), system zgłasza ForegroundServiceStartNotAllowedException.

Jeśli Twoja aplikacja deklaruje uprawnienie SYSTEM_ALERT_WINDOW i uruchamia usługi na pierwszym planie z poziomu usług działających w tle, może być dotknięta tą zmianą. Jeśli Twoja aplikacja otrzymuje ForegroundServiceStartNotAllowedException, sprawdź kolejność jej działań i upewnij się, że aplikacja ma już aktywne okno nakładki, zanim spróbuje uruchomić usługę na pierwszym planie z tle. Aby sprawdzić, czy okno nakładki jest obecnie widoczne, wywołaj View.getWindowVisibility() lub zastąp View.onWindowVisibilityChanged(), aby otrzymywać powiadomienia o zmianie widoczności.

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). Aby włączyć nowe ograniczenia dotyczące uruchamiania usług na pierwszym planie w tle, uruchom to polecenie adb:

adb shell am compat enable FGS_SAW_RESTRICTIONS your-package-name

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

以 Android 15（API 级别 35）及更高版本为目标平台的应用无法再更改设备上的勿扰 (DND) 功能的全局状态或政策（无论是通过修改用户设置还是关闭勿扰模式）。相反，应用必须提供 AutomaticZenRule，系统会将其与现有的“最严格的政策优先”方案合并为一个全局政策。对之前会影响全局状态的现有 API 的调用（setInterruptionFilter、setNotificationPolicy）会导致创建或更新隐式 AutomaticZenRule，该 AutomaticZenRule 会根据这些 API 调用的调用周期开启和关闭。

请注意，只有当应用调用 setInterruptionFilter(INTERRUPTION_FILTER_ALL) 并希望该调用停用之前由其所有者激活的 AutomaticZenRule 时，此更改才会影响可观察到的行为。

Zmiany w interfejsie OpenJDK API

Android 15 将继续更新 Android 的核心库，以与最新 OpenJDK LTS 版本中的功能保持一致。

以下变更可能会影响以 Android 15（API 级别 35）为目标平台的应用的兼容性：

  • 对字符串格式化 API 进行了更改：现在，使用以下 String.format() 和 Formatter.format() API 时，对实参索引、标志、宽度和精度的验证要求变得更加严格：

    例如，当使用参数索引 0（格式字符串中的 %0）时，系统会抛出以下异常：

    IllegalFormatArgumentIndexException: Illegal format argument index = 0

    在这种情况下，可以使用实参索引 1（格式字符串中的 %1）来解决此问题。

  • 对 Arrays.asList(...).toArray() 的组件类型所做的更改：使用 Arrays.asList(...).toArray() 时，所得数组的组件类型现在是 Object，而不是底层数组元素的类型。因此，以下代码会抛出 ClassCastException：

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

    在这种情况下，为了在生成的数组中保留 String 作为组件类型，您可以改用 Collection.toArray(Object[])：

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

  • 语言代码处理方面的变更：使用 Locale API 时，希伯来语、意第绪语和印度尼西亚语的语言代码不再转换为其过时的形式（希伯来语：iw、意第绪语：ji 和印度尼西亚语：in）。指定这些语言区域的语言代码时，请改用 ISO 639-1 中的代码（希伯来语：he、意第绪语：yi 和印度尼西亚语：id）。

  • 随机整数序列的更改：根据 https://bugs.openjdk.org/browse/JDK-8301574 中所做的更改，以下 Random.ints() 方法现在返回的数字序列与 Random.nextInt() 方法返回的数字序列不同：

    一般来说，此更改不应导致应用出现破坏性行为，但您的代码不应期望从 Random.ints() 方法生成的序列与 Random.nextInt() 相匹配。

在您更新应用 build 配置中的 compileSdk 以使用 Android 15（API 级别 35）后，新的 SequencedCollection API 可能会影响应用的兼容性：

  • kotlin-stdlib 中 MutableList.removeFirst() 和 MutableList.removeLast() 扩展函数的冲突

    Java 中的 List 类型会映射到 Kotlin 中的 MutableList 类型。 由于 List.removeFirst() 和 List.removeLast() API 已在 Android 15（API 级别 35）中引入，因此 Kotlin 编译器会将函数调用（例如 list.removeFirst()）静态解析为新的 List API，而不是 kotlin-stdlib 中的扩展函数。

    如果某个应用重新编译时将 compileSdk 设置为 35，并将 minSdk 设置为 34 或更低值，然后该应用在 Android 14 及更低版本上运行，则会抛出运行时错误：

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

    Android Gradle 插件中现有的 NewApi lint 选项可以捕获这些新的 API 用法。

    ./gradlew lint

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

    如需修正运行时异常和 lint 错误，可以在 Kotlin 中将 removeFirst() 和 removeLast() 函数调用分别替换为 removeAt(0) 和 removeAt(list.lastIndex)。如果您使用的是 Android Studio Ladybug | 2024.1.3 或更高版本，它还会针对这些错误提供快速修复选项。

    如果已停用 lint 选项，请考虑移除 @SuppressLint("NewApi") 和 lintOptions { disable 'NewApi' }。

  • 与 Java 中的其他方法发生冲突

    现有类型中添加了新方法，例如 List 和 Deque。这些新方法可能与具有相同名称和实参类型的其他接口和类中的方法不兼容。如果方法签名发生不兼容的冲突，javac 编译器会输出 build 时错误。例如：

    错误示例 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

    错误示例 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

    错误示例 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

    如需修复这些 build 错误，实现这些接口的类应使用兼容的返回类型替换相应方法。例如：

    @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 złośliwymi aplikacjami.

Ograniczone wersje protokołu 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ójnej i intuicyjnej obsługi.

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.

全面实施政策

Aplikacje są domyślnie wyświetlane bez ramki na urządzeniach z Androidem 15, jeśli są kierowane na tę wersję systemu (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 na urządzeniu z Androidem 15 jest wyświetlana od krawędzi do krawędzi. 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 wymuszanie wyświetlania bez ramki w 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ę gestami.
  • Nawigacja przy użyciu 3 przycisków
    • Domyślnie ustawiona jest nieprzezroczystość na poziomie 80%, a kolor może być dopasowany do tła okna.
    • Dolne przesunięcie jest wyłączone, więc treść jest rysowana za paskiem nawigacyjnym systemu, chyba że zastosowano wstawki.
    • setNavigationBarColor i R.attr#navigationBarColor są domyślnie dopasowane do tła okna. Tło okna musi być rysunkiem w kolorze, aby można było zastosować tę wartość domyślną. Ten interfejs API został wycofany, ale nadal wpływa na nawigację 3-przyciskową.
    • setNavigationBarContrastEnforced i R.attr#navigationBarContrastEnforced mają domyślnie wartość „prawda”, co dodaje 80-procentowe nieprzezroczyste tło w przypadku nawigacji za pomocą 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 na wyświetlaczu
    • Wartość layoutInDisplayCutoutMode okien niepływających musi być równa 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 na wyświetlaczu, 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 na urządzeniu z Androidem 15 zajmuje cały ekran. Jednak wiele elementów jest teraz ukrytych przez pasek stanu, pasek nawigacyjny z 3 przyciskami lub wycięcie na wyświetlaczu 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 wcięcia, aby interfejs użytkownika 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 na całym ekranie 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 zamiast LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS używa SHORT_EDGES, NEVER lub DEFAULT. 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 zostaną zmienione, 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 wstawek i zastosować je ręcznie. W androidx.compose.material 1.6.0 i nowszych wersjach użyj parametru windowInsets, aby ręcznie zastosować wcięcia w przypadku BottomAppBar, TopAppBar, BottomNavigation i NavigationRail. Podobnie użyj parametru contentWindowInsets dla 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 kompozycji niestandardowych zastosuj wstawki ręcznie jako dopełnienie. Jeśli treść znajduje 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 elementu RecyclerView zastosuj dopełnienie za pomocą tego odbiornika, a także dodaj element 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 Compose od krawędzi do krawędzi.

Wycofane interfejsy API

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

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

稳定配置

If your app targets Android 15 (API level 35) or higher, Configuration no longer excludes the system bars. If you use the screen size in the Configuration class for layout calculation, you should replace it with better alternatives like an appropriate ViewGroup, WindowInsets, or WindowMetricsCalculator depending on your need.

Configuration has been available since API 1. It is typically obtained from Activity.onConfigurationChanged. It provides information like window density, orientation, and sizes. One important characteristic about the window sizes returned from Configuration is that it previously excluded the system bars.

The configuration size is typically used for resource selection, such as /res/layout-h500dp, and this is still a valid use case. However, using it for layout calculation has always been discouraged. If you do so, you should move away from it now. You should replace the use of Configuration with something more suitable depending on your use case.

If you use it to calculate the layout, use an appropriate ViewGroup, such as CoordinatorLayout or ConstraintLayout. If you use it to determine the height of the system navbar, use WindowInsets. If you want to know the current size of your app window, use computeCurrentWindowMetrics.

The following list describes the fields affected by this change:

Atrybut elegantTextHeight ma domyślnie wartość true.

对于以 Android 15（API 级别 35）为目标平台的应用，elegantTextHeight TextView 属性默认会变为 true，将默认使用的紧凑字体替换为一些具有较大垂直测量的脚本，使其更易于阅读。紧凑字体旨在防止布局中断；Android 13（API 级别 33）允许文本布局利用 fallbackLineSpacing 属性拉伸垂直高度，从而防止许多此类中断。

在 Android 15 中，系统中仍保留了紧凑字体，因此您的应用可以将 elegantTextHeight 设置为 false 以获得与之前相同的行为，但即将发布的版本不太可能支持此字体。因此，如果您的应用支持以下脚本：阿拉伯语、老挝语、缅甸语、泰米尔语、古吉拉特语、卡纳达语、马拉雅拉姆语、奥里亚语、泰卢固语或泰语，请将 elegantTextHeight 设置为 true 以测试您的应用。

针对以 Android 14（API 级别 34）及更低版本为目标平台的应用的 elegantTextHeight 行为。
以 Android 15 为目标平台的应用的 elegantTextHeight 行为。

Szerokość widoku TextView zmienia się 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 w widoku EditText uwzględniająca ustawienia regionalne

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

Android 15 wprowadza te zmiany w działaniu aplikacji w zakresie kamery i multimediów, które są kierowane na Androida 15 lub nowszego.

Ograniczenia dotyczące żądania fokusu audio

以 Android 15（API 级别 35）为目标平台的应用必须是顶部应用或正在运行前台服务，才能请求音频焦点。如果应用在未满足上述任一要求的情况下尝试请求焦点，调用将返回 AUDIOFOCUS_REQUEST_FAILED。

如需详细了解音频焦点，请参阅管理音频焦点。

Zaktualizowane ograniczenia dotyczące interfejsów API innych niż 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 aplikację. 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.

如需详细了解此 Android 版本中的变更，请参阅 Android 15 中有关限制非 SDK 接口的更新。如需全面了解有关非 SDK 接口的详细信息，请参阅对非 SDK 接口的限制。