Android में Dangerous Permission: यह क्या है, अनुमतियों की सूची और रनटाइम अनुरोध

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

Dangerous Permission Android सिस्टम अनुमतियों की एक श्रेणी है जो उपयोगकर्ता के संवेदनशील डेटा तक पहुँच प्रदान करती है। सामान्य अनुमतियों के विपरीत, खतरनाक अनुमतियाँ इंस्टॉलेशन के दौरान स्वचालित रूप से नहीं दी जाती हैं — एप्लिकेशन को Android 6.0 Marshmallow (API 23) में शुरू की गई रनटाइम तंत्र के माध्यम से रनटाइम पर स्पष्ट रूप से उनका अनुरोध करना होता है।

स्पष्ट अनुरोध की आवश्यकता उन डेटा की प्रकृति के कारण है जिन्हें ये अनुमतियाँ सुरक्षित करती हैं: उपयोगकर्ता का स्थान, व्यक्तिगत संपर्क, कैमरा और माइक्रोफ़ोन सामग्री, कॉल इतिहास और SMS। Android इस डेटा को संवेदनशील मानता है और आवश्यकता है कि उपयोगकर्ता सचेत रूप से पहुँच प्रदान करे। Android Privacy Sandbox (2024) के अनुसार, उपयोगकर्ता औसतन लगभग 30 प्रतिशत रनटाइम अनुरोधों को अस्वीकार करते हैं।

Dangerous Permission की एक मुख्य विशेषता किसी भी समय इसे रद्द करने की क्षमता है। उपयोगकर्ता सेटिंग्स — ऐप्स — अनुमतियाँ पर जाकर किसी भी खतरनाक अनुमति को बंद कर सकता है। एप्लिकेशन को इसके लिए तैयार रहना चाहिए कि पहले दी गई अनुमति बिना पुनरारंभ के किसी भी समय रद्द की जा सकती है।

ProtectionLevel dangerous

सुरक्षा स्तर dangerous OS स्तर पर सिस्टम अनुमति परिभाषाओं में सेट किया जाता है। जब कोई एप्लिकेशन इस protectionLevel के साथ uses-permission घोषित करता है, तो सिस्टम अनुमति को रनटाइम अनुरोध की आवश्यकता वाली के रूप में चिह्नित करता है। normal के विपरीत, खतरनाक अनुमतियाँ हमेशा सिस्टम अनुमति प्रबंधन UI में प्रदर्शित होती हैं और रद्द की जा सकती हैं।

Permission Group और Dangerous

सभी खतरनाक अनुमतियाँ कार्यात्मक श्रेणी के अनुसार Permission Groups में समूहित की जाती हैं। उदाहरण के लिए, CAMERA और CAMERA2 CAMERA समूह में हैं, ACCESS_FINE_LOCATION और ACCESS_COARSE_LOCATION LOCATION समूह में हैं। यदि उपयोगकर्ता ने किसी समूह से एक अनुमति दी है, तो उसी समूह की शेष अनुमतियाँ बिना अतिरिक्त डायलॉग के स्वचालित रूप से प्रदान की जाती हैं।

रनटाइम अनुरोध कैसे काम करता है

रनटाइम अनुरोध एक तंत्र है जिसमें एप्लिकेशन अनुमति अनुरोध डायलॉग प्रदर्शित करने के लिए सिस्टम API को कॉल करता है। उपयोगकर्ता अनुमति के नाम और Allow और Deny बटन के साथ एक मोडल विंडो देखता है। प्रतिक्रिया के बाद, सिस्टम परिणाम के साथ onRequestPermissionsResult कॉलबैक को कॉल करता है।

पूर्ण चक्र में तीन चरण शामिल हैं: checkSelfPermission के माध्यम से स्थिति जाँचना, अनुमति न होने पर requestPermissions को कॉल करना, और onRequestPermissionsResult में परिणाम को संभालना। स्थिति जाँच अनिवार्य है क्योंकि उपयोगकर्ता ने सेटिंग्स के माध्यम से किसी भी समय अनुमति रद्द कर दी हो सकती है, और बिना जाँच के फ़ंक्शन को कॉल करने से 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
            )
        }
    }
}

