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

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

• इंस्टॉल करते समय अनुमतियां

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

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

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

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

रनटाइम की अनुमतियों की मदद से, किसी भी ऐप्लिकेशन को उपयोगकर्ता की सहमति के बिना उसका निजी डेटा ऐक्सेस करने से रोका जाता है. और उन्हें इस बारे में ज़्यादा जानकारी और ऐक्सेस की जानकारी देनी होगी कि किस तरह की अनुमतियां ऐप्लिकेशन या तो ढूंढ रहे हैं या उन्हें अनुमति मिल गई है. रनटाइम मॉडल, डेवलपर को इससे लोगों को यह समझने में मदद मिलती है कि ऐप्लिकेशन को किन अनुमतियों की ज़रूरत है. साथ ही, इससे लोगों को पारदर्शिता बनाए रखता है, ताकि उपयोगकर्ता अपनी सहमति देने या न देने के बारे में बेहतर फ़ैसले ले सकें.

वे अनुमतियां जिन पर असर पड़ा है

रनटाइम अनुमतियों का मॉडल इस्तेमाल करने के लिए, Android 6.0 और उसके बाद के वर्शन के लिए खतरनाक अनुमतियों की ज़रूरत होती है. खतरनाक अनुमतियां ज़्यादा जोखिम वाली अनुमतियां होती हैं, जैसे कि READ_CALENDAR ऐप्लिकेशन से उपयोगकर्ता के निजी डेटा को ऐक्सेस करने या किसी डिवाइस को कंट्रोल करने का अनुरोध करना. उपयोगकर्ता पर असर पड़ता है. खतरनाक अनुमतियों की सूची देखने के लिए, यह निर्देश चलाएं:

adb shell pm list permissions -g -d

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

Android 10 में सख्त और सॉफ़्ट पाबंदियां

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

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

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

अनुमति वाली सूची, इंस्टॉल करने के दौरान ली जाती है और जब

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

उपयोगकर्ता, अनुमतियों को मैन्युअल तौर पर अनुमति नहीं दे सकते.

ज़रूरी शर्तें

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

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

अनुमतियों को माइग्रेट करना

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

Android 9 से 10 के अपडेट में, मुश्किल से सीमित अनुमतियां मिलती हैं अनुमति वाली सूची में शामिल. फ़ोरग्राउंड/बैकग्राउंड के बंटवारे की अनुमतियों को लागू करने के बारे में जानकारी के लिए, Android 10 निजता में बदलाव से शुरू होने वाला बैकग्राउंड का अनुरोध करें जगह की जानकारी.

SDK टूल इंटिग्रेशन

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

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

सिस्टम इमेज पर मौजूद ऐप्लिकेशन और पहले से इंस्टॉल किए गए ऐप्लिकेशन, अपने-आप पहले से इंस्टॉल नहीं होते अनुमतियां दी हैं. हमारा सुझाव है कि आप पहले से इंस्टॉल किए गए ऐप्लिकेशन डेवलपर के साथ काम करें. जैसे, OEM, मोबाइल और इंटरनेट सेवा देने वाली कंपनी, और तीसरे पक्ष की कंपनियां पक्ष) का इस्तेमाल करके, developer का इस्तेमाल करके ऐप्लिकेशन में ज़रूरी बदलाव करें दिशा-निर्देशों के मुताबिक होना चाहिए. खास तौर पर, आपको यह पक्का करना होगा कि पहले से इंस्टॉल किए गए ऐप्लिकेशन में बदलाव किए गए हों, ताकि जब उपयोगकर्ता अनुमतियां रद्द कर देता है, तब क्रैश और अन्य समस्याएं.

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

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

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

बिना ग्राफ़िक यूज़र इंटरफ़ेस वाले ऐप्लिकेशन

सिर्फ़ गतिविधियों के लिए ही अनुमतियों का अनुरोध किया जा सकता है. सेवाएं सीधे तौर पर अनुमतियों का अनुरोध नहीं कर सकतीं.

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

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

पैकेज इंस्टॉलर यूज़र इंटरफ़ेस (यूआई) को पसंद के मुताबिक बनाएं

