Ta strona została przetłumaczona przez Cloud Translation API.

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 w działaniu dotyczą wyłącznie aplikacji kierowanych na Androida 16 lub nowszego. Jeśli Twoja aplikacja jest kierowana na Androida 16 lub nowszego, w razie potrzeby zmodyfikuj ją, aby obsługiwała te funkcje.

Zapoznaj się też z listą zmian w działaniu, które dotyczą wszystkich aplikacji działających na Androidzie 16, niezależnie od tego, czy Twoja aplikacja ma targetSdkVersion.

Wrażenia użytkownika i interfejs systemu

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

Odrzucenie wyświetlania bez ramki

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 Beta 版 3 中进行测试，请确保您的应用支持无边框设计，并移除对 R.attr#windowOptOutEdgeToEdgeEnforcement 的所有使用，以便您的应用在 Android 15 设备上也支持无边框设计。如需支持边到边，请参阅 Compose 和 Views 指南。

Wymagane przeprowadzenie migracji lub rezygnacja z funkcji przewidywania wstecz.

W przypadku aplikacji kierowanych na Androida 16 (poziom interfejsu API 36) lub nowszego i działających na urządzeniu z Androidem 16 lub nowszym domyślnie włączone są przewidujące animacje systemu (powrót do ekranu głównego, między zadaniami i między działaniami). Dodatkowo funkcja onBackPressed nie jest wywoływana, a zapytanie KeyEvent.KEYCODE_BACK nie jest już wysyłane.

Jeśli Twoja aplikacja przechwytuje zdarzenie wstecz i nie została jeszcze przeniesiona na przewidywane wsteczne przechodzenie, zaktualizuj ją, aby używała obsługiwanych interfejsów API do nawigacji wstecz, lub użyj tymczasowego wyłączenia, ustawiając atrybut android:enableOnBackInvokedCallback na false w tagu <application> lub <activity> pliku AndroidManifest.xml aplikacji.

Animacja przewidywanego powrotu do domu.

Przewidowana animacja aktywności.

Animacja predykcyjna dotycząca wielu zadań.

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

Apps targeting Android 15 (API level 35) have the elegantTextHeight TextView attribute set to true by default, replacing the compact font with one that is much more readable. You could override this by setting the elegantTextHeight attribute to false.

Android 16 deprecates the elegantTextHeight attribute, and the attribute will be ignored once your app targets Android 16. The "UI fonts" controlled by these APIs are being discontinued, so you should adapt any layouts to ensure consistent and future proof text rendering in Arabic, Lao, Myanmar, Tamil, Gujarati, Kannada, Malayalam, Odia, Telugu or Thai.

`elegantTextHeight` behavior for apps targeting Android 14 (API level 34) and lower, or for apps targeting Android 15 (API level 35) that overrode the default by setting the `elegantTextHeight` attribute to `false`.

`elegantTextHeight` behavior for apps targeting Android 16, or for apps targeting Android 15 (API level 35) that didn't override the default by setting the `elegantTextHeight` attribute to `false`.

Główna funkcja

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

Optymalizacja harmonogramu pracy z ustaloną 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 interfejsu 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）为目标平台的应用，Android 16 对系统管理屏幕方向、尺寸调整能力和宽高比限制的方式进行了更改。在最小宽度大于等于 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 (poziom interfejsu API 36) zawiera te zmiany dotyczące danych o zdrowiu i aktywności fizycznej:

Uprawnienia dotyczące zdrowia i fitnessu

W przypadku aplikacji kierowanych na Androida 16 (poziom API 36) lub nowszego uprawnienia BODY_SENSORS korzystają z bardziej szczegółowych uprawnień android.permissions.health, których używa też Health Connect. Począwszy 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 typy usług działających na pierwszym planie:

HEART_RATE_BPM z Health Services 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 poprosić o odpowiednie szczegółowe uprawnienia:

Aby monitorować tętno, SpO2 lub temperaturę skóry podczas korzystania z aplikacji: poproś o szczegółowe uprawnienia w sekcji android.permissions.health, na przykład READ_HEART_RATE zamiast BODY_SENSORS.
Dostęp do czujnika w tle: poproś o READ_HEALTH_DATA_IN_BACKGROUND zamiast o BODY_SENSORS_BACKGROUND.

