شکل زیر پشته حسگر Android را نشان می‌دهد. هر مؤلفه فقط با مؤلفه‌هایی که مستقیماً در بالا و پایین آن قرار دارند ارتباط برقرار می‌کند، هرچند برخی‌از حسگرها می‌توانند درصورت وجود هاب حسگر، آن را دور بزنند. جریان‌ها را از برنامه‌ها به حسگرها و جریان‌های داده را از حسگرها به برنامه‌ها کنترل می‌کند.
شکل ۱. لایه‌های پشته حسگر Android و مالکان مربوطه آن‌ها
کیت توسعه نرم‌افزار (SDK)
برنامه‌ها ازطریق میانای برنامه‌سازی کاربردی Sensors SDK (کیت توسعه نرم‌افزار) به حسگرها دسترسی پیدا می‌کنند. «کیت توسعه نرم‌افزار» حاوی توابعی برای فهرست کردن حسگرهای دردسترس و ثبت حسگر است.
هنگام ثبت‌نام در حسگر، برنامه فرکانس نمونه‌برداری ترجیحی و الزامات تأخیر خود را مشخص می‌کند.
- برای مثال، ممکن است برنامه‌ای در شتاب‌سنج پیش‌فرض ثبت شود، رویدادها را با فرکانس ۱۰۰ هرتز درخواست کند، و اجازه دهد رویدادها با تأخیر ۱ ثانیه‌ای گزارش شوند.
- برنامه رویدادهای شتاب‌سنج را با نرخ حداقل ۱۰۰ هرتز دریافت می‌کند و ممکن است تا ۱ ثانیه تأخیر داشته باشد.
برای کسب اطلاعات بیشتر درباره «کیت توسعه نرم‌افزار»، به اسناد توسعه‌دهنده مراجعه کنید.
Framework
این چارچوب مسئول پیوند دادن چندین برنامه به HAL است. خود HAL تک‌کاربر است. بدون این چندبرابرسازی در سطح چارچوب، تنها یک برنامه می‌تواند در هر زمان به هر حسگر دسترسی داشته باشد.
- وقتی اولین برنامه در حسگری ثبت می‌شود، چارچوب درخواستی برای فعال کردن حسگر به HAL ارسال می‌کند.
- وقتی برنامه‌های دیگری برای همان حسگر ثبت می‌شوند، چارچوب الزامات هر برنامه را درنظر می‌گیرد و پارامترهای درخواست‌شده به‌روزشده را به HAL ارسال می‌کند.
- بسامد نمونه‌گیری حداکثر بسامد نمونه‌گیری درخواستی خواهد بود، یعنی برخی‌از برنامه‌ها رویدادها را با بسامدی بالاتر از بسامد درخواستی خود دریافت خواهند کرد.
- حداکثر تأخیر گزارش‌دهی حداقل مقادیر درخواستی خواهد بود. اگر برنامه‌ای حسگری با بیشینه تأخیر گزارشگری ۰ درخواست کند، همه برنامه‌ها رویدادهای این حسگر را در حالت پیوسته دریافت خواهند کرد، حتی اگر برخی‌از آن‌ها حسگر را با بیشینه تأخیر گزارشگری غیرصفر درخواست کرده باشند. برای جزئیات بیشتر، دسته‌بندی را ببینید.
- وقتی آخرین برنامه ثبت‌شده در یک حسگر از آن لغو ثبت می‌کند، چارچوب‌ها درخواستی به HAL ارسال می‌کند تا حسگر را غیرفعال کند تا برق به‌طور غیرضروری مصرف نشود.
تأثیر چندبرابرسازی
این نیاز به یک لایه چندگانه در چارچوب، برخی‌از تصمیمات طراحی را توضیح می‌دهد.
- وقتی برنامه‌ای درخواست فرکانس نمونه‌برداری خاصی می‌کند، هیچ تضمینی وجود ندارد که رویدادها با نرخ سریع‌تری نرسند. اگر برنامه دیگری همان حسگر را با نرخ سریع‌تری درخواست کند، برنامه اول نیز آن‌ها را با نرخ سریع دریافت خواهد کرد.
- همین عدم تضمین برای بیشینه تأخیر گزارش‌دهی درخواستی نیز اعمال می‌شود: برنامه‌ها ممکن است رویدادهایی با تأخیر بسیار کمتر از آنچه درخواست کرده‌اند دریافت کنند.
- علاوه‌بر بسامد نمونه‌برداری و بیشینه تأخیر گزارش‌دهی، برنامه‌ها نمی‌توانند
پارامترهای حسگر را پیکربندی کنند.
- برای مثال، حسگر فیزیکی‌ای را تصور کنید که می‌تواند هم در حالت «دقت بالا» و هم در حالت «مصرف کم» کار کند.
- فقط یکی از این دو حالت را می‌توان در دستگاه Android استفاده کرد، زیرا درغیراین‌صورت، ممکن است برنامه‌ای حالت دقت بالا را درخواست کند و برنامه دیگری حالت مصرف کم باتری را؛ در این صورت چارچوب نمی‌تواند هر دو برنامه را راضی کند. چارچوب باید همیشه بتواند همه کارخواه‌هایش را برآورده کند، بنابراین این گزینه امکان‌پذیر نیست.
- هیچ سازوکاری برای ارسال داده از برنامه‌ها به حسگرها یا راه‌اندازهای آن‌ها وجود ندارد. این کار تضمین می‌کند که یک برنامه نتواند عملکرد حسگرها را تغییر دهد و باعث ازکار افتادن برنامه‌های دیگر شود.
ادغام حسگر
چارچوب Android پیاده‌سازی پیش‌فرضی برای برخی‌از حسگرهای ترکیبی ارائه می‌دهد. وقتی ژیروسکوپ، شتاب‌سنج، و مغناطیس‌سنج در دستگاهی وجود داشته باشد، اما حسگرهای بردار چرخش، جاذبه، و شتاب خطی وجود نداشته باشد، چارچوب این حسگرها را پیاده‌سازی می‌کند تا برنامه‌ها همچنان بتوانند از آن‌ها استفاده کنند.
پیاده‌سازی پیش‌فرض به همه داده‌هایی که دیگر پیاده‌سازی‌ها به آن‌ها دسترسی دارند دسترسی ندارد و باید در SoC اجرا شود، بنابراین به اندازه دیگر پیاده‌سازی‌ها دقیق و به اندازه آن‌ها در مصرف انرژی کارآمد نیست. تا حد امکان، سازندگان دستگاه باید حسگرهای ترکیبی خودشان (بردار چرخش، شتاب گرانشی و خطی، و همچنین حسگرهای ترکیبی جدیدتر مثل بردار چرخش بازی) را تعریف کنند و به این پیاده‌سازی پیش‌فرض تکیه نکنند. سازندگان دستگاه می‌توانند همچنین از فروشندگان تراشه حسگر بخواهند که پیاده‌سازی را دراختیارشان قرار دهند.
پیاده‌سازی پیش‌فرض ترکیب حسگر نگهداری نمی‌شود و ممکن است باعث شود دستگاه‌هایی که به آن متکی هستند در «آزمون سازگاری» رد شوند.
زیر سرپوش
این بخش به‌عنوان اطلاعات زمینه‌ای برای کسانی که کد چارچوب «پروژه متن‌باز Android» (AOSP) را نگهداری می‌کنند ارائه شده است. برای تولیدکنندگان سخت‌افزار مرتبط نیست.
JNI
این چارچوب از «میانای بومی جاوا» (JNI) مرتبط با android.hardware استفاده می‌کند و در دایرکتوری frameworks/base/core/jni/ قرار دارد. این کد برای دسترسی به سخت‌افزار حسگر، کد بومی سطح پایین‌تر را فرا می‌خواند.
چارچوب بومی
چارچوب بومی در frameworks/native/ تعریف شده است و معادل بومی برای بسته android.hardware ارائه می‌دهد. چارچوب بومی، پراکسی‌های Binder IPC را برای دسترسی به سرویس‌های خاص حسگر فراخوانی می‌کند.
ارتباط میان پردازشی Binder
کارگزاران نیابتی IPC Binder ارتباط را در مرزهای فرایند تسهیل می‌کنند.
HAL
«میانای برنامه‌سازی کاربردی لایه انتزاع سخت‌افزار حسگرها» (HAL) رابط بین گردانندگان سخت‌افزار و چارچوب Android است. این عملکرد از یک میانای HAL sensors.h و یک پیاده‌سازی HAL که از آن به‌عنوان sensors.cpp یاد می‌کنیم تشکیل شده است.
میانای کاربری توسط Android و همیاران AOSP تعریف می‌شود و پیاده‌سازی توسط سازنده دستگاه ارائه می‌شود.
میانای HAL حسگر در hardware/libhardware/include/hardware قرار دارد.
برای جزئیات بیشتر، sensors.h
را ببینید.
دوره انتشار
پیاده‌سازی HAL با تنظیم your_poll_device.common.version مشخص می‌کند که از کدام نسخه میانای HAL استفاده می‌کند. نسخه‌های میانای HAL موجود در sensors.h تعریف شده‌اند و عملکرد به آن نسخه‌ها مرتبط است.
چارچوب Android درحال‌حاضر از نسخه‌های ۱.۰ و ۱.۳ پشتیبانی می‌کند، اما به‌زودی دیگر از نسخه ۱.۰ پشتیبانی نخواهد شد. این سند رفتار نسخه ۱.۳ را شرح می‌دهد که همه دستگاه‌ها باید به آن ارتقا یابند. برای جزئیات مربوط به نحوه ارتقا به نسخه ۱.۳، به منسوخ شدن نسخه HAL مراجعه کنید.
درایور هسته
گردانندگان حسگر با دستگاه‌های فیزیکی تعامل دارند. در برخی موارد، پیاده‌سازی HAL و درایورها یک موجودیت نرم‌افزاری هستند. در موارد دیگر، ادغام‌کننده سخت‌افزار از سازندگان تراشه حسگر می‌خواهد تا درایورها را ارائه دهند، اما خودشان پیاده‌سازی HAL را می‌نویسند.
در همه موارد، پیاده‌سازی HAL و درایورهای هسته برعهده تولیدکنندگان سخت‌افزار است و Android رویکردهای ترجیحی برای نوشتن آن‌ها ارائه نمی‌دهد.
مرکز حسگر
پشته حسگر دستگاه می‌تواند به‌صورت اختیاری شامل مرکز حسگر باشد که برای انجام برخی محاسبات سطح پایین با توان کم درحالی‌که SoC می‌تواند در حالت تعلیق باشد مفید است. برای مثال، شمارش قدم‌ها یا ترکیب حسگر می‌تواند در این تراشه‌ها انجام شود. همچنین مکان خوبی برای پیاده‌سازی دسته‌بندی حسگر، افزودن سخت‌افزار FIFO برای رویدادهای حسگر است. برای اطلاعات بیشتر، دسته‌بندی را ببینید.
توجه: برای توسعه ویژگی‌های جدید ContextHub که از حسگرها یا LEDهای جدید استفاده می‌کنند، می‌توانید از Neonkey SensorHub متصل به برد توسعه Hikey یا Hikey960 نیز استفاده کنید.
نحوه تحقق هاب حسگر به معماری بستگی دارد. این مرکز گاهی تراشه‌ای جداگانه است و گاهی در همان تراشه SoC قرار دارد. از ویژگی‌های مهم مرکز حسگر این است که باید حافظه کافی برای دسته‌بندی داشته باشد و مصرف برق بسیار کمی داشته باشد تا بتوان حسگرهای کم‌مصرف Android را پیاده‌سازی کرد. برخی‌از مراکز حسگر دارای ریزکنترل‌گر برای محاسبات عمومی و شتاب‌دهنده‌های سخت‌افزاری برای فعال کردن محاسبات با توان بسیار پایین برای حسگرهای کم‌مصرف هستند.
نحوه معماری مرکز حسگر و نحوه ارتباط آن با حسگرها و SoC (گذرگاه I2C، گذرگاه SPI، و غیره) توسط Android مشخص نشده است، اما باید هدف آن به حداقل رساندن مصرف کلی برق باشد.
یکی از گزینه‌هایی که به‌نظر می‌رسد تأثیر قابل‌توجهی بر سادگی پیاده‌سازی دارد، داشتن دو خط وقفه از مرکز حسگر به SoC است: یکی برای وقفه‌های بیدار شدن (برای حسگرهای بیدار شدن) و دیگری برای وقفه‌های غیربیدار شدن (برای حسگرهای غیربیدار شدن).
حسگرها
این‌ها تراشه‌های فیزیکی MEMs هستند که اندازه‌گیری‌ها را انجام می‌دهند. در بسیاری از موارد، چندین حسگر فیزیکی در یک تراشه وجود دارد. برای مثال، برخی‌از تراشه‌ها شامل شتاب‌سنج، ژیروسکوپ، و مغناطیس‌سنج هستند. (چنین تراشه‌هایی اغلب تراشه‌های ۹ محوره نامیده می‌شوند، زیرا هر حسگر داده‌ها را در ۳ محور ارائه می‌دهد.)
برخی‌از این تراشه‌ها همچنین دارای منطقی برای انجام محاسبات معمول مثل تشخیص حرکت، تشخیص گام، و ترکیب حسگر ۹ محوره هستند.
اگرچه الزامات و توصیه‌های مربوط به دقت و مصرف برق CDD حسگر Android را هدف قرار می‌دهند و نه حسگرهای فیزیکی را، این الزامات بر انتخاب حسگرهای فیزیکی تأثیر می‌گذارند. برای مثال، الزامات دقت در بردار چرخش بازی بر دقت موردنیاز برای ژیروسکوپ فیزیکی تأثیر می‌گذارد. این وظیفه سازنده دستگاه است که الزامات مربوط به حسگرهای فیزیکی را تعیین کند.