Runtime Permission: कितने प्रकार हैं और Android में कार्य सिद्धांत

Runtime Permission क्या है?

Runtime Permission एक Android सुरक्षा मॉडल है जहाँ ऐप उस समय संवेदनशील डेटा तक पहुँच का अनुरोध करता है जब वह कार्यक्षमता वास्तव में उपयोगकर्ता के लिए आवश्यक होती है। Android 6.0 से पहले, सभी अनुमतियाँ ऐप इंस्टॉलेशन पर प्रदान की जाती थीं, और उपयोगकर्ता ऐप को पूरी तरह से हटाए बिना उन्हें रद्द नहीं कर सकता था।

Android अनुमति मॉडल का विकास

Android 6.0 से पहले, उपयोगकर्ता इंस्टॉलेशन पर सभी अनुमतियों की सूची देखता था और या तो सभी को स्वीकार कर सकता था या इंस्टॉलेशन से इनकार कर सकता था। 2015 के एक अध्ययन से पता चला कि 87% उपयोगकर्ता इंस्टॉलेशन पर अनुमति सूची नहीं पढ़ते हैं। Android 6.0 ने रनटाइम अनुमतियाँ पेश कीं, अनुमतियों को सामान्य (स्वचालित) और खतरनाक (अनुरोध के साथ) में विभाजित किया। Android 11 ने एक-बार की अनुमतियाँ जोड़ीं — ऐप बंद होने पर स्वचालित रद्दीकरण। Android 13 ने फोटो पिकर और पुश सूचनाओं को अलग रनटाइम अनुमतियों के रूप में पेश किया।

iOS iOS 10 से समान मॉडल का उपयोग करता है, जहाँ कैमरा, माइक्रोफ़ोन और जियोलोकेशन तक पहुँच पहले उपयोग पर अनुरोधित की जाती है। हालाँकि, iOS में “सामान्य अनुमतियों” की अवधारणा नहीं है — प्रत्येक अनुमति स्पष्ट रूप से अनुरोधित की जाती है, और इनकार डेवलपर द्वारा सिस्टम सेटिंग्स के माध्यम से पुनः अनुरोध करने तक बना रहता है।

Android में Runtime Permission कैसे काम करता है?

Runtime Permission requestPermissions() विधि (AndroidX — ActivityResultLauncher) द्वारा लाए गए सिस्टम डायलॉग के माध्यम से काम करता है। सिस्टम एक स्पष्टीकरण के साथ मानक डायलॉग दिखाता है, और उपयोगकर्ता “अनुमति दें” या “अस्वीकार करें” चुनता है। प्रतिक्रिया के बाद, एक कॉलबैक ट्रिगर होता है जहाँ ऐप उपयोगकर्ता के निर्णय को संभालता है।

ActivityResultLauncher के माध्यम से अनुमति का अनुरोध

private lateinit var requestPermissionLauncher: ActivityResultLauncher<String>

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

    requestPermissionLauncher =
        registerForActivityResult(ActivityResultContracts.RequestPermission()) { isGranted ->
            if (isGranted) {
                startCamera()
            } else {
                showPermissionDeniedDialog()
            }
        }
}

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

shouldShowRequestPermissionRationale विधि true लौटाती है यदि उपयोगकर्ता पहले ही एक बार अनुरोध को अस्वीकार कर चुका है। इस मामले में, यह अनुशंसा की जाती है कि स्पष्टीकरण के साथ एक डायलॉग दिखाया जाए कि ऐप को अनुमति की आवश्यकता क्यों है, और उसके बाद ही पुनः अनुरोध किया जाए। इससे उपयोगकर्ता की सहमति की संभावना 30–40% बढ़ जाती है (Google I/O 2024 डेटा)।

Android में अनुमतियों के प्रकार

Android सभी अनुमतियों को कई सुरक्षा स्तरों में वर्गीकृत करता है: सामान्य, खतरनाक, हस्ताक्षर और विशेष। सामान्य अनुमतियाँ इंस्टॉलेशन पर स्वचालित रूप से प्रदान की जाती हैं। खतरनाक अनुमतियाँ रनटाइम अनुरोध की आवश्यकता होती हैं। हस्ताक्षर अनुमतियाँ केवल उसी प्रमाणपत्र से हस्ताक्षरित ऐप के लिए उपलब्ध हैं।

