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

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 और इससे पहले के वर्शन की तरह ही, सिस्टम ऐप्लिकेशन इंस्टॉल करते समय, अनुरोध करने वाले ऐप्लिकेशन को सामान्य अनुमतियां अपने-आप देता है. साथ ही, उपयोगकर्ता से अनुमति नहीं मांगता. अनुमतियों के बारे में ज़्यादा जानने के लिए, <permission> एलिमेंट का दस्तावेज़ देखें.

Android 10 में सख्त और सामान्य पाबंदियां

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

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

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

अनुमति वाली सूची में शामिल करने की प्रोसेस, इंस्टॉल करने के दौरान होती है. साथ ही,

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

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

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

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

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

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

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

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

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

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

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

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

पहले से इंस्टॉल किए गए ऐप्लिकेशन

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

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

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

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

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

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

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

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

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

अपवाद बनाना

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

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

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

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

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

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

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

अनुमतियों की जांच करना

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

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

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

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

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

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

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