Data types

Given a HIDL interface file, the Java HIDL backend generates Java interfaces, Stub, and Proxy code. It supports all scalar HIDL types ([u]int{8,16,32,64}_t, float, double, and enums), as well as strings, interfaces, safe_union types, struct types, and arrays and vectors of supported HIDL types. The Java HIDL backend does NOT support union types or fmq types. Android 11 adds support for the memory and handle types.

As Java runtime doesn't support the concept of unsigned integers natively, all unsigned types (and enums based on them) are silently treated as their signed equivalents, i.e. uint32_t becomes an int in the Java interface. No value conversion is performed; the implementor on the Java side must use the signed values as if they were unsigned.

Enums

Enums don't generate Java enum classes but are instead translated into inner classes containing a static constant definition for each enum case. If the enum class derives from some other enum class, it inherits that class's storage type. Enumerations based on an unsigned integer type are rewritten into their signed equivalent. Since the underlying type is a primitive, the default value for enum fields/variables is zero even when there is no zero enumerator.

For example, a SomeBaseEnum with a type of uint8_t:

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

… becomes:

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

And:

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

… is rewritten as:

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

Strings

String in Java is utf-8 or utf-16 but is converted to utf-8 as the common HIDL type when transported. Additionally, String must not be null when passed into HIDL.

Handle and memory

Android 11 introduces Java support for the handle and memory types. They are translated into android.os.NativeHandle and android.os.HidlMemory, respectively. A null handle is considered valid, while a null memory isn't.

In the generated server code, received memory and handle arguments are only valid within the scope of the method invocation. If the server implementation wants to extend their lifetime, they must be duplicated using their resepective dup() methods. The returned instance can be used beyond the method invocation and should be properly closed when done with.

In the generated client code, handles and memory instances that are sent as input arguments of the called method don't need to be duplicated nor kept valid after the method returns. However, handles and memory instances that are received as output arguments are automatically duplicated by the autogenerated code and must be properly closed when done with. This is true whether those return arguments appear as return values of the method (in the single return value case) or using the synchronous callback style (used in the multiple return value case).

For more information about duplication and closing, see the documentation of the Java classes.

Arrays and vectors

Arrays are translated into Java arrays and vectors are translated into ArrayList<T> where T is the appropriate object type, possibly wrapping scalar types such as vec<int32_t> => ArrayList<Integer>). For example:

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

… becomes:

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

Structures

Structures are translated into Java classes with a similar layout. For example:

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

… becomes:

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

Declared types

Each top-level type declared in types.hal gets its own .java output file (as required by Java). For example, the following types.hal file results in two extra files being created (Foo.java and Bar.java):

struct Foo {
 ...
};

struct Bar {
 ...

 struct Baz {
 };

 ...
};

The definition of Baz lives in a static inner class of Bar (in Bar.java).