ממשק VHAL

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

ה-VHAL של AIDL מוגדר בקובץ android.hardware.automotive.vehicle namespace. ממשק VHAL מוגדר ב-IVehicle.aidl. אלא אם צוין אחרת, צריך להטמיע את כל השיטות לגרסה ספציפית של VHAL.

גרסאות

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

פונקציות וקריאות חוזרות

הפונקציות של VHAL מוגדרות ב-IVehicle.aidl.

פונקציות ה-callbacks מוגדרות ב-IVehicleCallback.aidl, והן מכילות את השיטות האלה.

הטמעת VHAL מאומתת על ידי VHAL VTS בכתובת VtsHalAutomotiveVehicle_TargetTest.cpp.

הבדיקה מוודאת שהשיטות הבסיסיות מיושמות בצורה נכונה ושההגדרות של הנכסים הנתמכים נכונות. הבדיקה פועלת בכל המכונות של VHAL במכשיר, אבל מערכת AAOS משתמשת רק במכונה שמוגדרת כברירת מחדל (android.hardware.automotive.vehicle.IVehicle/default).

ערך מאפיין הרכב

משתמשים במבנה VehiclePropValue כדי לתאר את הערך של כל מאפיין, שכולל את השדות הבאים:

פונקציות getValues ו-setValues אסינכרוניות

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

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

איור 1. תהליך אסינכרוני.

רכיבי parcelable גדולים

כל המבנים שנקראים XXXs, כמו VehiclePropConfigs,‏ SetValueRequests ו-VehiclePropValues, נקראים LargeParcelable (או StableLargeParcelable). כל אחד מהם מייצג רשימה של ערכים שמשמשים להעברת נתונים גדולים שעשויים לחרוג מהמגבלות של ה-binder (4KB בהטמעה של הספרייה LargeParcelable) מעבר לגבולות ה-binder. לכל אחד מהם יש הגדרת מבנה דומה שמכילה את השדות הבאים.

לדוגמה, VehiclePropConfigs מוגדר בתור:

parcelable VehiclePropConfigs {
    // The list of vehicle property configs if they fit the binder memory
    // limitation.
    VehiclePropConfig[] payloads;
    // Shared memory file to store configs if they exceed binder memory
    // limitation. Created by VHAL, readable only at client. Client could keep
    // the fd opened or keep the FD mapped to access configs.
    @nullable ParcelFileDescriptor sharedMemoryFd;
}

VehiclePropConfigs מכיל עומסי נתונים לא ריקים או את הערך sharedMemoryFd שאינו null.

• אם השדה payloads לא ריק, הוא מאחסן רשימה של הנתונים בפועל, שהם הגדרות הנכס.
• אם הערך של sharedMemoryFd הוא לא null, הוא מכיל קובץ של זיכרון משותף שמאחסן את המבנה המסודר של VehiclePropConfigs. המבנה משתמש בפונקציה writeToParcel כדי לסדר את הנתונים של Parcel.

כלקוח Java ל-VHAL, Car Service מטפל בסריאליזציה ובדה-סריאליזציה של LargeParcelable. להטמעות VHAL וללקוחות מקומיים, צריך לבצע סריאליזציה ופעולה הפוכה של LargeParcelable באמצעות הספרייה LargeParcelable או באמצעות כיתת wrapper שימושית לספרייה ב-ParcelableUtils.h.

לדוגמה, לקוח מקומי שמנתח בקשות ל-getValues שקיבלו מ-binder:

// 'requests' are from the binder.
GetValueRequests requests;
expected<LargeParcelableBase::BorrowedOwnedObject, ScopedAStatus> deserializedResults = fromStableLargeParcelable(requests);
if (deserializedResults.ok()) {
    const std::vector& getValueRequests = deserializedResults.value().getObject()->payloads;
    // Use the getValueRequests.
  } else {
    // handle error.
}

בהמשך מוצגת דוגמה להטמעת VHAL ששולחת תוצאות של getValues דרך ה-binder:

std::vector results = getResults();
GetValueResults parcelableResults;
ScopedAStatus status = vectorToStableLargeParcelable(std::move(results), &parcelableResults);
if (status.isOk()) {
    // Send parcelableResults through callback.
} else {
    // Handle error.
}