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.

Interfejs użytkownika i systemowy

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

Wycofanie opcji rezygnacji z wyświetlania od krawędzi do krawędzi

Android 15 wymusza wyświetlanie od krawędzi do krawędzi w przypadku aplikacji kierowanych na Androida 15 (poziom API 35), ale możesz zrezygnować z tej opcji, ustawiając R.attr#windowOptOutEdgeToEdgeEnforcement na true. W przypadku aplikacji kierowanych na Androida 16 (poziom API 36) metoda R.attr#windowOptOutEdgeToEdgeEnforcement jest wycofana i wyłączona, a aplikacja nie może zrezygnować z wyświetlania bez ramki.

• Jeśli aplikacja jest kierowana na Androida 16 (API na poziomie 36) i działa na urządzeniu z Androidem 15, R.attr#windowOptOutEdgeToEdgeEnforcement nadal działa.
• Jeśli 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.

Aby przetestować aplikację na Androidzie 16, upewnij się, że obsługuje ona tryb od krawędzi do krawędzi, i usuń wszystkie wystąpienia R.attr#windowOptOutEdgeToEdgeEnforcement, aby aplikacja obsługiwała ten tryb również na urządzeniach z Androidem 15. Aby dowiedzieć się, jak obsługiwać tryb od krawędzi do krawędzi, zapoznaj się ze wskazówkami dotyczącymi Compose i widoków.

W przypadku przewidywanego przejścia wstecz wymagana jest migracja lub rezygnacja

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

Jeśli Twoja aplikacja przechwytuje zdarzenie przejścia wstecz i nie została jeszcze przeniesiona na przewidywane przejście wstecz, zaktualizuj ją, aby korzystała z obsługiwanych interfejsów API przechodzenia 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 eleganckich czcionek

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 (API na poziomie 36) zawiera te zmiany, które modyfikują lub rozszerzają różne podstawowe funkcje systemu Android.

Optymalizacja harmonogramu pracy ze stałą 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 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 (takich jak telefony, tablety, urządzenia składane, komputery, samochody i telewizory) oraz w trybach okien na dużych ekranach (takich jak podzielony ekran i tryb okien na pulpicie). Deweloperzy powinni więc tworzyć aplikacje na Androida, które dostosowują się do każdego rozmiaru ekranu i okna, niezależnie od orientacji urządzenia. Paradygmaty takie jak ograniczanie orientacji i możliwości zmiany rozmiaru są zbyt restrykcyjne w dzisiejszym świecie wielu urządzeń.

Ignorowanie ograniczeń dotyczących orientacji, możliwości zmiany rozmiaru i formatu obrazu

W przypadku aplikacji kierowanych na Androida 16 (poziom API 36) ograniczenia dotyczące orientacji, możliwości zmiany rozmiaru i formatu obrazu nie obowiązują już na wyświetlaczach o najmniejszej szerokości >= 600 dp. Aplikacje wypełniają całe okno wyświetlania, niezależnie od formatu obrazu lub preferowanej przez użytkownika orientacji, i nie są stosowane czarne pasy po bokach.

Ta zmiana wprowadza nowe standardowe działanie platformy. Android przechodzi na model, w którym aplikacje mają dostosowywać się do różnych orientacji, rozmiarów wyświetlacza i formatów obrazu. Ograniczenia takie jak stała orientacja czy ograniczona możliwość zmiany rozmiaru utrudniają dostosowywanie aplikacji. Dostosuj aplikację, aby zapewnić użytkownikom jak najlepsze wrażenia.

Możesz też przetestować to zachowanie, korzystając z systemu sprawdzania zgodności aplikacji i włączając flagę zgodności UNIVERSAL_RESIZABLE_BY_DEFAULT.

Typowe zmiany powodujące niezgodność

Ignorowanie ograniczeń dotyczących orientacji, możliwości zmiany rozmiaru i formatu obrazu może mieć wpływ na interfejs aplikacji na niektórych urządzeniach, zwłaszcza na elementy, które zostały zaprojektowane dla małych układów 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 formatu obrazu lub orientacji mogą powodować problemy z wyświetlaniem aplikacji. Dowiedz się więcej o tym, jak ich unikać i poprawić działanie aplikacji na różnych urządzeniach.

