Dangerous Permission sa Android: esensya, listahan ng mga pahintulot at runtime na kahilingan

Ano ang Dangerous Permission sa Android

Dangerous Permission ay isang kategorya ng mga pahintulot ng system ng Android na nagbibigay ng access sa mga kumpidensyal na data ng gumagamit. Hindi tulad ng mga normal na pahintulot, ang mga mapanganib na pahintulot ay hindi awtomatikong ibinibigay sa pag-install — ang application ay dapat na malinaw na humiling sa kanila sa panahon ng runtime sa pamamagitan ng mekanismo na ipinakilala sa Android 6.0 Marshmallow (API 23).

Ang pangangailangan para sa malinaw na kahilingan ay dahil sa kalikasan ng data na pinoprotektahan ng mga pahintulot na ito: geolokasyon ng gumagamit, personal na mga contact, nilalaman ng camera at mikropono, kasaysayan ng tawag at SMS. Itinuturing ng Android ang data na ito bilang sensitibo at nangangailangan ng may kamalayang pahintulot ng gumagamit. Ayon sa Android Privacy Sandbox (2024), tinatanggihan ng mga gumagamit ang humigit-kumulang 30 porsyento ng mga runtime na kahilingan sa karaniwan.

Ang pangunahing tampok ng Dangerous Permission — posibilidad ng pagbawi anumang oras. Maaaring pumunta ang gumagamit sa Mga Setting — Mga Application — Mga Pahintulot at ilipat ang switch para sa anumang mapanganib na pahintulot. Ang application ay dapat maging handa na ang pahintulot na ibinigay ay maaaring bawiin anumang oras nang walang restart.

ProtectionLevel dangerous

Ang antas ng proteksyon dangerous ay itinakda sa mga system definition ng mga pahintulot sa antas ng OS. Kapag ang application ay nagdeklara ng uses-permission na may ganitong protectionLevel, minamarkahan ng system ang pahintulot bilang nangangailangan ng runtime na kahilingan. Hindi tulad ng normal, ang mga dangerous na pahintulot ay palaging ipinapakita sa system UI ng pamamahala ng pahintulot at maaaring bawiin.

Permission Group at Dangerous

Ang lahat ng mga mapanganib na pahintulot ay pinagsama-sama sa Permission Group ayon sa functional na katangian. Halimbawa, ang CAMERA at CAMERA2 ay nasa grupong CAMERA, ang ACCESS_FINE_LOCATION at ACCESS_COARSE_LOCATION — sa grupong LOCATION. Kung ang gumagamit ay nagbigay ng isang pahintulot mula sa grupo, ang iba pang mga pahintulot ng parehong grupo ay awtomatikong ibinibigay nang walang karagdagang dialog.

Paano gumagana ang runtime na kahilingan

Ang runtime na kahilingan ay ang mekanismo kung saan tinatawag ng application ang system API upang magpakita ng dialog na may kahilingan para sa pahintulot. Nakikita ng gumagamit ang isang modal window na may pangalan ng pahintulot at mga pindutan ng Allow at Deny. Pagkatapos ng tugon, tinatawag ng system ang callback na onRequestPermissionsResult na may resulta.

Ang buong cycle ay may kasamang tatlong hakbang: pagsusuri ng status sa pamamagitan ng checkSelfPermission, pagtawag ng requestPermissions kapag walang pahintulot at pagproseso ng resulta sa onRequestPermissionsResult. Ang pagsusuri ng status ay sapilitan dahil maaaring bawiin ng gumagamit ang pahintulot anumang oras sa pamamagitan ng mga setting, at ang pagtawag ng function nang walang pagsusuri ay hahantong sa 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
            )
        }
    }
}

Ang pagproseso ng resulta ay nagaganap sa ActivityResultLauncher o onRequestPermissionsResult. Ang inirerekomendang modernong diskarte — paggamit ng ActivityResultContracts.RequestPermission, na nagbibigay ng mas malinis na API nang walang mga explicit na code ng kahilingan. Ang kontratang ito ay nagbabalik ng Boolean — kung ang pahintulot ay ibinigay o hindi.

Pinakamahusay na kasanayan sa paghiling

Humingi ng mga mapanganib na pahintulot nang mahigpit sa konteksto ng paggamit ng function, hindi sa pagsisimula ng application. Kung pinindot ng gumagamit ang pindutan ng camera — humingi ng CAMERA. Kung binuksan niya ang mapa — humingi ng LOCATION. Ang kontekstuwal na kahilingan ay nagbibigay ng dalawang beses na mas maraming pag-apruba kaysa sa paghiling ng lahat ng pahintulot sa unang paglunsad. Inirerekomenda din na huwag humingi ng higit sa isang pahintulot sa isang pagkakataon, upang maunawaan ng gumagamit kung aling function ang nangangailangan ng access.

Listahan ng mga mapanganib na pahintulot sa Android

Tinutukoy ng Android ang ilang grupo ng mga mapanganib na pahintulot, bawat isa ay naglalaman ng isa hanggang ilang constants. Ang pinakakumpletong listahan ay nasa klase ng Manifest.permission. Nasa ibaba ang mga pangunahing grupo at pahintulot na ginagamit sa pag-develop.

Mga bagong pahintulot sa Android 12+

Simula sa Android 12, pinahigpit ng Google ang mga kinakailangan para sa ilang pahintulot. Halimbawa, ang BLUETOOTH_CONNECT at BLUETOOTH_SCAN ay naging mapanganib at nangangailangan ng runtime na kahilingan. Lumitaw din ang pahintulot na BODY_SENSORS_BACKGROUND para sa background na access sa mga sensor. Ang mga developer ay kailangang mag-update ng targetSdkVersion at subukan ang mga kahilingan sa kasalukuyang mga bersyon ng OS.

