Zmiany w działaniu: wszystkie aplikacje

Platforma Android 16 zawiera zmiany w działaniu, które mogą mieć wpływ na Twoją aplikację. Poniższe zmiany w działaniu mają zastosowanie do wszystkich aplikacji uruchamianych na Androidzie 16, niezależnie od targetSdkVersion. Przetestuj aplikację, a potem w razie potrzeby zmodyfikuj ją, aby obsługiwała te zmiany.

Zapoznaj się też z listą zmian w działaniu, które mają wpływ tylko na aplikacje kierowane na Androida 16.

Główna funkcja

Android 16 (API na poziomie 36) zawiera te zmiany, które modyfikują lub rozszerzają różne podstawowe funkcje systemu Android.

Optymalizacje limitów JobScheduler

Od Androida 16 dostosowujemy limit czasu wykonywania zwykłych i przyspieszonych zadań na podstawie tych czynników:

  • Do którego zasobnika gotowości aplikacji należy aplikacja: w Androidzie 16 aktywne zasobniki gotowości będą egzekwowane przez duży limit czasu działania.
  • Jeśli zadanie rozpocznie się, gdy aplikacja jest na pierwszym planie: w Androidzie 16 zadania rozpoczęte, gdy aplikacja jest widoczna dla użytkownika, i kontynuowane po tym, jak aplikacja stanie się niewidoczna, będą podlegać limitowi czasu wykonywania zadania.
  • Jeśli zadanie jest wykonywane podczas działania usługi na pierwszym planie: w Androidzie 16 zadania wykonywane równocześnie z usługą na pierwszym planie będą podlegać limitowi czasu wykonywania zadania. Jeśli używasz zadań do przesyłania danych inicjowanego przez użytkownika, rozważ użycie zadań przesyłania danych inicjowanego przez użytkownika.

Ta zmiana ma wpływ na zadania zaplanowane za pomocą WorkManagera, JobSchedulera i DownloadManagera. Aby sprawdzić, dlaczego zadanie zostało zatrzymane, zalecamy zarejestrowanie przyczyny zatrzymania zadania przez wywołanie funkcji WorkInfo.getStopReason() (w przypadku zadań JobScheduler wywołaj funkcję JobParameters.getStopReason()).

Informacje o tym, jak stan aplikacji wpływa na zasoby, z których może korzystać, znajdziesz w sekcji Limity zasobów związane z zarządzaniem energią. Więcej informacji o sprawdzonych metodach optymalnego wykorzystania baterii znajdziesz w przewodniku na temat optymalizacji wykorzystania baterii w przypadku interfejsów API do planowania zadań.

Zalecamy też korzystanie z nowego interfejsu API JobScheduler#getPendingJobReasonsHistory wprowadzonego w Androidzie 16, aby dowiedzieć się, dlaczego zadanie nie zostało wykonane.

Testowanie

Aby przetestować działanie aplikacji, możesz włączyć zastępowanie niektórych optymalizacji limitu zadań, o ile aplikacja działa na urządzeniu z Androidem 16.

Aby wyłączyć egzekwowanie zasady „najwyższy stan będzie zgodny z limitem czasu działania zadania”, uruchom to polecenie: adb

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_TOP_STARTED_JOBS APP_PACKAGE_NAME

Aby wyłączyć egzekwowanie zasady „zadania wykonywane równocześnie z usługą na pierwszym planie będą podlegać limitowi czasu działania zadania”, uruchom to polecenie:adb

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_FGS_JOBS APP_PACKAGE_NAME

Aby przetestować określone zachowanie zasobnika gotowości aplikacji, możesz ustawić zasobnik gotowości aplikacji za pomocą tego polecenia adb:

adb shell am set-standby-bucket APP_PACKAGE_NAME active|working_set|frequent|rare|restricted

Aby sprawdzić, w którym zasobniku gotowości aplikacji znajduje się Twoja aplikacja, możesz użyć tego polecenia adb:

adb shell am get-standby-bucket APP_PACKAGE_NAME

Przyczyna zatrzymania porzuconych pustych zadań

Porzucenie zadania ma miejsce, gdy powiązany z nim obiekt JobParameters został usunięty, ale metoda JobService#jobFinished(JobParameters, boolean) nie została wywołana, aby zasygnalizować ukończenie zadania. Oznacza to, że zadanie może być wykonywane i przeplanowywane bez wiedzy aplikacji.