परिणाम का हैंडलिंग ActivityResultLauncher या onRequestPermissionsResult में होता है। अनुशंसित आधुनिक दृष्टिकोण ActivityResultContracts.RequestPermission का उपयोग करना है, जो स्पष्ट अनुरोध कोड के बिना एक स्वच्छ API प्रदान करता है। यह कॉन्ट्रैक्ट Boolean लौटाता है — कि अनुमति दी गई या नहीं।

अनुरोध के सर्वोत्तम अभ्यास

एप्लिकेशन स्टार्टअप पर नहीं, बल्कि फ़ीचर के उपयोग के संदर्भ में सख्ती से खतरनाक अनुमतियों का अनुरोध करें। यदि उपयोगकर्ता ने कैमरा बटन दबाया — CAMERA का अनुरोध करें। यदि उन्होंने मानचित्र खोला — LOCATION का अनुरोध करें। प्रासंगिक अनुरोध पहले लॉन्च पर सभी अनुमतियों का अनुरोध करने की तुलना में दोगुनी स्वीकृतियाँ देते हैं। एक बार में एक से अधिक अनुमति का अनुरोध न करने की भी सिफारिश की जाती है ताकि उपयोगकर्ता समझ सके कि किस सुविधा को पहुँच की आवश्यकता है।

Android में खतरनाक अनुमतियों की सूची

Android परिभाषित करता है खतरनाक अनुमतियों के कई समूह, प्रत्येक में एक या अधिक स्थिरांक होते हैं। सबसे पूर्ण सूची Manifest.permission वर्ग में उपलब्ध है। नीचे विकास में उपयोग किए जाने वाले मुख्य समूह और अनुमतियाँ दी गई हैं।

Android 12+ में नई अनुमतियाँ

Android 12 से शुरू होकर, Google ने कुछ अनुमतियों के लिए आवश्यकताएँ कड़ी कर दी हैं। उदाहरण के लिए, BLUETOOTH_CONNECT और BLUETOOTH_SCAN खतरनाक हो गए हैं और रनटाइम अनुरोध की आवश्यकता है। सेंसर तक पृष्ठभूमि पहुँच के लिए BODY_SENSORS_BACKGROUND अनुमति भी जोड़ी गई है। डेवलपर्स को targetSdkVersion अपडेट करना होगा और वर्तमान OS संस्करणों पर अनुरोधों का परीक्षण करना होगा।

Android 13+ के लिए अनुमतियाँ

Android 13 (API 33) ने सूचनाओं (POST_NOTIFICATIONS) और मीडिया फ़ाइलों (READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_MEDIA_AUDIO) के लिए नई अनुमतियाँ पेश कीं, जिन्होंने सामान्य READ_EXTERNAL_STORAGE को बदल दिया। अब फ़ोटो, वीडियो और ऑडियो तक पहुँच एकल डायलॉग के बिना विशिष्ट अनुमतियों के माध्यम से अलग-अलग अनुरोधित की जाती है।

Dangerous बनाम Normal Permission

Dangerous और Normal Permission प्रदान करने के तरीके, रद्द करने की क्षमता और UX में मौलिक रूप से भिन्न हैं। Normal इंस्टॉलेशन के दौरान स्वचालित रूप से दी जाती है, Dangerous के लिए स्पष्ट रनटाइम डायलॉग की आवश्यकता होती है। Normal को सेटिंग्स के माध्यम से रद्द नहीं किया जा सकता, Dangerous को किसी भी समय अक्षम किया जा सकता है। यह विषमता विभिन्न विकास पैटर्न बनाती है।

कोड के दृष्टिकोण से, खतरनाक अनुमतियों के लिए अधिक कार्य की आवश्यकता होती है: checkSelfPermission, requestPermissions, अस्वीकृति को संभालना। सामान्य अनुमतियों के लिए, AndroidManifest.xml में एक पंक्ति पर्याप्त है। हालाँकि, Dangerous Permission उपयोगकर्ता को नियंत्रण देता है, जो विश्वास बढ़ाता है, विशेष रूप से कैमरा या स्थान जैसी संवेदनशील सुविधाओं के लिए।

श्रेणियों के बीच चुनाव डेवलपर के ऊपर नहीं है — यह सिस्टम द्वारा निर्धारित किया जाता है। डेवलपर केवल uses-permission घोषित करता है, और सिस्टम protectionLevel के आधार पर श्रेणी निर्धारित करता है। हालाँकि, खतरनाक अनुमतियों का अनुरोध करने की रणनीति उपयोगकर्ता अनुभव को प्रभावित करती है: बार-बार या अनुचित डायलॉग एप्लिकेशन की रेटिंग कम करते हैं।

