Uprawnienia wykonawcze

W systemie Android 6.0 i nowszym model uprawnień aplikacji systemu Android 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 z wcześniej 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ą przez 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 przez okno dialogowe uprawnień środowiska wykonawczego , aby zawsze zezwolić, zezwolić podczas używania lub odmówić uprawnień. Po uaktualnieniu systemu operacyjnego do Androida 10 uprawnienia nadane aplikacjom są zachowywane, ale użytkownicy mogą przejść do Ustawień i je zmienić.

Uprawnienia w czasie wykonywania 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 żądają aplikacje lub które zostały im przyznane. Model środowiska uruchomieniowego zachęca deweloperów do pomagania użytkownikom w zrozumieniu, dlaczego aplikacje wymagają wymaganych 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 stałe lub miękkie. W obu przypadkach ograniczone uprawnienia również muszą znajdować się na białej liście. Ograniczenia twarde nieumieszczone na białej liście zachowują się inaczej niż ograniczenia miękkie nieumieszczone na białej liście:

  • ( Twarde ograniczenia ) Aplikacjom nie można przyznać uprawnień, które nie znajdują się na białej liście.
  • ( Ograniczenia miękkie ) Aplikacje bez białej listy 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 umieszczać na białej liście ograniczonych uprawnień 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ń.

Biała lista 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, aby umieścić to uprawnienie na białej liście.
  • Instalator (np. Sklep Google Play) oznacza uprawnienia jako umieszczone na białej liście.

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

Wymagania

Model uprawnień wykonawczych 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 pakietu Android Compatibility Test Suite (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 kontrolera 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 twardym ograniczeniem są umieszczane na białej liście. 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ć preinstalowane 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 preinstalowane 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 od 6,0 ​​do 9 niektóre uprawnienia są przyznawane podczas procesu instalacji. Jednak począwszy od 10, proces 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 nowszych aplikacje bezgłowe muszą korzystać z jednej z następujących metod, aby zażądać 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 i 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 Androida 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.

Uprawnienia do testowania

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