Context Hub Runtime Environment (CHRE)

گوشی های هوشمند دارای تعدادی پردازنده هستند که هر کدام برای انجام وظایف مختلف بهینه شده اند. با این حال، اندروید فقط روی یک پردازنده اجرا می شود: پردازنده برنامه ها (AP). AP برای ارائه عملکرد عالی برای موارد استفاده روی صفحه نمایش مانند بازی تنظیم شده است، اما برای پشتیبانی از ویژگی هایی که نیاز به پردازش های مکرر و کوتاه در تمام مدت دارند، حتی زمانی که صفحه نمایش خاموش است، بسیار پرقدرت است. پردازنده‌های کوچک‌تر می‌توانند این حجم‌های کاری را کارآمدتر انجام دهند و وظایف خود را بدون تأثیر قابل توجهی بر عمر باتری انجام دهند. با این حال، محیط‌های نرم‌افزاری در این پردازنده‌های کم‌مصرف محدودتر هستند و می‌توانند بسیار متفاوت باشند، که توسعه چند پلتفرمی را دشوار می‌کند.

Context Hub Runtime Environment (CHRE) یک پلت فرم مشترک برای اجرای برنامه ها روی یک پردازنده کم مصرف با یک API ساده، استاندارد و جاسازی شده ارائه می دهد. CHRE این امکان را برای OEM های دستگاه و شرکای مورد اعتماد آن ها فراهم می کند تا پردازش را از AP ​​تخلیه کنند، باتری را ذخیره کنند و زمینه های مختلف تجربه کاربر را بهبود بخشند، و دسته ای از ویژگی های همیشه روشن و آگاه به زمینه را فعال کنند، به ویژه آنهایی که مربوط به کاربرد ماشین هستند. یادگیری حس محیطی

مفاهیم کلیدی

CHRE محیط نرم‌افزاری است که در آن برنامه‌های کوچک بومی، به نام nanoapps ، روی یک پردازنده کم‌مصرف اجرا می‌شوند و از طریق API مشترک CHRE با سیستم زیربنایی تعامل دارند. برای تسریع اجرای صحیح APIهای CHRE، یک پیاده سازی مرجع بین پلتفرمی CHRE در AOSP گنجانده شده است. پیاده‌سازی مرجع شامل کدها و انتزاعات رایج برای سخت‌افزار و نرم‌افزار زیربنایی از طریق یک سری لایه‌های انتزاعی پلتفرم (PAL) است. نانواپلیکیشن‌ها تقریباً همیشه به یک یا چند برنامه کلاینت در حال اجرا در Android متصل هستند که از طریق APIهای سیستم ContextHubManager با دسترسی محدود با CHRE و نانوبرنامه‌ها تعامل دارند.

در سطح بالایی، می توان شباهت هایی بین معماری CHRE و اندروید به طور کلی ترسیم کرد. با این حال، چند تمایز مهم وجود دارد:

  • CHRE فقط از اجرای نانواپلیکیشن‌های توسعه‌یافته در کد بومی (C یا C++) پشتیبانی می‌کند. جاوا پشتیبانی نمی شود
  • به دلیل محدودیت‌های منابع و محدودیت‌های امنیتی، CHRE برای استفاده توسط برنامه‌های خودسرانه شخص ثالث Android باز نیست. فقط برنامه های قابل اعتماد سیستم می توانند به آن دسترسی داشته باشند.

همچنین تمایز مهمی بین مفهوم CHRE و هاب حسگر وجود دارد. در حالی که استفاده از سخت افزار مشابه برای پیاده سازی هاب حسگر و CHRE معمول است، CHRE خود عملکرد حسگر مورد نیاز HAL سنسورهای Android را ارائه نمی دهد. CHRE به Context Hub HAL گره خورده است و به عنوان مشتری چارچوب حسگر خاص دستگاه برای دریافت داده های حسگر بدون دخالت AP عمل می کند.

معماری چارچوب CHRE

