Android-də Permission Group — bu nədir, icazə qrupları və işləmə prinsipi

Android-də Permission Group nədir

Permission Group — bu, Android-in sistem mexanizmidir, bir neçə təhlükəli icazəni funksional təyinatına görə bir qrupda birləşdirir. Hər qrupun sətir identifikatoru var, məsələn android.permission-group.CAMERA və ya android.permission-group.LOCATION. Bir qrup daxilindəki bütün icazələr məntiqi olaraq əlaqəlidir və cihazın oxşar funksiyalarına giriş təmin edir.

İcazə qrupları Android 6.0 Marshmallow ilə runtime sorğu modeli ilə birlikdə ortaya çıxdı. Onların əsas məqsədi istifadəçi ilə qarşılıqlı əlaqəni sadələşdirməkdir: hər bir fərdi icazə üçün bir sıra dialoqlar əvəzinə, sistem hər qrup üçün bir dialoq göstərir. Əgər istifadəçi qrupdan bir icazə veribsə, qalanları avtomatik təsdiqlənmiş sayılır. Android UX Research (2015)-ə görə, bu, ilk işə salınmada imtinaların sayını 20 faiz azaldıb.

Başa düşmək vacibdir ki, tətbiq inkişaf etdiricisi öz Permission Group-larını yarada bilməz. Qruplar əməliyyat sistemi səviyyəsində əvvəlcədən müəyyən edilir və hər cihazda permissions.xml fayllarında təsvir olunur. Tətbiq yalnızca uses-permission göstərir, sistem isə protectionLevel və AOSP-də kateqoriyalaşdırmaya əsasən icazəni avtomatik olaraq qrupu ilə əlaqələndirir.

Sistem qrupu necə müəyyən edir

İcazənin qrupla əlaqələndirilməsi sistem icazə tərifindəki permissionGroup atributu vasitəsilə baş verir. Məsələn, CAMERA permissionGroup="android.permission-group.CAMERA" ilə, ACCESS_FINE_LOCATION isə permissionGroup="android.permission-group.LOCATION" ilə elan edilib. Bu xəritələmə Android Open Source Project kodunda sərt şəkildə müəyyən edilib və bütün sertifikatlaşdırılmış cihazlarda eynidir.

Permission Group necə işləyir

Qrup mexanizmi “hər qrup üçün bir dialoq” prinsipi ilə işləyir. Tətbiq ilk dəfə hər hansı təhlükəli icazə tələb etdikdə, sistem onun Permission Group-unu yoxlayır. Bu qrupdan hələ heç bir icazə verilməyibsə — dialoq göstərilir. Razılıqdan sonra sistem bütün qrupu verilmiş kimi qeyd edir və eyni qrupdan digər icazələrin sonrakı sorğuları UI olmadan təmin edilir.

Alqoritm sadələşdirilmiş formada belə görünür:

• Tətbiq ACCESS_FINE_LOCATION üçün requestPermissions çağırır
• Sistem qrupu müəyyən edir — android.permission-group.LOCATION
• LOCATION qrupunun əvvəlcə verilib-verilmədiyini yoxlayır
• Yoxdursa — qrupun adı və daxil olan icazələrin siyahısı ilə dialoq göstərir
• Allow-dan sonra — bütün LOCATION qrupu verilmiş sayılır
• ACCESS_COARSE_LOCATION indi əlavə sorğu olmadan əlçatandır

Bu mexanizm yalnız təhlükəli icazələrə şamil edilir. Normal icazələrin qrupları yoxdur və bu məntiqdə iştirak etmir. İmtiyazlı və imzalanmış icazələr də qruplaşdırılmır — onların ayrı giriş idarəetmə sistemi var.

Qrup məntiqinin məhdudiyyətləri

Qruplar “tərs istiqamətdə” işləmir: parametrlər vasitəsilə qrupdan bir icazənin geri götürülməsi yalnız onu geri götürür, qalanlarına təsir etmir. Həmçinin, istifadəçi qrup üçün dialoqu rədd edibsə, bu digər qrupları bloklamır — başqa qrupdan hər yeni icazə öz dialoqunu göstərəcək. Permission Group yalnız sorğun UX-inə təsir edir, təhlükəsizlik modelinə deyil.

Android-də Permission Group siyahısı

Android müəyyən edir təhlükəli icazələr üçün aşağıdakı sistem Permission Group-ları. Hər qrup ümumi funksional təyinata görə birləşdirilmiş bir və ya daha çox icazəni əhatə edir.

Yeni versiyalarda dəyişikliklər

Android 13-də (API 33) BLUETOOTH_SCAN, BLUETOOTH_CONNECT və BLUETOOTH_ADVERTISE-ı birləşdirən yeni NEARBY_DEVICES qrupu ortaya çıxdı. Həmçinin, STORAGE qrupu qismən READ_MEDIA_IMAGES, READ_MEDIA_VIDEO və READ_MEDIA_AUDIO media icazələri ilə əvəz olundu, bunlar STORAGE-ə daxil deyil, əksinə qruplaşdırma olmadan müstəqil təhlükəli icazələrdir.

Özəl icazələr üçün qruplar

Tərtibatçılar manifestdə permissionGroup atributu vasitəsilə özəl Permission Group-ları ilə öz icazələrini elan edə bilərlər. Lakin bu, yalnız eyni tətbiqin özəl icazələri üçün işləyir və sistem UI dialoqlarına təsir etmir. Praktikada özəl Permission Group-lar nadir hallarda istifadə olunur — bir yığında öz tətbiqləri arasında qarşılıqlı əlaqə üçün.