आपके पास अनुमतियों के यूज़र इंटरफ़ेस (यूआई) थीम को पसंद के मुताबिक बनाने के लिए, डिवाइस की डिफ़ॉल्ट थीम अपडेट की जा रही हैं (Theme.DeviceDefault.Settings और Theme.DeviceDefault.Light.Dialog.NoActionBar) इस्तेमाल करने वाला पैकेज इंस्टॉलर. हालांकि, ऐप्लिकेशन डेवलपर के लिए एक जैसा अनुभव बेहद ज़रूरी होता है. इसलिए, आप अनुमतियों के प्लेसमेंट, पोज़िशन, और नियमों को पसंद के मुताबिक नहीं बना सकते यूज़र इंटरफ़ेस (यूआई) दिखता है.

अगर दूसरी भाषाओं के लिए स्ट्रिंग शामिल करनी है, तो स्ट्रिंग को एओएसपी के रूप में जोड़ा जाता है.

अपवाद बनाएं

आपके पास उन ऐप्लिकेशन को पहले से अनुमतियां देने का विकल्प होता है जो डिफ़ॉल्ट हैंडलर हैं या की सेवा देने वाली कंपनियां, PackageManager में DefaultPermissionGrantPolicy.java क्लास. उदाहरण:

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

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

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

कस्टम अनुमतियों और ग्रुप को सामान्य के तौर पर सेट किया जा सकता है या खतरनाक हैं और मौजूदा अनुमतियों के ग्रुप की सुविधा मिलती है, जैसा कि Android 5.x और इससे पहले के वर्शन में मिलता था.

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

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

टेस्ट की अनुमतियां

Android में कम्पैटिबिलिटी टेस्ट सुइट (सीटीएस) के टेस्ट शामिल हैं. इनकी मदद से, पुष्टि की जा सकती है अलग-अलग अनुमतियां सही ग्रुप के साथ मैप की गई हों. इन परीक्षणों में सफल होना Android 6.0 और उसके बाद के वर्शन के साथ काम करने वाले CTS की ज़रूरत होती है.

अनुमतियां वापस लें

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

यह समझना ज़रूरी है कि किसी एक अनुमति को वापस लेना सेटिंग यूज़र इंटरफ़ेस (यूआई), जो ग्रुप के हिसाब से अनुमतियों का इस्तेमाल करता है. आम तौर पर, अनुमतियों का ग्रुप इस तरह से दिखता है जब तक उस ग्रुप में कम से कम एक अनुमति दी गई हो. अगर पक्का करना हो कि उपयोगकर्ता आपके लिए ज़रूरी सेटिंग में निरस्त किए जाने की पुष्टि कर सकते हैं, तो अनुमति समूह में अनुमति है. यह जानने के लिए कि किसी खास ग्रुप से कौन-कौनसी अनुमतियां हैं, PackageManager.getGroupOfPlatformPermission का इस्तेमाल करें और PackageManager.getPlatformPermissionsForGroup.

जब सिस्टम अनुरोध की गई अनुमतियों को रद्द करता है, तो यह उससे जुड़े बैकग्राउंड को भी रद्द कर देता है अनुमतियां तब दी जाएंगी, जब फ़ोरग्राउंड से जुड़ी उनसे जुड़ी कोई भी अनुमति अब भी न दी गई हो.

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

किसी अनुमति के रद्द होने के बाद, उसके लिए फिर से अनुरोध किया जा सकता है. साथ ही, उपयोगकर्ता अनुरोध स्वीकार या अस्वीकार करने के लिए प्रॉम्प्ट किया जाए. ऐसी अनुमति का अनुरोध नहीं किया जा सकता, जिसके पास उपयोगकर्ता ने पहले अस्वीकार कर दिया हो. हमारा सुझाव है कि आप इन अनुमतियों को वापस ले लें फ़िलहाल होल्ड पर हैं, लेकिन अब उसकी ज़रूरत नहीं है, तो आपको उपयोगकर्ता को सहमति तब तक वापस ली जा सकती है, जब तक वे लागू नहीं होते.