GitLab

To implement a virtual MIDI device, include a subclass of MidiDeviceService in
your application.  This service is identified by an intent filter and meta-data
in the application's manifest to allow the MIDI manager to register the virtual device
without actually running the application. Instead, the application's MidiDeviceService
subclass is started on demand when MIDI manager clients want to open the device.

Here is an example of how the MidiDeviceService might be described in the application manifest:

    <service android:name="VirtualDeviceService">
        <intent-filter>
            <action android:name="android.media.midi.MidiDeviceService" />
        </intent-filter>
        <meta-data android:name="android.media.midi.MidiDeviceService"
            android:resource="@xml/device_info" />
    </service>

and the device_info.xml meta-data:

<devices>
    <device manufacturer="Sample Manufacturer" model="Sample Model" private="false">
        <input-port name="my input port" />
        <output-port name="my output port" />
    </device>
</devices>

(note that the <input-port> and <output-port> names are not currently used, but support for these
will be added in a subsequent change)

Client's of the virtual device will bind directly to the hosting application's MidiDeviceService subclass.
To support this, MidiManager.openDevice() now returns the MidiDevice asynchronously via a callback.

This change also adds a utility class called MidiDispatcher, which is a MidiReceiver
that dispatches all data it receives to a list of other MidiReceivers.
We now use this internally in MidiInputPort and MidiDeviceServer, but developers
may use it for other purposes as well.

Change-Id: Ic3009f06d56f3d5edbd87de3f0c330b51a1c217d