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 targetSdkVersion aplikacji.

Interfejs użytkownika i systemowy

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

Wycofanie opcji rezygnacji z wyświetlania od krawędzi do krawędzi

Android 15 强制要求以 Android 15（API 级别 35）为目标平台的应用采用边到边模式，但您的应用可以通过将 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 和视图指南。

W przypadku przewidywanego przejścia wstecz wymagana jest migracja lub rezygnacja

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

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

预测性返回主屏幕动画。

预测性跨 activity 动画。

预测性跨任务动画。

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

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 funkcja

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

Optymalizacja harmonogramu 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 (poziom 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 (takich jak telefony, tablety, urządzenia składane, komputery, samochody i telewizory) oraz w trybach okien na dużych ekranach (takich jak podzielony ekran i tryb okien na pulpicie). Deweloperzy powinni więc tworzyć aplikacje na Androida, które dostosowują się do każdego rozmiaru ekranu i okna, niezależnie od orientacji urządzenia. Paradygmaty takie jak ograniczanie orientacji i możliwości zmiany rozmiaru są zbyt restrykcyjne w dzisiejszym świecie wielu urządzeń.

Ignorowanie ograniczeń dotyczących orientacji, możliwości zmiany rozmiaru i formatu obrazu

W przypadku aplikacji kierowanych na Androida 16 (poziom API 36) ograniczenia dotyczące orientacji, możliwości zmiany rozmiaru i formatu obrazu nie obowiązują już na wyświetlaczach o najmniejszej szerokości >= 600 dp. Aplikacje wypełniają całe okno wyświetlania, niezależnie od formatu obrazu lub preferowanej przez użytkownika orientacji, i nie są stosowane czarne pasy po bokach.

Ta zmiana wprowadza nowe standardowe działanie platformy. Android przechodzi na model, w którym aplikacje mają dostosowywać się do różnych orientacji, rozmiarów wyświetlacza i formatów obrazu. Ograniczenia takie jak stała orientacja czy ograniczona możliwość zmiany rozmiaru utrudniają dostosowywanie aplikacji. Dostosuj aplikację, aby zapewnić użytkownikom jak najlepsze wrażenia.

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

Typowe zmiany powodujące niezgodność

Ignorowanie ograniczeń dotyczących orientacji, możliwości zmiany rozmiaru i formatu obrazu może mieć wpływ na interfejs aplikacji na niektórych urządzeniach, zwłaszcza na elementy, które zostały zaprojektowane dla małych układów 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 formatu obrazu lub orientacji mogą powodować problemy z wyświetlaniem aplikacji. Dowiedz się więcej o tym, jak ich unikać i poprawić działanie aplikacji na różnych urządzeniach.

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

Szczegóły implementacji

Następujące atrybuty manifestu i interfejsy API środowiska wykonawczego są ignorowane na urządzeniach z dużym ekranem w trybach pełnoekranowym i wielu okien:

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

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

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

Jeśli chodzi o możliwość zmiany rozmiaru wyświetlacza, android:resizeableActivity="false", android:minAspectRatio i android:maxAspectRatio nie mają wpływu.

W przypadku aplikacji kierowanych na Androida 16 (API na poziomie 36) ograniczenia dotyczące orientacji, możliwości zmiany rozmiaru i formatu obrazu są domyślnie ignorowane na dużych ekranach. Każda aplikacja, która nie jest w pełni gotowa, może tymczasowo zastąpić to zachowanie, rezygnując z niego, co spowoduje, że będzie działać w trybie zgodności.

Wyjątki

Ograniczenia dotyczące orientacji, możliwości zmiany rozmiaru i formatu obrazu w Androidzie 16 nie obowiązują w tych sytuacjach:

• Gry (na podstawie flagi android:appCategory)
• użytkownicy wyraźnie akceptują działanie domyślne aplikacji w ustawieniach formatu 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>

Ważne: rezygnacja jest tymczasowa i nie będzie obowiązywać, gdy w przyszłej wersji Androida poziom interfejsu API będzie wynosić 37. Oznacza to, że w przypadku aplikacji kierowanych na interfejs API na poziomie 37 ograniczenia dotyczące orientacji, możliwości zmiany rozmiaru i formatu obrazu są ignorowane na wyświetlaczach o rozmiarze co najmniej sw600dp.

Zdrowie i fitness

Android 16 (poziom API 36) zawiera te zmiany dotyczące danych 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ń w ramach android.permissions.health, których używa też 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:

• HEART_RATE_BPM z funkcji dotyczących zdrowia na Wear OS
• Sensor.TYPE_HEART_RATE z Menedżera czujników Androida
• heartRateAccuracy i heartRateBpm od ProtoLayout na Wear OS
• FOREGROUND_SERVICE_TYPE_HEALTH, gdzie zamiast uprawnienia BODY_SENSORS wymagane jest uprawnienie android.permission.health.

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

• W przypadku monitorowania tętna, SpO2 lub temperatury skóry podczas używania: poproś o szczegółowe uprawnienia w ramach android.permissions.health, np. READ_HEART_RATE zamiast BODY_SENSORS.
• W przypadku dostępu do czujników w tle: poproś o READ_HEALTH_DATA_IN_BACKGROUND zamiast BODY_SENSORS_BACKGROUND.

Są to te same uprawnienia, które chronią dostęp do odczytu danych z Health Connect, magazynu danych na Androidzie, w którym przechowywane są dane o zdrowiu, aktywności fizycznej i samopoczuciu.

Aplikacje mobilne

Aplikacje mobilne, które przechodzą na uprawnienie READ_HEART_RATE i inne uprawnienia szczegółowe, muszą też zadeklarować aktywność, aby wyświetlać politykę prywatności aplikacji. To samo wymaganie dotyczy Health Connect.

Ważne: brak uzasadnienia w przypadku aplikacji mobilnych spowoduje odebranie uprawnień.

Połączenia

Android 16 (poziom API 36) wprowadza te zmiany w stosie Bluetooth, aby poprawić łączność z urządzeniami peryferyjnymi.

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

作为改进了对键值对丢失的处理的一部分，Android 16 还引入了 2 个新 intent，以便应用更好地了解键值对丢失和加密更改。

以 Android 16 为目标平台的应用现在可以：

• 在检测到远程键盘连接丢失时接收 ACTION_KEY_MISSING intent，以便提供更具信息量的用户反馈并采取适当的措施。
• 每当链接的加密状态发生变化时，都会收到 ACTION_ENCRYPTION_CHANGE intent。这包括加密状态更改、加密算法更改和加密密钥大小更改。如果应用在稍后收到 ACTION_ENCRYPTION_CHANGE intent 时成功加密了链接，则必须将该绑定视为已恢复。

适应不同的 OEM 实现

虽然 Android 16 引入了这些新 intent，但其实现和广播可能会因不同的设备制造商 (OEM) 而异。为了确保您的应用在所有设备上都能提供一致且可靠的体验，开发者应设计其绑定丢失处理机制，以妥善适应这些潜在的变化。

我们建议您采用以下应用行为：

• 如果广播 ACTION_KEY_MISSING intent：

  系统会断开 ACL（异步无连接）链接，但会保留设备的配对信息（如此处所述）。

  您的应用应将此 intent 用作检测配对丢失的主要信号，并在发起设备忘记或重新配对之前引导用户确认远程设备是否在范围内。

  如果设备在收到 ACTION_KEY_MISSING 后断开连接，您的应用应谨慎重新连接，因为设备可能已不再与系统绑定。

• 如果未广播 ACTION_KEY_MISSING intent：

  ACL 链接将保持连接状态，系统会移除设备的配对信息，与 Android 15 中的行为相同。

  在这种情况下，您的应用应继续使用与之前的 Android 版本相同的现有配对丢失处理机制，以检测和管理配对丢失事件。

Nowy sposób usuwania połączenia Bluetooth

现在，以 Android 16 为目标平台的所有应用都可以使用 CompanionDeviceManager 中的公共 API 解除蓝牙设备配对。如果配套设备作为 CDM 关联进行管理，则应用可以在关联的设备上使用新的 removeBond(int) API 触发蓝牙配对的移除。该应用可以通过监听蓝牙设备广播事件 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 bezpieczniejszych intencji to wieloetapowa inicjatywa, której celem jest zwiększenie bezpieczeństwa mechanizmu rozpoznawania intencji na Androidzie. Celem jest ochrona aplikacji przed szkodliwymi działaniami przez dodanie kontroli podczas przetwarzania intencji i filtrowanie intencji, które nie spełniają określonych kryteriów.

W Androidzie 15 ta funkcja skupiała się na aplikacji wysyłającej. Teraz, w Androidzie 16, kontrola przechodzi na aplikację odbierającą, co pozwala deweloperom na 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ć dopasowywane do żadnego filtra intencji.

Te zmiany dotyczą tylko sytuacji, gdy używanych jest kilka aplikacji, i nie mają wpływu na obsługę intencji w ramach jednej aplikacji.

Wpływ

Charakter akceptacji oznacza, ż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;
• świadomie zdecydować się na stosowanie w swoich aplikacjach bardziej rygorystycznych praktyk dotyczących obsługi intencji.

Takie podejście oparte na akceptacji minimalizuje ryzyko uszkodzenia istniejących aplikacji, które mogą polegać na obecnym, mniej bezpiecznym zachowaniu związanym z rozpoznawaniem intencji.

Chociaż początkowy wpływ na Androida 16 może być ograniczony, inicjatywa Bezpieczniejsze intencje ma plan działania, który ma na celu zwiększenie wpływu w przyszłych wersjach Androida. Planujemy, aby ścisłe rozpoznawanie intencji stało się działaniem domyślnym.

Funkcja bezpieczniejszych intencji może znacznie zwiększyć bezpieczeństwo ekosystemu Androida, utrudniając szkodliwym aplikacjom wykorzystywanie luk w zabezpieczeniach mechanizmu rozpoznawania intencji.

Jednak przejście na model rezygnacji i obowiązkowe egzekwowanie musi być dokładnie 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 włączona w całej aplikacji, ale wyłączona w 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>

Uwaga: atrybut można określić w tagu <application>, a także w tagach komponentów, takich jak <activity>, <activity-alias>, <receiver>, <service>, <provider>. Atrybut w komponencie może służyć do zastąpienia atrybutu w tagu <application>.

Więcej informacji o obsługiwanych flagach:

Nazwa flagi	Opis
enforceIntentFilter	Wymusza bardziej rygorystyczne dopasowywanie przychodzących intencji
brak	Wyłącza wszystkie specjalne reguły dopasowywania dla przychodzących intencji. Jeśli określisz kilka flag, sprzeczne wartości zostaną rozwiązane przez nadanie pierwszeństwa fladze „none”
allowNullAction	Zmniejsza rygorystyczność reguł dopasowywania, aby umożliwić dopasowywanie intencji bez działania. Ta flaga ma być używana w połączeniu z „enforceIntentFilter”, aby uzyskać określone działanie

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 logu z ostrzeżeniami, takie jak "Intent does not match component's intent filter:" i "Access blocked:" z tagiem "PackageManager.". Wskazuje to na 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 表面，已废弃或仅用于 GPU 开发的 Mali GPU IOCTL 已在正式版 build 中被屏蔽。此外，用于 GPU 性能分析的 IOCTL 已限制为 shell 进程或可调试应用。如需详细了解平台级政策，请参阅 SAC 更新。

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

此项变更不会影响受支持的图形 API（包括 Vulkan 和 OpenGL），预计也不会影响开发者或现有应用。 GPU 性能分析工具（例如 Streamline Performance Analyzer 和 Android 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 并将其分配给 [e-mail]。

常见问题解答

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. 使用此政策是否会影响内核驱动程序的性能？ 此政策已在 Mali GPU 上使用 GFXBench 进行了测试，未观察到 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) zawiera te zmiany dotyczące prywatności.

