रनटाइम अनुमतियों का अनुरोध करें

हर Android ऐप्लिकेशन, सीमित ऐक्सेस वाले सैंडबॉक्स में चलता है. अगर आपके ऐप्लिकेशन को अपने सैंडबॉक्स के बाहर के संसाधनों या जानकारी का इस्तेमाल करना है, तो रनटाइम की अनुमति का एलान किया जा सकता है. साथ ही, अनुमति का ऐसा अनुरोध सेट अप किया जा सकता है जो यह ऐक्सेस देता है. ये चरण अनुमतियों का इस्तेमाल करने के लिए वर्कफ़्लो का हिस्सा हैं.

अगर आपने खतरनाक अनुमतियों का एलान किया है और आपका ऐप्लिकेशन, Android 6.0 (एपीआई लेवल 23) या उसके बाद के वर्शन पर चलने वाले डिवाइस पर इंस्टॉल है, तो आपको इस गाइड में दिए गए निर्देशों का पालन करके, रनटाइम के दौरान खतरनाक अनुमतियों का अनुरोध करना होगा.

अगर डेवलपर को नुकसान पहुंचाने वाली किसी भी अनुमति के बारे में जानकारी नहीं दी जाती है या आपका ऐप्लिकेशन किसी ऐसे डिवाइस पर इंस्टॉल किया गया है जो Android 5.1 (एपीआई लेवल 22) या इससे पहले के वर्शन पर काम करता है, तो अनुमतियां अपने-आप मिल जाती हैं. इसके बाद, आपको इस पेज पर बचा हुआ कोई भी चरण पूरा करने की ज़रूरत नहीं होगी.

बुनियादी सिद्धांत

रनटाइम के दौरान अनुमतियों का अनुरोध करने के बुनियादी सिद्धांत यहां दिए गए हैं:

  • जब उपयोगकर्ता उस सुविधा के साथ इंटरैक्ट करना शुरू करता है जिसके लिए अनुमति की ज़रूरत होती है, तो उससे अनुमति मांगें.
  • उपयोगकर्ता को ब्लॉक न करें. शिक्षा से जुड़े यूज़र इंटरफ़ेस (यूआई) फ़्लो को रद्द करने का विकल्प हमेशा उपलब्ध कराएं. जैसे, वह फ़्लो जिसमें अनुमतियों का अनुरोध करने की वजह के बारे में बताया गया हो.
  • अगर उपयोगकर्ता किसी सुविधा के लिए ज़रूरी अनुमति को अस्वीकार या निरस्त करता है, तो ऐप्लिकेशन से उस सुविधा के लिए किए जाने वाले अनुरोध को हटा दें, ताकि उपयोगकर्ता ऐप्लिकेशन का इस्तेमाल जारी रख सके. इसके लिए, ऐसी सुविधा को बंद कर दें जिसके लिए, उपयोगकर्ता की अनुमति ली जाती है.
  • सिस्टम के व्यवहार के बारे में कोई अनुमान न लगाएं. उदाहरण के लिए, यह न सोचें कि अनुमतियां उसी अनुमति ग्रुप में दिखती हैं. अनुमति ग्रुप की मदद से, सिस्टम को उपयोगकर्ता को दिखाए जाने वाले सिस्टम डायलॉग की संख्या कम करने में मदद मिलती है. ऐसा तब होता है, जब कोई ऐप्लिकेशन मिलती-जुलती अनुमतियों का अनुरोध करता है.

अनुमतियों के अनुरोध के लिए वर्कफ़्लो

अपने ऐप्लिकेशन में रनटाइम की अनुमतियों का एलान करने और उनका अनुरोध करने से पहले, इस बात का आकलन करें कि आपके ऐप्लिकेशन को ऐसा करना ज़रूरी है या नहीं. आपके पास अपने ऐप्लिकेशन में कई काम करने के विकल्प हैं. जैसे, फ़ोटो खींचना, मीडिया चलाना रोकना, और काम के विज्ञापन दिखाना. इसके लिए, आपको किसी अनुमति का एलान करने की ज़रूरत नहीं है.

