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

W przypadku aplikacji kierowanych na Androida 16 (API na poziomie 36) lub nowszego i działających na urządzeniu z Androidem 16 lub nowszym domyślnie włączone są animacje systemowe przewidywanego przejścia wstecz (powrót do ekranu głównego, przejście między zadaniami i przejście między aktywnościami). Dodatkowo nie jest wywoływana funkcja onBackPressed ani nie jest już wysyłany kod KeyEvent.KEYCODE_BACK.

Jeśli Twoja aplikacja przechwytuje zdarzenie przejścia wstecz i nie została jeszcze zmigrowana do przewidywanego przejścia wstecz, zaktualizuj ją, aby korzystała z obsługiwanych interfejsów API przechodzenia wstecz, lub tymczasowo zrezygnuj z tej funkcji, ustawiając android:enableOnBackInvokedCallback atrybut na false w <application> lub <activity> tagu 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 API 36) zawiera te zmiany, które modyfikują lub rozszerzają różne podstawowe funkcje systemu Android.

Optymalizacja harmonogramu pracy przy stałej stawce

Prior to targeting Android 16, when scheduleAtFixedRate missed a task execution due to being outside a valid process lifecycle, all missed executions immediately execute when the app returns to a valid lifecycle.

When targeting Android 16, at most one missed execution of scheduleAtFixedRate is immediately executed when the app returns to a valid lifecycle. This behavior change is expected to improve app performance. Test this behavior in your app to check if your app is impacted. You can also test by using the app compatibility framework and enabling the STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS compat flag.

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

With Android apps now running on a variety of devices (such as phones, tablets, foldables, desktops, cars, and TVs) and windowing modes on large screens (such as split screen and desktop windowing), developers should build Android apps that adapt to any screen and window size, regardless of device orientation. Paradigms like restricting orientation and resizability are too restrictive in today's multidevice world.

Ignore orientation, resizability, and aspect ratio restrictions

For apps targeting Android 16 (API level 36), orientation, resizability, and aspect ratio restrictions no longer apply on displays with smallest width >= 600dp. Apps fill the entire display window, regardless of aspect ratio or a user's preferred orientation, and pillarboxing isn't used.

This change introduces a new standard platform behavior. Android is moving toward a model where apps are expected to adapt to various orientations, display sizes, and aspect ratios. Restrictions like fixed orientation or limited resizability hinder app adaptability. Make your app adaptive to deliver the best possible user experience.

You can also test this behavior by using the app compatibility framework and enabling the UNIVERSAL_RESIZABLE_BY_DEFAULT compat flag.

Common breaking changes

Ignoring orientation, resizability, and aspect ratio restrictions might impact your app's UI on some devices, especially elements that were designed for small layouts locked in portrait orientation: for example, issues like stretched layouts and off-screen animations and components. Any assumptions about aspect ratio or orientation can cause visual issues with your app. Learn more about how to avoid them and improve your app's adaptive behaviour.

Allowing device rotation results in more activity re-creation, which can result in losing user state if not properly preserved. Learn how to correctly save UI state in Save UI states.

Implementation details

The following manifest attributes and runtime APIs are ignored across large screen devices in full-screen and multi-window modes:

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

The following values for screenOrientation, setRequestedOrientation(), and getRequestedOrientation() are ignored:

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

Regarding display resizability, android:resizeableActivity="false", android:minAspectRatio, and android:maxAspectRatio have no effect.

For apps targeting Android 16 (API level 36), app orientation, resizability, and aspect ratio constraints are ignored on large screens by default, but every app that isn't fully ready can temporarily override this behavior by opting out (which results in the previous behavior of being placed in compatibility mode).

Exceptions

The Android 16 orientation, resizability, and aspect ratio restrictions don't apply in the following situations:

• Games (based on the android:appCategory flag)
• Users explicitly opting in to the app's default behavior in aspect ratio settings of the device
• Screens that are smaller than sw600dp

Opt out temporarily

To opt out a specific activity, declare the PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY manifest property:

<activity ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
  ...
</activity>

If too many parts of your app aren't ready for Android 16, you can opt out completely by applying the same property at the application level:

<application ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
</application>

Zdrowie i fitness

