Permission Group di Android — apa itu, grup izin dan prinsip kerja

Apa itu Permission Group di Android

Permission Group — adalah mekanisme sistem Android yang menggabungkan beberapa izin berbahaya ke dalam satu grup berdasarkan tujuan fungsionalnya. Setiap grup memiliki pengidentifikasi string, misalnya android.permission-group.CAMERA atau android.permission-group.LOCATION. Semua izin dalam satu grup terhubung secara logis dan memberikan akses ke fungsi perangkat yang terkait.

Grup izin muncul di Android 6.0 Marshmallow bersamaan dengan model permintaan runtime. Tujuan utama mereka adalah menyederhanakan interaksi dengan pengguna: alih-alih serangkaian dialog untuk setiap izin individual, sistem menampilkan satu dialog per grup. Jika pengguna telah memberikan satu izin dari suatu grup, sisanya dianggap secara otomatis disetujui. Menurut Android UX Research (2015), ini mengurangi jumlah penolakan pada peluncuran pertama sebesar 20 persen.

Penting untuk dipahami bahwa pengembang tidak dapat membuat Permission Group sendiri. Grup telah ditentukan sebelumnya di tingkat sistem operasi dan dijelaskan dalam file permissions.xml di setiap perangkat. Aplikasi hanya menentukan uses-permission, dan sistem secara otomatis mencocokkan izin dengan grupnya berdasarkan protectionLevel dan kategorisasi di AOSP.

Bagaimana sistem menentukan grup

Pencocokan izin dengan grup terjadi melalui atribut permissionGroup dalam definisi sistem izin. Misalnya, CAMERA dideklarasikan dengan permissionGroup="android.permission-group.CAMERA", ACCESS_FINE_LOCATION — dengan permissionGroup="android.permission-group.LOCATION". Pemetaan ini ditetapkan secara kaku dalam kode Android Open Source Project dan sama di semua perangkat bersertifikat.

Bagaimana Permission Group bekerja

Mekanisme grup bekerja berdasarkan prinsip “satu dialog per grup”. Ketika aplikasi pertama kali meminta izin berbahaya apa pun, sistem memeriksa Permission Group-nya. Jika belum ada izin dari grup ini yang diberikan — dialog ditampilkan. Setelah persetujuan, sistem menandai seluruh grup sebagai telah diberikan, dan permintaan selanjutnya dari izin lain dalam grup yang sama dipenuhi tanpa antarmuka pengguna.

Algoritma yang disederhanakan terlihat seperti ini:

• Aplikasi memanggil requestPermissions untuk ACCESS_FINE_LOCATION
• Sistem menentukan grup — android.permission-group.LOCATION
• Memeriksa apakah grup LOCATION sebelumnya telah diberikan
• Jika belum — menampilkan dialog dengan nama grup dan daftar izin yang termasuk
• Setelah Allow — seluruh grup LOCATION dianggap telah diberikan
• ACCESS_COARSE_LOCATION sekarang tersedia tanpa permintaan tambahan

Mekanisme ini hanya berlaku untuk izin berbahaya. Izin normal tidak memiliki grup dan tidak berpartisipasi dalam logika ini. Izin istimewa dan yang ditandatangani juga tidak dikelompokkan — mereka memiliki sistem manajemen akses terpisah.

Keterbatasan logika grup

Grup tidak bekerja secara terbalik: mencabut satu izin dari grup melalui pengaturan hanya mencabut izin tersebut, tanpa memengaruhi yang lain. Juga, jika pengguna menolak dialog untuk suatu grup, ini tidak memblokir grup lain — setiap izin baru dari grup lain akan menampilkan dialognya sendiri. Permission Group hanya memengaruhi UX permintaan, bukan model keamanan.

Daftar Permission Group di Android

Android mendefinisikan Permission Group sistem berikut untuk izin berbahaya. Setiap grup mencakup satu atau lebih izin yang disatukan oleh tujuan fungsional yang sama.

Perubahan di versi baru

Di Android 13 (API 33) muncul grup baru NEARBY_DEVICES yang menggabungkan BLUETOOTH_SCAN, BLUETOOTH_CONNECT dan BLUETOOTH_ADVERTISE. Juga, grup STORAGE sebagian digantikan oleh izin media READ_MEDIA_IMAGES, READ_MEDIA_VIDEO dan READ_MEDIA_AUDIO, yang bukan bagian dari STORAGE, melainkan izin berbahaya independen tanpa pengelompokan.

Grup untuk izin kustom

Pengembang dapat mendeklarasikan izin mereka sendiri dengan Permission Group kustom melalui atribut permissionGroup dalam manifes. Namun ini hanya berfungsi untuk izin kustom aplikasi yang sama dan tidak memengaruhi dialog UI sistem. Dalam praktiknya, Permission Group kustom jarang digunakan — untuk interaksi antar aplikasi sendiri dalam satu tumpukan.

