بيئة وقت تشغيل مركز السياق (CHRE)

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

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

المفاهيم الرئيسية

بيئة CHRE هي بيئة البرامج التي يتم فيها تنفيذ التطبيقات الأصلية الصغيرة، والتي تُعرف باسم التطبيقات المصغّرة، على معالج يستهلك طاقة منخفضة وتتفاعل مع النظام الأساسي من خلال واجهة برمجة التطبيقات الشائعة CHRE API. لتسريع التنفيذ الصحيح لواجهتَي برمجة التطبيقات CHRE API، تم تضمين تنفيذ مرجعي لـ CHRE على جميع المنصات في AOSP. يتضمّن التنفيذ المرجعي رموزًا وعمليات تجريدية شائعة ل الأجهزة والبرامج الأساسية من خلال سلسلة من طبقات تجريد المنصة (PALs). تكون التطبيقات المصغّرة مرتبطة دائمًا تقريبًا بتطبيق عميل واحد أو أكثر يعمل على نظام التشغيل Android، والذي يتفاعل مع CHRE والتطبيقات المصغّرة من خلال واجهات برمجة تطبيقات نظام ContextHubManager ذات الوصول المحدود.

على مستوى عالٍ، يمكن إجراء مقارنات بين بنية CHRE و Android ككل. ومع ذلك، هناك بعض الاختلافات المهمة:

  • لا يدعم CHRE إلا تشغيل التطبيقات النانوية التي تم تطويرها باستخدام رموز برمجية أصلية (C أو C++ )، ولا يمكن استخدام Java.
  • بسبب القيود المفروضة على الموارد والقيود الأمنية، لا يمكن استخدام ميزة "الوصول إلى ذاكرة التخزين المؤقت للتطبيقات الأخرى" من قِبل تطبيقات Android عشوائية تابعة لجهات خارجية. ولا يمكن سوى للتطبيقات الموثوق بها من النظام الوصول إليه.

هناك أيضًا فرق مهم بين مفهوم CHRE ومركز الاستشعار. على الرغم من أنّه من الشائع استخدام الجهاز نفسه لتنفيذ مركز التحكّم في المستشعرات ووحدة التحكّم في سرعة المعالجة، لا توفّر وحدة التحكّم في سرعة المعالجة نفسها إمكانات المستشعر التي تتطلّبها HAL لأدوات استشعار Android. يرتبط CHRE بـ HAL لمركز السياق، وهو يعمل كعميل لإطار عمل أداة الاستشعار الخاصة بالجهاز لاستلام بيانات المستشعر بدون تضمين نقطة الوصول (AP).

بنية إطار عمل CHRE

الشكل 1: بنية إطار عمل CHRE

طبقة تجريد الأجهزة (HAL) لمركز السياق

طبقة HAL (التجريد من الأجهزة) في Context Hub هي الواجهة بين إطار عمل Android وتنفيذ CHRE على الجهاز، والتي تم تحديدها فيhardware/interfaces/contexthub. يحدد السياق على HAL واجهات برمجة التطبيقات التي يكتشف من خلالها إطار عمل Android مراكز السياقات المتاحة وتطبيقاتها النانوية، ويتفاعل مع تلك التطبيقات النانوية من خلال تمرير الرسائل، ويسمح بتحميل هذه التطبيقات وإلغاء تحميلها. يتوفّر في system/chre/host تطبيق مرجعي لواجهة برمجة التطبيقات Context Hub HAL يعمل مع التطبيق المرجعي لواجهة برمجة التطبيقات CHRE.

في حال تعارض هذه المستندات مع تعريف HAL، تكون الأولوية لتعريف HAL.

الإعداد

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

تحميل التطبيقات المصغّرة وتفريغها

يمكن أن يتضمّن مركز السياق مجموعة من التطبيقات المصغّرة المضمّنة في صورة الجهاز ويتم تحميلها عند بدء CHRE. تُعرف هذه التطبيقات باسم التطبيقات المصغّرة المحمَّلة مسبقًا، ويجب تضمينها في أول ردّ ممكن على queryApps().

يتيح "واجهة برمجة التطبيقات لوحدة التحكّم في السياق" أيضًا تحميل التطبيقات المصغّرة وتفريغها ديناميكيًا أثناء وقت التشغيل، وذلك من خلال الدالتَين loadNanoApp() وunloadNanoApp(). يتم تقديم التطبيقات المصغّرة لواجهة HAL بتنسيق ثنائي خاص بتنفيذ الأجهزة والبرامج في CHRE على الجهاز.

