صورة نظام مشترَكة في Android

تعرض هذه الصفحة العديد من الآليات التي يمكن لمصنّعي الأجهزة الأصلية (OEM) التي تعمل بنظام التشغيل Android استخدامها للحصول على صورة نظام مشتركة (SSI) خاصة بهم على مستوى خطوط الإنتاج. ويقترح أيضًا إجراءً يستند إلى صورة نظام عامة (GSI) تم إنشاؤها باستخدام مشروع Android مفتوح المصدر (AOSP) لإنشاء هوية ذاتية السيادة (SSI) مملوكة من الشركة المصنّعة للمعدات الأصلية.

الخلفية

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

الحافز

كان رمز إطار العمل الذي تم إصداره في AOSP متوافقًا مع بنية Treble، كما حافظ على التوافق مع الإصدارات السابقة من عمليات التنفيذ الخاصة بالمورّدين. على سبيل المثال، يمكن تشغيل صورة نظام عامة تم إنشاؤها من مصادر Android 10 AOSP على أي جهاز متوافق مع Treble يعمل بالإصدار 8 من نظام التشغيل Android أو الإصدارات الأحدث. يتم تعديل إصدار Android الذي يتم شحنه على أجهزة المستهلكين من قِبل مورّدي نظام التشغيل على الشريحة (SoC) ومصنّعي المعدات الأصلية (OEM). (راجِع دورة إصدار Android). لم يتم تصميم هذه التغييرات والإضافات التي تم إجراؤها على إطار العمل للحفاظ على التوافق مع الإصدارات القديمة، ما أدّى إلى زيادة التعقيد وارتفاع التكلفة عند ترقية نظام التشغيل. تزيد التغييرات والتعديلات الخاصة بالجهاز من تكلفة عملية ترقية إصدار نظام التشغيل Android وتعقيدها.

قبل الإصدار 11 من نظام التشغيل Android، لم تكن هناك بنية واضحة تتيح للشركاء إنشاء إضافات معيارية لإطار عمل نظام التشغيل Android. يوضّح هذا المستند الخطوات التي يمكن لمورّدي المنظومة على الرقاقة (SoC) والمصنّعين الأصليين للأجهزة اتّخاذها لإنشاء معرّف SSI. وهذا يعني توفُّر صورة واحدة تم إنشاؤها من مصادر إطار عمل نظام التشغيل Android لإعادة استخدامها على أجهزة متعددة، وذلك للحفاظ على التوافق مع الأنظمة القديمة مع عمليات التنفيذ الخاصة بالمورّدين، ولتقليل تعقيد تكلفة ترقيات نظام التشغيل Android بشكل كبير. للاطّلاع على الخطوات المحدّدة التي يجب اتّباعها لإنشاء SSI، راجِع قسم الخطوات المقترَحة لإنشاء SSI استنادًا إلى GSI، وتذكَّر أنّه ليس عليك اتّباع جميع الخطوات الأربع. تعتمد الخطوات التي تختارها (الخطوة 1 فقط، مثلاً) على عملية التنفيذ.

نظرة عامة على SSI

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

يُرجى العِلم أنّ المصنّعين الأصليين للأجهزة ومورّدي نظام على شريحة واحدة (SoC) ينشئون واجهات SSI تتضمّن جميع الميزات والتعديلات المخصّصة التي يحتاجها المصنّع الأصلي للأجهزة. تهدف الآليات وأفضل الممارسات الواردة في هذه الصفحة إلى مساعدة الشركات المصنّعة للأجهزة الأصلية في تحقيق الأهداف الرئيسية التالية:

• إعادة استخدام معرّف SSI على عدة رموز تخزين تعريفية للأجهزة
• تحديث نظام Android باستخدام الإضافات النموذجية لتسهيل ترقيات نظام التشغيل

إنّ الفكرة الأساسية لفصل المكوّنات الخاصة بالمنتج إلى قسم المنتج تشبه فكرة Treble الخاصة بفصل المكوّنات الخاصة بنظام على شريحة إلى قسم المورّد. تتيح واجهة المنتج (مشابهة لإطار عمل VINTF) التواصل بين SSI وقسم المنتج. يُرجى العِلم أنّه في ما يتعلق بـ SSI، يشير مصطلح "المكوّنات" إلى جميع الموارد والملفات الثنائية والنصوص والمكتبات وما إلى ذلك التي يتم تثبيتها في الصور، والتي تصبح في الأساس أقسامًا.

