Dangerous Permission în Android: esența, lista permisiunilor și solicitarea runtime

Ce este Dangerous Permission în Android

Dangerous Permission — este o categorie de permisiuni de sistem Android care oferă acces la datele confidențiale ale utilizatorului. Spre deosebire de permisiunile normale, permisiunile periculoase nu sunt acordate automat la instalare — aplicația trebuie să le solicite explicit în timpul execuției prin mecanismul runtime, introdus în Android 6.0 Marshmallow (API 23).

Necesitatea solicitării explicite se datorează naturii datelor protejate de aceste permisiuni: geolocația utilizatorului, contactele personale, conținutul camerei și microfonului, istoricul apelurilor și SMS. Android consideră aceste date ca sensibile și necesită acordul conștient al utilizatorului. Conform Android Privacy Sandbox (2024), utilizatorii resping în medie aproximativ 30 la sută din solicitările runtime.

Caracteristica cheie a Dangerous Permission — posibilitatea de revocare în orice moment. Utilizatorul poate accesa Setări — Aplicații — Permisiuni și poate comuta comutatorul pentru orice permisiune periculoasă. Aplicația trebuie să fie pregătită ca permisiunea care a fost acordată să poată fi revocată în orice moment fără repornire.

ProtectionLevel dangerous

Nivelul de protecție dangerous este stabilit în definițiile sistemice ale permisiunilor la nivel de OS. Când aplicația declară uses-permission cu un astfel de protectionLevel, sistemul marchează permisiunea ca necesitând solicitare runtime. Spre deosebire de normal, permisiunile dangerous sunt întotdeauna afișate în interfața de gestionare a permisiunilor și pot fi revocate.

Permission Group și Dangerous

Toate permisiunile periculoase sunt grupate în Permission Group după criterii funcționale. De exemplu, CAMERA și CAMERA2 se află în grupul CAMERA, ACCESS_FINE_LOCATION și ACCESS_COARSE_LOCATION — în grupul LOCATION. Dacă utilizatorul a acordat o permisiune din grup, celelalte permisiuni ale aceluiași grup sunt acordate automat fără dialog suplimentar.

Cum funcționează solicitarea runtime

Solicitarea runtime — este mecanismul prin care aplicația apelează API-ul sistemului pentru a afișa un dialog de solicitare a permisiunii. Utilizatorul vede o fereastră modală cu numele permisiunii și butoanele Allow și Deny. După răspuns, sistemul apelează callback-ul onRequestPermissionsResult cu rezultatul.

Ciclul complet include trei pași: verificarea statutului prin checkSelfPermission, apelarea requestPermissions în lipsa permisiunii și procesarea rezultatului în onRequestPermissionsResult. Verificarea statutului este obligatorie, deoarece utilizatorul poate revoca permisiunea în orice moment prin setări, iar apelarea funcției fără verificare va duce la SecurityException.

fun checkAndRequestCameraPermission() {
    when {
        ContextCompat.checkSelfPermission(
            this,
            Manifest.permission.CAMERA
        ) == PackageManager.PERMISSION_GRANTED -> {
            openCamera()
        }
        else -> {
            ActivityCompat.requestPermissions(
                this,
                arrayOf(Manifest.permission.CAMERA),
                REQUEST_CAMERA_CODE
            )
        }
    }
}

Procesarea rezultatului are loc în ActivityResultLauncher sau onRequestPermissionsResult. Abordarea modernă recomandată — utilizarea ActivityResultContracts.RequestPermission, care oferă un API mai curat fără coduri explicite de solicitare. Acest contract returnează Boolean — dacă permisiunea a fost acordată sau nu.

Cele mai bune practici de solicitare

Solicitați permisiunile periculoase strict în contextul utilizării funcției, nu la pornirea aplicației. Dacă utilizatorul a apăsat butonul camerei — solicitați CAMERA. Dacă a deschis harta — solicitați LOCATION. Solicitarea contextuală oferă de două ori mai multe acorduri decât solicitarea tuturor permisiunilor la prima lansare. De asemenea, se recomandă să nu solicitați mai mult de o permisiune odată, pentru ca utilizatorul să înțeleagă ce funcție necesită acces.

Lista permisiunilor periculoase în Android

Android definește mai multe grupuri de permisiuni periculoase, fiecare conținând de la una la mai multe constante. Lista cea mai completă este prezentată în clasa Manifest.permission. Mai jos sunt prezentate principalele grupuri și permisiuni utilizate în dezvoltare.

Permisiuni noi în Android 12+

Începând cu Android 12, Google a înăsprit cerințele pentru unele permisiuni. De exemplu, BLUETOOTH_CONNECT și BLUETOOTH_SCAN au devenit periculoase și necesită solicitare runtime. De asemenea, a apărut permisiunea BODY_SENSORS_BACKGROUND pentru accesul în fundal la senzori. Dezvoltatorii trebuie să actualizeze targetSdkVersion și să testeze solicitările pe versiunile curente de OS.

