Supported third-party applications and protocols

The USB launcher service supports third-party applications and protocols used by a variety of devices. To work with these devices, the service can probe them for protocol support and request that they switch to another personality.

Note:

The probing of protocol support can be automated through the USB launcher service or manually done by a service or application after it reads a device's information through PPS and decides to use the device for a certain purpose. Publishing device information and probing for protocol support prolongs the time from when a smartphone is connected to when its UI appears on the target's display, but even with the expected latency increase, vendor certification can still be achieved with the target system.

The design principle here is that usblauncher_otg or another process can decide if it wants to use a device's projection technology.

Android Open Accessory

Some Android applications, such as Android Auto, require the device to run the Android Open Accessory (AOA) protocol. To get the device to do this, you must confirm that it supports this protocol and if necessary, request that it enable the AOA modes you want to use.

To learn whether a device supports AOA, you must define the AOA table in the configuration, which makes the USB launcher service probe the device for its AOA support when the device is attached. If AOA support is confirmed, the aoa attribute is written to the PPS device information object and contains the protocol version (e.g., aoa::2). The service works with AOA versions 1 and 2.

The AOA table can contain only the blacklist rule, which specifies the devices to ignore during probing. You still must define the table (even if it's empty) if you want to probe any devices.

AOA = {
    blacklist = {
        { vid = 0x05ac; }; -- Any Apple device
        { vid = 0x0781; did = 0x5530 }; -- SanDisk Cruzer
        { vid = 0x04e8; did = 0x5091 }; -- Samsung YP-S3 media player
    };
}

Some devices misbehave when probed for AOA support. In this example, we specify the vendor ID for Apple devices because there's no need to probe them for AOA support. In the remaining list entries, we use both the vendor ID (vid) and device ID (did) to list other devices that we don't want to probe.

To request that a device enable AOA, a process external to usblauncher_otg must monitor updates to the PPS device information object. When it reads the aoa attribute, the process must write the start_aoa command to the device control object, requesting the AOA modes it wants to enable. The process can check whether the command succeeded by reading the last_cmd attribute from that same object. If it finds that the command failed, the process can examine the execution details stored in that attribute, take corrective action, and reissue the command.

When the device receives the AOA request, it becomes temporarily invisible on the USB port but then, after enabling the requested AOA modes, reappears as a new device with a different vendor ID and product ID. Any drivers that were already running (e.g., MTP) are terminated and not restarted. There is no default driver to run for communicating with devices over AOA because applications that use this protocol are custom applications that need custom drivers. In rules.lua, we provide a sample matching rule as a placeholder:

product(0x18d1, 0x2d00, 0x2d05) { -- Google AOA
    interface(0) {
        custom = function(obj)
            if obj.EXTRA and obj.EXTRA:find('aoa::') then
                return "echo AOA busno=$(busno),devno=$(devno)";
            else
                return "echo Error - AOA probe failed\z
                        busno=$(busno),devno=$(devno)";
            end
        end;
        driver"$(custom)";
    };
};

This matching rule applies to devices running AOA. The rule contains a function that reads the aoa attribute and echoes the device information. In your configuration, you need to replace this with a suitable driver-launching command. If the attribute isn't found (which means the second probe for AOA support failed), the function prints an error message. This second probing is done when the device reappears on the USB bus with its AOA personality. Although unlikely, it's possible that this additional probe will fail, so it's good practice to handle the error.