شکل 1. معماری چارچوب CHRE

Context Hub HAL

لایه انتزاعی سخت‌افزار Context Hub (HAL) رابط بین چارچوب Android و پیاده‌سازی CHRE دستگاه است که در hardware/interfaces/contexthub تعریف شده است. Context Hub HAL APIهایی را تعریف می‌کند که چارچوب Android از طریق آن هاب‌های زمینه موجود و نانوبرنامه‌های آن‌ها را کشف می‌کند، با آن نانواپلیکیشن‌ها از طریق ارسال پیام تعامل می‌کند، و اجازه می‌دهد تا برنامه‌های نانو بارگیری و بارگیری شوند. یک پیاده سازی مرجع از Context Hub HAL که با پیاده سازی مرجع CHRE کار می کند در system/chre/host موجود است.

در صورت تضاد بین این مستندات و تعریف HAL، تعریف HAL ​​اولویت دارد.

مقداردهی اولیه

هنگامی که اندروید بوت می شود، ContextHubService تابع getHubs() HAL را فراخوانی می کند تا مشخص کند که آیا هاب زمینه در دستگاه موجود است یا خیر. این یک تماس مسدودکننده و یکباره است، بنابراین برای جلوگیری از تأخیر در راه‌اندازی باید سریع تکمیل شود، و باید نتیجه دقیقی را ارائه دهد، زیرا پس از آن، هاب‌های زمینه جدیدی نمی‌توانند معرفی شوند.

بارگیری و تخلیه برنامه های نانو

یک هاب زمینه می‌تواند شامل مجموعه‌ای از برنامه‌های نانو باشد که در تصویر دستگاه گنجانده شده و با شروع CHRE بارگیری می‌شوند. اینها به عنوان nanoapps از پیش بارگذاری شده شناخته می شوند و باید در اولین پاسخ ممکن به queryApps() گنجانده شوند.

Context Hub HAL همچنین از بارگیری و تخلیه نانواپلیکیشن ها به صورت پویا در زمان اجرا، از طریق توابع loadNanoApp() و unloadNanoApp() پشتیبانی می کند. نانواپلیکیشن ها در قالب باینری مخصوص اجرای سخت افزار و نرم افزار CHRE دستگاه در اختیار HAL قرار می گیرند.

اگر پیاده‌سازی برای بارگذاری یک برنامه نانو شامل نوشتن آن در حافظه غیرفرار، مانند حافظه فلش متصل به پردازنده‌ای که CHRE را اجرا می‌کند، باشد، پیاده‌سازی CHRE باید همیشه با این نانوبرنامه‌های پویا در حالت غیرفعال راه‌اندازی شود. این بدان معناست که تا زمانی که یک درخواست enableNanoapp() از طریق HAL دریافت نشود، هیچ یک از کدهای nanoapp اجرا نمی شود. نانواپلیکیشن های از پیش بارگذاری شده می توانند در حالت فعال مقداردهی اولیه شوند.

هاب زمینه دوباره راه اندازی می شود

در حالی که انتظار نمی رود CHRE در طول عملیات عادی راه اندازی مجدد شود، ممکن است لازم باشد از شرایط غیرمنتظره مانند تلاش برای دسترسی به یک آدرس حافظه نقشه برداری نشده بازیابی شود. در این شرایط، CHRE به طور مستقل از Android راه اندازی مجدد می شود. HAL از طریق رویداد RESTARTED به Android اطلاع می‌دهد، که باید آن را فقط پس از شروع مجدد CHRE ارسال کند تا جایی که بتواند درخواست‌های جدید مانند queryApps() را بپذیرد.

نمای کلی سیستم CHRE

