أساسيات التطبيق

يمكن كتابة تطبيقات Android باستخدام Kotlin ولغة البرمجة Java ولغات C++. تجمّع أدوات حزمة تطوير البرامج (SDK) لنظام التشغيل Android الرمز البرمجي الخاص بك مع أي ملفات بيانات وموارد في حزمة APK أو "مجموعة حزمات تطبيق Android".

حزمة Android، وهي ملف أرشيف يتضمّن لاحقة .apk، تحتوي على محتوى تطبيق Android المطلوب في وقت التشغيل، كما أنّها الملف الذي تستخدمه الأجهزة التي تعمل بنظام التشغيل Android لتثبيت التطبيق.

إنّ مجموعة حزمات تطبيق Android، وهي ملف أرشيف يتضمّن لاحقة .aab، تحتوي على محتوى مشروع تطبيق Android، بما في ذلك بعض البيانات الوصفية الإضافية غير المطلوبة في وقت التشغيل. تنسيق AAB هو تنسيق نشر لا يمكن تثبيته على أجهزة Android. يعمل على تأجيل إنشاء حزمة APK والتوقيع عليها إلى مرحلة لاحقة.

عند توزيع تطبيقك من خلال Google Play، على سبيل المثال، تنشئ خوادم Google Play حِزم APK محسّنة لا تحتوي إلا على الموارد والرموز التي يطلبها الجهاز المحدّد الذي يطلب تثبيت التطبيق.

يتوفّر كل تطبيق Android في وضع الحماية للأمان الخاص به، ومحميًا من خلال ميزات الأمان التالية في Android:

• نظام التشغيل Android هو نظام Linux متعدد المستخدمين يكون فيه كل تطبيق مستخدمًا مختلفًا.
• بشكل تلقائي، يعيّن النظام رقم تعريف مستخدم فريدًا لنظام التشغيل Linux لكل تطبيق، والذي لا يستخدمه إلا النظام ويكون غير معروف للتطبيق. يضبط النظام الأذونات لجميع الملفات في التطبيق، بحيث يمكن لمعرّف المستخدم المحدّد لهذا التطبيق فقط الوصول إليها.
• ولكل عملية جهاز افتراضي خاص بها، لذلك يتم تشغيل الرمز البرمجي للتطبيق بمعزل عن التطبيقات الأخرى.
• يتم تشغيل كل تطبيق تلقائيًا في عملية Linux الخاصة به. ويبدأ نظام Android العملية عند الحاجة إلى تنفيذ أي من مكونات التطبيق، ثم يوقف العملية عند عدم الحاجة إليها أو عندما يضطر النظام إلى استرداد الذاكرة للتطبيقات الأخرى.

ينفِّذ نظام Android مبدأ الحدّ الأدنى من الأذونات المميّزة. وهذا يعني أن كل تطبيق، بشكل افتراضي، لديه إمكانية الوصول فقط إلى المكونات التي يتطلبها لأداء عمله، وليس أكثر من ذلك. وهذا يؤدي إلى إنشاء بيئة آمنة للغاية حيث لا يتمكن التطبيق من الوصول إلى أجزاء من النظام، والتي لم يتم منحه إذنًا لها.

ومع ذلك، هناك طرق يمكن للتطبيق من خلالها مشاركة البيانات مع التطبيقات الأخرى ووصول التطبيق إلى خدمات النظام:

• من الممكن ترتيب تطبيقين يتشاركان في رقم تعريف مستخدم Linux نفسه، وفي هذه الحالة يمكنهما الوصول إلى الملفات الخاصة ببعضهما البعض. للحفاظ على موارد النظام، يمكن أيضًا للتطبيقات التي لها رقم تعريف المستخدم نفسه أن تعمل على عملية Linux نفسها وتشارك الجهاز الافتراضي نفسه. ويجب أيضًا توقيع التطبيقات باستخدام الشهادة نفسها.
• يمكن لأي تطبيق طلب إذن للوصول إلى بيانات الجهاز مثل الموقع الجغرافي للجهاز والكاميرا واتصال البلوتوث. ويجب على المستخدم منح هذه الأذونات صراحةً. لمزيد من المعلومات حول الأذونات، يُرجى الاطّلاع على الأذونات على Android.

يقدم الجزء المتبقي من هذا المستند المفاهيم التالية:

