Uprawnienia wykonawcze

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

  • Uprawnienia w czasie instalacji

    ( Android 5.1 i starsze ) Użytkownicy przyznają niebezpieczne uprawnienia do aplikacji, gdy ją instalują lub aktualizują. Producenci urządzeń i operatorzy mogą wstępnie instalować aplikacje ze wstępnie przyznanymi uprawnieniami bez powiadamiania użytkownika.

  • Uprawnienia wykonawcze

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

    ( Android 10 ) Użytkownicy widzą zwiększoną przejrzystość i mają kontrolę nad tym, które aplikacje mają uprawnienia do rozpoznawania aktywności (AR). Użytkownicy są monitowani w oknie dialogowym uprawnień czasu wykonywania , aby zawsze zezwolić, zezwolić podczas używania lub odmówić uprawnień. Po uaktualnieniu systemu operacyjnego do Androida 10 uprawnienia przyznane aplikacjom są zachowywane, ale użytkownicy mogą przejść do Ustawień i je zmienić.

Uprawnienia środowiska wykonawczego uniemożliwiają aplikacjom uzyskiwanie dostępu do prywatnych danych bez zgody użytkownika oraz zapewniają im dodatkowy kontekst i wgląd w typy uprawnień, których aplikacje oczekują lub które zostały im przyznane. Model środowiska uruchomieniowego zachęca deweloperó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 przyznawania lub odmawiania.

Uprawnienia, których dotyczy problem

Android 6.0 i nowsze wymagają niebezpiecznych uprawnień do korzystania z modelu uprawnień środowiska wykonawczego. Uprawnienia niebezpieczne to uprawnienia wyższego ryzyka (takie jak READ_CALENDAR ), które zapewniają aplikacjom żądającym dostępu do prywatnych danych użytkownika lub kontroli nad urządzeniem, co może negatywnie wpłynąć 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 uprawnienia, które nie są niebezpieczne, w tym uprawnienia normalne, systemowe i podpisu. Normalne uprawnienia to uprawnienia niższego ryzyka (takie jak SET_WALLPAPER ), które zapewniają żądającym aplikacjom dostęp do izolowanych funkcji na poziomie aplikacji przy minimalnym ryzyku dla innych aplikacji, systemu lub użytkownika. Podobnie jak w Androidzie 5.1 i niższych wersjach, system automatycznie przyznaje normalne uprawnienia żądającej aplikacji podczas instalacji i nie pyta 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ć ograniczone na twardym lub miękkim. W obu przypadkach ograniczone uprawnienia muszą być również umieszczone na liście dozwolonych. Niedozwolone ograniczenia twarde działają inaczej niż niedozwolone ograniczenia miękkie:

  • ( Twarde ograniczenia ) Aplikacjom nie można przyznać uprawnień, które nie znajdują się na liście dozwolonych.
  • ( Ograniczenia miękkie ) Aplikacje bez listy dozwolonych zachowują się zgodnie z określonymi uprawnieniami, o które proszą. Zachowanie jest opisane w dokumentacji publicznej dla żądanego pozwolenia.

Podczas instalowania aplikacji instalator (np. Sklep Google Play) może wybrać, aby nie zezwalać na wyświetlanie ograniczonych uprawnień dla aplikacji. Uprawnienia są ograniczone przez platformę i można je przyznać tylko wtedy, gdy aplikacja spełnia specjalne kryteria zgodnie z zasadami platformy. Przykłady typów uprawnień z twardym ograniczeniem obejmują uprawnienia do SMS-ów i rejestru połączeń.

Lista dozwolonych ma miejsce podczas instalacji i kiedy

  • aplikacja jest już zainstalowana podczas aktualizacji systemu Android 9 do 10.
  • zezwolenie jest wstępnie przyznane lub aplikacja jest wstępnie zainstalowana.
  • wymagane jest uprawnienie dla roli, która jest już zdefiniowana do listy dozwolonych uprawnień.
  • Instalator (np. Sklep Google Play) oznacza uprawnienia jako dozwolone.

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

Wymagania

Model uprawnień środowiska wykonawczego dotyczy wszystkich aplikacji, w tym aplikacji zainstalowanych fabrycznie oraz 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 systemem Android 6.0 lub nowszym. Jest to wymuszane przez testy zestawu testów zgodności systemu Android (CTS).
  • Aplikacje muszą prosić użytkowników o przyznanie uprawnień aplikacji w czasie wykonywania. Aby uzyskać szczegółowe informacje, zobacz Aktualizacja aplikacji . Ograniczone wyjątki mogą zostać przyznane domyślnym aplikacjom i programom obsługi, które zapewniają podstawową funkcjonalność urządzenia, podstawową dla oczekiwanego działania urządzenia. (Na przykład domyślna aplikacja Dialer urządzenia do obsługi ACTION_CALL może mieć dostęp z uprawnieniami Telefon.) Aby uzyskać szczegółowe informacje, zobacz Tworzenie wyjątków .
  • Wstępnie załadowane aplikacje, które mają niebezpieczne uprawnienia, muszą mieć poziom 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 PermissionController, użytkownicy mogą cofnąć niebezpieczne uprawnienia preinstalowanych aplikacji i tak dalej.
  • Aplikacje bezgłowe muszą użyć 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 bezgłowe .

