البائع APEX

يمكنك استخدام تنسيق ملف APEX لحزم وتثبيت وحدات نظام التشغيل Android ذات المستوى الأدنى. فهو يسمح ببناء وتثبيت المكونات بشكل مستقل مثل الخدمات والمكتبات الأصلية، وتطبيقات HAL، والبرامج الثابتة، وملفات التكوين، وما إلى ذلك.

يتم تثبيت APEXes للمورد بواسطة نظام الإنشاء تلقائيًا في قسم /vendor ويتم تنشيطه في وقت التشغيل بواسطة apexd تمامًا مثل APEXes في الأقسام الأخرى.

استخدم حالات

وحدات صور البائع

تعمل APEXes على تسهيل التجميع الطبيعي ونموذجية تطبيقات الميزات على صور البائعين.

عندما يتم إنشاء صور البائعين كمجموعة من APEXes الخاصة بالموردين والتي تم إنشاؤها بشكل مستقل، يكون بمقدور الشركات المصنعة للأجهزة انتقاء واختيار تطبيقات البائع المحددة المطلوبة على أجهزتهم بسهولة. يمكن للمصنعين أيضًا إنشاء بائع جديد APEX إذا لم يكن أي من APEXes المقدم يناسب احتياجاتهم، أو كان لديهم أجهزة مخصصة جديدة تمامًا.

على سبيل المثال، قد تختار الشركة المصنعة للمعدات الأصلية (OEM) إنشاء أجهزتها باستخدام تطبيق AOSP wifi APEX، وتطبيق SoC bluetooth APEX، وتنفيذ الهاتف المخصص لـ OEM APEX.

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

تكرار المطور

تساعد Vendor APEXes المطورين على التكرار بشكل أسرع أثناء تطوير وحدات البائع عن طريق تجميع تطبيق كامل للميزات، مثل wifi HAL، داخل المورد APEX. يمكن للمطورين بعد ذلك إنشاء البائع APEX ودفعه بشكل فردي لاختبار التغييرات، بدلاً من إعادة بناء صورة البائع بالكامل.

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

كما يعمل التجميع الطبيعي لمنطقة المعالم في APEX على تبسيط عملية إنشاء التغييرات ودفعها واختبارها لمنطقة الميزات تلك. على سبيل المثال، تؤدي إعادة تثبيت APEX إلى تحديث أي مكتبة مجمعة أو ملفات التكوين التي يتضمنها APEX تلقائيًا.

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

مثال لسير العمل:

# Build the entire device and flash. OR, obtain an already-flashed device.
source build/envsetup.sh && lunch oem_device-userdebug
m
fastboot flashall -w

# Test the device.
... testing ...

# Check previous behavior using a vendor APEX from one week ago, downloaded from
# your continuous integration build.
... download command ...
adb install <path to downloaded APEX>
adb reboot
... testing ...

# Edit and rebuild just the APEX to change and test behavior.
... edit APEX source contents ...
m <apex module name>
adb install out/<path to built APEX>
adb reboot
... testing ...

أمثلة

الأساسيات

راجع صفحة تنسيق ملف APEX الرئيسية للحصول على معلومات APEX العامة، بما في ذلك متطلبات الجهاز وتفاصيل تنسيق الملف وخطوات التثبيت.

في Android.bp ، يؤدي تعيين vendor: true إلى جعل وحدة APEX هي بائع APEX.

apex {
  ..
  vendor: true,
  ..
}

الثنائيات والمكتبات المشتركة

يتضمن APEX تبعيات متعدية داخل حمولة APEX ما لم يكن لديها واجهات مستقرة.

تتضمن الواجهات الأصلية الثابتة لتبعيات البائع APEX cc_library مع stubs أو ndk_library أو llndk_library . يتم استبعاد هذه التبعيات من التغليف، ويتم تسجيل التبعيات في بيان APEX. تتم معالجة البيان بواسطة linkerconfig بحيث تكون التبعيات الأصلية الخارجية متاحة في وقت التشغيل.

