AndroidManifest Permissions: mga pangunahing konsepto, deklarasyon at mga uri ng pahintulot

Ano ang AndroidManifest Permissions?

Ang AndroidManifest Permissions ay ang mekanismo ng seguridad ng Android na kumokontrol sa pag-access ng mga app sa protektadong data at mga function ng system. Ang bawat app ay dapat magdeklara ng mga kinakailangang pahintulot sa file na AndroidManifest.xml gamit ang elementong <uses-permission>. Kung walang deklarasyon, ang pagtawag sa kaukulang API ay magtatapos sa error sa seguridad na SecurityException.

Ang modelo ng pahintulot ng Android ay dumaan sa ilang yugto ng ebolusyon. Bago ang Android 6.0 (API 23), lahat ng pahintulot ay ibinibigay sa pag-install — nakita ng user ang buong listahan at pumayag o tumanggi sa pag-install ng app. Simula sa Android 6.0, ang mga pahintulot na antas dangerous ay hinihiling habang tumatakbo (Runtime Permissions), na nagbibigay sa user ng mas nababaluktot na kontrol.

Ang mga pahintulot ay nahahati sa apat na antas ng proteksyon: normal (awtomatikong ibinibigay sa pag-install), dangerous (nangangailangan ng runtime na kahilingan), signature (magagamit lamang sa mga app na naka-sign ng parehong certificate) at special (nangangailangan ng hiwalay na pag-activate sa mga setting). Ang bawat antas ay may sariling mekanismo ng pagbibigay at pagbawi.

Ayon sa Google I/O 2024, sa Android 15 ay pinlano ang pagpapakilala ng mas granular na mga pahintulot — ang user ay maaaring magbigay ng access lamang sa mga tiyak na file sa media library, hindi sa buong library. Ipinagpapatuloy nito ang trend ng Android na bawasan ang dami ng data na ibinibigay bilang default.

Pagkakaiba sa modelo ng pahintulot ng iOS

Hindi tulad ng iOS kung saan lahat ng pahintulot ay hinihiling habang tumatakbo (runtime), hinahati ng Android ang mga pahintulot sa install-time at runtime. Ang antas normal ay awtomatikong ibinibigay sa pag-install nang walang abiso sa user. Ang antas dangerous ay nangangailangan ng tahasang dialog, tulad ng sa iOS.

Isa pang pagkakaiba: sa Android, ang mga pahintulot ay pinagsama-sama sa mga grupo (permission groups). Kung pumayag ang user sa pag-access sa camera, awtomatikong makakakuha ng access ang app sa mikropono — pareho sila sa iisang grupong MICROPHONE. Sa iOS, ang bawat pahintulot ay hinihiling nang hiwalay, independiyente sa grupo.

Ebolusyon ng mga pahintulot ayon sa bersyon ng Android

Anong mga uri ng pahintulot ang mayroon

Tinutukoy ng Android ang apat na antas ng proteksyon (protection levels) para sa mga pahintulot, bawat isa ay may sariling mga patakaran sa pagbibigay. Suriin natin ang bawat antas nang detalyado.

Normal Permissions (install-time)

Ang mga normal na pahintulot ay awtomatikong ibinibigay sa pag-install ng app nang walang abiso o kahilingan mula sa user. Sinasaklaw nila ang access sa mga function na may mababang panganib na hindi nagbabanta sa privacy ng user: INTERNET, ACCESS_NETWORK_STATE, VIBRATE, BLUETOOTH. Hindi nakikita ng user ang dialog ng pahintulot — ang pahintulot ay itinuturing na ibinigay sa pamamagitan ng pag-install.

Ang developer ay hindi kailangang magproseso ng kahilingan sa code para sa normal na pahintulot — sapat na na ideklara ang mga ito sa manifest. Gayunpaman, sa Android 12+ sa pag-install mula sa Google Play, nakikita ng user ang tab na “Mga Pahintulot” na may listahan ng lahat ng normal na pahintulot, na nagpapataas ng transparency. Ayon sa Statista (2024), higit sa 90% ng mga app sa Google Play ay gumagamit ng INTERNET bilang pinakakaraniwang normal na pahintulot.

