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

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

बैकग्राउंड

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

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

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

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

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

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

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

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

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

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

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

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

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

चेतावनी: AndroidManifest.xml में sharedUserId एट्रिब्यूट फ़ाइल <manifest> हर पैकेज के लिए टैग का इस्तेमाल इनके लिए किया जा सकता है: कई पैकेज को एक ही यूज़र आईडी असाइन किया गया हो. हालांकि, शेयर किए गए यूज़र आईडी की वजह से, पैकेज के लिए यह तय नहीं किया जा सकता कि डेटा कैसे इकट्ठा किया जाएगा मैनेजर. इसलिए, इनके इस्तेमाल की सलाह बिलकुल सही नहीं दी जाती है. साथ ही, इन्हें 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 प्लैटफ़ॉर्म के सिक्योरिटी मॉडल के बारे में ज़्यादा जानकारी.