סביבת זמן ריצה של מרכז המידע (CHRE)

טלפונים חכמים מכילים מספר מעבדים, שכל אחד מהם מותאם לביצועים משימות שונות. עם זאת, מערכת Android פועלת רק במעבד אחד: האפליקציות מעבד (AP). סוכנות AP מוכנה לספק ביצועים מעולים בצפייה במסך לדוגמה, כמו גיימינג, אבל אין מספיק כוח כדי לתמוך בתכונות שדורשות רצפי עיבוד קצרים ותכופים כל הזמן, גם כשהמסך מושבתת. מעבדים קטנים יותר יכולים להתמודד עם עומסי העבודה האלה בצורה יעילה יותר, להשלים את המשימות שלהם בלי להשפיע באופן משמעותי על חיי הסוללה. אבל, במעבדים בעלי מתח נמוך אלה הן מוגבלות יותר ויכול להיות שהן עשויות שונות מאוד, מה שמקשה על פיתוח בפלטפורמות שונות.

סביבת זמן ריצה של מרכז הקשר (CHRE) מספקת פלטפורמה משותפת להרצה במעבד בעל מתח נמוך, באמצעות מודל פשוט וסטנדרטי עם API ידידותי להטמעה. CHRE מקל על יצרני ציוד מקורי של מכשירים ועל האמינות שלהם להפחית את העומס על העיבוד מ-AP, כדי לחסוך בסוללה ולשפר של חוויית המשתמש, ולאפשר סיווג של פעולה כל הזמן, מבוססת-הקשר, במיוחד כאלו שכוללות יישום מלמידת מכונה לחישת אווירה.

מושגים מרכזיים

CHRE היא סביבת התוכנה שבה אפליקציות נייטיב קטנות, שנקראות nanoapps, לפעול במעבד בעל מתח נמוך ולנהל אינטראקציה עם באמצעות ה-CHRE API הנפוץ. כדי להאיץ יישום תקין של ממשקי API של CHRE, הטמעת קובצי עזר בפלטפורמות שונות של CHRE כלולה AOSP. הטמעת קובץ העזר כוללת קוד נפוץ והפשטות חומרה ותוכנה בסיסיים באמצעות סדרה של שכבות הפשטה של פלטפורמות (PAL). הננו-אפליקציות כמעט תמיד מקושרות לאפליקציית לקוח אחת או יותר שפועלות ב- Android, שיוצרים אינטראקציה עם CHRE ועם ננואפליקציות דרך גישה מוגבלת ContextHubManager ממשקי API של המערכת.

ברמה גבוהה, ניתן למצוא קווים מקבילים בין הארכיטקטורה של CHRE Android באופן כללי. עם זאת, יש כמה הבדלים חשובים:

  • CHRE תומכת בהרצת רק ננו-אפליקציות שפותחו בקוד נייטיב (C או C++); אין תמיכה ב-Java.
  • עקב אילוצי משאבים והגבלות אבטחה, CHRE לא פתוח לשימוש על ידי אפליקציות שרירותיות של צד שלישי ל-Android. רק אפליקציות מהימנים על ידי המערכת יכולות לגשת אליו.

יש גם הבחנה חשובה בין המושג CHRE ורכזת חיישן. אומנם מקובל להשתמש באותה חומרה כדי להטמיע את מפצל החיישן ו-CHRE, חברת CHRE עצמה לא מספקת את יכולות החיישן שנדרשת באמצעות החיישנים של Android HAL. CHRE קשור אל מרכז ההקשר HAL, והוא פועל כלקוח של חיישן ספציפי למכשיר כדי לקבל נתוני חיישנים בלי לערב את AP.

ארכיטקטורת framework של CHRE

איור 1. ארכיטקטורת framework של CHRE

HAL במרכז ההקשר

