Android में Permission Group — यह क्या है, अनुमति समूह और कार्य सिद्धांत

Android में Permission Group क्या है

Permission Group Android का एक सिस्टम तंत्र है जो कई खतरनाक अनुमतियों को उनके कार्यात्मक उद्देश्य के आधार पर एक समूह में जोड़ता है। प्रत्येक समूह का एक स्ट्रिंग पहचानकर्ता होता है, उदाहरण के लिए android.permission-group.CAMERA या android.permission-group.LOCATION। एक समूह के भीतर सभी अनुमतियाँ तार्किक रूप से संबंधित होती हैं और डिवाइस के संबंधित कार्यों तक पहुँच प्रदान करती हैं।

अनुमति समूह Android 6.0 Marshmallow में रनटाइम अनुरोध मॉडल के साथ दिखाई दिए। इनका मुख्य उद्देश्य उपयोगकर्ता के साथ बातचीत को सरल बनाना है: प्रत्येक व्यक्तिगत अनुमति के लिए संवादों की श्रृंखला के बजाय, सिस्टम प्रति समूह एक संवाद दिखाता है। यदि उपयोगकर्ता ने समूह से एक अनुमति प्रदान की है, तो बाकी स्वचालित रूप से स्वीकृत मानी जाती हैं। Android UX Research (2015) के अनुसार, इसने पहले लॉन्च पर अस्वीकृतियों की संख्या को 20 प्रतिशत तक कम कर दिया।

यह समझना महत्वपूर्ण है कि डेवलपर अपने स्वयं के Permission Group नहीं बना सकता। समूह ऑपरेटिंग सिस्टम स्तर पर पूर्वनिर्धारित होते हैं और प्रत्येक डिवाइस पर permissions.xml फ़ाइलों में वर्णित होते हैं। एप्लिकेशन केवल uses-permission घोषित करता है, और सिस्टम स्वचालित रूप से protectionLevel और AOSP में वर्गीकरण के आधार पर अनुमति को उसके समूह से मैप करता है।

सिस्टम समूह कैसे निर्धारित करता है

अनुमति का समूह से मिलान सिस्टम अनुमति परिभाषा में permissionGroup विशेषता के माध्यम से होता है। उदाहरण के लिए, CAMERA को permissionGroup="android.permission-group.CAMERA" के साथ घोषित किया गया है, ACCESS_FINE_LOCATION को permissionGroup="android.permission-group.LOCATION" के साथ। यह मैपिंग Android Open Source Project कोड में हार्डकोडेड है और सभी प्रमाणित उपकरणों पर समान है।

Permission Group कैसे काम करते हैं

समूह तंत्र “प्रति समूह एक संवाद” के सिद्धांत पर काम करता है। जब कोई एप्लिकेशन पहली बार कोई खतरनाक अनुमति माँगता है, तो सिस्टम उसके Permission Group की जाँच करता है। यदि इस समूह से अभी तक कोई अनुमति प्रदान नहीं की गई है — तो एक संवाद दिखाया जाता है। सहमति के बाद, सिस्टम पूरे समूह को प्रदान किया हुआ चिह्नित करता है, और उसी समूह से अन्य अनुमतियों के बाद के अनुरोध बिना UI के पूरे होते हैं।

सरलीकृत एल्गोरिदम इस प्रकार दिखता है:

• एप्लिकेशन ACCESS_FINE_LOCATION के लिए requestPermissions कॉल करता है
• सिस्टम समूह निर्धारित करता है — android.permission-group.LOCATION
• जाँच करता है कि LOCATION समूह पहले प्रदान किया गया है या नहीं
• यदि नहीं — समूह नाम और शामिल अनुमतियों की सूची के साथ एक संवाद दिखाता है
• Allow के बाद — पूरा LOCATION समूह प्रदान माना जाता है
• ACCESS_COARSE_LOCATION अब अतिरिक्त अनुरोध के बिना उपलब्ध है

यह तंत्र केवल खतरनाक अनुमतियों पर लागू होता है। सामान्य अनुमतियों के समूह नहीं होते और वे इस तर्क में भाग नहीं लेतीं। विशेषाधिकार प्राप्त और हस्ताक्षरित अनुमतियाँ भी समूहित नहीं की जाती हैं — उनकी पहुँच नियंत्रण की अलग प्रणाली होती है।

समूह तर्क की सीमाएँ

