रनटाइम अनुमतियाँ

एंड्रॉइड 6.0 और उच्चतर में, एंड्रॉइड एप्लिकेशन अनुमति मॉडल को उपयोगकर्ताओं के लिए अनुमतियों को अधिक समझने योग्य, उपयोगी और सुरक्षित बनाने के लिए डिज़ाइन किया गया है। मॉडल ने उन Android एप्लिकेशन को स्थानांतरित कर दिया जिन्हें खतरनाक अनुमतियों की आवश्यकता होती है (देखें प्रभावित अनुमतियां ) इंस्टॉल-टाइम अनुमति मॉडल से रनटाइम अनुमति मॉडल में:

• इंस्टाल-टाइम अनुमतियाँ

  ( एंड्रॉइड 5.1 और उससे पहले के वर्शन) उपयोगकर्ता ऐप को इंस्टॉल या अपडेट करते समय किसी ऐप को खतरनाक अनुमतियां देते हैं। डिवाइस निर्माता और वाहक उपयोगकर्ता को सूचित किए बिना पूर्व-अनुमति वाले ऐप्स को प्रीइंस्टॉल कर सकते हैं।

• रनटाइम अनुमतियाँ

  ( एंड्रॉइड 6.0 - 9 ) जब ऐप चल रहा हो तो उपयोगकर्ता किसी ऐप को खतरनाक अनुमतियां देते हैं। जब अनुमतियों का अनुरोध किया जाता है (जैसे कि जब ऐप लॉन्च होता है या जब उपयोगकर्ता किसी विशिष्ट सुविधा का उपयोग करता है) तो एप्लिकेशन पर निर्भर करता है, लेकिन उपयोगकर्ता विशिष्ट अनुमति समूहों के लिए एप्लिकेशन एक्सेस को अनुदान/अस्वीकार करता है। ओईएम/वाहक ऐप्स को प्री-इंस्टॉल कर सकते हैं, लेकिन जब तक वे अपवाद प्रक्रिया से नहीं गुजरते तब तक अनुमति नहीं दे सकते। ( अपवाद बनाना देखें।)

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

रनटाइम अनुमतियां ऐप्स को उपयोगकर्ता की सहमति के बिना निजी डेटा तक पहुंच प्राप्त करने से रोकती हैं, और उन्हें उन अनुमतियों के प्रकारों में अतिरिक्त संदर्भ और दृश्यता प्रदान करती हैं जो एप्लिकेशन या तो मांग रहे हैं, या दी गई हैं। रनटाइम मॉडल डेवलपर्स को उपयोगकर्ताओं को यह समझने में मदद करने के लिए प्रोत्साहित करता है कि एप्लिकेशन को अनुरोधित अनुमतियों की आवश्यकता क्यों है, और अधिक पारदर्शिता प्रदान करता है ताकि उपयोगकर्ता उन्हें देने या अस्वीकार करने के बारे में बेहतर निर्णय ले सकें।

प्रभावित अनुमतियाँ

एंड्रॉइड 6.0 और उच्चतर को रनटाइम अनुमति मॉडल का उपयोग करने के लिए खतरनाक अनुमतियों की आवश्यकता होती है। खतरनाक अनुमतियां उच्च जोखिम वाली अनुमतियां हैं (जैसे कि READ_CALENDAR ) जो अनुरोध करने वाले एप्लिकेशन को निजी उपयोगकर्ता डेटा तक पहुंच प्रदान करती हैं, या किसी डिवाइस पर नियंत्रण करती हैं, जो उपयोगकर्ता को नकारात्मक रूप से प्रभावित कर सकती हैं। खतरनाक अनुमतियों की सूची देखने के लिए, कमांड चलाएँ:

adb shell pm list permissions -g -d

