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

हर 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 फ़ाइल में इन लाइब्रेरी की डिपेंडेंसी जोड़ें:

  • androidx.activity, वर्शन 1.2.0 या इसके बाद का वर्शन
  • androidx.fragment, 1.3.0 या इसके बाद का वर्शन

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

  • किसी एक अनुमति का अनुरोध करने के लिए, 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>

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

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

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

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

  • परिवार के साथ जगह की जानकारी शेयर करने वाले ऐप्लिकेशन में, एक सुविधा की मदद से उपयोगकर्ता अपने परिवार के सदस्यों के साथ जगह की जानकारी लगातार शेयर कर सकते हैं.
  • किसी 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

अन्य संसाधन

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

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

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

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