AndroidManifest Permissions: मुख्य अवधारणाएँ, घोषणा और अनुमतियों के प्रकार

AndroidManifest Permissions क्या हैं?

AndroidManifest Permissions Android का सुरक्षा तंत्र है जो संरक्षित डेटा और सिस्टम फ़ंक्शन तक एप्लिकेशन की पहुँच को नियंत्रित करता है। प्रत्येक एप्लिकेशन को तत्व का उपयोग करके AndroidManifest.xml फ़ाइल में आवश्यक अनुमतियाँ घोषित करनी होती हैं। घोषणा के बिना, संबंधित API को कॉल करने पर SecurityException सुरक्षा त्रुटि उत्पन्न होगी।

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

अनुमतियाँ चार सुरक्षा स्तरों में विभाजित हैं: normal (इंस्टॉलेशन पर स्वचालित रूप से प्रदान), dangerous (रनटाइम अनुरोध की आवश्यकता), signature (केवल उसी प्रमाणपत्र से हस्ताक्षरित एप्लिकेशन के लिए उपलब्ध) और special (सेटिंग्स में अलग सक्रियण की आवश्यकता)। प्रत्येक स्तर का अपना प्रदान और रद्दीकरण तंत्र है।

Google I/O 2024 के अनुसार, Android 15 अधिक ग्रैन्युलर अनुमतियाँ पेश करने की योजना बना रहा है — उपयोगकर्ता पूरी मीडिया लाइब्रेरी के बजाय केवल विशिष्ट फ़ाइलों तक पहुँच प्रदान कर सकेगा। यह डिफ़ॉल्ट रूप से प्रदान किए गए डेटा की मात्रा को कम करने की Android की प्रवृत्ति को जारी रखता है।

iOS अनुमति मॉडल से अंतर

iOS के विपरीत, जहाँ सभी अनुमतियाँ रनटाइम पर अनुरोधित की जाती हैं, Android अनुमतियों को इंस्टॉल-टाइम और रनटाइम में विभाजित करता है। normal स्तर बिना उपयोगकर्ता सूचना के इंस्टॉलेशन पर स्वचालित रूप से प्रदान किया जाता है। dangerous स्तर को iOS की तरह स्पष्ट संवाद की आवश्यकता होती है।

एक और अंतर: Android में, अनुमतियाँ अनुमति समूहों में संगठित हैं। यदि उपयोगकर्ता कैमरा पहुँच के लिए सहमत होता है, तो एप्लिकेशन स्वचालित रूप से माइक्रोफ़ोन तक पहुँच प्राप्त करता है — वे एक ही MICROPHONE समूह में हैं। iOS में, प्रत्येक अनुमति समूहों की परवाह किए बिना स्वतंत्र रूप से अनुरोधित की जाती है।

Android संस्करणों के अनुसार अनुमतियों का विकास

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

Android अनुमतियों के लिए चार सुरक्षा स्तर परिभाषित करता है, प्रत्येक के अपने प्रदान नियम हैं। आइए प्रत्येक स्तर को विस्तार से देखें।

Normal अनुमतियाँ (इंस्टॉल-टाइम)

Normal अनुमतियाँ बिना उपयोगकर्ता सूचना या अनुरोध के एप्लिकेशन इंस्टॉलेशन पर स्वचालित रूप से प्रदान की जाती हैं। वे कम जोखिम वाले कार्यों को कवर करती हैं जो उपयोगकर्ता की गोपनीयता को खतरा नहीं पहुँचाते: INTERNET, ACCESS_NETWORK_STATE, VIBRATE, BLUETOOTH। उपयोगकर्ता को कोई सहमति संवाद नहीं दिखता — अनुमति इंस्टॉलेशन के बाद प्रदान मानी जाती है।

डेवलपर को normal अनुमतियों के लिए कोड में अनुरोध संभालने की आवश्यकता नहीं है — मेनिफ़ेस्ट में घोषित करना पर्याप्त है। हालाँकि, Android 12+ में, Google Play से इंस्टॉल करते समय, उपयोगकर्ता सभी normal अनुमतियों को सूचीबद्ध करने वाला एक «अनुमतियाँ» टैब देखता है, जिससे पारदर्शिता बढ़ती है। Statista (2024) के अनुसार, Google Play में 90% से अधिक एप्लिकेशन सबसे सामान्य normal अनुमति के रूप में INTERNET का उपयोग करते हैं।