• مكوّنات إطار العمل الأساسية التي تحدِّد تطبيقك.
• ملف البيان الذي تُعلن فيه عن المكوّنات وميزات الجهاز المطلوبة لتطبيقك.
• الموارد التي تكون منفصلة عن رمز التطبيق والتي تسمح لتطبيقك بتحسين سلوكه بلطف ليلائم مجموعة متنوعة من عمليات ضبط الأجهزة.

مكوّنات التطبيق

مكوّنات التطبيق هي الوحدات الأساسية لأي تطبيق Android. وكل مكوِّن هو نقطة دخول يمكن من خلالها للنظام أو المستخدم الدخول إلى تطبيقك. وتعتمد بعض المكونات على غيرها.

هناك أربعة أنواع من مكوّنات التطبيق:

• الأنشطة
• الخدمات
• أجهزة استقبال البث
• موفّرو المحتوى

يخدم كل نوع غرضًا مميزًا وله دورة حياة فريدة تحدد كيفية إنشاء المكون وتدميره. توضح الأقسام التالية الأنواع الأربعة لمكونات التطبيق.

الأنشطة

النشاط هو نقطة الدخول للتفاعل مع المستخدم. وهو يمثّل شاشة واحدة بواجهة مستخدم. على سبيل المثال، قد يحتوي تطبيق البريد الإلكتروني على نشاط يعرض قائمة بالرسائل الإلكترونية الجديدة، ونشاط آخر لإنشاء رسالة إلكترونية، ونشاط آخر لقراءة رسائل البريد الإلكتروني. على الرغم من أن الأنشطة تعمل معًا لتكوين تجربة مستخدم متماسكة في تطبيق البريد الإلكتروني، إلا أن كل منها مستقل عن الآخر.

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

يسهّل النشاط التفاعلات الرئيسية التالية بين النظام والتطبيق:

• تتبُّع ما يهم المستخدم في الوقت الحالي، أي ما يظهر على الشاشة، لكي يواصل النظام تشغيل العملية التي تستضيف النشاط.
• معرفة العمليات التي تم استخدامها سابقًا والتي تحتوي على الأنشطة المتوقّفة التي قد يعود المستخدم إليها مع إعطاء الأولوية لتلك العمليات بشكل أكبر لإبقائها متاحة
• مساعدة التطبيق في إنهاء عمليته حتى يتمكن المستخدم من العودة إلى الأنشطة مع استعادة الحالة السابقة.
• توفير طريقة للتطبيقات لتنفيذ تدفقات المستخدمين بين بعضها البعض، وضمان أن ينسّق النظام هذه المسارات. المثال الأساسي على ذلك هو المشاركة.

تنفِّذ نشاطًا كفئة فرعية من صف Activity. للحصول على مزيد من المعلومات حول الصف Activity، يُرجى الاطّلاع على مقدمة عن الأنشطة.

الخدمات

الخدمة هي نقطة دخول للأغراض العامة لإبقاء التطبيق قيد التشغيل في الخلفية لجميع أنواع الأسباب. هو مكوِّن يعمل في الخلفية لإجراء عمليات طويلة المدى أو لتنفيذ العمل في ما يتعلق بالعمليات عن بُعد. لا توفر الخدمة واجهة مستخدم.

على سبيل المثال، قد تشغّل إحدى الخدمات الموسيقى في الخلفية عندما يكون المستخدم في تطبيق مختلف، أو قد تجلب البيانات عبر الشبكة بدون حظر تفاعل المستخدم مع أحد الأنشطة. يمكن لمكوِّن آخر، مثل نشاط، بدء الخدمة والسماح بتشغيلها أو الارتباط بها للتفاعل معها.

هناك نوعان من الخدمات تخبران النظام بكيفية إدارة تطبيق: الخدمات التي تم تشغيلها والخدمات المرتبطة.

تطلب الخدمات التي تم تشغيلها من النظام الحفاظ على تشغيلها حتى اكتمال عملها. قد يكون ذلك لمزامنة بعض البيانات في الخلفية أو تشغيل الموسيقى حتى بعد مغادرة المستخدم التطبيق. تمثل مزامنة البيانات في الخلفية أو تشغيل الموسيقى أنواعًا مختلفة من الخدمات التي تم بدؤها، ويتعامل معها النظام بشكل مختلف:

• إنّ تشغيل الموسيقى هو أمر يدركه المستخدم بشكل مباشر، ويُبلغ التطبيق بذلك النظام من خلال الإشارة إلى أنه يريد أن يكون قيد التشغيل في المقدّمة، مع إرسال إشعار لإعلام المستخدم بأنّه قيد التشغيل. وفي هذه الحالة، يعطي النظام الأولوية لمواصلة عملية تشغيل تلك الخدمة، لأنّ تجربة المستخدم سيئة في حال إيقافها.
• إنّ الخدمة العادية التي تعمل في الخلفية ليست على عِلم بها مباشرةً، لذلك يوفّر النظام مزيدًا من الحرية في إدارة العملية. فقد يؤدي ذلك إلى إنهائه، أو إعادة تشغيل الخدمة في وقت لاحق، أو إعادة تشغيل الخدمة في وقت لاحق، أو عند الحاجة إلى ذاكرة وصول عشوائي خاصة بالأشياء التي تهم المستخدم بشكل فوري.

يتم تشغيل الخدمات المرتبطة لأنّ تطبيقًا آخر (أو النظام) قد طلب الاستفادة من الخدمة. توفر الخدمة المرتبطة واجهة برمجة تطبيقات لعملية أخرى، ويعرف النظام أن هناك تبعية بين هذه العمليات. لذا، إذا كانت العملية "أ" مرتبطة بخدمة في العملية "ب"، يعرف النظام أنها بحاجة إلى الحفاظ على تشغيل العملية "ب" وخدمتها من أجل التشغيل "أ". علاوة على ذلك، إذا كانت العملية "أ" أمرًا يهتم به المستخدم، فسيعرف كيفية التعامل مع العملية "ب" على أنها شيء يهتم به المستخدم أيضًا.

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

يتم تنفيذ الخدمة كفئة فرعية من Service. لمزيد من المعلومات حول الفئة Service، يُرجى الاطّلاع على نظرة عامة على الخدمات.

ملاحظة: إذا كان تطبيقك يستهدف الإصدار Android 5.0 (المستوى 21 من واجهة برمجة التطبيقات) أو إصدارًا أحدث، استخدِم الفئة JobScheduler لجدولة الإجراءات. تتمتع JobScheduler بميزة الحفاظ على البطارية من خلال جدولة المهام على النحو الأمثل لتقليل استهلاك الطاقة واستخدام واجهة برمجة التطبيقات Doze (القيلولة). للحصول على مزيد من المعلومات حول استخدام هذا الصف، راجع المستندات المرجعية لـ JobScheduler.

أجهزة استقبال البث

جهاز استقبال البث هو مكوِّن يسمح للنظام بتسليم الأحداث إلى التطبيق خارج تدفق المستخدم العادي حتى يتمكن التطبيق من الاستجابة لإعلانات البث على مستوى النظام. نظرًا لأن أجهزة استقبال البث هي إدخال آخر محدد جيدًا في التطبيق، يمكن للنظام إرسال عمليات البث حتى إلى التطبيقات غير قيد التشغيل في الوقت الحالي.

لذلك، على سبيل المثال، يمكن للتطبيق جدولة منبه لنشر إشعار لإخبار المستخدم عن حدث قادم. ولأنّ المنبّه تم تسليمه إلى BroadcastReceiver في التطبيق، لا حاجة إلى أن يظل التطبيق قيد التشغيل إلى أن ينطلق المنبّه.

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

على الرغم من أنّ أجهزة استقبال البث لا تعرض واجهة مستخدم، يمكنهم إنشاء إشعار في شريط الحالة لتنبيه المستخدم عند وقوع حدث بث. ومع ذلك، يكون جهاز استقبال البث أكثر شيوعًا من مدخل لمكوّنات أخرى وهو مخصص لتنفيذ قدر ضئيل جدًا من العمل.

على سبيل المثال، يمكن لجهاز استقبال البث جدولة JobService لتنفيذ بعض الأعمال استنادًا إلى حدث يستخدم JobScheduler. غالبًا ما تتضمّن أجهزة استقبال البث التطبيقات التي تتفاعل مع بعضها البعض، لذا من المهم الانتباه إلى الآثار الأمنية المرتبطة عند إعدادها.

يتم تنفيذ جهاز استقبال البث كفئة فرعية من BroadcastReceiver، ويتم تسليم كل عملية بث ككائن Intent. لمزيد من المعلومات، اطّلِع على صف BroadcastReceiver.

موفّرو المحتوى

يدير موفّر المحتوى مجموعة مشتركة من بيانات التطبيق التي يمكنك تخزينها في نظام الملفات، أو قاعدة بيانات SQLite، أو على الويب، أو في أي موقع تخزين دائم آخر يمكن لتطبيقك الوصول إليه. من خلال موفر المحتوى، يمكن للتطبيقات الأخرى الاستعلام عن البيانات أو تعديلها، إذا سمح مزوّد المحتوى بذلك.