अगर आपको लगता है कि आपके ऐप्लिकेशन को रनटाइम की अनुमतियों का एलान करना और उनका अनुरोध करना है, तो यह तरीका अपनाएं:

  1. अपने ऐप्लिकेशन की मेनिफ़ेस्ट फ़ाइल में, उन अनुमतियों का एलान करें जिनके लिए आपके ऐप्लिकेशन को अनुरोध करना पड़ सकता है.
  2. अपने ऐप्लिकेशन का यूज़र एक्सपीरियंस (यूएक्स) इस तरह डिज़ाइन करें कि आपके ऐप्लिकेशन में की जाने वाली कुछ कार्रवाइयां, रनटाइम की कुछ खास अनुमतियों से जुड़ी हों. उपयोगकर्ताओं को बताएं कि किन कार्रवाइयों के लिए, उन्हें आपके ऐप्लिकेशन को निजी डेटा ऐक्सेस करने की अनुमति देनी पड़ सकती है.
  3. आपके ऐप्लिकेशन में, किसी ऐसे टास्क या कार्रवाई को शुरू करने के लिए उपयोगकर्ता का इंतज़ार करें जिसके लिए उपयोगकर्ता के खास निजी डेटा का ऐक्सेस ज़रूरी हो. उस समय, आपका ऐप्लिकेशन उस डेटा को ऐक्सेस करने के लिए ज़रूरी रनटाइम की अनुमति का अनुरोध कर सकता है.

  4. देखें कि उपयोगकर्ता ने आपके ऐप्लिकेशन के लिए, रनटाइम की अनुमति पहले ही दी है या नहीं. अगर ऐसा है, तो आपका ऐप्लिकेशन उपयोगकर्ता का निजी डेटा ऐक्सेस कर सकता है. अगर ऐसा नहीं है, तो अगले चरण पर जाएं.

    आपको हर बार यह देखना होगा कि आपके पास उस कार्रवाई के लिए अनुमति है या नहीं.

  5. देखें कि आपके ऐप्लिकेशन को उपयोगकर्ता को वजह बतानी चाहिए या नहीं. साथ ही, यह भी बताएं कि आपके ऐप्लिकेशन को उपयोगकर्ता से किसी खास रनटाइम की अनुमति क्यों चाहिए. अगर सिस्टम यह तय करता है कि आपके ऐप्लिकेशन को वजह नहीं दिखानी चाहिए, तो यूज़र इंटरफ़ेस (यूआई) एलिमेंट दिखाए बिना सीधे अगले चरण पर जाएं.

    अगर सिस्टम यह तय करता है कि आपके ऐप्लिकेशन को वजह बतानी चाहिए, तो उपयोगकर्ता को यूज़र इंटरफ़ेस (यूआई) एलिमेंट में वजह बताएं. इस वजह में, साफ़ तौर पर बताएं कि आपका ऐप्लिकेशन किस तरह का डेटा ऐक्सेस करने की कोशिश कर रहा है. साथ ही, यह भी बताएं कि अगर उपयोगकर्ता रनटाइम की अनुमति देता है, तो उसे क्या फ़ायदे मिलेंगे. जब उपयोगकर्ता, वजह स्वीकार कर ले, तब अगले चरण पर जाएं.

  6. रनटाइम की उस अनुमति का अनुरोध करें जिसकी ज़रूरत आपके ऐप्लिकेशन को उपयोगकर्ता का निजी डेटा ऐक्सेस करने के लिए है. सिस्टम, रनटाइम के दौरान अनुमति का अनुरोध दिखाता है. जैसे, अनुमतियों की खास जानकारी वाले पेज पर दिखाया गया अनुरोध.

  7. उपयोगकर्ता के जवाब की जांच करें—उन्होंने रनटाइम की अनुमति देने या अस्वीकार करने का विकल्प चुना है या नहीं.

  8. अगर उपयोगकर्ता ने आपके ऐप्लिकेशन को अनुमति दी है, तो आपके पास उपयोगकर्ता के निजी डेटा को ऐक्सेस करने का विकल्प होता है. अगर उपयोगकर्ता ने अनुमति नहीं दी है, तो अपने ऐप्लिकेशन के अनुभव को बेहतर बनाएं, ताकि वह उपयोगकर्ता को उस जानकारी के बिना फ़ंक्शन उपलब्ध करा सके जिसे उस अनुमति से सुरक्षित किया गया है.

पहली इमेज में, इस प्रोसेस से जुड़े वर्कफ़्लो और फ़ैसलों के सेट को दिखाया गया है:

पहली इमेज. Android पर रनटाइम की अनुमतियों का एलान करने और उनके लिए अनुरोध करने का वर्कफ़्लो दिखाने वाला डायग्राम.

देखें कि आपके ऐप्लिकेशन को पहले से अनुमति दी गई थी या नहीं

यह पता करने के लिए कि उपयोगकर्ता ने आपके ऐप्लिकेशन को पहले से ही कोई अनुमति दी है या नहीं, उस अनुमति को ContextCompat.checkSelfPermission() वाले तरीके में पास करें. यह तरीका, PERMISSION_GRANTED या PERMISSION_DENIED दिखाता है. यह इस बात पर निर्भर करता है कि आपके ऐप्लिकेशन के पास अनुमति है या नहीं.

बताएं कि आपके ऐप्लिकेशन को इस अनुमति की ज़रूरत क्यों है

requestPermissions() को कॉल करने पर, सिस्टम से दिखने वाला अनुमतियों का डायलॉग बॉक्स बताता है कि आपके ऐप्लिकेशन को कौनसी अनुमति चाहिए. हालांकि, इसमें यह नहीं बताया जाता कि यह अनुमति क्यों चाहिए. कुछ मामलों में, उपयोगकर्ता को यह समझ नहीं आ सकता. requestPermissions() को कॉल करने से पहले, उपयोगकर्ता को यह बताना अच्छा होता है कि आपके ऐप्लिकेशन को अनुमतियां क्यों चाहिए.

रिसर्च से पता चलता है कि जब उपयोगकर्ताओं को यह पता होता है कि ऐप्लिकेशन को अनुमतियों की ज़रूरत क्यों है, तो वे उन्हें आसानी से दे देते हैं. जैसे, क्या अनुमति की ज़रूरत ऐप्लिकेशन की मुख्य सुविधा के काम करने के लिए है या विज्ञापन दिखाने के लिए. इस वजह से, अगर एपीआई कॉल के सिर्फ़ उन हिस्सों का इस्तेमाल किया जा रहा है जो अनुमतियों के किसी ग्रुप में आते हैं, तो इससे यह साफ़ तौर पर बताने में मदद मिलती है कि इनमें से किन अनुमतियों का इस्तेमाल किया जा रहा है और क्यों किया जा रहा है. उदाहरण के लिए, अगर सिर्फ़ जगह की अनुमानित जानकारी का इस्तेमाल किया जा रहा है, तो ऐप्लिकेशन के ब्यौरे या ऐप्लिकेशन के सहायता लेखों में उपयोगकर्ता को इसकी जानकारी दें.

कुछ मामलों में, उपयोगकर्ताओं को रीयल टाइम में संवेदनशील डेटा के ऐक्सेस के बारे में बताना भी मददगार होता है. उदाहरण के लिए, अगर आपके ऐप्लिकेशन में कैमरे या माइक्रोफ़ोन का इस्तेमाल किया जा रहा है, तो उपयोगकर्ता को इसकी सूचना देना अच्छा होगा. इसके लिए, अपने ऐप्लिकेशन में कहीं भी सूचना आइकॉन का इस्तेमाल करें या सूचना ट्रे में सूचना दें. ऐसा तब करें, जब ऐप्लिकेशन बैकग्राउंड में चल रहा हो. इससे यह नहीं लगेगा कि आप चुपके से डेटा इकट्ठा कर रहे हैं.

