Runtime Permission: istota, rodzaje i zasada działania w Androidzie

Co to jest Runtime Permission?

Runtime Permission (uprawnienie czasu wykonania) — to model bezpieczeństwa Android, w którym aplikacja żąda dostępu do poufnych danych w momencie, gdy ta funkcjonalność jest rzeczywiście potrzebna użytkownikowi. Przed Android 6.0 wszystkie uprawnienia były udzielane podczas instalacji aplikacji, a użytkownik nie mógł ich cofnąć bez całkowitego usunięcia aplikacji.

Ewolucja modelu uprawnień Android

Przed Android 6.0 użytkownik widział listę wszystkich uprawnień podczas instalacji i mógł albo zaakceptować wszystkie, albo zrezygnować z instalacji. Badanie z 2015 roku wykazało, że 87% użytkowników nie czyta listy uprawnień podczas instalacji. Android 6.0 wprowadził runtime permissions, dzieląc uprawnienia na normal (automatyczne) i dangerous (z żądaniem). Android 11 dodał one-time permissions — automatyczne cofanie po zamknięciu aplikacji. Android 13 wprowadził Photo Picker i powiadomienia push jako osobne runtime permissions.

iOS używa podobnego modelu od wersji iOS 10, gdzie dostęp do kamery, mikrofonu i geolokalizacji jest żądany przy pierwszym użyciu. Jednak iOS nie ma pojęcia „normal permissions“ — każde uprawnienie jest żądane jawnie, a odmowa jest zapisywana do czasu ponownego żądania przez programistę poprzez ustawienia systemowe.

Jak działa Runtime Permission w Androidzie?

Runtime Permission działa przez systemowe okno dialogowe wywoływane metodą requestPermissions() (AndroidX — ActivityResultLauncher). System wyświetla standardowe okno dialogowe z wyjaśnieniem, a użytkownik wybiera „Zezwól“ lub „Zabroń“. Po odpowiedzi wywoływane jest callback wyniku, w którym aplikacja obsługuje decyzję użytkownika.

Źądanie uprawnienia przez ActivityResultLauncher

private lateinit var requestPermissionLauncher: ActivityResultLauncher<String>

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)

    requestPermissionLauncher =
        registerForActivityResult(ActivityResultContracts.RequestPermission()) { isGranted ->
            if (isGranted) {
                startCamera()
            } else {
                showPermissionDeniedDialog()
            }
        }
}

private fun checkCameraPermission() {
    when {
        ContextCompat.checkSelfPermission(this, Manifest.permission.CAMERA)
                == PackageManager.PERMISSION_GRANTED -> {
            startCamera()
        }
        ActivityCompat.shouldShowRequestPermissionRationale(this, Manifest.permission.CAMERA) -> {
            showRationaleDialog { requestPermissionLauncher.launch(Manifest.permission.CAMERA) }
        }
        else -> {
            requestPermissionLauncher.launch(Manifest.permission.CAMERA)
        }
    }
}

Metoda shouldShowRequestPermissionRationale zwraca true, jeśli użytkownik już raz odrzucił żądanie. W tym przypadku zaleca się pokazanie okna dialogowego z wyjaśnieniem, dlaczego aplikacja potrzebuje uprawnienia, a dopiero potem ponowne żądanie. Zwiększa to prawdopodobieństwo zgody użytkownika o 30–40% (dane Google I/O 2024).

Rodzaje uprawnień w Androidzie

Android klasyfikuje wszystkie uprawnienia na kilka poziomów ochrony: normal, dangerous, signature i special. Normal permissions są udzielane automatycznie podczas instalacji. Dangerous permissions wymagają żądania runtime. Signature permissions są dostępne tylko dla aplikacji podpisanych tym samym certyfikatem.

Grupy niebezpiecznych uprawnień

Special permissions (SYSTEM_ALERT_WINDOW, WRITE_SETTINGS, MANAGE_EXTERNAL_STORAGE) wymagają dodatkowego przejścia do ustawień systemowych przez Settings.ACTION_MANAGE_OVERLAY_PERMISSION. Te uprawnienia nie mogą być żądane standardowym oknem dialogowym i wymagają wyraźnego przejścia użytkownika do ekranu ustawień.

Źądanie uprawnień w Android 12+

Android 12 wprowadził znaczące zmiany w modelu runtime permissions. One-time permissions pozwalają udzielić dostępu do kamery, mikrofonu lub geolokalizacji tylko na jedną sesję. Gdy użytkownik zamknie aplikację, uprawnienie jest automatycznie cofane. Privacy indicators — zielone wskaźniki na pasku stanu pokazujące, kiedy aplikacja używa kamery lub mikrofonu.

Obsługa uprawnień jednorazowych

