Zmiany zachowania: aplikacje kierowane na Androida 16 lub nowszego

Podobnie jak w przypadku poprzednich wersji Androida, w Androidzie 16 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 16 lub nowszego. Jeśli Twoja aplikacja jest kierowana na Androida 16 lub nowszego, zmodyfikuj ją, aby w odpowiednich przypadkach 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 16 niezależnie od aplikacji targetSdkVersion.

Wrażenia użytkowników i interfejs systemu

Android 16 (API na poziomie 36) zawiera te zmiany, które mają na celu zapewnienie bardziej spójnych i intuicyjnych wrażeń użytkownika.

Rezygnacja z wyświetlania od krawędzi do krawędzi

Android 15 wymusza wyświetlanie aplikacji od krawędzi do krawędzi w przypadku aplikacji kierowanych na Androida 15 (API na poziomie 35), ale możesz zrezygnować z tej funkcji, ustawiając R.attr#windowOptOutEdgeToEdgeEnforcement na true. W przypadku aplikacji kierowanych na Androida 16 (poziom API 36) interfejs R.attr#windowOptOutEdgeToEdgeEnforcement jest wycofany i wyłączony, a aplikacja nie może zrezygnować z wyświetlania bez ramki.

  • Jeśli Twoja aplikacja jest kierowana na Androida 16 (API na poziomie 36) i działa na urządzeniu z Androidem 15, funkcja R.attr#windowOptOutEdgeToEdgeEnforcement nadal działa.
  • Jeśli Twoja aplikacja jest kierowana na Androida 16 (API na poziomie 36) i działa na urządzeniu z Androidem 16, funkcja R.attr#windowOptOutEdgeToEdgeEnforcement jest wyłączona.

Jeśli testujesz aplikację na Androidzie 16, upewnij się, że obsługuje ona wyświetlanie od krawędzi do krawędzi, i usuń wszystkie wystąpienia R.attr#windowOptOutEdgeToEdgeEnforcement, aby aplikacja obsługiwała wyświetlanie od krawędzi do krawędzi również na urządzeniu z Androidem 15. Aby obsługiwać wyświetlanie od krawędzi do krawędzi, zapoznaj się z wytycznymi dotyczącymi kompozycji i widoków.

Wymagana migracja lub rezygnacja w przypadku przewidywanego przejścia wstecz

W przypadku aplikacji kierowanych na Androida 16 (API na poziomie 36) lub nowszego i działających na urządzeniu z Androidem 16 lub nowszym domyślnie włączone są animacje systemowe przewidywanego przejścia wstecz (powrót do ekranu głównego, przejście między zadaniami i przejście między aktywnościami). Dodatkowo nie jest wywoływana funkcja onBackPressed ani nie jest już wysyłany kod KeyEvent.KEYCODE_BACK.

Jeśli Twoja aplikacja przechwytuje zdarzenie przejścia wstecz i nie została jeszcze zmigrowana do przewidywanego przejścia wstecz, zaktualizuj ją, aby korzystała z obsługiwanych interfejsów API przechodzenia wstecz, lub tymczasowo zrezygnuj z tej funkcji, ustawiając android:enableOnBackInvokedCallback atrybut na false w <application> lub <activity> tagu w pliku AndroidManifest.xml aplikacji.

Animacja przewidywanego powrotu do ekranu głównego.
Animacja przewidywanego przejścia między aktywnościami.
Animacja przewidywanego przejścia między zadaniami.

Wycofanie i wyłączenie interfejsów API czcionek Elegant

Aplikacje kierowane na Androida 15 (API na poziomie 35) mają atrybut elegantTextHeight TextView domyślnie ustawiony na true, co powoduje zastąpienie czcionki kompaktowej czcionką znacznie bardziej czytelną. Możesz to zmienić, ustawiając atrybut elegantTextHeight na false.

