AndroidManifest.xml — यह क्या है, मुख्य घटक और मैनिफ़ेस्ट कॉन्फ़िगरेशन

AndroidManifest.xml क्या है

AndroidManifest.xml वह मूल कॉन्फ़िगरेशन फ़ाइल है XML फ़ॉर्मेट में जो प्रत्येक Android प्रोजेक्ट को app/src/main निर्देशिका में होना चाहिए। Android सिस्टम किसी भी एप् कोड को चलाने से पहले — इंस्टॉल के समय APK पार्सिंग के दौरान — इसे पार्स करता है। यदि मैनिफ़ेस्ट में सिंटैक्स त्रुटि है या कोई अनिवार्य घोषणा गयब है, तो इंस्टॉलेशन एक त्रुटि संदेश के साथ रुक जाता है।

फ़ाइल में एप्लिकेशन की पूरी घोषणा होती है: सभी घटकों (Activity, Service, BroadcastReceiver, ContentProvider) की सूची, अनुरोधित अनुमतियाँ, न्यूनतम SDK संस्करण, हार्डवेयर आवश्यकताएँ और थीम और शैली कॉन्फ़िगरेशन। प्रत्येक घटक जो सिस्टम या अन्य एप्स द्वारा बुलाया जा सकता है, उसे मैनिफ़ेस्ट में स्पष्ट रूप से घोषित किया जाना चाहिए। यह एक सुरक्षा आवश्यकता है: स्पष्ट घोषणा के बिना, घटक बुलाये जाने के लिए उपलब्ध नहीं होता है।

बिना एक सही ढंग से कॉन्फ़िगर किए मैनिफ़ेस्ट के, एप्लिकेशन Google Play या साइडलोडिंग के माध्यम से इंस्टॉल नहीं किया जा सकता है। सिस्टम APK पार्सिंग के दौरान मैनिफ़ेस्ट की जाँच करता है और त्रुटियों पर इंस्टॉलेशन को अस्वीकार कर देता है। Google Play असुरक्षित कॉन्फ़िगरेशनों के लिए मैनिफ़ेस्ट को भी स्कैन करता है: यदि किसी घटक पर intent-filter के बिना exported=true है, तो एक चेतावनी जारी की जाती है, और यदि targetSdk 34+ के लिए अनिवार्य अनुमतियाँ गयब हैं, तो प्रकाशन अवरुद्ध हो जाता है। इसलिए, मैनिफ़ेस्ट संरचना को समझना Android डिवेलपर्स के लिए एक अनिवार्य कौशल है।

मैनिफ़ेस्ट में एप्लिकेशन के घटक

प्रत्येक Android एप् घटक को मैनिफ़ेस्ट में स्पष्ट रूप से पंजीकृत होना चाहिए। यह सभी चार प्रकार के घटकों के लिए एक अनिवार्य प्लेटफ़ॉर्म आवश्यकता है। पंजीकरण के बिना, घटक सिस्टम द्वारा नहीं बनाया जा सकता है, और इसे लॉन्च करने की कोशिश करने पर ActivityNotFoundException या इसी तरह का अपवाद आएगा। घटक एप्लिकेशन टैग के अंदर एक क्रम में पंजीकृत होते हैं जो उनके संचालन को प्रभावित नहीं करता है।

Activity

activity टैग एप् स्क्रीन को रजिस्टर करता है। exported गुण यह निर्धारित करता है कि क्या अन्य एप्स इस Activity को लॉन्च कर सकते हैं। Android 12 से शुरू करके, intent-filter होने पर exported का अभाव बिल्ड त्रुटि का कारण बनता है — यह एक सुरक्षा आवश्यकता है। एंट्री पॉइंट MAIN क्रिया और LAUNCHER श्रेणी के साथ intent-filter के माध्यम से सेट किया जाता है। प्रत्येक Activity का एक अनोखा android:name होना चाहिए जो पूर्ण या सापेक्ष क्लास नाम से मेल खाता हो।

