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

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

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

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

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

    (Android 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 . में हार्ड और सॉफ्ट प्रतिबंध

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

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

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

श्वेतसूचीकरण स्थापना के दौरान होता है, और कब

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

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

आवश्यकताएं

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

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

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

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

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

एकीकरण

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

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

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

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

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

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

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

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

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

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

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

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

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

अपवाद बनाना

आप उन अनुप्रयोगों जो सामान्य हैंडलर या कोर ओएस कार्यक्षमता के लिए प्रदाताओं का उपयोग कर रहे हैं करने के लिए पहले से अनुदान कर सकते हैं अनुमतियाँ DefaultPermissionGrantPolicy.java PackageManager में वर्ग। उदाहरण:

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 संगतता के लिए एक आवश्यकता है।