בסמארטפונים יש כמה מעבדים, שכל אחד מהם מותאם לביצוע משימות שונות. עם זאת, Android פועל רק במעבד אחד: מעבד האפליקציות (AP). ה-AP מכוונן לספק ביצועים מעולים בתרחישי שימוש שבהם המסך דלוק, כמו משחקים, אבל הוא צורך יותר מדי חשמל כדי לתמוך בתכונות שדורשות התפרצויות קצרות ותכופות של עיבוד כל הזמן, גם כשהמסך כבוי. מעבדים קטנים יותר יכולים לטפל בעומסי העבודה האלה בצורה יעילה יותר, ולהשלים את המשימות שלהם בלי להשפיע באופן משמעותי על חיי הסוללה. עם זאת, סביבות התוכנה במעבדים עם צריכת אנרגיה נמוכה מוגבלות יותר ויכולות להשתנות מאוד, מה שמקשה על פיתוח בפלטפורמות שונות.
סביבת זמן ריצה של מרכז ההקשר (CHRE) מספקת פלטפורמה משותפת להרצת אפליקציות במעבד בעל צריכת אנרגיה נמוכה, עם ממשק API פשוט, סטנדרטי ונוח להטמעה. בעזרת CHRE, יצרני ציוד מקורי (OEM) של מכשירים ושותפיהם המהימנים יכולים להעביר בקלות את העיבוד מה-AP, לחסוך בחיי הסוללה ולשפר תחומים שונים בחוויית המשתמש. בנוסף, הם יכולים להפעיל סוג של תכונות שפועלות תמיד ומבוססות על הקשר, במיוחד תכונות שכוללות שימוש בלמידת מכונה לחישת הסביבה.
מושגים מרכזיים
CHRE היא סביבת התוכנה שבה אפליקציות מקומיות קטנות, שנקראות נאנו-אפליקציות, פועלות במעבד בעל צריכת אנרגיה נמוכה ומקיימות אינטראקציה עם המערכת הבסיסית באמצעות ממשק ה-API המשותף של CHRE. כדי לזרז את ההטמעה הנכונה של ממשקי ה-API של CHRE, הוספנו ל-AOSP הטמעת עזרה לפלטפורמות שונות של CHRE. הטמעת העזרה כוללת קוד משותף ורמות הפשטה של החומרה והתוכנה הבסיסיות, באמצעות סדרה של שכבות הפשטה של פלטפורמה (PAL). כמעט תמיד, אפליקציות ננו קשורות לאפליקציית לקוח אחת או יותר שפועלות ב-Android, שמקיימות אינטראקציה עם CHRE ואפליקציות ננו באמצעות ממשקי API של מערכת ContextHubManager עם גישה מוגבלת.
ברמה גבוהה, אפשר למצוא קווי דמיון בין הארכיטקטורה של CHRE לבין Android בכללותה. עם זאת, יש כמה הבדלים חשובים:
- ב-CHRE אפשר להריץ רק ננו-אפליקציות שפותחו בקוד מקורי (C או C++). אין תמיכה ב-Java.
- עקב מגבלות משאבים ומגבלות אבטחה, ה-CHRE לא פתוח לשימוש באפליקציות צד שלישי שרירותיות ל-Android. רק אפליקציות מהימנות למערכת יכולות לגשת אליו.
חשוב גם להבחין בין המושג CHRE לבין מרכז חיישנים. אמנם מקובל להשתמש באותה חומרה כדי להטמיע את מרכז החיישנים ואת ה-CHRE, אבל ה-CHRE עצמו לא מספק את יכולות החיישן הנדרשות על ידי Android Sensors HAL. ה-CHRE קשור ל-HAL של Context Hub, והוא פועל כלקוח של מסגרת חיישנים ספציפית למכשיר כדי לקבל נתוני חיישנים בלי לערב את ה-AP.
איור 1. ארכיטקטורת המסגרת של CHRE
HAL של Context Hub
שכבת ההפשטה של החומרה (HAL) של Context Hub היא הממשק בין מסגרת Android לבין הטמעת ה-CHRE במכשיר, שמוגדר ב-hardware/interfaces/contexthub.
HAL של מרכז ההקשר מגדיר את ממשקי ה-API שבאמצעותם מסגרת Android מאתרת מרכזי הקשר זמינים ואת האפליקציות הננו שלהם, יוצרת אינטראקציה עם האפליקציות הננו האלה באמצעות העברת הודעות ומאפשרת לטעון ולפרוק אפליקציות ננו. הטמעת העזר של HAL של Context Hub שפועלת עם הטמעת העזר של CHRE זמינה בכתובת system/chre/host.
במקרה של סתירה בין המסמכים האלה לבין ההגדרה של HAL, ההגדרה של HAL היא הקובעת.
אתחול
כשמערכת Android מופעלת, השירות ContextHubService מפעיל את פונקציית ה-HAL getHubs() כדי לקבוע אם יש מרכזי הקשר זמינים במכשיר. זוהי קריאה חד-פעמית שחוסמת את המערכת, לכן היא צריכה להסתיים במהירות כדי לא לעכב את האתחול, והיא צריכה להחזיר תוצאה מדויקת, כי אי אפשר להוסיף מרכזי הקשר חדשים לאחר מכן.
טעינה ופריקה של ננו-אפליקציות
מרכז הקשר יכול לכלול קבוצה של ננו-אפליקציות שכלולות בתמונת המכשיר ונטענות כש-CHRE מופעל. הן נקראות ננו-אפליקציות שמוטענות מראש, וצריך לכלול אותן בתגובה הראשונה האפשרית לשדה queryApps().
ב-HAL של Context Hub יש תמיכה גם בטעינה ובפריקה של ננו-אפליקציות באופן דינמי בזמן ריצה, באמצעות הפונקציות loadNanoApp() ו-unloadNanoApp(). אפליקציות ננו מועברות ל-HAL בפורמט בינארי ספציפי להטמעת החומרה והתוכנה של CHRE במכשיר.
אם ההטמעה של טעינת אפליקציית ננו כוללת כתיבת שלה בזיכרון לא נדיף, כמו אחסון פלאש שמחובר למעבד שמריץ את CHRE, אז הטמעת CHRE תמיד צריכה להתאפס עם אפליקציות הננו הדינמיות האלה במצב מושבת. כלומר, אף אחד מהקוד של האפליקציה המינימלית לא מבוצע עד שמתקבלת בקשה מסוג enableNanoapp() דרך ה-HAL. אפליקציות ננו שהוטענו מראש יכולות להתחיל לפעול בסטטוס מופעל.
Context Hub מופעל מחדש
לא צפוי שה-CHRE יופעל מחדש במהלך הפעולה הרגילה, אבל יכול להיות שיהיה צורך להתאושש מתנאי לא צפויים, כמו ניסיון לגשת לכתובת זיכרון לא ממופה. במקרים כאלה, CHRE מופעל מחדש בנפרד מ-Android. ה-HAL מודיע על כך ל-Android באמצעות האירוע RESTARTED, שצריך לשלוח רק אחרי שה-CHRE יופעל מחדש עד שהוא יוכל לקבל בקשות חדשות, כמו queryApps().
סקירה כללית על מערכת CHRE
CHRE תוכנן לפי ארכיטקטורה מבוססת-אירועים, שבה יחידת החישוב הראשית היא אירוע שמוענק לנקודת הכניסה לטיפול באירועים של ננו-אפליקציה. אפשר להשתמש במסגרת CHRE עם כמה שרשורים, אבל אף אפליקציית ננו לא מופעלת מכמה שרשורים בו-זמנית. מסגרת CHRE יוצרת אינטראקציה עם אפליקציית ננו נתונה דרך אחת משלוש נקודות הכניסה של אפליקציית הננו (nanoappStart(), nanoappHandleEvent() ו-nanoappEnd()) או דרך קריאה חוזרת (callback) שסופקה בקריאה קודמת ל-CHRE API. אפליקציות ננו יוצרות אינטראקציה עם מסגרת CHRE והמערכת הבסיסית דרך CHRE API. ממשק ה-API של CHRE מספק קבוצה של יכולות בסיסיות וגם שירותים לגישה לאותות לפי הקשר, כולל חיישנים, GNSS, Wi-Fi, WWAN ואודיו. אפשר להרחיב אותו באמצעות יכולות נוספות ספציפיות לספק לשימוש ב-nanoapps ספציפיים לספק.
מערכת build
רכיב ה-HAL של Context Hub ורכיבים נחוצים אחרים בצד AP נוצרים לצד Android, אבל לקוד שפועל ב-CHRE יכולות להיות דרישות שאינן תואמות למערכת ה-build של Android, למשל צורך בסביבת פיתוח כלים ייעודית. לכן, פרויקט CHRE ב-AOSP מספק מערכת build פשוטה שמבוססת על GNU Make כדי לקמפל אפליקציות ננו, ואפשרות להפוך את מסגרת CHRE לספריות שאפשר לשלב במערכת. יצרני מכשירים שמוסיפים תמיכה ב-CHRE צריכים לשלב תמיכה במערכת build למכשירי היעד שלהם ב-AOSP.
ה-CHRE API נכתב לפי תקן השפה C99, וההטמעה של ההפניה משתמשת בקבוצת משנה מוגבלת של C++11 שמתאימה לאפליקציות עם משאבים מוגבלים.
CHRE API
CHRE API הוא אוסף של קובצי כותרת מסוג C שמגדירים את ממשק התוכנה בין אפליקציית הננו לבין המערכת. הוא נועד להפוך את הקוד של ננו-אפליקציות לתואם לכל המכשירים שתומכים ב-CHRE. כלומר, לא צריך לשנות את קוד המקור של ננו-אפליקציה כדי לתמוך בסוג מכשיר חדש, אבל יכול להיות שיהיה צורך לבצע הידור מחדש במיוחד עבור קבוצת ההוראות של המעבד או ממשק ה-ABI (Application Binary Interface) של מכשיר היעד. הארכיטקטורה ועיצוב ה-API של CHRE מבטיחים גם ש-nanoapps יהיו תואמים בינארי בגרסאות שונות של CHRE API. כלומר, לא צריך לבצע הידור מחדש של nanoapp כדי להריץ אותו במערכת שמטמיעה גרסה שונה של CHRE API בהשוואה ל-API היעד שאליו ה-nanoapp עבר הידור. במילים אחרות, אם קובץ בינארי של אפליקציית nanoapp פועל במכשיר שתומך ב-CHRE API v1.3, והמכשיר הזה משודרג לתמיכה ב-CHRE API v1.4, אותו קובץ בינארי של אפליקציית nanoapp ממשיך לפעול. באופן דומה, ה-nanoapp יכול לפעול ב-CHRE API v1.2, ולהחליט בזמן הריצה אם הוא זקוק ליכולות מ-API v1.3 כדי להשיג את השימוש שלו, או אם הוא יכול לפעול, אולי עם פגיעה מינימלית בתכונות.
גרסאות חדשות של CHRE API מוצגות יחד עם Android, אבל מכיוון שההטמעה של CHRE היא חלק מהטמעת הספק, גרסה של CHRE API שנתמכת במכשיר לא תמיד מקושרת לגרסה של Android.
סיכום הגרסה
בדומה לסכימה של ניהול הגרסאות של Android HIDL, ממשק ה-API של CHRE פועל לפי ניהול גרסאות סמנטי.
הגרסה הראשית מציינת תאימות בינארית, והגרסה המשנית עולה כשמוסיפים תכונות שתואמות לאחור. ה-CHRE API כולל הערות בקוד המקור כדי לזהות באיזו גרסה הוכנסה פונקציה או פרמטר, לדוגמה @since v1.1.
הטמעת CHRE חושפת גם גרסה של תיקון ספציפית לפלטפורמה דרך chreGetVersion(), שמציינת מתי מתבצעות תיקוני באגים או עדכונים קלים בהטמעה.
גרסה 1.0 (Android 7)
כולל תמיכה בחיישנים וביכולות הליבה של ננו-אפליקציות, כמו אירועים ומעכבים.
גרסה 1.1 (Android 8)
הוספת יכולות מיקום באמצעות מיקום GNSS ומדידות גולמיות, סריקת Wi-Fi ומידע על רשתות סלולריות, לצד שיפורים כלליים שמאפשרים תקשורת בין ננו-אפליקציות ושיפורים נוספים.
גרסה 1.2 (Android 9)
נוספה תמיכה בנתונים ממיקרופון עם צריכת אנרגיה נמוכה, מדידת מרחק RTT ב-Wi-Fi, התראות על הפעלה והשבתה של נקודות גישה ושיפורים נוספים.
גרסה 1.3 (Android 10)
שיפור היכולות שקשורות לנתוני כיול חיישנים, הוספת תמיכה בסינון נתוני חיישנים באצווה על פי דרישה, הגדרת סוג חיישן לזיהוי צעדים והרחבת אירועי מיקום GNSS באמצעות שדות דיוק נוספים.
גרסה 1.4 (Android 11)
נוספה תמיכה במידע על תאים של 5G, דמפ לניפוי באגים של ננו-אפליקציות ושיפורים נוספים.
תכונות מערכת חובה
מקורות של אותות לפי הקשר, כמו חיישנים, מסווגים לתחומי תכונות אופציונליים, אבל יש כמה פונקציות ליבה שנדרשות בכל הטמעות ה-CHRE. הוא כולל ממשקי API של ליבה, כמו אלה שמשמשים להגדרת שעונים, לשליחה ולקבלה של הודעות ללקוחות במעבד האפליקציות, לרישום ביומן ועוד. פרטים מלאים זמינים במאמר כותרות API.
בנוסף לתכונות הליבה של המערכת שמקודדות ב-CHRE API, יש גם תכונות חובה ברמת המערכת של CHRE שמצוינות ברמת ה-HAL של Context Hub. האפשרות החשובה ביותר היא היכולת לטעון ולפרוק באופן דינמי אפליקציות ננו.
ספרייה רגילה של C/C++
כדי לצמצם את השימוש בזיכרון ואת המורכבות של המערכת, ההטמעות של CHRE נדרשות לתמוך רק בקבוצת משנה של ספריות C ו-C++ רגילות ותכונות שפה שדורשות תמיכה בסביבת זמן ריצה. בהתאם לעקרונות האלה, חלק מהתכונות מוחרגות במפורש בגלל הצורך שלהן בזיכרון ובתלות רחבה ברמת מערכת ההפעלה, וחלק מהתכונות מוחרגות כי הן הוחלפו בממשקי API מתאימים יותר ל-CHRE. הרשימה הבאה היא חלקית בלבד, אבל היא כוללת את היכולות הבאות שלא יהיו זמינות ל-nanoapps:
- חריגות ב-C++ ומידע על סוגים בסביבת זמן הריצה (RTTI)
- תמיכה בספרייה רגילה במספר תהליכים, כולל כותרות C++11
<thread>,<mutex>,<atomic>,<future> - ספריות קלט/פלט רגילות של C ו-C++
- ספריית התבניות הרגילה של C++ (STL)
- ספריית ביטויים רגולריים רגילה של C++
- הקצאת זיכרון דינמית באמצעות פונקציות רגילות (לדוגמה,
malloc,calloc,realloc,free,operator new) ופונקציות ספרייה רגילות אחרות שמשתמשות באופן מהותי בהקצאה דינמית, כמוstd::unique_ptr - תמיכה בתווי Unicode ובתמיכה בתווים מקומיים
- ספריות של תאריכים ושעות
- פונקציות שמשנות את הזרימה הרגילה של התוכנית, כולל
<setjmp.h>,<signal.h>, abort, std::terminate - גישה לסביבת המארח, כולל
system, getenv - POSIX וספריות אחרות שלא נכללות בתקני השפה C99 או C++11
במקרים רבים, יש יכולות מקבילות שזמינות בפונקציות של CHRE API ובספריות השירות. לדוגמה, אפשר להשתמש ב-chreLog לרישום ביומן ניפוי באגים שמטורגט למערכת logcat של Android, בעוד שבתוכנית מסורתית יותר יכול להיות שייעשה שימוש ב-printf או ב-std::cout.
לעומת זאת, יש צורך ביכולות ספרייה רגילות מסוימות. תלוי בהטמעה של הפלטפורמה אם הספריות האלה יוצגו באמצעות ספריות סטטיות שאפשר לכלול בקובץ הבינארי של ה-nanoapp, או באמצעות קישור דינמי בין ה-nanoapp למערכת. דוגמאות לתחומי מומחיות כאלה:
- כלי עזר למחרוזות ולמערכים:
memcmp,memcpy,memmove,memset,strlen ספריית מתמטיקה: פונקציות נפוצות של נקודה צפה (floating-point) ברמת דיוק יחידה:
- פעולות בסיסיות:
ceilf,fabsf,floorf,fmaxf,fminf,fmodf,roundf,lroundf,remainderf - פונקציות מעריכיות ופונקציות כוח:
expf, log2f, powf, sqrtf - פונקציות טריגונומטריות והיפרבוליות:
sinf,cosf,tanf,asinf,acosf,atan2f,tanhf
- פעולות בסיסיות:
חלק מהפלטפורמות הבסיסיות תומכות ביכולות נוספות, אבל ננו-אפליקציה לא נחשבת לניידת בין הטמעות של CHRE, אלא אם היא מגבילה את יחסי התלות החיצוניים שלה לפונקציות של CHRE API ולפונקציות ספריית סטנדרטיות שאושרו.
תכונות אופציונליות
כדי לקדם חומרה ותוכנה, ממשק ה-API של CHRE מחולק לאזורי תכונות, שנחשבים אופציונליים מנקודת המבט של ה-API. יכול להיות שהתכונות האלה לא נדרשות כדי לתמוך בהטמעה תואמת של CHRE, אבל יכול להיות שהן נדרשות כדי לתמוך ב-nanoapp מסוים. גם אם פלטפורמה מסוימת לא תומכת בקבוצה מסוימת של ממשקי API, אפליקציות ננו שמפנות לפונקציות האלה צריכות להיות מסוגלות לפתח ולטעון אותן.
חיישנים
באמצעות CHRE API אפשר לבקש נתונים מהחיישנים, כולל מד תאוצה, ג'ירוסקופ, מגנטומטר, חיישן אור סביבתי וחיישן קירבה. ממשקי ה-API האלה נועדו לספק קבוצת תכונות דומה לזו של ממשקי ה-API של חיישני Android, כולל תמיכה בצבירה של דגימות חיישן כדי לצמצם את צריכת החשמל. עיבוד נתוני החיישן ב-CHRE מאפשר עיבוד של אותות תנועה עם צריכת אנרגיה נמוכה בהרבה וזמן אחזור נמוך יותר בהשוואה לעיבוד ב-AP.
GNSS
CHRE מספקת ממשקי API לבקשת נתוני מיקום ממערכת לוויינים גלובלית לניווט (GNSS), כולל GPS ומערכות אחרות של לוויינים. הבקשות האלה כוללות בקשות לתיקוני מיקום תקופתיים ונתוני מדידה גולמיים, אבל שתי היכולות האלה הן עצמאיות. מכיוון של-CHRE יש קישור ישיר למערכת המשנית של GNSS, צריכת האנרגיה נמוכה יותר בהשוואה לבקשות GNSS שמבוססות על נקודת הגישה, כי הנקודה יכולה להישאר במצב שינה במהלך כל מחזור החיים של סשן המיקום.
Wi-Fi
CHRE מאפשר אינטראקציה עם צ'יפ ה-Wi-Fi, בעיקר למטרות מיקום. מערכת GNSS פועלת היטב במיקומים בחוץ, אבל תוצאות סריקות Wi-Fi יכולות לספק מידע מדויק על המיקום בתוך מבנים ובאזורים מפותחים. בנוסף לחיסכון בעלויות של הפעלת הנקודה לשיתוף אינטרנט לצורך סריקה, ה-CHRE יכול להאזין לתוצאות של סריקות Wi-Fi שמתבצעות על ידי קושחת ה-Wi-Fi למטרות קישוריות, שבדרך כלל לא מועברות לנקודה לשיתוף אינטרנט מסיבות של צריכת חשמל. שימוש בסריקות קישוריות למטרות הקשריות עוזר לצמצם את המספר הכולל של סריקות ה-Wi-Fi שמבוצעות, וכך לחסוך באנרגיה.
תמיכה ב-Wi-Fi נוספה ב-CHRE API v1.1, כולל היכולת לעקוב אחרי תוצאות הסריקה ולהפעיל סריקות על פי דרישה. בגרסת 1.2 נוספה היכולת לבצע מדידות של זמן נסיעה הלוך ושוב (RTT) בנקודות גישה שתומכות בתכונה הזו, וכך לקבוע מיקום יחסי מדויק.
WWAN
באמצעות CHRE API אפשר לאחזר את פרטי הזיהוי של התא שמספק את השירות ושל התאים השכנים, שמשמשים בדרך כלל למטרות מיקום ברמת פירוט גסה.
אודיו
CHRE יכול לעבד קבוצות של נתוני אודיו ממיקרופון בעל הספק נמוך, שבדרך כלל משתמש בחומרה המשמשת להטמעת ה-HAL של SoundTrigger. עיבוד נתוני אודיו ב-CHRE מאפשר למזג אותם עם נתונים אחרים, כמו חיישני תנועה.
הטמעת הפניה
קוד העזר של מסגרת CHRE נכלל ב-AOSP בפרויקט system/chre, והוא מיושם ב-C++11. אין צורך לעשות זאת, אבל מומלץ שכל הטמעות ה-CHRE יתבססו על קוד הבסיס הזה, כדי להבטיח עקביות ולהאיץ את אימוץ היכולות החדשות. אפשר לראות את הקוד הזה כאנלוגי למסגרת הליבה של Android, כי הוא הטמעה של ממשקי API בקוד פתוח שבהם האפליקציות משתמשות, ומיועד לשמש כבסיס ותורן לתאימות. אפשר להתאים אישית את הקוד המשותף ולהרחיב אותו באמצעות יכולות ספציפיות לספק, אבל מומלץ לשמור על הקוד המשותף קרוב ככל האפשר למסמך העזרה. בדומה ל-HAL של Android, ההטמעה של CHRE מתבססת על הפשטות שונות של פלטפורמות, כדי לאפשר התאמה לכל מכשיר שעונה על הדרישות המינימליות.
לפרטים טכניים ולמדריך להעברה, אפשר לעיין בקובץ README שכלול בפרויקט system/chre.