Uprawnienia w czasie działania aplikacji

W systemie Android 6.0 i nowszych model uprawnień aplikacji Android został zaprojektowany tak, aby uprawnienia były bardziej zrozumiałe, przydatne i bezpieczne dla użytkowników. Model przeniósł aplikacje na Androida wymagające niebezpiecznych uprawnień (zobacz Uprawnienia, których to dotyczy ) z modelu uprawnień w czasie instalacji do modelu uprawnień w czasie wykonywania :

  • Uprawnienia w czasie instalacji

    ( Android 5.1 i starsze wersje ) Użytkownicy przyznają aplikacji niebezpieczne uprawnienia podczas jej instalowania lub aktualizowania. Producenci urządzeń i operatorzy mogą preinstalować aplikacje ze wstępnie przyznanymi uprawnieniami bez powiadamiania użytkownika.

  • Uprawnienia wykonawcze

    ( Android 6.0 – 9 ) Użytkownicy udzielają aplikacji niebezpiecznych uprawnień, gdy jest ona uruchomiona. To, kiedy żądane są uprawnienia (na przykład podczas uruchamiania aplikacji lub gdy użytkownik uzyskuje dostęp do określonej funkcji) zależy od aplikacji, ale użytkownik przyznaje/odmawia dostępu aplikacji do określonych grup uprawnień. Producenci OEM/przewoźnicy mogą wstępnie instalować aplikacje, ale nie mogą wstępnie przyznawać uprawnień, chyba że przejdą przez proces wyjątku. (Zobacz Tworzenie wyjątków .)

    ( Android 10 ) Użytkownicy widzą większą przejrzystość i mają kontrolę nad tym, które aplikacje mają uprawnienia wykonawcze do rozpoznawania aktywności (AR). W oknie dialogowym uprawnień środowiska wykonawczego użytkownicy są proszeni o określenie: zawsze zezwalaj, zezwalaj podczas używania lub odmawiaj uprawnień. Po uaktualnieniu systemu operacyjnego do Androida 10 uprawnienia nadane aplikacjom zostaną zachowane, ale użytkownicy będą mogli przejść do Ustawień i je zmienić.

Uprawnienia środowiska wykonawczego uniemożliwiają aplikacjom uzyskiwanie dostępu do prywatnych danych bez zgody użytkownika i zapewniają im dodatkowy kontekst i wgląd w typy uprawnień, których aplikacje szukają lub które zostały przyznane. Model środowiska wykonawczego zachęca programistów do pomagania użytkownikom w zrozumieniu, dlaczego aplikacje wymagają żądanych uprawnień, i zapewnia większą przejrzystość, dzięki czemu użytkownicy mogą podejmować lepsze decyzje dotyczące ich przyznania lub odmowy.

Dotknięte uprawnienia

Android 6.0 i nowsze wymagają niebezpiecznych uprawnień, aby móc korzystać z modelu uprawnień wykonawczych. Niebezpieczne uprawnienia to uprawnienia wyższego ryzyka (takie jak READ_CALENDAR ), które przyznają żądającym aplikacjom dostęp do prywatnych danych użytkownika lub kontrolę nad urządzeniem, co może mieć negatywny wpływ na użytkownika. Aby wyświetlić listę niebezpiecznych uprawnień, uruchom polecenie:

adb shell pm list permissions -g -d

Android 6.0 i nowsze nie zmieniają zachowania normalnych uprawnień . Są to wszystkie nieszkodliwe uprawnienia, w tym uprawnienia normalne, systemowe i uprawnienia do podpisu. Normalne uprawnienia to uprawnienia niższego ryzyka (takie jak SET_WALLPAPER ), które przyznają żądającym aplikacjom dostęp do izolowanych funkcji na poziomie aplikacji przy minimalnym ryzyku dla innych aplikacji, systemu lub użytkownika. Podobnie jak w przypadku Androida 5.1 i wcześniejszych wersji, system automatycznie przyznaje normalne uprawnienia żądającej aplikacji podczas instalacji i nie prosi użytkownika o zatwierdzenie. Szczegółowe informacje na temat uprawnień można znaleźć w dokumentacji elementu <permission> .