Dangerous Permissions (runtime)

Ang mga dangerous na pahintulot ay sumasaklaw sa access sa data at function na maaaring lumabag sa privacy: camera, mikropono, geolocation, contact, SMS, telepono, kalendaryo, body sensor. Ang mga pahintulot na ito ay nangangailangan ng dalawang-hakbang na mekanismo: deklarasyon sa manifest + kahilingan habang tumatakbo sa pamamagitan ng ActivityCompat.requestPermissions().

Maaaring tanggihan ng user ang pagbibigay ng dangerous na pahintulot, at dapat na maayos na pangasiwaan ng app ang sitwasyong ito. Sa Android 11+, kung dalawang beses tumanggi ang user, ang mga sumusunod na kahilingan ay hindi magpapakita ng system dialog — awtomatikong nagbabalik ang system ng DENIED. Sa kasong ito, kailangan mong idirekta ang user sa mga setting.

Signature at Special Permissions

Ang antas na signature — ang pahintulot ay awtomatikong ibinibigay kung ang app ay naka-sign ng parehong certificate gaya ng system o ibang app na tumukoy ng pahintulot. Ginagamit para sa system at corporate na app. Halimbawa: BIND_ACCESSIBILITY_SERVICE — magagamit lamang sa mga system app.

Ang antas na special (SYSTEM_ALERT_WINDOW, WRITE_SETTINGS, REQUEST_INSTALL_PACKAGES, MANAGE_EXTERNAL_STORAGE) — nangangailangan ng hiwalay na aksyon ng user sa pamamagitan ng system setting. Maaaring buksan ng app ang pahina ng setting gamit ang Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION). Nililimitahan ng Google Play ang paggamit ng special na pahintulot at nangangailangan ng katwiran sa form sa pag-publish.

Runtime Permission: pagtatrabaho sa mga dangerous na pahintulot

Simula sa Android 6.0, lahat ng dangerous na pahintulot ay nangangailangan ng kahilingan habang tumatakbo. Suriin natin ang buong siklo ng trabaho na may runtime permissions sa Kotlin.

Pagsusuri at paghiling ng pahintulot

Bago tumawag ng API na nangangailangan ng dangerous na pahintulot, laging suriin ang kasalukuyang status sa pamamagitan ng ContextCompat.checkSelfPermission(). Kung ang status ay PERMISSION_GRANTED — maaaring tawagin ang API. Kung PERMISSION_DENIED — dapat hilingin ang pahintulot sa pamamagitan ng ActivityResultContract RequestPermission (AndroidX) o hindi na ginagamit na requestPermissions().

Inirerekomenda na gamitin ang ActivityResultContracts.RequestMultiplePermissions para sabay-sabay na humiling ng maraming pahintulot. Inirerekomenda ng Google ang pag-grupo ng mga kaugnay na pahintulot (hal. camera + mikropono para sa pag-record ng video) sa isang dialog, upang makita ng user ang buong konteksto ng kahilingan.

import android.Manifest
import android.content.pm.PackageManager
import androidx.activity.result.contract.ActivityResultContracts
import androidx.core.content.ContextCompat

class CameraActivity : AppCompatActivity() {
    private val requestPermissionLauncher =
        registerForActivityResult(
            ActivityResultContracts.RequestPermission()
        ) { isGranted: Boolean ->
            if (isGranted) {
                openCamera()
            } else {
                explainWhyPermissionNeeded()
            }
        }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        checkCameraPermission()
    }

    private fun checkCameraPermission() {
        when {
            ContextCompat.checkSelfPermission(this,
                Manifest.permission.CAMERA
            ) == PackageManager.PERMISSION_GRANTED -> {
                openCamera()
            }
            shouldShowRequestPermissionRationale(
                Manifest.permission.CAMERA
            ) -> {
                showRationale()
            }
            else -> {
                requestPermissionLauncher.launch(
                    Manifest.permission.CAMERA
                )
            }
        }
    }
}

Pangangasiwa sa pagtanggi na “Don’t ask again”

