בתרשים הבא מוצגת ערימת החיישנים של 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/. הקוד הזה קורא לקוד המקורי ברמה הנמוכה כדי לקבל גישה לחיישן.
מסגרת מקורית
המסגרת המקורית מוגדרת ב-frameworks/native/ ומספקת מקבילה מקורית לחבילה android.hardware. המסגרת המקורית קוראת לשרתי ה-proxy של 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.
מנהל התקן של ליבה
מנהלי ההתקנים של החיישנים יוצרים אינטראקציה עם המכשירים הפיזיים. במקרים מסוימים, הטמעת ה-HAL ומנהלי ההתקנים הם אותה ישות תוכנה. במקרים אחרים, משלבי החומרה מבקשים מיצרני שבבי החיישנים לספק את מנהלי ההתקנים, אבל הם אלה שכותבים את הטמעת ה-HAL.
בכל המקרים, הטמעת HAL ומנהלי התקנים של ליבת המערכת הם באחריות יצרני החומרה, ו-Android לא מספקת גישות מועדפות לכתיבתם.
מרכז חיישנים
מערך החיישנים של מכשיר יכול לכלול באופן אופציונלי רכזת חיישנים, שיכולה לבצע חישובים ברמה נמוכה בצריכת חשמל נמוכה בזמן שה-SoC יכול להיות במצב השהיה. לדוגמה, אפשר לבצע ספירת צעדים או מיזוג חיישנים בצ'יפים האלה. זה גם מקום טוב להטמעה של איגוד חיישנים, הוספה של FIFO בחומרה לאירועי החיישנים. מידע נוסף זמין במאמר בנושא עיבוד באצווה.
הערה: כדי לפתח תכונות חדשות של ContextHub שמשתמשות בחיישנים או בנוריות LED חדשים, אפשר גם להשתמש ב-Neonkey SensorHub שמחובר ללוח פיתוח Hikey או Hikey960.
האופן שבו מתבצעת המימוש של מרכז החיישנים תלוי בארכיטקטורה. לפעמים זהו שבב נפרד, ולפעמים הוא כלול באותו שבב כמו ה-SoC. מאפיינים חשובים של מרכז החיישנים הם שהוא צריך להכיל מספיק זיכרון לאיגום, ולצרוך מעט מאוד חשמל כדי לאפשר הטמעה של חיישני Android עם צריכת חשמל נמוכה. חלק ממרכזי החיישנים מכילים מיקרו-בקר לחישובים כלליים, ומאיצי חומרה שמאפשרים חישובים עם צריכת חשמל נמוכה מאוד עבור חיישנים עם צריכת חשמל נמוכה.
הארכיטקטורה של מרכז החיישנים והאופן שבו הוא מתקשר עם החיישנים ועם ה-SoC (אפיק I2C, אפיק SPI וכו') לא מוגדרים על ידי Android, אבל המטרה היא למזער את צריכת החשמל הכוללת.
אחת האפשרויות שנראה שיש לה השפעה משמעותית על פשטות ההטמעה היא שימוש בשני קווי הפרעה שיוצאים ממרכז החיישנים אל ה-SoC: קו אחד להפרעות של התעוררות (לחיישני התעוררות) וקו שני להפרעות שאינן של התעוררות (לחיישנים שאינם של התעוררות).
חיישנים
אלה שבבים פיזיים של MEMS שמבצעים את המדידות. במקרים רבים, יש כמה חיישנים פיזיים על אותו שבב. לדוגמה, חלק מהשבבים כוללים מד תאוצה, ג'ירוסקופ ומגנטומטר. (שבבים כאלה נקראים בדרך כלל שבבים עם 9 צירים, כי כל חיישן מספק נתונים על פני 3 צירים).
חלק מהשבבים האלה מכילים גם לוגיקה מסוימת לביצוע חישובים רגילים, כמו זיהוי תנועה, זיהוי צעדים ומיזוג נתונים מחיישן 9 צירים.
למרות שהדרישות וההמלצות של CDD לגבי עוצמה ודיוק מיועדות לחיישן Android ולא לחיישנים הפיזיים, הדרישות האלה משפיעות על הבחירה של החיישנים הפיזיים. לדוגמה, דרישת הדיוק של וקטור הסיבוב במשחק משפיעה על רמת הדיוק הנדרשת של הג'ירוסקופ הפיזי. הדרישות לחיישנים פיזיים נקבעות על ידי יצרן המכשיר.