खतरनाक अनुमति समूह

विशेष अनुमतियाँ (SYSTEM_ALERT_WINDOW, WRITE_SETTINGS, MANAGE_EXTERNAL_STORAGE) को Settings.ACTION_MANAGE_OVERLAY_PERMISSION के माध्यम से सिस्टम सेटिंग्स में अतिरिक्त नेविगेशन की आवश्यकता होती है। इन अनुमतियों का अनुरोध मानक सिस्टम डायलॉग के माध्यम से नहीं किया जा सकता है और सेटिंग्स स्क्रीन में उपयोगकर्ता की स्पष्ट कार्रवाई की आवश्यकता होती है।

Android 12+ में अनुमतियों का अनुरोध

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

एक-बार की अनुमतियों को संभालना

// Android 12+ — एक-बार के स्थान अनुमति को संभालना
private fun checkLocationPermission() {
    val permissionLauncher =
        registerForActivityResult(ActivityResultContracts.RequestMultiplePermissions()) { permissions ->

        val fineLocationGranted = permissions[Manifest.permission.ACCESS_FINE_LOCATION]
        val coarseLocationGranted = permissions[Manifest.permission.ACCESS_COARSE_LOCATION]

        if (fineLocationGranted == true) {
            showUserLocation()
        } else {
            showLocationDisabledDialog()
        }
    }

    permissionLauncher.launch(
        arrayOf(
            Manifest.permission.ACCESS_FINE_LOCATION,
            Manifest.permission.ACCESS_COARSE_LOCATION
        )
    )
}

// जाँच करें कि क्या अनुमति सिस्टम द्वारा रद्द कर दी गई थी (Android 12+)
class PermissionReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        if (intent.action == Intent.ACTION_PERMISSION_REVOCATION) {
            handleRevokedPermission(intent.getStringExtra(Intent.EXTRA_REVOKED_PERMISSION))
        }
    }
}

Android 13 ने POST_NOTIFICATIONS अनुमति को खतरनाक समूह में जोड़ा, जिससे पुश सूचनाएँ भेजने के लिए स्पष्ट अनुरोध की आवश्यकता होती है। Android 14 ने पृष्ठभूमि जियोलोकेशन पर प्रतिबंध लगाए: ऐप को हर बार पृष्ठभूमि स्थान का अनुरोध करने पर उपयोगकर्ता की स्पष्ट स्वीकृति प्राप्त करनी होगी। फोटो पिकर (API 33+) ने छवि चयन के लिए READ_EXTERNAL_STORAGE की आवश्यकता को समाप्त कर दिया।

उपयोगकर्ता के इनकार को संभालना

उपयोगकर्ता का इनकार अनुमति अनुरोध को एक सामान्य स्थिति है जिसे सही ढंग से संभाला जाना चाहिए। इनकार दो प्रकार के होते हैं: एक-बार (उपयोगकर्ता ने “अस्वीकार करें” दबाया) और स्थायी (उपयोगकर्ता ने “फिर से न पूछें” चुना)। दूसरे मामले में, सिस्टम डायलॉग फिर से नहीं दिखेगा, और ऐप को उपयोगकर्ता को सिस्टम सेटिंग्स पर रीडायरेक्ट करना होगा।

इनकार संभालने की रणनीति

पहले इनकार के बाद, ऐप को एक तर्क संवाद दिखाना चाहिए — अपना स्वयं का स्पष्टीकरण कि अनुमति क्यों आवश्यक है। यदि उपयोगकर्ता फिर से मना करता है, तो ऐप को Settings.ACTION_APPLICATION_DETAILS_SETTINGS के माध्यम से ऐप सेटिंग्स स्क्रीन पर रीडायरेक्ट करना चाहिए। Material 3 अधिक प्राकृतिक UX के लिए PermissionRequestBottomSheet का उपयोग करने की सलाह देता है।