Mga pahintulot para sa Android 13+

Ang Android 13 (API 33) ay nagpakilala ng mga bagong pahintulot para sa mga notification (POST_NOTIFICATIONS) at para sa mga media file (READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_MEDIA_AUDIO), na pumalit sa pangkalahatang READ_EXTERNAL_STORAGE. Ngayon ang access sa mga larawan, video at audio ay hinihiling nang hiwalay sa pamamagitan ng mga espesyalisadong pahintulot nang walang iisang dialog.

Dangerous vs Normal Permission

Ang Dangerous at Normal Permission ay pangunahing naiiba sa paraan ng pagbibigay, posibilidad ng pagbawi at UX. Ang Normal ay awtomatikong ibinibigay sa pag-install, ang Dangerous ay nangangailangan ng explicit na runtime dialog. Ang Normal ay hindi maaaring bawiin sa pamamagitan ng mga setting, ang Dangerous ay maaaring patayin anumang oras. Ang asimetrya na ito ay naglalatag ng iba't ibang pattern ng pag-develop.

Mula sa pananaw ng code, ang mga mapanganib na pahintulot ay nangangailangan ng mas maraming trabaho: checkSelfPermission, requestPermissions, paghawak ng pagtanggi. Para sa Normal, sapat na ang isang linya sa AndroidManifest.xml. Kasabay nito, ang Dangerous Permission ay nagbibigay sa gumagamit ng kontrol, na nagpapataas ng tiwala, lalo na para sa mga sensitibong function tulad ng camera o geolokasyon.

Ang pagpili sa pagitan ng mga kategorya ay wala sa harap ng developer — ito ay tinutukoy ng system. Ang developer ay nagdedeklara lamang ng uses-permission, at ang system batay sa protectionLevel ay tinutukoy ang kategorya. Gayunpaman, ang estratehiya ng paghiling ng mga mapanganib na pahintulot ay nakakaapekto sa karanasan ng gumagamit: ang madalas o hindi naaangkop na mga dialog ay nagpapababa ng rating ng application.

Paano humiling ng mga pahintulot sa Kotlin

Ang modernong paraan ng paghiling ng mga pahintulot sa Kotlin — paggamit ng ActivityResultContracts.RequestMultiplePermissions o RequestPermission. Ang mga kontratang ito ay bahagi ng library ng androidx.activity at nagbibigay ng malinis na API batay sa lambda, nang hindi kinakailangang i-override ang 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
                )
        }
    }
}

Paghiling ng maraming pahintulot nang sabay-sabay

Kapag ang application ay nangangailangan ng maraming mapanganib na pahintulot nang sabay-sabay, gamitin ang RequestMultiplePermissions. Ang kontrata ay nagbabalik ng Map<String, Boolean> kung saan ang susi ay ang pangalan ng pahintulot at ang halaga ay ang resulta. Ito ay maginhawa sa unang paglunsad kapag kailangan humingi ng CAMERA at RECORD_AUDIO para sa pag-record ng video.

Paghawak ng pagtanggi sa unang pagkakataon

Kung tinanggihan ng gumagamit ang kahilingan, ang pamamaraang shouldShowRequestPermissionRationale ay nagbabalik ng true. Ito ay isang senyales upang magpakita ng paliwanag kung bakit kailangan ang pahintulot. Pinakamahusay na kasanayan — magpakita ng custom na dialog na may paliwanag at pindutan ng Subukan Muli. Kung ang gumagamit ay muling tinanggihan ang kahilingan na may check sa Never Ask Again, ang shouldShowRequestPermissionRationale ay magbabalik ng false at kailangang i-redirect sa Mga Setting.

Paghawak ng pagtanggi at Never Ask Again

Never Ask Again ay isang flag na maaaring itakda ng gumagamit kapag muling tinatanggihan ang runtime dialog. Pagkatapos nito, ang standard na dialog window ay hindi na ipinapakita para sa pahintulot na ito. Ang tanging paraan upang magbigay ng access — i-redirect ang gumagamit sa system settings ng mga application.

Kailangan ng developer na makilala ang dalawang senaryo ng pagtanggi: una — kapag ang shouldShowRequestPermissionRationale ay nagbabalik ng true (tinanggihan ng gumagamit ngunit ang dialog ay maaari pa ring ipakita) at pangalawa — kapag ang pamamaraan ay nagbabalik ng false (Never Ask Again ay aktibo o ang pahintulot ay hinarang ng patakaran). Sa pangalawang kaso, dapat ipakita ang pindutan ng Buksan ang Mga Setting.

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

private fun showSettingsRedirectDialog(permission: String) {
    AlertDialog.Builder(this)
        .setTitle("Ipinagbabawal ang pag-access")
        .setMessage(
            "Naka-block ang permission. Buksan ang mga setting."
        )
        .setPositiveButton("Mga Setting") { _, _ ->
            val intent = Intent(
                Settings.ACTION_APPLICATION_DETAILS_SETTINGS,
                Uri.fromParts(
                    "package", packageName, null
                )
            )
            startActivity(intent)
        }
        .show()
}

Mahalaga na huwag humiling muli ng pahintulot kung ang shouldShowRequestPermissionRationale ay nagbalik ng false. Ang paulit-ulit na pagtawag ng requestPermissions sa kasong ito ay hindi magpapakita ng dialog — ang resulta ay darating kaagad na may DENIED nang walang paliwanag. Ang gumagamit ay haharap sa hindi maintindihang pag-uugali, na negatibong makakaapekto sa karanasan ng paggamit ng application.