अगर आपको अपने ऐप्लिकेशन में किसी सुविधा को काम करने के लिए अनुमति का अनुरोध करना है, लेकिन उपयोगकर्ता को इसकी वजह साफ़ तौर पर नहीं पता है, तो उपयोगकर्ता को यह बताएं कि आपको सबसे संवेदनशील अनुमतियों की ज़रूरत क्यों है.

अगर ContextCompat.checkSelfPermission() तरीका PERMISSION_DENIED दिखाता है, तो shouldShowRequestPermissionRationale() को कॉल करें. अगर यह तरीका true दिखाता है, तो उपयोगकर्ता को जानकारी देने वाला यूज़र इंटरफ़ेस (यूआई) दिखाएं. इस यूज़र इंटरफ़ेस (यूआई) में, बताएं कि उपयोगकर्ता को जिस सुविधा को चालू करना है उसके लिए किसी खास अनुमति की ज़रूरत क्यों है.

इसके अलावा, अगर आपका ऐप्लिकेशन जगह की जानकारी, माइक्रोफ़ोन या कैमरे से जुड़ी अनुमति का अनुरोध करता है, तो बताएं कि आपके ऐप्लिकेशन को इस जानकारी का ऐक्सेस क्यों चाहिए.

अनुमतियां मांगें

जब उपयोगकर्ता कोई शिक्षा से जुड़ा यूज़र इंटरफ़ेस देख ले या shouldShowRequestPermissionRationale() की रिटर्न वैल्यू से पता चलता हो कि आपको शिक्षा से जुड़ा कोई यूज़र इंटरफ़ेस दिखाने की ज़रूरत नहीं है, तो अनुमति का अनुरोध करें. उपयोगकर्ताओं को सिस्टम की अनुमति वाला डायलॉग दिखता है. इसमें वे यह चुन सकते हैं कि आपके ऐप्लिकेशन को कोई खास अनुमति देनी है या नहीं.

ऐसा करने के लिए, AndroidX लाइब्रेरी में शामिल RequestPermission कंट्रेट का इस्तेमाल करें. इसमें, सिस्टम को अनुमति के अनुरोध वाले कोड को मैनेज करने की अनुमति दी जाती है. RequestPermission कॉन्ट्रैक्ट का इस्तेमाल करने से, आपके लॉजिक को आसानी से समझा जा सकता है. इसलिए, जब भी हो सके, इसका इस्तेमाल करने का सुझाव दिया जाता है. हालांकि, ज़रूरत पड़ने पर अनुमति के अनुरोध के हिस्से के तौर पर, खुद से अनुरोध कोड मैनेज किया जा सकता है. साथ ही, इस अनुरोध कोड को अनुमति के कॉलबैक लॉजिक में शामिल किया जा सकता है.

सिस्टम को अनुमति अनुरोध कोड मैनेज करने की अनुमति दें

अनुमतियों के अनुरोध से जुड़े अनुरोध कोड को सिस्टम मैनेज कर सके, इसके लिए अपने मॉड्यूल की build.gradle फ़ाइल में इन लाइब्रेरी की डिपेंडेंसी जोड़ें:

इसके बाद, इनमें से किसी एक क्लास का इस्तेमाल किया जा सकता है:

  • किसी एक अनुमति का अनुरोध करने के लिए, RequestPermission का इस्तेमाल करें.
  • एक साथ कई अनुमतियों का अनुरोध करने के लिए, RequestMultiplePermissions का इस्तेमाल करें.

RequestPermission समझौते का इस्तेमाल करने का तरीका यहां बताया गया है. RequestMultiplePermissions समझौते के लिए भी प्रोसेस करीब-करीब एक जैसी है.

  1. अपनी गतिविधि या फ़्रैगमेंट के शुरू होने के लॉजिक में, registerForActivityResult() को कॉल करके ActivityResultCallback को लागू करें. ActivityResultCallback से यह तय होता है कि आपका ऐप्लिकेशन, अनुमति के अनुरोध के लिए उपयोगकर्ता के जवाब को कैसे मैनेज करता है.

    registerForActivityResult() की रिटर्न वैल्यू का रेफ़रंस रखें, जो ActivityResultLauncher टाइप की हो.

  2. ज़रूरत पड़ने पर, सिस्टम की अनुमतियों का डायलॉग बॉक्स दिखाने के लिए, ActivityResultLauncher के उस इंस्टेंस पर launch() तरीका कॉल करें जिसे आपने पिछले चरण में सेव किया था.

    launch() को कॉल करने के बाद, सिस्टम की अनुमतियों वाला डायलॉग बॉक्स दिखता है. जब उपयोगकर्ता कोई विकल्प चुनता है, तो सिस्टम एसिंक्रोनस रूप से ActivityResultCallback को लागू करने की आपकी प्रोसेस शुरू करता है. इसकी जानकारी आपने पिछले चरण में दी थी.

    ध्यान दें: launch() को कॉल करने पर दिखने वाले डायलॉग को आपका ऐप्लिकेशन कस्टमाइज़ नहीं कर सकता. उपयोगकर्ता को ज़्यादा जानकारी या संदर्भ देने के लिए, अपने ऐप्लिकेशन का यूज़र इंटरफ़ेस (यूआई) बदलें, ताकि उपयोगकर्ता यह आसानी से समझ सकें कि आपके ऐप्लिकेशन की किसी सुविधा के लिए खास अनुमति की ज़रूरत क्यों है. उदाहरण के लिए, आपके पास उस बटन के टेक्स्ट को बदलने का विकल्प होता है जिससे सुविधा चालू होती है.

    साथ ही, सिस्टम की अनुमति वाले डायलॉग बॉक्स में मौजूद टेक्स्ट, आपके अनुरोध की गई अनुमति से जुड़े अनुमति ग्रुप का रेफ़रंस देता है. अनुमतियों के इस ग्रुप को, सिस्टम को आसानी से इस्तेमाल करने के लिए डिज़ाइन किया गया है. आपके ऐप्लिकेशन को इस बात पर भरोसा नहीं करना चाहिए कि अनुमतियां किसी खास अनुमति ग्रुप में शामिल हैं या नहीं.