CHRE حول یک معماری رویداد محور طراحی شده است، که در آن واحد اولیه محاسبات رویدادی است که به نقطه ورود مدیریت رویداد نانواپلیکیشن منتقل می شود. در حالی که چارچوب CHRE می‌تواند چند رشته‌ای باشد، یک نانوبرنامه مشخص هرگز از چند رشته به‌طور موازی اجرا نمی‌شود. چارچوب CHRE از طریق یکی از سه نقطه ورودی نانواپلیکیشن ( nanoappStart() ، nanoappHandleEvent() و nanoappEnd() ) یا از طریق یک فراخوان ارائه شده در یک تماس قبلی CHRE API، با یک نانوبرنامه معین تعامل می کند و نانواپلیکیشن ها با چارچوب CHRE تعامل دارند و سیستم زیربنایی از طریق CHRE API. CHRE API مجموعه‌ای از عملکردهای اساسی و همچنین امکاناتی را برای دسترسی به سیگنال‌های متنی، از جمله حسگرها، GNSS، Wi-Fi، WWAN و صدا فراهم می‌کند و می‌توان آن را با قابلیت‌های اضافی خاص فروشنده برای استفاده توسط نانواپلیکیشن‌های خاص توسعه داد. .

ساخت سیستم

در حالی که Context Hub HAL و سایر اجزای ضروری سمت AP در کنار Android ساخته می‌شوند، کدی که در CHRE اجرا می‌شود می‌تواند الزاماتی داشته باشد که آن را با سیستم ساخت اندروید ناسازگار می‌کند، مانند نیاز به یک زنجیره ابزار تخصصی. بنابراین، پروژه CHRE در AOSP یک سیستم ساخت ساده‌شده مبتنی بر GNU Make برای کامپایل نانواپلیکیشن‌ها و به‌طور اختیاری، چارچوب CHRE در کتابخانه‌هایی که می‌توانند با سیستم یکپارچه شوند، ارائه می‌کند. سازندگان دستگاه‌هایی که پشتیبانی از CHRE را اضافه می‌کنند، باید پشتیبانی سیستم ساخت دستگاه‌های هدف خود را در AOSP ادغام کنند.

CHRE API با استاندارد زبان C99 نوشته شده است و پیاده سازی مرجع از یک زیر مجموعه محدود C++11 مناسب برای برنامه های کاربردی با منابع محدود استفاده می کند.

CHRE API

CHRE API مجموعه‌ای از فایل‌های هدر C است که رابط نرم‌افزاری بین یک برنامه نانو و سیستم را تعریف می‌کند. این برنامه به گونه‌ای طراحی شده است که کدهای نانواپلیکیشن‌ها را با همه دستگاه‌هایی که از CHRE پشتیبانی می‌کنند، سازگار کند، به این معنی که کد منبع یک برنامه نانو برای پشتیبانی از یک نوع دستگاه جدید نیازی به تغییر ندارد، اگرچه ممکن است نیاز به کامپایل مجدد به طور خاص برای پردازنده دستگاه مورد نظر داشته باشد. مجموعه دستورالعمل یا رابط باینری برنامه (ABI). معماری CHRE و طراحی API همچنین تضمین می‌کند که نانواپلیکیشن‌ها با نسخه‌های مختلف CHRE API سازگار باینری هستند، به این معنی که یک نانواپ برای اجرا روی سیستمی که نسخه متفاوتی از CHRE API را اجرا می‌کند، نیازی به کامپایل مجدد ندارد. API هدفی که نانوبرنامه بر اساس آن کامپایل شده است. به عبارت دیگر، اگر یک باینری نانواپلیکی روی دستگاهی اجرا شود که از CHRE API v1.3 پشتیبانی می‌کند و آن دستگاه برای پشتیبانی از CHRE API v1.4 ارتقا یابد، همان باینری نانواپلیکی به کار خود ادامه می‌دهد. به طور مشابه، نانواپلیکیشن می‌تواند بر روی CHRE API نسخه 1.2 اجرا شود و می‌تواند در زمان اجرا تعیین کند که آیا برای دستیابی به عملکرد خود به عملکردی از API نسخه 1.3 نیاز دارد یا اینکه می‌تواند به طور بالقوه با کاهش ویژگی‌های زیبا کار کند.