على عكس APEXes في قسم /system ، عادةً ما تكون APEXes للمورد مرتبطة بإصدار VNDK محدد. تضمن مكتبات VNDK استقرار ABI داخل الإصدار، حتى نتمكن من التعامل مع مكتبات VNDK على أنها مستقرة وتقليل حجم APEXes للمورد عن طريق استبعادها من APEXes باستخدام خاصية use_vndk_as_stable .

في المقتطف أدناه، سيحتوي APEX على كل من الملف الثنائي ( my_service ) وتبعياته غير المستقرة ( *.so files). لن يحتوي على مكتبات VNDK، حتى عندما يتم إنشاء my_service باستخدام مكتبات VNDK مثل libbase . بدلاً من ذلك، في وقت التشغيل، ستستخدم my_service libbase من مكتبات VNDK التي يوفرها النظام.

apex {
  ..
  vendor: true,
  use_vndk_as_stable: true,
  binaries: ["my_service"],
  ..
}

في المقتطف أدناه، سيحتوي APEX على المكتبة المشتركة my_standalone_lib وأي من تبعياتها غير المستقرة (كما هو موضح أعلاه).

apex {
  ..
  vendor: true,
  use_vndk_as_stable: true,
  native_shared_libs: ["my_standalone_lib"],
  ..
}

تطبيقات HAL

لتحديد تطبيق HAL، قم بتوفير الثنائيات والمكتبات المقابلة داخل مورد APEX مشابه للأمثلة التالية:

• مجسات هال
• هزاز هال
• واي فاي هال
• هال الهاتف

لتغليف تطبيق HAL بشكل كامل، يجب على APEX أيضًا تحديد أي أجزاء VINTF وبرامج نصية init ذات صلة.

شظايا VINTF

يمكن تقديم أجزاء VINTF من البائع APEX عندما تكون الأجزاء موجودة في etc/vintf الخاص بـ APEX.

استخدم خاصية prebuilts لتضمين أجزاء VINTF في APEX.

apex {
  ..
  vendor: true,
  prebuilts: ["fragment.xml"],
  ..
}

prebuilt_etc {
  name: "fragment.xml",
  src: "fragment.xml",
  sub_dir: "vintf",
}

البرامج النصية الأولية

يمكن أن تتضمن APEXes نصوص init بطريقتين: (أ) ملف نصي تم إنشاؤه مسبقًا ضمن حمولة APEX، أو (ب) نص برمجي init عادي في /vendor/etc . يمكنك ضبط كليهما لنفس APEX.

البرنامج النصي الأولي في APEX:

prebuilt_etc {
  name: "myinit.rc",
  src: "myinit.rc"
}

apex {
  ..
  vendor: true,
  prebuilts: ["myinit.rc"],
  ..
}

يمكن أن تحتوي البرامج النصية الأولية داخل APEXes على تعريفات service فقط. يمكن أن تحتوي البرامج النصية الأولية في Vendor APEXes on <property> أيضًا.

كن حذرا عند استخدام on التوجيهات. نظرًا لأنه يتم تحليل البرامج النصية init في APEXes وتنفيذها بعد تنشيط APEXes، فلا يمكن استخدام بعض الأحداث أو الخصائص. استخدم apex.all.ready=true لإطلاق الإجراءات في أقرب وقت ممكن.

البرامج الثابتة

مثال:

• البرامج الثابتة لخدمة الاهتزاز

قم بتضمين البرامج الثابتة في بائع APEX بنوع الوحدة النمطية prebuilt_firmware ، على النحو التالي.

prebuilt_firmware {
  name: "my.bin",
  src: "path_to_prebuilt_firmware",
  vendor: true,
}

apex {
  ..
  vendor: true,
  prebuilts: ["my.bin"],  // installed inside APEX as /etc/firmware/my.bin
  ..
}