यहां दिया गया कोड स्निपेट, अनुमतियों के रिस्पॉन्स को मैनेज करने का तरीका दिखाता है:

Kotlin

// Register the permissions callback, which handles the user's response to the
// system permissions dialog. Save the return value, an instance of
// ActivityResultLauncher. You can use either a val, as shown in this snippet,
// or a lateinit var in your onAttach() or onCreate() method.
val requestPermissionLauncher =
    registerForActivityResult(RequestPermission()
    ) { isGranted: Boolean ->
        if (isGranted) {
            // Permission is granted. Continue the action or workflow in your
            // app.
        } else {
            // Explain to the user that the feature is unavailable because the
            // feature requires a permission that the user has denied. At the
            // same time, respect the user's decision. Don't link to system
            // settings in an effort to convince the user to change their
            // decision.
        }
    }

Java

// Register the permissions callback, which handles the user's response to the
// system permissions dialog. Save the return value, an instance of
// ActivityResultLauncher, as an instance variable.
private ActivityResultLauncher<String> requestPermissionLauncher =
    registerForActivityResult(new RequestPermission(), isGranted -> {
        if (isGranted) {
            // Permission is granted. Continue the action or workflow in your
            // app.
        } else {
            // Explain to the user that the feature is unavailable because the
            // feature requires a permission that the user has denied. At the
            // same time, respect the user's decision. Don't link to system
            // settings in an effort to convince the user to change their
            // decision.
        }
    });

इस कोड स्निपेट में, अनुमति की जांच करने और ज़रूरत पड़ने पर उपयोगकर्ता से अनुमति का अनुरोध करने के लिए, सुझाई गई प्रोसेस के बारे में बताया गया है:

Kotlin

when {
    ContextCompat.checkSelfPermission(
            CONTEXT,
            Manifest.permission.REQUESTED_PERMISSION
            ) == PackageManager.PERMISSION_GRANTED -> {
        // You can use the API that requires the permission.
    }
    ActivityCompat.shouldShowRequestPermissionRationale(
            this, Manifest.permission.REQUESTED_PERMISSION) -> {
        // In an educational UI, explain to the user why your app requires this
        // permission for a specific feature to behave as expected, and what
        // features are disabled if it's declined. In this UI, include a
        // "cancel" or "no thanks" button that lets the user continue
        // using your app without granting the permission.
        showInContextUI(...)
    }
    else -> {
        // You can directly ask for the permission.
        // The registered ActivityResultCallback gets the result of this request.
        requestPermissionLauncher.launch(
                Manifest.permission.REQUESTED_PERMISSION)
    }
}

Java

if (ContextCompat.checkSelfPermission(
        CONTEXT, Manifest.permission.REQUESTED_PERMISSION) ==
        PackageManager.PERMISSION_GRANTED) {
    // You can use the API that requires the permission.
    performAction(...);
} else if (ActivityCompat.shouldShowRequestPermissionRationale(
        this, Manifest.permission.REQUESTED_PERMISSION)) {
    // In an educational UI, explain to the user why your app requires this
    // permission for a specific feature to behave as expected, and what
    // features are disabled if it's declined. In this UI, include a
    // "cancel" or "no thanks" button that lets the user continue
    // using your app without granting the permission.
    showInContextUI(...);
} else {
    // You can directly ask for the permission.
    // The registered ActivityResultCallback gets the result of this request.
    requestPermissionLauncher.launch(
            Manifest.permission.REQUESTED_PERMISSION);
}

अनुमति के अनुरोध का कोड खुद मैनेज करना

सिस्टम को अनुमति के अनुरोध का कोड मैनेज करने की अनुमति देने के बजाय, आपके पास अनुमति के अनुरोध के कोड को खुद मैनेज करने का विकल्प होता है. ऐसा करने के लिए, requestPermissions() पर किए गए कॉल में अनुरोध कोड शामिल करें.

नीचे दिए गए कोड स्निपेट में, अनुरोध के कोड का इस्तेमाल करके अनुमति का अनुरोध करने का तरीका बताया गया है:

Kotlin

when {
    ContextCompat.checkSelfPermission(
            CONTEXT,
            Manifest.permission.REQUESTED_PERMISSION
            ) == PackageManager.PERMISSION_GRANTED -> {
        // You can use the API that requires the permission.
        performAction(...)
    }
    ActivityCompat.shouldShowRequestPermissionRationale(
            this, Manifest.permission.REQUESTED_PERMISSION) -> {
        // In an educational UI, explain to the user why your app requires this
        // permission for a specific feature to behave as expected, and what
        // features are disabled if it's declined. In this UI, include a
        // "cancel" or "no thanks" button that lets the user continue
        // using your app without granting the permission.
        showInContextUI(...)
    }
    else -> {
        // You can directly ask for the permission.
        requestPermissions(CONTEXT,
                arrayOf(Manifest.permission.REQUESTED_PERMISSION),
                REQUEST_CODE)
    }
}

Java

if (ContextCompat.checkSelfPermission(
        CONTEXT, Manifest.permission.REQUESTED_PERMISSION) ==
        PackageManager.PERMISSION_GRANTED) {
    // You can use the API that requires the permission.
    performAction(...);
} else if (ActivityCompat.shouldShowRequestPermissionRationale(
        this, Manifest.permission.REQUESTED_PERMISSION)) {
    // In an educational UI, explain to the user why your app requires this
    // permission for a specific feature to behave as expected, and what
    // features are disabled if it's declined. In this UI, include a
    // "cancel" or "no thanks" button that lets the user continue
    // using your app without granting the permission.
    showInContextUI(...);
} else {
    // You can directly ask for the permission.
    requestPermissions(CONTEXT,
            new String[] { Manifest.permission.REQUESTED_PERMISSION },
            REQUEST_CODE);
}

जब उपयोगकर्ता, सिस्टम की अनुमतियों वाले डायलॉग बॉक्स में जवाब देता है, तो सिस्टम आपके ऐप्लिकेशन में onRequestPermissionsResult() को लागू करता है. सिस्टम, अनुमति वाले डायलॉग बॉक्स में उपयोगकर्ता के जवाब के साथ-साथ, आपके तय किए गए अनुरोध कोड को भी पास करता है. इस बारे में यहां दिए गए कोड स्निपेट में बताया गया है:

Kotlin

override fun onRequestPermissionsResult(requestCode: Int,
        permissions: Array<String>, grantResults: IntArray) {
    when (requestCode) {
        PERMISSION_REQUEST_CODE -> {
            // If request is cancelled, the result arrays are empty.
            if ((grantResults.isNotEmpty() &&
                    grantResults[0] == PackageManager.PERMISSION_GRANTED)) {
                // Permission is granted. Continue the action or workflow
                // in your app.
            } else {
                // Explain to the user that the feature is unavailable because
                // the feature requires a permission that the user has denied.
                // At the same time, respect the user's decision. Don't link to
                // system settings in an effort to convince the user to change
                // their decision.
            }
            return
        }

        // Add other 'when' lines to check for other
        // permissions this app might request.
        else -> {
            // Ignore all other requests.
        }
    }
}

Java

@Override
public void onRequestPermissionsResult(int requestCode, String[] permissions,
        int[] grantResults) {
    switch (requestCode) {
        case PERMISSION_REQUEST_CODE:
            // If request is cancelled, the result arrays are empty.
            if (grantResults.length > 0 &&
                    grantResults[0] == PackageManager.PERMISSION_GRANTED) {
                // Permission is granted. Continue the action or workflow
                // in your app.
            }  else {
                // Explain to the user that the feature is unavailable because
                // the feature requires a permission that the user has denied.
                // At the same time, respect the user's decision. Don't link to
                // system settings in an effort to convince the user to change
                // their decision.
            }
            return;
        }
        // Other 'case' lines to check for other
        // permissions this app might request.
    }
}

जगह की जानकारी की अनुमतियों का अनुरोध करना

जगह की जानकारी की अनुमतियों का अनुरोध करते समय, उन सभी सबसे सही तरीकों का पालन करें जो किसी भी रनटाइम की अनुमति के लिए अपनाए जाते हैं. जगह की जानकारी की अनुमतियों के मामले में एक अहम फ़र्क़ यह होता है कि सिस्टम में जगह की जानकारी से जुड़ी कई अनुमतियां शामिल होती हैं. आपको किन अनुमतियों का अनुरोध करना है और कैसे करना है, यह इस बात पर निर्भर करता है कि आपके ऐप्लिकेशन के इस्तेमाल के उदाहरण के लिए, जगह की जानकारी की ज़रूरी शर्तें क्या हैं.

फ़ोरग्राउंड में जगह की जानकारी

अगर आपके ऐप्लिकेशन में ऐसी सुविधा है जो सिर्फ़ एक बार या तय समय के लिए जगह की जानकारी शेयर करती है या उसे ऐक्सेस करती है, तो उस सुविधा के लिए फ़ोरग्राउंड में जगह की जानकारी ऐक्सेस करने की ज़रूरत होती है. इसके कुछ उदाहरण यहां दिए गए हैं:

  • नेविगेशन ऐप्लिकेशन में मौजूद एक सुविधा की मदद से, उपयोगकर्ताओं को मोड़-दर-मोड़ निर्देश मिलते हैं.
  • मैसेजिंग ऐप्लिकेशन में मौजूद एक सुविधा की मदद से, उपयोगकर्ता अपनी मौजूदा जगह की जानकारी किसी दूसरे उपयोगकर्ता के साथ शेयर कर सकते हैं.

अगर आपके ऐप्लिकेशन की कोई सुविधा, यहां दी गई किसी स्थिति में डिवाइस की मौजूदा जगह की जानकारी ऐक्सेस करती है, तो सिस्टम आपके ऐप्लिकेशन को फ़ोरग्राउंड जगह की जानकारी का इस्तेमाल मानता है:

  • आपके ऐप्लिकेशन से जुड़ी गतिविधि दिखती है.

  • आपका ऐप्लिकेशन, फ़ोरग्राउंड सेवा चला रहा है. जब कोई फ़ोरग्राउंड सेवा चल रही होती है, तो सिस्टम उपयोगकर्ता को इसकी सूचना देता है. जब आपका ऐप्लिकेशन बैकग्राउंड में चल रहा होता है, तब भी वह डिवाइस के डेटा को ऐक्सेस करता रहता है. जैसे, जब उपयोगकर्ता अपने डिवाइस पर होम बटन दबाता है या डिवाइस का डिसप्ले बंद करता है.

    Android 10 (एपीआई लेवल 29) और इसके बाद के वर्शन पर, आपको location के फ़ोरग्राउंड सेवा टाइप के बारे में बताना होगा. इस बारे में नीचे दिए गए कोड स्निपेट में बताया गया है. हमारा सुझाव है कि Android के पुराने वर्शन पर, फ़ोरग्राउंड सेवा के इस टाइप का एलान करें.

    <!-- Recommended for Android 9 (API level 28) and lower. -->
<!-- Required for Android 10 (API level 29) and higher. -->
<service
    android:name="MyNavigationService"
    android:foregroundServiceType="location" ... >
    <!-- Any inner elements go here. -->
</service>

जब आपका ऐप्लिकेशन, स्क्रीन पर खुला होने पर जगह की जानकारी ऐक्सेस करने की अनुमति या स्क्रीन पर बंद होने पर जगह की जानकारी ऐक्सेस करने की अनुमति का अनुरोध करता है, तब आपके ऐप्लिकेशन को फ़ोरग्राउंड में जगह की जानकारी की ज़रूरत होती है. इसकी जानकारी, यहां दिए गए स्निपेट में दी गई है:

<manifest ... >
  <!-- Include this permission any time your app needs location information. -->
  <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />

  <!-- Include only if your app benefits from precise location access. -->
  <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
</manifest>

बैकग्राउंड में जगह की जानकारी

