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

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

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

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

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

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

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

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

هيكل إطار CHRE

الشكل 1. بنية إطار لجنة حقوق الأخلاقيات الإنسانية

مركز السياق HAL

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

في حالة وجود تعارض بين هذه الوثائق وتعريف HAL، يكون لتعريف HAL ​​الأسبقية.

التهيئة

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

تحميل وتفريغ تطبيقات النانو

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

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

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

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

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

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

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

بناء النظام

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

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

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

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

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

ملخص الإصدار

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

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

الإصدار 1.0 (أندرويد 7)

يتضمن دعمًا لأجهزة الاستشعار ووظائف تطبيقات النانو الأساسية، مثل الأحداث والمؤقتات.

الإصدار 1.1 (أندرويد 8)

يقدم إمكانات الموقع من خلال موقع GNSS والقياسات الأولية، ومسح Wi-Fi، ومعلومات الشبكة الخلوية، إلى جانب التحسينات العامة لتمكين الاتصال من تطبيق nanoapp إلى تطبيق nanoapp، وتحسينات أخرى.

الإصدار 1.2 (أندرويد 9)

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

الإصدار 1.3 (أندرويد 10)

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

الإصدار 1.4 (أندرويد 11)

يضيف دعمًا لمعلومات خلية 5G وتفريغ تصحيح أخطاء nanoapp وتحسينات أخرى.

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

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

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

مكتبة 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 لتسجيل تصحيح الأخطاء الذي يستهدف نظام Android logcat، حيث قد يستخدم برنامج أكثر تقليدية 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

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

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

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

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

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

النظم العالمية لسواتل الملاحة

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

واي فاي

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

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

شبكة واسعة النطاق

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

صوتي

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

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

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

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