نسخه‌های جدید CHRE API در کنار Android منتشر می‌شوند، اما از آنجایی که اجرای CHRE بخشی از پیاده‌سازی فروشنده است، نسخه CHRE API پشتیبانی‌شده در دستگاه لزوماً به نسخه Android مرتبط نیست.

خلاصه نسخه

مانند طرح نسخه‌سازی HIDL Android ، API CHRE از نسخه‌سازی معنایی پیروی می‌کند. نسخه اصلی نشان دهنده سازگاری باینری است، در حالی که نسخه کوچک هنگامی که ویژگی های سازگار با عقب معرفی می شود افزایش می یابد. CHRE API شامل حاشیه نویسی کد منبع برای تشخیص اینکه کدام نسخه یک تابع یا پارامتر را معرفی کرده است، به عنوان مثال @since v1.1 .

پیاده‌سازی CHRE همچنین یک نسخه پچ مخصوص پلتفرم را از طریق chreGetVersion() نشان می‌دهد، که نشان می‌دهد چه زمانی رفع اشکال یا به‌روزرسانی‌های جزئی در پیاده‌سازی انجام می‌شود.

نسخه 1.0 (اندروید 7)

شامل پشتیبانی از حسگرها و عملکردهای هسته‌ای نانواپلیکیشن مانند رویدادها و تایمرها می‌شود.

نسخه 1.1 (اندروید 8)

قابلیت‌های مکان را از طریق مکان‌یابی GNSS و اندازه‌گیری‌های خام، اسکن Wi-Fi، و اطلاعات شبکه سلولی، همراه با اصلاحات کلی برای فعال کردن ارتباط بین برنامه‌ها و نانواپلیکیشن‌ها و سایر پیشرفت‌ها معرفی می‌کند.

نسخه 1.2 (اندروید 9)

پشتیبانی از داده‌های میکروفون کم‌مصرف، محدوده RTT Wi-Fi، اعلان‌های بیداری/خواب AP و سایر پیشرفت‌ها را اضافه می‌کند.

نسخه 1.3 (اندروید 10)

قابلیت‌های مربوط به داده‌های کالیبراسیون حسگر را افزایش می‌دهد، پشتیبانی برای شستشوی داده‌های حسگر دسته‌ای در صورت تقاضا اضافه می‌کند، نوع سنسور تشخیص مرحله را تعریف می‌کند، و رویدادهای مکان GNSS را با فیلدهای دقت اضافی گسترش می‌دهد.

نسخه 1.4 (اندروید 11)

پشتیبانی از اطلاعات سلول 5G، حذف اشکال‌زدایی نانواپلیکیشن و سایر پیشرفت‌ها را اضافه می‌کند.

ویژگی های سیستم اجباری

در حالی که منابع سیگنال‌های زمینه‌ای، مانند حسگرها، در بخش‌های ویژگی اختیاری دسته‌بندی می‌شوند، چند عملکرد اصلی در تمام پیاده‌سازی‌های CHRE مورد نیاز است. این شامل APIهای سیستم اصلی، مانند مواردی برای تنظیم تایمر، ارسال و دریافت پیام به مشتریان در پردازنده برنامه‌ها، ورود به سیستم و غیره است. برای جزئیات کامل، سرصفحه های API را ببینید.

علاوه بر ویژگی‌های اصلی سیستم کدگذاری شده در CHRE API، ویژگی‌های اجباری در سطح سیستم CHRE نیز در سطح Context Hub HAL مشخص شده‌اند. مهمترین آنها توانایی بارگذاری و تخلیه پویا نانواپلیکیشن ها است.

کتابخانه استاندارد C/C++