الأقسام المتعلقة بالمعلومات الحساسة لتحديد هوية المستخدم

يوضّح الشكل 1 الأقسام حول SSI والواجهات ذات الإصدارات المختلفة في جميع الأقسام والسياسات المتعلّقة بالواجهات. يوضّح هذا القسم كل قسم وواجهة بالتفصيل.

الشكل 1. الأقسام والواجهات المتعلقة بالهوية الذاتية السيادية

الصور والأقسام

توضّح المعلومات الواردة في هذا القسم الفرق بين المصطلحَين صورة وقسم.

• الصورة هي جزء من البرامج يمكن تعديله بشكل مستقل.
• القسم هو موقع تخزين فعلي يمكن تعديله بشكل مستقل.

يتم تحديد الأقسام في الشكل 1 على النحو التالي:

• صورة النظام الموقّع (SSI): صورة النظام الموقّع هي الصورة الشائعة لدى المصنّع الأصلي للجهاز، ويمكن أن تكون متوفّرة على أجهزة متعددة. لا يحتوي على أي مكونات خاصة بالأجهزة أو المنتجات. وبحسب التعريف، تتم مشاركة كل ما يتضمّنه معرّف SSI معيّن بين جميع الأجهزة التي تستخدم هذا المعرّف. يتألف SSI من صورة واحدة /system أو من صورة /system وقسمَي /system_ext، كما هو موضّح في الشكل 1.

  • يحتوي القسم /system على مكونات مستندة إلى مشروع Android المفتوح المصدر (AOSP)، بينما يحتوي القسم /system_ext، عند تنفيذه، على إضافات ومكونات خاصة بمصنّعي المعدات الأصلية ومورّدي شرائح النظام (SoC) تكون مرتبطة بإحكام بمكونات AOSP. على سبيل المثال، تتناسب مكتبة إطار عمل Java الخاصة بمصنّع المعدات الأصلية والتي توفّر واجهات برمجة تطبيقات مخصّصة لتطبيقات مصنّع المعدات الأصلية بشكل أفضل مع قسم /system_ext مقارنةً بقسم /system. يتم إنشاء محتوى كل من القسمين /system و/system_ext من مصادر Android المعدَّلة من قِبل المصنّع الأصلي للجهاز.

  • إنّ قسم /system_ext اختياري، ولكن من المفيد استخدامه لأي ميزات وإضافات مخصّصة مرتبطة بإحكام بمكوّنات مستندة إلى AOSP. يساعدك هذا التمييز في تحديد التغييرات التي عليك إجراؤها لنقل هذه المكوّنات من القسم /system_ext إلى القسم /product على مدار فترة زمنية.

• المنتج: مجموعة من المكوّنات الخاصة بالمنتج أو الجهاز والتي تمثّل التعديلات والإضافات التي يجريها المصنّع الأصلي للجهاز على نظام التشغيل Android. ضَع المكوّنات الخاصة بنظام SoC في القسم /vendor. يمكن لمورّدي نظام على شريحة (SoC) استخدام /product القسم للمكوّنات المناسبة، مثل المكوّنات المستقلة عن نظام على شريحة. على سبيل المثال، إذا كان مورّد نظام على شريحة (SoC) يقدّم مكونًا مستقلاً عن النظام على شريحة لعملائه من مصنّعي المعدات الأصلية (OEM) (وهو مكون اختياري يمكن شحنه مع المنتج)، يمكن لمورّد النظام على شريحة وضع هذا المكون في صورة المنتج. لا يتم تحديد موقع المكوّن حسب ملكيته، بل حسب الغرض منه.

• المورّد: مجموعة من المكوّنات الخاصة بنظام على شريحة واحدة.