Dangerous अनुमतियाँ (रनटाइम)

Dangerous अनुमतियाँ डेटा और कार्यों तक पहुँच को कवर करती हैं जो गोपनीयता से समझौता कर सकते हैं: कैमरा, माइक्रोफ़ोन, जियोलोकेशन, संपर्क, SMS, फ़ोन, कैलेंडर, बॉडी सेंसर। इन अनुमतियों को दो-चरणीय तंत्र की आवश्यकता होती है: मेनिफ़ेस्ट में घोषणा + ActivityCompat.requestPermissions() के माध्यम से रनटाइम अनुरोध।

उपयोगकर्ता एक dangerous अनुमति से इनकार कर सकता है, और एप्लिकेशन को इस परिदृश्य को सही ढंग से संभालना चाहिए। Android 11+ में, यदि उपयोगकर्ता दो बार इनकार करता है, तो बाद के अनुरोध सिस्टम संवाद नहीं दिखाते — सिस्टम स्वचालित रूप से DENIED लौटाता है। इस मामले में, एप्लिकेशन को उपयोगकर्ता को सेटिंग्स पर निर्देशित करना चाहिए।

Signature और Special अनुमतियाँ

signature स्तर — अनुमति स्वचालित रूप से प्रदान की जाती है यदि एप्लिकेशन उसी प्रमाणपत्र से हस्ताक्षरित है जो सिस्टम या किसी अन्य एप्लिकेशन ने अनुमति को परिभाषित किया है। सिस्टम और कॉर्पोरेट एप्लिकेशन के लिए उपयोग किया जाता है। उदाहरण: BIND_ACCESSIBILITY_SERVICE — केवल सिस्टम एप्लिकेशन के लिए उपलब्ध।

special स्तर (SYSTEM_ALERT_WINDOW, WRITE_SETTINGS, REQUEST_INSTALL_PACKAGES, MANAGE_EXTERNAL_STORAGE) — सिस्टम सेटिंग्स के माध्यम से उपयोगकर्ता की स्पष्ट कार्रवाई की आवश्यकता होती है। एप्लिकेशन Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION) का उपयोग करके सेटिंग्स पृष्ठ खोल सकता है। Google Play special अनुमतियों के उपयोग को प्रतिबंधित करता है और प्रकाशन करते समय फ़ॉर्म में औचित्य की आवश्यकता होती है।

Runtime Permission: dangerous अनुमतियों के साथ काम करना

Android 6.0 से, सभी dangerous अनुमतियों को रनटाइम पर अनुरोध की आवश्यकता होती है। आइए Kotlin में रनटाइम अनुमतियों के साथ पूर्ण कार्य चक्र देखें।

अनुमति की जाँच और अनुरोध

वह API कॉल करने से पहले जिसके लिए dangerous अनुमति की आवश्यकता है, हमेशा ContextCompat.checkSelfPermission() के माध्यम से वर्तमान स्थिति जाँचें। यदि स्थिति PERMISSION_GRANTED है, तो आप API कॉल कर सकते हैं। यदि PERMISSION_DENIED है, तो आपको ActivityResultContract RequestPermission (AndroidX) या पुराने requestPermissions() के माध्यम से अनुमति का अनुरोध करना होगा।

एक साथ कई अनुमतियों का अनुरोध करने के लिए ActivityResultContracts.RequestMultiplePermissions का उपयोग करने की अनुशंसा की जाती है। Google एक संवाद में संबंधित अनुमतियों (जैसे, वीडियो रिकॉर्डिंग के लिए कैमरा + माइक्रोफ़ोन) को समूहित करने की अनुशंसा करता है, ताकि उपयोगकर्ता अनुरोध का पूरा संदर्भ देख सके।

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

«फिर से मत पूछें» अस्वीकृति को संभालना