Twarde i miękkie ograniczenia w Androidzie 10

Oprócz tego, że jest niebezpieczne, pozwolenie może być albo twarde, albo miękkie. W obu przypadkach ograniczone uprawnienia również muszą znajdować się na liście dozwolonych. Twarde ograniczenia nie znajdujące się na liście dozwolonych zachowują się inaczej niż miękkie ograniczenia nie znajdujące się na liście dozwolonych:

  • ( Twarde ograniczenia ) Nie można przyznać uprawnień aplikacjom, które nie znajdują się na liście dozwolonych.
  • ( Miękkie ograniczenia ) Aplikacje bez listy dozwolonych zachowują się zgodnie z konkretnym zezwoleniem, o które proszą. Zachowanie jest opisane w dokumentacji publicznej dotyczącej żądanego pozwolenia.

Podczas instalowania aplikacji instalator (np. Sklep Google Play) może nie umieszczać na liście dozwolonych ograniczonych uprawnień aplikacji. Uprawnienia są ograniczone przez platformę i można je przyznać tylko wtedy, gdy aplikacja spełnia specjalne kryteria określone w zasadach platformy. Przykładami typów uprawnień z twardymi ograniczeniami są uprawnienia do SMS-ów i rejestru połączeń.

Umieszczenie na liście dozwolonych następuje podczas instalacji i kiedy

  • aplikacja jest już zainstalowana podczas aktualizacji Androida 9 do 10.
  • zezwolenie zostało wstępnie przyznane lub aplikacja została preinstalowana.
  • wymagane jest uprawnienie dla roli, która jest już zdefiniowana na liście dozwolonych.
  • instalator (taki jak Sklep Google Play) oznacza uprawnienie jako listę dozwolonych.

Użytkownicy nie mogą ręcznie dodawać uprawnień do listy dozwolonych.

Wymagania

Model uprawnień wykonawczych dotyczy wszystkich aplikacji, w tym aplikacji preinstalowanych i aplikacji dostarczanych na urządzenie w ramach procesu konfiguracji. Wymagania dotyczące oprogramowania aplikacyjnego obejmują:

  • Model uprawnień środowiska wykonawczego musi być spójny na wszystkich urządzeniach z Androidem 6.0 i nowszym. Jest to wymuszane przez testy pakietu testów zgodności systemu Android (CTS).
  • Aplikacje muszą monitować użytkowników o przyznanie uprawnień aplikacji w czasie wykonywania. Aby uzyskać szczegółowe informacje, zobacz Aktualizowanie aplikacji . Można przyznać ograniczone wyjątki domyślnym aplikacjom i programom obsługi, które zapewniają podstawową funkcjonalność urządzenia, fundamentalną dla oczekiwanego działania urządzenia. (Na przykład domyślna aplikacja Dialer na urządzeniu do obsługi ACTION_CALL może mieć dostęp do uprawnień Telefonu). Aby uzyskać szczegółowe informacje, zobacz Tworzenie wyjątków .
  • Wstępnie załadowane aplikacje, które mają niebezpieczne uprawnienia, muszą być kierowane na poziom interfejsu API 23 i utrzymywać model uprawnień środowiska wykonawczego. Oznacza to, że przepływ interfejsu użytkownika podczas instalacji aplikacji nie może odbiegać od implementacji AOSP elementu PermissionController, użytkownicy mogą odwołać niebezpieczne uprawnienia wstępnie zainstalowanych aplikacji i tak dalej.
  • Aplikacje bezgłowe muszą korzystać z działania, aby zażądać uprawnień lub udostępnić identyfikator UID innej aplikacji, która ma niezbędne uprawnienia. Aby uzyskać szczegółowe informacje, zobacz Aplikacje bezobsługowe .

Migracja uprawnień

Uprawnienia przyznane aplikacjom na Androidzie 5.x pozostają przyznane po aktualizacji do Androida 6.0 lub nowszego, ale użytkownicy mogą w dowolnym momencie odwołać te uprawnienia.

