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 में निजता से जुड़े नए बदलावों के साथ ऐप्लिकेशन बनाना