Android 16 (poziom 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.

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

All apps targeting Android 16 are now able to unpair bluetooth devices using a public API in CompanionDeviceManager. If a companion device is being managed as a CDM association, then the app can trigger bluetooth bond removal by using the new removeBond(int) API on the associated device. The app can monitor the bond state changes by listening to the bluetooth device broadcast event 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

Funkcja Safer Intents to wieloetapowa inicjatywa na rzecz bezpieczeństwa, która ma na celu zwiększenie bezpieczeństwa mechanizmu rozpoznawania intencji w Androidzie. Jej 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 funkcja ta koncentrowała się na aplikacji wysyłającej, a teraz w Androidzie 16, przenosi kontrolę na aplikację odbierającą, umożliwiając deweloperom włączenie ścisłego rozpoznawania intencji za pomocą pliku manifestu aplikacji.

Wprowadzamy 2 kluczowe zmiany:

1. Intencje jawne muszą pasować do filtra intencji komponentu docelowego: jeśli intencja jest jawnie kierowana 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ć rozpoznawane przez żaden filtr intencji.

Te zmiany mają zastosowanie tylko wtedy, gdy używanych jest kilka aplikacji, i nie wpływają na obsługę intencji w obrębie jednej aplikacji.

Wpływ

Funkcja jest opcjonalna, co oznacza, że deweloperzy muszą ją wyraźnie włączyć w pliku manifestu aplikacji, aby zaczęła działać. W rezultacie wpływ tej funkcji będzie ograniczony do aplikacji, których deweloperzy:

• znają funkcję Safer Intents i jej zalety,
• aktywnie decydują się na włączenie do swoich aplikacji bardziej rygorystycznych praktyk obsługi intencji.

Takie podejście oparte na akceptacji minimalizuje ryzyko uszkodzenia istniejących aplikacji, które mogą polegać na obecnym, mniej bezpiecznym sposobie rozpoznawania intencji.

Chociaż początkowy wpływ w Androidzie 16 może być ograniczony, inicjatywa Safer Intents ma plan działania, który zapewni szerszy wpływ w przyszłych wersjach Androida. Docelowo chcemy, aby ścisłe rozpoznawanie intencji było domyślnym zachowaniem.

Funkcja Safer Intents może znacznie zwiększyć bezpieczeństwo ekosystemu Androida, utrudniając szkodliwym aplikacjom wykorzystywanie luk w zabezpieczeniach 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 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>

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 intencję prawidłowo wypełnił intencję. Zablokowane intencje będą jednak powodować wyświetlanie ostrzegawczych komunikatów w logach, takich 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

To harden the Mali GPU surface, Mali GPU IOCTLs that have been deprecated or are intended solely for GPU development have been blocked in production builds. Additionally, IOCTLs used for GPU profiling have been restricted to the shell process or debuggable applications. Refer to the SAC update for more details on the platform-level policy.

This change takes place on Pixel devices using the Mali GPU (Pixel 6-9). Arm has provided official categorization of their IOCTLs in Documentation/ioctl-categories.rst of their r54p2 release. This list will continue to be maintained in future driver releases.

This change does not impact supported graphics APIs (including Vulkan and OpenGL), and is not expected to impact developers or existing applications. GPU profiling tools such as the Streamline Performance Analyzer and the Android GPU Inspector won't be affected.

Testing

If you see a SELinux denial similar to the following, it is likely your application has been impacted by this change:

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

If your application needs to use blocked IOCTLs, please file a bug and assign it to android-partner-security@google.com.

FAQ

1. Does this policy change apply to all OEMs? This change will be opt-in, but available to any OEMs who would like to use this hardening method. Instructions for implementing the change can be found in the implementation documentation.

2. Is it mandatory to make changes in the OEM codebase to implement this, or does it come with a new AOSP release by default? The platform-level change will come with a new AOSP release by default. Vendors may opt-in to this change in their codebase if they would like to apply it.

3. Are SoCs responsible for keeping the IOCTL list up to date? For example, if my device uses an ARM Mali GPU, would I need to reach out to ARM for any of the changes? Individual SoCs must update their IOCTL lists per device upon driver release. For example, ARM will update their published IOCTL list upon driver updates. However, OEMs should make sure that they incorporate the updates in their SEPolicy, and add any selected custom IOCTLs to the lists as needed.

4. Does this change apply to all Pixel in-market devices automatically, or is a user action required to toggle something to apply this change? This change applies to all Pixel in-market devices using the Mali GPU (Pixel 6-9). No user action is required to apply this change.

5. Will use of this policy impact the performance of the kernel driver? This policy was tested on the Mali GPU using GFXBench, and no measurable change to GPU performance was observed.

6. Is it necessary for the IOCTL list to align with the current userspace and kernel driver versions? Yes, the list of allowed IOCTLs must be synchronized with the IOCTLs supported by both the userspace and kernel drivers. If the IOCTLs in the user space or kernel driver are updated, the SEPolicy IOCTL list must be updated to match.

7. ARM has categorized IOCTLs as 'restricted' / 'instrumentation', but we want to use some of them in production use-cases, and/or deny others. Individual OEMs/SoCs are responsible for deciding on how to categorize the IOCTLs they use, based on the configuration of their userspace Mali libraries. ARM's list can be used to help decide on these, but each OEM/SoC's use-case may be different.

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:

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

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.

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:

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.