AndroidManifest.xml — ما هو، المكونات الرئيسية وتكوين المانيفست

ما هو AndroidManifest.xml

AndroidManifest.xml هو ملف التكوين الجذري بتنسيق XML الذي يجب أن يكون موجودًا في كل مشروع Android في المسار app/src/main. يقوم نظام Android بتحليله قبل تشغيل أي كود للتطبيق — أثناء تحليل APK عند التثبيت. إذا كان المانيفست يحتوي على خطأ نحوي أو يفتقد إعلانًا إلزاميًا، يتم إيقاف التثبيت مع رسالة خطأ.

يحتوي الملف على إعلان كامل للتطبيق: قائمة جميع المكونات (Activity، Service، BroadcastReceiver، ContentProvider)، الأذونات المطلوبة، أدنى إصدار لـ SDK، متطلبات العدات وتكوين السمات والأنماط. يجب أن يتم التصريح بصراحة بكل مكون يمكن أن يتم استدعاؤه من قبل النظام أو التطبيقات الأخرى في المانيفست. هذا متطلب أماني: بدون إعلان صريح، لا يكون المكون متاحًا للاستدعاء.

بدون مانيفست مكون بشكل صحيح، لا يمكن تثبيت التطبيق عبر Google Play أو التثبيت الجانبي. يتحقق النظام من المانيفست أثناء تحليل APK ويرفض التثبيت عند وجود أخطاء. كما يقوم Google Play بفحص المانيفست بحثًا عن تكوينات غير آمنة: إذا كان exported=true على مكون بدون intent-filter، يتم إصدار تحذير، وإذا كانت الأذونات الإلزامية لـ targetSdk 34+ مفقودة، يتم حظر النشر. لذا، فهم هيكل المانيفست هو مهارة إلزامية لمطوري Android.

مكونات التطبيق في المانيفست

يجب أن يتم تسجيل كل مكون من مكونات تطبيق Android بصراحة في المانيفست. هذا متطلب إلزامي من المنصة لجميع أنواع المكونات الأربعة. بدون تسجيل، لا يمكن للنظام إنشاء المكون، ومحاولة تشغيله ستؤدي إلى ActivityNotFoundException أو استثناء مماثل. تتم تسجيل المكونات داخل وسم application بترتيب لا يؤثر على عملها.

Activity

يسجل وسم activity شاشة التطبيق. تحدد السمة exported ما إذا كانت التطبيقات الأخرى تستطيع تشغيل هذه Activity. بدءًا من Android 12، عدم وجود exported عند وجود intent-filter يتسبب في خطأ بناء — هذا متطلب أماني. تتم تعيين نقطة الدخول عبر intent-filter بإجراء MAIN وفئة LAUNCHER. يجب أن يكون لكل 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، هناك قيود صارمة على الخدمات الخلفية: تتطلب الخدمة الأمامية إشعارًا إلزاميًا مرئيًا للمستخدم مع أيقونة، وتعيش الخدمة المرتبطة فقط وجود عميل مرتبط بها. الخدمات التي تعمل في الخلفية بدون إشعار يتم إنهاؤها تلقائيًا من قبل النظام خلال دقائق بعد انتقال التطبيق إلى الخلفية. للمهام طويلة المدة، استخدم WorkManager بدلًا من Service.

<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 لتجنب خطأ إذن غير معروف على الأجهزة القديمة. تسمح السمة maxSdkVersion في uses-permission بإلغاء الأذونات غير الضرورية تلقائيًا عند تحديث التطبيق على إصدارات 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. لدعم تصاميم URL مخصصة مثل myapp://، يكفي تحديد النمط بدون مضيف. ولكن، يوصي 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>

يسمح وسم meta-data داخل application بتخزين أزواج مفتاح-قيمة تعسفية. هذا مفيد لتكوين مكتبات الطرف الثالث: مفاتيح API، عناوين endpoint وعلامات الوظائف. البيانات من 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 ويوفر آلية أكثر مرونة لإدارة أمان الاتصالات على مستوى نظام التشغيل.

تطلب السمة android:largeHeap حجم كومة مزداد للتطبيق. افتراضيًا، يخصص Android لكل تطبيق مقدارًا محدودًا من الذاكرة يعتمد على الجهاز وإصدار نظام التشغيل. إذا كان التطبيق يعمل مع صور كبيرة أو فيديو أو مجموعات بيانات كبيرة، يمكن لـ largeHeap منع OutOfMemoryError. ولكن إساءة استخدام هذه السمة ضارة: يتم إنهاء التطبيق ذو استهلاك الذاكرة العالي بشكل أسرع من قبل النظام عند ندرة الموارد. استخدم largeHeap فقط بعد التحليل وتأكيد الحاجة.