Uprawnienia czasu działania

W Androidzie 6.0 i nowszych model uprawnień aplikacji na Androida bardziej zrozumiałe, przydatne i bezpieczne dla użytkowników. Ten model przeniósł Androida aplikacje, które wymagają niebezpiecznych uprawnień (zobacz uprawnienia, których to dotyczy) z modelu uprawnień czasu instalacji do modelu uprawnień środowiska wykonawczego:

  • Uprawnienia podczas instalacji

    (Android 5.1 i starsze) Użytkownicy przyznają aplikacji niebezpieczne uprawnienia podczas jej instalowania lub aktualizowania. Urządzenie producenci i operatorzy mogą wstępnie instalować aplikacje ze wstępnie przyznanymi uprawnieniami bez powiadamiania użytkownika.

  • Uprawnienia czasu działania

    (Android 6.0 do 9) Użytkownicy przyznają aplikacji niebezpieczne uprawnienia, gdy jest ona uruchomiona. Gdy wymagane są uprawnienia (np. podczas uruchamiania aplikacji lub gdy użytkownik uzyskuje dostęp do określonego) ) zależy od aplikacji, ale użytkownik udziela/odmawia jej dostępu grupy uprawnień. OEM/operatorzy mogą wstępnie instalować aplikacje, ale nie mogą im przyznawać uprawnień, chyba że przejść przez proces wyjątku. (Patrz sekcja Tworzenie wyjątki).

    (Android 10) Użytkownicy zauważyli zwiększoną przejrzystość i kontrolować, które aplikacje mają uprawnienia czasu działania rozpoznawania aktywności (AR). Prośby użytkowników: uprawnienia w czasie działania, aby zawsze zezwalać na nie, zezwalać na używanie lub odmawiać uprawnień. Po uaktualnieniu systemu operacyjnego do Androida 10 uprawnienia przyznane aplikacjom zostaną zachowane. ale użytkownicy mogą je zmienić w Ustawieniach.

uprawnienia w czasie działania uniemożliwiają aplikacjom dostęp do prywatnych danych bez zgody użytkownika; i zapewnić im dodatkowy kontekst oraz wgląd w typy uprawnień, które które mają wnioskować albo zostały przyznane. Model środowiska wykonawczego zachęca programistów do pomaga użytkownikom zrozumieć, dlaczego aplikacje wymagają żądanych uprawnień, i daje większe możliwości przejrzystości, dzięki czemu użytkownicy mogą podejmować lepsze decyzje dotyczące przyznania lub odmowy dostępu.

Uprawnienia, których to dotyczy

Android 6.0 i nowsze wymagają niebezpiecznych uprawnień do korzystania z modelu uprawnień czasu działania. Niebezpieczne uprawnienia to uprawnienia wysokiego ryzyka (np. READ_CALENDAR), które przyznają wysyłania żądań dostępu do prywatnych danych użytkownika lub kontroli nad urządzeniem, co może negatywnie 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ą działania normalnych wersji . Są to uprawnienia, które nie są niebezpieczne, w tym uprawnienia zwykłe, i podpisów. Zwykłe uprawnienia to uprawnienia o mniejszym ryzyku (takie jak SET_WALLPAPER), które przyznają żądania dostępu aplikacji na poziomie izolowanej aplikacji funkcje przy minimalnym ryzyku dla innych aplikacji, systemu lub użytkownika. Na przykład w Androidzie 5.1 dla starszych wersji, system automatycznie przyznaje normalne uprawnienia aplikacji wysyłającej żądanie pod adresem instalacji i nie będzie prosić użytkownika o zatwierdzenie. Szczegółowe informacje o uprawnieniach znajdziesz w sekcji <permission> elementu.

Ścisłe i miękkie ograniczenia w Androidzie 10

Uprawnienia te mogą być nie tylko niebezpieczne, ale też bezwarunkowo lub wstępnie ograniczone. W obu przypadkach uprawnienie z ograniczeniami musi też znajdować się na liście dozwolonych. Niedozwolone ograniczenia sztywne działają inaczej niż pozorne, które nie znajdują się na liście dozwolonych ograniczenia:

  • (Twarde ograniczenia) Nie można przyznać aplikacjom uprawnień, które nie są znajduje się na liście dozwolonych.
  • (Ograniczenia mało restrykcyjne) Aplikacje bez umieszczenia na liście dozwolonych działają zgodnie z o konkretne uprawnienia. zachowanie jest opisane publicznie; dokumentację dotyczącą wymaganych uprawnień.

Podczas instalowania aplikacji instalator (np. Sklep Google Play) może wybrać aby nie dodać do listy dozwolonych uprawnień z ograniczeniami w przypadku aplikacji. Uprawnienia: są ograniczone przez platformę i można je przyznać tylko wtedy, gdy aplikacja spełnia specjalne kryteria zgodnie z zasadami platformy. Przykładami takich uprawnień są SMS-y. i rejestru połączeń.