إذا كان تنفيذ تحميل تطبيق nanoapp يتضمن كتابته في ذاكرة غير متقلبة، مثل وحدة تخزين فلاش متصلة بالمعالج الذي يشغّل CHRE، يجب أن يتم دائمًا تشغيل تنفيذ CHRE مع هذه التطبيقات الديناميكية المصغرة في حالة إيقاف. وهذا يعني أنّه لا يتم تنفيذ أيّ من رموز التطبيق المصغّر إلى أن يتم تلقّي طلب enableNanoapp() من خلال HAL. يمكن بدء تشغيل التطبيقات المصغّرة المحمَّلة مسبقًا في الحالة المفعَّلة.

تتم إعادة تشغيل "مركز السياق".

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

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

تم تصميم CHRE استنادًا إلى بنية مستندة إلى الأحداث، حيث تكون الوحدة الأساسية للحساب هي حدث يتم تمريره إلى نقطة دخول معالجة الأحداث في التطبيق المصغّر. يمكن أن يكون إطار عمل CHRE متعدد السلاسل، ولكن لا يتم تنفيذ nanoapp معيّن من سلاسل محادثات متعددة بالتوازي. يتفاعل إطار عمل CHRE مع أي تطبيق نانوnanoappStart()nanoappHandleEvent()nanoappEnd() توفّر واجهة برمجة التطبيقات CHRE API مجموعة من الإمكانات الأساسية بالإضافة إلى تسهيلات للوصول إلى الإشارات السياقية، بما في ذلك الأدوات الاستشعارية ونظام تحديد المواقع العالمي (GNSS) وWi-Fi وشبكة WWAN والصوت، ويمكن توسيع نطاقها باستخدام إمكانات إضافية خاصة بالمورّد لاستخدامها من خلال التطبيقات المصغّرة الخاصة بالمورّد.

نظام التصميم

على الرغم من أنّ Context Hub HAL والمكونات الأخرى اللازمة من جهة AP يتم إنشاؤها جنبًا إلى جنب مع Android، يمكن أن يكون للرمز البرمجي الذي يتم تشغيله ضمن CHRE متطلبات تجعله غير متوافق مع نظام إنشاء Android، مثل الحاجة إلى toolchain مخصّصة. لذلك، يقدّم مشروع CHRE في AOSP نظام برمجة مختصرة سهل الاستخدام يستند إلى GNU Make لتجميع التطبيقات المصغّرة، واختياريًا، إطار عمل CHRE في مكتبات يمكن دمجها مع النظام. على مصنعي الأجهزة الذين يضيفون ميزة CHRE دمج ميزة نظام الإنشاء لأجهزة الإصدار المستهدف في AOSP.

تمّت كتابة واجهة برمجة التطبيقات CHRE وفقًا لمعيار لغة C99، ويستخدم التنفيذ المرجعي مجموعة فرعية محدودة من C++11 مناسبة للتطبيقات التي تتضمّن موارد محدودة.

واجهة برمجة التطبيقات CHRE

واجهة برمجة التطبيقات CHRE هي مجموعة من ملفات عناوين C التي تحدّد واجهة البرنامج بين التطبيق المصغّر والنظام. تم تصميمه لجعل رمز التطبيقات المصغّرة متوافقًا على جميع الأجهزة المتوافقة مع CHRE، ما يعني أنّه ليس من الضروري تعديل رمز المصدر لتطبيق مصغّر لكي يكون متوافقًا مع نوع جهاز جديد، إلا أنّه قد يتطلّب إعادة الترجمة خصيصًا لمجموعة تعليمات معالج الجهاز المستهدَف أو واجهة التطبيق الثنائية (ABI). تضمن أيضًا بنية CHRE وتصميم واجهة برمجة التطبيقات أن تكون التطبيقات المصغّرة متوافقة مع الثنائي على مستوى الإصدارات المختلفة من واجهة برمجة التطبيقات CHRE، ما يعني أنّه ليس على المطوّر إعادة تجميع التطبيق المصغّر لتشغيله على نظام يستخدم إصدارًا مختلفًا من واجهة برمجة التطبيقات CHRE مقارنةً بواجهة برمجة التطبيقات المستهدَفة التي تم تجميع التطبيق المصغّر وفقًا لها. بمعنى آخر، إذا تم تشغيل برنامج ثنائي nanoapp على جهاز يتوافق مع الإصدار 1.3 من واجهة CHRE API، وتمت ترقية هذا الجهاز ليتوافق مع الإصدار 1.4 من واجهة CHRE API، سيستمر عمل البرنامج الثنائي nanoapp نفسه. وبالمثل، يمكن تشغيل التطبيق المصغّر باستخدام الإصدار 1.2 من واجهة برمجة التطبيقات CHRE API، ويمكنه تحديد ما إذا كان يتطلب إمكانات من الإصدار 1.3 من واجهة برمجة التطبيقات لتحقيق استخدامه، أو ما إذا كان يمكنه العمل، مع احتمال تقليل وظائفه بشكل سلس.

