रनटाइम की अनुमतियां

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

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

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

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

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

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

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

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

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

adb shell pm list permissions -g -d

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

एंड्रॉइड 10 में कठोर और नरम प्रतिबंध

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

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

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

अनुमति सूची स्थापना के दौरान और कब होती है

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

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

आवश्यकताएं

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

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

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

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

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

एकीकरण

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

एप्लिकेशन अपडेट किया जा रहा है

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

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

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

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

नेतृत्वहीन अनुप्रयोग

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

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

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

पैकेजइंस्टालर यूआई को अनुकूलित करना

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

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

अपवाद बनाना

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

ACTION_CALL (Dialer) Default
Phone, Contacts, SMS, Microphone
SMS_DELIVER_ACTION (SMS/MMS) Default
Phone, Contacts, SMS

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

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

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

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

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

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

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

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

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

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

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

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