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

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

बैकग्राउंड

Android, अलग-अलग अधिकारों वाला ऑपरेटिंग सिस्टम है. इसमें हर ऐप्लिकेशन, सिस्टम की अलग पहचान (Linux यूज़र आईडी और ग्रुप आईडी) के साथ चलता है. सिस्टम के कुछ हिस्सों को भी अलग-अलग पहचानों में बांटा गया है. इस वजह से, 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 एट्रिब्यूट ज़रूरी है. इससे सिस्टम को यह पता चलता है कि अनुमति की ज़रूरत वाले ऐप्लिकेशन के बारे में उपयोगकर्ताओं को कैसे बताया जाए या किन ऐप्लिकेशन के पास अनुमति हो सकती है. इसके बारे में, लिंक किए गए दस्तावेज़ में बताया गया है.

The 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> एलिमेंट के साथ किया गया है और वे भी जिनका एलान कहीं और किया गया है. इससे सिर्फ़ यह तय होता है कि उपयोगकर्ता को अनुमतियां कैसे ग्रुप की जाती हैं. The <permission-group> एलिमेंट, यह तय नहीं करता कि ग्रुप में कौनसी अनुमतियां शामिल हैं. हालांकि, यह ग्रुप को एक नाम देता है.

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

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

कस्टम अनुमति के सुझाव

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

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

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