Runtime Permission: esența, tipurile și principiul de funcționare în Android

Ce este Runtime Permission?

Runtime Permission (permisiunea de timp de execuție) — este un model de securitate Android în care aplicația solicită accesul la date confidențiale în momentul când acea funcționalitate este cu adevărat necesară utilizatorului. Înainte de Android 6.0, toate permisiunile erau acordate la instalarea aplicației, iar utilizatorul nu le putea revoca fără a șterge complet aplicația.

Evoluția modelului de permisiuni Android

Înainte de Android 6.0, utilizatorul vedea lista tuturor permisiunilor la instalare și putea fie să le accepte pe toate, fie să renunțe la instalare. Un studiu din 2015 a arătat că 87% dintre utilizatori nu citesc lista de permisiuni la instalare. Android 6.0 a introdus runtime permissions, împărțind permisiunile în normal (automate) și dangerous (cu solicitare). Android 11 a adăugat one-time permissions — revocare automată după închiderea aplicației. Android 13 a introdus Photo Picker și notificările push ca runtime permissions separate.

iOS folosește un model similar din versiunea iOS 10, unde accesul la cameră, microfon și geolocație este solicitat la prima utilizare. Totuși, iOS nu are conceptul de „normal permissions“ — fiecare permisiune este solicitată explicit, iar refuzul este salvat până la o nouă solicitare din partea dezvoltatorului prin setările sistemului.

Cum funcționează Runtime Permission în Android?

Runtime Permission funcționează printr-un dialog de sistem apelat prin metoda requestPermissions() (AndroidX — ActivityResultLauncher). Sistemul afișează un dialog standard cu explicații, iar utilizatorul alege „Permite“ sau „Refuză“. După răspuns, este apelat un callback al rezultatului în care aplicația gestionează decizia utilizatorului.

Solicitarea permisiunii prin 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 returnează true dacă utilizatorul a respins deja o dată solicitarea. În acest caz, se recomandă afișarea unui dialog cu explicația de ce aplicația are nevoie de permisiune și abia apoi re-solicitarea. Aceasta crește probabilitatea de acceptare cu 30–40% (date Google I/O 2024).

Tipuri de permisiuni în Android

Android clasifică toate permisiunile în mai multe niveluri de protecție: normal, dangerous, signature și special. Normal permissions sunt acordate automat la instalare. Dangerous permissions necesită solicitare runtime. Signature permissions sunt disponibile doar pentru aplicațiile semnate cu același certificat.

Grupurile de permisiuni periculoase

Special permissions (SYSTEM_ALERT_WINDOW, WRITE_SETTINGS, MANAGE_EXTERNAL_STORAGE) necesită o navigare suplimentară la setările sistemului prin Settings.ACTION_MANAGE_OVERLAY_PERMISSION. Aceste permisiuni nu pot fi solicitate prin dialogul standard de sistem și necesită o navigare explicită a utilizatorului la ecranul de setări.

Solicitarea permisiunilor în Android 12+

Android 12 a introdus schimbări semnificative în modelul runtime permissions. One-time permissions permit acordarea accesului la cameră, microfon sau geolocație doar pentru o sesiune. Când utilizatorul închide aplicația, permisiunea este revocată automat. Privacy indicators — indicatoare verzi în bara de stare care arată când aplicația folosește camera sau microfonul.

Gestionarea permisiunilor unice

// Android 12+ — gestionarea permisiunii unice pentru geolocație
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
        )
    )
}

// Verificare dacă permisiunea a fost revocată de sistem (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 a adăugat permisiunea POST_NOTIFICATIONS în grupul dangerous, cerând solicitare explicită pentru trimiterea notificărilor push. Android 14 a introdus restricții privind geolocația în fundal: aplicația trebuie să obțină acordul explicit al utilizatorului de fiecare dată când solicită background location. Photo Picker (API 33+) a înlocuit necesitatea READ_EXTERNAL_STORAGE pentru selectarea imaginilor.

Gestionarea refuzurilor utilizatorului

Refuzul utilizatorului de a acorda permisiunea este o situație normală care trebuie gestionată corect. Există două tipuri de refuz: unic (utilizatorul a apăsat „Refuză“) și permanent (utilizatorul a ales „Nu mai întreba“). În al doilea caz, dialogul de sistem nu va mai fi afișat, iar aplicația trebuie să redirecționeze utilizatorul la setările sistemului.

Strategia de gestionare a refuzurilor

După primul refuz, aplicația ar trebui să afișeze un rationale dialog — propria explicație a motivului pentru care permisiunea este necesară. Dacă utilizatorul refuză din nou, acesta trebuie redirecționat la ecranul de setări al aplicației prin Settings.ACTION_APPLICATION_DETAILS_SETTINGS. Material 3 recomandă utilizarea PermissionRequestBottomSheet pentru o experiență mai naturală.

Este important să nu blocați complet funcționalitatea aplicației la refuz. De exemplu, dacă utilizatorul a respins geolocația, aplicația ar trebui să propună introducerea manuală a adresei. Pentru cameră — să permită încărcarea imaginii din galerie. Google recomandă să oferiți întotdeauna un mecanism de fallback pentru toate runtime permissions.

Recomandări de securitate

Runtime permissions nu sunt doar un mecanism tehnic, ci și un element de încredere al utilizatorului în aplicație. Solicitarea permisiunii în momentul nepotrivit (de exemplu, la prima lansare) reduce semnificativ probabilitatea de acceptare. Google Play Store analizează frecvența și contextul solicitărilor de permisiuni: aplicațiile cu solicitări agresive primesc poziții mai joase în căutare.

Regulile de solicitare a permisiunilor

Context — solicitați permisiunea imediat înainte de executarea acțiunii care o necesită. Minim — solicitați doar permisiunile cu adevărat necesare pentru funcționarea caracteristicii. Transparență — explicați utilizatorului de ce este necesară permisiunea înainte de dialogul de sistem. Revocare — abonați-vă la ACTION_PERMISSION_REVOCATION pentru gestionarea corectă a revocării permisiunii în timpul execuției.

Pentru testarea runtime permissions, folosiți comenzile adb: adb shell pm revoke <package> android.permission.CAMERA vă permite să simulați revocarea permisiunii fără reinstalarea aplicației. Espresso și UiAutomator acceptă testarea dialogurilor de permisiuni prin GrantPermissionRule. Integrarea acestor instrumente în pipeline-ul CI/CD este obligatorie pentru aplicațiile cu runtime permissions.

Auditul permisiunilor în Google Play Console

Google Play Console oferă secțiunea Permission auditing (audit permisiuni), unde dezvoltatorul vede cât de des sunt solicitate permisiunile, ce procent de utilizatori acordă accesul și care permisiuni au fost revocate. Analiza acestor date ajută la identificarea solicitărilor ineficiente și optimizarea UX. De exemplu, dacă mai puțin de 40% dintre utilizatori acordă geolocația, merită să reconsiderați momentul solicitării și să adăugați o justificare mai convingătoare.

Utilizarea Android Vitals pentru monitorizarea ANR (Application Not Responding) legate de permisiuni este, de asemenea, esențială. Dacă solicitarea permisiunii se execută pe thread-ul principal sau dialogul de sistem blochează UI, aceasta poate provoca ANR pe dispozitivele lente. Externalizați verificarea și solicitarea permisiunilor într-un thread separat sau folosiți corutinele Kotlin pentru procesare asincronă pentru a evita blocarea interfeței utilizatorului.