Permission Group sa Android — ano ito, mga grupo ng pahintulot at prinsipyo ng paggana

Ano ang Permission Group sa Android

Permission Group — ay isang mekanismo ng sistema ng Android na pinagsasama ang maraming mapanganib na pahintulot sa isang grupo batay sa kanilang functional na layunin. Bawat grupo ay may string identifier, halimbawa android.permission-group.CAMERA o android.permission-group.LOCATION. Lahat ng pahintulot sa loob ng isang grupo ay lohikal na konektado at nagbibigay ng access sa magkakaugnay na function ng device.

Ang mga grupo ng pahintulot ay lumitaw sa Android 6.0 Marshmallow kasama ng runtime request model. Ang kanilang pangunahing layunin ay pasimplehin ang interaksyon sa user: sa halip na isang serye ng mga dialog para sa bawat indibidwal na pahintulot, ang sistema ay nagpapakita ng isang dialog bawat grupo. Kung ang user ay nagbigay ng isang pahintulot mula sa isang grupo, ang iba ay itinuturing na awtomatikong naaprubahan. Ayon sa Android UX Research (2015), nabawasan nito ang bilang ng mga pagtanggi sa unang paglunsad ng 20 porsyento.

Mahalagang maunawaan na ang developer ay hindi maaaring lumikha ng kanyang sariling Permission Group. Ang mga grupo ay paunang natukoy sa antas ng operating system at inilalarawan sa mga permissions.xml file sa bawat device. Ang app ay tumutukoy lamang ng uses-permission, at ang sistema ay awtomatikong itinutugma ang pahintulot sa grupo nito batay sa protectionLevel at pagkakategorya sa AOSP.

Paano tinutukoy ng sistema ang grupo

Ang pagtutugma ng pahintulot sa grupo ay nangyayari sa pamamagitan ng attribute na permissionGroup sa system definition ng pahintulot. Halimbawa, ang CAMERA ay idineklara na may permissionGroup="android.permission-group.CAMERA", ACCESS_FINE_LOCATION — na may permissionGroup="android.permission-group.LOCATION". Ang mapping na ito ay mahigpit na itinakda sa code ng Android Open Source Project at pareho sa lahat ng certified device.

Paano gumagana ang Permission Group

Ang mekanismo ng grupo ay gumagana sa prinsipyong “isang dialog bawat grupo”. Kapag ang app ay humiling ng anumang mapanganib na pahintulot sa unang pagkakataon, sinusuri ng sistema ang Permission Group nito. Kung wala pang pahintulot mula sa grupong ito ang naibigay — ipinapakita ang isang dialog. Pagkatapos ng pagpayag, minamarkahan ng sistema ang buong grupo bilang naibigay, at ang mga susunod na kahilingan ng iba pang pahintulot mula sa parehong grupo ay natutupad nang walang user interface.

Ang algorithm ay ganito ang hitsura:

• Tumawag ang app ng requestPermissions para sa ACCESS_FINE_LOCATION
• Tinutukoy ng sistema ang grupo — android.permission-group.LOCATION
• Sinusuri kung ang grupong LOCATION ay naibigay na dati
• Kung hindi — magpapakita ng dialog na may pangalan ng grupo at listahan ng mga kasamang pahintulot
• Pagkatapos ng Allow — ang buong grupong LOCATION ay itinuturing na naibigay
• Ang ACCESS_COARSE_LOCATION ay available na ngayon nang walang karagdagang kahilingan

Ang mekanismong ito ay nalalapat lamang sa mga mapanganib na pahintulot. Ang mga normal na pahintulot ay walang grupo at hindi nakikilahok sa lohikang ito. Ang mga privileged at signed na pahintulot ay hindi rin pinapangkat — mayroon silang hiwalay na sistema ng pamamahala ng access.

Mga limitasyon ng lohika ng grupo

Ang mga grupo ay hindi gumagana sa reverse: ang pagbawi ng isang pahintulot mula sa isang grupo sa pamamagitan ng mga setting ay binabawi lamang ito, nang hindi naaapektuhan ang iba. Gayundin, kung tinanggihan ng user ang dialog para sa isang grupo, hindi nito hinaharangan ang ibang mga grupo — bawat bagong pahintulot mula sa ibang grupo ay magpapakita ng sarili nitong dialog. Permission Group ay nakakaapekto lamang sa UX ng kahilingan, hindi sa modelo ng seguridad.

Listahan ng Permission Group sa Android

Tinutukoy ng Android ang sumusunod na system Permission Group para sa mga mapanganib na pahintulot. Bawat grupo ay may kasamang isa o higit pang pahintulot na pinag-isa ng isang karaniwang functional na layunin.

Mga pagbabago sa mga bagong bersyon

Sa Android 13 (API 33) lumitaw ang bagong grupo na NEARBY_DEVICES na pinagsasama ang BLUETOOTH_SCAN, BLUETOOTH_CONNECT at BLUETOOTH_ADVERTISE. Gayundin, ang grupong STORAGE ay bahagyang pinalitan ng media permissions na READ_MEDIA_IMAGES, READ_MEDIA_VIDEO at READ_MEDIA_AUDIO, na hindi bahagi ng STORAGE, kundi mga independiyenteng mapanganib na pahintulot nang walang pagpapangkat.

Mga grupo para sa custom na pahintulot

Ang mga developer ay maaaring magdeklara ng kanilang sariling mga pahintulot na may custom na Permission Group sa pamamagitan ng attribute na permissionGroup sa manifest. Ngunit ito ay gumagana lamang para sa custom na pahintulot ng parehong app at hindi nakakaapekto sa system UI dialogs. Sa praktika, ang custom na Permission Group ay bihirang ginagamit — para sa interaksyon sa pagitan ng sariling mga app sa isang stack.