Android 6.0 और उच्चतर सामान्य अनुमतियों के व्यवहार को नहीं बदलते हैं। ये सभी गैर-खतरनाक अनुमतियां हैं जिनमें सामान्य, सिस्टम और हस्ताक्षर अनुमतियां शामिल हैं। सामान्य अनुमतियां कम जोखिम वाली अनुमतियां हैं (जैसे कि SET_WALLPAPER ) जो अनुरोध करने वाले एप्लिकेशन को अन्य एप्लिकेशन, सिस्टम या उपयोगकर्ता के लिए न्यूनतम जोखिम के साथ अलग-अलग एप्लिकेशन-स्तरीय सुविधाओं तक पहुंच प्रदान करती हैं। जैसा कि एंड्रॉइड 5.1 और निचले रिलीज में, सिस्टम स्वचालित रूप से इंस्टॉलेशन के अनुरोध करने वाले एप्लिकेशन को सामान्य अनुमति देता है और उपयोगकर्ता को अनुमोदन के लिए संकेत नहीं देता है। अनुमतियों के विवरण के लिए, <अनुमति> तत्व दस्तावेज़ीकरण देखें।

Android 10 . में हार्ड और सॉफ्ट प्रतिबंध

खतरनाक होने के अलावा, अनुमति या तो कठोर-प्रतिबंधित या नरम-प्रतिबंधित हो सकती है। किसी भी मामले में, प्रतिबंधित अनुमति को भी सूचीबद्ध किया जाना चाहिए। गैर-अनुमत सूचीबद्ध कठोर प्रतिबंध गैर-अनुमत सूचीबद्ध सॉफ्ट प्रतिबंधों से अलग व्यवहार करते हैं:

• ( कठिन प्रतिबंध ) ऐप्स को अनुमति नहीं दी जा सकती जो सूचीबद्ध नहीं हैं।
• ( सॉफ्ट प्रतिबंध ) बिना अनुमति के ऐप्स उनके द्वारा अनुरोधित विशिष्ट अनुमति के अनुसार व्यवहार करते हैं। अनुरोधित अनुमति के लिए सार्वजनिक दस्तावेज़ीकरण में व्यवहार का वर्णन किया गया है।

ऐप इंस्टॉल करते समय, इंस्टॉलर (जैसे कि Google Play Store) ऐप के लिए प्रतिबंधित अनुमतियों को सूचीबद्ध नहीं करने का चयन कर सकता है। अनुमतियाँ प्लेटफ़ॉर्म द्वारा प्रतिबंधित हैं और केवल तभी दी जा सकती हैं जब कोई ऐप प्रति प्लेटफ़ॉर्म नीति के विशेष मानदंडों को पूरा करता हो। कठोर-प्रतिबंधित अनुमति प्रकारों के उदाहरणों में एसएमएस और कॉल लॉग अनुमतियां शामिल हैं।

स्थापना के दौरान, और कब

• एंड्रॉइड 9-टू-10 अपग्रेड के दौरान एक ऐप पहले से इंस्टॉल है।
• अनुमति पहले से दी गई है या ऐप पहले से इंस्टॉल है।
• एक भूमिका के लिए अनुमति की आवश्यकता होती है जो अनुमति को अनुमति देने के लिए पहले से ही परिभाषित है।
• इंस्टॉलर (जैसे Google Play Store) अनुमति को सूचीबद्ध के रूप में चिह्नित करता है।

उपयोगकर्ता मैन्युअल रूप से सूची अनुमतियों की अनुमति नहीं दे सकते।

आवश्यकताएं

रनटाइम अनुमति मॉडल सभी एप्लिकेशन पर लागू होता है, जिसमें पहले से इंस्टॉल किए गए ऐप्स और सेटअप प्रक्रिया के हिस्से के रूप में डिवाइस पर डिलीवर किए गए ऐप्स शामिल हैं। एप्लिकेशन सॉफ़्टवेयर आवश्यकताओं में शामिल हैं:

• रनटाइम अनुमति मॉडल Android 6.0 और उच्चतर पर चलने वाले सभी उपकरणों में एक जैसा होना चाहिए। यह Android संगतता परीक्षण सूट (CTS) परीक्षणों द्वारा लागू किया गया है।
• ऐप्स को उपयोगकर्ताओं को रनटाइम पर एप्लिकेशन अनुमतियां देने के लिए संकेत देना चाहिए। विवरण के लिए, एप्लिकेशन अपडेट करना देखें। डिफ़ॉल्ट एप्लिकेशन और हैंडलर को सीमित अपवाद दिए जा सकते हैं जो डिवाइस के अपेक्षित संचालन के लिए मूलभूत डिवाइस कार्यक्षमता प्रदान करते हैं। (उदाहरण के लिए, ACTION_CALL को संभालने के लिए डिवाइस के डिफ़ॉल्ट डायलर ऐप में फ़ोन अनुमति एक्सेस हो सकती है।) विवरण के लिए, अपवाद बनाना देखें।
• खतरनाक अनुमतियों वाले प्रीलोडेड ऐप्स को एपीआई स्तर 23 को लक्षित करना चाहिए और रनटाइम अनुमति मॉडल को बनाए रखना चाहिए। यानी, ऐप इंस्टॉलेशन के दौरान UI प्रवाह PermissionController के AOSP कार्यान्वयन से विचलित नहीं होना चाहिए, उपयोगकर्ता पहले से इंस्टॉल किए गए ऐप्स की खतरनाक अनुमतियों को रद्द कर सकते हैं, और इसी तरह।
• हेडलेस एप्लिकेशन को अनुमतियों का अनुरोध करने के लिए या किसी अन्य एप्लिकेशन के साथ यूआईडी साझा करने के लिए एक गतिविधि का उपयोग करना चाहिए जिसमें आवश्यक अनुमतियां हों। विवरण के लिए, हेडलेस एप्लिकेशन देखें।

अनुमतियाँ माइग्रेशन

एंड्रॉइड 5.x पर एप्लिकेशन को दी गई अनुमतियां एंड्रॉइड 6.0 या उच्चतर पर अपडेट करने के बाद दी जाती हैं, लेकिन उपयोगकर्ता किसी भी समय उन अनुमतियों को रद्द कर सकते हैं।

एंड्रॉइड 9-टू -10 अपडेट में, सभी हार्ड-प्रतिबंधित अनुमतियां सूचीबद्ध हो जाती हैं। अग्रभूमि/पृष्ठभूमि विभाजन अनुमतियों को लागू करने के विवरण के लिए, Android 10 गोपनीयता परिवर्तन देखें, जिसकी शुरुआत अनुरोध पृष्ठभूमि स्थान से होती है।

एकीकरण

एंड्रॉइड 6.0 और उच्चतर के लिए एप्लिकेशन रनटाइम अनुमति मॉडल को एकीकृत करते समय, आपको नए मॉडल के साथ काम करने के लिए पहले से इंस्टॉल किए गए एप्लिकेशन को अपडेट करना होगा। आप उन ऐप्स के लिए अपवादों को भी परिभाषित कर सकते हैं जो मुख्य कार्यक्षमता के लिए डिफ़ॉल्ट हैंडलर/प्रदाता हैं, कस्टम अनुमतियों को परिभाषित करते हैं, और PermissionController ऐप में उपयोग की जाने वाली थीम को अनुकूलित करते हैं।

एप्लिकेशन अपडेट करना

सिस्टम छवि पर एप्लिकेशन और पहले से इंस्टॉल किए गए एप्लिकेशन स्वचालित रूप से पूर्व-अनुमत अनुमतियां नहीं हैं। डेवलपर दिशानिर्देशों का उपयोग करके आवश्यक ऐप संशोधन करने के लिए हम आपको पहले से इंस्टॉल किए गए ऐप डेवलपर्स (OEM, कैरियर और तृतीय पक्ष) के साथ काम करने के लिए प्रोत्साहित करते हैं। विशेष रूप से, आपको यह सुनिश्चित करना होगा कि जब उपयोगकर्ता अनुमतियां रद्द करते हैं तो क्रैश और अन्य समस्याओं से बचने के लिए प्रीइंस्टॉल्ड एप्लिकेशन को संशोधित किया जाता है।