Kung dalawang beses tumanggi ang user, inililipat ng Android ang kahilingan sa status na “Never ask again”. Sa kasong ito, nagbabalik ang shouldShowRequestPermissionRationale() ng false, at hindi ipapakita ang system dialog. Dapat idirekta ng app ang user sa system setting sa pamamagitan ng Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS).

Mahalaga: huwag magpakita ng dialog na nag-aalok na buksan ang mga setting kaagad pagkatapos ng unang pagtanggi — ito ay itinuturing na agresibong pag-uugali. Gamitin ang shouldShowRequestPermissionRationale() upang matukoy kung kailangan magpakita ng paliwanag. Material Design Guidelines ay nagrerekomenda na magpakita ng screen na may paliwanag ng halaga ng access, hindi lamang isang button na “Buksan ang mga setting”.

private fun openAppSettings() {
    Intent(
        Settings.ACTION_APPLICATION_DETAILS_SETTINGS,
        Uri.fromParts("package", packageName, null)
    ).also { intent ->
        startActivity(intent)
    }
}

private fun showPermissionSettings() {
    AlertDialog.Builder(this)
        .setTitle("Access sa camera")
        .setMessage("Payagan ang access sa camera sa Mga Setting, "
            + "upang kumuha ng litrato para sa profile")
        .setPositiveButton("Buksan ang mga setting") { _, _ ->
            openAppSettings()
        }
        .setNegativeButton("Kanselahin", null)
        .show()
}

Deklarasyon ng mga pahintulot sa AndroidManifest.xml

Ang file na AndroidManifest.xml ay naglalaman ng elementong <uses-permission> para sa bawat pahintulot na ginagamit ng app. Ang mga pahintulot ay idinedeklara sa antas ng <manifest> bago ang elementong <application>.

Sintaks ng deklarasyon

Ang bawat pahintulot ay idinedeklara bilang isang hiwalay na elementong <uses-permission> na may attribute na android:name na nagpapakita ng buong pangalan ng pahintulot. Para sa mga pahintulot na lumitaw sa mga tiyak na bersyon ng Android, gamitin ang attribute na maxSdkVersion upang limitahan ang deklarasyon sa mga kinakailangang bersyon lamang — ito ay nagpapabuti sa compatibility.

Halimbawa, ang pahintulot na WRITE_EXTERNAL_STORAGE ay hindi kailangan sa Android 10+ (Scoped Storage), kaya tukuyin ang maxSdkVersion=“28” (Android 9). Ito ay pumipigil sa mga hindi kinakailangang tanong mula sa mga user sa mga bagong bersyon. Android Studio ay nagbabala tungkol sa inirerekomendang maxSdkVersion sa pamamagitan ng Lint.

<!-- AndroidManifest.xml -->
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android">

    <!-- Normal permissions (install-time) -->
    <uses-permission
        android:name="android.permission.INTERNET" />
    <uses-permission
        android:name="android.permission.ACCESS_NETWORK_STATE" />

    <!-- Dangerous permissions (runtime) -->
    <uses-permission
        android:name="android.permission.CAMERA" />
    <uses-permission
        android:name="android.permission.ACCESS_FINE_LOCATION" />

    <!-- Legacy storage permission limited to API 28 and below -->
    <uses-permission
        android:name="android.permission.WRITE_EXTERNAL_STORAGE"
        android:maxSdkVersion="28" />

    <uses-feature
        android:name="android.hardware.camera"
        android:required="false" />

    <application>
        <!-- ... -->
    </application>
</manifest>

Paggamit ng <uses-feature> para sa pag-filter

Ang elementong <uses-feature> ay tumutukoy na ang app ay nangangailangan ng tiyak na hardware (camera, GPS, NFC). Ang attribute na android:required=“false” ay nagpapahintulot sa pag-install ng app sa mga device na walang hardware na ito — ang pagsusuri ng availability ay ginagawa sa code. Kung required=“true”, ini-filter ng Google Play ang app at ito ay nagiging hindi available para sa hindi angkop na mga device.