Android 16 wycofuje atrybut elegantTextHeight. Gdy aplikacja będzie kierowana na Androida 16, atrybut ten będzie ignorowany. Interfejsy API kontrolujące „czcionki interfejsu” zostaną wycofane, więc musisz dostosować układy, aby zapewnić spójne i przyszłościowe renderowanie tekstu w językach arabskim, laotańskim, birmańskim, tamilskim, gudżarati, kannada, malajalam, odia, telugu i tajskim.

Zachowanie elegantTextHeight w przypadku aplikacji kierowanych na Androida 14 (API na poziomie 34) lub starszego albo aplikacji kierowanych na Androida 15 (API na poziomie 35), które zastąpiły domyślne ustawienie, ustawiając atrybut elegantTextHeight na false.
elegantTextHeight w przypadku aplikacji kierowanych na Androida 16 (API na poziomie 36) lub aplikacji kierowanych na Androida 15 (API na poziomie 35), które nie zastąpiły domyślnego ustawienia atrybutu elegantTextHeight wartością false.

Główna funkcjonalność

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

Optymalizacja planowania pracy ze stałą stawką

Przed kierowaniem na Androida 16, gdy scheduleAtFixedRate nie udało się wykonać zadania, ponieważ nie było ono dostępne w ramach prawidłowego cyklu życia procesu, wszystkie niewykonane zadania są natychmiast wykonywane, gdy aplikacja wraca do prawidłowego cyklu życia.

W przypadku kierowania na Androida 16 maksymalnie 1 niewykonany wcześniej element scheduleAtFixedRate jest natychmiast wykonywany, gdy aplikacja wraca do prawidłowego cyklu życia. Ta zmiana zachowania powinna poprawić działanie aplikacji. Przetestuj to zachowanie w aplikacji, aby sprawdzić, czy na nią wpływa. Możesz też przeprowadzić testy za pomocą ramy kompatybilności aplikacji i włączenia flagi zgodności STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS.

Formaty urządzeń

Android 16 (API na poziomie 36) zawiera te zmiany dotyczące aplikacji wyświetlanych na urządzeniach z dużym ekranem.

Układy adaptacyjne

现在，Android 应用可在各种设备（例如手机、平板电脑、可折叠设备、桌面设备、汽车和电视）上运行，并且在大屏设备上支持多种窗口模式（例如分屏和桌面窗口化模式），因此开发者应构建能够适应任何屏幕和窗口尺寸的 Android 应用，无论设备屏幕方向如何。在当今多设备的世界中，限制屏幕方向和尺寸可调整性等范式过于严格。

忽略屏幕方向、尺寸可调整性和宽高比限制

对于以 Android 16（API 级别 36）为目标平台的应用，在最小宽度 >= 600dp 的显示屏上，屏幕方向、尺寸调整能力和宽高比限制不再适用。应用会填满整个显示窗口，无论宽高比或用户偏好的屏幕方向如何，都不会使用竖屏黑边模式。

此变更引入了新的标准平台行为。Android 正在向一种模型转变，在该模型中，应用需要适应各种屏幕方向、显示大小和宽高比。固定屏幕方向或有限的尺寸调整等限制会阻碍应用的适应性。使应用具有自适应性，以提供尽可能最佳的用户体验。

您还可以使用应用兼容性框架并启用 UNIVERSAL_RESIZABLE_BY_DEFAULT 兼容性标志来测试此行为。

常见的重大更改

忽略屏幕方向、可调整大小性和宽高比限制可能会影响应用在某些设备上的界面，尤其是那些专为锁定为纵向的小布局设计的元素：例如，布局拉伸、动画和组件超出屏幕等问题。任何关于宽高比或屏幕方向的假设都可能导致应用出现视觉问题。详细了解如何避免这些问题并改进应用的自适应行为。

允许设备旋转会导致更多 activity 重新创建，如果未正确保留用户状态，可能会导致用户状态丢失。如需了解如何正确保存界面状态，请参阅保存界面状态。

实现细节

在全屏模式和多窗口模式下，以下清单属性和运行时 API 会被大屏设备忽略：

系统会忽略 screenOrientation、setRequestedOrientation() 和 getRequestedOrientation() 的以下值：

  • portrait
  • reversePortrait
  • sensorPortrait
  • userPortrait
  • landscape
  • reverseLandscape
  • sensorLandscape
  • userLandscape