Aplikacje korzystające z JobScheduler nie utrzymują silnego odwołania do obiektu JobParameters, a czas oczekiwania będzie teraz mieć nowy powód zatrzymania zadania STOP_REASON_TIMEOUT_ABANDONED zamiast STOP_REASON_TIMEOUT.

Jeśli nowy powód zaniechania będzie występował często, system podejmie działania zaradcze, aby zmniejszyć częstotliwość wykonywania zadań.

Aplikacje powinny używać nowego powodu zatrzymania, aby wykrywać i zmniejszać liczbę porzuconych zadań.

Jeśli używasz WorkManagera, AsyncTaska lub DownloadManagera, nie musisz nic robić, ponieważ te interfejsy API zarządzają cyklem pracy w imieniu aplikacji.

Całkowite wycofanie JobInfo#setImportantWhileForeground

Metoda JobInfo.Builder#setImportantWhileForeground(boolean) wskazuje ważność zadania, gdy aplikacja do planowania jest na pierwszym planie lub gdy jest tymczasowo zwolniona z ograniczeń działania w tle.

Ta metoda została wycofana w Androidzie 12 (poziom API 31). Od Androida 16 ta metoda nie działa już prawidłowo i jej wywołanie zostanie zignorowane.

Usunięcie tej funkcji dotyczy również JobInfo#isImportantWhileForeground(). Od wersji 16 Androida, jeśli metoda jest wywoływana, zwraca ona false.

Zakres priorytetu uporządkowanej transmisji nie jest już globalny

Aplikacje na Androida mogą definiować priorytety odbiorników transmisji, aby kontrolować kolejność, w jakiej odbiorniki otrzymują i przetwarzają transmisję. W przypadku odbiorników zadeklarowanych w manifeście aplikacje mogą używać atrybutu android:priority do definiowania priorytetu, a w przypadku odbiorników zarejestrowanych w kontekście aplikacje mogą używać interfejsu API IntentFilter#setPriority() do definiowania priorytetu. Gdy przesyłasz transmisję, system dostarcza ją odbiorcom w kolejności priorytetów, od najwyższego do najniższego.

W Androidzie 16 kolejność wysyłania danych w ramach transmisji z użyciem atrybutu android:priority lub IntentFilter#setPriority() w różnych procesach nie będzie gwarantowana. Priorytety transmisji będą uwzględniane tylko w ramach tego samego procesu aplikacji, a nie wszystkich procesów.

Priorytety transmisji będą automatycznie ograniczone do zakresu (SYSTEM_LOW_PRIORITY + 1, SYSTEM_HIGH_PRIORITY - 1). Ustawienie SYSTEM_LOW_PRIORITY, SYSTEM_HIGH_PRIORITY jako priorytetu transmisji będzie możliwe tylko dla komponentów systemowych.

Na Twoją aplikację może mieć wpływ:

  1. Twoja aplikacja ma zadeklarowane 2 procesy z tym samym zamiarem przesyłania strumienia danych i oczekuje, że te zamiary będą odbierane w określonej kolejności na podstawie priorytetu.
  2. Proces aplikacji wchodzi w interakcje z innymi procesami i oczekuje określonej kolejności otrzymywania intencji rozgłoszenia.

Jeśli procesy muszą ze sobą współpracować, powinny komunikować się za pomocą innych kanałów koordynacji.

Wewnętrzne zmiany ART

Android 16 zawiera najnowsze aktualizacje środowiska wykonawczego Android Runtime (ART), które poprawiają wydajność tego środowiska i zapewniają obsługę dodatkowych funkcji Javy. Dzięki aktualizacjom systemowym Google Play te ulepszenia są też dostępne na ponad miliardzie urządzeń z Androidem 12 (poziom interfejsu API 31) lub nowszym.

Po wprowadzeniu tych zmian biblioteki i kod aplikacji korzystające z wewnętrznych struktur ART mogą nie działać prawidłowo na urządzeniach z Androidem 16 oraz na starszych wersjach Androida, które aktualizują moduł ART za pomocą aktualizacji systemu Google Play.

Używanie wewnętrznych struktur (np. interfejsów innych niż SDK) może zawsze prowadzić do problemów ze zgodnością, ale szczególnie ważne jest unikanie korzystania z kodu (lub bibliotek zawierających kod), który wykorzystuje wewnętrzne struktury ART, ponieważ zmiany w ART nie są powiązane z wersją platformy, na której działa urządzenie, i są udostępniane ponad miliardowi urządzeń za pomocą aktualizacji systemu Google Play.

