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 و سیستم زیرین API از طریق CHRE تعامل دارند. 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 مراجعه کنید.

،

گوشی های هوشمند دارای تعدادی پردازنده هستند که هر کدام برای انجام وظایف مختلف بهینه شده اند. با این حال، اندروید فقط روی یک پردازنده اجرا می شود: پردازنده برنامه ها (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 و سیستم زیرین API از طریق CHRE تعامل دارند. 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 می تواند دسته های داده های صوتی را از یک میکروفون کم مصرف پردازش کند ، که به طور معمول از سخت افزار مورد استفاده برای اجرای HAL Soundtrigger استفاده می کند. پردازش داده های صوتی در CHRE می تواند آن را با داده های دیگر مانند سنسورهای حرکتی ذوب شود.

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

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

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

،

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

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

مفاهیم کلیدی

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

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

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

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

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

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

مرکز توپی هال

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

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

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

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

نانوپه ها را بارگیری و بارگیری کنید

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

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

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

مرکز توپی دوباره راه اندازی می شود

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

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

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

ساخت سیستم

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

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

chre api

CHRE API مجموعه ای از پرونده های هدر C است که رابط نرم افزاری بین NanoApp و سیستم را تعریف می کند. این طراحی شده است تا کد NanoApps را در تمام دستگاه هایی که از CHRE پشتیبانی می کنند سازگار باشد ، به این معنی که برای پشتیبانی از یک نوع دستگاه جدید ، کد منبع برای NanoApp نیازی به اصلاح ندارد ، اگرچه ممکن است برای مجموعه دستورالعمل پردازنده دستگاه هدف یا رابط باینری برنامه (ABI) به طور خاص مجدداً مورد استفاده قرار گیرد. معماری CHRE و طراحی API همچنین اطمینان حاصل می کنند که نانوپه ها در بین نسخه های مختلف CHRE API سازگار هستند ، به این معنی که برای اجرای روی سیستمی که نسخه متفاوتی از API chre را در مقایسه با API هدف که NanoApp در برابر آن تشکیل شده است ، نیازی به استفاده مجدد ندارد. به عبارت دیگر ، اگر یک باینری NanoApp بر روی دستگاهی اجرا شود که از CHRE API V1.3 پشتیبانی می کند ، و آن دستگاه برای پشتیبانی از CHRE API V1.4 به روز می شود ، همان دودویی NanoApp همچنان عملکرد خود را ادامه می دهد. به طور مشابه ، NanoApp می تواند روی CHRE API V1.2 اجرا شود ، و می تواند در زمان اجرا تعیین کند که آیا برای دستیابی به استفاده از آن به قابلیت های API V1.3 نیاز دارد ، یا اینکه آیا می تواند کار کند ، به طور بالقوه با تخریب ویژگی های برازنده.

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

خلاصه نسخه

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

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

نسخه 1.0 (Android 7)

شامل پشتیبانی از سنسورها ، و قابلیت های اصلی NanoApp مانند رویدادها و تایمرها است.

نسخه 1.1 (Android 8)

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

نسخه 1.2 (Android 9)

پشتیبانی از داده های یک میکروفون کم مصرف ، Wi-Fi RTT ، اعلان های AP Wake and Sleep و سایر پیشرفت ها را پشتیبانی می کند.

نسخه 1.3 (Android 10)

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

نسخه 1.4 (Android 11)

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

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

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

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

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

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

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

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

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

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

حسگرها

CHRE API امکان درخواست داده ها از سنسورها از جمله شتاب سنج ، ژیروسکوپ ، مغناطیس سنج ، سنسور نور محیط و نزدیکی را فراهم می کند. این API ها به منظور ارائه یک مجموعه ویژگی مشابه API های Android Sensors ، از جمله پشتیبانی از نمونه های سنسور دسته بندی برای کاهش مصرف برق هستند. پردازش داده های سنسور در 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 V1.1 ، از جمله توانایی نظارت بر نتایج اسکن و اسکن های محرک بر روی تقاضا اضافه شد. این قابلیت ها در V1.2 با امکان انجام اندازه گیری زمان سفر به دور (RTT) در برابر نقاط دسترسی که از این ویژگی پشتیبانی می کنند ، گسترش یافته است ، که این امر تعیین موقعیت نسبی دقیق را امکان پذیر می کند.

WWAN

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

صوتی

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

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

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

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

،

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

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

مفاهیم کلیدی

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

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

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

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

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

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

مرکز توپی هال

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

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

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

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

نانوپه ها را بارگیری و بارگیری کنید

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

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

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

مرکز توپی دوباره راه اندازی می شود

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

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

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

ساخت سیستم

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

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

chre api

CHRE API مجموعه ای از پرونده های هدر C است که رابط نرم افزاری بین NanoApp و سیستم را تعریف می کند. این طراحی شده است تا کد NanoApps را در تمام دستگاه هایی که از CHRE پشتیبانی می کنند سازگار باشد ، به این معنی که برای پشتیبانی از یک نوع دستگاه جدید ، کد منبع برای NanoApp نیازی به اصلاح ندارد ، اگرچه ممکن است برای مجموعه دستورالعمل پردازنده دستگاه هدف یا رابط باینری برنامه (ABI) به طور خاص مجدداً مورد استفاده قرار گیرد. معماری CHRE و طراحی API همچنین اطمینان حاصل می کنند که نانوپه ها در بین نسخه های مختلف CHRE API سازگار هستند ، به این معنی که برای اجرای روی سیستمی که نسخه متفاوتی از API chre را در مقایسه با API هدف که NanoApp در برابر آن تشکیل شده است ، نیازی به استفاده مجدد ندارد. به عبارت دیگر ، اگر یک باینری NanoApp بر روی دستگاهی اجرا شود که از CHRE API V1.3 پشتیبانی می کند ، و آن دستگاه برای پشتیبانی از CHRE API V1.4 به روز می شود ، همان دودویی NanoApp همچنان عملکرد خود را ادامه می دهد. به طور مشابه ، NanoApp می تواند روی CHRE API V1.2 اجرا شود ، و می تواند در زمان اجرا تعیین کند که آیا برای دستیابی به استفاده از آن به قابلیت های API V1.3 نیاز دارد ، یا اینکه آیا می تواند کار کند ، به طور بالقوه با تخریب ویژگی های برازنده.

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

خلاصه نسخه

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

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

نسخه 1.0 (Android 7)

شامل پشتیبانی از سنسورها ، و قابلیت های اصلی NanoApp مانند رویدادها و تایمرها است.

نسخه 1.1 (Android 8)

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

نسخه 1.2 (Android 9)

پشتیبانی از داده های یک میکروفون کم مصرف ، Wi-Fi RTT ، اعلان های AP Wake and Sleep و سایر پیشرفت ها را پشتیبانی می کند.

نسخه 1.3 (Android 10)

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

نسخه 1.4 (Android 11)

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

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

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

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

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

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

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

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

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

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

حسگرها

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

GNSS

CHRE API را برای درخواست داده های مکان از یک سیستم ماهواره ای ناوبری جهانی (GNSS) ، از جمله GPS و سایر صورتهای فلکی ماهواره ، تهیه می کند. This includes requests for periodic position fixes, as well as raw measurement data, though both are independent capabilities. As CHRE has a direct link to the GNSS subsystem, power is reduced compared to AP-based GNSS requests, because the AP can stay asleep during the entire lifecycle of a location session.

وای فای

CHRE provides the ability to interact with the Wi-Fi chip, primarily for location purposes. While GNSS works well for outdoor locations, the results of Wi-Fi scans can provide accurate location information indoors and in developed areas. In addition to avoiding the cost of waking the AP for a scan, CHRE can listen to the results of Wi-Fi scans performed by the Wi-Fi firmware for connectivity purposes, which typically aren't delivered to the AP for power reasons. Leveraging connectivity scans for contextual purposes helps to reduce the total number of Wi-Fi scans performed, saving power.

Support for Wi-Fi was added in CHRE API v1.1, including the ability to monitor scan results and trigger scans on demand. These capabilities were extended in v1.2 with the ability to perform Round-Trip Time (RTT) measurements against access points that support the feature, which enables accurate relative position determination.

WWAN

The CHRE API provides the ability to retrieve cell identification information for the serving cell and its neighbors, which is typically used for coarse-grained location purposes.

صوتی

CHRE can process batches of audio data from a low-power microphone, which typically leverages hardware used to implement the SoundTrigger HAL. Processing audio data in CHRE can enable it to be fused with other data, such as motion sensors.

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

Reference code for the CHRE framework is included in AOSP in the system/chre project, implemented in C++11. While not strictly required, it's recommended for all CHRE implementations to be based off of this codebase, to help ensure consistency and accelerate adoption of new capabilities. This code can be seen as an analogue to the core Android framework in that it's an open-source implementation of APIs that apps use, serving as a baseline and standard for compatibility. While it can be customized and extended with vendor-specific capabilities, the recommendation is to maintain the common code as close to the reference as possible. Similar to the HALs of Android, the CHRE reference implementation uses various platform abstractions to enable it to be adapted to any device meeting the minimum requirements.

For technical details and a porting guide, see the README included in the system/chre project.