对于显示屏可调整大小性，android:resizeableActivity="false"、android:minAspectRatio 和 android:maxAspectRatio 没有影响。

对于以 Android 16（API 级别 36）为目标平台的应用，默认情况下，大屏设备会忽略应用的屏幕方向、尺寸调整和宽高比限制。尚未完全准备就绪的每个应用都可以通过选择停用来暂时替换此行为，这会导致应用恢复到之前放置在兼容模式下的行为。

例外情况

在以下情况下，Android 16 的屏幕方向、尺寸调整能力和宽高比限制不适用：

  • 游戏（基于 android:appCategory 标志）
  • 用户在设备的宽高比设置中明确选择启用应用的默认行为
  • 小于 sw600dp 的屏幕

暂时选择不接收

如需选择停用特定 activity，请声明 PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY 清单属性：

<activity ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
  ...
</activity>

如果应用的很多部分尚未准备好支持 Android 16，您可以在应用级别应用相同的属性，从而完全选择不启用该功能：

<application ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
</application>

Zdrowie i fitness

Android 16 (API na poziomie 36) zawiera te zmiany związane z danymi o zdrowiu i aktywności fizycznej.

Uprawnienia dotyczące zdrowia i aktywności fizycznej

W przypadku aplikacji kierowanych na Androida 16 (API na poziomie 36) lub nowszego uprawnienia BODY_SENSORS korzystają z bardziej szczegółowych uprawnień android.permissions.health, które są też używane przez Health Connect. Od Androida 16 interfejsy API, które wcześniej wymagały uprawnień BODY_SENSORS lub BODY_SENSORS_BACKGROUND, wymagają teraz odpowiednich uprawnień android.permissions.health. Ma to wpływ na te typy danych, interfejsy API i rodzaje usług działających na pierwszym planie:

Jeśli Twoja aplikacja korzysta z tych interfejsów API, powinna prosić o odpowiednie szczegółowe uprawnienia:

Są one takie same jak uprawnienia, które chronią dostęp do odczytywania danych z Health Connect, czyli magazynu danych Androida dotyczących zdrowia, aktywności fizycznej i samopoczucia.

Aplikacje mobilne

Aplikacje mobilne, które przechodzą na korzystanie z READ_HEART_RATE i innych szczegółowych uprawnień, muszą też zadeklarować aktywność, aby wyświetlać politykę prywatności aplikacji. Jest to takie samo wymaganie jak w przypadku Health Connect.

Łączność

Android 16 (API na poziomie 36) zawiera te zmiany w stosie Bluetooth, które mają na celu poprawę łączności z urządzeniami peryferyjnymi.

Nowe intencje do obsługi utraty powiązania i zmian szyfrowania

W ramach ulepszonej obsługi utraty połączenia Android 16 wprowadza 2 nowe intencje, które zwiększają świadomość aplikacji na temat utraty połączenia i zmian szyfrowania.

Aplikacje kierowane na Androida 16 mogą teraz:

  • Otrzymywać intencję ACTION_KEY_MISSING, gdy wykryje utratę połączenia zdalnego, aby móc udzielić użytkownikowi bardziej szczegółowej odpowiedzi i podjąć odpowiednie działania.
  • Otrzymywać intencję ACTION_ENCRYPTION_CHANGE za każdym razem, gdy zmienia się stan szyfrowania linku. Obejmuje to zmianę stanu szyfrowania, zmianę algorytmu szyfrowania i zmianę rozmiaru klucza szyfrowania. Aplikacje muszą uznać, że połączenie zostało przywrócone, jeśli link zostanie zaszyfrowany po otrzymaniu intencji ACTION_ENCRYPTION_CHANGE.

Dostosowanie do różnych implementacji OEM