يتم تثبيت وحدات prebuilt_firmware في دليل <apex name>/etc/firmware الخاص بـ APEX. ueventd بمسح أدلة /apex/*/etc/firmware للعثور على وحدات البرامج الثابتة.

يجب أن يقوم file_contexts الخاص بـ APEX بتسمية أي إدخالات حمولة البرامج الثابتة بشكل صحيح لضمان إمكانية الوصول إلى هذه الملفات بواسطة ueventd في وقت التشغيل؛ عادةً ما تكون تسمية vendor_file كافية. على سبيل المثال:

(/.*)? u:object_r:vendor_file:s0

وحدات النواة

قم بتضمين وحدات kernel في البائع APEX كوحدات تم إنشاؤها مسبقًا، على النحو التالي.

prebuilt_etc {
  name: "my.ko",
  src: "my.ko",
  vendor: true,
  sub_dir: "modules"
}

apex {
  ..
  vendor: true,
  prebuilts: ["my.ko"],  // installed inside APEX as /etc/modules/my.ko
  ..
}

يجب أن يقوم file_contexts الخاص بـ APEX بتسمية أي إدخالات حمولة وحدة kernel بشكل صحيح. على سبيل المثال:

/etc/modules(/.*)? u:object_r:vendor_kernel_modules:s0

يجب تثبيت وحدات Kernel بشكل صريح. يوضح المثال التالي للبرنامج النصي init الموجود في قسم البائع التثبيت عبر insmod :

my_init.rc :

on early-boot
  insmod /apex/myapex/etc/modules/my.ko
  ..

تراكبات موارد وقت التشغيل

مثال:

• الحبار RROs

قم بتضمين تراكبات موارد وقت التشغيل في مورد APEX باستخدام خاصية rros .

runtime_resource_overlay {
    name: "my_rro",
    soc_specific: true,
}


apex {
  ..
  vendor: true,
  rros: ["my_rro"],  // installed inside APEX as /overlay/my_rro.apk
  ..
}

ملفات التكوين الأخرى

تدعم ملفات APEXes للمورد العديد من ملفات التكوين الأخرى التي توجد عادةً في قسم البائع كإنشاءات مسبقة داخل APEXes للمورد، ويتم إضافة المزيد.

أمثلة:

• XMLs لإعلان الميزة
  • تتميز المستشعرات بـ XMLs باعتبارها مُنشأة مسبقًا في مستشعر HAL بائع APEX
• ملفات تكوين الإدخال
  • تكوينات الشاشة التي تعمل باللمس كإنشاءات مسبقة في بائع التكوين فقط APEX

ميزات التطوير الإضافية

اختيار APEX عند بدء التشغيل

مثال:

• كاميرا الحبار التي تمت محاكاتها HAL APEX

يمكن للمطورين أيضًا تثبيت إصدارات متعددة من APEXes الخاصة بالمورد والتي تشترك في نفس اسم ومفتاح APEX، ثم اختيار الإصدار الذي يتم تنشيطه أثناء كل عملية تمهيد باستخدام sysprops المستمرة. بالنسبة لبعض حالات استخدام المطورين، قد يكون هذا أسهل من تثبيت نسخة جديدة من APEX باستخدام adb install .

أمثلة لحالات الاستخدام:

• تثبيت 3 إصدارات من مزود wifi HAL APEX: يمكن لفرق ضمان الجودة إجراء اختبار يدوي أو آلي باستخدام إصدار واحد، ثم إعادة التشغيل إلى إصدار آخر وإعادة تشغيل الاختبارات، ثم مقارنة النتائج النهائية.
• تثبيت إصدارين من كاميرا APEX، بائع HAL، الحالي والتجريبي : يمكن لمستخدمي التطبيق التجريبي استخدام الإصدار التجريبي دون تنزيل ملف إضافي وتثبيته، حتى يتمكنوا من التبديل مرة أخرى بسهولة.

أثناء عملية التمهيد، يبحث apexd عن sysprops الذي يتبع تنسيقًا محددًا لتنشيط إصدار APEX الصحيح.

التنسيقات المتوقعة لمفتاح الخاصية هي:

• تكوين التمهيد
  • يُستخدم لتعيين القيمة الافتراضية في BoardConfig.mk .
  • androidboot.vendor.apex.<apex name>
• sysprop المستمر
  • يُستخدم لتغيير القيمة الافتراضية التي تم تعيينها على جهاز تم تشغيله بالفعل.
  • يتجاوز قيمة bootconfig إذا كانت موجودة.
  • persist.vendor.apex.<apex name>

يجب أن تكون قيمة الخاصية هي اسم ملف APEX الذي يجب تفعيله.

// Default version.
apex {
  name: "com.oem.camera.hal.my_apex_default",
  vendor: true,
  ..
}

// Non-default version.
apex {
  name: "com.oem.camera.hal.my_apex_experimental",
  vendor: true,
  ..
}

يجب أيضًا تكوين الإصدار الافتراضي باستخدام bootconfig في BoardConfig.mk :

# Example for APEX "com.oem.camera.hal" with the default above:
BOARD_BOOTCONFIG += \
    androidboot.vendor.apex.com.oem.camera.hal=com.oem.camera.hal.my_apex_default

بعد تشغيل الجهاز، قم بتغيير الإصدار المنشط عن طريق تعيين sysprop المستمر:

$ adb root;
$ adb shell setprop \
    persist.vendor.apex.com.oem.camera.hal \
    com.oem.camera.hal.my_apex_experimental;
$ adb reboot;

إذا كان الجهاز يدعم تحديث bootconfig بعد الوميض (على سبيل المثال عبر أوامر fastboot oem )، فإن تغيير خاصية bootconfig لـ APEX متعدد التثبيت يؤدي أيضًا إلى تغيير الإصدار الذي تم تنشيطه عند التمهيد.

بالنسبة للأجهزة المرجعية الافتراضية المستندة إلى Cuttlefish ، يمكنك استخدام الأمر --extra_bootconfig_args لتعيين خاصية bootconfig مباشرة أثناء التشغيل. على سبيل المثال:

launch_cvd --noresume \
  --extra_bootconfig_args "androidboot.vendor.apex.com.oem.camera.hal:=com.oem.camera.hal.my_apex_experimental";

,

يمكنك استخدام تنسيق ملف APEX لحزم وتثبيت وحدات نظام التشغيل Android ذات المستوى الأدنى. فهو يسمح ببناء وتثبيت المكونات بشكل مستقل مثل الخدمات والمكتبات الأصلية، وتطبيقات HAL، والبرامج الثابتة، وملفات التكوين، وما إلى ذلك.

يتم تثبيت APEXes للمورد بواسطة نظام الإنشاء تلقائيًا في قسم /vendor ويتم تنشيطه في وقت التشغيل بواسطة apexd تمامًا مثل APEXes في الأقسام الأخرى.

استخدم حالات

وحدات صور البائع

تعمل APEXes على تسهيل التجميع الطبيعي ونموذجية تطبيقات الميزات على صور البائعين.

عندما يتم إنشاء صور البائعين كمجموعة من APEXes الخاصة بالموردين والتي تم إنشاؤها بشكل مستقل، يكون بمقدور الشركات المصنعة للأجهزة انتقاء واختيار تطبيقات البائع المحددة المطلوبة على أجهزتهم بسهولة. يمكن للمصنعين أيضًا إنشاء بائع جديد APEX إذا لم يكن أي من APEXes المقدم يناسب احتياجاتهم، أو كان لديهم أجهزة مخصصة جديدة تمامًا.

على سبيل المثال، قد تختار الشركة المصنعة للمعدات الأصلية (OEM) إنشاء أجهزتها باستخدام تطبيق AOSP wifi APEX، وتطبيق SoC bluetooth APEX، وتنفيذ الهاتف المخصص لـ OEM APEX.

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

تكرار المطور

تساعد Vendor APEXes المطورين على التكرار بشكل أسرع أثناء تطوير وحدات البائع عن طريق تجميع تطبيق كامل للميزات، مثل wifi HAL، داخل المورد APEX. يمكن للمطورين بعد ذلك إنشاء البائع APEX ودفعه بشكل فردي لاختبار التغييرات، بدلاً من إعادة بناء صورة البائع بالكامل.

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

كما يعمل التجميع الطبيعي لمنطقة المعالم في APEX على تبسيط عملية إنشاء التغييرات ودفعها واختبارها لمنطقة الميزات تلك. على سبيل المثال، تؤدي إعادة تثبيت APEX إلى تحديث أي مكتبة مجمعة أو ملفات التكوين التي يتضمنها APEX تلقائيًا.

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

مثال لسير العمل:

# Build the entire device and flash. OR, obtain an already-flashed device.
source build/envsetup.sh && lunch oem_device-userdebug
m
fastboot flashall -w

# Test the device.
... testing ...

# Check previous behavior using a vendor APEX from one week ago, downloaded from
# your continuous integration build.
... download command ...
adb install <path to downloaded APEX>
adb reboot
... testing ...

# Edit and rebuild just the APEX to change and test behavior.
... edit APEX source contents ...
m <apex module name>
adb install out/<path to built APEX>
adb reboot
... testing ...

أمثلة

الأساسيات

راجع صفحة تنسيق ملف APEX الرئيسية للحصول على معلومات APEX العامة، بما في ذلك متطلبات الجهاز وتفاصيل تنسيق الملف وخطوات التثبيت.

في Android.bp ، يؤدي تعيين vendor: true إلى جعل وحدة APEX هي بائع APEX.

apex {
  ..
  vendor: true,
  ..
}

الثنائيات والمكتبات المشتركة

يتضمن APEX تبعيات متعدية داخل حمولة APEX ما لم يكن لديها واجهات مستقرة.

تتضمن الواجهات الأصلية الثابتة لتبعيات البائع APEX cc_library مع stubs أو ndk_library أو llndk_library . يتم استبعاد هذه التبعيات من التغليف، ويتم تسجيل التبعيات في بيان APEX. تتم معالجة البيان بواسطة linkerconfig بحيث تكون التبعيات الأصلية الخارجية متاحة في وقت التشغيل.

على عكس APEXes في قسم /system ، عادةً ما تكون APEXes للمورد مرتبطة بإصدار VNDK محدد. تضمن مكتبات VNDK استقرار ABI داخل الإصدار، حتى نتمكن من التعامل مع مكتبات VNDK على أنها مستقرة وتقليل حجم APEXes للمورد عن طريق استبعادها من APEXes باستخدام خاصية use_vndk_as_stable .

في المقتطف أدناه، سيحتوي APEX على كل من الملف الثنائي ( my_service ) وتبعياته غير المستقرة ( *.so files). لن يحتوي على مكتبات VNDK، حتى عندما يتم إنشاء my_service باستخدام مكتبات VNDK مثل libbase . بدلاً من ذلك، في وقت التشغيل، ستستخدم my_service libbase من مكتبات VNDK التي يوفرها النظام.

apex {
  ..
  vendor: true,
  use_vndk_as_stable: true,
  binaries: ["my_service"],
  ..
}

في المقتطف أدناه، سيحتوي APEX على المكتبة المشتركة my_standalone_lib وأي من تبعياتها غير المستقرة (كما هو موضح أعلاه).

apex {
  ..
  vendor: true,
  use_vndk_as_stable: true,
  native_shared_libs: ["my_standalone_lib"],
  ..
}

تطبيقات HAL

لتحديد تطبيق HAL، قم بتوفير الثنائيات والمكتبات المقابلة داخل مورد APEX مشابه للأمثلة التالية:

• مجسات هال
• هزاز هال
• واي فاي هال
• هال الهاتف

لتغليف تطبيق HAL بشكل كامل، يجب على APEX أيضًا تحديد أي أجزاء VINTF وبرامج نصية init ذات صلة.

شظايا VINTF

يمكن تقديم أجزاء VINTF من البائع APEX عندما تكون الأجزاء موجودة في etc/vintf الخاص بـ APEX.

استخدم خاصية prebuilts لتضمين أجزاء VINTF في APEX.

apex {
  ..
  vendor: true,
  prebuilts: ["fragment.xml"],
  ..
}

prebuilt_etc {
  name: "fragment.xml",
  src: "fragment.xml",
  sub_dir: "vintf",
}

البرامج النصية الأولية

يمكن أن تتضمن APEXes نصوص init بطريقتين: (أ) ملف نصي تم إنشاؤه مسبقًا ضمن حمولة APEX، أو (ب) نص برمجي init عادي في /vendor/etc . يمكنك ضبط كليهما لنفس APEX.

البرنامج النصي الأولي في APEX:

prebuilt_etc {
  name: "myinit.rc",
  src: "myinit.rc"
}

apex {
  ..
  vendor: true,
  prebuilts: ["myinit.rc"],
  ..
}

يمكن أن تحتوي البرامج النصية الأولية داخل APEXes على تعريفات service فقط. يمكن أن تحتوي البرامج النصية الأولية في Vendor APEXes on <property> أيضًا.

كن حذرا عند استخدام on التوجيهات. نظرًا لأنه يتم تحليل البرامج النصية init في APEXes وتنفيذها بعد تنشيط APEXes، فلا يمكن استخدام بعض الأحداث أو الخصائص. استخدم apex.all.ready=true لإطلاق الإجراءات في أقرب وقت ممكن.

البرامج الثابتة

مثال:

• البرامج الثابتة لخدمة الاهتزاز

قم بتضمين البرامج الثابتة في بائع APEX بنوع الوحدة النمطية prebuilt_firmware ، على النحو التالي.

prebuilt_firmware {
  name: "my.bin",
  src: "path_to_prebuilt_firmware",
  vendor: true,
}

apex {
  ..
  vendor: true,
  prebuilts: ["my.bin"],  // installed inside APEX as /etc/firmware/my.bin
  ..
}

يتم تثبيت وحدات prebuilt_firmware في دليل <apex name>/etc/firmware الخاص بـ APEX. ueventd بمسح أدلة /apex/*/etc/firmware للعثور على وحدات البرامج الثابتة.

