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

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

बैकग्राउंड

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

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

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

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

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

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

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

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

यूज़र आईडी और फ़ाइल ऐक्सेस

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

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

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

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

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

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

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

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

हमारा सुझाव है कि अनुमतियों के नाम से पहले, ऐप्लिकेशन के पैकेज का नाम जोड़ें. इसके लिए, रिवर्स-डोमेन-स्टाइल नेमिंग का इस्तेमाल करें. इसके बाद, .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> एलिमेंट तय करके, अन्य ऐप्लिकेशन से पसंद के मुताबिक अनुमतियों का अनुरोध किया जा सकता है. हालांकि, ध्यान से सोचें कि क्या आपको वाकई कई साइटों की ज़रूरत है.

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

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