• تصميم وتصنيع المعدات الأصلية (ODM): مجموعة من المكوّنات الخاصة باللوحة والتي لا يوفّرها نظام SoC. وعادةً ما يملك مورّد نظام SoC صورة المورّد، بينما يملك صانع الجهاز صورة تصميم وتصنيع المعدات الأصلية (ODM). في حال عدم توفّر قسم /odm منفصل، يتم دمج صور مورّد نظام التشغيل على الشريحة (SoC) وصور الشركة المصنّعة للجهاز الأصلي (ODM) معًا في القسم /vendor.

الواجهات بين الصور

تتوفّر واجهتان رئيسيتان لصور البائعين والمنتجات حول تقنية SSI:

• واجهة المورّد (VINTF): VINTF هي الواجهة الخاصة بالمكوّنات التي تتضمّنها صور المورّد وODM. لا يمكن للمكوّنات الموجودة في صور المنتج والنظام التفاعل مع صور المورّد والشركة المصنّعة للتصميم الأصلي إلا من خلال هذه الواجهة. على سبيل المثال، لا يمكن أن تعتمد صورة المورّد على جزء خاص من صورة النظام، والعكس صحيح. تم تحديد ذلك في الأصل في Project Treble، الذي قسّم الصور إلى أقسام خاصة بالنظام وأخرى خاصة بالمورّد. يتم وصف الواجهة باستخدام الآليات التالية:

  • HIDL (لا يتوفّر Passthrough HAL إلا للوحدتَين system وsystem_ext)
  • Stable AIDL
  • الإعدادات
    • System properties API
    • Config file schema API
  • VNDK
  • واجهات برمجة التطبيقات في حزمة تطوير البرامج لنظام التشغيل Android
  • مكتبة Java SDK

• واجهات المنتج: واجهة المنتج هي الواجهة بين SSI وصورة المنتج. يؤدي تحديد واجهة ثابتة إلى فصل مكوّنات المنتج عن مكوّنات النظام في SSI. تتطلّب واجهة المنتج واجهات مستقرة مماثلة لواجهة VINTF. ومع ذلك، لا يتم فرض استخدام واجهات برمجة التطبيقات الخاصة بحزمة تطوير البرامج (SDK) لنظام التشغيل Android وVNDK إلا على الأجهزة التي تعمل بالإصدار 11 من نظام التشغيل Android (والإصدارات الأحدث).

تفعيل ميزة "التعريف الذاتي" في Android 11

يوضّح هذا القسم كيفية استخدام الميزات الجديدة المتاحة لدعم ميزة SSI في نظام التشغيل Android 11.

قسم /system_ext

تم طرح القسم /system_ext في نظام التشغيل Android 11 كقسم اختياري. (وهو المكان المخصّص للمكوّنات غير التابعة لمشروع Android المفتوح المصدر (AOSP) والمرتبطة بشكل وثيق بالمكوّنات المحدّدة في مشروع Android المفتوح المصدر (AOSP) في القسم /system). يُفترض أنّ القسم /system_ext هو إضافة خاصة بالمصنّع الأصلي للجهاز إلى القسم /system ، بدون تحديد واجهة بين القسمَين. يمكن للمكوّنات في القسم /system_ext إجراء طلبات خاصة إلى واجهة برمجة التطبيقات في القسم /system، ويمكن للمكوّنات في القسم /system إجراء طلبات خاصة إلى واجهة برمجة التطبيقات في القسم /system_ext.

ونظرًا لأنّ القسمَين مرتبطان بإحكام، يتم ترقيتهما معًا عند طرح إصدار جديد من Android. لا يشترط أن يكون /system_ext القسم الذي تم إنشاؤه للإصدار السابق من Android متوافقًا مع القسم /system في إصدار Android التالي.

لتثبيت وحدة على القسم /system_ext، أضِف system_ext_specific: true إلى الملف Android.bp. بالنسبة إلى الأجهزة التي لا تحتوي على قسم /system_ext، ثبِّت هذه الوحدات في الدليل الفرعي ./system_ext ضمن القسم /system.

السجلّ

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

ومع ذلك، يكون القسم /system_ext مفيدًا للحفاظ على القسم /system قريبًا من مشروع Android المفتوح المصدر (AOSP) قدر الإمكان. باستخدام SSI، يتم استثمار معظم جهد الترقية في المكوّنات الموجودة في قسمَي /system و/system_ext. عند إنشاء صورة النظام من مصادر مشابهة قدر الإمكان لتلك الموجودة في مشروع Android مفتوح المصدر (AOSP)، يمكنك تركيز جهود الترقية على صورة system_ext.

