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

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

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

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

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

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

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

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

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

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

ה-HAR לא מטפל בנושאים הבאים:

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

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

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

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

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

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

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

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

ארגז HAR

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

המבנה הכללי של display-safety

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

ארגז, מסגרת ואפליקציה של HAR

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

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

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

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

שם ההפשטה פונקציה קשורה תיאור הערות
OpenGL רינדור דו-ממדי מספק יכולות רינדור של OpenGLES 2.0/3.0 ל-crate של מסגרת HAR.
Audio עיבוד אודיו מספק ממשק כמו Android SoundPool לניהול ולהפעלה של אודיו במערכת.
Camera תצוגת מצלמת הרכב מספק ממשק דמוי EVS HAL לניהול ולהצגה של מידע ממצלמת הרכב.
Looper הלולאה הראשית של האפליקציה והגדרת התצוגה מספק ממשק שדומה ל-Android Looper כדי לנהל את הלולאות הראשיות של האפליקציה ואת הגדרות התצוגה בהתאם לפלטפורמה.
UserInput מגע, מקלדת, הגה או חוגה וקלט אחר שספציפי לפלטפורמה מספק ממשק שמאפשר להזין קלט מגע ומקלדת לאפליקציות שמבוססות על HAR. הטמעת קובץ עזר שמבוססת על Linux evdev ב-har-user-input-evdev.
VehicleData שדה להזנת מצב הרכב ממשק שמספק לאפליקציות שמבוססות על HAR זרם של נתוני רכב שרירותיים, כמו אלה שסופקו על ידי Android VHAL או CAN bus.
ResourceManager מסמך עיצוב ספציפי לאפליקציה שנשמר במטמון מספק מטמון בזיכרון של משאבים שנדרשים להפעלת HAR, כמו תמונות שנשמרו במטמון ומסמכי עיצוב. עדיין לא הוטמע מטמון דיסק.
Logging רישום ביומן המערכת וטלמטריה מספק תמיכה ברישום ביומן שספציפי לפלטפורמה באמצעות מערכת המעקב. כך אפשר לאסוף נתוני טלמטריה כפי שנדרש על ידי הפלטפורמה.
Tracing תיעוד עקבות המערכת מספק הפשטה לשילוב עם מערכות מעקב ופרופילים.
Monitoring מעקב אחר המערכת ערכת כלים למעקב אחרי הביצועים וזמני האחזור במסגרת HAR.
Commlib נתוני הרכב הטמעה לדוגמה באמצעות סריאליזציה של protobuf. הוצא משימוש: צריך להשתמש בממשקי API שמוגדרים ב-reference/harry-control-api ובהטמעות harry-grpcio-server ו-harry-tonic-server (הטמעת קובץ עזר).
TestSupport הוקים לתמיכה בבדיקות תמיכה בהגדרה ובפירוק של מקרי בדיקה, ביצירת אירועי בדיקה ובארטיפקטים של בדיקות. לדוגמה, יצירת אירועי מגע מדומים כדי לבדוק את UserInput ויצירת צילומי מסך לניתוח. התכונה הזו נעולה על ידי Rust כדי למנוע הכללה בגרסאות build בסביבת הייצור.

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

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

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

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

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

שמות של תכונות שמות ההטמעות מבנים ורשימות של HAR framework
GlContextFactory OpenGL trait harry::Renderer
harry::DisplayRotation
AudioApiFactory Audio harry::AudioApi
harry::AudioDevice
harry::VolumeMillibel
ICameraManager Camera harry::ICameraDevice
harry::CameraDescriptor
Looper Looper harry::LooperMessage
harry::LooperOptions
harry::DisplayId
PlatformVehicleData VehicleData harry::VehicleDataType
harry::VehicleDataListener
ResourceManager (Struct) ResourceManager harry::ResourceManagerMessage
harry::ResourceToken
harry::RawImageData
PlatformTracing Tracing לא רלוונטי
HarPerformanceMonitor Monitoring harry::Renderer
harry::ResolveLatencyToken
PlatformTestSupport TestSupport harry::TestConfig
harry::TestDisplayConfig

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

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

השגיאות שמוחזרות על ידי הטמעות של פלטפורמות הן מסוג harry::error::Error. כדי לוודא שסוגי שגיאות של הפלטפורמה לא דולפים לקוד של האפליקציה, צריך להשתמש בשגיאה סטנדרטית (stderr) שסופקה על ידי מסגרת ה-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),
}

שגיאות שבעקבותיהן אי אפשר לשחזר מוחזרות בעיקר דרך הממשקים והקריאות החוזרות (callbacks) שהוגדרו.

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

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

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

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

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

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