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 (poziom API 35), ale Twoja aplikacja może z tego zrezygnować, ustawiając wartość R.attr#windowOptOutEdgeToEdgeEnforcement na true. W przypadku aplikacji kierowanych na Androida 16 (poziom interfejsu API 36) interfejs R.attr#windowOptOutEdgeToEdgeEnforcement został wycofany i wyłączony, a Twoja 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, R.attr#windowOptOutEdgeToEdgeEnforcementnadal działa.
• Jeśli Twoja aplikacja jest kierowana na Androida 16 (poziom API 36) i działa na urządzeniu z Androidem 16, R.attr#windowOptOutEdgeToEdgeEnforcement jest wyłączona.

Aby przetestować Androida 16 w wersji beta 3, sprawdź, czy Twoja aplikacja obsługuje wyświetlacz od krawędzi do krawędzi, i usuń wszelkie odwołania do R.attr#windowOptOutEdgeToEdgeEnforcement, aby aplikacja obsługiwała też wyświetlacz od krawędzi do krawędzi na urządzeniu z Androidem 15. Aby obsługiwać krawędzie, zapoznaj się z informacjami w sekcji Kompozycja i Widok.

Wymagane przeprowadzenie migracji lub rezygnacja z funkcji przewidywania wstecz.

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

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

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

Aplikacje kierowane na Androida 15 (poziom API 35) mają atrybut elegantTextHeight TextView ustawiony domyślnie na true, co zastępuje czcionkę kompaktową czcionką znacznie łatwiejszą do odczytania. Możesz to zmienić, ustawiając atrybut elegantTextHeight na false.

W Androidzie 16 atrybut elegantTextHeight jest przestarzały. Gdy Twoja aplikacja będzie kierowana na Androida 16, atrybut ten zostanie zignorowany. Czcionki interfejsu kontrolowane przez te interfejsy API zostaną wycofane, dlatego należy dostosować wszelkie układy, aby zapewnić spójne i przyszłe renderowanie tekstu w języku arabskim, laotam, tamilskim, gudżarati, kannada, malajalam, orija, 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

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), Android 16 includes changes to how the system manages orientation, resizability, and aspect ratio restrictions. On displays with smallest width >= 600dp, the restrictions no longer apply. Apps also 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, so we recommend making 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 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

For apps targeting Android 16 or higher, MediaStore#getVersion() will now be unique to each app. This eliminates identifying properties from the version string to prevent abuse and usage for fingerprinting techniques. Apps shouldn't make any assumptions around the format of this version. Apps should already handle version changes when using this API and in most cases shouldn't need to change their current behavior, unless the developer has attempted to infer additional information that is beyond the intended scope of this 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.