Chociaż Android 16 wprowadza te nowe intencje, ich implementacja i transmisja mogą się różnić w zależności od producenta urządzenia (OEM). Aby zapewnić spójne i niezawodne działanie aplikacji na wszystkich urządzeniach, deweloperzy powinni zaprojektować obsługę utraty zabezpieczeń w sposób umożliwiający dostosowanie się do tych potencjalnych różnic.

Zalecamy takie zachowanie aplikacji:

  • Jeśli intencja ACTION_KEY_MISSING jest nadawana:

    System rozłączy połączenie ACL (Asynchronous Connection-Less), ale informacje o połączeniu urządzenia zostaną zachowane (jak opisano tutaj).

    Aplikacja powinna używać tego zamiaru jako głównego sygnału do wykrywania utraty połączenia i prowadzenia użytkownika przez proces potwierdzania, że urządzenie zdalne znajduje się w zasięgu, zanim rozpocznie się zapominanie urządzenia lub ponowne parowanie.

    Jeśli urządzenie rozłączy się po otrzymaniu ACTION_KEY_MISSING, aplikacja powinna zachować ostrożność podczas ponownego nawiązywania połączenia, ponieważ urządzenie może nie być już połączone z systemem.

  • Jeśli intencja ACTION_KEY_MISSING NIE JEST transmitowana:

    Połączenie ACL pozostanie aktywne, a system usunie informacje o połączeniu urządzenia. To zachowanie jest takie samo jak w Androidzie 15.

    W takim przypadku aplikacja powinna nadal używać dotychczasowych mechanizmów obsługi utraty połączenia, tak jak w poprzednich wersjach Androida, aby wykrywać zdarzenia utraty połączenia i nimi zarządzać.

Nowy sposób usuwania powiązania Bluetooth

Wszystkie aplikacje kierowane na Androida 16 mogą teraz odłączać urządzenia Bluetooth za pomocą publicznego interfejsu API w CompanionDeviceManager. Jeśli urządzenie towarzyszące jest zarządzane jako powiązanie CDM, aplikacja może wywołać usunięcie połączenia Bluetooth, używając nowego interfejsu removeBond(int) na powiązanym urządzeniu. Aplikacja może monitorować zmiany stanu połączenia, nasłuchując zdarzenia przesyłania danych z urządzenia Bluetooth ACTION_BOND_STATE_CHANGED.

Bezpieczeństwo

Android 16 (API na poziomie 36) zawiera te zmiany dotyczące bezpieczeństwa.

Blokowanie wersji MediaStore

W przypadku aplikacji kierowanych na Androida 16 lub nowszego ciąg MediaStore#getVersion() będzie teraz niepowtarzalny dla każdej aplikacji. Pozwoli to wyeliminować z ciągu wersji właściwości identyfikujące, aby zapobiec nadużyciom i użyciu w ramach technik odciskania palca. Aplikacje nie powinny zakładać niczego w stosunku do formatu tej wersji. Aplikacje powinny już obsługiwać zmiany wersji podczas korzystania z tego interfejsu API i w większości przypadków nie trzeba zmieniać ich bieżącego działania, chyba że deweloper próbował wywnioskować dodatkowe informacje wykraczające poza zamierzony zakres tego interfejsu API.

Bezpieczniejsze intencje

Bezpieczniejsze intencje to wieloetapowa inicjatywa dotycząca bezpieczeństwa, która ma na celu zwiększenie bezpieczeństwa mechanizmu rozpoznawania intencji w Androidzie. Celem jest ochrona aplikacji przed złośliwymi działaniami przez dodanie kontroli podczas przetwarzania intencji i filtrowanie intencji, które nie spełniają określonych kryteriów.

W Androidzie 15 funkcja ta była skoncentrowana na aplikacji wysyłającej. W Androidzie 16 kontrola przechodzi na aplikację odbierającą, co umożliwia deweloperom włączenie ścisłego rozpoznawania intencji za pomocą manifestu aplikacji.

Wprowadzamy 2 kluczowe zmiany:

  1. Intencje bezpośrednie muszą pasować do filtra intencji komponentu docelowego: Jeśli intencja jest kierowana bezpośrednio na komponent, powinna pasować do filtra intencji tego komponentu.

  2. Intencje bez działania nie mogą pasować do żadnego filtra intencji: intencje, które nie mają określonego działania, nie powinny być rozwiązywane w żadnym filtrze intencji.