Zezwolenie na obracanie urządzenia powoduje częstsze ponowne tworzenie aktywności, co może skutkować utratą stanu użytkownika, jeśli nie zostanie on prawidłowo zachowany. Dowiedz się, jak prawidłowo zapisywać stan interfejsu, w artykule Zapisywanie stanów interfejsu.

Szczegóły implementacji

Następujące atrybuty manifestu i interfejsy API środowiska wykonawczego są ignorowane na urządzeniach z dużym ekranem w trybach pełnoekranowym i wielu okien:

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

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

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

Jeśli chodzi o możliwość zmiany rozmiaru wyświetlacza, 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, możliwości zmiany rozmiaru i formatu obrazu są domyślnie ignorowane na dużych ekranach. Każda aplikacja, która nie jest w pełni gotowa, może tymczasowo zastąpić to zachowanie, rezygnując z niego, co spowoduje, że będzie działać w trybie zgodności.

Wyjątki

Ograniczenia dotyczące orientacji, możliwości zmiany rozmiaru i formatu obrazu w Androidzie 16 nie obowiązują w tych sytuacjach:

• Gry (na podstawie flagi android:appCategory)
• użytkownicy wyraźnie akceptują działanie domyślne aplikacji w ustawieniach formatu 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 dotyczące danych 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ń w ramach android.permissions.health, których używa też 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 od ProtoLayout na Wear OS
• FOREGROUND_SERVICE_TYPE_HEALTH, gdzie zamiast uprawnienia BODY_SENSORS wymagane jest uprawnienie android.permission.health.

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

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

Są to te same uprawnienia, które chronią dostęp do odczytu danych z Health Connect, magazynu danych na Androidzie, w którym przechowywane są dane o zdrowiu, aktywności fizycznej i samopoczuciu.

Aplikacje mobilne

Aplikacje mobilne, które przechodzą na uprawnienie READ_HEART_RATE i inne uprawnienia szczegółowe, muszą też zadeklarować aktywność, aby wyświetlać politykę prywatności aplikacji. To samo wymaganie dotyczy Health Connect.

Połączenia

Android 16 (poziom API 36) wprowadza te zmiany w stosie Bluetooth, aby poprawić łączność z urządzeniami peryferyjnymi.

Nowe intencje do obsługi utraty powiązania 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 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 bezpieczniejszych intencji to wieloetapowa inicjatywa, której celem jest zwiększenie bezpieczeństwa mechanizmu rozpoznawania intencji na Androidzie. Celem jest ochrona aplikacji przed szkodliwymi 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 skupiała się na aplikacji wysyłającej. Teraz, w Androidzie 16, kontrola przechodzi na aplikację odbierającą, co pozwala deweloperom na włączenie ścisłego rozpoznawania intencji za pomocą manifestu aplikacji.

Wprowadzamy 2 kluczowe zmiany:

1. Intencje bezpośrednie muszą pasować do filtra intencji komponentu docelowego: jeśli intencja jest kierowana bezpośrednio 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ć dopasowywane do żadnego filtra intencji.

Te zmiany dotyczą tylko sytuacji, gdy używanych jest kilka aplikacji, i nie mają wpływu na obsługę intencji w ramach jednej aplikacji.

Wpływ

Charakter akceptacji oznacza, że deweloperzy muszą wyraźnie 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;
• świadomie zdecydować się na stosowanie w swoich aplikacjach bardziej rygorystycznych praktyk dotyczących obsługi intencji.

Takie podejście oparte na akceptacji minimalizuje ryzyko uszkodzenia istniejących aplikacji, które mogą polegać na obecnym, mniej bezpiecznym zachowaniu związanym z rozpoznawaniem intencji.

Chociaż początkowy wpływ na Androida 16 może być ograniczony, inicjatywa Bezpieczniejsze intencje ma plan działania, który ma na celu zwiększenie wpływu w przyszłych wersjach Androida. Planujemy, aby ścisłe rozpoznawanie intencji stało się działaniem domyślnym.

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

Jednak przejście na model rezygnacji i obowiązkowe egzekwowanie musi być dokładnie 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 ją wypełnił. Zablokowane intencje będą jednak wywoływać komunikaty logu z ostrzeżeniami, takie 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