Dodawanie do listy dozwolonych odbywa się podczas instalacji

  • aplikacja jest już zainstalowana podczas uaktualniania Androida do wersji 9–10.
  • uprawnienie lub aplikacja jest wstępnie zainstalowana;
  • uprawnienie jest wymagane w przypadku roli, która została już zdefiniowana do listy dozwolonych uprawnienia.
  • instalator (np. Sklep Google Play) oznaczy uprawnienie jako znajduje się na liście dozwolonych.

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

Wymagania

Model uprawnień w czasie działania dotyczy wszystkich aplikacji, w tym aplikacji zainstalowanych fabrycznie przesyłane na urządzenie w ramach procesu konfiguracji. Wymagania dotyczące oprogramowania aplikacji:

  • Model uprawnień czasu działania musi być spójny na wszystkich urządzeniach z Androidem 6.0 i wyższe. Jest to egzekwowane w ramach testów CTS (Android Compatibility Test Suite).
  • Aplikacje muszą prosić użytkowników o przyznanie uprawnień w czasie działania. Więcej informacji znajdziesz w sekcji Aktualizowanie Czasami można zrobić wyjątek dla domyślnych aplikacji i modułów obsługi które zapewniają podstawowe funkcje urządzenia niezbędne do jego oczekiwanego działania. (Na przykład domyślna aplikacja Telefon na urządzeniu do obsługi funkcji ACTION_CALL może mieć Dostęp do uprawnień telefonu). Szczegółowe informacje znajdziesz w sekcji Tworzenie wyjątków.
  • Wstępnie załadowane aplikacje z niebezpiecznymi uprawnieniami musi być kierowana na interfejs API na poziomie 23 i utrzymywać model uprawnień w czasie działania; Chodzi o przepływ interfejsu podczas instalacji aplikacji nie mogą odbiegać od implementacji AOSP PermissionController, użytkownicy mogą anulować niebezpieczne uprawnienia wstępnie zainstalowanych aplikacji itd. włącz.
  • Aplikacje bez interfejsu graficznego muszą używać aktywności, aby prosić o uprawnienia lub udostępniać Identyfikator UID innej aplikacji, która ma niezbędne uprawnienia. Więcej informacji znajdziesz w artykule Aplikacje bez interfejsu graficznego.

Migracja uprawnień

Uprawnienia przyznane aplikacjom na Androidzie 5.x pozostają przyznane po zaktualizowaniu Androida do wersji 6.0. lub wyższym, ale użytkownicy mogą je w każdej chwili anulować.

W aktualizacji Androida od 9 do 10 wszystkie uprawnienia z ograniczeniami znajduje się na liście dozwolonych. Szczegółowe informacje o implementowaniu uprawnień do podziału na pierwszym planie i w tle znajdziesz w artykule Zmiana ustawień prywatności w Androidzie 10, zaczynając od sekcji Żądanie tła lokalizacji.

Integracja

Podczas integracji modelu uprawnień czasu działania aplikacji z Androidem 6.0 lub nowszym musisz zaktualizować wstępnie zainstalowane aplikacje, aby były zgodne z nowym modelem. Możesz też określić wyjątki dla aplikacji. które są domyślnymi modułami obsługi/dostawcami głównej funkcjonalności, zdefiniować niestandardowe uprawnienia oraz dostosować motyw używany w aplikacji PermissionController.

Aktualizowanie aplikacji

Aplikacje w obrazie systemu i wstępnie zainstalowane aplikacje nie są automatycznie wstępnie przyznawane uprawnień. Zachęcamy do współpracy z deweloperami aplikacji zainstalowanych fabrycznie (OEM, operatorem aplikacji) oraz wprowadzenia wymaganych zmian za pomocą programisty wytycznych. Przede wszystkim należy się upewnić, że wstępnie zainstalowane aplikacje zostały zmodyfikowane, awarii i innych problemów, gdy użytkownicy anulują uprawnienia.

Wstępnie załadowane aplikacje

W Androidzie 9 i starszych wersjach wstępnie załadowane aplikacje, które korzystają z niebezpiecznych uprawnień, muszą być kierowane na interfejs API na poziomie 23 lub nowszym oraz zachowaj model uprawnień AOSP na Androidzie 6.0 lub nowszym. Na przykład: podczas instalacji aplikacji nie mogą odbiegać od implementacji AOSP PermissionController Użytkownicy mogą nawet odebrać niebezpieczne uprawnienia fabrycznie zainstalowanych aplikacji.

W Androidzie w wersji od 6.0 do 9 niektóre uprawnienia są przyznawane podczas instalacji. Jednak po uruchomieniu w wersji 10 proces instalacji (wykonywany przez aplikację Package Installer) jest funkcją inną niż przyznawanie uprawnień (w sekcji Permission Controller).

Aplikacje bez interfejsu graficznego

O uprawnienia mogą prosić tylko działania. Usługi nie mogą bezpośrednio prosić o uprawnienia.

  • W Androidzie 5.1 i starszych wersjach aplikacje bez interfejsu graficznego mogą prosić o uprawnienia, gdy: albo zostały zainstalowane fabrycznie i nie wymagały użycia żadnej aktywności.
  • W Aplikacje bez interfejsu graficznego na Androida 6.0 lub nowsze muszą używać jednej z tych metod, aby: poproś o uprawnienia:
    • Dodaj aktywność, aby poprosić o uprawnienia. (Jest to preferowana metoda).
    • Udostępnij identyfikator UID innej aplikacji, która ma niezbędne uprawnienia. Użyj tej tylko wtedy, gdy platforma ma obsługiwać wiele plików APK jako jeden .

