Zmiany zachowania: aplikacje kierowane na Androida 16 lub nowszego

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

Zapoznaj się też z listą zmian w zachowaniu, które mają wpływ na wszystkie aplikacje działające na Androidzie 16, niezależnie od targetSdkVersion aplikacji.

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.

Wyłączenie wyświetlania bez ramki

Android 15 强制执行全屏显示，但您的应用可以通过将 R.attr#windowOptOutEdgeToEdgeEnforcement 设置为 true 来选择停用此功能。对于以 Android 16（API 级别 36）为目标平台的应用，R.attr#windowOptOutEdgeToEdgeEnforcement 已被废弃并停用，并且您的应用无法选择不采用从边缘到边缘的布局。

• 如果您的应用以 Android 16（API 级别 36）为目标平台，并且在 Android 15 设备上运行，则 R.attr#windowOptOutEdgeToEdgeEnforcement 会继续正常运行。
• 如果您的应用以 Android 16（API 级别 36）为目标平台，并且在 Android 16 设备上运行，则 R.attr#windowOptOutEdgeToEdgeEnforcement 会被停用。

如需在 Android 16 中进行测试，请确保您的应用支持无边框设计，并移除所有 R.attr#windowOptOutEdgeToEdgeEnforcement 用法，以便您的应用在 Android 15 设备上也能支持无边框设计。如需支持从边缘到边缘的显示，请参阅 Compose 和 Views 指南。

Wymagana migracja lub rezygnacja z przewidywanego powrotu

对于以 Android 16（API 级别 36）或更高版本为目标平台且在搭载 Android 16 或更高版本的设备上运行的应用，预测性返回系统动画（返回主屏幕、跨任务和跨 activity）默认处于启用状态。此外，系统不再调用 onBackPressed，也不再调度 KeyEvent.KEYCODE_BACK。

如果您的应用会拦截返回事件，但您尚未迁移到预测性返回，请更新应用以使用受支持的返回导航 API，或者通过在应用的 AndroidManifest.xml 文件的 <application> 或 <activity> 标记中将 android:enableOnBackInvokedCallback 属性设置为 false 来暂时选择停用。

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

以 Android 15（API 级别 35）为目标平台的应用默认将 elegantTextHeight TextView 属性设置为 true，从而将紧凑型字体替换为可读性更高的字体。您可以通过将 elegantTextHeight 属性设置为 false 来替换此设置。

Android 16 弃用了 elegantTextHeight 属性，当您的应用以 Android 16 为目标平台后，系统会忽略该属性。由这些 API 控制的“界面字体”即将停用，因此您应调整所有布局，以确保阿拉伯语、老挝语、缅甸语、泰米尔语、古吉拉特语、卡纳达语、马拉雅拉姆语、奥里亚语、泰卢固语或泰语文本的呈现效果一致且不受未来变化的影响。

针对以 Android 14（API 级别 34）及更低版本为目标平台的应用，或针对以 Android 15（API 级别 35）为目标平台且通过将 elegantTextHeight 属性设置为 false 替换默认值的应用，

以 Android 16（API 级别 36）为目标平台的应用，或以 Android 15（API 级别 35）为目标平台但未通过将 elegantTextHeight 属性设置为 false 来替换默认值的应用，其

Główna funkcja

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

Optymalizacja harmonogramu pracy przy stałej stawce

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 (poziom interfejsu API 36) wprowadza te zmiany w aplikacjach wyświetlanych na urządzeniach z dużym ekranem:

Układy adaptacyjne

Aplikacje na Androida działają teraz na różnych urządzeniach (np. telefonach, tabletach, urządzeniach składanych, komputerach, samochodach i telewizorach) oraz w różnych trybach okien na dużych ekranach (np. w trybie podzielonego ekranu i okien na komputerze). Deweloperzy powinni tworzyć aplikacje na Androida, które dostosowują się do dowolnego rozmiaru ekranu i okna, niezależnie od orientacji urządzenia. Paradygmaty takie jak ograniczenie orientacji i możliwości zmiany rozmiaru są zbyt restrykcyjne w dzisiejszym świecie wielu urządzeń.

