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

Interfejs użytkownika i systemu

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

Wyłączenie wyświetlania bez ramki

Android 15 wymusza wyświetlanie bez ramki 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 powrotu

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

以 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 替换默认值的应用，
elegantTextHeight 行为。
以 Android 16（API 级别 36）为目标平台的应用，或以 Android 15（API 级别 35）为目标平台但未通过将 elegantTextHeight 属性设置为 false 来替换默认值的应用，其
elegantTextHeight 行为。

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

W przypadku aplikacji kierowanych na Androida 16 (API na poziomie 36) ta wersja Androida wprowadza zmiany w sposobie zarządzania przez system ograniczeniami dotyczącymi orientacji, zmiany rozmiaru i proporcji. 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 pliku manifestu i interfejsy API środowiska wykonawczego:

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 parametry 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, zmiany rozmiaru i proporcji 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

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

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

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

Aplikacjach mobilnych

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

Łą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 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 (poziom API 36) zawiera te zmiany dotyczące bezpieczeństwa:

Blokowanie wersji MediaStore

对于以 Android 16 或更高版本为目标平台的应用，MediaStore#getVersion() 现在将是每个应用的唯一标识。这会从版本字符串中移除标识属性，以防止滥用和用于指纹识别技术。应用不应对此版本的格式做出任何假设。在使用此 API 时，应用应已处理版本变更，并且在大多数情况下无需更改其当前行为，除非开发者尝试推断超出此 API 预期范围的其他信息。

Bezpieczniejsze intencje

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

W Androidzie 15 ta funkcja 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 rozwiązywanie intencji za pomocą manifestu aplikacji.

Wprowadzamy 2 kluczowe zmiany:

  1. Intencje bezpośrednie muszą być zgodne z filtrem intencji komponentu docelowego: Jeśli intencja jest kierowana bezpośrednio na komponent, powinna być zgodna z filtrem intencji tego komponentu.

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

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

Wpływ

Wymaga to zgody użytkownika, co oznacza, ż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ą korzystać z obecnego, mniej bezpiecznego sposobu 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 będzie 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 całej aplikacji, ale wyłączona lub z niej zrezygnowano na odbiorniku:

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

Więcej informacji o obsługiwanych flagach:

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

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.". Oznacza 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:")

Prywatność

Android 16 (poziom API 36) wprowadza następujące 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 odcisku palca użytkownika i działanie jako serwer proxy lokalizacji.

Projekt Local Network Protections ma na celu ochronę prywatności użytkownika poprzez ograniczenie dostępu do sieci lokalnej za pomocą nowego uprawnienia środowiska wykonawczego.

Plan wydania

Ta zmiana zostanie wprowadzona między 2 wersjami: 25Q2 i TBD. 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 niejawnego dostępu do sieci lokalnej, korzystając z tych wskazówek, i przygotować się na odrzucenie lub cofnięcie nowego uprawnienia przez użytkownika.

Wpływ

Na obecnym etapie LNP jest funkcją, którą można włączyć. Oznacza to, że dotyczy ona tylko aplikacji, 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 dostępu w kolejnej wersji.

Aplikacje będą miały wpływ na dostęp do sieci lokalnej użytkownika, jeśli korzystają z tych funkcji:

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

Ruch do i z adresu sieci lokalnej wymaga zezwolenia na dostęp 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 pakietów UDP unicast, multicast i broadcast tak
Odbieranie przychodzących pakietów UDP unicast, multicast i broadcast tak

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

Wyjątki od powyższych reguł:

  • Jeśli serwer DNS urządzenia znajduje się w sieci lokalnej, ruch do niego lub z niego (na porcie 53) nie wymaga uprawnień dostępu do sieci lokalnej.
  • Aplikacje, 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.).

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

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

  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:

Uprawnienia Żą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, gdy tylko 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 // 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)

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