Te zmiany mają zastosowanie tylko wtedy, gdy w procesie uczestniczy kilka aplikacji, i nie wpływają na obsługę intencji w ramach jednej aplikacji.

Wpływ

Oznacza to, że deweloperzy muszą wyraźnie włączyć tę funkcję w pliku manifestu aplikacji, aby zaczęła działać. W związku z tym wpływ tej funkcji będzie ograniczony do aplikacji, których deweloperzy:

  • znają funkcję bezpieczniejszych intencji i jej zalety;
  • aktywne decydowanie o wdrażaniu w aplikacjach bardziej rygorystycznych praktyk obsługi intencji;

Takie podejście minimalizuje ryzyko uszkodzenia istniejących aplikacji, które mogą polegać na obecnym, mniej bezpiecznym sposobie rozpoznawania intencji.

Początkowy wpływ w Androidzie 16 może być ograniczony, ale inicjatywa Safer Intents ma plan działania, który pozwoli osiągnąć szerszy wpływ w przyszłych wersjach Androida. Planujemy, że w przyszłości ścisłe rozpoznawanie intencji będzie domyślnym działaniem.

Funkcja bezpieczniejszych intencji może znacznie zwiększyć bezpieczeństwo ekosystemu Androida, ponieważ utrudnia złośliwym aplikacjom wykorzystywanie luk w mechanizmie rozpoznawania intencji.

Przejście na rezygnację i obowiązkowe egzekwowanie musi być jednak starannie zarządzane, aby rozwiązać potencjalne problemy ze zgodnością z istniejącymi aplikacjami.

Implementacja

Deweloperzy muszą wyraźnie włączyć bardziej rygorystyczne dopasowywanie intencji za pomocą atrybutu intentMatchingFlags w pliku manifestu aplikacji. Oto przykład, w którym funkcja jest opcjonalna w całej aplikacji, ale wyłączona lub z niej zrezygnowano na odbiorniku:

<application android:intentMatchingFlags="enforceIntentFilter">
    <receiver android:name=".MyBroadcastReceiver" android:exported="true" android:intentMatchingFlags="none">
        <intent-filter>
            <action android:name="com.example.MY_CUSTOM_ACTION" />
        </intent-filter>
        <intent-filter>
            <action android:name="com.example.MY_ANOTHER_CUSTOM_ACTION" />
        </intent-filter>
    </receiver>
</application>

Więcej informacji o obsługiwanych flagach:

Nazwa flagi Opis
enforceIntentFilter Wymaga bardziej rygorystycznego dopasowywania przychodzących intencji
brak Wyłącza wszystkie specjalne reguły dopasowywania w przypadku przychodzących intencji. Jeśli podasz kilka flag, sprzeczne wartości zostaną rozwiązane przez nadanie priorytetu fladze „none”.
allowNullAction Zmienia reguły dopasowywania, aby umożliwić dopasowywanie intencji bez działania. Ta flaga jest używana w połączeniu z parametrem „enforceIntentFilter”, aby uzyskać określone zachowanie.

Testowanie i debugowanie

Gdy egzekwowanie jest aktywne, aplikacje powinny działać prawidłowo, jeśli wywołujący intencję prawidłowo ją wypełnił. Zablokowane intencje będą jednak wywoływać komunikaty ostrzegawcze w dzienniku, np. "Intent does not match component's intent filter:" i "Access blocked:", z tagiem "PackageManager."."Intent does not match component's intent filter:"Wskazuje to potencjalny problem, który może mieć wpływ na aplikację i wymaga uwagi.

Filtr Logcat:

tag=:PackageManager & (message:"Intent does not match component's intent filter:" | message: "Access blocked:")

Filtrowanie wywołań systemowych GPU