<activity
    android:name=".MainActivity"
    android:exported="true"
    android:windowSoftInputMode="adjustResize">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
</activity>

Service

service टैग एक बैकग्रॉंड सर्विस को परिभाषित करता है। Android 8 से शुरू करके, बैकग्रॉंड सर्विसों पर सत्वर प्रतिबंध हैं: एक foreground सर्विस को एक आइकन के साथ अनिवार्य उपयोगकर्ता-दृश्य अधिसूचना चाहिए, और एक bound सर्विस केवल तब तक जीवित रहता है जब तक उससे कोई क्लाइंट बँधा हो। अधिसूचना के बिना बैकग्रॉंड में चलने वाली सर्विसें एप् के बैकग्रॉंड में जाने के कुछ मिनटों के भीतर सिस्टम द्वारा स्वचालित रूप से समाप्त कर दी जाती हैं। लंबे समय के कार्यों के लिए, Service के बजाय WorkManager का उपयोग करें।

<service
    android:name=".SyncService"
    android:exported="false"
    android:foregroundServiceType="dataSync" />

BroadcastReceiver

receiver टैग सिस्टम या कस्टम ब्रॉडकास्ट संदेशों के लिए एक रिसीवर की घोषणा करता है। Android 8 से शुरू करके, अधिकांश अव्यक्त ब्रॉडकास्ट अब मैनिफ़ेस्ट में स्थैतिक रूप से घोषित रिसीवर्स को डेलिवर नहीं किए जाते हैं। इसके बजाय, कोड में Context.registerReceiver के माध्यम से रिसीवर्स को डायनामिक रूप से रजिस्टर करने की अनुशंसा की जाती है। अपवादों में BOOT_COMPLETED जैसे कुछ सिस्टम ब्रॉडकास्ट शामिल हैं, जिन्हें अद्यापि मैनिफ़ेस्ट में स्थैतिक पंजीकरण की आवश्यकता होती है।

<receiver
    android:name=".ConnectivityReceiver"
    android:exported="true">
    <intent-filter>
        <action android:name="android.net.conn.CONNECTIVITY_CHANGE" />
    </intent-filter>
</receiver>

Android में अनुमतियाँ (Permissions)

Android में प्रत्येक खतरनाक अनुमति को मैनिफ़ेस्ट में uses-permission टैग के माध्यम से घोषणा की आवश्यकता होती है। Android 6 से शुरू करके, खतरनाक अनुमतियों को रनटाइम पर उपयोगकर्ता संवाद के माध्यम से अनुरोध किया जाता है, लेकिन मैनिफ़ेस्ट में घोषणा अनिवार्य बनी रहती है। इसके बिना, requestPermissions मेथड SecurityException फैंकति करता है। INTERNET और ACCESS_NETWORK_STATE जैसे सामान्य स्तर की अनुमतियाँ इंस्टॉल के समय स्वचालित रूप से प्रदान की जाती हैं।

uses-permission-sdk-23 टैग केवल Android 6.0+ पर आवश्यक अनुमतियों को निर्दिष्ट करता है। यह मौजूदा अनुमतियों का अनुरोध किए बिना पुराने संस्करणों के साथ संगतता बनाए रखने की अनुमति देता है। उदाहरण के लिए, POST_NOTIFICATIONS केवल Android 13+ पर उपलब्ध है, इसलिए पुराने डिवाइसों पर अज्ञात अनुमति त्रुटि से बचने के लिए इसे uses-permission-sdk-33 के माध्यम से निर्दिष्ट किया जाना चाहिए। uses-permission में maxSdkVersion गुण नए Android संस्करणों पर एप् को अपडेट करते समय अनावश्यक अनुमतियों को स्वचालित रूप से रद्द करने की अनुमति देता है।