W aktualizacji Androida 9 do 10 wszystkie uprawnienia z twardymi ograniczeniami zostaną umieszczone na liście dozwolonych. Aby uzyskać szczegółowe informacje na temat wdrażania uprawnień podziału pierwszego planu na tło, zobacz temat Zmiana prywatności w systemie Android 10 , zaczynając od sekcji Żądaj lokalizacji w tle .

Integracja

Integrując model uprawnień wykonawczych aplikacji dla systemu Android 6.0 i nowszych wersji, należy zaktualizować preinstalowane aplikacje, aby działały z nowym modelem. Możesz także zdefiniować wyjątki dla aplikacji, które są domyślnymi programami obsługi/dostawcami podstawowych funkcji, zdefiniować uprawnienia niestandardowe i dostosować motyw używany w aplikacji PermissionController .

Aktualizowanie aplikacji

Aplikacje znajdujące się w obrazie systemu i aplikacje preinstalowane nie mają automatycznie przyznanych uprawnień. Zachęcamy do współpracy z twórcami preinstalowanych aplikacji (OEM, operatorzy i strony trzecie) w celu wprowadzenia wymaganych modyfikacji aplikacji zgodnie z wytycznymi dla programistów . W szczególności należy upewnić się, że preinstalowane aplikacje zostały zmodyfikowane, aby uniknąć awarii i innych problemów, gdy użytkownicy cofają uprawnienia.

Wstępnie załadowane aplikacje

W systemie Android 9 i starszych aplikacjach wstępnie załadowanych, które korzystają z niebezpiecznych uprawnień, muszą być kierowane na poziom interfejsu API 23 lub wyższy i obsługiwać model uprawnień AOSP w systemie Android 6.0 lub nowszym. Na przykład przepływ interfejsu użytkownika podczas instalacji aplikacji nie może odbiegać od implementacji AOSP PermissionController . Użytkownicy mogą nawet cofnąć niebezpieczne uprawnienia preinstalowanych aplikacji.

W Androidzie od 6.0 do 9 niektóre uprawnienia są przyznawane podczas instalacji. Jednak począwszy od wersji 10, przebieg instalacji (wykonywany przez aplikację Package Installer ) jest funkcją odrębną od przyznawania uprawnień (w aplikacji Permission Controller ).

Aplikacje bezgłowe

Tylko działania mogą prosić o uprawnienia. Usługi nie mogą bezpośrednio żądać uprawnień.

  • W systemie Android 5.1 i wcześniejszych aplikacjach bezgłowych może żądać uprawnień po zainstalowaniu lub jeśli zostały preinstalowane bez użycia działania.
  • W systemie Android 6.0 i nowszych aplikacjach bezgłowych musi używać jednej z następujących metod, aby poprosić o uprawnienia:
    • Dodaj działanie, aby poprosić o uprawnienia. (Jest to preferowana metoda.)
    • Udostępnij identyfikator UID innej aplikacji, która ma niezbędne uprawnienia. Użyj tej metody tylko wtedy, gdy potrzebujesz platformy do obsługi wielu plików APK w ramach jednej aplikacji.

Celem jest uniknięcie dezorientowania użytkowników prośbami o pozwolenie, które pojawiają się wyrwane z kontekstu.

Dostosowywanie interfejsu użytkownika PackageInstaller

W razie potrzeby możesz dostosować motyw interfejsu użytkownika uprawnień, aktualizując domyślne motywy urządzeń ( Theme.DeviceDefault.Settings i Theme.DeviceDefault.Light.Dialog.NoActionBar ) używane przez PackageInstaller. Ponieważ jednak spójność ma kluczowe znaczenie dla twórców aplikacji, nie można dostosować rozmieszczenia, pozycji ani reguł wyświetlania interfejsu użytkownika uprawnień.

Aby dołączyć ciągi znaków dla dodatkowych języków, prześlij je do AOSP.

Tworzenie wyjątków