Aby zwiększyć bezpieczeństwo procesora graficznego Mali, w wersjach produkcyjnych zablokowaliśmy wycofane lub przeznaczone wyłącznie do programowania procesora graficznego Mali wywołania IOCTL. Dodatkowo IOCTL używane do profilowania GPU zostały ograniczone do procesu powłoki lub aplikacji, które można debugować. Więcej informacji o zasadach na poziomie platformy znajdziesz w aktualizacji SAC.

Zmiana ta dotyczy urządzeń Pixel z procesorem graficznym Mali (Pixel 6–9). Firma Arm udostępniła oficjalną klasyfikację swoich IOCTL w Documentation/ioctl-categories.rst wersji r54p2. Ta lista będzie aktualizowana w przyszłych wersjach sterowników.

Ta zmiana nie ma wpływu na obsługiwane interfejsy API grafiki (w tym Vulkan i OpenGL) i nie powinna mieć wpływu na deweloperów ani istniejące aplikacje. Nie wpłynie to na narzędzia do profilowania GPU, takie jak Streamline Performance Analyzer i Android GPU Inspector.

Testowanie

Jeśli widzisz odmowę SELinux podobną do tej poniżej, prawdopodobnie ta zmiana wpłynęła na Twoją aplikację:

06-30 10:47:18.617 20360 20360 W roidJUnitRunner: type=1400 audit(0.0:85): avc:  denied  { ioctl }
for  path="/dev/mali0" dev="tmpfs" ino=1188 ioctlcmd=0x8023
scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:gpu_device:s0 tclass=chr_file
permissive=0 app=com.google.android.selinux.pts

Jeśli Twoja aplikacja musi używać zablokowanych kodów IOCTL, zgłoś błąd i przypisz go do android-partner-security@google.com.

Najczęstsze pytania

  1. Czy ta zmiana zasad dotyczy wszystkich producentów OEM? Ta zmiana będzie opcjonalna, ale dostępna dla wszystkich producentów OEM, którzy chcą używać tej metody wzmacniania zabezpieczeń. Instrukcje wdrażania zmian znajdziesz w dokumentacji implementacji.

  2. Czy aby wdrożyć tę funkcję, trzeba wprowadzić zmiany w bazie kodu OEM, czy jest ona domyślnie dostępna w nowej wersji AOSP? Zmiana na poziomie platformy będzie domyślnie wprowadzana w nowej wersji AOSP. Jeśli dostawcy chcą zastosować tę zmianę, mogą ją wprowadzić w swojej bazie kodu.

  3. Czy zespoły ds. SoC odpowiadają za aktualizowanie listy IOCTL? Jeśli na przykład moje urządzenie korzysta z procesora graficznego ARM Mali, czy w przypadku jakichkolwiek zmian muszę kontaktować się z firmą ARM? Poszczególne systemy SoC muszą aktualizować listy IOCTL dla każdego urządzenia po wydaniu sterownika. Na przykład ARM zaktualizuje opublikowaną listę IOCTL po aktualizacji sterowników. Producenci OEM powinni jednak upewnić się, że uwzględnili aktualizacje w swojej polityce SEPolicy i w razie potrzeby dodali wybrane niestandardowe wywołania IOCTL do list.

  4. Czy ta zmiana zostanie automatycznie zastosowana na wszystkich dostępnych na rynku urządzeniach Pixel, czy też użytkownik musi coś przełączyć, aby ją zastosować? Ta zmiana dotyczy wszystkich dostępnych na rynku urządzeń Pixel z procesorem graficznym Mali (Pixel 6–9). Aby zastosować tę zmianę, użytkownik nie musi podejmować żadnych działań.

  5. Czy użycie tej zasady wpłynie na wydajność sterownika jądra? Zasady te zostały przetestowane na procesorze graficznym Mali za pomocą GFXBench i nie zaobserwowano żadnych mierzalnych zmian w wydajności procesora graficznego.

  6. Czy lista IOCTL musi być zgodna z bieżącymi wersjami przestrzeni użytkownika i sterownika jądra? Tak, lista dozwolonych kodów IOCTL musi być zsynchronizowana z kodami IOCTL obsługiwanymi przez sterowniki przestrzeni użytkownika i sterowniki jądra. Jeśli IOCTL w przestrzeni użytkownika lub sterowniku jądra zostaną zaktualizowane, lista IOCTL w SEPolicy musi zostać zaktualizowana, aby była zgodna z tymi zmianami.

  7. Firma ARM sklasyfikowała IOCTL jako „ograniczone” lub „instrumentacyjne”, ale chcemy używać niektórych z nich w przypadkach produkcyjnych lub odmawiać dostępu do innych. Poszczególni producenci OEM/SoC odpowiadają za decydowanie o sposobie kategoryzowania używanych przez nich IOCTL na podstawie konfiguracji bibliotek Mali w przestrzeni użytkownika. Lista ARM może pomóc w podjęciu decyzji, ale zastosowania każdego producenta OEM lub SoC mogą się różnić.