सामान्य स्तर की अनुमतियाँ (INTERNET, ACCESS_NETWORK_STATE) इंस्टॉल के समय स्वचालित रूप से प्रदान की जाती हैं और रनटाइम अनुरोध की आवश्यकता नहीं होती है। वे uses-permission के माध्यम से भी घोषित की जाती हैं लेकिन उपयोगकर्ता को संवाद में नहीं दिखाई जाती हैं। अन्य एप्लिकेशनों से एप् घटकों तक पहुंच को नियंत्रित करने के लिए, अनुमति-संरक्षित घटक तंत्र का उपयोग किया जाता है: आप Activity या Service स्तर पर एक कस्टम अनुमति निर्दिष्ट कर सकते हैं, जिसे बाहर से घटक को बुलाये जाने पर सिस्टम द्वारा जाँचा जाएगा। यह अंतर-प्रक्रिया संचार के लिए एक अतिरिक्त सुरक्षा परत प्रदान करता है।

Intent Filters और डीप लिंक्स

मैनिफ़ेस्ट में intent-filter टैग घोषित करता है कि कौन से अव्यक्त इंटेंट को एक घटक संभाल सकता है। यह वह तंत्र है जिसके माध्यम से Android सिस्टम या कस्टम क्रियाओं को एप् से जोड़ता है। एक intent filter में तीन तत्व होते हैं: क्रिया (action), श्रेणी (category) और डेटा (data)। घटक को कौन से इंटेंट प्राप्त करने चाहिए, इसका सटीक वर्णन करने के लिए तीनों को जोड़ा जा सकता है। सिस्टम सबसे विशिष्ट फ़िल्टर के आधार पर उपयुक्त घटक का चयन करता है।

<activity android:name=".DeepLinkActivity">
    <intent-filter android:autoVerify="true">
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data
            android:scheme="https"
            android:host="itsectr.com"
            android:pathPrefix="/app" />
    </intent-filter>
</activity>

autoVerify गुण Android App Links सत्यापन को सक्षम करता है: सिस्टम डोमेन स्वामित्व की पुष्टि के लिए सर्वर से संपर्क करता है। सत्यापन के बिना, डीप लिंक्स मानक चूज़र डायलॉग के माध्यम से काम करते हैं जहाँ उपयोगकर्ता चुनता है कि लिंक कौन से एप् से खोले। सफल सत्यापन के बाद, लिंक्स बिना डायलॉग के सीधे एप् में खुलते हैं। Google Search Console भी डीप लिंक्स को इंडेक्स करने और उन्हें खोज परिणामों में दिखाने के लिए autoVerify का उपयोग करता है।

action.VIEW और DEFAULT और BROWSABLE श्रेणियों के साथ फ़िल्टर ब्राउज़रों, ईमेल और अन्य एप्स से लिंक्स को संभालते हैं। Android में डीप लिंक्स को लागू करने का यह मुख्य तंत्र है। myapp:// जैसी कस्टम URL स्कीम का समर्थन करने के लिए, बिना होस्ट के सिर्फ स्कीम निर्दिष्ट करें। हालांकि, Google कस्टम स्कीम के बजाय HTTPS डीप लिंक्स का उपयोग करने की अनुशंसा करता है क्योंकि वे अधिक सुरक्षित हैं और अतिरिक्त अनुमतियों की आवश्यकता नहीं होती है। कस्टम स्कीम को कोई भी एप् रोक सकता है जो उसी स्कीम को रजिस्टर करता है।

एप्लिकेशन के गुण और मेटाडेटा

मूल manifest टैग में पैकेज, संस्करण और SDK गुण होते हैं। application टैग वैश्विक सेटिंग्स स्टोर करता है: थीम, आइकन, लेबल और डीबगिंग फ़्लैग्स। manifest गुण पैकेज स्तर पर संस्करण को परिभाषित करते हैं, जबकि application गुण एप् के समग्र स्वरूप और व्यवहार को निर्धारित करते हैं। मान @-सिंटैक्स के माध्यम से संसाधन संदर्भ या स्ट्रिंग लिटरल हो सकते हैं।