Inirerekomenda na para sa lahat ng hardware function ay tukuyin ang required=“false” at suriin ang availability nang programmatically sa pamamagitan ng PackageManager.hasSystemFeature(). Pinapalawak nito ang audience ng iyong app. Ang tanging exception ay kapag ang function ay kritikal para sa operasyon ng app (ang app sa pag-order ng taxi na walang GPS ay walang saysay).

Mga pinakamahusay na kasanayan at pagkakamali

Ang tamang pagtatrabaho sa mga pahintulot ay isang pangunahing aspeto ng kalidad ng Android app. Suriin natin ang mga pangunahing rekomendasyon at karaniwang pagkakamali.

Pag-minimize ng mga hinihiling na pahintulot

Humiling lamang ng mga pahintulot na talagang kinakailangan para sa operasyon ng app. Ang bawat karagdagang pahintulot ay nagbabawas ng conversion ng pag-install at nagpapataas ng bilang ng mga pagtanggi. Google Play Console ay nagpapakita kung ilang user ang tumigil sa pag-install dahil sa set ng pahintulot. Ayon sa AppBrain (2024), ang mga app na may 10+ dangerous na pahintulot ay may 35% mas kaunting pag-install.

Regular na suriin ang listahan ng pahintulot. Alisin ang mga hindi ginagamit, lalo na kapag lumilipat sa mga bagong bersyon ng Android kung saan ang ilang pahintulot ay naging opsiyonal. Halimbawa, sa pagdating ng photo picker (ActivityResultContracts.PickVisualMedia) sa Android 13+, ang access sa media library ay maaaring makuha nang walang dangerous na pahintulot na READ_MEDIA_IMAGES.

Pagpapakita ng rationale bago ang kahilingan

Bago humiling ng dangerous na pahintulot, magpakita sa user ng screen na may paliwanag kung bakit kailangan ang pahintulot na ito at kung anong halaga ang ibinibigay nito. Material Design ay nagrerekomenda ng paggamit ng bottom sheet o dialog na may icon, maikling teksto at button na “Magpatuloy”. Ang rationale ay nagpapataas ng pahintulot ng 20–30% kumpara sa direktang kahilingan.

Suriin ang shouldShowRequestPermissionRationale() bago tumawag ng launch(). Kung ito ay true — magpakita ng rationale. Kung ito ay false — alinman sa pahintulot ay naibigay na o ang user ay permanenteng tumanggi (never ask again). Sa huling kaso, magpakita ng button na “Buksan ang mga setting”, huwag ulitin ang kahilingan.

Pagsubok ng lahat ng sitwasyon ng pahintulot

Subukan ang lahat ng posibleng sitwasyon: pagbibigay ng pahintulot, pagtanggi, permanenteng pagtanggi, pagbawi ng pahintulot sa mga setting, pag-reset ng pahintulot (Android 11+ auto-reset). Bawat sitwasyon ay dapat pangasiwaan nang walang crash at walang pagkawala ng data. Android Testing Guide ay nagrerekomenda ng paggamit ng TestPermission library para sa pag-automate ng pagsubok.

Bigyan ng espesyal na atensyon ang sitwasyon kung kailan binawi ng user ang pahintulot habang tumatakbo ang app (na-minimize na app → Mga Setting → pagbawi). Sa pagbalik sa app, suriin muli ang lahat ng pahintulot sa pamamagitan ng onResume(). Huwag umasa sa pag-cache ng status ng pahintulot — maaaring baguhin ito ng user anumang oras.

Mga karaniwang pagkakamali

• Paghiling ng pahintulot nang walang paunang pagsusuri ng checkSelfPermission — nagdudulot ng hindi kinakailangang dialog
• Pagwalang-bahala sa shouldShowRequestPermissionRationale — nagpapalala ng UX pagkatapos ng unang pagtanggi
• Paghiling ng pahintulot nang walang konteksto (“Payagan ang access?” lamang) — nagbabawas ng pahintulot
• Paggamit ng WRITE_EXTERNAL_STORAGE sa Android 10+ nang walang maxSdkVersion — hindi kinakailangang kahilingan
• Kawalan ng pagsusuri ng pahintulot sa onResume — pag-miss sa pagbawi ng pahintulot sa mga setting