यदि उपयोगकर्ता दो बार इनकार करता है, तो Android अनुरोध को «Never ask again» स्थिति में डाल देता है। इस मामले में, shouldShowRequestPermissionRationale() false लौटाता है, और सिस्टम संवाद नहीं दिखाया जाएगा। एप्लिकेशन को Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS) के माध्यम से उपयोगकर्ता को सिस्टम सेटिंग्स पर निर्देशित करना चाहिए।

महत्वपूर्ण: पहले इनकार के तुरंत बाद सेटिंग्स खोलने का संवाद न दिखाएँ — इसे आक्रामक व्यवहार माना जाता है। यह निर्धारित करने के लिए shouldShowRequestPermissionRationale() का उपयोग करें कि क्या स्पष्टीकरण दिखाने की आवश्यकता है। Material Design Guidelines केवल «सेटिंग्स खोलें» बटन के बजाय पहुँच के मूल्य की व्याख्या करने वाली स्क्रीन दिखाने की अनुशंसा करते हैं।

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("कैमरा तक पहुँच")
        .setMessage("सेटिंग्स में कैमरा पहुँच की अनुमति दें, "
            + "प्रोफ़ाइल फ़ोटो लेने के लिए")
        .setPositiveButton("सेटिंग्स खोलें") { _, _ ->
            openAppSettings()
        }
        .setNegativeButton("रद्द करें", null)
        .show()
}

AndroidManifest.xml में अनुमतियों की घोषणा

AndroidManifest.xml फ़ाइल में प्रत्येक अनुमति के लिए तत्व होता है जिसका एप्लिकेशन उपयोग करता है। अनुमतियाँ स्तर पर तत्व से पहले घोषित की जाती हैं।

घोषणा सिंटैक्स

प्रत्येक अनुमति एक अलग तत्व के साथ android:name विशेषता का उपयोग करके घोषित की जाती है जो पूर्ण अनुमति नाम निर्दिष्ट करती है। विशिष्ट Android संस्करणों में पेश की गई अनुमतियों के लिए, घोषणा को केवल आवश्यक संस्करणों तक सीमित करने के लिए maxSdkVersion विशेषता का उपयोग करें — इससे अनुकूलता में सुधार होता है।

उदाहरण के लिए, WRITE_EXTERNAL_STORAGE अनुमति Android 10+ (Scoped Storage) पर आवश्यक नहीं है, इसलिए maxSdkVersion="28" (Android 9) निर्दिष्ट करें। यह नए संस्करणों पर उपयोगकर्ताओं से अनावश्यक प्रश्नों को रोकता है। Android Studio Lint के माध्यम से अनुशंसित maxSdkVersion के बारे में चेतावनी देता है।

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

फ़िल्टरिंग के लिए का उपयोग

तत्व इंगित करता है कि एप्लिकेशन को विशिष्ट हार्डवेयर (कैमरा, GPS, NFC) की आवश्यकता है। android:required="false" विशेषता एप्लिकेशन को उस हार्डवेयर के बिना उपकरणों पर इंस्टॉल करने की अनुमति देती है — उपलब्धता कोड में जाँची जाती है। यदि required="true" है, तो Google Play एप्लिकेशन को फ़िल्टर करता है, जिससे यह अनुपयुक्त उपकरणों के लिए अनुपलब्ध हो जाता है।

सभी हार्डवेयर सुविधाओं के लिए required="false" सेट करने और PackageManager.hasSystemFeature() के माध्यम से प्रोग्रामेटिक रूप से उपलब्धता जाँचने की अनुशंसा की जाती है। यह आपके एप्लिकेशन के दर्शकों का विस्तार करता है। एकमात्र अपवाद यदि सुविधा एप्लिकेशन के संचालन के लिए महत्वपूर्ण है (GPS के बिना टैक्सी ऑर्डरिंग एप्लिकेशन का कोई मतलब नहीं है)।

सर्वोत्तम अभ्यास और त्रुटियाँ

अनुमतियों का उचित प्रबंधन Android एप्लिकेशन गुणवत्ता का एक प्रमुख पहलू है। आइए मुख्य अनुशंसाओं और सामान्य त्रुटियों की समीक्षा करें।

