סוגי נתונים

בהינתן קובץ ממשק HIDL, הקצה העורפי Java HIDL יוצר ממשקי Java, לשונית וקוד Proxy. הוא תומך בכל הסוגים הסקלריים של HIDL ([u]int{8,16,32,64}_t, float, double, וגם enums), וגם מחרוזות, ממשקים, סוגי Safe_union, מבנה שונים, מערכים ווקטורים של סוגי HIDL נתמכים. הקצה העורפי Java HIDL לא תומך בסוגי איחוד או בסוגי FMq. במכשירי Android 11 מוסיף תמיכה ב-memory handle סוגים.

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

טיפוסים בני מנייה (enum)

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

לדוגמה, SomeBaseEnum עם סוג של uint8_t:

enum SomeBaseEnum : uint8_t { foo = 3 };
enum SomeEnum : SomeBaseEnum {
    quux = 33,
    goober = 127
};

... הופך ל:

public final class SomeBaseEnum { public static final byte foo = 3; }
public final class SomeEnum {
    public static final byte foo = 3;
    public static final byte quux = 33;
    public static final byte goober = 127;
}

וגם:

enum SomeEnum : uint8_t {
    FIRST_CASE = 10,
    SECOND_CASE = 192
};

... נכתב מחדש כך:

public final class SomeEnum {
    static public final byte FIRST_CASE  = 10;  // no change
    static public final byte SECOND_CASE = -64;
}

מיתרים

הפורמט של String ב-Java הוא utf-8 או utf-16, אבל הוא מומר ל-utf-8 כסוג HIDL נפוץ במהלך העברה. בנוסף, String לא יכול להיות null כשמעבירים אותו ל-HIDL.

כינוי וזיכרון

מערכת Android 11 כוללת תמיכה ב-Java לhandle ול memory סוגים. הן מתורגמות לandroid.os.NativeHandle ול android.os.HidlMemory, בהתאמה. כינוי null נחשב תקין הזיכרון עצמו,

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

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

מידע נוסף על כפילות וסגירה אפשר למצוא במסמכי התיעוד של מחלקות Java.

מערכים ווקטורים

מערכים מתורגמים למערכי Java ומתורגמים וקטורים ArrayList<T> כאשר T הוא סוג האובייקט המתאים, ייתכן כולל סוגים סקלריים, כמו vec<int32_t> => ArrayList<Integer>). מוצרים לדוגמה:

takeAnArray(int32_t[3] array);
returnAVector() generates (vec<int32_t> result);

... הופך ל:

void takeAnArray(int[] array);
ArrayList<Integer> returnAVector();

מבנים

מבנים מתורגמים למחלקות Java בפריסה דומה. עבור דוגמה:

struct Bar {
 vec<bool> someBools;
};
struct Foo {
 int32_t a;
 int8_t b;
 float[10] c;
 Bar d;
};

... הופך ל:

class Bar {
 public final ArrayList<Boolean> someBools = new ArrayList();
};
class Foo {
 public int a;
 public byte b;
 public final float[] c = new float[10];
 public final Bar d = new Bar();
}

סוגים מוצהרים

לכל סוג ברמה העליונה שהוצהר ב-types.hal יש Java משלו. קובץ פלט (כפי שנדרש על ידי Java). לדוגמה, הקובץ types.hal גורם ליצירה של שני קבצים נוספים (Foo.Java ? ו-Bar.Java):

struct Foo {
 ...
};

struct Bar {
 ...

 struct Baz {
 };

 ...
};

ההגדרה של באז נמצאת במחלקה פנימית סטטית של Bar (בBar.java).