Permisiuni pentru Android 13+

Android 13 (API 33) a introdus permisiuni noi pentru notificări (POST_NOTIFICATIONS) și pentru fișiere media (READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_MEDIA_AUDIO), înlocuind READ_EXTERNAL_STORAGE general. Acum accesul la fotografii, video și audio se solicită separat prin permisiuni specializate fără un dialog unic.

Dangerous vs Normal Permission

Dangerous și Normal Permission diferă fundamental prin modul de acordare, posibilitatea de revocare și UX. Normal se acordă automat la instalare, Dangerous necesită un dialog runtime explicit. Normal nu poate fi revocat prin setări, Dangerous poate fi dezactivat în orice moment. Această asimetrie impune modele de dezvoltare diferite.

Din punct de vedere al codului, permisiunile periculoase necesită mai multă muncă: checkSelfPermission, requestPermissions, gestionarea refuzului. Pentru permisiunile normale este suficient un rând în AndroidManifest.xml. În același timp, Dangerous Permission oferă utilizatorului control, ceea ce crește încrederea, în special pentru funcțiile sensibile precum camera sau geolocația.

Alegerea între categorii nu stă în fața dezvoltatorului — este determinată de sistem. Dezvoltatorul declară doar uses-permission, iar sistemul pe baza protectionLevel determină categoria. Cu toate acestea, strategia de solicitare a permisiunilor periculoase influențează experiența utilizatorului: dialogurile frecvente sau inadecvate reduc ratingul aplicației.

Cum se solicită permisiuni în Kotlin

Modul modern de solicitare a permisiunilor în Kotlin — utilizarea ActivityResultContracts.RequestMultiplePermissions sau RequestPermission. Aceste contracte fac parte din biblioteca androidx.activity și oferă un API curat bazat pe lambda, fără a fi nevoie să suprascrieți onRequestPermissionsResult.

class CameraActivity : AppCompatActivity() {
    private val requestPermissionLauncher =
        registerForActivityResult(
            ActivityResultContracts.RequestPermission()
        ) { isGranted: Boolean ->
            if (isGranted) {
                openCamera()
            } else {
                showPermissionDeniedMessage()
            }
        }

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

Solicitarea mai multor permisiuni simultan

Când aplicația are nevoie de mai multe permisiuni periculoase simultan, utilizați RequestMultiplePermissions. Contractul returnează Map<String, Boolean>, unde cheia este numele permisiunii, iar valoarea este rezultatul. Acest lucru este convenabil la prima lansare când trebuie solicitate CAMERA și RECORD_AUDIO pentru înregistrarea video.

Gestionarea primului refuz

Dacă utilizatorul a respins solicitarea, metoda shouldShowRequestPermissionRationale returnează true. Acesta este un semnal pentru a afișa o explicație despre necesitatea permisiunii. Cea mai bună practică — afișarea unui dialog personalizat cu explicație și butonul Reîncercare. Dacă utilizatorul a respins din nou solicitarea cu bifa Never Ask Again, shouldShowRequestPermissionRationale va returna false și trebuie să redirecționați la Setări.

Gestionarea refuzului și Never Ask Again

Never Ask Again — este un fanion pe care utilizatorul îl poate seta la respingerea repetată a dialogului runtime. După aceasta, dialogul standard nu se mai afișează pentru această permisiune. Singura modalitate de a acorda accesul — redirecționarea utilizatorului la setările sistemului pentru aplicații.

Dezvoltatorul trebuie să distingă două scenarii de refuz: primul — când shouldShowRequestPermissionRationale returnează true (utilizatorul a respins, dar dialogul poate fi încă afișat) și al doilea — când metoda returnează false (Never Ask Again este activ sau permisiunea este blocată de politică). În al doilea caz, trebuie afișat butonul Deschide setări.

fun handlePermissionDenied(permission: String) {
    if (ActivityCompat.shouldShowRequestPermissionRationale(
            this, permission
    )) {
        showRationaleDialog(permission)
    } else {
        showSettingsRedirectDialog(permission)
    }
}

private fun showSettingsRedirectDialog(permission: String) {
    AlertDialog.Builder(this)
        .setTitle("Acces interzis")
        .setMessage(
            "Permisiune blocată. Deschideți setările."
        )
        .setPositiveButton("Setări") { _, _ ->
            val intent = Intent(
                Settings.ACTION_APPLICATION_DETAILS_SETTINGS,
                Uri.fromParts(
                    "package", packageName, null
                )
            )
            startActivity(intent)
        }
        .show()
}

Este important să nu solicitați din nou permisiunea dacă shouldShowRequestPermissionRationale a returnat false. Apelarea repetată a requestPermissions în acest caz nu va afișa dialogul — rezultatul va veni imediat cu DENIED fără explicație. Utilizatorul se va confrunta cu un comportament de neînțeles, ceea ce va afecta negativ experiența de utilizare a aplicației.