Types de données

À partir d'un fichier d'interface HIDL, le backend Java HIDL génère des interfaces Java, bouchon et code de proxy. Compatible avec tous les types de HIDL scalaire ([u]int{8,16,32,64}_t, float, double, et enum, ainsi que les chaînes, les interfaces, les types safe_union, les champs les tableaux et les vecteurs des types HIDL pris en charge. Le backend Java HIDL N'est PAS compatible avec les types "union" ni "fmq". Android 11 prend en charge memory et Types handle.

Comme l'environnement d'exécution Java n'accepte pas le concept d'entiers non signés de manière native, tous les types non signés (et les énumérations basées sur ceux-ci) sont traités silencieusement comme leurs équivalents signés (par exemple, uint32_t devient int dans l'interface Java. Aucune conversion de valeur n'est effectuée. le responsable de la mise en œuvre Le côté Java doit utiliser les valeurs signées comme si elles n'étaient pas signées.

Énumérations

Les énumérations ne génèrent pas de classes d'énumération Java, mais sont traduites en contenant une définition de constante statique pour chaque cas d'énumération. Si l'énumération dérive d'une autre classe d'énumération, elle hérite du type de stockage de cette classe. Les énumérations basées sur un type d'entier non signé sont réécrites dans leur équivalent. Étant donné que le type sous-jacent est un type primitif, la valeur par défaut Les champs/variables d'énumération sont nuls, même en l'absence d'énumérateur.

Par exemple, un SomeBaseEnum dont le type est uint8_t:

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

... devient:

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;
}

Et:

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

... est réécrit comme suit:

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

Strings

String en Java est utf-8 ou utf-16, mais est converti en utf-8 comme type de HIDL commun lors du transport. En outre, String ne doit pas être nulle lorsqu'elle est transmise à HIDL.

Identifiant et mémoire

Android 11 prend en charge Java pour handle et Types memory. Ils sont traduits en android.os.NativeHandle et android.os.HidlMemory, respectivement. Un handle nul est considéré comme valide, tandis qu'un Null la mémoire ne l’est pas.

Dans le code server généré, les arguments de mémoire reçue et de traitement ne sont que valide dans le champ d'application de l'appel de méthode. Si l'implémentation du serveur souhaite étendre sa durée de vie, ils doivent être dupliqués à l'aide de leurs méthodes dup() correspondantes. La L'instance renvoyée peut être utilisée au-delà de l'appel de méthode et doit être correctement fermée une fois l'opération terminée. .

Dans le code client généré, traite et garde les instances de mémoire qui sont envoyés en tant qu'arguments d'entrée de la méthode appelée, qui n'ont pas besoin d'être dupliqués ni conservés valide après le retour de la méthode. Cependant, les identifiants et les instances de mémoire received en tant qu'arguments de sortie sont automatiquement dupliqués par code généré automatiquement et doit être correctement fermé une fois l'opération terminée. C'est vrai que ces méthodes renvoient arguments apparaissent en tant que valeurs de retour de la méthode (dans le cas d'une valeur de retour unique) ou en utilisant les style de rappel synchrone (utilisé dans le cas de valeurs de retour multiples).

Pour en savoir plus sur la duplication et la fermeture, consultez la documentation relative aux classes Java.

Tableaux et vecteurs

Les tableaux sont traduits en tableaux Java, et les vecteurs sont traduits en ArrayList<T>, où T est le type d'objet approprié, éventuellement encapsulant des types scalaires tels que vec<int32_t> => ArrayList<Integer>). Par exemple:

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

... devient:

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

Structures

Les structures sont converties en classes Java avec une mise en page similaire. Exemple :

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

... devient:

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 déclarés

Chaque type de niveau supérieur déclaré dans types.hal a son propre fichier .java de sortie (comme requis par Java). Par exemple : Le fichier types.hal entraîne la création de deux fichiers supplémentaires (Foo.java). et Bar.java):

struct Foo {
 ...
};

struct Bar {
 ...

 struct Baz {
 };

 ...
};

La définition de Baz se trouve dans une classe interne statique de Bar (dans Bar.java).