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

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

बैकग्राउंड

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

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

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

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

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

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

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

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

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

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

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

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

Android के सुरक्षा मॉडल के बारे में ज़्यादा जानने के लिए, 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> एलिमेंट तय करके, दूसरे ऐप्लिकेशन से पसंद के मुताबिक अनुमतियों का अनुरोध किया जा सकता है. हालांकि, यह ध्यान से देखें कि ऐसा करना ज़रूरी है या नहीं.

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

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