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 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
JobInfo.Builder#setImportantWhileForeground(boolean) 方法用于在调度应用位于前台或暂时豁免于后台限制时指示作业的优先级。
自 Android 12（API 级别 31）起，此方法已废弃。从 Android 16 开始，它不再有效，系统会忽略调用此方法。
此功能移除也适用于 JobInfo#isImportantWhileForeground()。从 Android 16 开始，如果调用该方法，该方法会返回 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:
- 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.
- 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 wprowadził obsługę stron pamięci 16 KB w celu optymalizacji wydajności platformy. Android 16 wprowadza tryb zgodności, który umożliwia uruchamianie niektórych aplikacji utworzonych z użyciem stron pamięci 4 KB na urządzeniu skonfigurowanym pod kątem stron pamięci 16 KB.
Jeśli aplikacja działa na urządzeniu z Androidem 16 lub nowszym, a Android wykryje, że ma ona strony pamięci wyrównane co 4 KB, automatycznie włączy tryb zgodności i wyświetli użytkownikowi powiadomienie. Ustawienie właściwości android:pageSizeCompat w pliku AndroidManifest.xml, aby włączyć tryb zgodności wstecznej, uniemożliwi wyświetlanie okna podczas uruchamiania aplikacji. Aby użyć właściwości android:pageSizeCompat, skompiluj aplikację za pomocą pakietu SDK Androida 16.
Aby zapewnić najlepszą wydajność, niezawodność i stabilność, aplikacja powinna być nadal zgodna z 16 KB. Więcej informacji znajdziesz w tym poście na blogu na temat aktualizowania aplikacji, aby obsługiwały strony pamięci o rozmiarze 16 KB.
Interfejs użytkownika i systemu
Android 16 (poziom API 36) zawiera te zmiany, które mają na celu zapewnienie bardziej spójnego i intuicyjnego interfejsu.
Wycofywanie uciążliwych komunikatów ułatwień dostępu
Android 16 废弃了无障碍功能通告，其特征是使用 announceForAccessibility 或调度 TYPE_ANNOUNCEMENT 无障碍功能事件。这可能会给 TalkBack 和 Android 屏幕阅读器用户带来不一致的用户体验，而替代方案可以更好地满足各种 Android 辅助技术的用户需求。
替代方案示例：
- 对于窗口更改等重大界面更改，请使用
Activity.setTitle(CharSequence)和setAccessibilityPaneTitle(java.lang.CharSequence)。在 Compose 中，使用Modifier.semantics { paneTitle = "paneTitle" } - 如需向用户告知关键界面的更改，请使用
setAccessibilityLiveRegion(int)。在 Compose 中，请使用Modifier.semantics { liveRegion = LiveRegionMode.[Polite|Assertive]}。应谨慎使用这些事件，因为它们可能会在每次更新视图时生成通知。 - 如需向用户发送错误通知，请发送类型为
AccessibilityEvent#CONTENT_CHANGE_TYPE_ERROR的AccessibilityEvent并设置AccessibilityNodeInfo#setError(CharSequence)，或使用TextView#setError(CharSequence)。
已废弃的 announceForAccessibility API 的参考文档中包含有关建议替代方案的更多详细信息。
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 (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
Właścicielem urządzenia wirtualnego jest zaufana aplikacja z uprawnieniami, która tworzy urządzenie wirtualne i nim zarządza. Właściciele urządzeń wirtualnych uruchamiają aplikacje na urządzeniu wirtualnym, a następnie wyświetlają je na ekranie urządzenia zdalnego, takiego jak komputer osobisty, urządzenie do wirtualnej rzeczywistości lub system informacyjno-rozrywkowy w samochodzie. Właściciel urządzenia wirtualnego korzysta z urządzenia lokalnego, np. telefonu komórkowego.
Zastąpienia na poziomie aplikacji
Na urządzeniach z Androidem 16 (poziom interfejsu API 36) właściciele urządzeń wirtualnych mogą zastępować ustawienia aplikacji na wybranych urządzeniach wirtualnych, którymi zarządzają. Aby na przykład ulepszyć układ aplikacji, właściciel urządzenia wirtualnego może ignorować ograniczenia dotyczące orientacji, proporcji i możliwości zmiany rozmiaru podczas wyświetlania aplikacji na zewnętrznym ekranie.
Typowe zmiany powodujące niezgodność
Zachowanie Androida 16 może mieć wpływ na interfejs aplikacji na urządzeniach z dużym ekranem, takich jak wyświetlacze samochodowe czy Chromebooki, zwłaszcza w przypadku układów zaprojektowanych z myślą o małych ekranach w orientacji pionowej. Aby dowiedzieć się, jak dostosować aplikację do wszystkich typów urządzeń, przeczytaj artykuł Informacje o układach adaptacyjnych.
Pliki referencyjne
Strumieniowe przesyłanie aplikacji towarzyszącej
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.
Lepsze zabezpieczenia przed atakami polegającymi na przekierowaniu intencji
Android 16 提供了针对一般 Intent 重定向攻击的默认安全性，并且只需进行最低限度的兼容性和开发者更改。
我们正在推出默认安全强化解决方案，以应对重定向漏洞。Intent在大多数情况下，使用 intent 的应用通常不会遇到任何兼容性问题；我们在整个开发过程中收集了指标，以监控哪些应用可能会出现中断。
当攻击者可以部分或完全控制用于在存在漏洞的应用上下文中启动新组件的 intent 内容时，Android 中就会出现 intent 重定向问题，而受害应用会在（“顶级”）Intent 的 extras 字段中启动不可信的子级 intent。这可能会导致攻击者应用在受害者应用的上下文中启动私有组件、触发特权操作或获得对敏感数据的 URI 访问权限，从而可能导致数据盗窃和任意代码执行。
选择停用 intent 重定向处理
Android 16 引入了一项新 API，允许应用选择停用启动安全保护功能。在默认安全行为会干扰正当应用用例的特定情况下，这可能是必要的。
对于针对 Android 16（API 级别 36）SDK 或更高版本进行编译的应用
您可以直接对 Intent 对象使用 removeLaunchSecurityProtection() 方法。
val i = intent
val iSublevel: Intent? = i.getParcelableExtra("sub_intent")
iSublevel?.removeLaunchSecurityProtection() // Opt out from hardening
iSublevel?.let { startActivity(it) }
对于针对 Android 15（API 级别 35）或更低版本进行编译的应用
虽然不建议这样做，但您可以使用反射来访问 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.