Migracja uprawnień

Uprawnienia przyznane aplikacjom w systemie Android 5.x pozostają przyznane po aktualizacji do systemu Android 6.0 lub nowszego, ale użytkownicy mogą je w dowolnym momencie odwołać.

W aktualizacji systemu Android od 9 do 10 wszystkie uprawnienia z twardymi ograniczeniami są umieszczane na liście dozwolonych. Aby uzyskać szczegółowe informacje na temat wdrażania uprawnień dzielenia pierwszego planu/tła, zobacz Zmiana prywatności w systemie Android 10 , zaczynając od Poproś o lokalizację w tle .

Integracja

Integrując model uprawnień środowiska wykonawczego aplikacji dla systemu Android 6.0 i nowszego, należy zaktualizować wstępnie zainstalowane aplikacje, aby działały z nowym modelem. Możesz również zdefiniować wyjątki dla aplikacji, które są domyślnymi programami obsługi/dostawcami dla podstawowych funkcji, zdefiniować uprawnienia niestandardowe i dostosować motyw używany w aplikacji PermissionController .

Aktualizowanie aplikacji

Aplikacje w obrazie systemu i aplikacje zainstalowane fabrycznie nie mają automatycznie wstępnie przyznanych uprawnień. Zachęcamy do współpracy z programistami wstępnie zainstalowanych aplikacji (OEM, operatorzy i firmy zewnętrzne), aby wprowadzić wymagane modyfikacje aplikacji zgodnie ze wskazówkami dla programistów . W szczególności musisz upewnić się, że wstępnie zainstalowane aplikacje są modyfikowane, aby uniknąć awarii i innych problemów, gdy użytkownicy odwołują uprawnienia.

Wstępnie załadowane aplikacje

W systemie Android 9 i niższych wstępnie załadowane aplikacje, które korzystają z niebezpiecznych uprawnień, muszą mieć docelowy poziom interfejsu API 23 lub wyższy i utrzymywać 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 systemie Android 6.0 do 9 niektóre uprawnienia są przyznawane podczas przepływu instalacji. Jednak począwszy od 10, przepływ 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 prosić o uprawnienia.

  • W systemie Android 5.1 i wcześniejszych aplikacje bezgłowe mogą prosić o uprawnienia po zainstalowaniu lub jeśli zostały zainstalowane wstępnie bez użycia działania.
  • W systemie Android 6.0 i nowszym aplikacje bezgłowe muszą korzystać z jednej z następujących metod w celu żądania uprawnień:
    • 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 pakietów APK jako jednej aplikacji.

Celem jest uniknięcie mylenia użytkowników z prośbami o uprawnienia, które pojawiają się poza kontekstem.

Dostosowywanie interfejsu użytkownika PackageInstaller

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

Aby dołączyć ciągi dla dodatkowych języków, dodaj ciągi do AOSP.

Tworzenie wyjątków

Możesz 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 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 i dodać uprawnienia specyficzne dla OEM/przewoźnika do istniejących grup uprawnień, tak jak w przypadku systemu Android 5.x i wcześniejszych wersji.

W systemie Android 6.0 i nowszych, jeśli dodasz nowe niebezpieczne uprawnienie, należy je obsłużyć w taki sam sposób, jak inne niebezpieczne uprawnienia (wymagane w czasie wykonywania 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żesz usunąć uprawnienia z grupy i przypisać 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 na odpowiednie grupy. Przejście tych testów jest wymagane dla zgodności z systemem Android 6.0 i nowszym CTS.

Anulowanie uprawnień

W systemie Android 13 i nowszych możesz odwołać własne przyznane uprawnienia środowiska uruchomieniowego za pomocą Context.revokeSelfPermissionsOnKill() . Odwołanie odbywa się asynchronicznie i jest wyzwalane, gdy jest to bezpieczne bez zakłócania pracy użytkownika. Po wyzwoleniu odwołania wszystkie procesy działające w wywołującym UID zostaną zabite.

Ważne jest, aby zrozumieć, że odwołanie pojedynczego uprawnienia może nie być odzwierciedlone w interfejsie ustawień, który traktuje uprawnienia według grup. Zazwyczaj grupa uprawnień będzie wyświetlana jako udzielona, ​​o ile przyznane jest co najmniej jedno z uprawnień w tej grupie. Jeśli ważne jest dla Ciebie upewnienie się, że użytkownicy mogą potwierdzić cofnięcie 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 .

Gdy system cofa żądane uprawnienia, cofa również odpowiednie uprawnienia w tle, jeśli żadne z odpowiadających im uprawnień pierwszego planu nie jest nadal 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 identyfikatorze użytkownika, na przykład za pomocą System.exit() . Jednak zaleca się, aby system zdecydował, kiedy go uruchomić.

Po skutecznym cofnięciu uprawnień możesz poprosić o to ponownie, a użytkownik zostanie poproszony o przyznanie lub odrzucenie żądania. Nie można poprosić o zezwolenie, które zostało wcześniej odrzucone przez użytkownika. Chociaż zachęcamy do cofnięcia uprawnień, które obecnie posiadasz, ale nie są już potrzebne, należy uważać, aby nie informować użytkownika o odwołaniu, dopóki nie zostanie ono skuteczne.