Dangerous Permission di Android: esensi, daftar izin dan permintaan runtime

Apa itu Dangerous Permission di Android

Dangerous Permission adalah kategori izin sistem Android yang memberikan akses ke data rahasia pengguna. Berbeda dengan izin normal, izin berbahaya tidak diberikan secara otomatis saat instalasi — aplikasi harus memintanya secara eksplisit selama runtime melalui mekanisme yang diperkenalkan di Android 6.0 Marshmallow (API 23).

Kebutuhan permintaan eksplisit disebabkan oleh sifat data yang dilindungi izin ini: geolokasi pengguna, kontak pribadi, konten kamera dan mikrofon, riwayat panggilan dan SMS. Android menganggap data ini sensitif dan memerlukan persetujuan sadar pengguna. Menurut Android Privacy Sandbox (2024), pengguna menolak sekitar 30 persen permintaan runtime rata-rata.

Fitur utama Dangerous Permission — kemungkinan pencabutan kapan saja. Pengguna dapat masuk ke Pengaturan — Aplikasi — Izin dan mengalihkan sakelar untuk izin berbahaya mana pun. Aplikasi harus siap bahwa izin yang telah diberikan dapat dicabut kapan saja tanpa restart.

ProtectionLevel dangerous

Tingkat perlindungan dangerous ditetapkan dalam definisi sistem izin di tingkat OS. Saat aplikasi mendeklarasikan uses-permission dengan protectionLevel seperti itu, sistem menandai izin sebagai yang memerlukan permintaan runtime. Berbeda dengan normal, izin dangerous selalu ditampilkan di UI sistem manajemen izin dan dapat dicabut.

Permission Group dan Dangerous

Semua izin berbahaya dikelompokkan dalam Permission Group berdasarkan fungsi. Misalnya, CAMERA dan CAMERA2 berada di grup CAMERA, ACCESS_FINE_LOCATION dan ACCESS_COARSE_LOCATION — di grup LOCATION. Jika pengguna telah memberikan satu izin dari grup, izin lain dari grup yang sama diberikan secara otomatis tanpa dialog tambahan.

Bagaimana cara kerja permintaan runtime

Permintaan runtime adalah mekanisme di mana aplikasi memanggil API sistem untuk menampilkan dialog dengan permintaan izin. Pengguna melihat jendela modal dengan nama izin dan tombol Allow dan Deny. Setelah respons, sistem memanggil callback onRequestPermissionsResult dengan hasilnya.

Siklus lengkap mencakup tiga langkah: pemeriksaan status melalui checkSelfPermission, pemanggilan requestPermissions saat izin tidak ada, dan pemrosesan hasil di onRequestPermissionsResult. Pemeriksaan status wajib dilakukan karena pengguna dapat mencabut izin kapan saja melalui pengaturan, dan memanggil fungsi tanpa pemeriksaan akan menyebabkan 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
            )
        }
    }
}

Pemrosesan hasil terjadi di ActivityResultLauncher atau onRequestPermissionsResult. Pendekatan modern yang direkomendasikan — menggunakan ActivityResultContracts.RequestPermission, yang menyediakan API lebih bersih tanpa kode permintaan eksplisit. Kontrak ini mengembalikan Boolean — apakah izin diberikan atau tidak.

Praktik terbaik permintaan

Mintalah izin berbahaya secara ketat dalam konteks penggunaan fitur, bukan saat memulai aplikasi. Jika pengguna menekan tombol kamera — minta CAMERA. Jika membuka peta — minta LOCATION. Permintaan kontekstual memberikan dua kali lebih banyak persetujuan daripada meminta semua izin saat peluncuran pertama. Juga disarankan untuk tidak meminta lebih dari satu izin sekaligus, sehingga pengguna memahami fitur mana yang memerlukan akses.

Daftar izin berbahaya di Android

Android mendefinisikan beberapa grup izin berbahaya, masing-masing berisi satu hingga beberapa konstanta. Daftar paling lengkap disajikan di kelas Manifest.permission. Di bawah ini adalah grup dan izin utama yang digunakan dalam pengembangan.

Izin baru di Android 12+

Mulai Android 12, Google memperketat persyaratan untuk beberapa izin. Misalnya, BLUETOOTH_CONNECT dan BLUETOOTH_SCAN menjadi berbahaya dan memerlukan permintaan runtime. Juga muncul izin BODY_SENSORS_BACKGROUND untuk akses latar belakang ke sensor. Pengembang harus memperbarui targetSdkVersion dan menguji permintaan pada versi OS saat ini.

