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

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

خلفية

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

تحفيز

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

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

نظرة عامة على مباحث أمن الدولة

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

لاحظ أن مصنعي المعدات الأصلية وبائعي SoC ينشئون مباحث أمن الدولة التي تتضمن كافة الميزات والتعديلات المخصصة التي يحتاجها مصنع المعدات الأصلية. إن الآليات وأفضل الممارسات المتوفرة في هذه الصفحة مخصصة لمصنعي المعدات الأصلية لاستخدامها للوصول إلى هذه الأهداف الرئيسية:

  • أعد استخدام SSI عبر وحدات SKU المتعددة للأجهزة.
  • قم بتحديث نظام Android باستخدام الامتدادات المعيارية لتسهيل ترقيات نظام التشغيل.

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

أقسام حول مباحث أمن الدولة

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

Partitions and interfaces around SSI block diagram

الشكل 1. الأقسام والواجهات حول مباحث أمن الدولة

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

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

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

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

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

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

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

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

  • البائع : مجموعة من المكونات الخاصة بـ SoC.

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

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

توجد واجهتان رئيسيتان لصور البائع والمنتج حول SSI:

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

    • HIDL (العبور HAL متاح فقط لوحدات system و system_ext )
    • AIDL مستقر
    • التكوينات
      • واجهة برمجة تطبيقات خصائص النظام
      • واجهة برمجة تطبيقات مخطط ملف التكوين
    • فندك
    • واجهات برمجة تطبيقات Android SDK
    • مكتبة جافا SDK

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

تمكين SSI في Android 11

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

القسم /system_ext

تم تقديم القسم /system_ext في Android 11 كقسم اختياري. (إنه المكان المناسب للمكونات غير التابعة لـ AOSP والتي لها اقتران محكم مع المكونات المحددة بواسطة AOSP في قسم /system .) من المفترض أن يكون القسم /system_ext هو الامتداد الخاص بـ OEM لقسم /system ، بدون واجهة محددة عبر القسمين. يمكن للمكونات الموجودة في القسم /system_ext إجراء استدعاءات API خاصة في القسم /system ، ويمكن للمكونات الموجودة في القسم /system إجراء استدعاءات API خاصة إلى القسم /system_ext .

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

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

تاريخ

فيما يلي بعض المحفوظات حول القسم /system_ext . كان هدف التصميم هو وضع كافة المكونات الخاصة بـ OEM، بغض النظر عما إذا كانت شائعة، في قسم /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 ، ومكتبات Java SDK في القسم /system أو /system_ext . يمكنك تحديد مكتبات Java SDK لواجهات برمجة التطبيقات المخصصة.

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

Suggested partitions for GSI-based SSI

الشكل 2. الأقسام المقترحة لمباحث أمن الدولة المستندة إلى GSI

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

يمكن لمصنعي المعدات الأصلية أيضًا استخدام GSI لصنع SSI الخاص بهم. كما هو موضح في الصور والأقسام ، يتكون SSI من صورة النظام للمكونات المعرفة من قبل AOSP وصورة system_ext للمكونات المعرفة من قبل OEM. عند استخدام GSI كصورة system ، يمكن لـ OEM التركيز على صورة system_ext للترقية.

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

الخطوة 1. وراثة generic_system.mk لصورة نظام OEM (OEM GSI)

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

Inheriting `generic_system.mk` for OEM system image

الشكل 3. وراثة generic_system.mk لصورة نظام OEM

الخطوة 2. جعل OEM GSI يحتوي على نفس قائمة الملفات مع AOSP GSI

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

Moving added files out of the OEM GSI

الشكل 4. نقل الملفات المضافة من OEM GSI

الخطوة 3. تحديد القائمة المسموح بها للحد من الملفات المعدلة في OEM GSI

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

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

Define an allowlist to reduce the list of modified files in OEM GSI

الشكل 5. حدد القائمة المسموح بها لتقليل قائمة الملفات المعدلة في OEM GSI

الخطوة 4. جعل OEM GSI له نفس الثنائيات مثل AOSP GSI

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

Make OEM GSI have the same binaries as AOSP GSI

الشكل 6. جعل OEM GSI له نفس الثنائيات مثل AOSP GSI

تعريف SSI لمصنعي المعدات الأصلية

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

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

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

فرض واجهات المنتج

لضمان أن قسم /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 يتضمن كافة الوحدات، ثم تصفية الوحدات غير المرغوب فيها باستخدام خاصية SKU ( ro.boot.hardware.sku ). لاستخدام عامل التصفية، يقوم مصنعو المعدات الأصلية بتراكب موارد إطار العمل config_disableApkUnlessMatchedSku_skus_list و config_disableApksUnlessMatchedSku_apk_list .

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

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

يعالج تراكب الموارد الثابت الحزم المتراكبة. ومع ذلك، يمكن أن يعيق تحديد SSI، لذا تأكد من تشغيل خصائص RRO وتعيينها بشكل صحيح. من خلال تعيين الخصائص على النحو التالي، يمكن لمصنعي المعدات الأصلية الحصول على جميع التراكبات التي تم إنشاؤها تلقائيًا كـ RROs.

PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty

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

أسئلة وأجوبة (FAQ)

هل يمكنني تحديد عدة مباحث أمن الدولة؟

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

هل يمكنني تعديل generic_system.mk ( mainline_system.mk ) لـ OEM GSI؟

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

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

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