בתרשים הבא מוצגת ערימת החיישנים של Android. כל רכיב מתקשר רק עם הרכיבים שנמצאים ישירות מעליו ומתחתיו, אבל חלק מהחיישנים יכולים לעקוף את מרכז החיישנים אם הוא קיים. השליטה בזרימת הנתונים מתבצעת מהאפליקציות אל החיישנים, וזרימת הנתונים מתבצעת מהחיישנים אל האפליקציות.
איור 1. שכבות של מחסנית חיישני Android והבעלים שלהן
SDK
אפליקציות ניגשות לחיישנים דרך Sensors SDK (ערכת פיתוח תוכנה) API. ערכת ה-SDK מכילה פונקציות להצגת רשימה של חיישנים זמינים ולרישום לחיישן.
כשנרשמים לחיישן, האפליקציה מציינת את תדירות הדגימה המועדפת ואת דרישות זמן האחזור שלה.
- לדוגמה, אפליקציה יכולה להירשם למד התאוצה שמוגדר כברירת מחדל, לבקש אירועים בתדירות של 100Hz ולאפשר דיווח על אירועים עם השהיה של שנייה אחת.
- האפליקציה תקבל אירועים מהמד תאוצה בקצב של 100Hz לפחות, ויכול להיות שיהיה עיכוב של עד שנייה אחת.
מידע נוסף על ה-SDK זמין במסמכי התיעוד למפתחים.
Framework
המסגרת אחראית לקישור בין כמה אפליקציות לבין HAL. ה-HAL עצמו הוא חד-לקוח. בלי הריבוב הזה ברמת המסגרת, רק אפליקציה אחת יכולה לגשת לכל חיישן בכל זמן נתון.
- כשאפליקציה ראשונה נרשמת לחיישן, המסגרת שולחת בקשה ל-HAL כדי להפעיל את החיישן.
- כשיישומים נוספים נרשמים לאותו חיישן, המסגרת לוקחת בחשבון את הדרישות של כל יישום ושולחת את הפרמטרים המעודכנים שנדרשים ל-HAL.
- תדירות הדגימה תהיה המקסימום מבין תדירויות הדגימה המבוקשות, כלומר חלק מהאפליקציות יקבלו אירועים בתדירות גבוהה יותר מזו שהן ביקשו.
- החביון המקסימלי של הדיווח יהיה המינימום מבין הערכים שצוינו בבקשה. אם אפליקציה אחת מבקשת חיישן אחד עם חביון דיווח מקסימלי של 0, כל האפליקציות יקבלו את האירועים מהחיישן הזה במצב רציף, גם אם חלק מהן ביקשו את החיישן עם חביון דיווח מקסימלי שאינו אפס. פרטים נוספים מופיעים במאמר בנושא הוספת כמה מוצרים בבת אחת.
- כשהאפליקציה האחרונה שרשומה לחיישן מסוים מבטלת את הרישום שלה, המסגרות שולחות בקשה ל-HAL כדי להשבית את החיישן, וכך לא נצרכת אנרגיה שלא לצורך.
השפעת ה-multiplexing
הצורך בשכבת ריבוב במסגרת מסביר חלק מההחלטות העיצוביות.
- כשיישום מבקש תדירות דגימה ספציפית, אין ערובה לכך שהאירועים לא יגיעו בקצב מהיר יותר. אם אפליקציה אחרת ביקשה את אותו החיישן בקצב מהיר יותר, גם האפליקציה הראשונה תקבל את הנתונים בקצב המהיר.
- אותו חוסר ודאות חל גם על זמן האחזור המקסימלי המבוקש של הדיווח: יכול להיות שאפליקציות יקבלו אירועים עם זמן אחזור קצר בהרבה ממה שהן ביקשו.
- בנוסף לתדירות הדגימה ולחביון המקסימלי של הדיווח, אפליקציות לא יכולות להגדיר פרמטרים של חיישנים.
- לדוגמה, נניח שיש חיישן פיזי שיכול לפעול גם במצב 'דיוק גבוה' וגם במצב 'צריכת חשמל נמוכה'.
- אפשר להשתמש רק באחד משני המצבים האלה במכשיר Android, כי אחרת, אפליקציה אחת תוכל לבקש את מצב הדיוק הגבוה, ואפליקציה אחרת תוכל לבקש את מצב חיסכון בסוללה. לא תהיה דרך למסגרת לספק את שתי האפליקציות. המסגרת צריכה תמיד להיות מסוגלת לספק את כל הלקוחות שלה, ולכן האפשרות הזו לא מתאימה.
- אין מנגנון לשליחת נתונים מהאפליקציות לחיישנים או למנהלי ההתקנים שלהם. כך אפליקציה אחת לא יכולה לשנות את ההתנהגות של החיישנים ולפגוע באפליקציות אחרות.
מיזוג נתונים מחיישנים
מסגרת Android מספקת הטמעה של ברירת מחדל לחלק מהחיישנים המורכבים. אם במכשיר יש ג'ירוסקופ, מד תאוצה ומגנטומטר, אבל אין חיישני ווקטור סיבוב, כבידה ותאוצה ליניארית, המסגרת מטמיעה את החיישנים האלה כדי שאפליקציות יוכלו להשתמש בהם.
להטמעה שמוגדרת כברירת מחדל אין גישה לכל הנתונים שיש להטמעות אחרות, והיא חייבת לפעול ב-SoC, ולכן היא לא מדויקת או חסכונית באנרגיה כמו הטמעות אחרות. ככל האפשר, יצרני מכשירים צריכים להגדיר חיישנים משולבים משלהם (וקטור סיבוב, כוח כבידה ותאוצה לינארית, וגם חיישנים מורכבים חדשים יותר כמו וקטור הסיבוב של המשחק) במקום להסתמך על יישום ברירת המחדל הזה. יצרני מכשירים יכולים גם לבקש מספקי שבבי חיישנים לספק להם הטמעה.
ההטמעה של שילוב החיישנים שמוגדרת כברירת מחדל לא מתעדכנת, ויכול להיות שהיא תגרום למכשירים שמסתמכים עליה להיכשל ב-CTS.
אפשרויות מתקדמות
הקטע הזה מיועד לספק מידע כללי למי שמנהל את קוד המסגרת של פרויקט הקוד הפתוח של Android (AOSP). הוא לא רלוונטי ליצרני חומרה.
JNI
המסגרת משתמשת בממשק Java Native Interface (JNI) שמשויך ל-android.hardware וממוקם בספרייה frameworks/base/core/jni/. הקוד הזה קורא לקוד Native ברמה נמוכה יותר כדי לקבל גישה לחומרה של החיישן.
מסגרת מקורית
מסגרת ה-Native מוגדרת ב-frameworks/native/ ומספקת מקבילה של Native לחבילה android.hardware. המסגרת המקורית קוראת ל-proxies של Binder IPC כדי לקבל גישה לשירותים ספציפיים של חיישנים.
Binder IPC
פרוקסי של Binder IPC מאפשרים תקשורת בין גבולות התהליך.
HAL
ממשק ה-API של שכבת הפשטת החומרה (HAL) של החיישנים הוא הממשק בין דרייברי החומרה לבין מסגרת Android. היא מורכבת מממשק HAL אחד, sensors.h, ומיישום HAL אחד שאנחנו מכנים sensors.cpp.
הממשק מוגדר על ידי Android ועל ידי תורמים ל-AOSP, וההטמעה מסופקת על ידי יצרן המכשיר.
ממשק חיישן HAL נמצא ב-hardware/libhardware/include/hardware.
פרטים נוספים מופיעים ב-sensors.h.
מחזור הפצה
ההטמעה של HAL מציינת איזו גרסה של ממשק HAL היא מטמיעה על ידי הגדרת your_poll_device.common.version. גרסאות הממשק הקיימות של HAL מוגדרות בקובץ sensors.h, והפונקציונליות קשורה לגרסאות האלה.
מסגרת Android תומכת כרגע בגרסאות 1.0 ו-1.3, אבל בקרוב לא תהיה יותר תמיכה בגרסה 1.0. במסמכי התיעוד האלה מתוארת ההתנהגות של גרסה 1.3, שכל המכשירים צריכים לשדרג אליה. לפרטים על שדרוג לגרסה 1.3, אפשר לעיין במאמר בנושא הוצאה משימוש של גרסת HAL.
Kernel driver
מנהלי ההתקנים של החיישנים יוצרים אינטראקציה עם המכשירים הפיזיים. במקרים מסוימים, הטמעת ה-HAL ומנהלי ההתקן הם אותה ישות תוכנה. במקרים אחרים, משלבי החומרה מבקשים מיצרני שבבי החיישנים לספק את מנהלי ההתקנים, אבל הם אלה שכותבים את הטמעת ה-HAL.
בכל המקרים, הטמעת HAL ומנהלי התקנים של ליבת המערכת הם באחריות יצרני החומרה, ו-Android לא מספקת גישות מועדפות לכתיבתם.
Sensor hub
מערך החיישנים של מכשיר יכול לכלול באופן אופציונלי רכזת חיישנים, שימושית לביצוע חישובים מסוימים ברמה נמוכה בצריכת חשמל נמוכה, בזמן שה-SoC יכול להיות במצב השהיה. לדוגמה, אפשר לבצע ספירת צעדים או מיזוג חיישנים בצ'יפים האלה. זה גם מקום טוב להטמעת אצווה של חיישנים, ולהוספת FIFO של חומרה לאירועים של החיישנים. מידע נוסף זמין במאמר בנושא עיבוד באצווה.
הערה: כדי לפתח תכונות חדשות של ContextHub שמשתמשות בחיישנים או בנוריות LED חדשים, אפשר גם להשתמש ב-Neonkey SensorHub שמחובר ללוח פיתוח Hikey או Hikey960.
האופן שבו ה-sensor hub ממומש תלוי בארכיטקטורה. לפעמים זהו שבב נפרד, ולפעמים הוא כלול באותו שבב כמו ה-SoC. מאפיינים חשובים של מרכז החיישנים הם שהוא צריך להכיל מספיק זיכרון לאיגום, ולצרוך מעט מאוד חשמל כדי לאפשר הטמעה של חיישני Android עם צריכת חשמל נמוכה. חלק ממרכזי החיישנים מכילים מיקרו-בקר לחישובים כלליים, ומאיצי חומרה שמאפשרים חישובים עם צריכת חשמל נמוכה מאוד עבור חיישנים עם צריכת חשמל נמוכה.
הארכיטקטורה של ה-sensor hub והאופן שבו הוא מתקשר עם החיישנים ועם ה-SoC (אפיק I2C, אפיק SPI וכו') לא מוגדרים על ידי Android, אבל המטרה היא למזער את צריכת החשמל הכוללת.
אחת האפשרויות שנראה שיש לה השפעה משמעותית על פשטות ההטמעה היא שימוש בשני קווי הפרעה שיוצאים ממרכז החיישנים אל ה-SoC: קו אחד להפרעות של התעוררות (לחיישני התעוררות), וקו שני להפרעות שאינן של התעוררות (לחיישנים שאינם של התעוררות).
חיישנים
אלה שבבים פיזיים של MEMS שמבצעים את המדידות. במקרים רבים, יש כמה חיישנים פיזיים על אותו שבב. לדוגמה, חלק מהשבבים כוללים מד תאוצה, ג'ירוסקופ ומגנטומטר. (שבבים כאלה נקראים בדרך כלל שבבים עם 9 צירים, כי כל חיישן מספק נתונים על פני 3 צירים).
חלק מהצ'יפים האלה מכילים גם לוגיקה מסוימת לביצוע חישובים רגילים, כמו זיהוי תנועה, זיהוי צעדים ומיזוג נתונים מחיישן 9 צירים.
למרות שהדרישות וההמלצות לגבי עוצמה ודיוק של CDD מיועדות לחיישן Android ולא לחיישנים הפיזיים, הדרישות האלה משפיעות על הבחירה של החיישנים הפיזיים. לדוגמה, דרישת הדיוק של וקטור הסיבוב במשחק משפיעה על רמת הדיוק הנדרשת של הג'ירוסקופ הפיזי. הדרישות לגבי חיישנים פיזיים נקבעות על ידי יצרן המכשיר.