على سبيل المثال، يوفر نظام Android موفّر محتوى يدير معلومات الاتصال الخاصة بالمستخدم. ويمكن لأي تطبيق لديه الأذونات المناسبة طلب بحث من موفّر المحتوى، مثل استخدام ContactsContract.Data، لقراءة معلومات عن شخص معيّن وكتابتها.

من المغري اعتبار موفر المحتوى مجرد فكرة مجرّدة في قاعدة البيانات، لأن هناك الكثير من واجهات برمجة التطبيقات والدعم المضمّن في هذه الحالة الشائعة. ومع ذلك، لها غرض أساسي مختلف من منظور تصميم النظام.

بالنسبة إلى النظام، يعتبر موفر المحتوى نقطة دخول إلى التطبيق لنشر عناصر بيانات مُسَمّاة، وتحديدها بواسطة مخطط URI. وبالتالي، يمكن للتطبيق تحديد الطريقة التي يريد بها ربط البيانات التي يحتوي عليها بمعرف URI، مع توزيع معرفات الموارد المنتظمة هذه على الكيانات الأخرى التي يمكنها بدورها استخدامها للوصول إلى البيانات. هناك بعض الأشياء المحددة التي يتيح ذلك للنظام القيام بها عند إدارة أحد التطبيقات:

• لا يتطلّب تخصيص معرّف موارد منتظم (URI) أن يظل التطبيق قيد التشغيل، لذلك يمكن أن تظل معرّفات الموارد المنتظمة (URI) بعد خروج تطبيقاتها المالكة. ولا يحتاج النظام إلا إلى التأكد من أن التطبيق المالك لا يزال قيد التشغيل عند استرداد بيانات التطبيق من معرّف الموارد المنتظم (URI) المقابل.
• وتوفر معرفات الموارد المنتظمة (URI) هذه أيضًا نموذج أمان مهمًا وبالغ الدقة. على سبيل المثال، يمكن للتطبيق وضع معرّف الموارد المنتظم (URI) لصورة لديه في الحافظة، ولكن ترك موفّر المحتوى مغلقًا بحيث لا يمكن للتطبيقات الأخرى الوصول إليه بحريّة. عندما يحاول تطبيق ثانٍ الوصول إلى معرّف الموارد المنتظم (URI) هذا في الحافظة، يمكن للنظام أن يسمح لهذا التطبيق بالوصول إلى البيانات باستخدام منح إذن معرّف موارد منتظم (URI) مؤقت، ما يتيح له الوصول إلى البيانات من خلال معرّف الموارد المنتظم هذا فقط، ولا يصل إلى أي بيانات أخرى في التطبيق الثاني.

موفرو المحتوى مفيدون أيضًا لقراءة وكتابة البيانات التي تكون خاصة بتطبيقك وغير مشاركتها.

يتم تنفيذ موفِّر المحتوى كفئة فرعية من ContentProvider، ويجب أن يستخدم مجموعة عادية من واجهات برمجة التطبيقات التي تمكّن التطبيقات الأخرى من إجراء المعاملات. للمزيد من المعلومات، يُرجى الاطّلاع على دليل مطوّري برامج موفّري المحتوى.

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

عندما يبدأ النظام تشغيل مكون، يبدأ العملية لهذا التطبيق، إذا لم يكن قيد التشغيل بالفعل، وينشئ مثيلاً للفئات المطلوبة للمكون. على سبيل المثال، إذا بدأ تطبيقك النشاط في تطبيق الكاميرا الذي يلتقط صورة، يكون هذا النشاط في العملية التي تخص تطبيق الكاميرا، وليس في عمليات التطبيق. لهذا السبب، على عكس التطبيقات في معظم الأنظمة الأخرى، لا تتضمّن تطبيقات Android نقطة إدخال واحدة، وهي عدم توفّر دالة main().

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

تفعيل المكوّنات

تفعِّل الرسالة غير المتزامنة التي تُسمى النية ثلاثة من أنواع المكوّنات الأربعة: الأنشطة والخدمات وأجهزة استقبال البث. تربط الأهداف المكوّنات الفردية ببعضها البعض في وقت التشغيل. يمكنك التفكير فيها على أنها رسائل تطلب إجراءً من مكونات أخرى، سواء كان المكون ينتمي إلى تطبيقك أو غير ذلك.