समूह “उल्टा” काम नहीं करते: सेटिंग्स के माध्यम से समूह से एक अनुमति रद्द करने से केवल वह अनुमति रद्द होती है, बाकी प्रभावित नहीं होतीं। साथ ही, यदि उपयोगकर्ता किसी समूह के संवाद को अस्वीकार करता है, तो यह अन्य समूहों को अवरुद्ध नहीं करता — प्रत्येक नई अनुमति दूसरे समूह से अपना स्वयं का संवाद दिखाएगी। Permission Group केवल अनुरोध UX को प्रभावित करता है, सुरक्षा मॉडल को नहीं।

Android में Permission Group की सूची

Android निम्नलिखित सिस्टम Permission Group को खतरनाक अनुमतियों के लिए परिभाषित करता है। प्रत्येक समूह में एक या अधिक अनुमतियाँ शामिल होती हैं जो एक सामान्य कार्यात्मक उद्देश्य से एकजुट होती हैं।

नए संस्करणों में बदलाव

Android 13 (API 33) पर, एक नया समूह NEARBY_DEVICES दिखाई दिया, जो BLUETOOTH_SCAN, BLUETOOTH_CONNECT और BLUETOOTH_ADVERTISE को जोड़ता है। साथ ही, STORAGE समूह को आंशिक रूप से मीडिया अनुमतियों READ_MEDIA_IMAGES, READ_MEDIA_VIDEO और READ_MEDIA_AUDIO से बदल दिया गया, जो STORAGE का हिस्सा नहीं हैं बल्कि समूहीकरण के बिना स्वतंत्र खतरनाक अनुमतियाँ हैं।

कस्टम अनुमति समूह

डेवलपर मैनिफ़ेस्ट में permissionGroup विशेषता के माध्यम से कस्टम Permission Group के साथ अपनी स्वयं की अनुमतियाँ घोषित कर सकते हैं। हालाँकि, यह केवल उसी एप्लिकेशन की कस्टम अनुमतियों के लिए काम करता है और सिस्टम UI संवादों को प्रभावित नहीं करता। व्यवहार में, कस्टम Permission Group का उपयोग शायद ही कभी किया जाता है — एक ही स्टैक में एप्लिकेशनों के बीच बातचीत के लिए।

Permission Group और UX

Permission Group का प्रभाव उपयोगकर्ता अनुभव पर महत्वपूर्ण है। समूहीकरण के कारण, उपयोगकर्ता विभिन्न अनुमतियों के लिए 8 अलग-अलग संवाद नहीं देखता, बल्कि कुछ समूह संवाद देखता है। इससे संज्ञानात्मक भार कम होता है और संभावना कम होती है कि उपयोगकर्ता इसके उद्देश्य को समझे बिना किसी अत्यंत महत्वपूर्ण अनुमति को अस्वीकार कर दे।

UX अनुसंधान दिखाता है कि समूह संवाद उपयोगकर्ताओं द्वारा अधिक पारदर्शी माने जाते हैं। जब कोई एप्लिकेशन “कैमरे तक पहुँचने की अनुमति” माँगता है, तो उपयोगकर्ता संदर्भ समझता है। यदि प्रत्येक अनुमति अलग-अलग माँगी जाती — CAMERA, CAMERA2, FLASHLIGHT — तो यह अतिरेक का आभास पैदा करता। Permission Group इस विस्तार को अमूर्त करता है।

सबसे अच्छा अभ्यास एक बार में केवल एक समूह से अनुमतियाँ माँगना है। यदि किसी एप्लिकेशन को कैमरा और स्थान दोनों चाहिए, तो उन्हें एक requestPermissions कॉल में न माँगें। पहले एक समूह को यह समझाने के बाद माँगें कि इसकी आवश्यकता क्यों है, फिर दूसरा। इससे उपयोगकर्ता को नियंत्रण और प्रत्येक सुविधा की अनुक्रमिक समझ मिलती है।

Permission Group बनाम ProtectionLevel

Permission Group और ProtectionLevel Android अनुमति प्रणाली के दो अलग-अलग आयाम हैं। ProtectionLevel निर्धारित करता है कि अनुमति कैसे प्रदान की जाती है (normal, dangerous, signature, privileged), जबकि Permission Group UI प्रदर्शन के लिए एक श्रेणी है। वे स्वतंत्र हैं, लेकिन व्यवहार में dangerous + permission group का संयोजन सबसे आम है।