Są to te same uprawnienia, które chronią dostęp do odczytu danych z Health Connect, czyli bazy danych Androida zawierającej dane o zdrowiu, kondycji i samopoczuciu.

Aplikacjach mobilnych

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

Łączność

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

Nowe intencje do obsługi utraty powiązań 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 zabezpieczeń:

Blokada 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 Bezpieczniejsze intencje to inicjatywa mająca na celu zwiększenie bezpieczeństwa mechanizmu rozwiązywania intencji w Androidzie. Celem jest ochrona aplikacji przed złośliwymi działaniami przez dodanie kontroli podczas przetwarzania intencji i odfiltrowywanie intencji, które nie spełniają określonych kryteriów.

W Androidzie 15 ta funkcja była skoncentrowana na aplikacji wysyłającej, ale w Androidzie 16 przejmuje kontrolę aplikacja odbiorcza, co pozwala deweloperom włączyć ścisłe rozwiązywanie intencji w manifeście aplikacji.

Wprowadzamy 2 kluczowe zmiany:

Intencje bezpośrednie muszą pasować do filtra intencji komponentu docelowego: Jeśli intencja kieruje się bezpośrednio na komponent, musi pasować do filtra intencji tego komponentu.
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 za pomocą żadnego filtra intencji.

Te zmiany mają zastosowanie tylko wtedy, gdy występuje wiele aplikacji, i nie mają wpływu na obsługę intencji w pojedynczej aplikacji.

Wpływ

Aby ta funkcja zaczęła działać, deweloperzy muszą ją włączyć w pliku manifestu aplikacji. W związku z tym wpływ tej funkcji będzie ograniczony do aplikacji, których deweloperzy:

znasz funkcję bezpiecznych intencji i jej zalety;
aktywnie wdrożyć w swoich aplikacjach bardziej rygorystyczne metody obsługi intencji;

Takie podejście minimalizuje ryzyko uszkodzenia dotychczasowych aplikacji, które mogą korzystać z obecnego, mniej bezpiecznego zachowania rozwiązywania intencji.

Chociaż początkowy wpływ na Androida 16 może być ograniczony, inicjatywa Bezpieczniejsze intencje ma plan na szersze wdrożenie w przyszłych wersjach Androida. Planujemy, że w przyszłości domyślnym zachowaniem będzie ścisłe rozwiązywanie intencji.

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

Jednak przejście na obowiązkowe stosowanie zasady i możliwość rezygnacji z niej wymagają starannego zarządzania, aby rozwiązać potencjalne problemy ze zgodnością z dotychczasowymi aplikacjami.

Implementacja

Deweloperzy muszą wyraźnie włączyć dopasowywanie według bardziej rygorystycznych intencji, używając atrybutu intentMatchingFlags w pliku manifestu aplikacji. Oto przykład, w którym funkcja jest włączona w przypadku całej aplikacji, ale wyłączona lub wyłączona na poziomie odbiorcy:

<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	Wprowadza bardziej rygorystyczne dopasowywanie intencji przychodzących
brak	Wyłącza wszystkie reguły dopasowywania specjalnego dla przychodzących intencji. Gdy podajesz kilka flag, sprzeczne wartości są rozwiązywane przez nadanie pierwszeństwa fladze „none”.
allowNullAction	Zmniejsza rygoryzm reguł dopasowywania, aby zezwolić na intencje bez dopasowania działania. Ten parametr należy używać w połączeniu z parametrem „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 intent wypełnił go prawidłowo. Zablokowane intencje będą jednak powodować wyświetlanie komunikatów z ostrzeżeniem, takich jak "Intent does not match component's intent filter:" i "Access blocked:", z dodatkiem tagu "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:")

Prywatność

Android 16 (poziom API 36) zawiera te zmiany dotyczące prywatności:

Dostęp do sieci lokalnej

Do urządzeń w sieci LAN można uzyskać dostęp z dowolnej aplikacji, która ma uprawnienia INTERNET. Ułatwia to aplikacjom nawiązywanie połączeń z urządzeniami lokalnymi, ale ma też wpływ na prywatność, np. tworzy odcisk palca użytkownika i działa jako serwer proxy w przypadku lokalizacji.