שכבת ההפשטה של חומרת הקשר (HAL) היא הממשק בין Android framework והטמעת CHRE של המכשיר, המוגדרים ב- hardware/interfaces/contexthub פרוטוקול Context Hub HAL מגדיר את ממשקי ה-API שדרכם framework של Android מוצא מרכזי הקשר זמינים ואת הננו-אפליקציות שלהם, יוצר איתם אינטראקציה ננו-אפליקציות שמעבירות הודעות, ומאפשרות טעינה של הננו-אפליקציות לא נטענו. קובץ עזר של הטמעה של Context Hub HAL שפועל עם יישום קובצי עזר של CHRE זמין בכתובת system/chre/host

במקרה של סתירה בין המסמך הזה לבין הגדרת HAL, הגדרה של HAL מקבלת עדיפות.

אתחול

לאחר הפעלת ה-Android, ContextHubService מפעילה את פונקציית HAL getHubs() כדי לקבוע אם יש מרכזים של הקשר שזמינות במכשיר. זוהי שיחה חד-פעמית של חסימה, לכן היא חייבת להסתיים במהירות כדי למנוע עיכובים באתחול, ועליה להחזיר תוצאה מדויקת, לאחר מכן אי אפשר יהיה להשתמש במרכזי הקשר.

טעינה והסרה של ננו-אפליקציות

מרכז הקשר יכול לכלול קבוצת ננו-אפליקציות שכלולות במכשיר תמונה ונטענו כאשר CHRE מתחיל. המוכרות האלה נקראות ננו-אפליקציות שנטענו מראש, וצריך להיכלל בתגובה הראשונה האפשרית ל-queryApps().

ב-Context Hub HAL יש גם תמיכה בטעינה והסרה של ננו-אפליקציות באופן דינמי ב זמן ריצה, באמצעות הפונקציות loadNanoApp() ו-unloadNanoApp(). ננו-אפליקציות סופקו ל-HAL בפורמט בינארי שספציפי לחומרת CHRE יישום התוכנה במכשיר.

אם ההטמעה של טעינת ננו-אפליקציה כרוכה בכתיבה של ננו-אפליקציה כלשהי זיכרון חדש, כמו אחסון Flash שמחובר למעבד שמריץ CHRE, הטמעת CHRE תמיד צריכה לאתחל עם הננו-אפליקציות הדינמיות האלה מושבת. המשמעות היא שאף אחד מהקודים של הננו-אפליקציה לא יופעל עד בקשת enableNanoapp() מתקבלת באמצעות HAL. ניתן לטעון ננו-אפליקציות מראש לאתחל במצב מופעל.

מרכז ההקשר מופעל מחדש

לא ניתן לצפות ש-CHRE יופעל מחדש במהלך פעולה רגילה, אבל ייתכן שנדרש כדי להתאושש מתנאים בלתי צפויים, כמו ניסיון לגשת לכתובת זיכרון לא ממופה. במצבים כאלה, CHRE תופעל מחדש בנפרד מ-Android. ארגון HAL מודיע ל-Android על כך באמצעות אירוע RESTARTED, שאותו צריך לשלוח רק אחרי ש-CHRE מאותחל מחדש שהוא יכול לקבל בקשות חדשות, כמו queryApps().

סקירה כללית של מערכת CHRE

CHRE תוכננה סביב ארכיטקטורה מבוססת-אירועים, שבה היחידה הראשית של חישוב הוא אירוע שמועבר לנקודת הכניסה של nanoapp לטיפול באירועים. בזמן מסגרת CHRE יכולה להיות מרובת שרשורים, ננו-אפליקציה מסוימת אף פעם לא מבוצעת מספר שרשורים במקביל. ה-framework של CHRE מקיים אינטראקציה עם ננו-אפליקציה נתונה דרך אחת משלוש נקודות הכניסה לננו-אפליקציות (nanoappStart(), nanoappHandleEvent() וגם nanoappEnd()) או באמצעות קריאה חוזרת (callback) שמסופקת קריאה קודמת ל-CHRE API ונאנו-אפליקציות יוצרים אינטראקציה עם מסגרת CHRE באמצעות ה-CHRE API. ה-CHRE API מספק ערכה של יכולות וגם אמצעים לגישה לאותות לפי הקשר, כולל חיישנים, GNSS, Wi-Fi, WWAN ואודיו, ואפשר להרחיב אותו באמצעות יכולות ספציפיות לספק, לשימוש בננו אפליקציות ספציפיות לספק.