Permission Group at UX

Ang epekto ng Permission Group sa karanasan ng user ay makabuluhan. Dahil sa pagpapangkat, ang user ay nakakakita hindi ng 8 magkahiwalay na dialog para sa iba’t ibang pahintulot, kundi ilang group dialog. Binabawasan nito ang cognitive load at pinabababa ang posibilidad na tanggihan ng user ang isang kritikal na pahintulot nang hindi nauunawaan ang layunin nito.

Ipinapakita ng pananaliksik sa UX na ang mga group dialog ay itinuturing ng mga user na mas transparent. Kapag humihiling ang app ng “access sa camera”, nauunawaan ng user ang konteksto. Kung ang bawat pahintulot ay hiwalay na hihilingin — CAMERA, CAMERA2, FLASHLIGHT — ito ay lilikha ng impresyon ng redundancy. Permission Group ay nag-aabstrak ng detalyeng ito.

Ang pinakamahusay na kasanayan ay humiling ng mga pahintulot lamang mula sa isang grupo sa isang pagkakataon. Kung ang app ay nangangailangan ng parehong camera at geolokasyon, huwag hilingin ang mga ito sa isang tawag na requestPermissions. Unang humiling ng isang grupo pagkatapos ng paliwanag, pagkatapos ang pangalawa. Ito ay nagbibigay sa user ng kontrol at sunud-sunod na pag-unawa sa bawat function.

Permission Group vs ProtectionLevel

Permission Group at ProtectionLevel — ito ay dalawang magkaibang dimensyon ng sistema ng pahintulot ng Android. Tinutukoy ng ProtectionLevel kung paano ibinibigay ang pahintulot (normal, dangerous, signature, privileged), at ang Permission Group ay isang kategorya para sa UI display. Ang mga ito ay independiyente, ngunit sa praktika, ang kombinasyon ng dangerous + permission group ang pinakamadalas mangyari.

Ang mga pahintulot ng parehong ProtectionLevel ay maaaring mapabilang sa iba’t ibang grupo. Halimbawa, ang ACCESS_FINE_LOCATION at CAMERA ay parehong may protectionLevel dangerous, ngunit nabibilang sa magkaibang grupo — LOCATION at CAMERA. At kabaligtaran, ang mga pahintulot na may parehong pangalan ay palaging nabibilang sa parehong grupo: ang ACCESS_FINE_LOCATION at ACCESS_COARSE_LOCATION ay pareho sa LOCATION.

Ang mas mataas na antas ng proteksyon — signature at privileged — ay hindi gumagamit ng Permission Group para sa UI. Ang kanilang pagbibigay ay kinokontrol sa antas ng sistema: ang signature ay ibinibigay sa mga app na naka-sign gamit ang parehong certificate ng sistema, at ang privileged ay ibinibigay sa mga app sa system image. Ang mga grupo para sa naturang mga pahintulot ay umiiral, ngunit hindi nakakaapekto sa UX dialogs, dahil ang mga dialog na ito ay wala.

Pagsusuri ng Permission Group sa code

Maaaring matukoy ng developer ang Permission Group ng anumang pahintulot sa pamamagitan ng PackageManager. Ang paraang getPermissionInfo ay nagbabalik ng PermissionInfo na may field na group na naglalaman ng string identifier ng grupo. Ito ay kapaki-pakinabang para sa logging, analytics at custom na UI screen ng pahintulot.

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

Paggamit sa DI at arkitektura

Ang kaalaman sa Permission Group ay tumutulong sa pagbuo ng arkitektura ng kahilingan. Maaaring lumikha ng abstraction na PermissionGroupProvider na nagbabalik ng listahan ng mga pahintulot para sa isang partikular na grupo. Pinapasimple nito ang pagsubok: sa mga unit test, ang provider ay nagbabalik ng pekeng data nang hindi tumatawag sa PackageManager. Sa mga instrumental na test — mga tunay na grupo mula sa sistema.

PermissionGroupProvider sa DI

Ang pagsasama ng PermissionGroupProvider sa pamamagitan ng Dagger Hilt o Koin ay nagbibigay-daan sa sentralisadong pamamahala ng pagmamapa ng mga pahintulot at grupo. Sa provider, ang resulta ng PackageManager.queryPermissionsByGroup ay maaaring i-cache upang maiwasan ang paulit-ulit na tawag sa sistema sa bawat kahilingan. Ito ay lalong mahalaga para sa mga screen ng setting kung saan ipinapakita ang buong listahan ng mga pahintulot at ang kanilang status.

Logging at analytics

Kapag nangongolekta ng analytics tungkol sa mga pagtanggi, kapaki-pakinabang na i-log hindi lamang ang pangalan ng pahintulot kundi pati na rin ang Permission Group nito. Nakakatulong ito na matukoy ang mga functional na lugar na nagdudulot ng pinakamaraming pagtanggi. Halimbawa, ang grupong LOCATION ay tradisyonal na may pinakamataas na porsyento ng pagtanggi — mga 40 porsyento, ayon sa mga istatistika ng Google Play Console.

Ang analytics bawat grupo ay tumutulong sa paggawa ng mga desisyon ng produkto: kung ang grupong CONTACTS ay may mataas na porsyento ng pagtanggi, marahil ay dapat muling isaalang-alang ang oras ng kahilingan o magdagdag ng dialog ng paliwanag. Ang approach na nakabatay sa grupo sa analytics ay nagbibigay ng mas kumpletong larawan kaysa sa pagsusuri ng indibidwal na pahintulot, dahil ang bilang ng mga pagtanggi para sa buong grupo ay sumasalamin sa pangkalahatang saloobin ng mga user sa functional na lugar.