إلغاء تجميع المكوّنات من الأقسام ‎ /system و‎ /system_ext في القسم ‎ /product

قدّمت الإصدار 9 من نظام التشغيل Android قسم /product مرتبطًا بقسم /system. تستخدم الوحدات في قسم /product موارد النظام بدون أي قيود، والعكس صحيح. لإتاحة SSI في Android 10، يتم تقسيم مكونات المنتج إلى قسمَي /system_ext و/product. لا يجب أن يلتزم قسم /system_ext بالقيود المفروضة على استخدام مكونات النظام التي كان يلتزم بها قسم /product في Android 9. بدءًا من Android 10، يجب فصل /product القسم عن القسم /system، ويجب أن يستخدم واجهات ثابتة من القسمين /system و/system_ext.

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

لفصل قسم /product عن مكونات النظام، يجب أن يتضمّن قسم /product سياسة التنفيذ نفسها التي يتضمّنها قسم /vendor الذي تم فصله مسبقًا باستخدام Project Treble.

بدءًا من Android 11، يتم فرض استخدام واجهات Java والأصلية لقسم /product كما هو موضّح أدناه. لمزيد من المعلومات، يُرجى الاطّلاع على فرض استخدام واجهات أقسام المنتجات.

• واجهات برمجة التطبيقات الأصلية: يجب فصل الوحدات الأصلية في القسم /product عن الأقسام الأخرى. التبعيات المسموح بها فقط من وحدات المنتج هي بعض مكتبات VNDK (بما في ذلك LLNDK) من قسم /system. يجب أن تكون مكتبات JNI التي تعتمد عليها تطبيقات المنتج هي مكتبات NDK.
• واجهات Java: لا يمكن لوحدات Java (التطبيق) في القسم /product استخدام واجهات برمجة التطبيقات المخفية لأنّها غير ثابتة. يجب أن تستخدم هذه الوحدات النمطية واجهات برمجة التطبيقات العامة وواجهات برمجة تطبيقات النظام من القسم /system فقط، ومكتبات حزمة تطوير البرامج (SDK) للغة Java في القسم /system أو القسم /system_ext. يمكنك تحديد مكتبات حزمة تطوير البرامج (SDK) للغة Java لواجهات برمجة التطبيقات المخصّصة.

الخطوات المقترَحة لاستخدام SSI المستند إلى GSI

الشكل 2. الأقسام المقترَحة لـ SSI المستندة إلى مؤشر البحث الثانوي العام

صورة النظام العامة (GSI) هي صورة النظام التي يتم إنشاؤها مباشرةً من مشروع Android مفتوح المصدر (AOSP). ويتم استخدامها في اختبارات التوافق مع Treble (مثل CTS-on-GSI)، كما أنّها تمثّل منصة مرجعية يمكن لمطوّري التطبيقات استخدامها لاختبار توافق تطبيقاتهم عندما لا يتوفّر لديهم جهاز حقيقي يعمل بإصدار Android المطلوب.

يمكن لمصنّعي المعدات الأصلية أيضًا استخدام GSI لإنشاء SSI. كما هو موضّح في الصور والأقسام، تتألف صورة النظام المشتركة من صورة النظام للمكوّنات المحدّدة في مشروع Android مفتوح المصدر (AOSP) وصورة system_ext للمكوّنات المحدّدة من قِبل الشركة المصنّعة للجهاز الأصلي. عند استخدام صورة GSI كصورة system، يمكن لمصنّع المعدات الأصلية التركيز على صورة system_ext لإجراء عملية الترقية.

يقدّم هذا القسم دليلاً لمصنّعي المعدات الأصلية الذين يريدون تقسيم التخصيصات إلى وحدات في القسمَين /system_ext و/product أثناء استخدام صورة نظام AOSP أو صورة نظام مشابهة لنظام AOSP. إذا أنشأ مصنّعو المعدات الأصلية صورة النظام من مصادر AOSP، يمكنهم استبدال صورة النظام التي أنشأوها بصورة GSI التي يوفّرها AOSP. ومع ذلك، ليس على الشركات المصنّعة للأجهزة الأصلية الوصول إلى الخطوة الأخيرة (استخدام صورة النظام العامة كما هي) دفعة واحدة.