يتم إنشاء غرض باستخدام عنصر Intent الذي يحدّد رسالة لتفعيل مكوِّن معيّن (هدف صريح) أو نوع معيّن من المكوّنات (هدف ضمني).

بالنسبة إلى الأنشطة والخدمات، تحدد الغرض الإجراء المطلوب تنفيذه، مثل عرض أو إرسال عنصر، وقد يحدد معرّف الموارد المنتظم (URI) للبيانات المطلوب اتخاذ إجراء بناءً عليها، من بين أمور أخرى قد يحتاج العنصر الذي يتم تشغيله إلى معرفتها.

على سبيل المثال، قد ينقل الهدف طلبًا لنشاط لعرض صورة أو فتح صفحة ويب. في بعض الحالات، يمكنك بدء نشاط لتلقي نتيجة، وفي هذه الحالة يعرض النشاط أيضًا النتيجة في Intent. يمكنك أيضًا أن تُصدر نية للسماح للمستخدم باختيار جهة اتصال شخصية وإعادتها إليك. يتضمن الغرض من الإرجاع عنوان URL يشير إلى جهة الاتصال المحددة.

بالنسبة إلى أجهزة استقبال البث، يحدّد الغرض إعلان البث. على سبيل المثال، لا يتضمّن البث للإشارة إلى أنّ مستوى شحن بطارية الجهاز منخفضًا سوى سلسلة إجراءات معروفة تشير إلى أنّ شحن البطارية منخفض.

على عكس الأنشطة والخدمات وأجهزة استقبال البث، يتم تفعيل موفّري المحتوى عند استهدافهم من خلال طلب وارد من ContentResolver. تتعامل أداة حلّ المحتوى مع جميع المعاملات المباشرة مع موفّر المحتوى، ويطلب المكوِّن الذي ينفّذ المعاملات مع مقدّم الخدمة الطرق في الكائن ContentResolver. وهذا يترك طبقة من التجريد لأسباب تتعلق بالأمان بين موفر المحتوى والمكونات التي تطلب المعلومات.

تتوفر طرق منفصلة لتفعيل كل نوع من أنواع المكوّنات:

• يمكنك بدء نشاط أو منحه إجراءً جديدًا عن طريق تمرير Intent إلى startActivity() أو startActivityForResult() عندما تريد أن يعرض النشاط نتيجة.
• في نظام التشغيل Android 5.0 (المستوى 21 من واجهة برمجة التطبيقات) والإصدارات الأحدث، يمكنك استخدام الفئة JobScheduler لجدولة الإجراءات. بالنسبة إلى الإصدارات السابقة من Android، يمكنك بدء خدمة أو تقديم تعليمات جديدة إلى خدمة جارية حاليًا من خلال تمرير Intent إلى startService(). يمكنك الربط بالخدمة من خلال تمرير Intent إلى bindService().
• يمكنك بدء البث من خلال إدخال Intent إلى طُرق مثل sendBroadcast() أو sendOrderedBroadcast().
• يمكنك إجراء طلب بحث لموفّر محتوى عن طريق استدعاء query() على ContentResolver.

لمزيد من المعلومات عن استخدام الأغراض، يُرجى الاطّلاع على مستند فلاتر الأهداف والغايات. توفر المستندات التالية مزيدًا من المعلومات حول تفعيل مكوّنات معيّنة: مقدمة عن الأنشطة ونظرة عامة على الخدمات وBroadcastReceiver وموفّري المحتوى.

ملف البيان

قبل أن يتمكن نظام Android من بدء تشغيل مكون تطبيق، يجب أن يعرف النظام أن المكوِّن موجود من خلال قراءة ملف بيان التطبيق، AndroidManifest.xml. يعلن تطبيقك عن جميع مكوِّناته في هذا الملف، الذي يقع في جذر دليل مشروع التطبيق.

ينفذ البيان عددًا من الأشياء بالإضافة إلى التعريف بمكونات التطبيق، مثل ما يلي:

• يحدد أي أذونات مستخدم يتطلبها التطبيق، مثل الوصول إلى الإنترنت أو الوصول لقراءة جهات اتصال المستخدم.
• يذكر الحدّ الأدنى لمستوى واجهة برمجة التطبيقات الذي يطلبه التطبيق، استنادًا إلى واجهات برمجة التطبيقات التي يستخدمها التطبيق.
• يوضح ميزات الأجهزة والبرامج التي يستخدمها أو يطلبها التطبيق، مثل الكاميرا أو خدمات البلوتوث أو شاشة اللمس المتعدد.
• بيان مكتبات واجهة برمجة التطبيقات التي يجب ربط التطبيق بها (بخلاف واجهات برمجة التطبيقات لإطار عمل Android)، مثل مكتبة "خرائط Google"