एक ही ProtectionLevel की अनुमतियाँ विभिन्न समूहों से संबंधित हो सकती हैं। उदाहरण के लिए, ACCESS_FINE_LOCATION और CAMERA दोनों का protectionLevel dangerous है लेकिन वे विभिन्न समूहों — LOCATION और CAMERA से संबंधित हैं। और इसके विपरीत, समान नाम वाली अनुमतियाँ हमेशा एक ही समूह से संबंधित होती हैं: ACCESS_FINE_LOCATION और ACCESS_COARSE_LOCATION दोनों LOCATION में हैं।

उच्च स्तरीय सुरक्षा स्तर — signature और privileged — UI के लिए Permission Group का उपयोग नहीं करते। उनका प्रदान सिस्टम स्तर पर नियंत्रित होता है: signature उन एप्लिकेशनों को प्रदान किया जाता है जो सिस्टम के समान प्रमाणपत्र से हस्ताक्षरित हैं, और privileged सिस्टम इमेज में एप्लिकेशनों को। ऐसी अनुमतियों के लिए समूह मौजूद हैं लेकिन UX संवादों को प्रभावित नहीं करते क्योंकि ये संवाद बस दिखाई नहीं देते।

कोड में Permission Group की जाँच

डेवलपर PackageManager के माध्यम से किसी भी अनुमति का Permission Group प्रोग्रामेटिक रूप से निर्धारित कर सकता है। getPermissionInfo विधि PermissionInfo लौटाती है जिसमें group फ़ील्ड होता है जिसमें समूह का स्ट्रिंग पहचानकर्ता होता है। यह लॉगिंग, विश्लेषण और कस्टम अनुमति UI स्क्रीन के लिए उपयोगी है।

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

DI और आर्किटेक्चर में उपयोग

Permission Group का ज्ञान अनुरोध आर्किटेक्चर बनाने में मदद करता है। आप PermissionGroupProvider नामक एक अमूर्तता बना सकते हैं जो किसी विशिष्ट समूह के लिए अनुमतियों की सूची लौटाता है। यह परीक्षण को सरल बनाता है: यूनिट परीक्षणों में, प्रदाता PackageManager को कॉल किए बिना नकली डेटा लौटाता है। इंस्ट्रूमेंटेशन परीक्षणों में, यह सिस्टम से वास्तविक समूह लौटाता है।

DI में PermissionGroupProvider

Dagger Hilt या Koin के माध्यम से PermissionGroupProvider को एकीकृत करना अनुमति-से-समूह मैपिंग के केंद्रीकृत प्रबंधन की अनुमति देता है। प्रदाता में, आप प्रत्येक अनुरोध पर बार-बार सिस्टम कॉल से बचने के लिए PackageManager.queryPermissionsByGroup के परिणाम को कैश कर सकते हैं। यह सेटिंग्स स्क्रीन के लिए विशेष रूप से महत्वपूर्ण है जहाँ अनुमतियों की पूरी सूची और उनकी स्थिति प्रदर्शित होती है।

लॉगिंग और विश्लेषण

अस्वीकृतियों के बारे में विश्लेषण एकत्र करते समय, न केवल अनुमति का नाम बल्कि उसका Permission Group भी लॉग करना उपयोगी है। इससे पहचान करने में मदद मिलती है कि कौन से कार्यात्मक क्षेत्र सबसे अधिक अस्वीकृतियाँ पैदा करते हैं। उदाहरण के लिए, LOCATION समूह पारंपरिक रूप से सबसे अधिक अस्वीकृति दर रखता है — Google Play Console के आँकड़ों के अनुसार लगभग 40 प्रतिशत।

समूहों द्वारा विश्लेषण उत्पाद निर्णय लेने में मदद करता है: यदि CONTACTS समूह में उच्च अस्वीकृति दर है, तो शायद अनुरोध के समय पर पुनर्विचार करना या तर्क संवाद जोड़ना उचित होगा। विश्लेषण के लिए समूह-आधारित दृष्टिकोण व्यक्तिगत अनुमतियों के विश्लेषण की तुलना में अधिक पूर्ण चित्र प्रदान करता है, क्योंकि पूरे समूह में अस्वीकृति की संख्या एक कार्यात्मक क्षेत्र के प्रति उपयोगकर्ताओं के सामान्य दृष्टिकोण को दर्शाती है।