अगर ऐप्लिकेशन में मौजूद कोई सुविधा, लगातार दूसरे लोगों के साथ जगह की जानकारी शेयर करती आ रही है या Geofence API का इस्तेमाल करती है, तो ऐप्लिकेशन के लिए बैकग्राउंड में जगह की जानकारी ऐक्सेस करने की ज़रूरत होती है. इसके कुछ उदाहरण यहां दिए गए हैं:

  • परिवार के साथ जगह की जानकारी शेयर करने वाले ऐप्लिकेशन में, एक सुविधा की मदद से उपयोगकर्ता अपने परिवार के सदस्यों के साथ जगह की जानकारी लगातार शेयर कर सकते हैं.
  • IoT ऐप्लिकेशन में यह सुविधा, उपयोगकर्ताओं को अपने होम डिवाइस को इस तरह से कॉन्फ़िगर करने देती है कि जब उपयोगकर्ता घर से बाहर जाए, तो वह अपने-आप बंद हो जाए और जब वह वापस घर आए, तो वह फिर से चालू हो जाए.

अगर आपका ऐप्लिकेशन, फ़ोरग्राउंड में जगह की जानकारी सेक्शन में बताई गई स्थितियों के अलावा किसी और स्थिति में डिवाइस की मौजूदा जगह की जानकारी ऐक्सेस करता है, तो सिस्टम यह मान लेता है कि आपका ऐप्लिकेशन बैकग्राउंड में जगह की जानकारी का इस्तेमाल कर रहा है. बैकग्राउंड में जगह की सटीक जानकारी, फ़ोरग्राउंड में जगह की सटीक जानकारी की तरह होती है. यह जगह की उन अनुमतियों पर निर्भर करती है जिनका एलान आपके ऐप्लिकेशन में किया जाता है.

Android 10 (एपीआई लेवल 29) और उसके बाद के वर्शन पर, रनटाइम के दौरान बैकग्राउंड में जगह की जानकारी ऐक्सेस करने का अनुरोध करने के लिए, आपको अपने ऐप्लिकेशन के मेनिफ़ेस्ट में ACCESS_BACKGROUND_LOCATION की अनुमति का एलान करना होगा. Android के पुराने वर्शन में, जब आपके ऐप्लिकेशन को फ़ोरग्राउंड में जगह की जानकारी का ऐक्सेस मिलता है, तो उसे बैकग्राउंड में भी जगह की जानकारी का ऐक्सेस अपने-आप मिल जाता है.

<manifest ... >
  <!-- Required only when requesting background location access on
       Android 10 (API level 29) and higher. -->
  <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />
</manifest>

अनुमति न मिलने की समस्या को मैनेज करें

अगर उपयोगकर्ता किसी अनुमति का अनुरोध अस्वीकार करता है, तो आपके ऐप्लिकेशन को उपयोगकर्ताओं को यह समझने में मदद करनी चाहिए कि अनुमति अस्वीकार करने के नतीजे क्या होते हैं. खास तौर पर, आपके ऐप्लिकेशन को उपयोगकर्ताओं को उन सुविधाओं के बारे में बताना चाहिए जो अनुमति न मिलने की वजह से काम नहीं करती हैं. ऐसा करते समय, इन सबसे सही तरीकों को ध्यान में रखें:

  • उपयोगकर्ता का ध्यान खींचने के लिए. अपने ऐप्लिकेशन के यूज़र इंटरफ़ेस (यूआई) के उस हिस्से को हाइलाइट करें जहां सीमित सुविधाएं उपलब्ध हैं. इसकी वजह यह है कि आपके ऐप्लिकेशन के पास ज़रूरी अनुमति नहीं है. ये तरीके इस्तेमाल किए जा सकते हैं:

    • वह मैसेज दिखाएं जहां सुविधा के नतीजे या डेटा दिखता था.
    • गड़बड़ी का आइकॉन और रंग वाला कोई दूसरा बटन दिखाएं.

  • सटीक जानकारी दें. सामान्य मैसेज न दिखाएं. इसके बजाय, साफ़ तौर पर बताएं कि आपके ऐप्लिकेशन के पास ज़रूरी अनुमति न होने की वजह से कौनसी सुविधाएं उपलब्ध नहीं हैं.

  • उपयोगकर्ता इंटरफ़ेस को ब्लॉक न करें. दूसरे शब्दों में, ऐसा कोई मैसेज न दिखाएं जो स्क्रीन पर पूरा दिखे और उपयोगकर्ताओं को आपके ऐप्लिकेशन का इस्तेमाल करने से पूरी तरह से रोक दे.

साथ ही, आपके ऐप्लिकेशन को अनुमति न देने के उपयोगकर्ता के फ़ैसले का सम्मान करना चाहिए. Android 11 (एपीआई लेवल 30) से, अगर उपयोगकर्ता किसी डिवाइस पर आपके ऐप्लिकेशन के इंस्टॉल होने के दौरान, किसी खास अनुमति के लिए एक से ज़्यादा बार अस्वीकार करें पर टैप करता है, तो आपका ऐप्लिकेशन उस अनुमति का फिर से अनुरोध करने पर, उपयोगकर्ता को सिस्टम की अनुमतियों वाला डायलॉग नहीं दिखता. उपयोगकर्ता की कार्रवाई का मतलब है कि "फिर से न पूछें." पिछले वर्शन में, जब भी आपका ऐप्लिकेशन किसी अनुमति का अनुरोध करता था, तब उपयोगकर्ताओं को सिस्टम की अनुमतियों वाला डायलॉग दिखता था. हालांकि, अगर उन्होंने पहले "फिर से न पूछें" चेकबॉक्स या विकल्प चुना था, तो ऐसा नहीं होता था.

अगर कोई उपयोगकर्ता अनुमति के अनुरोध को एक से ज़्यादा बार अस्वीकार करता है, तो इसे हमेशा के लिए अस्वीकार माना जाता है. यह ज़रूरी है कि उपयोगकर्ताओं से अनुमतियां सिर्फ़ तब मांगी जाएं, जब उन्हें किसी खास सुविधा का ऐक्सेस चाहिए. ऐसा न करने पर, हो सकता है कि आप अनुमतियों का फिर से अनुरोध न कर पाएं.