<manifest
    xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.itsectr.myapp"

    <uses-sdk
        android:minSdkVersion="24"
        android:targetSdkVersion="34" />

    <application
        android:label="MyApp"
        android:icon="@mipmap/ic_launcher"
        android:theme="@style/Theme.MyApp"
        android:supportsRtl="true"
        android:allowBackup="true">
        <!--  एप्लिकेशन के घटक  -->
    </application>
</manifest>

application के अंदर meta-data टैग मनमानी कुंजी-मान जोड़े स्टोर करने की अनुमति देता है। यह तीसरे पक्ष की लाइब्रेरियों को कॉन्फ़िगर करने के लिए सुविधाजनक है: API कुंजीं, endpoint URL और फ़ीचर फ़्लैग्स। meta-data से डेटा रनटाइम पर PackageManager.getApplicationInfo().metaData के माध्यम से पहुंच योग्य है। उदाहरण के लिए, Firebase और Google Maps स्रोत कोड में हार्डकोडिंग किए बिना एक्सेस कुंजीयों को पास करने के लिए meta-data का उपयोग करते हैं। इसके बजाय, कुंजीं मैनिफ़ेस्ट में सेट की जाती हैं और बिल्ड फ़्लेवर्स के अनुसार भिन्न हो सकती हैं।

android:extractNativeLibs गुण APK से नेटिव लाइब्रेरियों के निष्कर्षण को नियंत्रित करता है। targetSdk 34+ वाले एप्स के लिए, यह गुण स्पष्ट रूप से निर्दिष्ट किया जाना चाहिए, अन्यथा बिल्ड INSTALL_FAILED_INVALID_APK त्रुटि के साथ विफल हो सकता है। यदि extractNativeLibs=false है, तो नेटिव लाइब्रेरियाँ बिना अनपैक किए APK के अंदर रहती हैं, जिससे इंस्टॉलेड एप् का आकार कम होता है लेकिन लाइब्रेरी लोडिंग समय बढ़ जाता है। अधिकांश आधुनिक एप्स के लिए, उपयोगकर्ता के डिवाइस पर डिस्क स्पेस कम करने के लिए extractNativeLibs=false की अनुशंसा की जाती है।

android:networkSecurityConfig गुण एक नेटवर्क सुरक्षा कॉन्फ़िगरेशन फ़ाइल निर्दिष्ट करने की अनुमति देता है। यह targetSdk 28+ वाले एप्स के लिए विशेष रूप से महत्वपूर्ण है, जहाँ HTTP ट्रैफिक डिफ़ॉल्ट रूप से अवरुद्ध है। कॉन्फ़िगरेशन फ़ाइल विश्वसनीय प्रमाणपत्रों, HTTP कनेक्शन के लिए डोमेन और प्रमाणपत्र पिनिंग नियमों को परिभाषित करती है। यह पुराने android:usesCleartextTraffic गुण को बदलता है और OS स्तर पर कनेक्शन सुरक्षा के प्रबंधन के लिए एक अधिक लचीला तंत्र प्रदान करता है।

android:largeHeap गुण एप् के लिए बढ़ी हुई हीप आकार का अनुरोध करता है। डिफ़ॉल्ट रूप से, Android प्रत्येक एप् को एक सीमित मेमरी आवंटित करता है जो डिवाइस और OS संस्करण पर निर्भर करता है। यदि एप् भारी छवियों, वीडियो या बड़े डेटासेट के साथ काम करता है, तो largeHeap OutOfMemoryError को रोक सकता है। हालांकि, इस गुण का दुरुपयोग हानिकारक है: उच्च मेमरी खपत वाला एप् संसाधनों की कमी होने पर सिस्टम द्वारा तेज़ी से समाप्त कर दिया जाता है। largeHeap का उपयोग केवल प्रोफ़ाइलिंग और आवश्यकता की पुष्टि के बाद ही करें।