Permission Group dan UX

Dampak Permission Group pada pengalaman pengguna sangat signifikan. Berkat pengelompokan, pengguna melihat bukan 8 dialog terpisah untuk izin yang berbeda, melainkan beberapa dialog grup. Ini mengurangi beban kognitif dan mengurangi kemungkinan pengguna menolak izin kritis tanpa memahami tujuannya.

Penelitian UX menunjukkan bahwa dialog grup dianggap lebih transparan oleh pengguna. Ketika aplikasi meminta “akses ke kamera”, pengguna memahami konteksnya. Jika setiap izin diminta secara terpisah — CAMERA, CAMERA2, FLASHLIGHT — ini akan menciptakan kesan redundansi. Permission Group mengabstraksi detail ini.

Praktik terbaik adalah meminta izin hanya dari satu grup pada satu waktu. Jika aplikasi membutuhkan kamera dan geolokasi, jangan memintanya dengan satu panggilan requestPermissions. Minta satu grup setelah penjelasan, lalu yang kedua. Ini memberi pengguna kontrol dan pemahaman berurutan tentang setiap fungsi.

Permission Group vs ProtectionLevel

Permission Group dan ProtectionLevel — ini adalah dua dimensi berbeda dari sistem izin Android. ProtectionLevel menentukan bagaimana izin diberikan (normal, dangerous, signature, privileged), sedangkan Permission Group adalah kategori untuk tampilan UI. Mereka independen, tetapi dalam praktiknya, kombinasi dangerous + permission group paling sering terjadi.

Izin dari ProtectionLevel yang sama dapat termasuk ke dalam grup yang berbeda. Misalnya, ACCESS_FINE_LOCATION dan CAMERA keduanya memiliki protectionLevel dangerous, tetapi termasuk ke dalam grup yang berbeda — LOCATION dan CAMERA. Dan sebaliknya, izin dengan nama yang sama selalu termasuk ke dalam grup yang sama: ACCESS_FINE_LOCATION dan ACCESS_COARSE_LOCATION keduanya di LOCATION.

Tingkat perlindungan yang lebih tinggi — signature dan privileged — tidak menggunakan Permission Group untuk UI. Pemberiannya dikontrol di tingkat sistem: signature diberikan kepada aplikasi yang ditandatangani dengan sertifikat yang sama dengan sistem, dan privileged kepada aplikasi dalam citra sistem. Grup untuk izin semacam itu ada, tetapi tidak memengaruhi dialog UX, karena dialog tersebut tidak ada.

Memeriksa Permission Group dalam kode

Pengembang dapat secara terprogram menentukan Permission Group dari izin apa pun melalui PackageManager. Metode getPermissionInfo mengembalikan PermissionInfo dengan bidang group yang berisi pengidentifikasi string grup. Ini berguna untuk logging, analitik, dan layar UI izin kustom.

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

Penggunaan dalam DI dan arsitektur

Pengetahuan tentang Permission Group membantu membangun arsitektur permintaan. Dapat dibuat abstraksi PermissionGroupProvider yang mengembalikan daftar izin untuk grup tertentu. Ini menyederhanakan pengujian: dalam pengujian unit, provider mengembalikan data palsu tanpa memanggil PackageManager. Dalam pengujian instrumental — grup nyata dari sistem.

PermissionGroupProvider dalam DI

Integrasi PermissionGroupProvider melalui Dagger Hilt atau Koin memungkinkan manajemen terpusat dari pemetaan izin dan grup. Dalam provider, hasil PackageManager.queryPermissionsByGroup dapat di-cache untuk menghindari panggilan sistem berulang pada setiap permintaan. Ini sangat penting untuk layar pengaturan di mana daftar lengkap izin dan statusnya ditampilkan.

Logging dan analitik

Saat mengumpulkan analitik tentang penolakan, berguna untuk mencatat tidak hanya nama izin tetapi juga Permission Group-nya. Ini membantu mengidentifikasi area fungsional yang menyebabkan penolakan paling banyak. Misalnya, grup LOCATION secara tradisional memiliki persentase penolakan tertinggi — sekitar 40 persen, menurut statistik Google Play Console.

Analitik per grup membantu dalam pengambilan keputusan produk: jika grup CONTACTS memiliki persentase penolakan yang tinggi, mungkin perlu mempertimbangkan kembali waktu permintaan atau menambahkan dialog penjelasan. Pendekatan grup terhadap analitik memberikan gambaran yang lebih lengkap daripada analisis izin individual, karena jumlah penolakan untuk seluruh grup mencerminkan sikap umum pengguna terhadap area fungsional tersebut.