Uprawnienia do sieci lokalnej

Dostęp do urządzeń w sieci LAN może uzyskać każda aplikacja, która ma uprawnienie INTERNET. Ułatwia to aplikacjom łączenie się z urządzeniami lokalnymi, ale ma też wpływ na prywatność, np. umożliwia tworzenie odcisku cyfrowego użytkownika i działa jako serwer proxy lokalizacji.

Projekt zabezpieczeń sieci lokalnej ma na celu ochronę prywatności użytkownika przez ograniczenie dostępu do sieci lokalnej za pomocą nowych uprawnień w czasie działania aplikacji.

Plan wdrażania

Ta zmiana zostanie wprowadzona między 2 wydaniami: odpowiednio 25Q2 i 26Q2. Deweloperzy muszą postępować zgodnie z tymi wskazówkami w II kwartale 2025 r. i przekazywać opinie, ponieważ te zabezpieczenia będą egzekwowane w późniejszej wersji Androida. Ponadto deweloperzy będą musieli zaktualizować scenariusze, które zależą od niejawnego dostępu do sieci lokalnej, korzystając z poniższych wskazówek, i przygotować się na odrzucenie i unieważnienie nowego uprawnienia przez użytkownika.

Wpływ

Na obecnym etapie LNP jest funkcją opcjonalną, co oznacza, że będzie ona miała wpływ tylko na aplikacje, które ją włączą. Celem fazy akceptacji jest umożliwienie deweloperom aplikacji zrozumienia, które części ich aplikacji zależą od niejawnego dostępu do sieci lokalnej, aby mogli przygotować się do zabezpieczenia ich uprawnieniami w następnej wersji.

