Android'de Permission Group — nedir, izin grupları ve çalışma prensibi

Android'de Permission Group Nedir

Permission Group, birden çok tehlikeli izni işlevsel amaçlarına göre bir grupta birleştiren bir Android sistem mekanizmasıdır. Her grubun bir dize tanımlayıcısı vardır, örneğin android.permission-group.CAMERA veya android.permission-group.LOCATION. Bir grup içindeki tüm izinler mantıksal olarak ilişkilidir ve cihazın ilgili işlevlerine erişim sağlar.

İzin grupları, Android 6.0 Marshmallow ile birlikte çalışma zamanı izin modeliyle ortaya çıktı. Temel amaçları, kullanıcı etkileşimini basitleştirmektir: her bir izin için bir dizi diyalog yerine, sistem grup başına bir diyalog gösterir. Kullanıcı bir gruptan bir izin verirse, diğerleri otomatik olarak onaylanmış sayılır. Android UX Research (2015)'e göre, bu, ilk başlatmada reddetme sayısını yüzde 20 oranında azalttı.

Geliştiricinin kendi Permission Group'larını oluşturamayacağını anlamak önemlidir. Gruplar, işletim sistemi düzeyinde önceden tanımlanmıştır ve her cihazdaki permissions.xml dosyalarında açıklanmıştır. Uygulama yalnızca uses-permission bildirir ve sistem, protectionLevel ve AOSP'deki kategorizasyona göre izni otomatik olarak grubuyla eşler.

Sistem grubu nasıl belirler

Bir iznin bir grupla eşleştirilmesi, sistem izin tanımındaki permissionGroup özniteliği aracılığıyla gerçekleşir. Örneğin, CAMERA permissionGroup="android.permission-group.CAMERA" ile, ACCESS_FINE_LOCATION ise permissionGroup="android.permission-group.LOCATION" ile bildirilir. Bu eşleme, Android Open Source Project kodunda sabit kodlanmıştır ve tüm sertifikalı cihazlarda aynıdır.

Permission Group Nasıl Çalışır

Grup mekanizması “grup başına bir diyalog” ilkesine göre çalışır. Bir uygulama ilk kez tehlikeli bir izin talep ettiğinde, sistem Permission Group'unu kontrol eder. Bu gruptan henüz hiçbir izin verilmemişse — bir diyalog gösterilir. Onaydan sonra, sistem tüm grubu verilmiş olarak işaretler ve aynı gruptaki diğer izinler için sonraki talepler kullanıcı arayüzü olmadan karşılanır.

Basitleştirilmiş algoritma şöyle görünür:

• Uygulama, ACCESS_FINE_LOCATION için requestPermissions çağırır
• Sistem grubu belirler — android.permission-group.LOCATION
• LOCATION grubunun daha önce verilip verilmediğini kontrol eder
• Verilmemişse — grup adı ve dahil edilen izinlerin listesiyle bir diyalog gösterir
• Allow'dan sonra — tüm LOCATION grubu verilmiş sayılır
• ACCESS_COARSE_LOCATION artık ek talep olmadan kullanılabilir

Bu mekanizma yalnızca tehlikeli izinler için geçerlidir. Normal izinlerin grupları yoktur ve bu mantığa katılmazlar. Ayrıcalıklı ve imzalı izinler de gruplanmaz — bunların ayrı bir erişim kontrol sistemi vardır.

Grup mantığının sınırlamaları

Gruplar “ters yönde” çalışmaz: ayarlar aracılığıyla bir gruptan bir izni iptal etmek, diğerlerini etkilemeden yalnızca o izni iptal eder. Ayrıca, kullanıcı bir grubun diyalogunu reddederse, bu diğer grupları engellemez — farklı bir gruptaki her yeni izin kendi diyalogunu gösterir. Permission Group yalnızca talep UX'ini etkiler, güvenlik modelini etkilemez.

Android'de Permission Group Listesi

Android, tehlikeli izinler için aşağıdaki sistem Permission Group'larını tanımlar. Her grup, ortak bir işlevsel amaçla birleştirilmiş bir veya daha fazla izin içerir.

Yeni sürümlerdeki değişiklikler

Android 13'te (API 33), BLUETOOTH_SCAN, BLUETOOTH_CONNECT ve BLUETOOTH_ADVERTISE'i birleştiren yeni bir NEARBY_DEVICES grubu ortaya çıktı. Ayrıca, STORAGE grubu kısmen medya izinleri READ_MEDIA_IMAGES, READ_MEDIA_VIDEO ve READ_MEDIA_AUDIO ile değiştirildi; bunlar STORAGE'ın parçası değil, gruplandırma olmadan bağımsız tehlikeli izinlerdir.

Özel izin grupları

Geliştiriciler, manifest dosyasındaki permissionGroup özniteliği aracılığıyla özel Permission Group'larla kendi izinlerini bildirebilirler. Ancak bu, yalnızca aynı uygulamanın özel izinleri için çalışır ve sistem arayüzü diyaloglarını etkilemez. Pratikte, özel Permission Group'lar nadiren kullanılır — aynı yığındaki uygulamalar arasındaki etkileşim için.

