שכבת הפשטה של פלטפורמת HAR

משתמשים ב-HAR (רכיב עיבוד עם זמינות גבוהה) כדי להציג מידע על הרכב ש-Android לא יכול להציג. זה יכול לקרות בגלל בעיות כמו הפעלה, זמינות, בטיחות או תקנות. ‫HAR היא אפליקציה ניידת ומובנית שנכתבה ב-Rust.

‫HAR, שנקרא גם מסגרת HAR, כולל קוד שמשמש לבניית אפליקציות. אפליקציה שנבנתה באמצעות HAR היא אפליקציה מבוססת-HAR. למסגרת HAR יש קטעי קוד לפלטפורמות שונות. לדוגמה, במערכת Linux, משתמשים בספריות כמו tinyalsa לצלילים. ל-QNX יש ספריות אודיו ייחודיות משלה.

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

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

חבילת מקרים לבדיקה של HAR מריצה בדיקות בכל מערכות המשנה שהוטמעו בפלטפורמה. בעזרת החבילה הזו אפשר לבדוק אם הפלטפורמות עומדות בדרישות של HAR ולמצוא בעיות חדשות.

הסברים על המונחים

המונחים האלה מופיעים בדף הזה:

אפליקציה מבוססת-HAR

אפליקציה ספציפית לפונקציה או ל-OEM שנבנתה באמצעות מסגרת HAR. אפליקציות שונות זו מזו לפי מצב האפליקציה ומאפיינים אחרים שאפשר להתאים אישית.

מסגרת HAR

מספק קבוצה בסיסית של כלים שמשמשים לבניית אפליקציות.

הפשטה של פלטפורמת HAR

חלק ממסגרת HAR שמספקת API מוכר שכל פלטפורמות היעד צריכות להטמיע.

חבילת מקרים לבדיקה HAR

סדרה של בדיקות מוכרות על הטמעות של פלטפורמות, שעוזרות לוודא שהטמעות של פלטפורמות תומכות ב-framework של HAR בפלטפורמה נתונה.

נכסים מוסתרים

קובץ HAR לא כולל:

• הטמעות נפרדות לכל פלטפורמת יעד: הטמעות לפלטפורמות יעד. במקום זאת, בדף הזה מתוארים הממשקים שיישומים של פלטפורמות צריכים לכלול, ו<b>חבילת מקרים לבדיקה</b> שצריך לעמוד בה.

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

מבנה ארגזים ברמה גבוהה של הפשטת פלטפורמה

פרויקטים ב-Rust מורכבים מ-crates. באיור 1 מוצגת מבנה ה-crate של שכבת ההפשטה של פלטפורמת ה-HAR. שכבת ההפשטה של הפלטפורמה משפיעה על שני ארגזי Rust או יותר:

• ההפשטות (תיאורי Rust trait) נמצאות בתיבת ה-crate של מסגרת HAR.

• ההטמעות בפלטפורמה מתבצעות באמצעות har-platform-x crate נפרד. לדוגמה, har-platform-linux או har-platform-android.

אי אפשר ליצור או לבדוק את תיבת ה-HAR בלי לציין הטמעה של פלטפורמה. זה מכוון כי מסגרת HAR היא מסגרת.

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

איור 1. ארגז HAR.

מבנה כללי בתוך display-safety

העיצוב הזה מוסיף סדרה של תיבות חדשות למאגר display_safety, כמו שמוצג באיור 2:

איור 2. מודולים של הפשטה.

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

תיאור כללי של שכבת ההפשטה של הפלטפורמה

בטבלה הזו מתוארות מערכות משנה ספציפיות לפלטפורמה שמוגדרות על ידי שכבת ההפשטה של פלטפורמת HAR.

מוסכמות מתן שמות ומבני מסגרות

בטבלה הזו מוצגים השמות והמבנים האלה:

• מופעים צפויים של מערכת משנה trait שסופקו על ידי מסגרת HAR. כל trait מייצג מערכת משנה ספציפית לפלטפורמה שצריך להטמיע.

• השמות הצפויים של יישומי מערכת משנה ספציפיים לפלטפורמה בכל תיבת פלטפורמה. אפליקציות שמבוססות על HAR מצפות שהשמות הספציפיים האלה יוטמעו.

• בדרך כלל משתמשים במופעים קשורים של מסגרת HAR‏ enum ו-struct כדי להעביר מידע מהטמעות שקשורות לפלטפורמה אל מסגרת HAR.

שגיאות וטיפול בשגיאות

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

שגיאות שמוחזרות מהטמעות של פלטפורמות הן מסוג harry::error::Error. כדי לוודא שסוגי השגיאות של הפלטפורמה לא חודרים לקוד האפליקציה, משתמשים בסוג השגיאה הרגיל שמסופק על ידי מסגרת ה-HAR.

סוג harry::error::Error מתרחב וכולל שגיאות ספציפיות לכל מערכות המשנה:

// This is Rust
pub enum Error {
  Msg(String), // A generic message string
  // Legacy error type, likely to be removed or merged into Msg
  Audio(String),
}

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

עיצוב מפורט של חבילת מקרים לבדיקה

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

יצירת בדיקות בחבילת מקרים לבדיקה

ב-Soong builds (מוגדרים על ידי קובצי Android.bp), הבדיקות עוברות קומפילציה כחלק ממערכת ה-build של פלטפורמת Android, וההפעלה שלהן מנוהלת על ידי atest.

הרצת חבילת מקרים לבדיקה

כדי לבדוק פלטפורמה ספציפית:

משתמשים בפקודה atest עם יעד הבדיקה הרלוונטי (לדוגמה, atest <module_name>). הפקודה הזו פורסת את הבדיקות ומריצה אותן במכשיר או באמולטור של Android.