يتم إصدار إصدارات جديدة من واجهة برمجة التطبيقات CHRE API مع نظام التشغيل Android، ولكن بما أنّ عملية تنفيذ CHRE هي جزء من تنفيذ المورّد، لا يكون إصدار واجهة برمجة التطبيقات CHRE API المتوافق مع جهاز معيّن مرتبطًا بالضرورة بأحد إصدارات Android.

ملخّص الإصدار

مثل مخطّط إصدار Android HIDL، تلتزم واجهة برمجة التطبيقات CHRE API بنظام الإصدارات الدلالية. يشير الإصدار الرئيسي إلى التوافق مع الثنائيات، بينما يتم زيادة الإصدار الثانوي عند طرح ميزات متوافقة مع الإصدارات القديمة. تتضمّن واجهة برمجة التطبيقات CHRE API تعليقات توضيحية لرمز المصدر لتحديد الإصدار الذي أدخل دالة أو مَعلمة، على سبيل المثال @since v1.1.

يعرض تنفيذ CHRE أيضًا إصدارًا خاصًا بالمنصة من خلال chreGetVersion()، ما يشير إلى إجراء إصلاحات للأعطال أو تعديلات طفيفة في التنفيذ.

الإصدار 1.0 (Android 7)

يشمل ذلك دعم أدوات الاستشعار وإمكانات تطبيقات النانو الأساسية، مثل الأحداث والموقّتات.

الإصدار 1.1 (Android 8)

يوفّر إمكانات تحديد الموقع الجغرافي من خلال الموقع الجغرافي لنظام تحديد المواقع العالمي (GNSS) والقياسات الأوّلية، والبحث عن شبكة Wi-Fi ومعلومات شبكة الجوّال، بالإضافة إلى تحسينات عامة لتفعيل تواصل التطبيقات المصغّرة مع بعضها، وغيرها من التحسينات.

الإصدار 1.2 (Android 9)

إتاحة استخدام بيانات من ميكروفون منخفض الطاقة، وقياس وقت الاستجابة (RTT) لشبكة Wi-Fi، وإشعارات AP للتشغيل والإيقاف، وتحسينات أخرى

الإصدار 1.3 (Android 10)

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

الإصدار 1.4 (Android 11)

إضافة إمكانية عرض معلومات خلايا الجيل الخامس وعرض بيانات تصحيح أخطاء التطبيقات المصغّرة وغيرها من التحسينات

ميزات النظام الإلزامية

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

بالإضافة إلى ميزات النظام الأساسية التي تمّ وضع معايير لها في واجهة برمجة التطبيقات CHRE API، هناك أيضًا ميزات إلزامية على مستوى النظام في CHRE تم تحديدها على مستوى Context Hub HAL. والميزة الأكثر أهمية من بين هذه الميزات هي إمكانية تحميل التطبيقات المصغّرة وتفريغها ديناميكيًا.

المكتبة العادية لـ C/C++

للحدّ من استخدام الذاكرة وتعقيد النظام، يجب أن توفّر تطبيقات CHRE مجموعة فرعية فقط من مكتبات C وC++ العادية وميزات اللغة التي تتطلّب دعم وقت التشغيل. استنادًا إلى هذه المبادئ، يتم استبعاد بعض الميزات صراحةً بسبب اعتمادها على ذاكرة وعمليات برمجية واسعة النطاق على مستوى نظام التشغيل، وبعض الميزات الأخرى بسبب استبدالها بواجهات برمجة تطبيقات أكثر ملاءمةً لنظام التشغيل Chrome. على الرغم من أنّ الإمكانات التالية ليست شاملة، فإنّ الإمكانات التالية غير مخصّصة لتوفيرها لتطبيقات nanoapps:

  • استثناءات C++ ومعلومات أنواع وقت التشغيل (RTTI)
  • إتاحة استخدام خيوط متعددة في المكتبة العادية، بما في ذلك رؤوس C++11 <thread> و<mutex> و<atomic> و<future>
  • مكتبات الإدخال والإخراج القياسية C وC++
  • مكتبة النماذج العادية (STL) في C++
  • مكتبة التعبيرات العادية العادية في C++
  • تخصيص الذاكرة الديناميكي من خلال الدوالّ العادية (مثل malloc وcalloc وrealloc وfree وoperator new) ودوالّ المكتبة العادية الأخرى التي تستخدم بشكلٍ أساسي التخصيص الديناميكي، مثل std::unique_ptr
  • إتاحة استخدام أحرف Unicode والترجمة
  • مكتبات التاريخ والوقت
  • الدوال التي تعدّل مسار البرنامج العادي، بما في ذلك <setjmp.h> <signal.h> وabort وstd::terminate
  • الوصول إلى بيئة المضيف، بما في ذلك system وgetenv
  • POSIX والمكتبات الأخرى غير المضمّنة في معايير اللغة C99 أو C++11

