סמארטפונים מכילים מספר מעבדים, שכל אחד מהם מותאם לביצוע משימות שונות. עם זאת, אנדרואיד פועל רק על מעבד אחד: מעבד היישומים (AP). ה-AP מכוון לספק ביצועים מעולים עבור מקרי שימוש במסך כמו משחקים, אבל הוא צריכת חשמל מכדי לתמוך בתכונות הדורשות פרצי עיבוד תכופים וקצרים כל הזמן, גם כשהמסך כבוי. מעבדים קטנים יותר מסוגלים להתמודד עם עומסי העבודה הללו ביעילות רבה יותר, ולהשלים את המשימות שלהם מבלי להשפיע באופן ניכר על חיי הסוללה. עם זאת, סביבות התוכנה במעבדים בעלי הספק נמוך מוגבלות יותר ויכולות להשתנות מאוד, מה שמקשה על פיתוח חוצה פלטפורמות.
Context Hub Runtime Environment (CHRE) מספקת פלטפורמה משותפת להפעלת אפליקציות על מעבד בעל הספק נמוך, עם API פשוט, סטנדרטי וידידותי משובץ. CHRE מקל על יצרני ציוד מקורי ושותפיהם המהימנים להוריד עיבוד מ-AP, לחסוך בסוללה ולשפר תחומים שונים של חווית המשתמש, ולאפשר מחלקה של תכונות תמיד-פועלות ומודעות להקשר, במיוחד אלה הכוללות יישום של מכונה. ללמוד חישת סביבה.
מושגי מפתח
CHRE היא סביבת התוכנה שבה יישומים מקומיים קטנים, הנקראים nanoapps , פועלים על מעבד בעל הספק נמוך ומקיימים אינטראקציה עם המערכת הבסיסית באמצעות ה-CHRE API המשותף. כדי להאיץ יישום נכון של ממשקי ה-API של CHRE, יישום התייחסות חוצה פלטפורמות של CHRE נכלל ב-AOSP. יישום ההתייחסות כולל קוד משותף והפשטות לחומרה ולתוכנה הבסיסית באמצעות סדרה של שכבות הפשטה של פלטפורמה (PAL). אפליקציות ננו קשורות כמעט תמיד ליישומי לקוח אחת או יותר הפועלות באנדרואיד, המקיימות אינטראקציה עם CHRE וננו אפליקציות באמצעות ממשקי API של מערכת ContextHubManager בגישה מוגבלת.
ברמה גבוהה, ניתן לשרטט הקבלות בין הארכיטקטורה של CHRE ואנדרואיד כולה. עם זאת, יש כמה הבחנות חשובות:
- CHRE תומך בהפעלת ננו-אפליקציות בלבד שפותחו בקוד מקורי (C או C++); Java אינה נתמכת.
- בשל אילוצי משאבים ומגבלות אבטחה, CHRE אינו פתוח לשימוש על ידי אפליקציות אנדרואיד שרירותיות של צד שלישי. רק אפליקציות מהימנות במערכת יכולות לגשת אליה.
יש גם הבחנה חשובה בין הרעיון של CHRE לבין רכזת חיישנים. למרות שמקובל להשתמש באותה חומרה כדי ליישם את רכזת החיישנים ואת CHRE, CHRE עצמו אינו מספק את פונקציונליות החיישנים הנדרשת על ידי Android Sensors HAL . CHRE קשור ל-Context Hub HAL, והוא פועל כלקוח של מסגרת חיישנים ספציפית למכשיר כדי לקבל נתוני חיישנים מבלי לערב את ה-AP.
איור 1. ארכיטקטורת מסגרת CHRE
Context Hub HAL
שכבת ההפשטה של החומרה של Context Hub (HAL) היא הממשק בין מסגרת האנדרואיד והטמעת CHRE של המכשיר, המוגדרת ב- hardware/interfaces/contexthub . ה-Context Hub HAL מגדיר את ממשקי ה-API שדרכם מסגרת האנדרואיד מגלה את רכזות ההקשר הזמינות ואת הננו-אפליקציות שלהם, מקיימת אינטראקציה עם הננו-אפליקציות הללו באמצעות העברת הודעות, ומאפשרת לטעון ולפרוק ננו-אפליקציות. יישום עזר של Context Hub HAL שעובד עם יישום עזר של CHRE זמין ב- system/chre/host .
במקרה של סתירה בין תיעוד זה לבין הגדרת HAL, הגדרת HAL עדיפה.
אִתחוּל
כאשר Android מאתחל, ContextHubService מפעיל את הפונקציה getHubs() HAL כדי לקבוע אם רכזות הקשר זמינות במכשיר. זוהי שיחה חוסמת וחד פעמית, ולכן עליה להסתיים במהירות כדי למנוע עיכוב באתחול, והיא חייבת להחזיר תוצאה מדויקת, מכיוון שלא ניתן להציג רכזות הקשר חדשות לאחר מכן.
טעינה ופריקה של ננו-אפליקציות
רכזת הקשר יכולה לכלול קבוצה של אפליקציות ננו הנכללות בתמונת המכשיר ונטענות כאשר CHRE מתחיל. אלה ידועים בשם ננו-אפליקציות שנטענו מראש, ויש לכלול אותם בתגובה האפשרית הראשונה ל- queryApps() .
ה-Context Hub HAL תומך גם בטעינה ובפריקה של ננו-אפליקציות באופן דינמי בזמן ריצה, באמצעות הפונקציות loadNanoApp() ו- unloadNanoApp() . ננו-אפליקציות מסופקות ל-HAL בפורמט בינארי ספציפי ליישום החומרה והתוכנה CHRE של המכשיר.
אם המימוש לטעינת ננו-אפליקציה כולל כתיבתו לזיכרון לא נדיף, כגון אחסון פלאש המחובר למעבד המריץ את CHRE, אז מימוש ה-CHRE חייב תמיד לאתחל עם ננו-אפליקציות דינמיות אלו במצב מושבת. משמעות הדבר היא שאף אחד מהקודים של nanoapp לא מבוצע עד שמתקבלת בקשת enableNanoapp() דרך ה-HAL. ננו-אפליקציות שנטענו מראש יכולים לאתחל במצב מופעל.
רכזת ההקשר מופעל מחדש
בעוד ש-CHRE לא צפוי להפעיל מחדש במהלך הפעולה הרגילה, ייתכן שיהיה צורך להתאושש מתנאים בלתי צפויים כגון ניסיון לגשת לכתובת זיכרון לא ממופה. במצבים אלה, CHRE מופעל מחדש באופן עצמאי מאנדרואיד. ה-HAL מודיע על כך לאנדרואיד באמצעות אירוע RESTARTED , שאותו עליו לשלוח רק לאחר ש-CHRE אותחל מחדש עד כדי כך שהוא יכול לקבל בקשות חדשות, כגון queryApps() .
סקירת מערכת CHRE
CHRE מתוכנן סביב ארכיטקטורה מונעת אירועים, כאשר יחידת החישוב העיקרית היא אירוע המועבר לנקודת הכניסה לטיפול באירועים של ננו-אפליקציה. בעוד שמסגרת CHRE יכולה להיות מרובת הליכי הליכי, ננו-אפליקציה נתונה לעולם אינה מבוצעת ממספר שרשורים במקביל. המסגרת של CHRE מקיימת אינטראקציה עם ננו-אפליקציה נתון דרך אחת משלוש נקודות הכניסה של ננו-אפליקציה ( nanoappStart() , nanoappHandleEvent() ו- nanoappEnd() ) או באמצעות התקשרות חוזרת שסופקה בקריאה קודמת ל-CHRE API, וננו-אפליקציות מקיימות אינטראקציה עם מסגרת CHRE ו המערכת הבסיסית באמצעות CHRE API. ה-CHRE API מספק קבוצה של פונקציונליות בסיסית כמו גם מתקנים לגישה לאותות הקשריים, כולל חיישנים, GNSS, Wi-Fi, WWAN ואודיו, וניתן להרחיב אותו עם יכולות נוספות ספציפיות לספק לשימוש על ידי ננו-אפליקציות ספציפיות לספק .
בניית מערכת
בעוד שה-Context Hub HAL ורכיבים נחוצים אחרים בצד AP בנויים לצד אנדרואיד, לקוד שפועל בתוך CHRE יכולות להיות דרישות שהופכות אותו לבלתי תואם למערכת הבנייה של אנדרואיד, כמו הצורך בשרשרת כלים מיוחדת. לכן, פרויקט CHRE ב-AOSP מספק מערכת בנייה פשוטה המבוססת על GNU Make כדי להדר ננו-אפליקציות, ובאופן אופציונלי, את מסגרת CHRE לספריות שניתן לשלב עם המערכת. יצרני התקנים המוסיפים תמיכה ב-CHRE צריכים לשלב תמיכת מערכת לבנות עבור התקני היעד שלהם ב-AOSP.
ה-CHRE API נכתב לתקן שפת C99, והטמעת ההפניה משתמשת בתת-קבוצה מוגבלת של C++11 המתאימה ליישומים מוגבלים במשאבים.
CHRE API
ה-CHRE API הוא אוסף של קבצי כותרת C המגדירים את ממשק התוכנה בין ננו-אפליקציה למערכת. זה נועד להפוך את קוד הננו-אפליקציות לתואם בכל המכשירים התומכים ב-CHRE, מה שאומר שאין צורך לשנות את קוד המקור של ננו-אפליקציה כדי לתמוך בסוג מכשיר חדש, אם כי ייתכן שיהיה צורך להידור מחדש במיוחד עבור המעבד של מכשיר היעד ערכת הוראות או ממשק בינארי של יישומים (ABI). ארכיטקטורת ה-CHRE ועיצוב ה-API גם מבטיחים שננו-אפליקציות תואמות בינאריות על פני גרסאות שונות של ה-CHRE API, מה שאומר שאין צורך להידור מחדש של ננו-אפליקציה כדי לרוץ על מערכת המיישמת גרסה שונה של ה-CHRE API בהשוואה ל-CHRE API. ה-API של היעד שלפיו ה-nanoapp מורכב. במילים אחרות, אם קובץ בינארי של nanoapp פועל על מכשיר התומך ב-CHRE API v1.3, והמכשיר הזה משודרג לתמיכה ב-CHRE API v1.4, אותו בינארי של nanoapp ממשיך לתפקד. באופן דומה, הננו-אפליקציה יכול לרוץ על CHRE API v1.2, ויכול לקבוע בזמן הריצה אם הוא דורש פונקציונליות מ-API v1.3 כדי להשיג את הפונקציונליות שלו, או שהוא יכול לפעול, פוטנציאלי עם השפלה של תכונות חינניות.
גרסאות חדשות של CHRE API משוחררות לצד אנדרואיד, אולם מכיוון שהטמעת CHRE היא חלק מהטמעת הספק , גרסת CHRE API הנתמכת במכשיר אינה בהכרח מקושרת לגרסת אנדרואיד.
סיכום גרסה
כמו סכימת הגירסאות HIDL של אנדרואיד , ה-CHRE API עוקב אחר גירסה סמנטית . הגרסה הראשית מציינת תאימות בינארית, בעוד שהגרסה המשנית גדלה כאשר מוצגות תכונות תואמות לאחור. ה-CHRE API כולל הערות קוד מקור כדי לזהות איזו גרסה הציגה פונקציה או פרמטר, למשל @since v1.1 .
הטמעת CHRE גם חושפת גרסת תיקון ספציפית לפלטפורמה באמצעות chreGetVersion() , אשר מציינת מתי מתבצעים תיקוני באגים או עדכונים קלים ביישום.
גרסה 1.0 (אנדרואיד 7)
כולל תמיכה בחיישנים ופונקציונליות ליבה של ננו-אפליקציות, כגון אירועים וטיימרים.
גרסה 1.1 (אנדרואיד 8)
מציג יכולות מיקום באמצעות מיקום GNSS ומדידות גולמיות, סריקת Wi-Fi ומידע רשת סלולרית, יחד עם חידודים כלליים כדי לאפשר תקשורת ננו-אפליקציה לננו-אפליקציה ושיפורים אחרים.
גרסה 1.2 (אנדרואיד 9)
מוסיף תמיכה בנתונים ממיקרופון בצריכת חשמל נמוכה, טווח Wi-Fi RTT, התראות AP ערה/שינה ושיפורים אחרים.
גרסה 1.3 (אנדרואיד 10)
משפר יכולות הקשורות לנתוני כיול חיישנים, מוסיף תמיכה בשטיפת נתוני חיישן אצווה לפי דרישה, מגדיר את סוג חיישן זיהוי הצעדים ומרחיב אירועי מיקום GNSS עם שדות דיוק נוספים.
גרסה 1.4 (אנדרואיד 11)
מוסיף תמיכה במידע סלולרי 5G, dump debug 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++ ספריות קלט/פלט סטנדרטיות
- 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 לרישום באגים הממוקדים למערכת Android logcat, כאשר תוכנית מסורתית יותר עשויה להשתמש printf או std::cout .
לעומת זאת, נדרשת פונקציונליות מסויימת של ספרייה סטנדרטית. זה תלוי ביישום הפלטפורמה לחשוף אותם באמצעות ספריות סטטיות להכללה בבינארי של ננו-אפליקציה, או על ידי קישור דינמי בין הננו-אפליקציה למערכת. זה כולל, אך לא מוגבל ל:
- כלי עזר למחרוזות/מערך:
memcmp,memcpy,memmove,memset,strlen ספריית מתמטיקה: פונקציות נפוצות של נקודה צפה בעלת דיוק יחיד:
- פעולות בסיסיות:
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 אלה נועדו לספק מערך תכונות הדומה לממשקי ה-API של חיישני Android, כולל תמיכה באיסוף דגימות חיישנים כדי להפחית את צריכת החשמל. עיבוד נתוני חיישנים בתוך CHRE מאפשר הספק נמוך בהרבה ועיבוד חביון נמוך יותר של אותות תנועה בהשוואה לריצה על ה-AP.
GNSS
CHRE מספקת ממשקי API לבקשת נתוני מיקום ממערכת לווייני ניווט גלובלית (GNSS), כולל GPS וקבוצות לווייניות אחרות. זה כולל בקשות לתיקוני מיקום תקופתיים, כמו גם נתוני מדידה גולמיים, אם כי שתיהן יכולות עצמאיות. מכיוון של-CHRE יש קישור ישיר לתת-מערכת ה-GNSS, ההספק מופחת בהשוואה לבקשות GNSS מבוססות AP, מכיוון שה-AP יכול להישאר במצב שינה במהלך כל מחזור החיים של הפעלת מיקום.
וויי - פיי
CHRE מספק את היכולת ליצור אינטראקציה עם שבב ה-Wi-Fi, בעיקר למטרות מיקום. בעוד GNSS עובד היטב עבור מיקומים חיצוניים, התוצאות של סריקות Wi-Fi יכולות לספק מידע מיקום מדויק בתוך הבית ובאזורים מפותחים. בנוסף להימנעות מהעלות של הערת ה-AP לסריקה, CHRE יכול להאזין לתוצאות של סריקות Wi-Fi המבוצעות על ידי קושחת ה-Wi-Fi למטרות קישוריות, שבדרך כלל אינן מועברות ל-AP מסיבות מתח. מינוף סריקות קישוריות למטרות הקשריות עוזר להפחית את המספר הכולל של סריקות Wi-Fi שבוצעו, תוך חיסכון בחשמל.
תמיכה ב-Wi-Fi נוספה ב-CHRE API v1.1, כולל היכולת לנטר את תוצאות הסריקה ולהפעיל סריקות לפי דרישה. יכולות אלו הורחבו ב-v1.2 עם היכולת לבצע מדידות Round-Trip Time (RTT) מול נקודות גישה התומכות בתכונה, מה שמאפשר קביעת מיקום יחסי מדויק.
WWAN
ה-CHRE API מספק את היכולת לאחזר מידע זיהוי תא עבור התא המשרת ושכניו, אשר משמש בדרך כלל למטרות מיקום גס.
שֶׁמַע
CHRE יכול לעבד קבוצות של נתוני אודיו ממיקרופון בעל הספק נמוך, שבדרך כלל מנצל חומרה המשמשת ליישום SoundTrigger HAL. עיבוד נתוני אודיו ב-CHRE יכול לאפשר את מיזוגם עם נתונים אחרים, כגון חיישני תנועה.
יישום התייחסות
קוד התייחסות למסגרת CHRE כלול ב-AOSP בפרויקט system/chre , מיושם ב-C++11. אמנם לא חובה בהחלט, אבל מומלץ שכל יישומי CHRE יתבססו על בסיס קוד זה, כדי לעזור להבטיח עקביות ולהאיץ אימוץ של יכולות חדשות. ניתן לראות את הקוד הזה כאנלוגי למסגרת הליבה של אנדרואיד בכך שהוא יישום קוד פתוח של ממשקי API שבהם יישומים משתמשים, המשמש קו בסיס וסטנדרט לתאימות. למרות שניתן להתאים אותו ולהרחיב אותו עם יכולות ספציפיות לספק, ההמלצה היא לשמור על הקוד המשותף קרוב ככל האפשר להפניה. בדומה ל-HALs של אנדרואיד, הטמעת התייחסות CHRE משתמשת בהפשטות פלטפורמה שונות כדי לאפשר לה להיות מותאם לכל מכשיר העומד בדרישות המינימום.
לפרטים טכניים ומדריך העברה, עיין ב- README הכלול בפרויקט system/chre .