Dangerous Permission Android-da: mahiyyəti, icazə siyahısı və runtime sorğusu

Android-da Dangerous Permission nədir

Dangerous Permission — Android sistem icazələrinin istifadəçinin məxfi məlumatlarına girişi təmin edən kateqoriyasıdır. Normal icazələrdən fərqli olaraq, təhlükəli icazələr quraşdırma zamanı avtomatik verilmir — tətbiq Android 6.0 Marshmallow (API 23)-də təqdim edilən runtime mexanizmi vasitəsilə onları işləmə zamanı açıq şəkildə soruşmalıdır.

Açıq sorğunun zəruriliyi bu icazələrin qoruduğu məlumatların xarakteri ilə bağlıdır: istifadəçinin geolokasiyası, şəxsi kontaktları, kamera və mikrofon məzmunu, zəng tarixçəsi və SMS. Android bu məlumatları həssas hesab edir və istifadəçinin şüurlu şəkildə razılıq verməsini tələb edir. Android Privacy Sandbox (2024) məlumatına görə, istifadəçilər orta hesabla runtime sorğularının təxminən 30 faizini rədd edir.

Dangerous Permission-ın əsas xüsusiyyəti istənilən vaxt geri alına bilməsidir. İstifadəçi Parametrlər — Tətbiqlər — İcazələr bölməsinə keçib istənilən təhlükəli icazə üçün keçidi dəyişə bilər. Tətbiq verilmiş icazənin istənilən vaxt yenidən başladılmadan geri alına biləcəyinə hazır olmalıdır.

ProtectionLevel dangerous

Dangerous qoruma səviyyəsi OS səviyyəsində sistem icazə təriflərində təyin edilir. Tətbiq belə protectionLevel ilə uses-permission bəyan etdikdə, sistem icazəni runtime sorğusu tələb edən kimi qeyd edir. Normal-dan fərqli olaraq, dangerous icazələri həmişə sistem icazə idarəetmə interfeysində göstərilir və geri alına bilər.

Permission Group və Dangerous

Bütün təhlükəli icazələr funksional əlamətə görə Permission Group-da qruplaşdırılıb. Məsələn, CAMERA və CAMERA2 CAMERA qrupunda, ACCESS_FINE_LOCATION və ACCESS_COARSE_LOCATION — LOCATION qrupundadır. İstifadəçi qrupdan bir icazə veribsə, həmin qrupun qalan icazələri əlavə dialoq olmadan avtomatik verilir.

Runtime sorğusu necə işləyir

Runtime sorğusu — tətbiqin icazə sorğusu ilə sistem dialoqunu göstərmək üçün sistem API-ni çağırdığı mexanizmdir. İstifadəçi icazənin adı və Allow və Deny düymələri olan modal pəncərə görür. Cavabdan sonra sistem nəticə ilə onRequestPermissionsResult callback-ni çağırır.

Tam dövr üç addımı əhatə edir: checkSelfPermission vasitəsilə statusun yoxlanılması, icazə olmadıqda requestPermissions-in çağırılması və nəticənin onRequestPermissionsResult-da işlənməsi. Status yoxlanışı məcburidir, çünki istifadəçi icazəni istənilən vaxt parametrlər vasitəsilə geri ala bilər və yoxlamadan funksiyanın çağırılması SecurityException-a səbəb olacaq.

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

Nəticənin işlənməsi ActivityResultLauncher və ya onRequestPermissionsResult-da baş verir. Müasir tövsiyə edilən yanaşma — ActivityResultContracts.RequestPermission istifadə etməkdir ki, bu da açıq sorğu kodları olmadan daha təmiz API təmin edir. Bu müqavilə Boolean qaytarır — icazə verilib ya yox.

Sorğu üçün ən yaxşı təcrübələr

Təhlükəli icazələri tətbiq işə düşəndə yox, ciddi şəkildə funksiyanın istifadə kontekstində soruşun. İstifadəçi kamera düyməsini basıbsa — CAMERA soruşun. Xəritəni açıbsa — LOCATION soruşun. Kontekstual sorğu ilk işə salınmada bütün icazələri soruşmaqdan iki dəfə çox təsdiq alır. Həmçinin bir dəfədə birdən çox icazə soruşmamaq tövsiyə olunur ki, istifadəçi hansı funksiyanın giriş tələb etdiyini başa düşsün.

Android-da təhlükəli icazələrin siyahısı

Android müəyyən edir bir neçə təhlükəli icazə qrupu, hər biri birdən bir neçə sabitə qədər daxildir. Ən tam siyahı Manifest.permission sinfində təqdim edilmişdir. Aşağıda işləmədə istifadə olunan əsas qruplar və icazələr göstərilmişdir.

Android 12+-da yeni icazələr

Android 12-dən başlayaraq, Google bəzi icazələrə tələbləri sərtləşdirdi. Məsələn, BLUETOOTH_CONNECT və BLUETOOTH_SCAN təhlükəli oldu və runtime sorğusu tələb edir. Həmçinin sensorlara fon girişi üçün BODY_SENSORS_BACKGROUND icazəsi meydana çıxdı. Tərtibatçılar targetSdkVersion-u yeniləməli və sorğuları OS-in cari versiyalarında test etməlidirlər.

