בתרשים הבא מוצג סטאק החיישנים של Android. כל רכיב מתקשר רק עם הרכיבים שמעליו ומתחתיו, אבל חלק מהחיישנים יכולים לעקוף את מרכז החיישנים אם הוא נמצא. השליטה זורמת מהאפליקציות אל החיישנים, והנתונים זורמים מהחיישנים אל האפליקציות.
איור 1. השכבות של מחסנית החיישנים של Android והבעלים שלהן
SDK
אפליקציות ניגשות לחיישנים דרך Sensors SDK API (ערכת כלים לפיתוח תוכנה). ה-SDK מכיל פונקציות להצגת רשימה של חיישנים זמינים ולרישום לחיישן.
כשרושמים חיישן, האפליקציה מציינת את תדירות הדגימה המועדפת ואת דרישות זמן האחזור שלה.
- לדוגמה, אפליקציה עשויה להירשם לתאוצה שמוגדרת כברירת מחדל, לבקש אירועים ב-100Hz ולאפשר דיווח על אירועים עם זמן אחזור של שנייה אחת.
- האפליקציה תקבל אירועים מהאצ"ל בקצב של לפחות 100Hz, ויכול להיות עיכוב של עד שנייה.
מידע נוסף על ה-SDK זמין במסמכי התיעוד למפתחים.
Framework
המסגרת אחראית לקישור בין האפליקציות השונות ל-HAL. ה-HAL עצמו הוא לקוח יחיד. בלי המיפוי הזה ברמת המסגרת, רק אפליקציה אחת יכולה לגשת לכל חיישן בכל זמן נתון.
- כשאפליקציה ראשונה מתחברת לחיישן, המסגרת שולחת בקשה ל-HAL כדי להפעיל את החיישן.
- כשאפליקציות נוספות נרשמות לאותו חיישן, המסגרת מביאה בחשבון את הדרישות מכל אפליקציה ושולחת את הפרמטרים המעודכנים המבוקשים ל-HAL.
- תדירות הדגימה תהיה התדירות הגבוהה ביותר מבין תדירות הדגימה המבוקשות, כלומר חלק מהאפליקציות יקבלו אירועים בתדירות גבוהה יותר מהתדירות שביקשו.
- זמן האחזור המקסימלי לדיווח יהיה המינימום מבין הזמנים המבוקשים. אם אפליקציה אחת מבקשת חיישן אחד עם זמן אחזור מקסימלי לדיווח של 0, כל האפליקציות יקבלו את האירועים מהחיישן הזה במצב רציף, גם אם חלק מהן ביקשו את החיישן עם זמן אחזור מקסימלי לדיווח שאינו אפס. פרטים נוספים זמינים במאמר אוסף בקשות.
- כשהאפליקציה האחרונה שרשומה לחיישן אחד מבטלת את הרישום שלו, המסגרות שולחות בקשה ל-HAL להשבית את החיישן כדי שלא יתבצע צריכת אנרגיה מיותרת.
ההשפעה של multiplexing
הצורך בשכבת מרבולן במסגרת מסביר חלק מההחלטות שקשורות לעיצוב.
- כשאפליקציה מבקשת תדירות דגימה ספציפית, אין ערובה שהאירועים לא יגיעו בקצב מהיר יותר. אם אפליקציה אחרת ביקשה את אותו חיישן בקצב מהיר יותר, גם האפליקציה הראשונה תקבל אותו בקצב המהיר.
- אותו חוסר התחייבות חל על זמן האחזור המקסימלי הנדרש לדיווח: יכול להיות שאפליקציות יקבלו אירועים עם זמן אחזור קצר בהרבה מהזמן שהן ביקשו.
- בנוסף לתדירות הדגימה ולזמן האחזור המקסימלי לדיווח, לאפליקציות אין אפשרות להגדיר פרמטרים של חיישנים.
- לדוגמה, נניח שיש חיישן פיזי שיכול לפעול גם במצב 'דיוק גבוה' וגם במצב 'צריכת אנרגיה נמוכה'.
- אפשר להשתמש רק באחד משני המצבים האלה במכשיר Android, כי אחרת אפליקציה אחת עשויה לבקש את מצב הדיוק הגבוה ואפליקציה אחרת עשויה לבקש את מצב צריכת האנרגיה הנמוכה, ולא תהיה שום דרך למסגרת לעמוד בדרישות של שתי האפליקציות. התשתית תמיד צריכה לעמוד בדרישות של כל הלקוחות שלה, ולכן זו לא אפשרות.
- אין מנגנון לשליחת נתונים מהאפליקציות אל החיישנים או אל מנהלי ההתקנים שלהם. כך אפשר לוודא שאפליקציה אחת לא תוכל לשנות את התנהגות החיישנים, וכך לגרום לשיבושים באפליקציות אחרות.
שילוב חיישנים
מסגרת Android מספקת הטמעה שמוגדרת כברירת מחדל לחלק מהחיישנים המשולבים. כשיש במכשיר ג'ירוסקופ, מד תאוצה ומגנטומטר, אבל אין חיישנים של וקטור סיבוב, כבידה ותאוצה לינארית, המסגרת מטמיעה את החיישנים האלה כדי שאפליקציות עדיין יוכלו להשתמש בהם.
להטמעת ברירת המחדל אין גישה לכל הנתונים שיש להטמעות אחרות גישה אליהם, והיא חייבת לפעול ב-SoC, כך שהיא לא מדויקת או חסכונית באנרגיה כמו הטמעות אחרות. ככל האפשר, יצרני המכשירים צריכים להגדיר חיישנים משולבים משלהם (וקטור סיבוב, כוח משיכה ותאוצה לינארית, וגם חיישנים מורכבים יותר כמו וקטור הסיבוב במשחק) במקום להסתמך על ההטמעה שמוגדרת כברירת מחדל. יצרני מכשירים יכולים גם לבקש מספקי צ'יפים של חיישנים לספק להם הטמעה.
הטמעת ברירת המחדל של שילוב החיישנים לא מתבצעת, ויכול להיות שהיא תגרום למכשירים שמסתמכים עליה להיכשל ב-CTS.
הגדרות
הקטע הזה מיועד למפתחים שמטפלים בקוד של מסגרת Android Open Source Project (AOSP). הוא לא רלוונטי ליצרני חומרה.
JNI
המסגרת משתמשת בממשק Java Native Interface (JNI) שמשויך ל-android.hardware וממוקם בספרייה frameworks/base/core/jni/. הקוד הזה קורא לקוד הנייטיב ברמה נמוכה יותר כדי לקבל גישה לחומרה של החיישן.
מסגרת מקורית
המסגרת המקורית מוגדרת ב-frameworks/native/ ומספקת מקבילה מקורית לחבילה android.hardware. המסגרת המקורית קוראת לשרתי ה-proxy של Binder IPC כדי לקבל גישה לשירותים ספציפיים לחיישנים.
Binder IPC
שרת ה-proxy של IPC ב-Binder מאפשר תקשורת מעבר לגבולות התהליכים.
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.
מנהל ליבה
מנהלי ההתקנים של החיישנים יוצרים אינטראקציה עם המכשירים הפיזיים. במקרים מסוימים, ההטמעה של HAL והמנהלים הם אותה ישות תוכנה. במקרים אחרים, חברת השילוב של החומרה מבקשת מיצרני צ'יפים של חיישנים לספק את מנהלי ההתקנים, אבל הם אלה שכותבים את הטמעת ה-HAL.
בכל המקרים, יישום HAL ומנהלי הליבה הם באחריות יצרני החומרה, ו-Android לא מספקת גישות מועדפות לכתיבה שלהם.
מרכז חיישנים
אפשר לכלול בסטאק החיישנים של המכשיר גם מרכז חיישנים, ששימושי לביצוע חישובים ברמה נמוכה עם צריכת אנרגיה נמוכה, בזמן שה-SoC יכול להיות במצב השהיה. לדוגמה, אפשר לבצע על הצ'יפים האלה ספירת צעדים או שילוב חיישנים. זה גם מקום טוב להטמיע בו ארגון נתונים בקבוצות (batching) של חיישנים, ולהוסיף FIFO של חומרה לאירועי החיישנים. מידע נוסף זמין במאמר אוסף בקשות.
הערה: כדי לפתח תכונות חדשות של ContextHub שמשתמשות בחיישני LED או חיישנים חדשים, אפשר גם להשתמש ב-Neonkey SensorHub שמחובר ללוח פיתוח של Hikey או Hikey960.
אופן המטא-מידע של מרכז החיישנים תלוי בארכיטקטורה. לפעמים הוא צ'יפ נפרד, ולפעמים הוא כלול באותו צ'יפ כמו ה-SoC. מאפיינים חשובים של מרכז החיישנים הם שהוא צריך להכיל מספיק זיכרון לצורך צבירה (batching) ולצרוך מעט מאוד חשמל כדי לאפשר הטמעה של חיישני Android עם צריכת אנרגיה נמוכה. חלק ממרכזי החיישנים מכילים מיקרו-בקר לחישוב גנרי ומאיצי חומרה שמאפשרים חישוב בצריכת אנרגיה נמוכה מאוד לחיישנים בעלי צריכת אנרגיה נמוכה.
ארכיטקטורת מרכז החיישנים והאופן שבו הוא מתקשר עם החיישנים ועם המעבד (I2C bus, SPI bus וכו') לא מצוינים ב-Android, אבל צריך לשאוף למזער את צריכת האנרגיה הכוללת.
אפשרות אחת שנראה שיש לה השפעה משמעותית על פשטוּת ההטמעה היא שימוש בשתי שורות השבתה (interrupt) שמגיעות ממרכז החיישנים ל-SoC: אחת להשבתה מעוררת (לחיישנים מעוררים) והשנייה להשבתה לא מעוררת (לחיישנים לא מעוררים).
חיישנים
אלה הם צ'יפים פיזיים של MEMs שמבצעים את המדידות. במקרים רבים, כמה חיישנים פיזיים נמצאים באותו צ'יפ. לדוגמה, צ'יפים מסוימים כוללים מד תאוצה, ג'ירוסקופ ומגנטומטר. (לרוב, צ'יפים כאלה נקראים צ'יפים עם 9 צירים, כי כל חיישן מספק נתונים על 3 צירים).
חלק מהשבבים האלה מכילים גם לוגיקה מסוימת לביצוע חישובים רגילים, כמו זיהוי תנועה, זיהוי צעדים ומילוי של חיישנים ב-9 צירים.
למרות שההמלצות והדרישות לגבי העוצמה והדיוק של CDD מיועדות לחיישן Android ולא לחיישנים הפיזיים, הדרישות האלה משפיעות על הבחירה של החיישנים הפיזיים. לדוגמה, דרישת הדיוק של וקטור הסיבוב במשחק משפיעה על רמת הדיוק הנדרשת של הגירוסקופ הפיזי. יצרן המכשיר הוא זה שקובע את הדרישות לחיישנים פיזיים.