Prywatność

Android 16 (API na poziomie 36) zawiera te zmiany dotyczące prywatności.

Uprawnienia do sieci lokalnej

Urządzenia w sieci LAN są dostępne dla każdej aplikacji, która ma uprawnienie INTERNET. Ułatwia to aplikacjom łączenie się z urządzeniami lokalnymi, ale ma też wpływ na prywatność, np. tworzenie odcisków palców użytkownika i działanie jako serwer proxy lokalizacji.

Projekt Local Network Protections ma na celu ochronę prywatności użytkowników poprzez ograniczenie dostępu do sieci lokalnej za pomocą nowego uprawnienia w czasie działania.

Plan wydania

Ta zmiana zostanie wprowadzona w okresie między 25Q2 a 26Q2. Deweloperzy muszą postępować zgodnie z tymi wytycznymi w 25Q2 i przesyłać opinie, ponieważ te zabezpieczenia zostaną wprowadzone w późniejszej wersji Androida. Ponadto będą musieli zaktualizować scenariusze, które zależą od niejawnego dostępu do sieci lokalnej, korzystając z tych wskazówek, i przygotować się na odrzucenie lub wycofanie nowego uprawnienia przez użytkownika.

Wpływ

Na obecnym etapie LNP jest funkcją, którą można włączyć. Oznacza to, że będzie ona miała wpływ tylko na aplikacje, które ją włączą. Celem fazy wyrażania zgody jest umożliwienie deweloperom aplikacji sprawdzenia, które części ich aplikacji zależą od domyślnego dostępu do sieci lokalnej, aby mogli przygotować się do ochrony tych części w kolejnej wersji.

Aplikacje będą miały wpływ, jeśli uzyskują dostęp do sieci lokalnej użytkownika za pomocą:

  • Bezpośrednie lub biblioteczne użycie surowych gniazd na adresach sieci lokalnej (np. protokół wykrywania usług mDNS lub SSDP)
  • Używanie klas na poziomie platformy, które mają dostęp do sieci lokalnej (np. NsdManager)

Ruch do i z adresu sieci lokalnej wymaga uprawnień dostępu do sieci lokalnej. W tabeli poniżej znajdziesz kilka typowych przypadków:

Operacja sieciowa niskiego poziomu aplikacji Wymagany jest dostęp do sieci lokalnej
Nawiązywanie wychodzącego połączenia TCP tak
Akceptowanie przychodzących połączeń TCP tak
Wysyłanie transmisji pojedynczej, grupowej lub rozgłoszeniowej UDP tak
Odbieranie przychodzących pakietów UDP unicast, multicast i broadcast tak

Te ograniczenia są zaimplementowane głęboko w stosie sieciowym, dlatego dotyczą wszystkich interfejsów API sieci. Dotyczy to gniazd utworzonych w kodzie natywnym lub zarządzanym, bibliotek sieciowych takich jak Cronet i OkHttp oraz wszystkich interfejsów API zaimplementowanych na ich podstawie. Próba rozpoznania usług w sieci lokalnej (czyli tych z sufiksem .local) będzie wymagać uprawnień do sieci lokalnej.