الخطوة 1: استخدام generic_system.mk لصورة نظام المصنّع الأصلي للجهاز (OEM GSI)

من خلال وراثة generic_system.mk (الذي كان يُطلق عليه الاسم mainline_system.mk في Android 11، وتمت إعادة تسميته إلى generic_system.mk في AOSP)، تتضمّن صورة النظام (OEM GSI) جميع الملفات التي تتضمّنها صورة AOSP GSI. ويمكن للمصنّعين الأصليين للأجهزة تعديل هذه الملفات، وبالتالي يمكن أن يحتوي إصدار GSI الخاص بالمصنّع الأصلي للجهاز على ملفات خاصة بالمصنّع الأصلي للجهاز بالإضافة إلى ملفات AOSP GSI. ومع ذلك، لا يُسمح لمصنّعي المعدات الأصلية بتعديل ملف generic_system.mk نفسه.

الشكل 3. استخدام generic_system.mk لصورة نظام الشركة المصنّعة للجهاز الأصلي

الخطوة 2: يجب أن تتضمّن حزمة GSI الخاصة بمصنّع المعدات الأصلية قائمة الملفات نفسها التي تتضمّنها حزمة GSI الخاصة بنظام التشغيل AOSP

لا يمكن أن يحتوي حزمة GSI الخاصة بمصنّع المعدات الأصلية على ملفات إضافية في هذه المرحلة. يجب نقل ملفات المصنّع الأصلي للأجهزة (OEM) المحمية بحقوق الملكية إلى القسم system_ext أو product.

الشكل 4. نقل الملفات المُضافة خارج حزمة GSI الخاصة بمصنّع المعدات الأصلية

الخطوة 3: تحديد قائمة السماح للحدّ من الملفات المعدَّلة في حزمة GSI الخاصة بمصنّع المعدات الأصلية

للتحقّق من الملفات المعدَّلة، يمكن لمصنّعي المعدات الأصلية استخدام أداة compare_images ومقارنة صورة نظام GSI من AOSP بصورة نظام GSI من مصنّع المعدات الأصلية. احصل على صورة نظام GSI من AOSP من خلال استهداف AOSP lunch generic_system_*.

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

الشكل 5. تحديد قائمة السماح لتقليل قائمة الملفات المعدَّلة في حزمة GSI الخاصة بمصنّع المعدات الأصلية

الخطوة 4: يجب أن تحتوي حزمة GSI الخاصة بمصنّع المعدات الأصلية على حِزم ثنائية مماثلة لحزمة GSI الخاصة بمشروع Android المفتوح المصدر

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

الشكل 6. جعل حِزم GSI الخاصة بمصنّعي المعدات الأصلية تتضمّن حِزمًا ثنائية مماثلة لحِزم GSI الخاصة بمشروع Android المفتوح المصدر

تحديد SSI لمصنّعي المعدات الأصلية

حماية قسم /system في وقت الإنشاء

لتجنُّب أي تغييرات خاصة بالمنتج في القسم /system وتحديد OEM GSI، يمكن لمصنّعي المعدات الأصلية استخدام ماكرو makefile يُسمى require-artifacts-in-path لمنع أي تعريف لوحدات النظام بعد استدعاء الماكرو. اطّلِع على مثال على إنشاء ملف makefile وتفعيل خيار التحقّق من مسار العنصر.

يمكن للمصنّعين الأصليين للأجهزة تحديد قائمة للسماح بتثبيت الوحدات الخاصة بالمنتج في القسم /system مؤقتًا. ومع ذلك، يجب أن تكون القائمة فارغة لجعل صورة GSI الخاصة بمصنّع المعدات الأصلية (OEM) مشتركة بين جميع منتجات المصنّع. تُستخدم هذه العملية لتحديد حزمة GSI الخاصة بمصنّع المعدات الأصلية، ويمكن أن تكون مستقلة عن خطوات حزمة GSI الخاصة بمشروع AOSP.

فرض استخدام واجهات المنتجات

