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 dotyczą wszystkich aplikacji działających 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 wpływają tylko na aplikacje kierowane na Androida 16.

Główna funkcja

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

Optymalizacje limitów JobScheduler

Starting in Android 16, we're adjusting regular and expedited job execution runtime quota based on the following factors:

• Which app standby bucket the application is in: in Android 16, active standby buckets will start being enforced by a generous runtime quota.
• If the job starts execution while the app is in a top state: in Android 16, Jobs started while the app is visible to the user and continues after the app becomes invisible, will adhere to the job runtime quota.
• If the job is executing while running a Foreground Service: in Android 16, jobs that are executing concurrently with a foreground service will adhere to the job runtime quota. If you're leveraging jobs for user initiated data transfer, consider using user initiated data transfer jobs instead.

This change impacts tasks scheduled using WorkManager, JobScheduler, and DownloadManager. To debug why a job was stopped, we recommend logging why your job was stopped by calling WorkInfo.getStopReason() (for JobScheduler jobs, call JobParameters.getStopReason()).

For information about how your app's state affects the resources it can use, see Power management resource limits. For more information on battery-optimal best practices, refer to guidance on optimize battery use for task scheduling APIs.

We also recommend leveraging the new JobScheduler#getPendingJobReasonsHistory API introduced in Android 16 to understand why a job has not executed.

Testing

To test your app's behavior, you can enable override of certain job quota optimizations as long as the app is running on an Android 16 device.

To disable enforcement of "top state will adhere to job runtime quota", run the following adb command:

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_TOP_STARTED_JOBS APP_PACKAGE_NAME

To disable enforcement of "jobs that are executing while concurrently with a foreground service will adhere to the job runtime quota", run the following adb command:

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_FGS_JOBS APP_PACKAGE_NAME

To test certain app standby bucket behavior, you can set the app standby bucket of your app using the following adb command:

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

To understand the app standby bucket your app is in, you can get the app standby bucket of your app using the following adb command:

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.

Wrażenia użytkowników i interfejs systemu

Android 16 (poziom interfejsu 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:

• W przypadku istotnych zmian w interfejsie, np. zmian w oknach, użyj Activity.setTitle(CharSequence) i setAccessibilityPaneTitle(java.lang.CharSequence). W sekcji Tworzenie wiadomości użyj skrótu Modifier.semantics { paneTitle = "paneTitle" }.
• Aby poinformować użytkownika o zmianach w kluczowych elementach interfejsu, użyj elementu setAccessibilityLiveRegion(int). W sekcji Utwórz kliknij Modifier.semantics { liveRegion = LiveRegionMode.[Polite|Assertive]} . Należy ich używać oszczędnie, ponieważ mogą generować powiadomienia za każdym razem, gdy nastąpi aktualizacja widoku.
• Aby powiadomić użytkowników o błędach, wyślij element AccessibilityEvent typu AccessibilityEvent#CONTENT_CHANGE_TYPE_ERROR i ustaw parametr AccessibilityNodeInfo#setError(CharSequence) lub użyj elementu TextView#setError(CharSequence).

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

Automatyczne ikony aplikacji z motywem

Od Androida 16 QPR2 Android automatycznie stosuje motywy do ikon aplikacji, aby zapewnić spójny wygląd ekranu głównego. Dzieje się tak, jeśli aplikacja nie ma własnej ikony z motywem. Aplikacje mogą kontrolować wygląd ikony tematycznej, dodając warstwę monochromatyczną do ikony adaptacyjnej i sprawdzając, jak będzie wyglądać ikona aplikacji w Android Studio.

Formaty urządzeń

Android 16 (poziom API 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.

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 zapewnia domyślne zabezpieczenia przed ogólnymi atakami polegającymi na IntentprzekierowaniuIntent, przy czym wymaga minimalnej zgodności i zmian ze strony deweloperów.

Wprowadzamy domyślne rozwiązania wzmacniające zabezpieczenia, które chronią przed wykorzystywaniem luk w zabezpieczeniach związanych z przekierowaniem Intent. W większości przypadków aplikacje korzystające z intencji nie będą miały problemów ze zgodnością. Podczas procesu tworzenia zbieraliśmy dane, aby monitorować, które aplikacje mogą ulec uszkodzeniu.

Przekierowanie intencji na Androidzie ma miejsce, gdy atakujący może częściowo lub całkowicie kontrolować zawartość intencji używanej do uruchamiania nowego komponentu w kontekście podatnej na ataki aplikacji, a aplikacja ofiary uruchamia niezaufaną intencję niższego poziomu w polu dodatkowym intencji („najwyższego poziomu”). Może to prowadzić do uruchamiania przez aplikację atakującą prywatnych komponentów w kontekście aplikacji ofiary, wywoływania działań z podwyższonymi uprawnieniami lub uzyskiwania dostępu do danych wrażliwych za pomocą identyfikatora URI, co może skutkować kradzieżą danych i wykonywaniem dowolnego kodu.

Rezygnacja z obsługi przekierowania intencji

Android 16 wprowadza nowy interfejs API, który umożliwia aplikacjom rezygnację z zabezpieczeń uruchamiania. Może to być konieczne w określonych przypadkach, gdy domyślne zachowanie związane z bezpieczeństwem zakłóca prawidłowe działanie aplikacji.

W przypadku aplikacji kompilowanych z użyciem pakietu SDK Androida 16 (poziom API 36) lub nowszego

Możesz bezpośrednio użyć metody removeLaunchSecurityProtection() na obiekcie Intent.

val i = intent
val iSublevel: Intent? = i.getParcelableExtra("sub_intent")
iSublevel?.removeLaunchSecurityProtection() // Opt out from hardening
iSublevel?.let { startActivity(it) }

W przypadku aplikacji kompilowanych pod kątem Androida 15 (API na poziomie 35) lub starszego

Chociaż nie jest to zalecane, możesz użyć odbicia, aby uzyskać dostęp do metody removeLaunchSecurityProtection().

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 Bluetooth, które poprawiają łączność z urządzeniami peryferyjnymi:

Ulepszona obsługa utraty połączenia

Od wersji 16 Androida zaktualizowano pakiet Bluetooth, aby zwiększyć bezpieczeństwo i wygodę użytkowników w przypadku wykrycia utraty połączenia z urządzeniem zdalnym. Wcześniej system automatycznie usuwał połączenie i inicjował nowy proces parowania, co mogło prowadzić do niezamierzonego ponownego parowania. W wielu przypadkach aplikacje nieprawidłowo obsługują zdarzenie utraty zabezpieczeń.

Aby ujednolicić obsługę, w Androidzie 16 ulepszono obsługę utraty zabezpieczeń. Jeśli po ponownym połączeniu nie uda się uwierzytelnić wcześniej sparowanego urządzenia Bluetooth, system rozłączy połączenie, zachowa lokalne informacje o sparowaniu i wyświetli okno systemu z informacją o utracie sparowania oraz instrukcją ponownego sparowania.