يجب أن يقوم file_contexts الخاص بـ APEX بتسمية أي إدخالات حمولة البرامج الثابتة بشكل صحيح لضمان إمكانية الوصول إلى هذه الملفات بواسطة ueventd في وقت التشغيل؛ عادةً ما تكون تسمية vendor_file كافية. على سبيل المثال:

(/.*)? u:object_r:vendor_file:s0

وحدات النواة

قم بتضمين وحدات kernel في البائع APEX كوحدات تم إنشاؤها مسبقًا، على النحو التالي.

prebuilt_etc {
  name: "my.ko",
  src: "my.ko",
  vendor: true,
  sub_dir: "modules"
}

apex {
  ..
  vendor: true,
  prebuilts: ["my.ko"],  // installed inside APEX as /etc/modules/my.ko
  ..
}

يجب أن يقوم file_contexts الخاص بـ APEX بتسمية أي إدخالات حمولة وحدة kernel بشكل صحيح. على سبيل المثال:

/etc/modules(/.*)? u:object_r:vendor_kernel_modules:s0

يجب تثبيت وحدات Kernel بشكل صريح. يوضح المثال التالي للبرنامج النصي init الموجود في قسم البائع التثبيت عبر insmod :

my_init.rc :

on early-boot
  insmod /apex/myapex/etc/modules/my.ko
  ..

