Permission Group w Android — co to jest, grupy uprawnień i zasada działania

Co to jest Permission Group w Android

Permission Group — to systemowy mechanizm Android, który łączy kilka niebezpiecznych uprawnień w jedną grupę na podstawie ich przeznaczenia funkcjonalnego. Każda grupa ma identyfikator ciągu znaków, na przykład android.permission-group.CAMERA lub android.permission-group.LOCATION. Wszystkie uprawnienia w obrębie jednej grupy są logicznie powiązane i zapewniają dostęp do pokrewnych funkcji urządzenia.

Grupy uprawnień pojawiły się w Android 6.0 Marshmallow wraz z modelem zapytań w czasie wykonywania. Ich głównym celem jest uproszczenie interakcji z użytkownikiem: zamiast serii okien dialogowych dla każdego pojedynczego uprawnienia, system wyświetla jedno okno dialogowe na grupę. Jeśli użytkownik udzielił jednego uprawnienia z grupy, pozostałe są uznawane za automatycznie zatwierdzone. Według Android UX Research (2015) zmniejszyło to liczbę odmów przy pierwszym uruchomieniu o 20 procent.

Ważne jest, aby zrozumieć, że programista nie może tworzyć własnych Permission Group. Grupy są predefiniowane na poziomie systemu operacyjnego i opisane w plikach permissions.xml na każdym urządzeniu. Aplikacja jedynie określa uses-permission, a system automatycznie dopasowuje uprawnienie do jego grupy na podstawie protectionLevel i kategoryzacji w AOSP.

Jak system określa grupę

Dopasowanie uprawnienia do grupy odbywa się poprzez atrybut permissionGroup w systemowej definicji uprawnienia. Na przykład CAMERA jest zadeklarowany z permissionGroup="android.permission-group.CAMERA", ACCESS_FINE_LOCATION — z permissionGroup="android.permission-group.LOCATION". To mapowanie jest sztywno określone w kodzie Android Open Source Project i jest takie samo na wszystkich certyfikowanych urządzeniach.

Jak działają Permission Group

Mechanizm grup działa na zasadzie „jedno okno dialogowe na grupę”. Gdy aplikacja po raz pierwszy żąda jakiegokolwiek niebezpiecznego uprawnienia, system sprawdza jego Permission Group. Jeśli żadne uprawnienie z tej grupy nie zostało jeszcze udzielone — wyświetlane jest okno dialogowe. Po wyrażeniu zgody system oznacza całą grupę jako udzieloną, a kolejne żądania innych uprawnień z tej samej grupy są realizowane bez interfejsu użytkownika.

Algorytm w uproszczeniu wygląda następująco:

• Aplikacja wywołuje requestPermissions dla ACCESS_FINE_LOCATION
• System określa grupę — android.permission-group.LOCATION
• Sprawdza, czy grupa LOCATION została już udzielona
• Jeśli nie — wyświetla okno dialogowe z nazwą grupy i listą wchodzących w skład uprawnień
• Po Allow — cała grupa LOCATION jest uznawana za udzieloną
• ACCESS_COARSE_LOCATION jest teraz dostępny bez dodatkowego żądania

Ten mechanizm dotyczy tylko niebezpiecznych uprawnień. Normalne uprawnienia nie mają grup i nie uczestniczą w tej logice. Uprawnienia uprzywilejowane i podpisane również nie są grupowane — mają osobny system zarządzania dostępem.

Ograniczenia logiki grupowej

Grupy nie działają „w drugą stronę”: cofnięcie jednego uprawnienia z grupy przez ustawienia cofa tylko je, nie wpływając na pozostałe. Również jeśli użytkownik odrzucił okno dialogowe dla grupy, nie blokuje to innych grup — każde nowe uprawnienie z innej grupy wyświetli własne okno dialogowe. Permission Group wpływa tylko na UX żądania, nie na model bezpieczeństwa.

Lista Permission Group w Android

Android określa następujące systemowe Permission Group dla niebezpiecznych uprawnień. Każda grupa zawiera jedno lub więcej uprawnień połączonych wspólnym przeznaczeniem funkcjonalnym.

Zmiany w nowych wersjach

W Android 13 (API 33) pojawiła się nowa grupa NEARBY_DEVICES, łącząca BLUETOOTH_SCAN, BLUETOOTH_CONNECT i BLUETOOTH_ADVERTISE. Również grupa STORAGE została częściowo zastąpiona uprawnieniami medialnymi READ_MEDIA_IMAGES, READ_MEDIA_VIDEO i READ_MEDIA_AUDIO, które nie wchodzą w skład STORAGE, ale są samodzielnymi niebezpiecznymi uprawnieniami bez grupowania.

Grupy dla niestandardowych uprawnień

Programiści mogą deklarować własne uprawnienia z niestandardowymi Permission Group poprzez atrybut permissionGroup w manifeście. Działa to jednak tylko dla niestandardowych uprawnień tej samej aplikacji i nie wpływa na systemowe okna dialogowe. W praktyce niestandardowe Permission Group są używane rzadko — do interakcji między własnymi aplikacjami w jednym stosie.

Permission Group a UX