מערכת build

למרות ש-Context Hub HAL ורכיבים נחוצים אחרים בצד ה-AP נוצרים לצד Android, קוד שפועל בתוך CHRE יכול להיות כפוף לדרישות שלא תואם למערכת ה-build של Android, כמו צורך בכלי. לכן, פרויקט CHRE ב-AOSP מספק build פשוט שמבוססת על GNU Maker כדי להדר ננו-אפליקציות, ובאופן אופציונלי, גם מודל CHRE ספריות שניתנות לשילוב עם המערכת. Device (מכשיר) ליצרנים שמוסיפים תמיכה ב-CHRE צריך לשלב תמיכה במערכות build, את מכשירי היעד שלהם ל-AOSP.

ה-CHRE API נכתב בתקן השפה C99, וקובץ העזר משתמשת בקבוצת משנה מוגבלת של C++11, שמתאימה למודעות מוגבלות במשאבים באפליקציות.

CHRE API

CHRE API הוא אוסף של קובצי כותרות C שמגדירים את התוכנה בין הננו-אפליקציה למערכת. הוא נועד ליצור ננו-אפליקציות שתואם לכל המכשירים שתומכים ב-CHRE, אין צורך לשנות את קוד המקור של nanoapp כדי לתמוך במכשיר חדש אבל יכול להיות שיהיה צורך להדר אותו מחדש במיוחד עבור מכשיר היעד קבוצת הוראות של מעבד מידע או ממשק בינארי לאפליקציה (ABI). ה-CHRE והארכיטקטורה של ה-API, מבטיחים שהננו-אפליקציות יהיו תואמות גם לבינארי. בגרסאות שונות של ה-CHRE API, כלומר ננו-אפליקציה צריך לבצע הידור מחדש כדי לרוץ במערכת שמממשת גרסה אחרת של ממשק ה-API של CHRE בהשוואה ל-API היעד שהננו-אפליקציה מורכבת ממנו. כלומר, אם קובץ בינארי של ננו-אפליקציה פועל במכשיר שתומך ב-CHRE API גרסה 1.3. המכשיר הזה שודרג לתמיכה ב-CHRE API v1.4, אותה ננו-אפליקציה. הבינארי ממשיך לפעול. באופן דומה, הננו-אפליקציה יכולה לרוץ ב-CHRE API גרסה 1.2, ויכול לקבוע בזמן הריצה אם הוא דורש יכולות מ-API v1.3 להשיג את השימוש בו, או אם הוא יכול לפעול, באופן שעשוי להיות חינני והשחתה של תכונות.

גרסאות חדשות של CHRE API מתפרסמות לצד Android, אבל עם CHRE הוא חלק הטמעה של ספק, גרסת ה-CHRE API שנתמכת במכשיר לא בהכרח מקושרת גרסת Android.

סיכום גרסה

לייק סכמת ניהול גרסאות של Android HIDL, CHRE API מבוסס על ניהול גרסאות סמנטי. הגרסה הראשית מציינת תאימות בינארית, והגרסה המשנית מצטברים עם השקה של תכונות תואמות לאחור. ממשק ה-API של CHRE הדוח כולל הערות של קוד מקור כדי לזהות באיזו גרסה הופעלה פונקציה או פרמטר מסוים, לדוגמה @since v1.1.

הטמעת CHRE גם חושפת גרסת תיקון ספציפית לפלטפורמה באמצעות chreGetVersion(), שמציין מתי בוצעו תיקוני באגים או עדכונים קלים בזמן ההטמעה.

גרסה 1.0 (Android 7)

כולל תמיכה בחיישנים ויכולות ליבה של ננו-אפליקציות, כמו אירועים מגבלות זמן.

גרסה 1.1 (Android 8)

שימוש ביכולות מיקום באמצעות GNSS ומדידות גולמיות, חיפוש נקודות Wi-Fi ומידע על הרשת הסלולרית, לצד שיפורים כלליים כדי לאפשר תקשורת בין ננו-אפליקציה לננו-אפליקציה, ושיפורים נוספים.

