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()
मेथड काम नहीं करता.
अगर आपका ऐप्लिकेशन, पिछली सूची में शामिल तरीकों के अलावा अन्य तरीकों से कॉल करने का एलान करता है, तो सभी Android वर्शन पर READ_PHONE_STATE
का अनुरोध किया जा सकता है.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 में निजता से जुड़े नए बदलावों के साथ डेवलपमेंट करना