تعريف المكونات

تتمثل المهمة الأساسية للبيان في إبلاغ النظام بمكونات التطبيق. على سبيل المثال، يمكن أن يعلن ملف البيان عن نشاط على النحو التالي:

<?xml version="1.0" encoding="utf-8"?>
<manifest ... >
    <application android:icon="@drawable/app_icon.png" ... >
        <activity android:name="com.example.project.ExampleActivity"
                  android:label="@string/example_label" ... >
        </activity>
        ...
    </application>
</manifest>

في العنصر <application>، تشير السمة android:icon إلى الموارد الخاصة برمز يحدد التطبيق.

في العنصر <activity>، تحدّد السمة android:name اسم الفئة المؤهل بالكامل للفئة الفرعية Activity، وتحدّد السمة android:label سلسلة لاستخدامها كتصنيف مرئي للمستخدم للنشاط.

يجب الإفصاح عن جميع مكوّنات التطبيق باستخدام العناصر التالية:

• عناصر <activity> للأنشطة
• عناصر <service> للخدمات
• عناصر <receiver> لأجهزة استقبال البث
• عناصر <provider> لمزودي المحتوى

إنّ الأنشطة والخدمات وموفّري المحتوى التي تُدرجها في مصدرك ولكن لا تذكرها في البيان غير مرئية للنظام، وبالتالي لا يمكن تشغيلها على الإطلاق. ومع ذلك، يمكن تعريف أجهزة استقبال البث في البيان أو إنشاؤها ديناميكيًا في رمز برمجي ككائنات BroadcastReceiver وتسجيلها لدى النظام عن طريق استدعاء registerReceiver().

للحصول على مزيد من المعلومات حول كيفية بنية ملف البيان لتطبيقك، يمكنك الاطّلاع على نظرة عامة على بيان التطبيق.

تعريف إمكانيات المكوِّن

كما سبق وذكرنا في قسم تفعيل المكوّنات، يمكنك استخدام علامة Intent لبدء الأنشطة والخدمات وأجهزة استقبال البث. يمكنك إجراء ذلك من خلال تسمية العنصر المستهدف بشكل صريح باستخدام اسم فئة المكوّن في الغرض. يمكنك أيضًا استخدام هدف ضمني يصف نوع الإجراء المطلوب تنفيذه، ويصف اختياريًا البيانات التي تريد تنفيذ الإجراء عليها. يتيح الغرض الضمني للنظام العثور على مكوِّن على الجهاز يمكنه تنفيذ الإجراء وبدء تشغيله. إذا كانت هناك مكونات متعددة يمكنها تنفيذ الإجراء الموضّح في الهدف، يختار المستخدم العنصر المطلوب استخدامه.

تنبيه: إذا كنت تستخدم نية لبدء Service، تأكَّد من أنّ تطبيقك آمن باستخدام هدف فاضح. يشكّل استخدام نية ضمنية لبدء الخدمة خطرًا أمنيًا، إذ لا يمكنك التأكد من الخدمة التي تستجيب للقصد ولا يمكن للمستخدم معرفة الخدمة التي تبدأ. بدءًا من Android 5.0 (المستوى 21 من واجهة برمجة التطبيقات)، يطرح النظام استثناءً في حال طلب البيانات bindService() بنيّة ضمنية. يُرجى عدم الإفصاح عن فلاتر الأهداف لخدماتك.

يحدِّد النظام المكوّنات التي يمكنها الاستجابة لهدف معيّن من خلال مقارنة النية التي يتم تلقّيها مع فلاتر النية المقدَّمة في ملف بيان التطبيقات الأخرى على الجهاز.

عند توضيح نشاط في ملف بيان تطبيقك، يمكنك اختياريًا تضمين فلاتر الأهداف التي توضِّح إمكانات النشاط كي تستجيب للغايات من التطبيقات الأخرى. يمكنك إجراء ذلك عن طريق إضافة عنصر <intent-filter> كعنصر ثانوي لعنصر تعريف المكوِّن.

على سبيل المثال، إذا أنشأت تطبيق بريد إلكتروني يتضمّن نشاطًا لإنشاء رسالة إلكترونية جديدة، يمكنك توضيح فلتر أهداف للردّ على رسائل النية "إرسال" لإرسال رسالة إلكترونية جديدة، كما هو موضّح في المثال التالي:

<manifest ... >
    ...
    <application ... >
        <activity android:name="com.example.project.ComposeEmailActivity">
            <intent-filter>
                <action android:name="android.intent.action.SEND" />
                <data android:type="*/*" />
                <category android:name="android.intent.category.DEFAULT" />
            </intent-filter>
        </activity>
    </application>
</manifest>

إذا أنشأ تطبيق آخر هدفًا من خلال إجراء ACTION_SEND وتمريره إلى startActivity()، قد يبدأ النظام نشاطك حتى يتمكّن المستخدم من إنشاء مسودة لرسالة إلكترونية وإرسالها.

ولمزيد من المعلومات عن إنشاء فلاتر الأهداف، اطّلِع على مستند فلاتر الأهداف والغايات.

الإفصاح عن متطلبات التطبيق

هناك مجموعة متنوّعة من الأجهزة التي تعمل بنظام التشغيل Android، ولا توفّر جميعها الميزات والإمكانات نفسها. لمنع تثبيت تطبيقك على الأجهزة التي تفتقر إلى الميزات التي يحتاجها تطبيقك، من المهم أن تحدِّد بوضوح ملفًا شخصيًا لأنواع الأجهزة التي يدعمها تطبيقك من خلال توضيح متطلبات الجهاز والبرامج في ملف البيان.

معظم هذه الإقرارات إعلامية فقط. لا يقرأ النظام هذه السمات، لكن بعض الخدمات الخارجية مثل Google Play يقرأها لتوفير الفلترة للمستخدمين عند البحث عن التطبيقات من أجهزتهم.

على سبيل المثال، لنفترض أن تطبيقك يتطلب كاميرا ويستخدم واجهات برمجة تطبيقات تم تقديمها في الإصدار Android 8.0 (المستوى 26 من واجهة برمجة التطبيقات). يجب الإفصاح عن هذه المتطلبات. يتم ضبط قيم minSdkVersion وtargetSdkVersion في ملف build.gradle الخاص بوحدة تطبيقك:

android {
  ...
  defaultConfig {
    ...
    minSdkVersion 26
    targetSdkVersion 29
  }
}

ملاحظة: لا تضبط minSdkVersion وtargetSdkVersion مباشرةً في ملف البيان، لأنّه يتم استبدالهما بواسطة Gradle أثناء عملية الإنشاء. لمزيد من المعلومات، يُرجى الاطِّلاع على تحديد متطلبات مستوى واجهة برمجة التطبيقات.

يجب توضيح ما يلي في ملف بيان تطبيقك عن ميزة الكاميرا:

<manifest ... >
    <uses-feature android:name="android.hardware.camera.any"
                  android:required="true" />
    ...
</manifest>

ووفقًا للبيانات الموضّحة في هذه الأمثلة، فإنّ الأجهزة التي لا تحتوي على كاميرا أو التي تعمل بالإصدار أقل من 8.0 من نظام التشغيل Android لا يمكنها تثبيت التطبيق من Google Play. ومع ذلك، يمكنك أيضًا توضيح أنّ تطبيقك يستخدم الكاميرا بدون طلب ذلك. لإجراء ذلك، يجب ضبط السمة required على false، والتحقّق في وقت التشغيل من أنّ الجهاز يتضمّن كاميرا، وإيقاف أي ميزات للكاميرا حسب الحاجة.

يتم توفير مزيد من المعلومات حول كيفية إدارة توافق تطبيقك مع الأجهزة المختلفة في نظرة عامة على توافق الأجهزة.

موارد التطبيقات

لا يتكون تطبيق Android من مجرد رموز برمجية. ويتطلب ذلك موارد منفصلة عن رمز المصدر، مثل الصور والملفات الصوتية وأي عنصر متعلق بالعرض المرئي للتطبيق. على سبيل المثال، يمكنك تحديد الصور المتحركة والقوائم والأنماط والألوان وتنسيق واجهات المستخدم الخاصة بالنشاط باستخدام ملفات XML.

يُسهِّل استخدام موارد التطبيق تحديث الخصائص المختلفة لتطبيقك بدون تعديل الكود. يتيح لك توفير مجموعات من الموارد البديلة تحسين تطبيقك ليلائم مجموعة متنوعة من إعدادات الأجهزة، مثل اللغات وأحجام الشاشات المختلفة.