Wszyscy deweloperzy powinni dokładnie przetestować swoje aplikacje na Androidzie 16, aby sprawdzić, czy nie są one dotknięte problemami. Dodatkowo sprawdź znane problemy, aby sprawdzić, czy Twoja aplikacja jest zależna od zidentyfikowanych przez nas bibliotek, które korzystają z wewnętrznych struktur ART. Jeśli masz kod aplikacji lub zależności biblioteki, które są dotknięte, poszukaj alternatywnych publicznych interfejsów API i poproś o publiczne interfejsy API do nowych zastosowań, tworząc prośbę o dodanie funkcji w naszym systemie śledzenia problemów.

Tryb zgodności z rozmiarem strony 16 KB

Android 15 introduced support for 16 KB memory pages to optimize performance of the platform. Android 16 adds a compatibility mode, allowing some apps built for 4 KB memory pages to run on a device configured for 16 KB memory pages.

When your app is running on a device with Android 16 or higher, if Android detects that your app has 4 KB aligned memory pages, it automatically uses compatibility mode and display a notification dialog to the user. Setting the android:pageSizeCompat property in the AndroidManifest.xml to enable the backwards compatibility mode will prevent the display of the dialog when your app launches. To use the android:pageSizeCompat property, compile your app using the Android 16 SDK.

For best performance, reliability, and stability, your app should still be 16 KB aligned. Check out our recent blog post on updating your apps to support 16 KB memory pages for more details.

The compatibility mode dialog that displays when the system detects that a 4 KB-aligned app could run more optimally if 16 KB aligned.

Wrażenia użytkowników i interfejs systemu

Android 16 (poziom API 36) zawiera te zmiany, które mają na celu zapewnienie bardziej spójnego i intuicyjnego interfejsu użytkownika.

Wycofywanie uciążliwych komunikatów ułatwień dostępu

W Androidzie 16 nie są już obsługiwane powiadomienia o ułatwieniach dostępu, które korzystają z announceForAccessibility lub wysyłają zdarzenia ułatwień dostępu TYPE_ANNOUNCEMENT. Mogą one powodować niespójności w działaniu czytnika ekranu TalkBack i Androida, a alternatywne rozwiązania lepiej odpowiadają na potrzeby użytkowników w różnych technologiach wspomagających na Androidzie.

Przykłady alternatyw:

Więcej informacji o sugerowanych zamiennikach znajdziesz w dokumentacji referencyjnej wycofanego interfejsu API announceForAccessibility.

Obsługa nawigacji przy użyciu 3 przycisków

Android 16 umożliwia korzystanie z przewidywanego przycisku Wstecz w nawigacji przy użyciu 3 przycisków w przypadku aplikacji, które zostały prawidłowo przeniesione na przewidywane Wstecz. Długie naciśnięcie przycisku Wstecz inicjuje animację przewidywanego przejścia wstecz, która wyświetla podgląd miejsca, do którego prowadzi przesunięcie wstecz.

To zachowanie dotyczy wszystkich obszarów systemu, które obsługują przewidywane animacje wstecz, w tym animacje systemowe (powrót do ekranu głównego, przełączanie się między zadaniami i czynnościami).

Animacje przewidywanego przejścia wstecz w trybie nawigacji przy użyciu 3 przycisków.

Automatyczne ikony aplikacji z motywem

Beginning with Android 16 QPR 2, Android automatically applies themes to app icons to create a cohesive home screen experience. This occurs if an app does not provide its own themed app icon. Apps can control the design of their themed app icon by including a monochrome layer within their adaptive icon and previewing what their app icon will look like in Android Studio.

Formaty urządzeń

Android 16 (API na poziomie 36) wprowadza te zmiany w aplikacjach, gdy są one wyświetlane na ekranach przez właścicieli urządzeń wirtualnych.

Zastąpienia właściciela urządzenia wirtualnego

A virtual device owner is a trusted or privileged app that creates and manages a virtual device. Virtual device owners run apps on a virtual device and then project the apps to the display of a remote device, such as a personal computer, virtual reality device, or car infotainment system. The virtual device owner is on a local device, such as a mobile phone.

Virtual device owner on phone creates virtual device that projects app to remote display.

Per-app overrides