في الكثير من الحالات، تتوفّر إمكانات مكافئة من وظائف واجهة برمجة تطبيقات CHRE ومكتبات الأدوات المساعدة. على سبيل المثال، يمكن استخدام chreLog لتسجيل تصحيح الأخطاء الموجَّه إلى نظام logcat في Android، حيث قد يستخدم برنامج تقليدي printf أو std::cout.

في المقابل، تكون بعض إمكانات المكتبة العادية مطلوبة. ويعود الأمر إلى عملية تنفيذ النظام الأساسي لعرض هذه الوظائف من خلال المكتبات الثابتة لتضمينها في ملف ثنائي لتطبيق nanoapp، أو من خلال الربط الديناميكي بين تطبيق nanoapp والنظام. ويشمل ذلك، على سبيل المثال لا الحصر:

  • أدوات السلاسل والمصفوفات: memcmp وmemcpy وmemmove وmemset strlen

  • مكتبة الرياضيات: دوال النقاط العائمة أحادية الدقة شائعة الاستخدام:

    • العمليات الأساسية: ceilf وfabsf وfloorf وfmaxf وfminf وfmodf roundf وlroundf وremainderf
    • الدوال الأسية والدوالّ الأسية للقوة: expf وlog2f وpowf وsqrtf
    • الدوال المثلثية والقطعية: sinf وcosf وtanf وasinf acosf وatan2f وtanhf

على الرغم من أنّ بعض المنصات الأساسية تتيح إمكانات إضافية، لا يُعتبر التطبيق المصغّر قابلاً للنقل على مستوى عمليات تنفيذ CHRE ما لم يفرض قيودًا على التبعيات الخارجية لدوالّ واجهة برمجة التطبيقات CHRE ودوالّ المكتبة العادية المعتمَدة.

ميزات اختيارية

للترويج للأجهزة والبرامج، تم تقسيم CHRE API إلى مجالات ميزات، والتي تُعدّ اختيارية من منظور واجهة برمجة التطبيقات. على الرغم من أنّ هذه الميزات قد لا تكون مطلوبة لتتوافق مع عملية تنفيذ متوافقة لـ CHRE، إلا أنّها قد تكون مطلوبة لتتوافق مع تطبيق صغير معيّن. حتى إذا كان النظام الأساسي لا يتوافق مع مجموعة معينة من واجهات برمجة التطبيقات، يجب أن تكون التطبيقات النانوية التي تشير إلى هذه الدوال قادرة على الإنشاء والتحميل.

أجهزة الاستشعار

توفّر واجهة برمجة التطبيقات CHRE API إمكانية طلب البيانات من أجهزة الاستشعار، بما في ذلك مقياس التسارع والجيروسكوب ومقياس المغناطيسية وجهاز استشعار الضوء المحيط وجهاز استشعار التقارب. تهدف واجهات برمجة التطبيقات هذه إلى توفير مجموعة ميزات مشابهة لواجهات برمجة تطبيقات أدوات استشعار Android ، بما في ذلك إتاحة تجميع عيّنات أدوات الاستشعار لتقليل استهلاك الطاقة. تؤدي معالجة بيانات الاستشعار ضمن CHRE إلى استهلاك طاقة أقل بكثير ووقت استجابة أقل لمعالجة إشارات الحركة مقارنةً بتشغيلها على نقطة الوصول.

نظام GNSS