Izin untuk Android 13+

Android 13 (API 33) memperkenalkan izin baru untuk notifikasi (POST_NOTIFICATIONS) dan file media (READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_MEDIA_AUDIO), menggantikan READ_EXTERNAL_STORAGE umum. Sekarang akses ke foto, video, dan audio diminta secara terpisah melalui izin khusus tanpa satu dialog tunggal.

Dangerous vs Normal Permission

Dangerous dan Normal Permission secara fundamental berbeda dalam cara pemberian, kemungkinan pencabutan, dan UX. Normal diberikan secara otomatis saat instalasi, Dangerous memerlukan dialog runtime eksplisit. Normal tidak dapat dicabut melalui pengaturan, Dangerous dapat dimatikan kapan saja. Asimetri ini menciptakan pola pengembangan yang berbeda.

Dari segi kode, izin berbahaya memerlukan lebih banyak pekerjaan: checkSelfPermission, requestPermissions, penanganan penolakan. Untuk Normal, satu baris di AndroidManifest.xml sudah cukup. Pada saat yang sama, Dangerous Permission memberi pengguna kontrol, yang meningkatkan kepercayaan, terutama untuk fitur sensitif seperti kamera atau geolokasi.

Pilihan antara kategori tidak ada di tangan pengembang — ditentukan oleh sistem. Pengembang hanya mendeklarasikan uses-permission, dan sistem berdasarkan protectionLevel menentukan kategori. Namun, strategi permintaan izin berbahaya memengaruhi pengalaman pengguna: dialog yang sering atau tidak tepat menurunkan peringkat aplikasi.

Cara meminta izin di Kotlin

Cara modern meminta izin di Kotlin — menggunakan ActivityResultContracts.RequestMultiplePermissions atau RequestPermission. Kontrak-kontrak ini termasuk dalam pustaka androidx.activity dan menyediakan API bersih berbasis lambda, tanpa perlu menimpa 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
                )
        }
    }
}

Meminta beberapa izin sekaligus

Ketika aplikasi memerlukan beberapa izin berbahaya secara bersamaan, gunakan RequestMultiplePermissions. Kontrak mengembalikan Map<String, Boolean> di mana kunci adalah nama izin dan nilai adalah hasilnya. Ini nyaman saat peluncuran pertama ketika perlu meminta CAMERA dan RECORD_AUDIO untuk perekaman video.

Penanganan penolakan pertama kali

Jika pengguna menolak permintaan, metode shouldShowRequestPermissionRationale mengembalikan true. Ini adalah sinyal untuk menampilkan penjelasan mengapa izin diperlukan. Praktik terbaik — menampilkan dialog kustom dengan penjelasan dan tombol Coba Lagi. Jika pengguna menolak lagi permintaan dengan centang Never Ask Again, shouldShowRequestPermissionRationale akan mengembalikan false dan perlu mengarahkan ke Pengaturan.

Penanganan penolakan dan Never Ask Again

Never Ask Again adalah bendera yang dapat diatur pengguna saat menolak dialog runtime untuk kedua kalinya. Setelah itu, dialog standar tidak lagi ditampilkan untuk izin ini. Satu-satunya cara untuk memberikan akses — mengarahkan pengguna ke pengaturan sistem aplikasi.

Pengembang perlu membedakan dua skenario penolakan: pertama — ketika shouldShowRequestPermissionRationale mengembalikan true (pengguna menolak tetapi dialog masih dapat ditampilkan) dan kedua — ketika metode mengembalikan false (Never Ask Again aktif atau izin diblokir oleh kebijakan). Dalam kasus kedua, tombol Buka Pengaturan harus ditampilkan.

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

private fun showSettingsRedirectDialog(permission: String) {
    AlertDialog.Builder(this)
        .setTitle("Akses ditolak")
        .setMessage(
            "Izin diblokir. Buka pengaturan."
        )
        .setPositiveButton("Pengaturan") { _, _ ->
            val intent = Intent(
                Settings.ACTION_APPLICATION_DETAILS_SETTINGS,
                Uri.fromParts(
                    "package", packageName, null
                )
            )
            startActivity(intent)
        }
        .show()
}

Penting untuk tidak meminta izin lagi jika shouldShowRequestPermissionRationale mengembalikan false. Pemanggilan ulang requestPermissions dalam kasus ini tidak akan menampilkan dialog — hasil akan segera datang dengan DENIED tanpa penjelasan. Pengguna akan menghadapi perilaku yang tidak dapat dipahami, yang akan berdampak negatif pada pengalaman menggunakan aplikasi.