Zmiany będą miały wpływ na aplikacje, które uzyskują dostęp do sieci lokalnej użytkownika za pomocą:

• bezpośrednie lub biblioteczne użycie nieprzetworzonych gniazd na adresach sieci lokalnej (np. protokół wykrywania usług mDNS lub SSDP);
• używanie klas na poziomie platformy, które uzyskują 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 w aplikacji	Wymagane uprawnienia do sieci lokalnej
Nawiązywanie wychodzącego połączenia TCP	tak
Akceptowanie przychodzących połączeń TCP	tak
wysyłanie pakietów UDP typu unicast, multicast i broadcast;	tak
odbieranie przychodzących pakietów UDP typu unicast, multicast i broadcast;	tak

Te ograniczenia są implementowane głęboko w stosie sieciowym, więc dotyczą wszystkich interfejsów API sieci. Obejmuje to gniazda utworzone w kodzie natywnym lub zarządzanym, biblioteki sieciowe takie jak Cronet i OkHttp oraz wszelkie interfejsy API zaimplementowane na ich podstawie. Próba rozpoznania usług w sieci lokalnej (czyli tych z sufiksem .local) będzie wymagać uprawnień do sieci lokalnej.

Uwaga: ruch pochodzący z komponentów Android Webview, które wymagają dostępu do sieci lokalnej, odziedziczy stan uprawnień z aplikacji hosta.