بالنسبة إلى كل مورد تضيفه إلى مشروع Android، تحدد أدوات إصدار حزمة SDK معرّفًا صحيحًا فريدًا يمكنك استخدامه للإشارة إلى المورد من رمز تطبيقك أو من موارد أخرى محدّدة في ملف XML. على سبيل المثال، إذا كان تطبيقك يحتوي على ملف صورة باسم logo.png (تم حفظه في دليل res/drawable/)، ستنشئ أدوات SDK رقم تعريف مورد باسم R.drawable.logo. يرتبط رقم التعريف هذا بعدد صحيح خاص بالتطبيق، والذي يمكنك استخدامه للإشارة إلى الصورة وإدراجها في واجهة المستخدم.

تُعدّ القدرة على توفير موارد بديلة لعمليات إعداد الأجهزة المختلفة أحد أهم جوانب توفير الموارد بشكل منفصل عن رمز المصدر.

على سبيل المثال، من خلال تحديد سلاسل واجهة المستخدم في ملف XML، يمكنك ترجمة السلاسل إلى لغات أخرى وحفظ تلك السلاسل في ملفات منفصلة. بعد ذلك، يطبّق نظام التشغيل Android سلاسل اللغات المناسبة على واجهة المستخدم استنادًا إلى مؤهِّل لغة تضيفه إلى اسم دليل الموارد، مثل res/values-fr/ لقيم السلسلة الفرنسية، وإعداد لغة المستخدم.

يتوافق Android مع العديد من المؤهِّلات للموارد البديلة. المؤهِّل هو سلسلة قصيرة يمكنك تضمينها في اسم أدلة الموارد لتحديد إعدادات الجهاز التي يتم استخدام هذه الموارد من أجلها.

على سبيل المثال، يمكنك إنشاء تخطيطات مختلفة لأنشطتك بناءً على اتجاه شاشة الجهاز وحجمه. عندما تكون شاشة الجهاز في اتجاه عمودي (طويل)، قد تريد تخطيطًا يحتوي على أزرار عموديًا، ولكن عندما تكون الشاشة في اتجاه أفقي (عريض)، قد تريد محاذاة الأزرار أفقيًا. لتغيير التنسيق اعتمادًا على الاتجاه، يمكنك تحديد تخطيطين وتطبيق المؤهل المناسب على اسم دليل كل تخطيط. بعد ذلك، يطبق النظام تلقائيًا التخطيط المناسب بناءً على اتجاه الجهاز الحالي.

لمعرفة مزيد من المعلومات حول أنواع الموارد المختلفة التي يمكنك تضمينها في تطبيقك وكيفية إنشاء موارد بديلة لعمليات إعداد الأجهزة المختلفة، يُرجى الاطّلاع على نظرة عامة على موارد التطبيقات. لمعرفة المزيد من المعلومات حول أفضل الممارسات وتصميم تطبيقات فعّالة ذات جودة إنتاج، يمكنك الاطّلاع على دليل بنية التطبيقات.

مراجع إضافية

للتعرُّف على كيفية تطوير تطبيقات Android باستخدام الفيديوهات والبرامج التعليمية على الترميز، يمكنك الاطّلاع على تطوير تطبيقات Android باستخدام لغة Kotlin الدورة التدريبية Udacity.

متابعة القراءة حول:

فلاتر Intent وIntent

تعرَّف على كيفية استخدام واجهات برمجة تطبيقات Intent لتفعيل مكوّنات التطبيقات، مثل الأنشطة والخدمات، وكيفية إتاحة مكوّنات تطبيقك للاستخدام من قِبل تطبيقات أخرى.

مقدمة عن الأنشطة

تعرَّف على كيفية إنشاء مثيل من الفئة Activity التي توفّر شاشة مميّزة في تطبيقك بواجهة مستخدم.

نظرة عامة على موارد التطبيقات

تعرَّف على كيفية تنظيم تطبيقات Android لفصل موارد التطبيق عن رمز التطبيق، بما في ذلك كيفية توفير موارد بديلة لإعدادات أجهزة محدّدة.

محتوى يهمّك أيضًا:

نظرة عامة على توافق الأجهزة

تعرَّف على آلية عمل Android على الأنواع المختلفة من الأجهزة وكيفية تحسين تطبيقك بما يتناسب مع كل جهاز أو حصر مدى توفّر تطبيقك على أجهزة مختلفة.

الأذونات على Android

تعرَّف على كيفية حظر Android من الوصول إلى واجهات برمجة تطبيقات معيّنة من خلال نظام أذونات يتطلّب موافقة المستخدم على استخدام تطبيقك لواجهات برمجة التطبيقات هذه.