हर Android ऐप्लिकेशन, सीमित ऐक्सेस वाले सैंडबॉक्स में चलता है. अगर आपके ऐप्लिकेशन को उसके सैंडबॉक्स के बाहर मौजूद संसाधनों या जानकारी के लिए, आपको रनटाइम का एलान करना होगा) अनुमति और अनुमति का अनुरोध सेट अप करें जिससे यह ऐक्सेस मिलता है. ये चरण, Google Analytics 4 पर माइग्रेट करने के वर्कफ़्लो का हिस्सा हैं अनुमतियां हैं.
अगर आपको अपने ऐप्लिकेशन में किसी खतरनाक चीज़ अनुमतियां और अगर आपका ऐप्लिकेशन, Android 6.0 (एपीआई लेवल 23) पर चलने वाले डिवाइस पर इंस्टॉल किया गया है या तो आपको रनटाइम के दौरान नुकसान पहुंचाने वाली अनुमतियों का अनुरोध करना होगा. इसके लिए, इस गाइड में दिए गए चरणों के बारे में जानें.
अगर आप किसी भी खतरनाक अनुमति के बारे में जानकारी नहीं देते या आपका ऐप्लिकेशन किसी जो डिवाइस Android 5.1 (एपीआई लेवल 22) या इससे पहले के वर्शन पर काम करते हैं उनके लिए ये अनुमतियां ज़रूरी हैं अपने-आप अनुमति मिल जाती है. साथ ही, आपको कोई भी बाकी चरण पूरा करने की ज़रूरत नहीं होती है इस पेज पर.
बुनियादी सिद्धांत
रनटाइम के दौरान अनुमतियों का अनुरोध करने के बुनियादी सिद्धांत यहां दिए गए हैं:
- जब उपयोगकर्ता, सुविधा देती हैं जिसे इसकी ज़रूरत है.
- उपयोगकर्ता को ब्लॉक न करें. शिक्षा से जुड़े यूज़र इंटरफ़ेस (यूआई) को हमेशा रद्द करने का विकल्प दें फ़्लो, जैसे कि एक ऐसा फ़्लो जो अनुमतियों के लिए अनुरोध करने की वजह बताता है.
- अगर उपयोगकर्ता, किसी सुविधा के लिए ज़रूरी अनुमति को अस्वीकार करता है या रद्द करता है, तो अपने ऐप्लिकेशन को डिग्रेड करना होगा, ताकि उपयोगकर्ता आपके ऐप्लिकेशन का इस्तेमाल जारी रख सकें. उस सुविधा को बंद कर दें जिसे अनुमति की ज़रूरत है.
- किसी सिस्टम व्यवहार को नहीं मानें. उदाहरण के लिए, यह न मानें कि अनुमतियां समान अनुमति ग्रुप में दिखते हैं. अनुमतियों का ग्रुप, सिर्फ़ आपकी मदद करता है सिस्टम डायलॉग की संख्या कम से कम कर देता है. उपयोगकर्ता को ये डायलॉग दिखाए जाते हैं जब कोई ऐप्लिकेशन काफ़ी हद तक मिलती-जुलती अनुमतियों का अनुरोध करता है.
अनुमतियों के अनुरोध के लिए वर्कफ़्लो
अपने ऐप्लिकेशन में रनटाइम की अनुमतियों का एलान करने और उनके लिए अनुरोध करने से पहले, समीक्षा करें कि आपके ऐप्लिकेशन को ऐसा करने की ज़रूरत है या नहीं. आप आपके ऐप्लिकेशन के इस्तेमाल के कई उदाहरणों को पूरा करता हो. जैसे, फ़ोटो लेना, मीडिया को रोकना बिना किसी विज्ञापन के, आपके कॉन्टेंट से जुड़े विज्ञापन दिखाता है. अनुमतियां दी हैं.
अगर इस बात की पुष्टि हो जाती है कि आपके ऐप्लिकेशन को रनटाइम की अनुमतियों का एलान करना होगा और इसके लिए अनुरोध करना होगा, तो इन चरणों को पूरा करें:
- अपने ऐप्लिकेशन की मेनिफ़ेस्ट फ़ाइल में, एलान करें अनुमतियां हैं, जिनकी ज़रूरत आपके ऐप्लिकेशन को पड़ सकती है अनुरोध.
- अपने ऐप्लिकेशन के उपयोगकर्ता अनुभव को इस तरह से डिज़ाइन करें कि आपके ऐप्लिकेशन में होने वाली खास कार्रवाइयां, रनटाइम की अनुमतियों की ज़रूरत होती है. उपयोगकर्ताओं को बताएं कि उन्हें कौनसी कार्रवाइयां करने की ज़रूरत पड़ सकती है ताकि आपके ऐप्लिकेशन को उपयोगकर्ता का निजी डेटा ऐक्सेस करने की अनुमति मिल सके.
- आपके ऐप्लिकेशन में टास्क या कार्रवाई शुरू करने के लिए, उपयोगकर्ता का इंतज़ार करें को ऐक्सेस करने के लिए, उपयोगकर्ता के कुछ निजी डेटा का ऐक्सेस ज़रूरी हो. इस समय आपका ऐप्लिकेशन ये काम कर सकता है: उस डेटा को ऐक्सेस करने के लिए ज़रूरी रनटाइम की अनुमति का अनुरोध करें.
जांचें कि उपयोगकर्ता ने रनटाइम पहले ही दिया है या नहीं की अनुमति देनी होगी, जो आपके ऐप्लिकेशन के लिए ज़रूरी है. अगर ऐसा है, तो आपका ऐप्लिकेशन उपयोगकर्ता का निजी डेटा हो सकता है. अगर ऐसा नहीं है, तो अगले चरण पर जाएं.
हर बार कार्रवाई करने पर, आपको यह देखना होगा कि आपके पास अनुमति है या नहीं चलाने के लिए अनुमति की ज़रूरत है.
देखें कि आपके ऐप्लिकेशन को इस्तेमाल करने की वजह दिखानी है या नहीं, इसमें बताया गया है कि आपके ऐप्लिकेशन के लिए लोगों को किसी खास रनटाइम की अनुमति की ज़रूरत क्यों है. अगर सिस्टम को लगता है कि आपके ऐप्लिकेशन में वजह नहीं बताई जानी चाहिए, तो बिना यूज़र इंटरफ़ेस (यूआई) एलिमेंट दिखाए बिना, सीधे अगले चरण पर जाएं.
अगर सिस्टम यह तय करता है कि आपके ऐप्लिकेशन में इसकी वजह बताई जानी चाहिए, तो उपयोगकर्ता को यूज़र इंटरफ़ेस (यूआई) एलिमेंट में बताई गई वजह बताएं. इस वजह में, यह साफ़ तौर पर बताएं कि आपका ऐप्लिकेशन किस डेटा को ऐक्सेस करने की कोशिश कर रहा है और उसके क्या फ़ायदे हैं अगर उपयोगकर्ता रनटाइम की अनुमति देता है, तो ऐप्लिकेशन उसे उपलब्ध करा सकता है. इस तारीख के बाद उपयोगकर्ता वजह स्वीकार कर लेता है और अगले चरण पर जाएं.
अपने ऐप्लिकेशन के लिए ज़रूरी रनटाइम की अनुमति का अनुरोध करें उपयोगकर्ता के निजी डेटा को ऐक्सेस करने के लिए. सिस्टम, रनटाइम दिखाता है अनुमति का प्रॉम्प्ट, जैसा कि अनुमतियों की खास जानकारी वाले पेज पर दिखता है पेज पर जाएं.
उपयोगकर्ता का जवाब देखें—चाहे वह रनटाइम की अनुमति का इस्तेमाल करें.
अगर उपयोगकर्ता ने आपके ऐप्लिकेशन को अनुमति दी है, तो आपके पास निजी ऐप्लिकेशन को उपयोगकर्ता डेटा. अगर उपयोगकर्ता ने इसके बजाय अनुमति नहीं दी है, तो शुक्रिया अंदाज़ में अपने ऐप्लिकेशन अनुभव, ताकि यह उपयोगकर्ता को फ़ंक्शन दे उसके लिए ज़रूरी है जो अनुमति देने के लिए सुरक्षित हो.
पहली इमेज में, इससे जुड़े वर्कफ़्लो और फ़ैसलों का सेट दिखाया गया है प्रक्रिया:
देखें कि आपके ऐप्लिकेशन को पहले से अनुमति दी गई थी या नहीं
यह देखने के लिए कि उपयोगकर्ता ने आपके ऐप्लिकेशन को पहले ही कोई खास अनुमति दी है या नहीं,
उस अनुमति को
ContextCompat.checkSelfPermission()
तरीका. इस तरीके से इनमें से कोई एक वैल्यू मिलती है
PERMISSION_GRANTED
या PERMISSION_DENIED
, यह इस बात पर निर्भर करता है कि आपके ऐप्लिकेशन को अनुमति है या नहीं.
बताएं कि आपके ऐप्लिकेशन को अनुमति की ज़रूरत क्यों है
कॉल करने के दौरान, सिस्टम आपको अनुमतियों वाला डायलॉग बॉक्स दिखाता है
requestPermissions()
ने बताया कि आपके ऐप्लिकेशन को कौनसी अनुमति चाहिए, लेकिन उसने कुछ नहीं बताया
क्यों. कुछ मामलों में, उपयोगकर्ता को उलझन हो सकती है. Google Merchant Center में
कॉल करने से पहले, उपयोगकर्ता को बताएं कि आपके ऐप्लिकेशन को अनुमतियां क्यों चाहिए
requestPermissions()
.
रिसर्च से पता चलता है कि अगर उपयोगकर्ता, अनुमतियों के अनुरोध पाना चाहते हैं, तो वे ज़्यादा सहज होते हैं उन्हें यह पता होता है कि ऐप्लिकेशन को उनकी ज़रूरत क्यों है. जैसे, वे यह जान पाते हैं कि ऐप्लिकेशन को जो ऐप्लिकेशन के मुख्य फ़ंक्शन या विज्ञापन के लिए ज़रूरी हो. इस वजह से, अगर आपको अनुमति ग्रुप के तहत आने वाले एपीआई कॉल के कुछ हिस्से का ही इस्तेमाल किया जा सकता है, इससे यह साफ़ तौर पर पता चलता है कि कौनसी अनुमतियों का इस्तेमाल किया जा रहा है और क्यों किया जा रहा है. इसके लिए उदाहरण के लिए, अगर सिर्फ़ अनुमानित जगह की जानकारी का इस्तेमाल किया जा रहा है, तो उपयोगकर्ता को अपने आपके ऐप्लिकेशन के बारे में जानकारी या सहायता लेखों में दी गई जानकारी शामिल होती है.
कुछ शर्तों के तहत, उपयोगकर्ताओं को रीयल टाइम में संवेदनशील जानकारी को ऐक्सेस करने की सुविधा मिलती है. उदाहरण के लिए, यदि आप नहीं बताया है, तो उपयोगकर्ता को सूचना आइकन पर क्लिक करें या सूचना ट्रे में (अगर बैकग्राउंड में चल रहा है), इसलिए ऐसा नहीं लगता कि आप चोरी-छिपे डेटा इकट्ठा करना.
आखिर में, अगर आपको अपने ऐप्लिकेशन में कुछ बनाने के लिए अनुमति का अनुरोध करने की ज़रूरत हो हालाँकि, उपयोगकर्ता को इसकी वजह साफ़ तौर पर नहीं बताई गई है. इसके अलावा, कोई ऐसा तरीका ढूँढें जिससे उपयोगकर्ता को यह जानें कि आपको सबसे संवेदनशील अनुमतियों की ज़रूरत क्यों है.
अगर ContextCompat.checkSelfPermission()
तरीका PERMISSION_DENIED
दिखाता है, तो
shouldShowRequestPermissionRationale()
को कॉल करें.
अगर इस तरीके से true
नतीजा मिलता है, तो उपयोगकर्ता को शिक्षा से जुड़ा यूज़र इंटरफ़ेस (यूआई) दिखाएं. इस यूज़र इंटरफ़ेस (यूआई) में,
बताएं कि उपयोगकर्ता जिस सुविधा को चालू करना चाहता है उसे
अनुमति.
अगर आपका ऐप्लिकेशन जगह की जानकारी, माइक्रोफ़ोन, तो यह बताएं कि आपको अपने ऐप्लिकेशन को आपके पास इस जानकारी का ऐक्सेस है.
अनुमतियां मांगें
उपयोगकर्ता के किसी शैक्षणिक यूज़र इंटरफ़ेस (यूआई) को देखने के बाद, या
shouldShowRequestPermissionRationale()
बताता है कि आपको उसे दिखाने की ज़रूरत नहीं है
एक शैक्षणिक यूज़र इंटरफ़ेस (यूआई) है, तो अनुमति के लिए अनुरोध करें. उपयोगकर्ताओं को सिस्टम दिखता है
अनुमति वाला डायलॉग बॉक्स, जहां वे यह चुन सकते हैं कि किसी खास अनुमति को
को अनुमति दें.
ऐसा करने के लिए, RequestPermission
का इस्तेमाल करें
कॉन्ट्रैक्ट, AndroidX लाइब्रेरी में शामिल होता है. इसमें सिस्टम को
आपके लिए अनुमति के अनुरोध का कोड भेजा जाएगा. क्योंकि
RequestPermission
कॉन्ट्रैक्ट का इस्तेमाल करने से, आपका लॉजिक आसान हो जाता है. इसलिए, हमारा सुझाव है कि
समाधान की जानकारी मिलती है. हालांकि, अगर ज़रूरी हो, तो आपके पास अनुरोध कोड को मैनेज करने का विकल्प भी है
खुद और
इस अनुरोध कोड को अपने अनुमति कॉलबैक लॉजिक में शामिल करें.
सिस्टम को अनुमति अनुरोध कोड मैनेज करने की अनुमति दें
सिस्टम को उस अनुरोध कोड को मैनेज करने की अनुमति देने के लिए जो
अनुमतियां मांगने का अनुरोध किया है, तो अपने यहां दी गई लाइब्रेरी पर निर्भरताएं जोड़ें
मॉड्यूल की build.gradle
फ़ाइल:
androidx.activity
, 1.2.0 या उसके बाद का वर्शनandroidx.fragment
, 1.3.0 या उसके बाद का वर्शन
इसके बाद, इनमें से किसी एक क्लास का इस्तेमाल करें:
- एक बार अनुमति का अनुरोध करने के लिए, इसका इस्तेमाल करें
RequestPermission
. - एक ही समय में कई अनुमतियों का अनुरोध करने के लिए, इसका इस्तेमाल करें
RequestMultiplePermissions
.
यहां दिए गए तरीके से, RequestPermission
को इस्तेमाल करने का तरीका पता चलता है. कॉन्टेंट बनाने
RequestMultiplePermissions
के समझौते के लिए भी प्रोसेस करीब-करीब एक जैसी ही है.
अपनी ऐक्टिविटी या फ़्रैगमेंट के इनिशलाइज़ेशन लॉजिक में, लागू करने की प्रक्रिया पास करें
ActivityResultCallback
में से CANNOT TRANSLATEregisterForActivityResult()
.ActivityResultCallback
से तय होता है कि आपका ऐप्लिकेशन, किसी व्यक्ति के दिए गए जवाब को कैसे मैनेज करता है अनुमति अनुरोध.registerForActivityResult()
की रिटर्न वैल्यू का रेफ़रंस रखें, जो इसका प्रकार हैActivityResultLauncher
.आवश्यक होने पर सिस्टम अनुमतियां डायलॉग दिखाने के लिए,
launch()
ActivityResultLauncher
के इंस्टेंस पर तरीका जिसे आपने इसमें सेव किया है पिछला चरण.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
में से, जैसा कि नीचे दिए गए कोड स्निपेट में दिखाया गया है. पुराने वर्शन पर इसलिए, हमारा सुझाव है कि आप फ़ोरग्राउंड सेवा के इस टाइप का एलान करें.<!-- 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_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>
बैकग्राउंड में जगह की जानकारी ऐक्सेस करने की सुविधा
अगर ऐप्लिकेशन में मौजूद कोई सुविधा है, तो उसे बैकग्राउंड में जगह की जानकारी ऐक्सेस करने की अनुमति चाहिए अन्य उपयोगकर्ताओं के साथ लगातार स्थान शेयर करता है या जियोफ़ेंसिंग एपीआई. कई उदाहरणों में ये शामिल हैं:
- फ़ैमिली ग्रुप के सदस्यों के साथ जगह की जानकारी शेयर करने वाले ऐप्लिकेशन में, एक सुविधा से उपयोगकर्ता लगातार परिवार के सदस्यों के साथ जगह की जानकारी शेयर कर सकती हैं.
- 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 ऐप्लिकेशन की अनुमतियों की पूरी सूची देखने के लिए, अनुमतियां एपीआई पर जाएं रेफ़रंस पेज पर जाएं.
एक बार के लिए दी जाने वाली अनुमतियां
यह सुविधा, 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
अन्य संसाधन
अनुमतियों के बारे में ज़्यादा जानकारी के लिए, ये लेख पढ़ें:
अनुमतियों का अनुरोध करने के बारे में ज़्यादा जानने के लिए, यहां जाएं: अनुमतियों के सैंपल
निजता की बेहतर तरीके से सुरक्षा करने वाले कोडलैब का इस्तेमाल भी किया जा सकता है तरीके शामिल करें.