C

Qt IF Generator Extensions

Qt IF Generator Extensions allows building a middleware layer for accessing Android Automotive Vehicle Properties. It makes use of tools and core APIs provided by the Qt Interface Framework module. It also delivers additional templates that can be used to generate additional project types:

Project TypeDescription
server_android_carapi_qtroGenerates a QtRemoteObjects based back end server implementation for the API first generated by the frontend option. This server delivers both complete and stub implementation required to access Android Automotive Vehicle Properties with use of QtRemoteObjects Backend template.
backend_android_carapi_jniGenerates JNI based back end for the API first generated by the frontend template. This back end delivers both complete and stub implementation required to access Android Automotive Vehicle Properties.

YAML Annotations

In order to be able to access Android Automotive Vehicle Properties, additional configuration has to be provided next to the QFace IDL itself. In the Qt IF Generator Extensions the following annotations (in the accompanying YAML file) are used for Interface Object type:

  • The imports tag:
    config_android_automotive:
        imports: ["android.car.VehicleAreaSeat","android.car.VehicleAreaWindow"]

    Defines a list of Android API imports that contain defines/consts related to properties handled by this interface (e.g. zone id consts). The entries will be converted into the list of imports:

    import android.car.VehicleAreaSeat;
    import android.car.VehicleAreaWindow;
  • The zoneAliases tag:
    config_android_automotive:
        zoneAliases: ["DRIVER_ZONE_ID = VehicleAreaSeat.SEAT_ROW_1_LEFT | VehicleAreaSeat.SEAT_ROW_2_LEFT | VehicleAreaSeat.SEAT_ROW_2_CENTER",
                      "PASSENGER_ZONE_ID = VehicleAreaSeat.SEAT_ROW_1_RIGHT | VehicleAreaSeat.SEAT_ROW_2_RIGHT",
                      "SEAT_ALL = DRIVER_ZONE_ID | PASSENGER_ZONE_ID"]

    Defines zones aliases for individual properties e.g. to be used with zones that group multiple sub-zones. The entries will be converted into the list of Java constants:

    public static final int DRIVER_ZONE_ID = VehicleAreaSeat.SEAT_ROW_1_LEFT | VehicleAreaSeat.SEAT_ROW_2_LEFT | VehicleAreaSeat.SEAT_ROW_2_CENTER;
    public static final int PASSENGER_ZONE_ID = VehicleAreaSeat.SEAT_ROW_1_RIGHT | VehicleAreaSeat.SEAT_ROW_2_RIGHT;
    public static final int SEAT_ALL = DRIVER_ZONE_ID | PASSENGER_ZONE_ID;
  • The zoneMappings tag:
    config_android_automotive:
        zoneMappings: {"" : "SEAT_ALL",
                       "Driver": "DRIVER_ZONE_ID",
                       "Passenger" : "PASSENGER_ZONE_ID"}

    Defines the zone mapping from QtIF's QML string representation to the underlying Java enum zone for Android Automotive. This will initialize a C++ map as follows:

    m_zoneMappings.insert(QStringLiteral(""), QAndroidJniObject::getStaticField<jint>(
                                                                        "io/qt/qtif/android/vehiclefunctions/QIfClimateControlSensors",
                                                                        "SEAT_ALL"));
    m_zoneMappings.insert(QStringLiteral("Driver"), QAndroidJniObject::getStaticField<jint>(
                                                                        "io/qt/qtif/android/vehiclefunctions/QIfClimateControlSensors",
                                                                        "DRIVER_ZONE_ID"));
    m_zoneMappings.insert(QStringLiteral("Passenger"), QAndroidJniObject::getStaticField<jint>(
                                                                        "io/qt/qtif/android/vehiclefunctions/QIfClimateControlSensors",
                                                                        "PASSENGER_ZONE_ID"));

In the Qt IF Generator Extensions the following annotations (in the accompanying YAML file) are used for Property Object type:

  • The vhalId property:
    config_android_automotive:
        vhalId: "HVAC_AC_ON"

    Defines the related android property id, as defined in Android Automotive Vehicle Property Ids.

  • The zone property:
    config_android_automotive:
        zone: ["DRIVER_ZONE_ID", "PASSENGER_ZONE_ID"]

    Defines the zone enum(s) for the related android property. The zone can be either one or more of the values defined under the interface's zoneAliases. If a zone holds multiple values, these values have to be defined as an array. The QML component can then decide which zone to control. For example:

    ClimateControl {
        id: climateControl
        zone: "Driver"
    }

    To get the value of climateControl for a given zone in QML, use the following snippet:

    property int tempValue = climateControl.zoneAt.Driver.targetTemperatureSet
  • The vhalType property:
    config_android_automotive:
        vhalType: "BOOLEAN"

    A vehicle property type as defined in Vehicle Properties.

  • The javaType property:
    config_android_automotive:
        javaType: "Boolean"

    The vehicle property Java type.