Permission Group və UX

Permission Group-un təsiri istifadəçi təcrübəsinə əhəmiyyətlidir. Qruplaşdırma sayəsində istifadəçi müxtəlif icazələr üçün 8 ayrı dialoq deyil, bir neçə qrup dialoqu görür. Bu, idrak yükünü azaldır və istifadəçinin məqsədini anlamadan kritik icazəni rədd etmə ehtimalını azaldır.

UX tədqiqatları göstərir ki, qrup dialoqları istifadəçilər tərəfindən daha şəffaf qəbul edilir. Tətbiq „kameraya giriş” tələb etdikdə, istifadəçi konteksti başa düşür. Hər icazə ayrıca tələb olunsaydı — CAMERA, CAMERA2, FLASHLIGHT — bu, artıqlıq təəssürattı yaradardı. Permission Group bu detallaşdırmanı abstraksiya edir.

Ən yaxşı təcrübə — icazələri yalnız bir qrupdan bir dəfəyə tələb etməkdir. Əgər tətbiq həm kameraya, həm də geolokasiyaya ehtiyac duyursa, onları bir requestPermissions çağırışı ilə tələb etməməlisiniz. Əvvəlcə bir qrupu izah etdikdən sonra tələb edin, sonra ikincisini. Bu, istifadəçiyə nəzarət və hər funksiyanın ardıcıl başa düşülməsini təmin edir.

Permission Group vs ProtectionLevel

Permission Group və ProtectionLevel — bunlar Android icazə sisteminin iki müxtəlif ölçüsüdür. ProtectionLevel icazənin necə verildiyini müəyyən edir (normal, dangerous, signature, privileged), Permission Group isə UI göstərimi üçün kateqoriyadır. Onlar müstəqildir, lakin praktikada dangerous + permission group birləşməsi ən çox rast gəlinir.

Eyni ProtectionLevel-də olan icazələr fərqli qruplara aid ola bilər. Məsələn, ACCESS_FINE_LOCATION və CAMERA hər ikisi protectionLevel dangerous-ə malikdir, lakin fərqli qruplara aiddir — LOCATION və CAMERA. Və əksinə, eyniadlı icazələr həmişə bir qrupa aiddir: ACCESS_FINE_LOCATION və ACCESS_COARSE_LOCATION hər ikisi LOCATION-dadır.

Daha yüksək səviyyəli qoruma səviyyələri — signature və privileged — UI üçün Permission Group istifadə etmir. Onların verilməsi sistem səviyyəsində idarə olunur: signature sistemlə eyni sertifikatla imzalanmış tətbiqlərə, privileged isə sistem şəklində olan tətbiqlərə verilir. Belə icazələr üçün qruplar mövcuddur, lakin UX dialoqlarına təsir etmir, çünki bu dialoqlar sadəcə mövcud deyil.

Kodda Permission Group-u yoxlamaq

Tərtibatçı proqram vasitəsilə PackageManager-dən istifadə edərək istənilən icazənin Permission Group-unu müəyyən edə bilər. getPermissionInfo metodu qrupun sətir identifikatorunu ehtiva edən group sahəsi ilə PermissionInfo qaytarır. Bu, loglama, analitika və özəl icazə UI ekranları üçün faydalıdır.

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

DI və arxitekturada istifadə

Permission Group-u bilmək sorğu arxitekturasını qurmağa kömək edir. Müəyyən bir qrup üçün icazələrin siyahısını qaytaran PermissionGroupProvider abstraksiyası yarada bilərsiniz. Bu, testləri asanlaşdırır: vahid testlərində provider PackageManager-ə müraciət etmədən saxta məlumatlar qaytarır. Instrumental testlərində — sistemdən real qruplar.

DI-də PermissionGroupProvider

PermissionGroupProvider-ı Dagger Hilt və ya Koin vasitəsilə inteqrasiya etmək icazələrin və qrupların xəritələnməsini mərkəzləşdirməyə imkan verir. Providerdə hər sorğuda təkrarlanan sistem çağırışlarını etməmək üçün PackageManager.queryPermissionsByGroup nəticəsini keşləyə bilərsiniz. Bu, xüsusilə bütün icazələrin və onların statusunun göstərildiyi parametrlər ekranları üçün vacibdir.

Loglama və analitika

İmtinalar haqqında analitika toplayarkən yalnız icazənin adını deyil, həm də onun Permission Group-unu loglamaq faydalıdır. Bu, hansı funksional sahələrin ən çox imtinaya səbəb olduğunu müəyyən etməyə imkan verir. Məsələn, LOCATION qrupu ənənəvi olaraq ən yüksək imtina faizinə malikdir — Google Play Console statistikasına görə təxminən 40 faiz.

Qruplar üzrə analitika məhsul qərarları qəbul etməyə kömək edir: əgər CONTACTS qrupu yüksək imtina faizinə malikdirsə, sorğu anını dəyişdirmək və ya izahat dialoqu əlavə etmək barədə düşünməyə dəyər. Analitikaya qrup yanaşması fərdi icazələrin təhlilindən daha tam şəkil verir, çünki bütün qrup üzrə imtinaların sayı istifadəçilərin funksional sahəyə ümumi münasibətini əks etdirir.