Android 13+ üçün icazələr

Android 13 (API 33) bildirişlər (POST_NOTIFICATIONS) və media faylları (READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_MEDIA_AUDIO) üçün yeni icazələr təqdim etdi, ümumi READ_EXTERNAL_STORAGE-i əvəz etdi. İndi foto, video və audioya giriş vahid dialoq olmadan ayrıca ixtisaslaşmış icazələr vasitəsilə soruşulur.

Dangerous vs Normal Permission

Dangerous və Normal Permission verilmə üsuluna, geri alma imkanına və UX-ə görə prinsipial olaraq fərqlənir. Normal quraşdırma zamanı avtomatik verilir, Dangerous açıq runtime dialoqu tələb edir. Normal parametrlər vasitəsilə geri alına bilməz, Dangerous istənilən vaxt söndürülə bilər. Bu asimmetriya müxtəlif işləmə nümunələrini müəyyən edir.

Kod baxımından təhlükəli icazələr daha çox iş tələb edir: checkSelfPermission, requestPermissions, imtinanın idarə edilməsi. Normal üçün AndroidManifest.xml-də bir sətir kifayətdir. Eyni zamanda, Dangerous Permission istifadəçiyə nəzarət verir ki, bu da xüsusilə kamera və ya geolokasiya kimi həssas funksiyalar üçün inamı artırır.

Kateqoriyalar arasında seçim tərtibatçının qarşısında durmur — sistem tərəfindən müəyyən edilir. Tərtibatçı yalnız uses-permission bəyan edir, sistem isə protectionLevel əsasında kateqoriyanı təyin edir. Lakin təhlükəli icazələrin sorğu strategiyası istifadəçi təcrübəsinə təsir edir: tez-tez və ya yersiz dialoqlar tətbiqin reytinqini aşağı salır.

Kotlin-də icazələri necə soruşmaq olar

Müasir üsul Kotlin-də icazə sorğusu — ActivityResultContracts.RequestMultiplePermissions və ya RequestPermission istifadə etməkdir. Bu müqavilələr androidx.activity kitabxanasının tərkibinə daxildir və onRequestPermissionsResult-u əvəz etmədən lambdalar əsasında təmiz API təmin edir.

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
                )
        }
    }
}

Bir neçə icazəni eyni anda soruşmaq

Tətbiqə eyni anda bir neçə təhlükəli icazə lazım olduqda, RequestMultiplePermissions istifadə edin. Müqavilə Map<String, Boolean> qaytarır, burada açar icazənin adı, dəyər isə nəticədir. Bu, video yazmaq üçün CAMERA və RECORD_AUDIO tələb olunduqda ilk işə salınmada rahatdır.

İlk dəfə imtinanın idarə edilməsi

Əgər istifadəçi sorğunu rədd edibsə, shouldShowRequestPermissionRationale metodu true qaytarır. Bu, icazənin nə üçün lazım olduğunu izah edən izahat göstərmək üçün siqnaldır. Ən yaxşı təcrübə — izahat və Təkrar et düyməsi olan xüsusi dialoq göstərməkdir. Əgər istifadəçi Never Ask Again işarəsi ilə sorğunu təkrar rədd edibsə, shouldShowRequestPermissionRationale false qaytaracaq və Parametrlərə yönləndirmək lazımdır.

İmtinanın və Never Ask Again-in idarə edilməsi

Never Ask Again — istifadəçinin runtime dialoqunu təkrar rədd edərkən təyin edə biləcəyi bayraqdır. Bundan sonra standart dialoq pəncərəsi bu icazə üçün artıq göstərilmir. Girişi təmin etməyin yeganə yolu — istifadəçini sistem tətbiq parametrlərinə yönləndirməkdir.

Tərtibatçı iki imtina ssenarisini fərqləndirməlidir: birinci — shouldShowRequestPermissionRationale true qaytardıqda (istifadəçi rədd etdi, lakin dialoq hələ göstərilə bilər) və ikinci — metod false qaytardıqda (Never Ask Again aktivdir və ya icazə siyasətlə bloklanıb). İkinci halda Parametrləri aç düyməsini göstərmək lazımdır.

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

private fun showSettingsRedirectDialog(permission: String) {
    AlertDialog.Builder(this)
        .setTitle("Giriş qadağandır")
        .setMessage(
            "İcazə bloklanıb. Parametrləri açın."
        )
        .setPositiveButton("Parametrlər") { _, _ ->
            val intent = Intent(
                Settings.ACTION_APPLICATION_DETAILS_SETTINGS,
                Uri.fromParts(
                    "package", packageName, null
                )
            )
            startActivity(intent)
        }
        .show()
}

shouldShowRequestPermissionRationale false qaytardıqda icazəni təkrar soruşmamaq vacibdir. Bu halda requestPermissions-in təkrar çağırılması dialoq göstərməyəcək — nəticə dərhal izahsız DENIED ilə gələcək. İstifadəçi anlaşılmaz davranışla qarşılaşacaq ki, bu da tətbiqdən istifadə təcrübəsinə mənfi təsir edəcək.