On devices running Android 16 (API level 36), virtual device owners can override app settings on select virtual devices that the virtual device owners manage. For example, to improve app layout, a virtual device owner can ignore orientation, aspect ratio, and resizability restrictions when projecting apps onto an external display.

Common breaking changes

The Android 16 behavior might impact your app's UI on large screen form factors such as car displays or Chromebooks, especially layouts that were designed for small displays in portrait orientation. To learn how to make your app adaptive for all device form factors, see About adaptive layouts.

References

Companion app streaming

Bezpieczeństwo

Android 16 (poziom interfejsu API 36) zawiera zmiany, które zwiększają bezpieczeństwo systemu, aby chronić aplikacje i użytkowników przed złośliwymi aplikacjami.

Lepsza ochrona przed atakami polegającymi na przekierowaniu intencji

Android 16 provides default security against general Intent redirection attacks, with minimum compatibility and developer changes required.

We are introducing by-default security hardening solutions to Intent redirection exploits. In most cases, apps that use intents normally won't experience any compatibility issues; we've gathered metrics throughout our development process to monitor which apps might experience breakages.

Intent redirection in Android occurs when an attacker can partly or fully control the contents of an intent used to launch a new component in the context of a vulnerable app, while the victim app launches an untrusted sub-level intent in an extras field of an ("top-level") Intent. This can lead to the attacker app launching private components in the context of the victim app, triggering privileged actions, or gaining URI access to sensitive data, potentially leading to data theft and arbitrary code execution.

Opt out of Intent redirection handling

Android 16 introduces a new API that allows apps to opt out of launch security protections. This might be necessary in specific cases where the default security behavior interferes with legitimate app use cases.

For applications compiling against Android 16 (API level 36) SDK or higher

You can directly use the removeLaunchSecurityProtection() method on the Intent object.

val i = intent
val iSublevel: Intent? = i.getParcelableExtra("sub_intent")
iSublevel?.removeLaunchSecurityProtection() // Opt out from hardening
iSublevel?.let { startActivity(it) }
For applications compiling against Android 15 (API level 35) or lower

While not recommended, you can use reflection to access the removeLaunchSecurityProtection() method.

val i = intent
val iSublevel: Intent? = i.getParcelableExtra("sub_intent", Intent::class.java)
try {
    val removeLaunchSecurityProtection = Intent::class.java.getDeclaredMethod("removeLaunchSecurityProtection")
    removeLaunchSecurityProtection.invoke(iSublevel)
} catch (e: Exception) {
    // Handle the exception, e.g., log it
} // Opt-out from the security hardening using reflection
iSublevel?.let { startActivity(it) }

Aplikacje towarzyszące nie otrzymują już powiadomień o przekroczeniu limitu czasu wykrywania

Android 16 wprowadza nowe zachowanie podczas procesu parowania urządzenia towarzyszącego, aby chronić prywatność lokalizacji użytkownika przed szkodliwymi aplikacjami. Wszystkie aplikacje towarzyszące działające na Androidzie 16 nie są już bezpośrednio powiadamiane o czasie oczekiwania na wykrycie za pomocą RESULT_DISCOVERY_TIMEOUT. Zamiast tego użytkownik o takich zdarzeniach jest informowany za pomocą wizualnego okna. Gdy użytkownik zamknie okno, aplikacja otrzyma powiadomienie o nieudanym powiązaniu z RESULT_USER_REJECTED.

Czas wyszukiwania został też wydłużony z pierwotnych 20 sekund, a użytkownik może w dowolnym momencie przerwać wykrywanie urządzenia. Jeśli w ciągu pierwszych 20 sekund od rozpoczęcia wyszukiwania zostanie wykryte co najmniej 1 urządzenie, CDM przestanie wyszukiwać kolejne urządzenia.

Łączność

Android 16 (poziom API 36) zawiera te zmiany w stosie Bluetootha, które poprawiają łączność z urządzeniami peryferyjnymi:

Ulepszona obsługa utraty połączenia

Starting in Android 16, the Bluetooth stack has been updated to improve security and user experience when a remote bond loss is detected. Previously, the system would automatically remove the bond and initiate a new pairing process, which could lead to unintentional re-pairing. We have seen in many instances apps not taking care of the bond loss event in a consistent way.

To unify the experience, Android 16 improved the bond loss handling to the system. If a previously bonded Bluetooth device could not be authenticated upon reconnection, the system will disconnect the link, retain local bond information, and display a system dialog informing users of the bond loss and directing them to re-pair.