Aby wzmocnić powierzchnię GPU Mali, w kompilacjach produkcyjnych zablokowano wywołania IOCTL GPU Mali, które zostały wycofane lub są przeznaczone wyłącznie do programowania GPU. Dodatkowo kody IOCTL używane do profilowania GPU zostały ograniczone do procesu powłoki lub aplikacji z możliwością debugowania. Więcej informacji o zasadach na poziomie platformy znajdziesz w aktualizacji dotyczącej SAC.

Ta zmiana dotyczy urządzeń Pixel z GPU Mali (Pixel 6–9). Firma Arm udostępniła oficjalną kategoryzację swoich wywołań IOCTL w Documentation/ioctl-categories.rst wersji r54p2. Ta lista będzie nadal aktualizowana w przyszłych wersjach sterowników.

Ta zmiana nie ma wpływu na obsługiwane interfejsy API grafiki (w tym Vulkan i OpenGL) i nie powinna mieć wpływu na deweloperów ani istniejące aplikacje. Nie będzie to miało wpływu na narzędzia do profilowania GPU, takie jak Streamline Performance Analyzer i Android GPU Inspector.

Testowanie

Jeśli widzisz odmowę SELinux podobną do tej, prawdopodobnie ta zmiana ma wpływ na Twoją aplikację:

06-30 10:47:18.617 20360 20360 W roidJUnitRunner: type=1400 audit(0.0:85): avc:  denied  { ioctl }
for  path="/dev/mali0" dev="tmpfs" ino=1188 ioctlcmd=0x8023
scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:gpu_device:s0 tclass=chr_file
permissive=0 app=com.google.android.selinux.pts

Jeśli Twoja aplikacja musi używać zablokowanych wywołań IOCTL, zgłoś błąd i przypisz go do android-partner-security@google.com.

Najczęstsze pytania

1. Czy ta zmiana zasad dotyczy wszystkich producentów OEM? Ta zmiana będzie opcjonalna, ale dostępna dla wszystkich producentów OEM, którzy chcą korzystać z tej metody wzmacniania zabezpieczeń. Instrukcje dotyczące wprowadzania zmian znajdziesz w dokumentacji dotyczącej implementacji.

2. Czy aby wdrożyć tę funkcję, trzeba wprowadzić zmiany w bazie kodu OEM, czy jest ona domyślnie dostępna w nowej wersji AOSP? Zmiana na poziomie platformy zostanie domyślnie wprowadzona w nowej wersji AOSP. Dostawcy mogą wyrazić zgodę na tę zmianę w swojej bazie kodu, jeśli chcą ją zastosować.

3. Czy producenci układów SoC są odpowiedzialni za aktualizowanie listy IOCTL? Jeśli na przykład moje urządzenie korzysta z GPU ARM Mali, czy muszę skontaktować się z firmą ARM w sprawie jakichkolwiek zmian? Poszczególne układy SoC muszą aktualizować listy IOCTL dla każdego urządzenia po wydaniu sterownika. Na przykład ARM aktualizuje opublikowaną listę IOCTL po aktualizacji sterowników. Producenci OEM powinni jednak upewnić się, że uwzględniają aktualizacje w swoich zasadach SEPolicy i w razie potrzeby dodają do list wybrane niestandardowe wywołania IOCTL.

4. Czy ta zmiana dotyczy automatycznie wszystkich urządzeń Pixel dostępnych na rynku, czy też użytkownik musi coś zrobić, aby ją zastosować? Ta zmiana dotyczy wszystkich dostępnych na rynku urządzeń Pixel z GPU Mali (Pixel 6–9). Aby zastosować tę zmianę, nie musisz podejmować żadnych działań.

5. Czy użycie tej zasady wpłynie na wydajność sterownika jądra? Ta zasada została przetestowana na GPU Mali za pomocą GFXBench i nie zaobserwowano żadnych mierzalnych zmian w wydajności GPU.