تراكبات موارد وقت التشغيل

مثال:

• الحبار RROs

قم بتضمين تراكبات موارد وقت التشغيل في مورد APEX باستخدام خاصية rros .

runtime_resource_overlay {
    name: "my_rro",
    soc_specific: true,
}


apex {
  ..
  vendor: true,
  rros: ["my_rro"],  // installed inside APEX as /overlay/my_rro.apk
  ..
}

ملفات التكوين الأخرى

تدعم ملفات APEXes للمورد العديد من ملفات التكوين الأخرى التي توجد عادةً في قسم البائع كإنشاءات مسبقة داخل APEXes للمورد، ويتم إضافة المزيد.

أمثلة:

• XMLs لإعلان الميزة
  • تتميز المستشعرات بـ XMLs باعتبارها مُنشأة مسبقًا في مستشعر HAL بائع APEX
• ملفات تكوين الإدخال
  • تكوينات الشاشة التي تعمل باللمس كإنشاءات مسبقة في بائع التكوين فقط APEX

ميزات التطوير الإضافية

اختيار APEX عند بدء التشغيل

مثال:

• كاميرا الحبار التي تمت محاكاتها HAL APEX

يمكن للمطورين أيضًا تثبيت إصدارات متعددة من APEXes الخاصة بالمورد والتي تشترك في نفس اسم ومفتاح APEX، ثم اختيار الإصدار الذي يتم تنشيطه أثناء كل عملية تمهيد باستخدام sysprops المستمرة. بالنسبة لبعض حالات استخدام المطورين، قد يكون هذا أسهل من تثبيت نسخة جديدة من APEX باستخدام adb install .