कुछ मामलों में, उपयोगकर्ता की ओर से कोई कार्रवाई किए बिना, अनुमति अपने-आप अस्वीकार हो सकती है. (अनुमति अपने-आप भी दी जा सकती है.) अपने-आप होने वाले व्यवहार के बारे में कुछ भी सोचना नहीं चाहिए. जब भी आपके ऐप्लिकेशन को किसी ऐसी सुविधा को ऐक्सेस करने की ज़रूरत हो जिसके लिए अनुमति की ज़रूरत है, तो देखें कि आपके ऐप्लिकेशन को अब भी वह अनुमति मिली हुई है या नहीं.

ऐप्लिकेशन की अनुमतियों के बारे में पूछते समय सबसे अच्छा उपयोगकर्ता अनुभव देने के लिए, ऐप्लिकेशन अनुमतियों के सबसे सही तरीके भी देखें.

जांच और डीबग करते समय, अस्वीकार किए जाने की स्थिति की जांच करना

यह पता लगाने के लिए कि किसी ऐप्लिकेशन को अनुमतियां हमेशा के लिए दी गई हैं या नहीं (डीबग करने और जांच करने के लिए), नीचे दिए गए निर्देश का इस्तेमाल करें:

adb shell dumpsys package PACKAGE_NAME

यहां PACKAGE_NAME, उस पैकेज का नाम है जिसकी जांच करनी है.

कमांड के आउटपुट में ऐसे सेक्शन होते हैं जो इस तरह दिखते हैं:

...
runtime permissions:
  android.permission.POST_NOTIFICATIONS: granted=false, flags=[ USER_SENSITIVE_WHEN_GRANTED|USER_SENSITIVE_WHEN_DENIED]
  android.permission.ACCESS_FINE_LOCATION: granted=false, flags=[ USER_SET|USER_FIXED|USER_SENSITIVE_WHEN_GRANTED|USER_SENSITIVE_WHEN_DENIED]
  android.permission.BLUETOOTH_CONNECT: granted=false, flags=[ USER_SENSITIVE_WHEN_GRANTED|USER_SENSITIVE_WHEN_DENIED]
...

जिन अनुमतियों को उपयोगकर्ता ने एक बार अस्वीकार कर दिया है उन्हें USER_SET से फ़्लैग किया जाता है. जिन अनुमतियों को अनुमति न दें को दो बार चुनकर हमेशा के लिए अस्वीकार किया गया है उन पर USER_FIXED का निशान लगा होता है.

यह पक्का करने के लिए कि टेस्टर को टेस्टिंग के दौरान अनुरोध डायलॉग दिखे, अपने ऐप्लिकेशन की गड़बड़ियों को ठीक करने के बाद इन फ़्लैग को रीसेट करें. इसके लिए, इस निर्देश का इस्तेमाल करें:

adb shell pm clear-permission-flags PACKAGE_NAME PERMISSION_NAME user-set user-fixed

PERMISSION_NAME, उस अनुमति का नाम है जिसे आपको रीसेट करना है.

Android ऐप्लिकेशन की अनुमतियों की पूरी सूची देखने के लिए, अनुमतियां एपीआई के रेफ़रंस पेज पर जाएं.

एक बार के लिए दी जाने वाली अनुमतियां

&#39;सिर्फ़ इस बार&#39; विकल्प, डायलॉग बॉक्स में मौजूद तीन बटनों में से दूसरा है.
दूसरी इमेज. सिस्टम डायलॉग, यह तब दिखता है, जब कोई ऐप्लिकेशन एक बार के लिए अनुमति का अनुरोध करता है.

Android 11 (एपीआई लेवल 30) से, जब भी आपका ऐप्लिकेशन जगह की जानकारी, माइक्रोफ़ोन या कैमरे से जुड़ी अनुमति का अनुरोध करता है, तो उपयोगकर्ता को दिखने वाले अनुमति डायलॉग में सिर्फ़ इस बार नाम का एक विकल्प दिखता है, जैसा कि दूसरे चित्र में दिखाया गया है. अगर उपयोगकर्ता डायलॉग बॉक्स में यह विकल्प चुनता है, तो आपके ऐप्लिकेशन को कुछ समय के लिए एक बार इस्तेमाल करने की अनुमति मिलती है.

आपके ऐप्लिकेशन से जुड़े डेटा को कुछ समय तक ऐक्सेस किया जा सकता है, जो आपके ऐप्लिकेशन के व्यवहार और उपयोगकर्ता की कार्रवाइयों के हिसाब से तय होता है:

  • जब तक आपके ऐप्लिकेशन की गतिविधि दिखती है, तब तक आपका ऐप्लिकेशन डेटा ऐक्सेस कर सकता है.
  • अगर उपयोगकर्ता आपके ऐप्लिकेशन को बैकग्राउंड में भेजता है, तो आपका ऐप्लिकेशन कुछ समय के लिए डेटा को ऐक्सेस करना जारी रख सकता है.
  • अगर गतिविधि दिखने के दौरान कोई फ़ोरग्राउंड सेवा लॉन्च की जाती है और उपयोगकर्ता आपके ऐप्लिकेशन को बैकग्राउंड में ले जाता है, तो आपका ऐप्लिकेशन तब तक डेटा ऐक्सेस करता रहेगा, जब तक फ़ोरग्राउंड सेवा बंद नहीं हो जाती.

अनुमति रद्द होने पर, ऐप्लिकेशन की प्रोसेस रद्द हो जाती है

अगर उपयोगकर्ता, सिस्टम सेटिंग में जाकर एक बार के लिए दी गई अनुमति को रद्द कर देता है, तो आपका ऐप्लिकेशन डेटा ऐक्सेस नहीं कर पाएगा. भले ही, आपने फ़ोरग्राउंड सेवा लॉन्च की हो. किसी भी अनुमति की तरह, अगर उपयोगकर्ता आपके ऐप्लिकेशन को एक बार दी गई अनुमति को रद्द कर देता है, तो आपके ऐप्लिकेशन की प्रोसेस खत्म हो जाती है.