प्री-लोडेड एप्लिकेशन

Android 9 और उसके बाद के संस्करण में, खतरनाक अनुमतियों का उपयोग करने वाले पहले से लोड किए गए ऐप्स को API स्तर 23 या उच्चतर को लक्षित करना चाहिए, और Android 6.0 और उच्चतर AOSP अनुमति मॉडल को बनाए रखना चाहिए। उदाहरण के लिए, ऐप इंस्टॉलेशन के दौरान UI प्रवाह PermissionController के AOSP कार्यान्वयन से विचलित नहीं होना चाहिए। उपयोगकर्ता पहले से इंस्टॉल किए गए ऐप्स की खतरनाक अनुमतियों को रद्द भी कर सकते हैं।

एंड्रॉइड 6.0 से 9 में, इंस्टॉल फ्लो के दौरान कुछ अनुमतियां दी जाती हैं। हालांकि, 10 से शुरू होकर, इंस्टॉल फ्लो ( Package Installer ऐप द्वारा निष्पादित) अनुमति देने से एक अलग कार्य है ( Permission Controller ऐप में)।

हेडलेस एप्लिकेशन

केवल गतिविधियां ही अनुमति का अनुरोध कर सकती हैं। सेवाएँ सीधे अनुमतियों का अनुरोध नहीं कर सकतीं।

• एंड्रॉइड 5.1 और इससे पहले के संस्करण में, हेडलेस एप्लिकेशन इंस्टॉल होने पर अनुमतियों का अनुरोध कर सकते हैं, या यदि वे किसी गतिविधि के उपयोग के बिना पहले से इंस्टॉल किए गए थे।
• एंड्रॉइड 6.0 और उच्चतर में, हेडलेस एप्लिकेशन को अनुमतियों का अनुरोध करने के लिए निम्न विधियों में से एक का उपयोग करना चाहिए:
• अनुमतियों का अनुरोध करने के लिए एक गतिविधि जोड़ें। (यह पसंदीदा तरीका है।)
• यूआईडी को किसी अन्य एप्लिकेशन के साथ साझा करें जिसमें आवश्यक अनुमतियां हों। इस पद्धति का उपयोग केवल तभी करें जब आपको एक ही एप्लिकेशन के रूप में कई एपीके को संभालने के लिए प्लेटफॉर्म की आवश्यकता हो।

इसका लक्ष्य उपयोगकर्ताओं को उन अनुमति अनुरोधों के साथ भ्रमित करने से बचना है जो संदर्भ से बाहर हैं।

PackageInstaller UI को अनुकूलित करना

यदि वांछित है, तो आप PackageInstaller द्वारा उपयोग की जाने वाली डिफ़ॉल्ट डिवाइस थीम ( Theme.DeviceDefault.Settings and Theme.DeviceDefault.Light.Dialog.NoActionBar ) को अपडेट करके अनुमतियाँ UI थीम को अनुकूलित कर सकते हैं। हालांकि, चूंकि ऐप डेवलपर के लिए एकरूपता महत्वपूर्ण है, इसलिए आप अनुमतियां UI के प्रकट होने के समय, प्लेसमेंट, स्थिति और नियमों को कस्टमाइज़ नहीं कर सकते हैं।

अतिरिक्त भाषाओं के लिए स्ट्रिंग्स शामिल करने के लिए, स्ट्रिंग्स को AOSP में योगदान करें।

अपवाद बनाना