أمثلة لحالات الاستخدام:

• تثبيت 3 إصدارات من مزود wifi HAL APEX: يمكن لفرق ضمان الجودة إجراء اختبار يدوي أو آلي باستخدام إصدار واحد، ثم إعادة التشغيل إلى إصدار آخر وإعادة تشغيل الاختبارات، ثم مقارنة النتائج النهائية.
• تثبيت إصدارين من كاميرا APEX، بائع HAL، الحالي والتجريبي : يمكن لمستخدمي التطبيق التجريبي استخدام الإصدار التجريبي دون تنزيل ملف إضافي وتثبيته، حتى يتمكنوا من التبديل مرة أخرى بسهولة.

أثناء عملية التمهيد، يبحث apexd عن sysprops الذي يتبع تنسيقًا محددًا لتنشيط إصدار APEX الصحيح.

التنسيقات المتوقعة لمفتاح الخاصية هي:

• تكوين التمهيد
  • يُستخدم لتعيين القيمة الافتراضية في BoardConfig.mk .
  • androidboot.vendor.apex.<apex name>
• sysprop المستمر
  • يُستخدم لتغيير القيمة الافتراضية التي تم تعيينها على جهاز تم تشغيله بالفعل.
  • يتجاوز قيمة bootconfig إذا كانت موجودة.
  • persist.vendor.apex.<apex name>

