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

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

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

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

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

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

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

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

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

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

Context Hub HAL

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

في حال حدوث تعارض بين هذه المستندات وتعريف طبقة تجريد الأجهزة (HAL)، تكون الأولوية لتعريف طبقة تجريد الأجهزة.

الإعداد

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

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

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

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

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

إعادة تشغيل Context Hub

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

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

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

نظام التصميم

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

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

CHRE API

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

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

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

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

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

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

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

الإصدار 1.1 (الإصدار 8 من نظام التشغيل Android)

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

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

تضيف هذه النسخة إمكانية استخدام البيانات من ميكروفون منخفض الطاقة، ونطاق Wi-Fi RTT، وإشعارات تنبيه AP والنوم، وغيرها من التحسينات.

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

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

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

إضافة دعم لمعلومات شبكة الجيل الخامس (5G) وتفريغ تصحيح أخطاء التطبيقات الصغيرة وغيرها من التحسينات.

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

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

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

مكتبة C/C++ القياسية

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

  • استثناءات C++ ومعلومات نوع وقت التشغيل (RTTI)
  • إتاحة استخدام المكتبة العادية في بيئات متعددة سلاسل التنفيذ، بما في ذلك عناوين C++11 <thread> و<mutex> و<atomic> و<future>
  • مكتبات الإدخال والإخراج العادية في C وC++
  • مكتبة نماذج C++ القياسية (STL)
  • مكتبة التعبيرات العادية القياسية في 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 API ومكتبات الأدوات المساعدة. على سبيل المثال، يمكن استخدام chreLog لتسجيل بيانات تصحيح الأخطاء المستهدَفة لنظام logcat في Android، حيث قد يستخدم برنامج أكثر تقليدية printf أو std::cout.

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

  • أدوات السلاسل والمصفوفات: 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

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

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

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

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

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

GNSS

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

Wi-Fi

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

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

WWAN

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

الصوت

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

التنفيذ المرجعي

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

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