आप पैकेजमैनेजर में DefaultPermissionGrantPolicy.java क्लास का उपयोग करके उन अनुप्रयोगों को अनुमतियां पूर्व-अनुमति दे सकते हैं जो डिफ़ॉल्ट हैंडलर या कोर OS कार्यक्षमता के लिए प्रदाता हैं। उदाहरण:

ACTION_CALL (Dialer) Default
Phone, Contacts, SMS, Microphone

SMS_DELIVER_ACTION (SMS/MMS) Default
Phone, Contacts, SMS

कस्टम अनुमतियों को परिभाषित करना

आप कस्टम अनुमतियों और समूहों को सामान्य या खतरनाक के रूप में परिभाषित कर सकते हैं और मौजूदा अनुमति समूहों में OEM/वाहक-विशिष्ट अनुमतियां जोड़ सकते हैं, जैसा कि आप Android 5.x और पहले के रिलीज़ में कर सकते थे।

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

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

परीक्षण अनुमतियाँ

एंड्रॉइड में संगतता परीक्षण सूट (सीटीएस) परीक्षण शामिल हैं जो सत्यापित करते हैं कि व्यक्तिगत अनुमतियों को सही समूहों में मैप किया गया है। इन परीक्षणों को पास करना Android 6.0 और बाद के CTS संगतता के लिए एक आवश्यकता है।

अनुमतियाँ निरस्त करना

Android 13 और बाद के संस्करणों में, आप Context.revokeSelfPermissionsOnKill() का उपयोग करके अपनी स्वयं की दी गई रनटाइम अनुमतियों को रद्द करने में सक्षम हैं। निरसन अतुल्यकालिक रूप से होता है और तब ट्रिगर होता है जब उपयोगकर्ता को बाधित किए बिना ऐसा करना सुरक्षित होता है। जब निरसन ट्रिगर होता है, तो कॉलिंग यूआईडी में चलने वाली सभी प्रक्रियाएं समाप्त हो जाएंगी।

यह समझना महत्वपूर्ण है कि एकल अनुमति को रद्द करना सेटिंग UI में प्रतिबिंबित नहीं हो सकता है, जो समूह द्वारा अनुमतियों को मानता है। आम तौर पर, एक अनुमति समूह तब तक प्रदर्शित किया जाएगा जब तक कि उस समूह में कम से कम एक अनुमति दी जाती है। यदि यह सुनिश्चित करना कि उपयोगकर्ता सेटिंग में निरसन की पुष्टि करने में सक्षम हैं, आपके लिए महत्वपूर्ण है, तो अनुमति समूह में प्रत्येक अनुमति को निरस्त करना सुनिश्चित करें। यह जानने के लिए कि कौन सी अनुमतियाँ एक निश्चित समूह से संबंधित हैं, आप PackageManager.getGroupOfPlatformPermission और PackageManager.getPlatformPermissionsForGroup का उपयोग कर सकते हैं।

जब सिस्टम अनुरोधित अनुमतियों को रद्द कर देता है, तो यह संबंधित पृष्ठभूमि अनुमतियों को भी रद्द कर देता है यदि उनकी कोई भी संबंधित अग्रभूमि अनुमति अभी भी प्रदान नहीं की जाती है।

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

एक अनुमति निरसन प्रभावी होने के बाद, आप इसे फिर से अनुरोध करने में सक्षम हैं, और उपयोगकर्ता को अनुरोध देने या अस्वीकार करने के लिए प्रेरित किया जाएगा। उस अनुमति का अनुरोध करना संभव नहीं है जिसे पहले उपयोगकर्ता द्वारा अस्वीकार कर दिया गया था। जबकि आपको उन अनुमतियों को रद्द करने के लिए प्रोत्साहित किया जाता है जो आपके पास वर्तमान में हैं लेकिन अब इसकी आवश्यकता नहीं है, आपको सावधान रहना चाहिए कि जब तक यह प्रभावी न हो जाए, तब तक उपयोगकर्ता को निरसन के बारे में सूचित न करें।