अनुरोधित अनुमतियों को न्यूनतम करें

केवल वे अनुमतियाँ अनुरोध करें जो एप्लिकेशन के संचालन के लिए वास्तव में आवश्यक हैं। प्रत्येक अतिरिक्त अनुमति इंस्टॉल रूपांतरण को कम करती है और अस्वीकृति दर बढ़ाती है। Google Play Console दिखाता है कि कितने उपयोगकर्ताओं ने अनुमति सेट के कारण इंस्टॉलेशन से इनकार किया। AppBrain (2024) के अनुसार, 10+ dangerous अनुमतियों वाले एप्लिकेशन में 35% कम इंस्टॉल होते हैं।

नियमित रूप से अपनी अनुमति सूची की समीक्षा करें। अप्रयुक्त अनुमतियाँ हटाएँ, विशेष रूप से नए Android संस्करणों में माइग्रेट करते समय जहाँ कुछ अनुमतियाँ वैकल्पिक हो जाती हैं। उदाहरण के लिए, Android 13+ में फ़ोटो पिकर (ActivityResultContracts.PickVisualMedia) के साथ, मीडिया लाइब्रेरी तक पहुँच खतरनाक READ_MEDIA_IMAGES अनुमति के बिना प्राप्त की जा सकती है।

अनुरोध से पहले तर्क दिखाएँ

एक खतरनाक अनुमति का अनुरोध करने से पहले, उपयोगकर्ता को एक स्क्रीन दिखाएँ जो समझाए कि इस अनुमति की आवश्यकता क्यों है और यह क्या मूल्य प्रदान करती है। Material Design एक आइकन, संक्षिप्त पाठ और «जारी रखें» बटन के साथ बॉटम शीट या संवाद का उपयोग करने की अनुशंसा करता है। तर्क सीधे अनुरोध की तुलना में सहमति को 20-30% तक बढ़ाता है।

launch() कॉल करने से पहले shouldShowRequestPermissionRationale() जाँचें। यदि true है, तो तर्क दिखाएँ। यदि false है, तो या तो अनुमति पहले ही प्रदान की जा चुकी है या उपयोगकर्ता ने इसे स्थायी रूप से अस्वीकार कर दिया है (फिर कभी न पूछें)। बाद के मामले में, अनुरोध दोहराने के बजाय «सेटिंग्स खोलें» बटन दिखाएँ।

सभी अनुमति परिदृश्यों का परीक्षण करें

सभी संभावित परिदृश्यों का परीक्षण करें: अनुमति प्रदान करना, अस्वीकृति, स्थायी अस्वीकृति, सेटिंग्स में अनुमति रद्द करना, अनुमति रीसेट (Android 11+ ऑटो-रीसेट)। प्रत्येक परिदृश्य को बिना क्रैश या डेटा हानि के संभाला जाना चाहिए। Android Testing Guide परीक्षण को स्वचालित करने के लिए TestPermission लाइब्रेरी का उपयोग करने की अनुशंसा करता है।

उस परिदृश्य पर विशेष ध्यान दें जब उपयोगकर्ता एप्लिकेशन चलने के दौरान अनुमति रद्द करता है (एप्लिकेशन छोटा → सेटिंग्स → रद्द)। एप्लिकेशन पर लौटने पर, onResume() में सभी अनुमतियों की जाँच करें। अनुमति स्थिति को कैश करने पर भरोसा न करें — उपयोगकर्ता इसे किसी भी समय बदल सकता है।

सामान्य त्रुटियाँ

• पहले checkSelfPermission जाँचे बिना अनुमति का अनुरोध — अनावश्यक संवाद ट्रिगर करता है
• shouldShowRequestPermissionRationale को अनदेखा करना — पहले इनकार के बाद UX खराब करता है
• संदर्भ के बिना अनुमति का अनुरोध (केवल «पहुँच की अनुमति दें?») — सहमति कम करता है
• Android 10+ पर maxSdkVersion के बिना WRITE_EXTERNAL_STORAGE का उपयोग — अनावश्यक अनुरोध
• onResume में अनुमति जाँच की कमी — सेटिंग्स में अनुमति रद्द करने से चूक