برای به حداقل رساندن استفاده از حافظه و پیچیدگی سیستم، پیاده‌سازی‌های CHRE فقط برای پشتیبانی از زیرمجموعه‌ای از کتابخانه‌های استاندارد C و C++ و ویژگی‌های زبانی که نیاز به پشتیبانی زمان اجرا دارند، مورد نیاز است. با پیروی از این اصول، برخی از ویژگی ها به دلیل حافظه و/یا وابستگی های گسترده در سطح سیستم عامل به صراحت کنار گذاشته می شوند، و برخی دیگر به دلیل جایگزینی آنها توسط API های مناسب تری مخصوص CHRE. در حالی که قرار نیست فهرستی جامع باشد، قابلیت های زیر در دسترس برنامه های نانو قرار نمی گیرند:

  • استثناهای C++ و اطلاعات نوع زمان اجرا (RTTI)
  • پشتیبانی استاندارد چند رشته ای کتابخانه، از جمله هدرهای C++11 <thread> ، <mutex> ، <atomic> ، <future>
  • کتابخانه های ورودی/خروجی استاندارد C و C++
  • کتابخانه قالب استاندارد C++ (STL)
  • کتابخانه C++ Standard Regular Expressions
  • تخصیص حافظه پویا از طریق توابع استاندارد (به عنوان مثال، malloc ، calloc ، realloc ، free ، operator new )، و دیگر توابع کتابخانه استاندارد که ذاتاً از تخصیص پویا استفاده می کنند، مانند std::unique_ptr
  • محلی سازی و پشتیبانی از کاراکترهای یونیکد
  • کتابخانه های تاریخ و زمان
  • توابعی که جریان نرمال برنامه را تغییر می دهند، از جمله <setjmp.h> ، <signal.h> ، abort ، std::terminate
  • دسترسی به محیط میزبان، از جمله system ، getenv
  • POSIX و سایر کتابخانه‌هایی که در استانداردهای زبان C99 یا C++11 گنجانده نشده‌اند

در بسیاری از موارد، عملکردهای معادل از توابع CHRE API و/یا کتابخانه های ابزار در دسترس است. به عنوان مثال، chreLog می توان برای ثبت اشکال زدایی با هدف سیستم Android logcat استفاده کرد، جایی که یک برنامه سنتی تر ممکن است از 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

در حالی که برخی از پلتفرم‌های زیربنایی از عملکردهای اضافی پشتیبانی می‌کنند، یک نانواپلیکیشن قابل حمل در سراسر پیاده‌سازی CHRE در نظر گرفته نمی‌شود مگر اینکه وابستگی‌های خارجی خود را به توابع CHRE API و عملکردهای استاندارد کتابخانه استاندارد محدود کند.

ویژگی های اختیاری

برای ارتقای سخت‌افزار و نرم‌افزار، CHRE API به بخش‌های ویژگی تقسیم می‌شود که از دیدگاه API اختیاری در نظر گرفته می‌شوند. اگرچه ممکن است این ویژگی‌ها برای پشتیبانی از اجرای CHRE سازگار مورد نیاز نباشند، ممکن است برای پشتیبانی از یک برنامه نانو خاص مورد نیاز باشند. حتی اگر یک پلتفرم از مجموعه معینی از API ها پشتیبانی نکند، نانواپلیکیشن هایی که به آن توابع اشاره می کنند باید بتوانند ساخته و بارگذاری شوند.

حسگرها

CHRE API امکان درخواست داده از حسگرهایی از جمله شتاب سنج، ژیروسکوپ، مغناطیس سنج، حسگر نور محیط و مجاورت را فراهم می کند. این APIها به منظور ارائه مجموعه‌ای از ویژگی‌های مشابه با APIهای سنسورهای Android، از جمله پشتیبانی از نمونه‌های حسگر دسته‌ای برای کاهش مصرف انرژی هستند. پردازش داده‌های حسگر در CHRE، پردازش سیگنال‌های حرکتی را با قدرت بسیار کمتر و تأخیر کمتر در مقایسه با اجرا در AP ممکن می‌سازد.

GNSS