توفّر CHRE واجهات برمجة تطبيقات لطلب بيانات الموقع الجغرافي من نظام تحديد المواقع العالمي باستخدام الأقمار الصناعية (GNSS)، بما في ذلك نظام تحديد المواقع العالمي (GPS) ومجموعات الأقمار الصناعية الأخرى. ويشمل ذلك طلبات تحديد المواقع الجغرافية بشكل دوري، بالإضافة إلى بيانات القياس الأوّلية، على الرغم من أنّ كلتا الوظيفتَين مستقلتَين. ونظرًا لأن CHRE لديها رابط مباشر إلى النظام الفرعي GNSS، يتم خفض الطاقة مقارنةً بطلبات GNSS المستندة إلى AP، لأن AP يمكن أن تظل في وضع السكون خلال دورة حياة جلسة الموقع بالكامل.

Wi-Fi

توفّر تقنية CHRE إمكانية التفاعل مع شريحة Wi-Fi، وذلك لأغراض تتعلّق بتحديد الموقع الجغرافي بشكل أساسي. على الرغم من أنّ نظام GNSS يعمل جيدًا في المواقع الجغرافية الخارجية، فإنّ نتائج عمليات البحث عن شبكات Wi-Fi يمكن أن توفّر معلومات دقيقة عن الموقع الجغرافي في الأماكن المغلقة وفي المناطق المتطورة. بالإضافة إلى تجنُّب تكلفة تنشيط نقطة الوصول لإجراء عملية بحث، يمكن لوحدة التحكّم في الطاقة الذكية (CHRE) الاستماع إلى نتائج عمليات البحث عن شبكة Wi-Fi التي يجريها الثابت المبرمَج لشبكة Wi-Fi أغراض الاتصال، والتي لا يتم عادةً إرسالها إلى نقطة الوصل لأسباب تتعلّق بالطاقة. وتساعد الاستفادة من عمليات البحث عن الاتصال لأغراض سياقية في تقليل إجمالي عدد عمليات البحث عن شبكة Wi-Fi التي يتم إجراؤها وتوفير الطاقة.

تمت إضافة إمكانية استخدام Wi-Fi في الإصدار 1.1 من CHRE API، بما في ذلك إمكانية رصد نتائج عمليات المسح وبدء عمليات المسح عند الطلب. تم توسيع نطاق هذه الإمكانات في الإصدار 1.2 من خلال إمكانية إجراء قياسات للوقت المستغرَق في رحلة البيانات ذهابًا وإيابًا (RTT) مقارنةً بنقاط الوصول التي تتيح هذه الميزة، ما يتيح تحديد الموضع النسبي بدقة.

شبكة WWAN

توفر واجهة برمجة تطبيقات CHRE إمكانية استرداد معلومات تعريف الخلية لخلية التقديم وجارها، والتي يتم استخدامها عادةً لأغراض الموقع الجغرافي الدقيق.

الصوت

يمكن لخدمة CHRE معالجة دفعات من البيانات الصوتية من ميكروفون منخفض الطاقة، والذي يستخدِم عادةً الأجهزة المستخدَمة لتنفيذ واجهة برمجة التطبيقات SoundTrigger HAL. يمكن أن تؤدي معالجة data الصوت في CHRE إلى دمجها مع بيانات أخرى، مثل أجهزة استشعار الحركة.

تطبيق المرجع

تم تضمين الرمز المرجعي لإطار عمل CHRE في AOSP في مشروع system/chre ، الذي تم تنفيذه باستخدام C++11. على الرغم من أنّ ذلك ليس مطلوبًا بشكل صارم، ننصحك بأن تستند جميع عمليات تنفيذ CHRE إلى قاعدة البيانات هذه، للمساعدة في ضمان الاتساق وتسريع اعتماد الإمكانات الجديدة. ويمكن النظر إلى هذا الرمز البرمجي كتشابه مع إطار عمل Android الأساسي في أنّه تنفيذ مفتوح المصدر لواجهات برمجة التطبيقات التي تستخدمها التطبيقات، ويعمل كمرجع ومعيار للتوافق. على الرغم من أنّه يمكن تخصيصه وتوسيع نطاقه باستخدام ميزات خاصة بالمورّد، ننصحك بالاحتفاظ بالرمز المشترَك أقرب ما يمكن إلى المرجع. على غرار واجهات HAL في Android، يستخدم تنفيذ CHRE المرجعي تصنيفات مختلفة للمنصة ليتمكّن من التكيّف مع أي جهاز يستوفي الحد الأدنى من المتطلبات.

للاطّلاع على التفاصيل الفنية ودليل نقل البيانات، يُرجى الاطّلاع علىملف التمهيد README المُدرَج في مشروع system/chre.