Można wstępnie udzielić uprawnień aplikacjom, które są domyślnymi programami obsługi lub dostawcami podstawowych funkcji systemu operacyjnego, korzystając z klasy DefaultPermissionGrantPolicy.java w menedżerze pakietów PackageManager. Przykłady:

ACTION_CALL (Dialer) Default
Phone, Contacts, SMS, Microphone
SMS_DELIVER_ACTION (SMS/MMS) Default
Phone, Contacts, SMS

Definiowanie uprawnień niestandardowych

Możesz zdefiniować niestandardowe uprawnienia i grupy jako normalne lub niebezpieczne oraz dodać uprawnienia specyficzne dla OEM/operatora do istniejących grup uprawnień, tak jak było to możliwe w systemie Android 5.x i wcześniejszych wersjach.

Jeśli w systemie Android 6.0 i nowszych wersjach dodasz nowe niebezpieczne uprawnienia, należy je traktować w taki sam sposób, jak inne niebezpieczne uprawnienia (wymagane w czasie działania aplikacji i możliwe do odwołania przez użytkowników). Konkretnie:

  • Możesz dodać nowe uprawnienia do bieżącej grupy, ale nie możesz modyfikować mapowania AOSP niebezpiecznych uprawnień i niebezpiecznych grup uprawnień. (Innymi słowy, nie można usunąć uprawnienia z grupy i przypisać go do innej grupy).
  • Możesz dodawać nowe grupy uprawnień w aplikacjach zainstalowanych na urządzeniu, ale nie możesz dodawać nowych grup uprawnień w manifeście platformy.

Testowanie uprawnień

Android zawiera testy Compatibility Test Suite (CTS), które sprawdzają, czy poszczególne uprawnienia są mapowane do odpowiednich grup. Zaliczenie tych testów jest warunkiem zgodności z systemem Android 6.0 i nowszymi wersjami CTS.

Cofanie uprawnień

W systemie Android 13 i nowszych wersjach możesz odwołać własne przyznane uprawnienia wykonawcze za pomocą Context.revokeSelfPermissionsOnKill() . Odwołanie następuje asynchronicznie i jest wyzwalane, gdy można to bezpiecznie zrobić, nie zakłócając pracy użytkownika. Po wyzwoleniu odwołania wszystkie procesy działające w wywołującym UID zostaną zabite.

Należy pamiętać, że cofnięcie pojedynczego uprawnienia może nie zostać odzwierciedlone w interfejsie ustawień, który traktuje uprawnienia według grup. Zazwyczaj grupa uprawnień będzie wyświetlana jako przyznana, jeśli co najmniej jedno z uprawnień w tej grupie zostanie przyznane. Jeśli ważne jest dla Ciebie zapewnienie użytkownikom możliwości potwierdzenia odwołania w ustawieniach, pamiętaj o cofnięciu wszystkich uprawnień w grupie uprawnień. Aby dowiedzieć się, które uprawnienia należą do określonej grupy, możesz użyć PackageManager.getGroupOfPlatformPermission i PackageManager.getPlatformPermissionsForGroup .

Kiedy system odwołuje żądane uprawnienia, odwołuje także odpowiednie uprawnienia w tle, jeśli żadne z odpowiadających im uprawnień na pierwszym planie nie zostało jeszcze przyznane.

Odwołanie nie zostanie wywołane, dopóki proces pozostanie na pierwszym planie, ale można je również wywołać od razu, ręcznie zabijając wszystkie procesy działające w bieżącym uid, na przykład za pomocą System.exit() . Zaleca się jednak, aby system sam zdecydował, kiedy ma zostać uruchomiony.

Gdy cofnięcie pozwolenia stanie się skuteczne, możesz zażądać go ponownie, a użytkownik zostanie poproszony o zaakceptowanie lub odrzucenie żądania. Nie ma możliwości zażądania zgody, której użytkownik wcześniej odmówił. Chociaż zachęcamy do cofnięcia uprawnień, które aktualnie posiadasz, ale nie są już potrzebne, powinieneś uważać, aby nie poinformować użytkownika o cofnięciu, dopóki nie zacznie ono obowiązywać.