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

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

خلفية

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

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

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

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

لمعرفة تفاصيل التنفيذ، يُرجى الاطّلاع على الخطوات المقترَحة لصورة نظام مشتركة مستندة إلى صورة نظام عامة. الخطوات نموذجية، ويمكنك اختيار تنفيذ مراحل معيّنة (مثل الخطوة 1: استخدام generic_system.mk لصورة نظام المصنّع الأصلي للأجهزة (OEM GSI)) بدلاً من جميع المراحل، وذلك استنادًا إلى البنية.

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

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

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

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

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

الأقسام حول صورة النظام المشتركة

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

الشكل 1: الأقسام والواجهات حول صورة النظام المشتركة

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

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

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

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

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

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

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

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

قسم /system_ext

قسم /system_ext اختياري. استخدِم هذا القسم لأي ميزات وعمليات توسيع مخصّصة مرتبطة بإحكام بالمكوّنات المستندة إلى AOSP. يُفترض أنّ هذا القسم هو عملية التوسيع الخاصة بالمصنّع الأصلي للأجهزة لقسم /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. كان هدف صورة النظام المشتركة هو إزالة قسم /system_ext في النهاية.

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

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

تتوفّر واجهتان رئيسيتان لصور المورّد والمنتج حول صورة النظام المشتركة:

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

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

• واجهات المنتج: هي الواجهة بين صورة النظام المشتركة وصورة المنتج. يؤدي تحديد واجهة مستقرة إلى فصل مكوّنات المنتج عن مكوّنات النظام في صورة نظام مشتركة.

تفعيل صورة النظام المشتركة

يوضّح هذا القسم كيفية إتاحة صورة النظام المشتركة في Android 11 والإصدارات الأحدث.

إزالة حزم المكوّنات

لإزالة حزمة قسم /product من مكوّنات النظام، يجب أن يكون لقسم /product سياسة الإنفاذ نفسها التي تم إزالتها من قسم /vendor باستخدام Mainline.

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

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

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

الخطوات المقترَحة لصورة نظام مشتركة مستندة إلى صورة نظام عامة

الشكل 2: الأقسام المقترَحة لصورة نظام مشتركة مستندة إلى صورة نظام عامة

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

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

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

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

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

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

الخطوة 2: التأكّد من أنّ صورة النظام العامة للمصنّع الأصلي للأجهزة تحتوي على قائمة الملفات نفسها التي تحتوي عليها صورة النظام العامة في AOSP

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

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

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

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

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

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

الخطوة 4: التأكّد من أنّ صورة النظام العامة للمصنّع الأصلي للأجهزة تحتوي على الملفات الثنائية نفسها التي تحتوي عليها صورة النظام العامة في AOSP

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

الشكل 6: التأكّد من أنّ صورة النظام العامة للمصنّع الأصلي للأجهزة تحتوي على الملفات الثنائية نفسها التي تحتوي عليها صورة النظام العامة في AOSP

تحديد صورة النظام المشتركة

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

حماية قسم /system في مدّة التصميم

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

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

جعل قسم /system_ext شائعًا

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

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

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

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

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

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

استبدال إيقاف التطبيقات الخاصة برمز التخزين التعريفي

أوقف Android 16 نهائيًا الآلية القديمة لإيقاف حِزم APK بشكل انتقائي استنادًا إلى رمز التخزين التعريفي للأجهزة باستخدام تراكبات موارد إطار العمل (config_disableApksUnlessMatchedSku_apk_list وconfig_disableApkUnlessMatchedSku_skus_list) وأزالها. لمعرفة التفاصيل، يُرجى الاطّلاع على aosp/3444399.

البديل المقترَح هو استخدام إعداد النظام install-in-user-type ضِمن الأدلة الخاصة برمز التخزين التعريفي. يمنع هذا النهج تثبيت الحزمة لأي مستخدم على رمز تخزين تعريفي معيّن، بدلاً من مجرد إيقافها بعد التثبيت.

1. أدرِج جميع حِزم APK (المجموعة الفرعية لجميع التطبيقات المحتمَلة لجميع رموز التخزين التعريفية في صورة النظام) في الصورة، عادةً في قسم /product.

2. تأكّد من ضبط رمز التخزين التعريفي للجهاز بشكل صحيح في سمة النظام ro.boot.hardware.sku (التي يستخدمها النظام لتحديد رمز التخزين التعريفي للجهاز في وقت التشغيل).

3. أنشِئ أدلة فرعية خاصة برمز التخزين التعريفي ضمن /product/etc/sysconfig/ باستخدام أسلوب التسمية sku_<SKU_NAME>. يحمّل النظام تلقائيًا الإعدادات من الدليل الذي يتطابق مع سمة ro.boot.hardware.sku. مثال على المسار: /product/etc/sysconfig/sku_basic_model/.

4. اضبط إعدادات منع تثبيت التطبيق. ضِمن الدليل الخاص برمز التخزين التعريفي، أنشِئ ملف إعداد XML (على سبيل المثال، disabled_apps.xml) واستخدِم العلامة <do-not-install-in> لاستبعاد حِزم معيّنة.

مثال على XML ‏ (/product/etc/sysconfig/sku_basic_model/disabled_apps.xml):

<?xml version="1.0" encoding="utf-8"?>
<config>
    <!-- Prevents this package from being installed for ANY user on this SKU -->
    <install-in-user-type package="com.example.premium.feature.app" >
        <do-not-install-in user-type="FULL" />
        <do-not-install-in user-type="SYSTEM" />
    </install-in-user-type>
</config>

في ما يلي مقارنة بين الطريقتَين:

في الحالات التي تتطلب تحكّمًا أكثر دقة (أي إيقاف تطبيق يتم تثبيته عادةً تلقائيًا على مستوى جميع رموز التخزين التعريفية)، يتيح Android أيضًا علامتَي disabled-in-sku وenabled-in-sku-override في sysconfig:

• <disabled-in-sku package="com.example.app" /> يؤدي إلى إيقاف التطبيق على مستوى العالم.

• <enabled-in-sku-override package="com.example.app" /> يؤدي إلى إعادة تفعيل التطبيق لرمز تخزين تعريفي معيّن عند وضعه في الدليل sku_<name> المقابل.

تحديد تراكب الموارد في الوقت الفعلي (RRO) بدلاً من استخدام تراكب الموارد الثابت

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

PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty

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

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

في ما يلي الأسئلة الشائعة حول صورة النظام المشتركة.

هل يمكنني تحديد صور نظام مشتركة متعددة؟

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

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

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