האיור הבא מייצג את מקבץ החיישנים של Android. כל רכיב מתקשר רק עם הרכיבים שנמצאים ישירות מעליו ומתחתיו החיישנים יכולים לעקוף את רכזת החיישן כשהיא נמצאת. שליטה בתהליכי העבודה אל החיישנים, והנתונים עוברים מהחיישנים עד תרגום מכונה.
איור 1. שכבות של מקבץ החיישנים של Android והבעלים שלהן
SDK
אפליקציות ניגשות לחיישנים באמצעות Sensors SDK (Software Development Kit) API. ה-SDK מכיל פונקציות לרישום חיישנים זמינים ולרישום באמצעות חיישן.
במהלך הרישום לחיישן, האפליקציה מציינת את הדגימה המועדפת שלה ואת דרישות זמן האחזור שלה.
- לדוגמה, אפליקציה עשויה להירשם במד התאוצה שמוגדר כברירת מחדל, מבקשים אירועים במהירות של 100Hz, ומאפשרים לדווח על אירועים תוך שנייה אחת זמן אחזור.
- האפליקציה תקבל אירועים ממד התאוצה בקצב של לפחות 100Hz, ואולי גם עיכוב של עד שנייה אחת.
מידע נוסף על ה-SDK זמין בתיעוד למפתחים.
מסגרת
ה-framework אחראי לקישור של מספר אפליקציות ל-HAL. שירות HAL עצמו מיועד ללקוח יחיד. בלי המיזוג הזה ברמת ה-framework, רק אפליקציה אחת יכולה לגשת לכל חיישן בכל בזמן נתון.
- כשאפליקציה ראשונה נרשמת לחיישן, ה-framework שולח בקשה ל-HAL כדי להפעיל את החיישן.
- כשאפליקציות נוספות נרשמות לאותו חיישן, ה-framework לוקח
לחשבון בדרישות מכל אפליקציה, ושולח את הבקשה המעודכנת
ל-HAL.
- תדירות הדגימה תהיה הערך המקסימלי של תדרי הדגימה הנדרשים, כלומר חלק האפליקציות יקבלו אירועים בתדירות גבוהה יותר מהתדירות נדרש.
- זמן האחזור המקסימלי לדיווח יהיה המינימלי מהזמן המבוקש. אם אפליקציה אחת מבקשת עם זמן אחזור מקסימלי של 0 לדיווח, כל האפליקציות יקבלו אירועים מהחיישן הזה במצב רציף, גם אם חלקם ביקשו את החיישן עם זמן אחזור מקסימלי לצורך דיווח שהוא לא אפס. לפרטים נוספים, ראו אצווה.
- כשהאפליקציה האחרונה שרשומה בחיישן אחד מבטלת את הרישום שלה, frameworks שולחת בקשה ל-HAL להשבתת החיישן כך שהחשמל לא שצורכות שלא לצורך.
ההשפעה של ריבוי עיבודים
הצורך הזה בשכבת ריבוב במסגרת המסגרת מסביר חלק מהעיצוב ההחלטות שלנו.
- כשאפליקציה מבקשת תדירות דגימה ספציפית, אין להבטיח שהאירועים לא יגיעו בקצב מהיר יותר. אם אפליקציה אחרת ביקשו את אותו החיישן בקצב מהיר יותר, האפליקציה הראשונה לקבל אותם בקצב מהיר.
- אותו חוסר אחריות חל גם על זמן האחזור המקסימלי המבוקש לדיווח: אפליקציות עשויות לקבל אירועים עם זמן אחזור קצר בהרבה מכפי שביקשו.
- מלבד תדירות הדגימה וזמן האחזור המקסימלי לדיווח, האפליקציות לא יכולות
להגדיר את הפרמטרים של החיישן.
- לדוגמה, דמיינו חיישן פיזי שיכול לפעול גם המצבים 'דיוק' ו'צריכת חשמל נמוכה'.
- ניתן להשתמש רק באחד משני המצבים האלה במכשיר Android, כי אחרת, אפליקציה יכולה לבקש את המצב של רמת דיוק גבוהה, מצב של צריכת חשמל נמוכה לא תהיה דרך שבה ה-framework מספק מענה תרגום מכונה. ה-framework חייב תמיד לעמוד בדרישות של כל הלקוחות שלה, לכן זו לא אפשרות.
- אין מנגנון להורדת נתונים מהאפליקציות לחיישנים או הנהגים שלהם. כך אפשר להבטיח שאפליקציה אחת לא תוכל לשנות את ההתנהגות של מהחיישנים האדירים, לשבור אפליקציות אחרות.
היתוך חיישן
ה-framework של Android מספק הטמעת ברירת מחדל של רכיבים מורכבים מחיישנים. כשיש במכשיר ג'ירוסקופ, מד תאוצה ומגנטומטר, אבל לא קיימים חיישנים של וקטור סיבוב, כוח הכבידה והאצה לינארית, החיישנים מטמיעים את החיישנים האלה עדיין יכולים להשתמש בהם.
להטמעת ברירת המחדל אין גישה לכל הנתונים להטמעות יש גישה אליהן, והן חייבות לרוץ ב-SoC, כך שלא מדויקות ולא יעילות בחשמל כמו אפליקציות אחרות. באותה מידה ככל האפשר, יצרני מכשירים צריכים להגדיר חיישנים משולבים משלהם (סיבוב הווקטורים, כוח הכבידה ותאוצה ליניארית, וגם חיישנים מורכבים חדשים יותר כמו וקטור הרוטציה של המשחק), במקום להסתמך על הטמעת ברירת המחדל הזו. יצרני מכשירים יכולים לבקש מספקים של צ'יפים של חיישנים גם כדי לספק להם הטמעה.
הטמעת ברירת המחדל של היתוך חיישן לא מתוחזקת עלולה לגרום למכשירים שמסתמכים עליו להיכשל ב-CTS.
הגדרות
הסעיף הזה מסופק כמידע רקע לאנשים שמנהלים את קוד המסגרת של Android Open Source Project (AOSP). זה לא רלוונטי ל יצרני חומרה.
JNI
ה-framework משתמש ב-Java Native Interface (JNI) שמשויך ל-android.hardware וממוקם בספרייה frameworks/base/core/jni/. הקוד הזה קורא לפונקציה
קוד מקורי ברמה נמוכה יותר לקבלת גישה לחומרה של החיישן.
מסגרת מותאמת
ה-framework מוגדר ב-frameworks/native/ ומספק
שמקבילה לחבילת android.hardware. ה-framework של נייטיב קורא לשרתי ה-proxy של Binder IPC לקבל גישה
ספציפיים לחיישנים.
Binder IPC
שרתי ה-proxy של Binder IPC מסייעים בתקשורת מעל גבולות תהליכים.
HAL
ממשק ה-API של שכבת הפשטה של חומרת החיישנים (HAL) הוא הממשק בין מנהלי התקנים לחומרה ו-framework של Android. הוא מורכב מממשק HAL אחד חיישני.h והטמעת HAL אחת שאנחנו מתייחסים אליה כ-חיישנים.cpp.
הממשק מוגדר על ידי תורמי תוכן ב-Android וב-AOSP, וגם מסופק על ידי יצרן המכשיר.
ממשק ה-HAL של החיישן נמצא בhardware/libhardware/include/hardware.
למידע נוסף: sensors.h
.
מחזור הפצה
הטמעת תקן HAL מציינת איזו גרסה של ממשק HAL היא
באמצעות הגדרה של your_poll_device.common.version. פלטפורמת HAL הקיימת
גרסאות ממשק מוגדרות ב-חיישנים.h והפונקציונליות קשורה אליהן
גרסאות שונות.
נכון לעכשיו, הגרסה של Android framework תומכת בגרסאות 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 bus, SPI bus , ...) לא צוין על ידי Android, אבל צריך להגדיר אותו בצמצום צריכת החשמל הכוללת.
אפשרות אחת שנראה שיש לה השפעה משמעותית על ההטמעה בתהליך פשוט יש שני שורות הפרעה שעוברות מרכזת החיישן אל ה-SoC: אחד להפרעות בהתעוררות (לחיישני השכמה), והשני להפרעות בהתעוררות הפרעות (בחיישנים שלא יוצאים ממצב שינה).
חיישנים
אלה הצ'יפים הפיזיים של ה-MEM שמבצעים את המדידות. במקרים רבים, יש כמה חיישנים פיזיים על אותו שבב. לדוגמה, חלק מהצ'יפים כוללים מד תאוצה, ג'ירוסקופ ומגנטומטר. (צ'יפים כאלה הם לעיתים קרובות שנקראים צ'יפים של 9 צירים, כי כל חיישן מספק נתונים על פני שלושה צירים).
חלק מהצ'יפים האלה גם מכילים לוגיקה כלשהי לביצוע חישובים רגילים, כמו זיהוי תנועה, זיהוי צעדים וחיישן 9 צירים.
למרות שהדרישות וההמלצות לגבי הספק והדיוק של CDD מתמקדות ב חיישן Android ולא החיישנים הפיזיים, הדרישות האלה משפיעות על בחירה בחיישנים פיזיים. לדוגמה, דרישת הדיוק לגבי המשחק. לווקטור הסיבוב יש השפעה על הדיוק הנדרש עבור לג'ירוסקופ. יצרן המכשיר צריך להסיק את הדרישות עבור מחיישנים פיזיים.