6. Czy lista IOCTL musi być zgodna z bieżącymi wersjami sterowników przestrzeni użytkownika i jądra? Tak, lista dozwolonych wywołań IOCTL musi być zsynchronizowana z wywołaniami IOCTL obsługiwanymi zarówno przez sterowniki przestrzeni użytkownika, jak i sterowniki jądra. Jeśli wywołania IOCTL w przestrzeni użytkownika lub sterowniku jądra zostaną zaktualizowane, należy odpowiednio zaktualizować listę wywołań IOCTL w SEPolicy.

7. ARM sklasyfikował IOCTL jako „ograniczone” / „instrumentacja”, ale chcemy używać niektórych z nich w przypadkach użycia produkcyjnego lub odrzucić inne. Poszczególni producenci OEM i twórcy układów SoC są odpowiedzialni za podjęcie decyzji o sposobie kategoryzowania używanych przez nich wywołań IOCTL na podstawie konfiguracji bibliotek Mali w przestrzeni użytkownika. Lista ARM może pomóc w podjęciu decyzji, ale każdy przypadek użycia OEM/SoC może być inny.

Prywatność

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

Uprawnienia do sieci lokalnej

Dostęp do urządzeń w sieci LAN może uzyskać każda aplikacja, która ma uprawnienie INTERNET. Ułatwia to aplikacjom łączenie się z urządzeniami lokalnymi, ale ma też wpływ na prywatność, np. umożliwia tworzenie odcisku cyfrowego użytkownika i działa jako serwer proxy lokalizacji.

Projekt zabezpieczeń sieci lokalnej ma na celu ochronę prywatności użytkownika przez ograniczenie dostępu do sieci lokalnej za pomocą nowych uprawnień w czasie działania aplikacji.

Plan wdrażania

Ta zmiana zostanie wprowadzona między 2 wydaniami: odpowiednio 25Q2 i 26Q2. Deweloperzy muszą postępować zgodnie z tymi wskazówkami w II kwartale 2025 r. i przekazywać opinie, ponieważ te zabezpieczenia będą egzekwowane w późniejszej wersji Androida. Ponadto deweloperzy będą musieli zaktualizować scenariusze, które zależą od niejawnego dostępu do sieci lokalnej, korzystając z poniższych wskazówek, i przygotować się na odrzucenie i unieważnienie nowego uprawnienia przez użytkownika.

Wpływ

Na obecnym etapie LNP jest funkcją opcjonalną, co oznacza, że będzie ona miała wpływ tylko na aplikacje, które ją włączą. Celem fazy akceptacji jest umożliwienie deweloperom aplikacji zrozumienia, które części ich aplikacji zależą od niejawnego dostępu do sieci lokalnej, aby mogli przygotować się do zabezpieczenia ich uprawnieniami w następnej wersji.

Zmiany będą miały wpływ na aplikacje, które uzyskują dostęp do sieci lokalnej użytkownika za pomocą:

• bezpośrednie lub biblioteczne użycie nieprzetworzonych gniazd na adresach sieci lokalnej (np. protokół wykrywania usług mDNS lub SSDP);
• używanie klas na poziomie platformy, 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ą implementowane głęboko w stosie sieciowym, więc dotyczą wszystkich interfejsów API sieci. Obejmuje to gniazda utworzone w kodzie natywnym lub zarządzanym, biblioteki sieciowe takie jak Cronet i OkHttp oraz wszelkie interfejsy API zaimplementowane 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 zasad:

• 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 deweloperów (akceptacja)

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

1. Zainstaluj na urządzeniu kompilację z 25Q2 Beta 3 lub nowszą.
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

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ędzie to miało 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. 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 samo jak przed włączeniem aplikacji.

Gdy zacznie obowiązywać egzekwowanie zasad dotyczących ochrony sieci lokalnej, ruch w sieci aplikacji będzie wyglądał tak:

Aby wyłączyć flagę App-Compat, 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 wywoła ono funkcję send lub jej wariant na adres sieci lokalnej.

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 z możliwością transmisji rozgłoszeniowej, takiego jak Wi-Fi lub Ethernet, ale nie obejmuje połączeń komórkowych (WWAN) ani połączeń VPN.

Za sieci lokalne uznawane są:

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:

• Połączenie lokalne
• Trasy połączone bezpośrednio
• sieci szczątkowe, takie jak Thread;
• Wiele podsieci (do ustalenia)

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