صورة نظام Android التي تمت مشاركتها

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

خلفية

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

الحافز

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

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

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

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

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

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

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

الأقسام حول SSI

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

الأقسام والواجهات حول مخطّط الكتلة لوحدة التحكّم في حدود الجلسة

الشكل 1: الأقسام والواجهات حول SSI

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

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

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

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

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

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

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

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

  • المورّد: مجموعة من المكوّنات الخاصة بوحدة المعالجة المركزية (SoC).

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

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

تتوفّر واجهتان رئيسيتان لصور المورّدين والمنتجات في SSI:

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

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

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

تفعيل SSI في Android 11

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

قسم ‎ /system_ext

تم تقديم قسم /system_ext في Android 11 كقسم اختياري. (إنّه المكان المخصّص للمكونات غير التابعة لمشروع AOSP والتي تتضمّن ربطًا وثيقًا بالمكونات المحدّدة في مشروع 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 أقرب ما يمكن إلى AOSP. باستخدام SSI، يتم توجيه معظم جهد الترقية إلى المكونات في قسمَي /system و/system_ext. عند إنشاء صورة النظام من مصادر مشابهة قدر الإمكان لتلك الواردة في AOSP، يمكنك تركيز جهود الترقية على صورة system_ext.

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

أضاف نظام التشغيل Android 9 قسم /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

الأقسام المقترَحة لميزة SSI المستندة إلى GSI

الشكل 2: الأقسام المقترَحة لميزة SSI المستندة إلى GSI

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

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

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

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

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

اكتساب ملف generic_system.mk لصورة نظام المصنّع الأصلي للجهاز

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

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

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

نقل الملفات المُضافة خارج حِزمة GSI الخاصة بصانع الجهاز

الشكل 4: نقل الملفات المُضافة خارج حِزمة GSI الخاصة بصانع الجهاز

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

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

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

تحديد قائمة مسموح بها لتقليل قائمة الملفات المعدَّلة في مبادرة GSI الخاصة بجهات التصنيع

الشكل 5: تحديد قائمة مسموح بها لتقليل قائمة الملفات المعدَّلة في مبادرة GSI الخاصة بجهات التصنيع

الخطوة 4: أن يتضمّن ملف GSI من المصنّع الأصلي للجهاز الثنائيات نفسها التي يتضمّنها ملف GSI من AOSP

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

أن يتضمّن ملف GSI من المصنّع الأصلي للجهاز الثنائيات نفسها التي يتضمّنها ملف GSI من AOSP

الشكل 6: جعل حِزم البرامج القابلة للتشغيل (GSI) الخاصة بجهات التصنيع تتضمّن حِزم البرامج القابلة للتشغيل نفسها التي تتضمّنها حِزم البرامج القابلة للتشغيل (GSI) من AOSP

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

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

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

يمكن للمصنّعين الأصليين للأجهزة تحديد قائمة للسماح بتثبيت وحدات خاصة بالمنتج في قسم /system مؤقتًا. ومع ذلك، يجب أن تكون القائمة فارغة لجعل ملف تعريف المصنّع الأصلي للجهاز GSI شائعًا في جميع منتجات المصنّع الأصلي للجهاز. هذه العملية مخصّصة لتحديد ملف 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 خاص بهم ويمكنهم مشاركة ملف 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 وإعدادها بشكلٍ سليم. من خلال ضبط السمات على النحو التالي، يمكن لمصنّعي المعدّات الأصلية الحصول على جميع التراكب التي يتم إنشاؤها تلقائيًا بصفتها تطبيقات مضمّنة في نظام التشغيل.

PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty

إذا كانت هناك حاجة إلى إعدادات تفصيلية، حدِّد مسار إعادة توجيه مخصّصًا يدويًا بدلاً من الاعتماد على مسار تم إنشاؤه تلقائيًا. للحصول على معلومات تفصيلية، يُرجى الاطّلاع على Runtime Resource Overlays (RROs). يمكن لمصنّعي المعدّات الأصلية أيضًا تحديد عمليات التثبيت من مصدر غير معروف مشروطة تعتمد على سمات النظام من خلال استخدام السمتَين 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.