Wyjątki od powyższych zasad:

• 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 podamy w IV kwartale 2025 r.).

Uwaga: wiele scenariuszy przesyłania multimediów zależy od dostępu do sieci lokalnej i będzie miało na nie wpływ ta zmiana. Nie wszystkie aplikacje, które oferują przesyłanie, będą jednak musiały prosić o nowe uprawnienia. W IV kwartale 2025 r. udostępnimy przyszłe interfejsy API i wskazówki dotyczące scenariuszy przesyłania.

Wskazówki dla deweloperów (akceptacja)

Aby włączyć ograniczenia dotyczące sieci lokalnej:

1. Zainstaluj na urządzeniu kompilację z 25Q2 Beta 3 lub nowszą.
2. Zainstaluj aplikację, którą chcesz przetestować.

3. Przełącz flagę Appcompat 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ędzie to miało wpływu na fazę akceptacji.

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

1. Upewnij się, że aplikacja deklaruje uprawnienie NEARBY_WIFI_DEVICES w pliku manifestu.
2. Otwórz Ustawienia > Aplikacje > [nazwa aplikacji] > Uprawnienia > Urządzenia w pobliżu > Zezwól.

Uwaga: w przyszłej wersji Androida ta funkcja będzie chroniona przez nowe uprawnienie w grupie uprawnień Urządzenia w pobliżu.

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

Gdy zacznie obowiązywać egzekwowanie zasad dotyczących ochrony sieci lokalnej, ruch w sieci aplikacji będzie wyglądał tak:

Uprawnienie	Żądanie wychodzące 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ę App-Compat, 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 wywoła ono funkcję send lub jej wariant na adres sieci lokalnej.

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 z możliwością transmisji rozgłoszeniowej, takiego jak Wi-Fi lub Ethernet, ale nie obejmuje połączeń komórkowych (WWAN) ani połączeń VPN.

Za sieci lokalne uznawane są:

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:

• Połączenie lokalne
• Trasy połączone bezpośrednio
• sieci szczątkowe, takie jak Thread;
• Wiele podsieci (do ustalenia)

Dodatkowo zarówno adresy multiemisji (224.0.0.0/4, ff00::/8), jak 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 或更高版本的设备上提示用户授予照片和视频权限时，如果用户选择限制对所选媒体的访问权限，则会在照片选择器中看到该应用拥有的所有照片。用户可以取消选择任何这些预选项，这会撤消该应用对这些照片和视频的访问权限。