Structure for Generated Projects

In the generator output directory, first, a new subfolder is created and named after the module ID. All the generated files are placed in this folder. The tables below describe the files that are generated for the project types delivered by the Qt IF Generator Extensions.

Qt Remote Objects Server

This generator template shall be used together with a project that contains the Qt Services code. The server_android_carapi_qtro template is only available if qmake/CMake finds the Qt Remotes Objects module. The code produced contains:

  • the code for establishing the connection
  • the code that enables the JNI interface to call the Java back end logic
  • default implementation of complete Java back end logic required to access Android Automotive Vehicle Properties
  • Java interface that can be implemented to provide back end logic, if default implementation doesn't meet the requirements
FilenamePurpose
core.h/cppCode for establishing the connection and starting the remoting for the source objects.
.priA standard Qt .pri file that contains all the generated files. Use this .pri file to include the generated files into a qmake project. It also includes the .rep file to the project, and calls the Remote Objects compiler (extra step that is done before the actual compilation).
.cmakeA standard Qt .cmake file that contains all the generated files. Use this .cmake file to include the generated files into a CMake project. Also, it includes the .rep file to the project, and calls the Remote Objects compiler (extra step that is done before the actual compilation).
.repThe input file for the Qt replica compiler to produce the source class code.
backend.h/cppSource QtRemoteObject implementation (that serves as adapter for Java back end implementation).
native_mappings.cppJNI bindings between {{interface|lower}}backend.cpp and Java back end implementation. There is only one instance of this file that provides mapping for all interfaces defined in the module.
android/src/io/qt/{{module|qml_type|replace('.', '/')|lower}}/{{interface}}.javaProvides an interface to notify {{interface|lower}}backend.cpp on property value change.
android/src/io/qt/{{module|qml_type|replace('.', '/')|lower}}/I{{interface}}.javaJava interface that needs to be implemented by the QtService sub-class in order to provide custom back end logic if default implementation doesn't meet the requirements
android/src/io/qt/{{module|qml_type|replace('.', '/')|lower}}/{{interface}}Sensors.javaProvides wrappers around Android Automotive Vehicle Properties that are used by default Java back end implementation.
android/src/io/qt/{{module|qml_type|replace('.', '/')|lower}}/{{interface}}Backend.javaDefault Java back end implementation.

The following diagram presents the possible use case scenarios:

  • using custom implementation for accessing vehicle property
  • using default implementation for accessing vehicle properties

JNI Back End

This generator template shall be used on a plugin project. The backend_android_carapi_jni template provides the production back end that can be used to access Android Automotive Vehicle Properties. The code produced contains:

  • the code for setting back end plugin
  • the code that enables JNI interface to actual Java back end logic
  • default implementation of complete Java back end logic required to access Android Automotive Vehicle Properties
  • Java interface that can be implemented to provide back end logic if default implementation doesn't meet the requirements
FilenamePurpose
plugin.h/cppFiles defining implementation of QtIf back end plugin implementing QIfServiceInterface.
.jsonFile containing identifiers of the exposed feature interfaces needed by the Qt plugin system.
.priA standard Qt .pri file that contains all the generated files. Use this .pri file to include the generated files into a qmake project.
.cmakeA standard Qt .cmake file that contains all the generated files. Use this .cmake file to include the generated files into a CMake project.
backend.h/cppQIfZonedFeatureInterface/QIfFeatureInterface implementation (that serves as adapter for Java back end implementation).
native_mappings.cppJNI bindings between {{interface|lower}}backend.cpp and Java back end implementation. There is only one instance of this file that provides mapping for all interfaces defined in the module.
android/src/io/qt/{{module|qml_type|replace('.', '/')|lower}}/{{interface}}.javaProvides an interface to notify {{interface|lower}}backend.cpp on property value change.
android/src/io/qt/{{module|qml_type|replace('.', '/')|lower}}/I{{interface}}.javaJava interface that needs to be implemented by QtActivity sub-class in order to provide custom back end logic if default implementation doesn't meet the requirements
android/src/io/qt/{{module|qml_type|replace('.', '/')|lower}}/{{interface}}Sensors.javaProvides wrappers around Android Automotive Vehicle Properties that are used by default Java back end implementation.
android/src/io/qt/{{module|qml_type|replace('.', '/')|lower}}/{{interface}}Backend.javaDefault Java back end implementation.

The following diagram presents the possible use case scenarios:

  • using default implementation for accessing vehicle properties
  • using custom implementation for accessing vehicle property

Available under certain Qt licenses.
Find out more.