Ignorowanie ograniczeń dotyczących orientacji, zmiany rozmiaru i współczynnika proporcji

W przypadku aplikacji kierowanych na Androida 16 (API na poziomie 36) ta wersja zawiera zmiany w sposobie zarządzania przez system ograniczeniami dotyczącymi orientacji, możliwości zmiany rozmiaru i formatu obrazu. Na wyświetlaczach o najmniejszej szerokości ≥ 600 dp ograniczenia nie obowiązują. Aplikacje wypełniają też całe okno wyświetlania niezależnie od współczynnika proporcji czy preferowanej orientacji użytkownika, a w tym przypadku nie stosuje się pillarboxingu.

Ta zmiana wprowadza nowe standardowe działanie platformy. Android zmierza w kierunku modelu, w którym aplikacje powinny dostosowywać się do różnych orientacji, rozmiarów wyświetlacza i proporcji. Ograniczenia takie jak stała orientacja lub ograniczona możliwość zmiany rozmiaru utrudniają dostosowanie aplikacji, dlatego zalecamy dostosowanie aplikacji, aby zapewnić użytkownikom jak najlepsze wrażenia.

Możesz też przetestować to zachowanie, korzystając z platformy zgodności aplikacji i włączając flagę zgodności UNIVERSAL_RESIZABLE_BY_DEFAULT.

Typowe zmiany powodujące niezgodność

Ignorowanie ograniczeń dotyczących orientacji, zmiany rozmiaru i proporcji może mieć wpływ na interfejs aplikacji na niektórych urządzeniach, zwłaszcza na elementy zaprojektowane z myślą o małych układach zablokowanych w orientacji pionowej. Może to powodować problemy takie jak rozciągnięte układy oraz animacje i komponenty poza ekranem. Wszelkie założenia dotyczące proporcji lub orientacji mogą powodować problemy wizualne w aplikacji. Dowiedz się więcej o tym, jak ich unikać i poprawić adaptacyjne działanie aplikacji.

Zezwolenie na obracanie urządzenia powoduje częstsze ponowne tworzenie aktywności, co może prowadzić do utraty stanu użytkownika, jeśli nie zostanie on prawidłowo zachowany. Dowiedz się, jak prawidłowo zapisywać stan interfejsu w sekcji Zapisywanie stanów interfejsu.

Szczegóły implementacji

Na urządzeniach z dużym ekranem w trybie pełnoekranowym i wielookienkowym ignorowane są te atrybuty manifestu i interfejsy API środowiska wykonawczego:

• screenOrientation
• resizableActivity
• minAspectRatio
• maxAspectRatio
• setRequestedOrientation()
• getRequestedOrientation()

Te wartości w przypadku screenOrientation, setRequestedOrientation() i getRequestedOrientation() są ignorowane:

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

W przypadku zmiany rozmiaru wyświetlacza elementy android:resizeableActivity="false", android:minAspectRatio i android:maxAspectRatio nie mają wpływu.

W przypadku aplikacji kierowanych na Androida 16 (poziom API 36) ograniczenia dotyczące orientacji, możliwości zmiany rozmiaru i formatu obrazu są domyślnie ignorowane na dużych ekranach, ale każda aplikacja, która nie jest w pełni gotowa, może tymczasowo zastąpić to zachowanie, rezygnując z tej funkcji (co spowoduje powrót do poprzedniego zachowania, czyli umieszczenia w trybie zgodności).

Wyjątki

Ograniczenia dotyczące orientacji, zmiany rozmiaru i proporcji w Androidzie 16 nie obowiązują w tych sytuacjach:

• Gry (na podstawie flagi android:appCategory)
• użytkownicy, którzy wyraźnie zgodzili się na domyślne działanie aplikacji w ustawieniach proporcji obrazu na urządzeniu;
• ekrany mniejsze niż sw600dp,

