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 یا اسی طرح کی مستثنا کا سبب بنے گی۔ اجزاء application ٹیگ کے اندر ایسے ترتیب سے رجسٹر کیے جاتے ہیں جو ان کے کام کو متاثر نہیں کرتا۔

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 میں اجازتیں

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 ٹیگ اعلان کرتا ہے کہ ایک جزو کون سے ضمنی intent کو سنبال سکتا ہے۔ یہ وہ میکانزم ہے جس کے ذریعۙ Android سسٹم یا کسٹم کاروائیوں کو ایپ سے منسلک کرتا ہے۔ ایک intent filter تین عناصر پر مشتمل ہے: کاروائی (action)، زمرہ (category) اور ڈیٹا (data)۔ ان تینوں کو ملا کر درست طور پر بیان کیا جا سکتا ہے کہ جزو کو کون سے intent وصول کرنے چاہیے۔ سسٹم سب سے مخصوص فلٹر کے بنیاد پر موزوں جزو کا انتخاب کرتا ہے۔

<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 کنجیاں، اینڈ پائنٹ URLز اور فیچر فلیگز۔ meta-data سے ڈیٹا رن ٹائم میں PackageManager.getApplicationInfo().metaData کے ذریعۙ قابل رسائی ہے۔ مثال کے طور پر، Firebase اور Google Maps مورچھ کوڈ میں ہارڈکوڈنگ کیے بغیر رسائی کنجیاں پہیانے کے لیے meta-data استعمال کرتے ہیں۔ اس کے بجائے، کنجیاں manifest میں مقرر کی جاتی ہیں اور مختلف بائلڈ فلیورز کے لیے مختلف ہو سکتی ہیں۔

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 کو صرف پروفائلنگ اور ضرورت کی تصدیق کے بعد استعمال کریں۔