Dzięki temu użytkownicy nie będą wprowadzani w błąd bez związku z prośbami o przyznanie uprawnień.

Dostosowywanie interfejsu PackageInstaller

W razie potrzeby możesz dostosować motyw interfejsu uprawnień przez aktualizowanie domyślnych motywów urządzenia (Theme.DeviceDefault.Settings) i Theme.DeviceDefault.Light.Dialog.NoActionBar) są wykorzystywane przez PackageInstaller. Spójność jest jednak kluczowa dla deweloperów aplikacji, nie można dostosować miejsca docelowego, pozycji ani reguł, które określają, kiedy uprawnienia Pojawi się interfejs.

Aby uwzględnić ciągi znaków dla dodatkowych języków, dodaj ciągi tekstowe do AOSP.

Utwórz wyjątki

Możesz wstępnie przyznać uprawnienia aplikacjom, które są domyślnymi modułami obsługi dostawców podstawowych funkcji systemu operacyjnego za pomocą DefaultPermissionGrantPolicy.java w usłudze PackageManager. Przykłady:

ACTION_CALL (Dialer) Default
Phone, Contacts, SMS, Microphone

SMS_DELIVER_ACTION (SMS/MMS) Default
Phone, Contacts, SMS

Zdefiniuj uprawnienia niestandardowe

Niestandardowe uprawnienia i grupy możesz zdefiniować jako zwykłe lub niebezpiecznych i dodać uprawnienia OEM/operatora do istniejących grup uprawnień, tak jak w Androidzie 5.x i starszych wersjach.

W Androidzie 6.0 i nowszych, jeśli dodasz nowe niebezpieczne uprawnienie, musi ono być obsługiwane w tak samo jak w przypadku innych niebezpiecznych uprawnień (żądanych w czasie działania aplikacji które użytkownicy mogą cofnąć). Więcej szczegółów:

  • Możesz dodać nowe uprawnienia do bieżącej grupy, ale nie możesz zmienić Mapowanie AOSP niebezpiecznych uprawnień i niebezpiecznych grup uprawnień. (Innymi słowy, nie można usunąć uprawnień z grupy i przypisać ich do innej grupy).
  • Możesz dodawać nowe grupy uprawnień w aplikacjach zainstalowanych na urządzeniu, Nie możesz jednak dodawać nowych grup uprawnień w pliku manifestu platformy.

Testuj uprawnienia

Android obejmuje testy Compatibility Test Suite (CTS), które weryfikują poszczególne uprawnienia są przypisane do odpowiednich grup. Zaliczenie tych testów jest wymaga zgodności z Androidem 6.0 lub nowszym z pakietem CTS.

Cofnij uprawnienia

Na Androidzie 13 i nowszych możesz anulować swoje przyznane uprawnień czasu działania za pomocą Context.revokeSelfPermissionsOnKill() Wycofywanie odbywa się asynchronicznie i jest aktywowane, gdy można to bezpiecznie zrobić bez zakłóceń. użytkownika. Odwołanie spowoduje zakończenie wszystkich procesów uruchomionych w wywołającym identyfikatorze UID.

Pamiętaj, że unieważnienie pojedynczego uprawnienia może nie zostać odzwierciedlone w interfejsu ustawień, który traktuje uprawnienia według grupy. Grupa uprawnień jest zwykle wyświetlana jako przyznanych, dopóki przyznano co najmniej jedno z uprawnień w tej grupie. Jeśli zadbasz o to, aby użytkownicy w ustawieniach mogą potwierdzić, że odwołanie jest ważne dla Ciebie, pamiętaj, aby uprawnienia w grupie uprawnień. Aby dowiedzieć się, które uprawnienia należą do określonej grupy, możesz użyj funkcji PackageManager.getGroupOfPlatformPermission i PackageManager.getPlatformPermissionsForGroup.

Gdy system anuluje żądane uprawnienia, anuluje też odpowiednie tło jeśli nie zostaną przyznane żadne z odpowiadających im uprawnień.

Odwoływanie nie jest aktywowane, dopóki proces pozostaje na pierwszym planie, ale może mogą zostać natychmiast uruchomione przez ręczne wyłączenie wszystkich procesów uruchomionych w bieżącym interfejsie UID, w instancji za pomocą interfejsu System.exit(). Zalecamy jednak, aby pozwolić systemowi na określenie, kiedy reklama ma zostać uruchomiona.

Po wycofaniu uprawnień możesz poprosić o nie ponownie, a użytkownik pojawi się prośba o udzielenie lub odrzucenie prośby. Nie można poprosić o uprawnienia, które wcześniej została wcześniej odrzucona przez użytkownika. Zachęcamy do cofnięcia tych uprawnień obecnie wstrzymane, ale nie są już potrzebne, należy uważać, aby nie informować użytkownika o do momentu wejścia w życie.