Tymczasowa rezygnacja

Aby zrezygnować z określonej aktywności, zadeklaruj właściwość manifestu:PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY

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

Jeśli zbyt wiele części aplikacji nie jest gotowych na Androida 16, możesz całkowicie zrezygnować z tej funkcji, stosując tę samą właściwość na poziomie aplikacji:

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

Zdrowie i fitness

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

Uprawnienia dotyczące zdrowia i aktywności fizycznej

对于以 Android 16（API 级别 36）或更高版本为目标平台的应用，BODY_SENSORS 权限使用 android.permissions.health 下更精细的权限，健康数据共享也使用这些权限。自 Android 16 起，凡是以前需要具有 BODY_SENSORS 或 BODY_SENSORS_BACKGROUND 权限的 API，现在都需要获取相应的 android.permissions.health 权限。这会影响以下数据类型、API 和前台服务类型：

• 从 Wear OS 上的健康服务中获取 HEART_RATE_BPM
• 来自 Android Sensor Manager 的 Sensor.TYPE_HEART_RATE
• 在 Wear OS 上，ProtoLayout 中的 heartRateAccuracy 和 heartRateBpm
• FOREGROUND_SERVICE_TYPE_HEALTH，其中需要使用相应的 android.permission.health 权限来代替 BODY_SENSORS

如果您的应用使用这些 API，则应请求相应的精细权限：

• 对于使用期间的心率、血氧饱和度或体表温度监测：请求 android.permissions.health 下的精细权限，例如 READ_HEART_RATE，而不是 BODY_SENSORS。
• 对于后台传感器访问权限：请求 READ_HEALTH_DATA_IN_BACKGROUND 而不是 BODY_SENSORS_BACKGROUND。

这些权限与用于保护对 Health Connect（Android 健康、健身和身心状态数据存储区）中读取数据的访问权限相同。

移动应用

迁移到使用 READ_HEART_RATE 和其他精细权限的移动应用还必须声明 activity 以显示应用的隐私权政策。此要求与健康数据共享的要求相同。

Łączność

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