इनकार पर ऐप की कार्यक्षमता को पूरी तरह से अवरुद्ध नहीं करना महत्वपूर्ण है। उदाहरण के लिए, यदि उपयोगकर्ता ने जियोलोकेशन को अस्वीकार कर दिया, तो ऐप को मैन्युअल पता इनपुट प्रदान करना चाहिए। कैमरे के लिए, गैलरी से छवि अपलोड करने की अनुमति दें। Google अनुशंसा करता है कि सभी रनटाइम अनुमतियों के लिए हमेशा एक वैकल्पिक तंत्र प्रदान किया जाए।

सुरक्षा अनुशंसाएँ

रनटाइम अनुमतियाँ केवल एक तकनीकी तंत्र नहीं हैं, बल्कि ऐप में उपयोगकर्ता के विश्वास का एक तत्व भी हैं। अनुचित समय पर अनुमति का अनुरोध (उदाहरण के लिए, पहले लॉन्च पर) सहमति की संभावना को काफी कम कर देता है। Google Play Store अनुमति अनुरोधों की आवृत्ति और संदर्भ का विश्लेषण करता है: आक्रामक अनुरोधों वाले ऐप को खोज में कम स्थान मिलता है।

अनुमति अनुरोध नियम

संदर्भ — उस क्रिया को करने से तुरंत पहले अनुमति का अनुरोध करें जिसके लिए इसकी आवश्यकता है। न्यूनतम — केवल उन्हीं अनुमतियों का अनुरोध करें जो वास्तव में सुविधा के काम करने के लिए आवश्यक हैं। पारदर्शिता — सिस्टम डायलॉग से पहले उपयोगकर्ता को समझाएँ कि अनुमति क्यों आवश्यक है। रद्दीकरण — रनटाइम पर अनुमति रद्दीकरण को सही ढंग से संभालने के लिए ACTION_PERMISSION_REVOCATION की सदस्यता लें।

रनटाइम अनुमतियों के परीक्षण के लिए, adb कमांड का उपयोग करें: adb shell pm revoke <package> android.permission.CAMERA ऐप को पुनः स्थापित किए बिना अनुमति रद्दीकरण का अनुकरण करने की अनुमति देता है। Espresso और UiAutomator GrantPermissionRule के माध्यम से अनुमति डायलॉग के परीक्षण का समर्थन करते हैं। रनटाइम अनुमतियों वाले ऐप के लिए CI/CD पाइपलाइन में इन उपकरणों का एकीकरण अनिवार्य है।

Google Play Console में अनुमति ऑडिटिंग

Google Play Console अनुमति ऑडिटिंग अनुभाग प्रदान करता है, जहाँ डेवलपर देख सकता है कि कितनी बार अनुमतियों का अनुरोध किया जाता है, कितने प्रतिशत उपयोगकर्ता पहुँच प्रदान करते हैं और कौन सी अनुमतियाँ रद्द की गईं। इस डेटा का विश्लेषण अप्रभावी अनुरोधों की पहचान करने और UX को अनुकूलित करने में मदद करता है। उदाहरण के लिए, यदि 40% से कम उपयोगकर्ता जियोलोकेशन प्रदान करते हैं, तो अनुरोध के समय पर पुनर्विचार करें और अधिक ठोस तर्क जोड़ें।

अनुमति-संबंधित ANR (एप्लिकेशन नॉट रिस्पॉन्डिंग) की निगरानी के लिए Android Vitals का उपयोग करना भी महत्वपूर्ण है। यदि अनुमति अनुरोध मुख्य थ्रेड पर निष्पादित किया जाता है या सिस्टम डायलॉग UI को अवरुद्ध करता है, तो यह धीमे उपकरणों पर ANR का कारण बन सकता है। उपयोगकर्ता इंटरफ़ेस को अवरुद्ध करने से बचने के लिए अनुमति जाँच और अनुरोध को एक अलग थ्रेड पर ले जाएँ या अतुल्यकालिक हैंडलिंग के लिए Kotlin कोरूटीन का उपयोग करें।