// Android 12+ — obsługa jednorazowego uprawnienia geolokalizacji
private fun checkLocationPermission() {
    val permissionLauncher =
        registerForActivityResult(ActivityResultContracts.RequestMultiplePermissions()) { permissions ->

        val fineLocationGranted = permissions[Manifest.permission.ACCESS_FINE_LOCATION]
        val coarseLocationGranted = permissions[Manifest.permission.ACCESS_COARSE_LOCATION]

        if (fineLocationGranted == true) {
            showUserLocation()
        } else {
            showLocationDisabledDialog()
        }
    }

    permissionLauncher.launch(
        arrayOf(
            Manifest.permission.ACCESS_FINE_LOCATION,
            Manifest.permission.ACCESS_COARSE_LOCATION
        )
    )
}

// Sprawdzenie, czy uprawnienie zostało cofnięte przez system (Android 12+)
class PermissionReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        if (intent.action == Intent.ACTION_PERMISSION_REVOCATION) {
            handleRevokedPermission(intent.getStringExtra(Intent.EXTRA_REVOKED_PERMISSION))
        }
    }
}

Android 13 dodał uprawnienie POST_NOTIFICATIONS do grupy dangerous, wymagając wyraźnego żądania wysyłania powiadomień push. Android 14 wprowadził ograniczenia dotyczące geolokalizacji w tle: aplikacja musi uzyskać wyraźną zgodę użytkownika za każdym razem przy żądaniu background location. Photo Picker (API 33+) zastąpił potrzebę READ_EXTERNAL_STORAGE do wyboru obrazów.

Obsługa odmów użytkownika

Odmowa użytkownika udzielenia uprawnienia — to normalna sytuacja, którą należy poprawnie obsłużyć. Istnieją dwa typy odmowy: jednorazowa (użytkownik kliknął „Zabroń“) i stała (użytkownik wybrał „Nie pytaj więcej“). W drugim przypadku systemowe okno dialogowe nie będzie już wyświetlane, a aplikacja musi przekierować użytkownika do ustawień systemowych.

Strategia obsługi odmów

Po pierwszej odmowie aplikacja powinna pokazać rationale dialog — własne wyjaśnienie, dlaczego uprawnienie jest konieczne. Jeśli użytkownik ponownie odmówi, należy przekierować go do ekranu ustawień aplikacji przez Settings.ACTION_APPLICATION_DETAILS_SETTINGS. Material 3 zaleca używanie PermissionRequestBottomSheet dla bardziej naturalnego UX.

Ważne, aby nie blokować całkowicie funkcjonalności aplikacji przy odmowie. Na przykład, jeśli użytkownik odrzucił geolokalizację, aplikacja powinna zaproponować ręczne wprowadzenie adresu. Dla kamery — umożliwić załadowanie obrazu z galerii. Google zaleca zawsze zapewniać mechanizm fallback dla wszystkich runtime permissions.

Zalecenia dotyczące bezpieczeństwa

Runtime permissions — to nie tylko mechanizm techniczny, ale także element zaufania użytkownika do aplikacji. Źądanie uprawnienia w nieodpowiednim momencie (na przykład przy pierwszym uruchomieniu) znacząco zmniejsza prawdopodobieństwo zgody. Google Play Store analizuje częstotliwość i kontekst żądań uprawnień: aplikacje z agresywnymi żądaniami otrzymują niższe pozycje w wyszukiwaniu.

Zasady żądania uprawnień

Kontekst — żądaj uprawnienia bezpośrednio przed wykonaniem działania, które go wymaga. Minimum — żądaj tylko tych uprawnień, które są rzeczywiście niezbędne do działania funkcji. Przejrzystość — wyjaśnij użytkownikowi, dlaczego uprawnienie jest potrzebne, przed systemowym oknem dialogowym. Cofnięcie — subskrybuj ACTION_PERMISSION_REVOCATION do poprawnej obsługi cofnięcia uprawnienia w czasie wykonania.

Do testowania runtime permissions używaj poleceń adb: adb shell pm revoke <package> android.permission.CAMERA pozwala symulować cofnięcie uprawnienia bez ponownej instalacji aplikacji. Espresso i UiAutomator obsługują testowanie okien dialogowych uprawnień przez GrantPermissionRule. Integracja tych narzędzi w pipeline CI/CD jest obowiązkowa dla aplikacji z runtime permissions.

Audyt uprawnień w Google Play Console

Google Play Console udostępnia sekcję Permission auditing (audyt uprawnień), gdzie programista widzi, jak często żądane są uprawnienia, jaki procent użytkowników udziela dostępu i które uprawnienia zostały cofnięte. Analiza tych danych pomaga zidentyfikować nieefektywne żądania i zoptymalizować UX. Na przykład, jeśli mniej niż 40% użytkowników udziela geolokalizacji, warto przeanalizować timing żądania i dodać bardziej przekonujące uzasadnienie.

Używanie Android Vitals do monitorowania permission-related ANR (Application Not Responding) jest również kluczowe. Jeśli żądanie uprawnienia wykonuje się na głównym wątku lub systemowe okno dialogowe blokuje UI, może to spowodować ANR na wolnych urządzeniach. Przenieś sprawdzanie i żądanie uprawnień do osobnego wątku lub użyj korutyn Kotlin do asynchronicznego przetwarzania, aby uniknąć blokowania interfejsu użytkownika.