Nowe intencje do obsługi utraty połączenia 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 połączenia 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 (poziom API 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

Funkcja Safer Intents 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, a w Androidzie 16 przenosi kontrolę na aplikację odbierającą, co pozwala programistom włączyć ścisłe rozpoznawanie 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 w przypadku wielu aplikacji i nie wpływają na obsługę intencji w ramach jednej aplikacji.

Wpływ

Oznacza to, że deweloperzy muszą jawnie 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 wdrażanie 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 na szersze zastosowanie w przyszłych wersjach Androida. Planujemy, że w przyszłości ścisłe rozpoznawanie intencji stanie się domyślnym zachowaniem.

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 przypadku całej aplikacji, ale wyłączona lub opcjonalna w przypadku odbiornika:

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

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

为了加固 Mali GPU 表面，在生产 build 中，已废弃或仅用于 GPU 开发的 Mali GPU IOCTL 已被屏蔽。此外，用于 GPU 性能分析的 IOCTL 已限制为 shell 进程或可调试的应用。如需详细了解平台级政策，请参阅 SAC 更新。

此更改适用于使用 Mali GPU 的 Pixel 设备（Pixel 6-9）。Arm 已在其 r54p2 版本的 Documentation/ioctl-categories.rst 中提供了 IOCTL 的官方分类。此列表将在未来的驱动程序版本中继续维护。

此项变更不会影响受支持的图形 API（包括 Vulkan 和 OpenGL），预计也不会影响开发者或现有应用。 Streamline Performance Analyzer 和 Android GPU 检查器等 GPU 性能剖析工具不会受到影响。

测试

如果您看到类似如下所示的 SELinux 拒绝，则说明您的应用可能受到了此变更的影响：

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

如果您的应用需要使用被屏蔽的 IOCTL，请提交 bug 并将其分配给 android-partner-security@google.com。

常见问题解答

1. 此政策变更是否适用于所有原始设备制造商 (OEM)？ 此变更将采用选择启用模式，但任何想要使用此强化方法的 OEM 都可以使用。如需了解如何实现此变更，请参阅实现文档。

2. 是否必须在 OEM 代码库中进行更改才能实现此功能，还是默认随新的 AOSP 版本提供？ 平台级变更将默认随新的 AOSP 版本一起发布。如果供应商想要应用此变更，可以在其代码库中选择启用此变更。

3. SoC 是否负责使 IOCTL 列表保持最新状态？例如，如果我的设备使用 ARM Mali GPU，我是否需要就任何更改与 ARM 联系？ 各个 SoC 必须在驱动程序发布后根据设备更新其 IOCTL 列表。 例如，ARM 会在驱动程序更新时更新其已发布的 IOCTL 列表。 不过，OEM 应确保在 SEPolicy 中纳入这些更新，并根据需要将任何选定的自定义 IOCTL 添加到列表中。

4. 此变更是否会自动应用于所有在售 Pixel 设备，还是需要用户执行操作来切换某些设置才能应用此变更？ 此变更适用于所有使用 Mali GPU 的 Pixel 在售设备（Pixel 6-9）。用户无需采取任何行动即可应用此变更。

5. 使用此政策会影响内核驱动程序的性能吗？ 我们使用 GFXBench 在 Mali GPU 上测试了此政策，未发现 GPU 性能有任何可衡量的变化。

6. IOCTL 列表是否需要与当前的用户空间和内核驱动程序版本保持一致？ 是的，允许的 IOCTL 列表必须与用户空间和内核驱动程序支持的 IOCTL 同步。如果用户空间或内核驱动程序中的 IOCTL 发生更新，则必须更新 SEPolicy IOCTL 列表以保持一致。

7. ARM 已将 IOCTL 分类为“受限”/“检测”，但我们希望在生产用例中使用其中一些 IOCTL，并拒绝其他 IOCTL。 各个 OEM/SoC 负责根据其用户空间 Mali 库的配置来决定如何对其使用的 IOCTL 进行分类。ARM 的列表可用于帮助确定这些值，但每个 OEM/SoC 的使用情形可能有所不同。

Prywatność

Android 16 (poziom API 36) wprowadza następujące zmiany dotyczące prywatności.

Zezwolenie na dostęp 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 odcisku cyfrowego użytkownika i pełnienie funkcji serwera proxy dla 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 środowiska wykonawczego.

Plan wydania

Ta zmiana zostanie wprowadzona w 2 wersjach: 25Q2 i 26Q2. Deweloperzy muszą postępować zgodnie z tymi wytycznymi w II kwartale 2025 r. i przesyłać opinie, ponieważ te zabezpieczenia zostaną wprowadzone w późniejszej wersji Androida. Ponadto będą musieli zaktualizować scenariusze, które zależą od domyślnego dostępu do sieci lokalnej, korzystając z tych wskazówek, i przygotować się na odrzucenie przez użytkownika nowych uprawnień lub ich cofnięcie.

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 na 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 zgody na dostęp do sieci lokalnej. W tabeli poniżej znajdziesz kilka typowych przypadków:

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, które używają 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ę wyrażania zgody.

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. Otwórz 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 sieciowy aplikacji będzie wyglądać tak:

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, gdy tylko wywoła ono funkcję send lub jej wariant w odniesieniu do lokalnego adresu sieciowego.

Przykładowe błędy:

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 // Link Local
• 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:

• Link-local
• Trasy połączone bezpośrednio
• sieci typu stub, takie jak Thread,
• Wiele podsieci (do ustalenia)

Adresy multiemisji (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

当面向 SDK 36 或更高版本的应用在搭载 Android 16 或更高版本的设备上提示用户授予照片和视频权限时，如果用户选择限制对所选媒体的访问权限，则会在照片选择器中看到该应用拥有的所有照片。用户可以取消选择任何这些预选项，这会撤消该应用对这些照片和视频的访问权限。