Wpływ Permission Group na doświadczenie użytkownika jest znaczący. Dzięki grupowaniu użytkownik widzi nie 8 osobnych okien dialogowych dla różnych uprawnień, ale kilka grupowych okien dialogowych. Zmniejsza to obciążenie poznawcze i zmniejsza prawdopodobieństwo, że użytkownik odrzuci krytyczne uprawnienie, nie rozumiejąc jego przeznaczenia.

Badania UX pokazują, że grupowe okna dialogowe są postrzegane przez użytkowników jako bardziej przejrzyste. Gdy aplikacja żąda „dostępu do aparatu”, użytkownik rozumie kontekst. Gdyby każde uprawnienie było żądane oddzielnie — CAMERA, CAMERA2, FLASHLIGHT — stworzyłoby to wrażenie nadmiarowości. Permission Group abstrahuje tę szczegółowość.

Najlepszą praktyką jest żądanie uprawnień tylko z jednej grupy na raz. Jeśli aplikacja potrzebuje dostępu i do aparatu, i do geolokalizacji, nie należy żądać ich jednym wywołaniem requestPermissions. Najpierw poproś o jedną grupę po wyjaśnieniu, do czego jest potrzebna, a następnie o drugą. Daje to użytkownikowi kontrolę i sekwencyjne zrozumienie każdej funkcji.

Permission Group vs ProtectionLevel

Permission Group i ProtectionLevel — to dwa różne wymiary systemu uprawnień Android. ProtectionLevel określa, w jaki sposób uprawnienie jest przyznawane (normal, dangerous, signature, privileged), a Permission Group to kategoria do wyświetlania w interfejsie użytkownika. Są niezależne, ale w praktyce kombinacja dangerous + permission group występuje najczęściej.

Uprawnienia tego samego ProtectionLevel mogą należeć do różnych grup. Na przykład ACCESS_FINE_LOCATION i CAMERA oba mają protectionLevel dangerous, ale należą do różnych grup — LOCATION i CAMERA. I odwrotnie, uprawnienia o tej samej nazwie zawsze należą do jednej grupy: ACCESS_FINE_LOCATION i ACCESS_COARSE_LOCATION obie w LOCATION.

Poziomy ochrony wyższego rzędu — signature i privileged — nie używają Permission Group dla interfejsu użytkownika. Ich przyznawanie jest kontrolowane na poziomie systemu: signature jest przyznawane aplikacjom podpisanym tym samym certyfikatem co system, a privileged — aplikacjom w obrazie systemowym. Grupy dla takich uprawnień istnieją, ale nie wpływają na okna dialogowe UX, ponieważ takich okien po prostu nie ma.

Sprawdzanie Permission Group w kodzie

Programista może programowo określić Permission Group dowolnego uprawnienia za pomocą PackageManager. Metoda getPermissionInfo zwraca PermissionInfo z polem group zawierającym identyfikator ciągu znaków grupy. Jest to przydatne do logowania, analityki i niestandardowych ekranów uprawnień w interfejsie użytkownika.

fun getPermissionGroupName(
    permission: String
): String? {
    return try {
        val pm = packageManager
        val info = pm.getPermissionInfo(
            permission,
            PackageManager.GET_META_DATA
        )
        info.group
    } catch (e: NameNotFoundException) {
        null
    }
}

fun getPermissionsByGroup(
    group: String
): List<String> {
    val pm = packageManager
    val perms = pm.queryPermissionsByGroup(
        group,
        PackageManager.GET_META_DATA
    )
    return perms.map { it.name }
}

Użycie w DI i architekturze

Znajomość Permission Group pomaga budować architekturę zapytań. Można stworzyć abstrakcję PermissionGroupProvider, która zwraca listę uprawnień dla konkretnej grupy. Upraszcza to testowanie: w testach jednostkowych provider zwraca fikcyjne dane bez odwoływania się do PackageManager. W testach instrumentalnych — rzeczywiste grupy z systemu.

PermissionGroupProvider w DI

Integracja PermissionGroupProvider poprzez Dagger Hilt lub Koin pozwala centralnie zarządzać mapowaniem uprawnień i grup. W providerze można zapisać w pamięci podręcznej wynik PackageManager.queryPermissionsByGroup, aby nie wykonywać powtarzalnych wywołań systemowych przy każdym żądaniu. Jest to szczególnie ważne dla ekranów ustawień, na których wyświetlana jest pełna lista uprawnień i ich status.

Logowanie i analityka

Podczas zbierania analityki dotyczącej odmów warto logować nie tylko nazwę uprawnienia, ale także jego Permission Group. Pozwala to zidentyfikować, które obszary funkcjonalne powodują najwięcej odmów. Na przykład grupa LOCATION tradycyjnie ma najwyższy procent odmów — około 40 procent, według statystyk Google Play Console.

Analityka według grup pomaga podejmować decyzje produktowe: jeśli grupa CONTACTS ma wysoki procent odmów, warto rozważyć zmianę momentu żądania lub dodanie okna dialogowego z uzasadnieniem. Podejście grupowe do analityki daje pełniejszy obraz niż analiza poszczególnych uprawnień, ponieważ liczba odmów dla całej grupy odzwierciedla ogólny stosunek użytkowników do obszaru funkcjonalnego.