CHRE APIهایی را برای درخواست داده‌های مکان از یک سیستم ماهواره‌ای ناوبری جهانی (GNSS)، از جمله GPS و سایر صورت‌های فلکی ماهواره‌ای فراهم می‌کند. این شامل درخواست‌ها برای اصلاحات دوره‌ای موقعیت، و همچنین داده‌های اندازه‌گیری خام است، اگرچه هر دو قابلیت مستقلی هستند. از آنجایی که CHRE یک پیوند مستقیم به زیرسیستم GNSS دارد، قدرت در مقایسه با درخواست‌های GNSS مبتنی بر AP کاهش می‌یابد، زیرا AP می‌تواند در تمام چرخه زندگی یک جلسه مکان در خواب بماند.

وای فای

CHRE توانایی تعامل با تراشه Wi-Fi را، عمدتاً برای اهداف مکان، فراهم می کند. در حالی که GNSS برای مکان‌های بیرونی به خوبی کار می‌کند، نتایج اسکن‌های Wi-Fi می‌تواند اطلاعات مکان دقیق را در داخل و مناطق توسعه‌یافته ارائه دهد. علاوه بر اجتناب از هزینه بیدار کردن AP برای اسکن، CHRE می‌تواند به نتایج اسکن‌های Wi-Fi انجام شده توسط سفت‌افزار Wi-Fi برای اهداف اتصال گوش دهد، که معمولاً به دلایل برق به AP تحویل داده نمی‌شوند. استفاده از اسکن های اتصال برای اهداف متنی به کاهش تعداد کل اسکن های Wi-Fi انجام شده کمک می کند و در مصرف انرژی صرفه جویی می کند.

پشتیبانی از Wi-Fi در CHRE API نسخه 1.1 اضافه شد، از جمله توانایی نظارت بر نتایج اسکن و شروع اسکن در صورت تقاضا. این قابلیت‌ها در نسخه 1.2 با توانایی انجام اندازه‌گیری‌های زمان رفت و برگشت (RTT) در برابر نقاط دسترسی که از این ویژگی پشتیبانی می‌کنند، گسترش یافتند، که تعیین موقعیت نسبی دقیق را ممکن می‌سازد.

WWAN

CHRE API توانایی بازیابی اطلاعات شناسایی سلول را برای سلول در حال خدمت و همسایگان آن فراهم می کند، که معمولاً برای اهداف مکان یابی درشت استفاده می شود.

سمعی

CHRE می‌تواند دسته‌ای از داده‌های صوتی را از یک میکروفون کم‌مصرف پردازش کند، که معمولاً از سخت‌افزار مورد استفاده برای اجرای SoundTrigger HAL استفاده می‌کند. پردازش داده های صوتی در CHRE می تواند آن را با داده های دیگر مانند حسگرهای حرکت ترکیب کند.

پیاده سازی مرجع

کد مرجع برای چارچوب CHRE در AOSP در پروژه system/chre که در C++11 پیاده سازی شده است، گنجانده شده است. در حالی که به شدت مورد نیاز نیست، برای کمک به اطمینان از ثبات و تسریع در پذیرش قابلیت‌های جدید، برای همه پیاده‌سازی‌های CHRE توصیه می‌شود که بر اساس این پایگاه کد باشند. این کد را می‌توان به‌عنوان آنالوگ چارچوب اصلی اندروید دید، زیرا یک پیاده‌سازی متن‌باز از APIها است که برنامه‌ها از آن استفاده می‌کنند و به‌عنوان خط پایه و استاندارد برای سازگاری عمل می‌کنند. در حالی که می توان آن را با قابلیت های خاص فروشنده سفارشی و گسترش داد، توصیه این است که کد مشترک را تا حد امکان نزدیک به مرجع نگه دارید. مشابه HALهای اندروید، پیاده‌سازی مرجع CHRE از انتزاعات پلتفرم مختلف استفاده می‌کند تا بتواند با هر دستگاهی که حداقل نیازمندی‌ها را دارد، سازگار شود.

برای جزئیات فنی و راهنمای انتقال، به README موجود در پروژه system/chre مراجعه کنید.