Android 11 में, उपयोगकर्ताओं को जगह की जानकारी, माइक्रोफ़ोन, और कैमरे के लिए ज़्यादा बारीक अनुमतियां तय करने की सुविधा मिलती है. इसके अलावा, सिस्टम उन ऐप्लिकेशन की अनुमतियों को रीसेट कर देता है जिन्हें इस्तेमाल नहीं किया जा रहा है और जो Android 11 या उसके बाद के वर्शन को टारगेट करते हैं. साथ ही, अगर ऐप्लिकेशन में सिस्टम सूचना विंडो का इस्तेमाल किया जाता है या फ़ोन नंबर से जुड़ी जानकारी पढ़ी जाती है, तो हो सकता है कि ऐप्लिकेशन को उन अनुमतियों को अपडेट करना पड़े जिनका एलान किया गया है.
एक बार के लिए अनुमतियां
Android 11 से, जब भी आपका ऐप्लिकेशन जगह की जानकारी, माइक्रोफ़ोन या कैमरे से जुड़ी अनुमति का अनुरोध करता है, तो उपयोगकर्ता को दिखने वाले अनुमति डायलॉग में सिर्फ़ इस बार नाम का एक विकल्प दिखता है. अगर उपयोगकर्ता डायलॉग बॉक्स में यह विकल्प चुनता है, तो आपके ऐप्लिकेशन को कुछ समय के लिए एक बार इस्तेमाल करने की अनुमति मिलती है.
इस बारे में ज़्यादा जानें कि सिस्टम, सिर्फ़ एक बार इस्तेमाल की जाने वाली अनुमतियों को कैसे मैनेज करता है.
इस्तेमाल नहीं किए जा रहे ऐप्लिकेशन से अनुमतियां अपने-आप रीसेट होने की सुविधा
अगर आपका ऐप्लिकेशन Android 11 या उसके बाद के वर्शन को टारगेट करता है और उसका इस्तेमाल कुछ महीनों से नहीं किया गया है, तो सिस्टम उपयोगकर्ता के डेटा की सुरक्षा करता है. इसके लिए, वह रनटाइम के दौरान ऐक्सेस की गई संवेदनशील अनुमतियों को अपने-आप रीसेट कर देता है. इस कार्रवाई का वही असर होता है जो उपयोगकर्ता के सिस्टम सेटिंग में जाकर, ऐप्लिकेशन के ऐक्सेस लेवल को अस्वीकार करें पर सेट करने पर होता है. अगर आपका ऐप्लिकेशन, रनटाइम के दौरान अनुमतियों का अनुरोध करने के सबसे सही तरीकों का पालन करता है, तो आपको अपने ऐप्लिकेशन में कोई बदलाव करने की ज़रूरत नहीं है. ऐसा इसलिए, क्योंकि जब उपयोगकर्ता आपके ऐप्लिकेशन की सुविधाओं के साथ इंटरैक्ट करता है, तो आपको यह पुष्टि करनी चाहिए कि उन सुविधाओं के पास ज़रूरी अनुमतियां हों.
इस बारे में ज़्यादा जानें कि सिस्टम, इस्तेमाल न किए गए ऐप्लिकेशन की अनुमतियों को अपने-आप कैसे रीसेट करता है.
अनुमति वाला डायलॉग बॉक्स दिखना
Android 11 से, अगर उपयोगकर्ता किसी डिवाइस पर आपके ऐप्लिकेशन के इंस्टॉल होने के दौरान, किसी खास अनुमति के लिए एक से ज़्यादा बार अस्वीकार करें पर टैप करता है, तो आपका ऐप्लिकेशन उस अनुमति का फिर से अनुरोध करने पर, उपयोगकर्ता को सिस्टम की अनुमतियों वाला डायलॉग नहीं दिखता. उपयोगकर्ता की कार्रवाई से पता चलता है कि "दोबारा न पूछें". पिछले वर्शन में, जब भी आपका ऐप्लिकेशन किसी अनुमति का अनुरोध करता था, तब उपयोगकर्ताओं को सिस्टम की अनुमतियों वाला डायलॉग दिखता था. ऐसा तब तक होता था, जब तक उपयोगकर्ता ने पहले से "फिर से न पूछें" चेकबॉक्स या विकल्प नहीं चुना होता. Android 11 में इस बदलाव की वजह से, उन अनुमतियों के लिए बार-बार अनुरोध नहीं किए जा सकेंगे जिन्हें उपयोगकर्ताओं ने अस्वीकार कर दिया है.
यह पता लगाने के लिए कि किसी ऐप्लिकेशन को अनुमतियां हमेशा के लिए दी गई हैं या नहीं (डीबग करने और जांच करने के लिए), नीचे दिए गए निर्देश का इस्तेमाल करें:
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 में, ऐप्लिकेशन को SYSTEM_ALERT_WINDOW
अनुमति देने के तरीके में कई बदलाव किए गए हैं. इन बदलावों का मकसद, अनुमति देने के लिए उपयोगकर्ताओं को ज़्यादा सोच-समझकर फ़ैसला लेने के लिए कहना है. इससे उपयोगकर्ताओं को सुरक्षित रखा जा सकेगा.
कुछ ऐप्लिकेशन को अनुरोध करने पर, SYSTEM_ALERT_WINDOW की अनुमति अपने-आप मिल जाती है
कुछ खास तरह के ऐप्लिकेशन को अनुरोध करने पर, SYSTEM_ALERT_WINDOW
अनुमति अपने-आप मिल जाती है:
जिस ऐप्लिकेशन में
ROLE_CALL_SCREENING
औरSYSTEM_ALERT_WINDOW
का अनुरोध है उसे अनुमति अपने-आप मिल जाती है. अगर ऐप्लिकेशन के पासROLE_CALL_SCREENING
नहीं है, तो वह अनुमति नहीं दे सकता.अगर कोई ऐप्लिकेशन
MediaProjection
के ज़रिए स्क्रीन कैप्चर कर रहा है औरSYSTEM_ALERT_WINDOW
का अनुरोध करता है, तो उसे अनुमति अपने-आप मिल जाती है. ऐसा तब तक होता है, जब तक उपयोगकर्ता ने ऐप्लिकेशन को अनुमति देने से साफ़ तौर पर इनकार नहीं कर दिया है. जब ऐप्लिकेशन स्क्रीन कैप्चर करना बंद कर देता है, तो उसे अनुमति नहीं मिलती. इस उदाहरण का मकसद, मुख्य रूप से गेम की लाइव स्ट्रीमिंग करने वाले ऐप्लिकेशन के लिए है.
इन ऐप्लिकेशन को SYSTEM_ALERT_WINDOW
की अनुमति पाने के लिए, ACTION_MANAGE_OVERLAY_PERMISSION
भेजने की ज़रूरत नहीं है. ये ऐप्लिकेशन सीधे तौर पर SYSTEM_ALERT_WINDOW
का अनुरोध कर सकते हैं.
MANAGE_OVERLAY_PERMISSION इंटेंट, उपयोगकर्ता को हमेशा सिस्टम की अनुमतियों की स्क्रीन पर ले जाते हैं
Android 11 से, ACTION_MANAGE_OVERLAY_PERMISSION
इंटेंट हमेशा उपयोगकर्ता को टॉप-लेवल की सेटिंग स्क्रीन पर ले जाते हैं. यहां उपयोगकर्ता, ऐप्लिकेशन के लिए SYSTEM_ALERT_WINDOW
अनुमतियां दे सकता है या उन्हें रद्द कर सकता है. इंटेंट में मौजूद किसी भी package:
डेटा को अनदेखा किया जाता है.
Android के पुराने वर्शन में, ACTION_MANAGE_OVERLAY_PERMISSION
इंटेंट के ज़रिए किसी पैकेज के बारे में बताया जा सकता था. इससे उपयोगकर्ता को अनुमति मैनेज करने के लिए, ऐप्लिकेशन की खास स्क्रीन पर ले जाया जाता था. Android 11 में यह सुविधा काम नहीं करती. इसके बजाय, उपयोगकर्ता को पहले वह ऐप्लिकेशन चुनना होगा जिसके लिए उसे अनुमति देनी है या जिससे अनुमति वापस लेनी है. इस बदलाव का मकसद, उपयोगकर्ताओं को ज़्यादा सुरक्षित अनुभव देना है. इसके लिए, अनुमति देने की प्रोसेस को ज़्यादा बेहतर बनाया गया है.
फ़ोन नंबर
Android 11, फ़ोन से जुड़ी उस अनुमति में बदलाव करता है जिसका इस्तेमाल आपका ऐप्लिकेशन, फ़ोन नंबर पढ़ते समय करता है.
अगर आपका ऐप्लिकेशन Android 11 या उसके बाद के वर्शन को टारगेट करता है और उसे यहां दी गई सूची में दिए गए फ़ोन नंबर के एपीआई ऐक्सेस करने हैं, तो आपको READ_PHONE_STATE
अनुमति के बजाय READ_PHONE_NUMBERS
अनुमति का अनुरोध करना होगा.
TelephonyManager
औरTelecomManager
, दोनों क्लास मेंgetLine1Number()
मेथड.TelephonyManager
क्लास में,getMsisdn()
का वह तरीका जो काम नहीं करता.
अगर आपका ऐप्लिकेशन, पिछली सूची में मौजूद तरीकों के अलावा किसी दूसरे तरीके को कॉल करने के लिए READ_PHONE_STATE
का एलान करता है, तो Android के सभी वर्शन के लिए READ_PHONE_STATE
का अनुरोध किया जा सकता है. अगर READ_PHONE_STATE
अनुमति का इस्तेमाल सिर्फ़ पिछली सूची में दिए गए तरीकों के लिए किया जाता है, तो अपनी मेनिफ़ेस्ट फ़ाइल को इस तरह अपडेट करें:
READ_PHONE_STATE
के एलान में बदलाव करें, ताकि आपका ऐप्लिकेशन सिर्फ़ Android 10 (एपीआई लेवल 29) और उससे पहले के वर्शन पर अनुमति का इस्तेमाल कर सके.READ_PHONE_NUMBERS
अनुमति जोड़ें.
मेनिफ़ेस्ट में एलान करने के लिए इस्तेमाल होने वाले इस स्निपेट से, इस प्रोसेस के बारे में पता चलता है:
<manifest> <!-- Grants the READ_PHONE_STATE permission only on devices that run Android 10 (API level 29) and lower. --> <uses-permission android:name="android.permission.READ_PHONE_STATE" android:maxSdkVersion="29" /> <uses-permission android:name="android.permission.READ_PHONE_NUMBERS" /> </manifest>
अन्य संसाधन
Android 11 में अनुमतियों में हुए बदलावों के बारे में ज़्यादा जानने के लिए, यहां दिए गए लेख पढ़ें:
वीडियो
Android 11 में निजता से जुड़े नए बदलावों के साथ ऐप्लिकेशन बनाना