Projekt Ochrona sieci lokalnej ma na celu ochronę prywatności użytkownika przez ograniczenie dostępu do sieci lokalnej za pomocą nowego uprawnienia w czasie wykonywania.

Plan wydania

Ta zmiana zostanie wdrożona między 2 wersjami: 25Q2 i TBD. Deweloperzy muszą przestrzegać tych wskazówek dotyczących 25Q2 i przekazywać opinie, ponieważ te zabezpieczenia zostaną wprowadzone w późniejszej wersji Androida. Ponadto deweloperzy będą musieli zaktualizować scenariusze, które zależą od domyślnego dostępu do sieci lokalnej, korzystając z tych wskazówek, oraz przygotować się na odrzucenie przez użytkownika i wycofanie nowego uprawnienia.

Wpływ

Obecnie jest to funkcja opcjonalna, co oznacza, że dotyczy ona tylko aplikacji, które ją obsługują. Celem fazy zgód jest umożliwienie deweloperom zrozumienia, które części ich aplikacji są zależne od domyślnego dostępu do sieci lokalnej, aby mogli przygotować się do wprowadzenia ochrony uprawnień w przyszłej wersji.

Dotyczy to aplikacji, które uzyskują dostęp do sieci lokalnej użytkownika za pomocą:

bezpośrednie lub biblioteczne korzystanie z nieprzetworzonych gniazd na adresy sieci lokalnej (np. protokół wykrywania usług mDNS lub SSDP);
Używanie klas na poziomie frameworku, 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:

Operacje sieciowe na niskim poziomie aplikacji	Wymagany dostęp przez sieć lokalną
Nawiązywanie wychodzącego połączenia TCP	tak
Akceptowanie przychodzących połączeń TCP	tak
Wysyłanie transmisji unicast, multicast i broadcast UDP	tak
Odbieranie przychodzącego pakietu UDP unicast, multicast lub broadcast	tak

Te ograniczenia są wdrażane głęboko w składniku sieciowym, dlatego dotyczą wszystkich interfejsów API sieciowych. Dotyczy to gniazd utworzonych w kodzie natywnym lub zarządzanym, bibliotek sieciowych, takich jak Cronet i OkHttp, oraz interfejsów API zaimplementowanych na ich podstawie. Próba rozwiązania usług w sieci lokalnej (czyli usług z przyrostkiem .local) wymaga uprawnień do sieci lokalnej.

Wyjątki od powyższych zasad:

Jeśli serwer DNS urządzenia znajduje się w sieci lokalnej, ruch do niego i 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ą wymagać uprawnień do sieci lokalnej (więcej wskazówek pojawi się w IV kwartale 2025 r.).

Wskazówki dla programistów (włączanie funkcji)

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

Przeprowadź flashowanie urządzenia z użyciem wersji 25Q2 Beta 3 lub nowszej.
Zainstaluj aplikację, którą chcesz przetestować.

Przełącz flagę Appcompat w adb:

adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>

Uruchom ponownie urządzenie

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

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

Upewnij się, że aplikacja deklaruje uprawnienie NEARBY_WIFI_DEVICES w pliku manifestu.
Kliknij Ustawienia > Aplikacje > [Nazwa aplikacji] > Uprawnienia > Urządzenia w pobliżu > Zezwalaj.

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

Gdy zaczniemy egzekwować ochronę sieci lokalnej, w ten sposób wpłynie to na ruch w sieci aplikacji:

Uprawnienia	Wychodzące żądanie LAN	Wychodzące/przychodzące żądanie internetowe	Żą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 wywołującego gniazda, gdy wywoła on metodę send lub jej wariant na potrzeby wysyłania do lokalnego adresu sieci.

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ę, np. Wi-Fi lub Ethernet, ale wyklucza połączenia komórkowe (WWAN) i VPN.

Do sieci lokalnych zaliczamy:

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
siecie typu stub, takie jak Thread;
Wiele podsieci (TBD)

Dodatkowo zarówno adresy multicast (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

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.