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.

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.

Rezygnacja z wyświetlania reklam 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 z przewidywanego przejścia wstecz

对于以 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 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 funkcja

Android 16 (poziom API 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 API 36) wprowadza te zmiany w aplikacjach 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
• resizableActivity
• minAspectRatio
• maxAspectRatio
• setRequestedOrientation()
• getRequestedOrientation()

系统会忽略 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>

重要提示： 此选择停用是临时性的，在未来的 Android 版本中以 API 级别 37 为目标平台时，此选择停用将不再适用。也就是说，对于以 API 级别 37 为目标的应用，在至少为 sw600dp 的显示屏上，系统会忽略屏幕方向、尺寸可调整性和宽高比限制。

Zdrowie i fitness

Android 16 (poziom interfejsu API 36) zawiera następujące 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:

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

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

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

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.

Ważne: jeśli nie podasz uzasadnienia dla aplikacji mobilnych, uprawnienie zostanie cofnięte.

Łączność

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

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

“更安全的 intent”功能是一项多阶段安全计划，旨在提高 Android 的 intent 解析机制的安全性。其目标是在 intent 处理期间添加检查，并过滤不符合特定条件的 intent，从而保护应用免受恶意操作的影响。

在 Android 15 中，此功能侧重于发送应用，而现在在 Android 16 中，控制权转移到了接收应用，开发者可以使用应用清单选择启用严格的 intent 解析。

我们正在实施两项关键变更：

1. 显式 intent 必须与目标组件的 intent 过滤器匹配：如果 intent 显式以某个组件为目标，则应与该组件的 intent 过滤器匹配。

2. 没有操作的 intent 无法与任何 intent 过滤器匹配：未指定操作的 intent 不应解析为任何 intent 过滤器。

这些变更仅在涉及多个应用时适用，不会影响单个应用内的 intent 处理。

影响

由于此功能是选择启用，因此开发者必须在应用清单中明确启用此功能，才能使其生效。因此，此功能的影响将仅限于以下应用：

• 了解“更安全的 intent”功能及其优势。
• 主动选择将更严格的 intent 处理实践融入到其应用中。

这种选择启用方法可最大限度地降低破坏可能依赖于当前安全性较低的 intent 解析行为的现有应用的风险。

虽然在 Android 16 中的初始影响可能有限，但“更安全的 intent”计划制定了在未来的 Android 版本中扩大影响的路线图。 该计划最终将使严格的 intent 解析成为默认行为。

“更安全的 intent”功能通过使恶意应用更难利用 intent 解析机制中的漏洞，有可能显著增强 Android 生态系统的安全性。

不过，向选择退出和强制执行的过渡必须经过仔细管理，以解决与现有应用潜在的兼容性问题。

实现

开发者需要在应用清单中使用 intentMatchingFlags 属性明确启用更严格的 intent 匹配。 以下示例展示了如何为整个应用选择启用此功能，但在接收器上停用/选择停用此功能：

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

注意： 可以在 <application> 标记以及组件标记（例如 <activity>、<activity-alias>、<receiver>、<service>、<provider>）上指定该属性，并且可以使用组件上的属性替换 <application> 标记上的属性

详细了解支持的标志：

标志名称	说明
enforceIntentFilter	对传入 intent 强制执行更严格的匹配
none	停用传入 intent 的所有特殊匹配规则。指定多个标志时，系统会优先使用“none”标志来解决冲突值
allowNullAction	放宽匹配规则，允许没有操作的 intent 进行匹配。此标志应与“enforceIntentFilter”结合使用，以实现特定行为

测试和调试

启用强制执行后，如果 intent 调用方已正确填充 intent，应用应能正常运行。 不过，被屏蔽的 intent 会触发警告日志消息，例如 "Intent does not match component's intent filter:" 和 "Access blocked:" ，并带有标记 "PackageManager." 。这表示可能存在影响应用的问题，需要引起 注意。

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 [e-mail].

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 (poziom API 36) zawiera te zmiany dotyczące prywatności:

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

Uwaga: ruch pochodzący z widoków internetowych na Androidzie, które wymagają dostępu do sieci lokalnej, będzie dziedziczyć stan uprawnień z aplikacji hosta.

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

Uwaga: wiele scenariuszy przesyłania multimediów zależy od dostępu do sieci lokalnej i ta zmiana będzie miała na nie wpływ. Nie wszystkie aplikacje, które oferują przesyłanie, będą jednak musiały prosić o nowe uprawnienia. Przyszłe interfejsy API i wskazówki dotyczące obsługi scenariuszy przesyłania zostaną udostępnione 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.

Uwaga: w przyszłej wersji Androida ta funkcja będzie chroniona przez nowe uprawnienia w grupie uprawnień dotyczących urządzeń w pobliżu.

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.