يجب أن تكون قيمة الخاصية هي اسم ملف APEX الذي يجب تفعيله.

// Default version.
apex {
  name: "com.oem.camera.hal.my_apex_default",
  vendor: true,
  ..
}

// Non-default version.
apex {
  name: "com.oem.camera.hal.my_apex_experimental",
  vendor: true,
  ..
}

يجب أيضًا تكوين الإصدار الافتراضي باستخدام bootconfig في BoardConfig.mk :

# Example for APEX "com.oem.camera.hal" with the default above:
BOARD_BOOTCONFIG += \
    androidboot.vendor.apex.com.oem.camera.hal=com.oem.camera.hal.my_apex_default

بعد تشغيل الجهاز، قم بتغيير الإصدار المنشط عن طريق تعيين sysprop المستمر:

$ adb root;
$ adb shell setprop \
    persist.vendor.apex.com.oem.camera.hal \
    com.oem.camera.hal.my_apex_experimental;
$ adb reboot;

إذا كان الجهاز يدعم تحديث bootconfig بعد الوميض (على سبيل المثال عبر أوامر fastboot oem )، فإن تغيير خاصية bootconfig لـ APEX متعدد التثبيت يؤدي أيضًا إلى تغيير الإصدار الذي تم تنشيطه عند التمهيد.

بالنسبة للأجهزة المرجعية الافتراضية المستندة إلى Cuttlefish ، يمكنك استخدام الأمر --extra_bootconfig_args لتعيين خاصية bootconfig مباشرة أثناء التشغيل. على سبيل المثال:

launch_cvd --noresume \
  --extra_bootconfig_args "androidboot.vendor.apex.com.oem.camera.hal:=com.oem.camera.hal.my_apex_experimental";