पसंद के मुताबिक ऐप्लिकेशन की अनुमति तय करना

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

बैकग्राउंड

Android एक ऐसा ऑपरेटिंग सिस्टम है जिसमें हर ऐप्लिकेशन, अलग-अलग सिस्टम आइडेंटिटी (Linux यूज़र आईडी और ग्रुप आईडी) के साथ काम करता है. सिस्टम के कुछ हिस्सों को भी अलग-अलग आइडेंटिटी में बांटा जाता है. इस तरह, Linux ऐप्लिकेशन को एक-दूसरे और सिस्टम से अलग रखता है.

ऐप्लिकेशन, अन्य ऐप्लिकेशन के लिए अपनी सुविधाओं को तब दिखा सकते हैं, जब वे ऐसी अनुमतियां तय करें जिनका अनुरोध अन्य ऐप्लिकेशन कर सकते हैं. वे ऐसी अनुमतियां भी तय कर सकते हैं जो ऐसे किसी भी अन्य ऐप्लिकेशन को अपने-आप उपलब्ध करा दिया जाता है जिस पर वही प्रमाणपत्र.

ऐप पर हस्ताक्षर

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

डिवाइस बनने के बाद, हस्ताक्षर की अनुमति दें

Android 12 (एपीआई लेवल 31) की शुरुआत में, knownCerts एट्रिब्यूट हस्ताक्षर-लेवल की अनुमतियों से आपको, जानी-पहचानी साइन इन की गतिविधियों का ब्यौरा देखने की सुविधा मिलती है एलान के तौर पर सबमिट किए गए सर्टिफ़िकेट समय.

आपके पास knownCerts एट्रिब्यूट का एलान करने का विकल्प है. साथ ही, हस्ताक्षर के लेवल की किसी खास अनुमति के लिए, अपने ऐप्लिकेशन के protectionLevel एट्रिब्यूट में knownSigner फ़्लैग का इस्तेमाल किया जा सकता है. इसके बाद, सिस्टम अनुरोध करने वाले ऐप्लिकेशन को अनुमति देता है, अगर अनुरोध करने वाले ऐप्लिकेशन के हस्ताक्षर करने वाला वंशावली, जिसमें हस्ताक्षर करने वाले मौजूदा व्यक्ति भी शामिल हैं, किसी एक डाइजेस्ट में से एक से मेल खाता है का एलान knownCerts एट्रिब्यूट में अनुमति के साथ किया गया है.

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

उपयोगकर्ता आईडी और फ़ाइल का ऐक्सेस

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

सुरक्षा की पुष्टि, प्रोसेस के लेवल पर की जाती है. इसलिए, आम तौर पर किसी एक प्रोसेस में दो पैकेज के कोड नहीं चलाए जा सकते. ऐसा इसलिए, क्योंकि उन्हें अलग-अलग Linux उपयोगकर्ताओं के तौर पर चलाना होता है.

किसी ऐप्लिकेशन के ज़रिए सेव किया गया कोई भी डेटा, उस ऐप्लिकेशन के उपयोगकर्ता को असाइन किया जाता है आईडी के साथ-साथ इसे आम तौर पर दूसरे पैकेज ऐक्सेस नहीं कर सकते.

Android के सुरक्षा मॉडल के बारे में ज़्यादा जानकारी के लिए, Android की सुरक्षा के बारे में खास जानकारी देखें.

चेतावनी: AndroidManifest.xml फ़ाइल के <manifest> टैग में मौजूद sharedUserId एट्रिब्यूट का इस्तेमाल करके, एक ही उपयोगकर्ता आईडी को कई पैकेज असाइन किया जा सकता है. हालांकि, शेयर किए गए उपयोगकर्ता आईडी की वजह से पैकेज मैनेजर में, तय नहीं किया जा सकता कि क्या होगा. इसलिए, इनके इस्तेमाल की सलाह बिलकुल सही नहीं दी जाती है. साथ ही, इन्हें Android का अगला वर्शन होने वाला है. इसके बजाय, ऐप्लिकेशन को शेयर किए गए कॉम्पोनेंट के बीच इंटरऑपरेबिलिटी को आसान बनाने के लिए, सेवाओं और कॉन्टेंट की सेवा देने वाली कंपनियों जैसी सही कम्यूनिकेशन सुविधाओं का इस्तेमाल करना चाहिए. ध्यान दें कि मौजूदा ऐप्लिकेशन, इस वैल्यू को हटा नहीं सकते, क्योंकि शेयर किए गए उपयोगकर्ता आईडी से माइग्रेट करने की सुविधा काम नहीं करती.

अनुमतियां तय करना और उन्हें लागू करना

अपनी अनुमतियां लागू करने के लिए, आपको सबसे पहले एक या ज़्यादा का उपयोग करके AndroidManifest.xml <permission> एलिमेंट.

नेमिंग कन्वेंशन

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

हमारा सुझाव है कि आप ऐप्लिकेशन के पैकेज के नाम के साथ अनुमतियों को प्रीफ़िक्स के तौर पर लगाएं. इसके लिए, रिवर्स डोमेन-स्टाइल वाला नाम, इसके बाद .permission. और फिर अनुमति की क्षमता का विवरण, ऊपरी SNAKE_CASE. उदाहरण के लिए, com.example.myapp.permission.ENGAGE_HYPERSPACE.

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