Permission Group ve UX

Permission Group'un etkisi kullanıcı deneyimi üzerinde önemlidir. Gruplama sayesinde, kullanıcı farklı izinler için 8 ayrı diyalog değil, birkaç grup diyalogu görür. Bu, bilişsel yükü azaltır ve kullanıcının amacını anlamadan kritik bir izni reddetme olasılığını düşürür.

UX araştırmaları, grup diyaloglarının kullanıcılar tarafından daha şeffaf algılandığını göstermektedir. Bir uygulama “kameraya erişim izni” talep ettiğinde, kullanıcı bağlamı anlar. Her izin ayrı ayrı talep edilseydi — CAMERA, CAMERA2, FLASHLIGHT — bu, fazlalık izlenimi yaratırdı. Permission Group bu ayrıntı düzeyini soyutlar.

En iyi uygulama, izinleri yalnızca bir seferde bir gruptan talep etmektir. Bir uygulamanın hem kameraya hem de konuma ihtiyacı varsa, bunları tek bir requestPermissions çağrısında talep etmeyin. Önce bir grubu neden gerekli olduğunu açıkladıktan sonra talep edin, ardından ikinciyi. Bu, kullanıcıya kontrol ve her işlev hakkında sıralı bir anlayış sağlar.

Permission Group vs ProtectionLevel

Permission Group ve ProtectionLevel, Android izin sisteminin iki farklı boyutudur. ProtectionLevel, bir iznin nasıl verildiğini (normal, dangerous, signature, privileged) belirlerken, Permission Group, kullanıcı arayüzünde görüntüleme için bir kategoridir. Bağımsızdırlar, ancak pratikte dangerous + permission group kombinasyonu en yaygın olanıdır.

Aynı ProtectionLevel'daki izinler farklı gruplara ait olabilir. Örneğin, ACCESS_FINE_LOCATION ve CAMERA'nın her ikisi de protectionLevel dangerous'a sahiptir ancak farklı gruplara — LOCATION ve CAMERA — aittir. Tersine, aynı ada sahip izinler her zaman aynı gruba aittir: ACCESS_FINE_LOCATION ve ACCESS_COARSE_LOCATION'ın her ikisi de LOCATION'dadır.

Daha yüksek düzeydeki koruma seviyeleri — signature ve privileged — kullanıcı arayüzü için Permission Group kullanmaz. Bunların verilmesi sistem düzeyinde kontrol edilir: signature, sistemle aynı sertifikayla imzalanmış uygulamalara, privileged ise sistem görüntüsündeki uygulamalara verilir. Bu tür izinler için gruplar mevcuttur ancak UX diyaloglarını etkilemez çünkü bu diyaloglar görünmez.

Kodda Permission Group Kontrolü

Geliştirici, PackageManager aracılığıyla herhangi bir iznin Permission Group'unu programlı olarak belirleyebilir. getPermissionInfo yöntemi, grubun dize tanımlayıcısını içeren bir group alanına sahip PermissionInfo döndürür. Bu, günlükleme, analiz ve özel izin arayüzü ekranları için kullanışlı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 ve mimaride kullanım

Permission Group bilgisi, istek mimarisi oluşturmaya yardımcı olur. Belirli bir grup için izin listesini döndüren PermissionGroupProvider adlı bir soyutlama oluşturabilirsiniz. Bu, test etmeyi basitleştirir: birim testlerinde sağlayıcı, PackageManager'i çağırmadan sahte veri döndürür. Enstrümantasyon testlerinde, sistemden gerçek grupları döndürür.

DI'da PermissionGroupProvider

PermissionGroupProvider'ı Dagger Hilt veya Koin aracılığıyla entegre etmek, izin-grup eşlemesinin merkezi yönetimine olanak tanır. Sağlayıcıda, her istekte tekrarlanan sistem çağrılarından kaçınmak için PackageManager.queryPermissionsByGroup sonucunu önbelleğe alabilirsiniz. Bu, özellikle izinlerin tam listesinin ve durumlarının görüntülendiği ayarlar ekranları için önemlidir.

Günlükleme ve analiz

Reddetmelerle ilgili analiz toplarken, yalnızca izin adını değil aynı zamanda Permission Group'unu da günlüğe kaydetmek faydalıdır. Bu, hangi işlevsel alanların en fazla reddetmeye neden olduğunu belirlemeye yardımcı olur. Örneğin, LOCATION grubu geleneksel olarak en yüksek reddetme oranına sahiptir — Google Play Console istatistiklerine göre yaklaşık yüzde 40.

Gruplara göre analiz, ürün kararları almaya yardımcı olur: CONTACTS grubu yüksek bir reddetme oranına sahipse, istek zamanlamasını yeniden gözden geçirmek veya bir gerekçe diyalogu eklemek gerekebilir. Analize grup tabanlı yaklaşım, bireysel izinlerin analizinden daha eksiksiz bir resim sağlar çünkü tüm bir gruptaki reddetme sayısı, kullanıcıların işlevsel bir alana karşı genel tutumunu yansıtır.