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

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

خلفية

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

الحافز

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

قبل Android 11، لم تكن هناك بنية واضحة تتيح للشركاء إنشاء إضافات وحدات إلى إطار عمل نظام التشغيل Android. يوضّح هذا المستند الخطوات التي يمكن لبائعي شرائح المنظومة المتكاملة (SoC) والمصنّعين الأصليّين للأجهزة اتّخاذها لإنشاء 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، والواجهات التي تتضمّن إصدارات مختلفة على مستوى الأقسام والسياسات على الواجهات. يشرح هذا القسم كل قسم من الأقسام والواجهات بالتفصيل.

الأقسام والواجهات حول مخطط كتلة 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) يقدّم مكوّنًا مستقلاً عن شريحة المعالجة المركزية لعملاء المصنّعين الأصليّين للأجهزة (وهو شحن اختياري مع المنتج)، يمكن لمورّد شريحة المعالجة المركزية وضع هذا المكوّن في صورة المنتج. لا يتم تحديد موقع المكوّن من خلال ملكيته، بل يتم تحديده من خلال الغرض منه.

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

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

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

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

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

    • HIDL (لا يتوفّر نظام HAL العبور إلا لوحدتَي system وsystem_ext)
    • لغة AIDL ثابتة
    • الإعدادات
      • واجهة برمجة تطبيقات خصائص النظام
      • واجهة برمجة التطبيقات لملف المخطّط
    • 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)، تتضمّن صورة النظام (OEM GSI) جميع الملفات المتوفرة في AOSP GSI. يمكن لمصنّعي الأجهزة الأصليين تعديل هذه الملفات، بحيث يمكن أن تحتوي حِزم GSI الخاصة بالمصنّعين الأصليين للأجهزة على ملفات ملكية للمصنّعين الأصليين للأجهزة بالإضافة إلى ملفات AOSP GSI. ومع ذلك، لا يُسمح لمصنّعي المعدّات الأصلية بتعديل ملف generic_system.mk نفسه.

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

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

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

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

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

الشكل 4: نقل الملفات المضافة خارج GSI من المصنّع الأصلي للجهاز

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

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

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

تحديد قائمة مسموح بها لتقليل قائمة الملفات المعدَّلة في مبادرة 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 الخاص بصانع جهاز أصلي؟

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

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

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