Google आपकी पसंदीदा भाषा में कॉन्टेंट का अनुवाद करने के लिए, एआई टेक्नोलॉजी का इस्तेमाल करता है. एआई से मिले अनुवादों में गलतियां हो सकती हैं.

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

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

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

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

सामान्य बातें

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

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

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

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

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

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

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

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

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

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

इस फ़्लोचार्ट में, रनटाइम की अनुमतियों का अनुरोध करने के लिए फ़ैसले लेने की प्रोसेस को दिखाया गया है. इसकी शुरुआत ऐप्लिकेशन की कार्रवाई से होती है. इसके बाद, यह जांच की जाती है कि अनुमति दी गई है या नहीं. फिर यह जांच की जाती है कि अनुमति मांगने की वजह बताने की ज़रूरत है या नहीं. इसके बाद, अनुमति का अनुरोध किया जाता है और उपयोगकर्ता के जवाब को मैनेज किया जाता है. — **पहली इमेज.** 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 के अनुबंध के लिए भी प्रोसेस करीब-करीब ऐसी ही है.

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

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

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

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

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

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

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

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

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() को किए जाने वाले कॉल में अनुरोध कोड शामिल करें.

ध्यान दें: 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 के पुराने वर्शन पर, हमारा सुझाव है कि आप फ़ोरग्राउंड सेवा के इस टाइप का एलान करें.
```


<service
    android:name="MyNavigationService"
    android:foregroundServiceType="location" ... >
    
</service>
```

जब आपका ऐप्लिकेशन ACCESS_COARSE_LOCATION या ACCESS_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>

बैकग्राउंड में लोकेशन ऐक्सेस करना

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

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

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

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

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

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

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

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

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 ऐप्लिकेशन की अनुमतियों की पूरी सूची देखने के लिए, अनुमतियों के एपीआई के रेफ़रंस पेज पर जाएं.

एक बार के लिए अनुमतियां

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

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

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

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

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

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

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

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

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

यह एक ऐसा एपीआई है जहां से, इस्तेमाल न की गई रनटाइम की अनुमति के लिए, अपने ऐप्लिकेशन का ऐक्सेस हटाया जा सकता है.
सिस्टम का एक ऐसा तरीका जो इस्तेमाल न किए जाने वाले ऐप्लिकेशन की अनुमतियों को अपने-आप रीसेट कर देता है.

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

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

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

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

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

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

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

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

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

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

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

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

adb shell install -g PATH_TO_APK_FILE

अन्य संसाधन

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

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

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

पीछे जाएं

ऐप्लिकेशन अनुमतियों का एलान करना

आगे बढ़ें

विशेष अनुमतियों का अनुरोध करें