גרסה 1.2 (Android 9)

הוספת תמיכה בנתונים ממיקרופון בעל מתח נמוך, מטווח Wi-Fi RTT, מ-AP התראות על השכמה ושינה ושיפורים נוספים.

גרסה 1.3 (Android 10)

שיפור היכולות שקשורות לנתוני כיול החיישן, תוספת תמיכה ריקון נתוני חיישנים מרובים על פי דרישה, מגדיר את סוג החיישן בשלב זיהוי השלב, מרחיב את אירועי המיקום של GNSS עם שדות דיוק נוספים.

גרסה 1.4 (Android 11)

הוספת תמיכה במידע על תא 5G, תמונת מצב של ניפוי באגים ב-nanoapp ועוד ושיפורים.

תכונות חובה של המערכת

בעוד שמקורות של אותות לפי הקשר, כמו חיישנים, מסווגים נדרשות כמה פונקציות ליבה בכל CHRE בפועל. זה כולל ממשקי API של מערכת הליבה, כמו אלה שמשמשים להגדרה מגבלות זמן, שליחה וקבלה של הודעות ללקוחות במעבד האפליקציות, רישום ביומן ועוד. פרטים מלאים זמינים כותרות API.

בנוסף לתכונות הליבה של המערכת שמקודדות ב-CHRE API, יש גם תכונות חובה ברמת המערכת CHRE שצוינו ברמת Context Hub HAL. המשמעותי ביותר מבין אלה היא היכולת לטעון ולהסיר באופן דינמי של ננו-אפליקציות.

ספרייה רגילה של C/C++

כדי למזער את השימוש בזיכרון ואת מורכבות המערכת, הטמעות CHRE שנדרשות כדי לתמוך רק בקבוצת משנה של ספריות C ו-C++ הרגילות תכונות שפה שמחייבות תמיכה בסביבת זמן ריצה. בהתאם לעקרונות האלה, תכונות לא נכללות באופן מפורש עקב הזיכרון שלהן וברמת מערכת ההפעלה הרחבה של יחסי התלות ואחרים, כי הם מוחלפים על ידי ממשקי API ספציפיים ל-CHRE. זו אמנם לא רשימה מקיפה, אבל הפרטים הבאים אסור שהיכולות יהיו זמינות לננו-אפליקציות:

  • חריגים ב-C++ ומידע על סוגי זמן ריצה (RTTI)
  • תמיכה בריבוי שרשורים בספרייה רגילה, כולל כותרות C++11 <thread>, <mutex>, <atomic>, <future>
  • ספריות C ו-C++ סטנדרטי של קלט/פלט
  • ספריית תבניות רגילה (STL) C++
  • ספריית 'ביטויים רגולריים רגילים' ב-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.

לעומת זאת, נדרשות כמה יכולות ספרייה רגילות. הוא יכול להחליט באמצעות ספריות סטטיות כדי לחשוף אותן בקובץ בינארי בננו-אפליקציה, או באמצעות קישור דינמי בין הננו-אפליקציה למערכת. הזה כולל, בין היתר:

  • כלי שירות למחרוזות ולמערך: 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 ולספרייה רגילה שאושרה למשימות ספציפיות.

תכונות אופציונליות

כדי לקדם חומרה ותוכנה, ה-CHRE API מחולק לאזורי מאפיינים, שנחשבים אופציונליים מבחינת ה-API. אומנם התכונות האלה ייתכן שאין בהן צורך כדי לתמוך בהטמעת CHRE תואמת, ייתכן שהן שנדרשת לתמיכה בננו-אפליקציה מסוימת. גם אם הפלטפורמה לא תומכת קבוצה מסוימת של ממשקי API, ננו-אפליקציות שמפנות לפונקציות האלה חייבות להיות מסוגלות ליצור וטוענים את המכשיר.

חיישנים