जब उपयोगकर्ता अगली बार आपका ऐप्लिकेशन खोलता है और आपके ऐप्लिकेशन की कोई सुविधा, जगह की जानकारी, माइक्रोफ़ोन या कैमरे का ऐक्सेस मांगती है, तो उपयोगकर्ता से फिर से अनुमति मांगी जाती है.

इस्तेमाल नहीं की गई अनुमतियां रीसेट करना

Android, इस्तेमाल नहीं की गई रनटाइम अनुमतियों को डिफ़ॉल्ट तौर पर 'अनुमति नहीं दी गई' स्थिति पर रीसेट करने के कई तरीके उपलब्ध कराता है:

ऐप्लिकेशन का ऐक्सेस हटाना

Android 13 (एपीआई लेवल 33) और उसके बाद वाले वर्शन पर, रनटाइम की उन अनुमतियों को हटाया जा सकता है जिनकी अब आपके ऐप्लिकेशन को ज़रूरत नहीं है. अपना ऐप्लिकेशन अपडेट करने पर, यह तरीका अपनाएं. इससे, उपयोगकर्ताओं के यह समझने में मदद मिलेगी कि आपका ऐप्लिकेशन खास अनुमतियों का अनुरोध क्यों कर रहा है. इस जानकारी से, उपयोगकर्ताओं का आपके ऐप्लिकेशन पर भरोसा बढ़ता है.

किसी रनटाइम की अनुमति का ऐक्सेस हटाने के लिए, उस अनुमति का नाम revokeSelfPermissionOnKill() में डालें. एक साथ कई रनटाइम अनुमतियों का ऐक्सेस हटाने के लिए, अनुमतियों के नामों का कलेक्शन revokeSelfPermissionsOnKill() में पास करें. अनुमति हटाने की प्रोसेस, अलग-अलग समय पर होती है. साथ ही, यह आपके ऐप्लिकेशन के यूआईडी से जुड़ी सभी प्रोसेस को बंद कर देती है.

सिस्टम आपके ऐप्लिकेशन से अनुमतियों का ऐक्सेस हटा सकता है. इसके लिए, आपके ऐप्लिकेशन से जुड़ी सभी प्रोसेस को बंद करना ज़रूरी है. एपीआई को कॉल करने पर, सिस्टम यह तय करता है कि इन प्रोसेस को कब बंद किया जा सकता है. आम तौर पर, सिस्टम तब तक इंतज़ार करता है, जब तक आपका ऐप्लिकेशन फ़ोरग्राउंड के बजाय, बैकग्राउंड में ज़्यादा समय तक नहीं चल जाता.

उपयोगकर्ता को यह बताने के लिए कि आपके ऐप्लिकेशन को अब कुछ खास रनटाइम अनुमतियों का ऐक्सेस नहीं चाहिए, अगली बार जब उपयोगकर्ता आपका ऐप्लिकेशन लॉन्च करे, तो उसे एक डायलॉग दिखाएं. इस डायलॉग में अनुमतियों की सूची शामिल की जा सकती है.

इस्तेमाल नहीं किए जा रहे ऐप्लिकेशन की अनुमतियां अपने-आप रीसेट होना

अगर आपका ऐप्लिकेशन Android 11 (एपीआई लेवल 30) या उसके बाद के वर्शन को टारगेट करता है और उसका इस्तेमाल कुछ महीनों से नहीं किया गया है, तो सिस्टम उपयोगकर्ता के डेटा की सुरक्षा करता है. इसके लिए, वह रनटाइम के दौरान ऐप्लिकेशन को दी गई संवेदनशील अनुमतियों को अपने-आप रीसेट कर देता है. ऐप्लिकेशन को हाइबरनेट करने के बारे में ज़्यादा जानने के लिए, गाइड पढ़ें.

ज़रूरत पड़ने पर, डिफ़ॉल्ट हैंडलर बनने का अनुरोध करना

कुछ ऐप्लिकेशन, उपयोगकर्ता के कॉल लॉग और एसएमएस से जुड़ी संवेदनशील जानकारी का इस्तेमाल करते हैं. अगर आपको कॉल लॉग और एसएमएस मैसेज की अनुमतियों का अनुरोध करना है और अपने ऐप्लिकेशन को Play Store पर पब्लिश करना है, तो आपको उपयोगकर्ता से कहना होगा कि वह रनटाइम की इन अनुमतियों का अनुरोध करने से पहले, आपके ऐप्लिकेशन को मुख्य सिस्टम फ़ंक्शन के लिए डिफ़ॉल्ट हैंडलर के तौर पर सेट करे.

डिफ़ॉल्ट हैंडलर के बारे में ज़्यादा जानकारी के लिए, सिर्फ़ डिफ़ॉल्ट हैंडलर में इस्तेमाल की जाने वाली अनुमतियों के बारे में गाइड देखें. इसमें, उपयोगकर्ताओं को डिफ़ॉल्ट हैंडलर प्रॉम्प्ट दिखाने के बारे में भी दिशा-निर्देश शामिल हैं.

जांच के लिए सभी रनटाइम की अनुमतियां दें

एम्युलेटर या टेस्ट डिवाइस पर ऐप्लिकेशन इंस्टॉल करते समय, रनटाइम की सभी अनुमतियां अपने-आप देने के लिए, adb shell install कमांड के लिए -g विकल्प का इस्तेमाल करें, जैसा कि इस कोड स्निपेट में बताया गया है:

adb shell install -g PATH_TO_APK_FILE

अन्य संसाधन

अनुमतियों के बारे में ज़्यादा जानकारी के लिए, ये लेख पढ़ें:

अनुमतियों का अनुरोध करने के बारे में ज़्यादा जानने के लिए, अनुमतियों के सैंपल देखें

निजता से जुड़ी सबसे सही कार्रवाइयों के बारे में बताने वाला कोडलैब भी पूरा किया जा सकता है.

पीछे जाएं
ऐप्लिकेशन अनुमतियों का एलान करना
आगे बढ़ें
विशेष अनुमतियों का अनुरोध करें