لضمان عدم تجميع قسم /product، يمكن لمصنّعي المعدات الأصلية التأكّد من أنّ أجهزتهم تفرض واجهات المنتج من خلال ضبط PRODUCT_PRODUCT_VNDK_VERSION:= current للوحدات الأصلية وPRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE:= true لوحدات Java. يتم ضبط هذه المتغيّرات تلقائيًا إذا كانت قيمة PRODUCT_SHIPPING_API_LEVEL للجهاز أكبر من أو تساوي 30. للحصول على معلومات تفصيلية، يُرجى الاطّلاع على فرض استخدام واجهات أقسام المنتجات.

جعل قسم /system_ext مشتركًا

قد يختلف قسم /system_ext بين الأجهزة، لأنّه يمكن أن يتضمّن وحدات خاصة بالجهاز ومضمّنة في النظام. بما أنّ SSI يتألف من قسمَي /system و/system_ext، فإنّ الاختلافات في قسم /system_ext تمنع الشركات المصنّعة للأجهزة الأصلية من تحديد SSI. يمكن لمصنّعي المعدات الأصلية الحصول على معرّف SSI خاص بهم ومشاركته بين أجهزة متعددة من خلال إزالة أي اختلافات وجعل قسم /system_ext مشتركًا.

يقدم هذا القسم اقتراحات لجعل القسم /system_ext شائعًا.

عرض واجهات برمجة التطبيقات المخفية في قسم النظام

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

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

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

تضمين المجموعة الفائقة من جميع حِزم APK وتخطّي بعض عمليات تثبيت الحِزم لكل جهاز

بعض الحِزم المضمّنة في النظام ليست شائعة على جميع الأجهزة. قد يكون من الصعب فصل وحدات حِزم APK هذه ونقلها إلى قسم المنتج أو قسم المورّد. كحلّ مؤقت، يمكن لمصنّعي المعدات الأصلية تضمين جميع الوحدات في SSI، ثم فلترة الوحدات غير المرغوب فيها باستخدام سمة رمز التخزين التعريفي (ro.boot.hardware.sku). لاستخدام الفلتر، يضع مصنّعو المعدات الأصلية موارد إطار العمل config_disableApkUnlessMatchedSku_skus_list وconfig_disableApksUnlessMatchedSku_apk_list.

للحصول على إعدادات أكثر دقة، عليك تعريف مستقبِل بث يوقف الحِزم غير الضرورية. يطلب برنامج استقبال البث setApplicationEnabledSetting إيقاف الحزمة عند تلقّي الرسالة ACTION_BOOT_COMPLETED.

تحديد RRO بدلاً من استخدام تراكب الموارد الثابتة

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

PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty

إذا كان الإعداد التفصيلي مطلوبًا، حدِّد RRO يدويًا بدلاً من الاعتماد على RRO تم إنشاؤه تلقائيًا. للحصول على معلومات تفصيلية، يُرجى الاطّلاع على تراكبات موارد وقت التشغيل (RRO). يمكن لمصنّعي المعدات الأصلية أيضًا تحديد عمليات RRO شرطية تعتمد على سمات النظام باستخدام السمتَين android:requiredSystemPropertyName وandroid:requiredSystemPropertyValue.

الأسئلة الشائعة

هل يمكنني تحديد عدة معرّفات SSI؟

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

هل يمكنني تعديل generic_system.mk (mainline_system.mk) لصورة نظام عامة (GSI) خاصة بمصنّع المعدات الأصلية؟

لا، ولكن يمكن لمصنّعي المعدات الأصلية تحديد ملف makefile جديد خاص بنظام GSI الخاص بهم يرث الملف generic_system.mk واستخدام ملف makefile الجديد بدلاً منه. للاطّلاع على مثال، راجِع فرض استخدام واجهات أقسام المنتجات.

هل يمكنني إزالة الوحدات النمطية من generic_system.mk التي تتعارض مع عملية التنفيذ؟

لا، يحتوي GSI على مجموعة الحد الأدنى من الوحدات القابلة للتشغيل والاختبار. إذا كنت تعتقد أنّ أحد الوحدات ليس ضروريًا، يُرجى الإبلاغ عن خطأ لتعديل الملف generic_system.mk في مشروع AOSP.