Kotlin में अनुमतियाँ कैसे अनुरोध करें

आधुनिक तरीका Kotlin में अनुमतियों का अनुरोध करने का ActivityResultContracts.RequestMultiplePermissions या RequestPermission का उपयोग करना है। ये कॉन्ट्रैक्ट androidx.activity लाइब्रेरी का हिस्सा हैं और onRequestPermissionsResult को ओवरराइड करने की आवश्यकता के बिना lambdas पर आधारित एक स्वच्छ API प्रदान करते हैं।

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

एक साथ कई अनुमतियों का अनुरोध करना

जब किसी एप्लिकेशन को एक साथ कई खतरनाक अनुमतियों की आवश्यकता हो, तो RequestMultiplePermissions का उपयोग करें। कॉन्ट्रैक्ट Map<String, Boolean> लौटाता है जहाँ कुंजी अनुमति का नाम और मान परिणाम है। यह पहले लॉन्च पर उपयोगी है जब वीडियो रिकॉर्डिंग के लिए CAMERA और RECORD_AUDIO का अनुरोध करने की आवश्यकता होती है।

पहली बार अस्वीकृति को संभालना

यदि उपयोगकर्ता अनुरोध को अस्वीकार करता है, तो shouldShowRequestPermissionRationale विधि true लौटाती है। यह संकेत है कि अनुमति की आवश्यकता का स्पष्टीकरण दिखाया जाए। सबसे अच्छा अभ्यास स्पष्टीकरण और पुनः प्रयास बटन के साथ एक कस्टम डायलॉग दिखाना है। यदि उपयोगकर्ता Never Ask Again चेकबॉक्स चिह्नित करके फिर से अनुरोध को अस्वीकार करता है, तो shouldShowRequestPermissionRationale false लौटाएगा, और आपको सेटिंग्स पर रीडायरेक्ट करने की आवश्यकता है।

अस्वीकृति और Never Ask Again को संभालना

Never Ask Again एक फ़्लैग है जिसे उपयोगकर्ता दूसरी बार रनटाइम डायलॉग को अस्वीकार करते समय सेट कर सकता है। इसके बाद, उस अनुमति के लिए मानक डायलॉग फिर से नहीं दिखाया जाता है। पहुँच प्रदान करने का एकमात्र तरीका उपयोगकर्ता को सिस्टम ऐप सेटिंग्स पर रीडायरेक्ट करना है।

डेवलपर को दो अस्वीकृति परिदृश्यों के बीच अंतर करना होगा: पहला, जब shouldShowRequestPermissionRationale true लौटाता है (उपयोगकर्ता ने अस्वीकार कर दिया लेकिन डायलॉग अभी भी दिखाया जा सकता है), और दूसरा, जब विधि false लौटाती है (Never Ask Again सक्रिय है या अनुमति नीति द्वारा अवरुद्ध है)। दूसरे मामले में, आपको सेटिंग्स खोलें बटन दिखाना चाहिए।

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

private fun showSettingsRedirectDialog(permission: String) {
    AlertDialog.Builder(this)
        .setTitle("पहुँच अस्वीकृत")
        .setMessage(
            "अनुमति अवरुद्ध। सेटिंग्स खोलें।"
        )
        .setPositiveButton("सेटिंग्स") { _, _ ->
            val intent = Intent(
                Settings.ACTION_APPLICATION_DETAILS_SETTINGS,
                Uri.fromParts(
                    "package", packageName, null
                )
            )
            startActivity(intent)
        }
        .show()
}

यह महत्वपूर्ण है कि यदि shouldShowRequestPermissionRationale ने false लौटाया है तो अनुमति का फिर से अनुरोध न करें। इस मामले में requestPermissions का बार-बार कॉल करने से कोई डायलॉग नहीं दिखेगा — परिणाम बिना स्पष्टीकरण के तुरंत DENIED के साथ वापस आएगा। उपयोगकर्ता को अस्पष्ट व्यवहार का सामना करना पड़ेगा, जो एप्लिकेशन अनुभव पर नकारात्मक प्रभाव डालता है।