CHRE API מספק את היכולת לבקש נתונים מחיישנים, כולל מד תאוצה, ג'ירוסקופ, מגנטומטר, חיישן אור רגיש וקרבה. ממשקי ה-API האלה נועדו לספק קבוצת תכונות שדומה לחיישנים של Android ממשקי API, כולל תמיכה בקיבוץ דגימות חיישנים כדי להפחית את צריכת החשמל. עיבוד נתוני חיישנים בתוך CHRE מאפשר צריכת חשמל נמוכה יותר וזמן אחזור קצר יותר עיבוד של אותות תנועה בהשוואה להרצה על סמך AP.

GNSS

CHRE מספקת ממשקי API לבקשת נתוני מיקום מניווט גלובלי במערכת לוויינית (GNSS), כולל GPS וכוכבי לוויין אחרים. הזה כולל בקשות לתיקוני מיקום תקופתיים, וגם נתוני מדידה גולמיים, למרות ששניהם בעלי יכולות עצמאיות. ל-CHRE יש קישור ישיר ל-GNSS במערכת המשנה, ההספק מופחת בהשוואה לבקשות GNSS המבוססות על AP, מפני שה-AP יכול להישאר במצב שינה במהלך כל מחזור החיים של סשן במיקום.

Wi-Fi

CHRE מספקת את היכולת ליצור אינטראקציה עם שבב ה-Wi-Fi, בעיקר עבור למטרות מיקום. GNSS פועלת טוב במיקומים בחוץ, אבל התוצאות של סריקות Wi-Fi יכולות לספק פרטי מיקום מדויקים בתוך מבנים ובפיתוח קטגוריות. בנוסף להימנע מהעלות של הפעלת ה-AP לסריקה, CHRE יכולה להאזין לתוצאות של סריקות Wi-Fi שבוצעו על ידי רשת ה-Wi-Fi קושחה למטרות קישוריות, שבדרך כלל לא נשלחת ל-AP מסיבות שקשורות לאספקת חשמל. מינוף של סריקות קישוריות למטרות הקשריות עוזר כדי להפחית את המספר הכולל של סריקות Wi-Fi שמתבצעות, ולחסוך בחשמל.

תמיכה ב-Wi-Fi נוספה ב-CHRE API v1.1, כולל היכולת לעקוב לסרוק תוצאות ולהפעיל סריקות על פי דרישה. היכולות האלה הורחבו ב- v1.2 עם היכולת לבצע זמן נסיעה הלוך ושוב (RTT) מדידות מול נקודות גישה (AP) שתומכות בתכונה הזו, וכך מאפשרות קביעה מדויקת של המיקום היחסי.

רשת WWAN

CHRE API מאפשר לאחזר פרטי זיהוי של תאים תא הצגת המודעות ושאר החלקים שלו, שמשמשים בדרך כלל למטרות מיקום בפירוט גס.

אודיו

התכונה CHRE יכולה לעבד קבוצות של נתוני אודיו ממיקרופון בעל מתח נמוך, בדרך כלל משתמשת בחומרה שמשמשת להטמעת SoundTrigger HAL. בטיפול נתוני אודיו ב-CHRE יכולים לאפשר מיזוג עם נתונים אחרים, כמו תנועה מחיישנים.

הטמעת קובצי עזר

קוד ההפניה של מסגרת CHRE כלול ב-AOSP ב-system/chre הטמענו ב-C++11. אמנם זו לא חובה בלבד, אבל מומלץ לעשות זאת את כל יישומי CHRE שמבוססים על ה-codebase הזה, כדי להבטיח באופן עקבי ולהאיץ את השימוש ביכולות חדשות. אפשר לראות את הקוד הזה היא אנלוגית למסגרת הליבה של Android כי היא של ממשקי API שמשמשים את האפליקציות, ומשמשים כממשקי API בסיסיים כדי להבטיח תאימות. אומנם אפשר להתאים אישית ולהרחיב אותו בעזרת מידע ספציפי לספק יכולות, מומלץ לשמור על הקוד המשותף קרוב ככל האפשר כמה שאפשר. בדומה ל-HALs של Android, ההפניה CHRE נעשות שימוש בהפשטות שונות של פלטפורמות כדי להתאים אותו בכל מכשיר שעומד בדרישות המינימליות.

לקבלת פרטים טכניים ומדריך ניוד, README שנכללות בפרויקט system/chre.