उदाहरण

उदाहरण के लिए, अगर किसी ऐप्लिकेशन को यह कंट्रोल करना है कि कौनसे अन्य ऐप्लिकेशन उसकी किसी ऐक्टिविटी को शुरू कर सकते हैं, तो वह इस ऑपरेशन के लिए अनुमति इस तरह से दे सकता है:

<manifest
  xmlns:android="http://schemas.android.com/apk/res/android"
  package="com.example.myapp" >
    
    <permission
      android:name="com.example.myapp.permission.DEADLY_ACTIVITY"
      android:label="@string/permlab_deadlyActivity"
      android:description="@string/permdesc_deadlyActivity"
      android:permissionGroup="android.permission-group.COST_MONEY"
      android:protectionLevel="dangerous" />
    ...
</manifest>

protectionLevel एट्रिब्यूट की वैल्यू देना ज़रूरी है. इससे सिस्टम को यह पता चलता है कि उपयोगकर्ताओं को, अनुमति की ज़रूरत वाले ऐप्लिकेशन के बारे में कैसे बताना है या किन ऐप्लिकेशन के पास अनुमति हो सकती है. इस बारे में लिंक किए गए दस्तावेज़ में बताया गया है.

android:permissionGroup एट्रिब्यूट ज़रूरी नहीं है. इसका इस्तेमाल, सिर्फ़ डिसप्ले की अनुमतियों के लिए किया जाता है उपयोगकर्ता को कौन-कौनसे प्रॉडक्ट दिखेंगे. ज़्यादातर मामलों में, इसे स्टैंडर्ड सिस्टम पर सेट किया जाता है ग्रुप (android.Manifest.permission_group में दी गई सूची में शामिल), हालांकि, नीचे दिए गए सेक्शन में बताए गए तरीके से, ग्रुप को खुद तय किया जा सकता है. हम किसी मौजूदा ग्रुप का इस्तेमाल करने का सुझाव देते हैं, क्योंकि इससे उपयोगकर्ता को अनुमति वाला यूज़र इंटरफ़ेस (यूआई) दिखाया गया.

आपको अनुमति के लिए, लेबल और जानकारी, दोनों देनी होगी. ये स्ट्रिंग रिसॉर्स होते हैं जिन्हें उपयोगकर्ता तब देख सकता है, जब वे अनुमतियों की सूची देख रहे हैं (android:label) या एक ही अनुमति के बारे में जानकारी दें (android:description). लेबल छोटा है: कुछ शब्द जो काम करती है, जिसे अनुमति सुरक्षित कर रही है. इसकी जानकारी इस अनुमति से, मालिक क्या कर सकता है, इसकी जानकारी देने वाले कुछ वाक्य. हमारे कन्वेंशन, दो वाक्यों में लिखा गया है, जहां पहले वाक्य में बताया गया है अनुमति और दूसरा वाक्य उपयोगकर्ता को चेतावनी देता है कि जो तब गलत हो सकता है, जब किसी ऐप्लिकेशन को यह अनुमति मिल जाती है.

यहां CALL_PHONE अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है अनुमति:

<string name="permlab_callPhone">directly call phone numbers</string>
<string name="permdesc_callPhone">Allows the app to call non-emergency
phone numbers without your intervention. Malicious apps may cause unexpected
calls on your phone bill.</string>

अनुमतियों का ग्रुप बनाना

पिछले सेक्शन में दिखाए गए तरीके के मुताबिक, android:permissionGroup एट्रिब्यूट का इस्तेमाल किया जा सकता है. इससे सिस्टम को, उपयोगकर्ता को अनुमतियों के बारे में बताने में मदद मिलती है. ज़्यादातर मामलों में, आप इसे एक मानक पर सेट करते हैं सिस्टम ग्रुप (यह सूची, देश या इलाके में मौजूद है android.Manifest.permission_group), लेकिन आप इसका इस्तेमाल करके अपना खुद का समूह भी तय कर सकते हैं <permission-group>.

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

आप ग्रुप का नाम, <permission> अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है एलिमेंट का permissionGroup एट्रिब्यूट की वैल्यू सबमिट करें.

<permission-tree> एलिमेंट, कोड में बताई गई अनुमतियों के ग्रुप के लिए नेमस्पेस तय करता है.

अनुमति के लिए पसंद के मुताबिक सुझाव

अपने ऐप्लिकेशन के लिए कस्टम अनुमतियां तय की जा सकती हैं. साथ ही, कस्टम अनुमतियों का अनुरोध किया जा सकता है दूसरे ऐप्लिकेशन से हटाने के लिए <uses-permission> एलिमेंट तय करें. हालांकि, ध्यान से देखें कि ऐसा करना ज़रूरी है या नहीं.

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

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

इनके बारे में पढ़ना जारी रखें:

<uses-permission>

मेनिफ़ेस्ट टैग के लिए एपीआई रेफ़रंस, जो आपके ऐप्लिकेशन के लिए ज़रूरी सिस्टम अनुमतियों के बारे में बताता है.

शायद आपकी दिलचस्पी इनमें भी हो:

Android की सुरक्षा से जुड़ी खास जानकारी

Android प्लैटफ़ॉर्म के सिक्योरिटी मॉडल के बारे में ज़्यादा जानकारी.