W Androidzie 6.0 i nowszych model uprawnień aplikacji został zaprojektowany tak, aby uprawnienia były bardziej zrozumiałe, przydatne i bezpieczne dla użytkowników. W ramach tego modelu aplikacje na Androida wymagające niebezpiecznych uprawnień (patrz Uprawnienia, których dotyczy zmiana) zostały przeniesione z modelu uprawnień na etapie instalacji do modelu uprawnień na etapie uruchamiania:
- Uprawnienia na czas instalacji
(Android 5.1 i starsze wersje) użytkownicy przyznają niebezpieczne uprawnienia aplikacji podczas jej instalowania lub aktualizowania. Producenci urządzeń i operatorzy mogą wstępnie instalować aplikacje z uprawnieniami przyznanymi z góry bez powiadamiania użytkownika.
- Uprawnienia czasu działania
(Android 6.0–9) Użytkownicy przyznają aplikacjom niebezpieczne uprawnienia, gdy aplikacja jest uruchomiona. Czas, w którym aplikacja prosi o uprawnienia (np. podczas uruchamiania aplikacji lub gdy użytkownik uzyskuje dostęp do konkretnej funkcji), zależy od aplikacji, ale użytkownik zezwala lub odmawia aplikacji dostępu do określonych grup uprawnień. Producenci OEM i operatorzy mogą wstępnie instalować aplikacje, ale nie mogą przyznawać uprawnień z wyprzedzeniem, chyba że przejdą proces wyjątku. (zobacz Tworzenie wyjątków).
(Android 10) Użytkownicy mają większą przejrzystość i kontrolę nad tym, które aplikacje mają uprawnienia do rozpoznawania aktywności (AR) w czasie działania. Użytkownicy są proszeni przez okno uprawnień w czasie działania aplikacji o zawsze zezwalanie, zezwalanie podczas korzystania z aplikacji lub odmowę przyznania uprawnień. Po uaktualnieniu systemu operacyjnego do Androida 10 uprawnienia przyznane aplikacjom są zachowywane, ale użytkownicy mogą je zmienić w Ustawieniach.
Uprawnienia w czasie działania uniemożliwiają aplikacjom uzyskiwanie dostępu do danych prywatnych bez zgody użytkownika. Zapewniają też użytkownikom dodatkowy kontekst i widoczność w zakresie typów uprawnień, o które aplikacje proszą lub które zostały im przyznane. Model czasu wykonywania zachęca deweloperów do informowania użytkowników, dlaczego aplikacje wymagają określonych uprawnień, oraz zapewnia większą przejrzystość, dzięki której użytkownicy mogą podejmować lepsze decyzje dotyczące przyznawania lub odmowy przyznania uprawnień.
Uprawnienia, których dotyczy problem
Android 6.0 i nowsze wymaga uprawnień niebezpiecznych, aby korzystać z modelu uprawnień w czasie wykonywania.
Uprawnienia niebezpieczne to uprawnienia o większym ryzyku (takie jak READ_CALENDAR), które umożliwiają aplikacjom dostęp do prywatnych danych użytkownika lub kontrolę nad urządzeniem, co może negatywnie wpłynąć na użytkownika. Aby wyświetlić listę niebezpiecznych uprawnień, uruchom to polecenie:
adb shell pm list permissions -g -d
Android 6.0 i nowsze nie zmieniają działania zwykłych uprawnień. Są to wszystkie niegroźne uprawnienia, w tym normalne, systemowe i uprawnienia do podpisywania. Uprawnienia normalne to uprawnienia o mniejszym ryzyku (takie jakSET_WALLPAPER), które przyznają aplikacjom dostęp do funkcji na poziomie aplikacji, ale z minimalnym ryzykiem dla innych aplikacji, systemu lub użytkownika. Podobnie jak w przypadku wersji Android 5.1 i starszych system automatycznie przyznaje normalne uprawnienia aplikacji proszącej o nie podczas instalacji i nie prosi użytkownika o pozwolenie. Szczegółowe informacje o uprawnieniach znajdziesz w dokumentacji elementu <permission>.
Ograniczenia twarde i miękkie w Androidzie 10
Uprawnienia mogą być niebezpieczne, a także podlegać ograniczeniom twardym lub miękkim. W obu przypadkach uprawnienie z ograniczeniem musi też zostać dodane do listy dozwolonych. Twarde ograniczenia dotyczące niedozwolonych treści działają inaczej niż miękkie ograniczenia dotyczące niedozwolonych treści:
- (Sztywne ograniczenia) Aplikacjom nie można przyznawać uprawnień, które nie są wymienione na liście dozwolonych.
- (Ograniczenia o łagodnym działaniu) Aplikacje bez zezwoleń działają zgodnie z uprawnieniami, o które proszą. Sposób działania jest opisany w publicznej dokumentacji dotyczącej żądanego uprawnienia.
Podczas instalowania aplikacji instalator (np. Sklep Google Play) może wybrać, aby nie zezwalać na uprawnienia ograniczone dla aplikacji. Uprawnienia są ograniczane przez platformę i mogą być przyznane tylko wtedy, gdy aplikacja spełnia specjalne kryteria zgodnie z zasadami platformy. Przykładami typów uprawnień z ostre ograniczone to uprawnienia do SMS-ów i rejestru połączeń.
Dodawanie do listy dozwolonych następuje podczas instalacji i w momencie, gdy
- podczas przejścia z Androida 9 na 10 aplikacja jest już zainstalowana.
- uprawnienie jest wstępnie przyznawane lub aplikacja jest wstępnie zainstalowana.
- uprawnienie jest wymagane w przypadku roli, która jest już zdefiniowana, aby zezwolić na uprawnienie.
- instalator (np. Sklep Google Play) oznacza uprawnienie jako dozwolone;
Użytkownicy nie mogą ręcznie dodawać uprawnień do listy dozwolonych.
Wymagania
Model uprawnień w czasie wykonywania dotyczy wszystkich aplikacji, w tym aplikacji wstępnie zainstalowanych i aplikacji dostarczonych na urządzenie w ramach procesu konfiguracji. Wymagania dotyczące oprogramowania aplikacji:
- Model uprawnień w czasie wykonywania musi być spójny na wszystkich urządzeniach z Androidem 6.0 lub nowszym. Wymaga tego pakiet testów zgodności z Androidem (Compatibility Test Suite, CTS).
- Aplikacje muszą poprosić użytkowników o przyznanie uprawnień w czasie działania. Szczegółowe informacje znajdziesz w artykule Aktualizowanie aplikacji. Ograniczone wyjątki mogą dotyczyć domyślnych aplikacji i obsług, które zapewniają podstawowe funkcje urządzenia niezbędne do jego prawidłowego działania.
(na przykład domyślna aplikacja Dialer na urządzeniu do obsługi
ACTION_CALLmoże mieć uprawnienia dostępu do telefonu). Szczegółowe informacje znajdziesz w artykule Tworzenie wyjątków. - Wstępnie zainstalowane aplikacje z uprawnieniami niebezpiecznymi muszą być kierowane na interfejs API na poziomie 23 i wykorzystywać model uprawnień w czasie wykonywania. Oznacza to, że interfejs użytkownika podczas instalacji aplikacji nie może odbiegać od implementacji interfejsu PermissionController w AOSP. Użytkownicy mogą też cofnąć niebezpieczne uprawnienia wstępnie zainstalowanych aplikacji.
- Bezgłowe aplikacje muszą używać działania, aby poprosić o uprawnienia lub udostępnić identyfikator UID innej aplikacji, która ma niezbędne uprawnienia. Szczegółowe informacje znajdziesz w artykule Aplikacje bez interfejsu użytkownika.
Migracja uprawnień
Uprawnienia przyznane aplikacjom na Androidzie 5.x pozostają ważne po aktualizacji do Androida 6.0 lub nowszego, ale użytkownicy mogą je w każdej chwili cofnąć.
W ramach aktualizacji z Androida 9 na 10 wszystkie uprawnienia z ograniczeniami twardymi zostaną dodane do listy dozwolonych. Szczegółowe informacje o wdrażaniu uprawnień podzielonych na tło i pozostawanie na pierwszym planie znajdziesz w artykule Zmiany w Androidzie 10 dotyczące prywatności, zaczynając od sekcji Wysyłanie żądania dostępu do lokalizacji w tle.
Integracja
Podczas integrowania modelu uprawnień aplikacji na czas wykonywania na Androidzie 6.0 lub nowszym musisz zaktualizować wstępnie zainstalowane aplikacje, aby działały z nowym modelem. Możesz też zdefiniować wyjątki dotyczące aplikacji, które są domyślnymi modułami obsługi lub dostawcami głównej funkcjonalności, zdefiniować uprawnienia niestandardowe i spersonalizować motyw używany w aplikacji PermissionController.
Aktualizowanie aplikacji
Aplikacje w obrazu systemu i wstępnie zainstalowane aplikacje nie mają automatycznie przyznanych uprawnień. Zachęcamy do współpracy z deweloperami wstępnie zainstalowanych aplikacji (OEM, operatorzy i firmy zewnętrzne) w celu wprowadzenia wymaganych modyfikacji aplikacji zgodnie z wytycznymi dla deweloperów. W szczególności musisz zadbać o to, aby w przypadku aplikacji wstępnie zainstalowanych w przypadku cofnięcia przez użytkowników uprawnień nie dochodziło do awarii ani innych problemów.
Wstępnie zainstalowane aplikacje
W Androidzie 9 i starszych wstępnie zainstalowane aplikacje, które używają niebezpiecznych uprawnień, muszą być kierowane na poziom interfejsu API 23 lub wyższy i stosować model uprawnień AOSP zgodny z Androidem 6.0 lub nowszym. Na przykład proces interfejsu użytkownika podczas instalacji aplikacji nie może odbiegać od implementacji AOSP w przypadku PermissionController. Użytkownicy mogą nawet cofnąć niebezpieczne uprawnienia w wstępnie zainstalowanych aplikacjach.
W Androidzie 6.0–9 niektóre uprawnienia są przyznawane podczas procesu instalacji. Jednak od Androida 10 proces instalacji (wykonany przez aplikację Package
Installer) jest oddzielną funkcją od przyznawania uprawnień (w aplikacji Permission Controller).
Aplikacje bez interfejsu
Tylko aktywności mogą prosić o uprawnienia. Usługi nie mogą bezpośrednio prosić o uprawnienia.
- W Androidzie 5.1 i starszych aplikacje bez interfejsu mogą prosić o uprawnienia podczas instalacji lub jeśli zostały wstępnie zainstalowane bez użycia aktywności.
- W Androidzie 6.0 i nowszych aplikacje bez interfejsu muszą używać jednej z tych metod do żądania uprawnień:
- Dodaj aktywność, aby poprosić o uprawnienia. (To jest preferowana metoda).
- Udostępnij identyfikator UID innej aplikacji, która ma niezbędne uprawnienia. Stosuj tę metodę tylko wtedy, gdy chcesz, aby platforma traktowała kilka plików APK jak jedną aplikację.
Celem jest unikanie wprowadzania użytkowników w błąd przez wyświetlanie próśb o uprawnienia w kontekście.
Dostosowywanie interfejsu PackageInstaller
Jeśli chcesz, możesz dostosować motyw interfejsu uprawnień, aktualizując domyślne motywy urządzenia (Theme.DeviceDefault.Settings i Theme.DeviceDefault.Light.Dialog.NoActionBar) używane przez PackageInstaller. Jednak ze względu na to, że spójność jest kluczowa dla deweloperów aplikacji, nie możesz dostosować miejsca, pozycji ani reguł wyświetlania interfejsu użytkownika uprawnień.
Aby uwzględnić ciągi tekstowe w dodatkowych językach, prześlij je do AOSP.
Tworzenie wyjątków
Za pomocą klasy DefaultPermissionGrantPolicy.java w PackageManager możesz z wyprzedzeniem przyznać uprawnienia aplikacjom, które są domyślnymi modułami obsługi lub dostawcami podstawowych funkcji systemu operacyjnego. Przykłady:
ACTION_CALL (Dialer) Default Phone, Contacts, SMS, Microphone
SMS_DELIVER_ACTION (SMS/MMS) Default Phone, Contacts, SMS
Definiowanie niestandardowych uprawnień
Możesz zdefiniować niestandardowe uprawnienia i grupy jako normalne lub niebezpieczne oraz 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, musisz je obsługiwać w taki sam sposób jak inne niebezpieczne uprawnienia (wymagane podczas działania aplikacji i możliwe do cofnięcia przez użytkowników). Więcej szczegółów:
- Możesz dodawać nowe uprawnienia do bieżącej grupy, ale nie możesz modyfikować mapowania uprawnień niebezpiecznych i grup uprawnień niebezpiecznych w AOSP. (Innymi słowy, nie możesz usunąć uprawnienia z grupy i przypisać go do innej grupy).
- Nowe grupy uprawnień możesz dodawać w aplikacji zainstalowanej na urządzeniu, ale nie możesz dodawać nowych grup uprawnień w pliku manifestu platformy.
Testowanie uprawnień
Android zawiera testy Compatibility Test Suite (CTS), które sprawdzają, czy poszczególne uprawnienia są mapowane na odpowiednie grupy. Pomyślne przejście tych testów jest wymagane w przypadku zgodności z CTS w Androidzie 6.0 i nowszych.
Odwołanie uprawnień
W Androidzie 13 i nowszych możesz cofnąć przyznane uprawnienia w czasie działania za pomocą Context.revokeSelfPermissionsOnKill().
Odwołanie odbywa się asynchronicznie i jest wywoływane, gdy można to zrobić bezpiecznie, bez zakłócania pracy użytkownika. Gdy zostanie wywołane cofnięcie uprawnień, wszystkie procesy działające w identyfikatorze UID wywołującego zostaną zakończone.
Pamiętaj, że cofnięcie uprawnienia może nie być widoczne w interfejsie ustawień, który traktuje uprawnienia grupowo. Grupa uprawnień jest zwykle wyświetlana jako przyznana, o ile co najmniej 1 uprawnienie z tej grupy jest przyznane. Jeśli zależy Ci na tym, aby użytkownicy mogli potwierdzić cofnięcie uprawnień w ustawieniach, cofnij wszystkie uprawnienia w grupie uprawnień. Aby dowiedzieć się, które uprawnienia należą do danej grupy, możesz użyć PackageManager.getGroupOfPlatformPermissioni PackageManager.getPlatformPermissionsForGroup.
Gdy system cofnie wymagane uprawnienia, cofnie również odpowiednie uprawnienia w tle, jeśli żadne z odpowiadających im uprawnień w tle nie są nadal przyznane.
Odwołanie nie jest aktywowane, dopóki proces pozostaje na pierwszym planie, ale można je również aktywować od razu, ręcznie zamykając wszystkie procesy uruchomione w bieżącym identyfikatorze użytkownika (UID), na przykład za pomocą System.exit().
Zalecamy jednak, aby system sam decydował, kiedy go uruchomić.
Gdy cofnięcie uprawnień wejdzie w życie, możesz ponownie poprosić o przyznanie uprawnień, a użytkownik zostanie poproszony o zaakceptowanie lub odrzucenie prośby. Nie można poprosić o uprawnienia, które zostały wcześniej odrzucone przez użytkownika. Zalecamy odebranie uprawnień, których obecnie nie potrzebujesz, ale które masz, ale nie informuj użytkownika o tym, dopóki nie wejdzie ono w życie.