À 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
).