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

Wymagane przeprowadzenie migracji lub rezygnacja z funkcji przewidywania wstecz.

W przypadku aplikacji kierowanych na Androida 16 (API na poziomie 36) lub nowszego i uruchamianych na urządzeniu z Androidem 16 lub nowszym animacje systemowe przewidywania powrotu (powrót do ekranu głównego, przełączanie między zadaniami i przełączanie między aktywnościami) są domyślnie włączone. Dodatkowo wywołanie onBackPressed i wysyłanie KeyEvent.KEYCODE_BACK nie są już wykonywane.

Jeśli Twoja aplikacja przechwytuje zdarzenie powrotu i nie została jeszcze przeniesiona do przewidywanego powrotu, zaktualizuj ją, aby korzystała z obsługiwanych interfejsów API nawigacji wstecz, lub tymczasowo zrezygnuj z tej funkcji, ustawiając atrybut android:enableOnBackInvokedCallback na false w tagu <application> lub <activity> w pliku AndroidManifest.xml aplikacji.

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.

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

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

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

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

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

W przypadku zmiany rozmiaru wyświetlacza 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 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:

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

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

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:

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:

1. Przeprowadź flashowanie urządzenia z użyciem wersji 25Q2 Beta 3 lub nowszej.
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

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.

1. Upewnij się, że aplikacja deklaruje uprawnienie NEARBY_WIFI_DEVICES w pliku manifestu.
2. 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:

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.