Wyjątki od powyższych reguł:

  • Jeśli serwer DNS urządzenia znajduje się w sieci lokalnej, ruch do niego lub z niego (na porcie 53) nie wymaga uprawnień dostępu do sieci lokalnej.
  • Aplikacje korzystające z przełącznika wyjścia jako selektora w aplikacji nie będą potrzebować uprawnień do sieci lokalnej (więcej wskazówek pojawi się w IV kwartale 2025 r.).

Wskazówki dla programistów (włącz)

Aby włączyć ograniczenia dotyczące sieci lokalnej, wykonaj te czynności:

  1. Wgraj na urządzenie kompilację w wersji 25Q2 Beta 3 lub nowszej.
  2. Zainstaluj aplikację, która ma zostać przetestowana.

  3. Przełącz flagę zgodności aplikacji w adb:

    adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>

  4. Uruchom ponownie urządzenie

Dostęp aplikacji do sieci lokalnej jest teraz ograniczony, a każda próba uzyskania dostępu do sieci lokalnej spowoduje błędy gniazda. Jeśli używasz interfejsów API, które wykonują operacje w sieci lokalnej poza procesem aplikacji (np. NsdManager), nie będą one miały wpływu na fazę rezygnacji.

Aby przywrócić dostęp, musisz przyznać aplikacji uprawnienia do NEARBY_WIFI_DEVICES.

  1. Sprawdź, czy aplikacja deklaruje uprawnienie NEARBY_WIFI_DEVICES w pliku manifestu.
  2. Wybierz kolejno Ustawienia > Aplikacje > [Nazwa aplikacji] > Uprawnienia > Urządzenia w pobliżu > Zezwól.

Dostęp aplikacji do sieci lokalnej powinien zostać przywrócony, a wszystkie scenariusze powinny działać tak jak przed włączeniem aplikacji.

Gdy zaczniemy egzekwować ochronę sieci lokalnej, ruch w sieci aplikacji będzie wyglądać tak:

Uprawnienie Żądanie wychodzące z sieci LAN Żądanie internetowe wychodzące/przychodzące Żądanie przychodzące z sieci LAN
Przyznano Works Works Works
Nie przyznano Wpadki Works Wpadki

Aby wyłączyć flagę zgodności aplikacji, użyj tego polecenia:

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

Błędy

Błędy wynikające z tych ograniczeń będą zwracane do gniazda wywołującego za każdym razem, gdy wywoła ono funkcję send lub jej wariant w odniesieniu do lokalnego adresu sieciowego.

Przykłady błędów:

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

Definicja sieci lokalnej

Sieć lokalna w tym projekcie to sieć IP, która korzysta z interfejsu sieciowego obsługującego transmisję, takiego jak Wi-Fi lub Ethernet, ale nie obejmuje połączeń komórkowych (WWAN) ani VPN.

Za sieci lokalne uznaje się:

IPv4:

  • 169.254.0.0/16 // Połączenie lokalne
  • 100.64.0.0/10 // CGNAT
  • 10.0.0.0/8 // RFC1918
  • 172.16.0.0/12 // RFC1918
  • 192.168.0.0/16 // RFC1918

IPv6:

  • Połączenie lokalne
  • Trasy połączone bezpośrednio
  • Sieci typu stub, takie jak Thread
  • Wiele podsieci (do ustalenia)

Adresy multicast (224.0.0.0/4, ff00::/8) i adres rozgłoszeniowy IPv4 (255.255.255.255) są klasyfikowane jako adresy sieci lokalnej.

Zdjęcia należące do aplikacji

Gdy aplikacja kierowana na pakiet SDK 36 lub nowszy na urządzeniach z Androidem 16 lub nowszym poprosi o uprawnienia do zdjęć i filmów, użytkownicy, którzy zdecydują się na ograniczenie dostępu do wybranych multimediów, zobaczą wszystkie zdjęcia należące do aplikacji wstępnie wybrane w selektorze zdjęć. Użytkownicy mogą odznaczyć dowolne z tych wstępnie wybranych elementów, co spowoduje cofnięcie dostępu aplikacji do tych zdjęć i filmów.