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
If you try to disable USB debugging before the socket
to listen is opened in the thread, it will end up
with an NPE.
Do some locking around socket creation and closing
to avoid this.
Bug: 18708503
Change-Id: Iac43e4806fff1e411772b1ba1a070d8a7c776fcb
- Change the package name from android.midi to android.media.midi
- Add option for specifying a Handler for DeviceCallback notifications
Change-Id: Ia9e9817a651c06299f4e02ee1da3c9666ff64cb9
Rename MidiReceiver.onPost() to post()
Change MidiManager.DeviceCallback from an interface to a class
Change-Id: I939ba7a7d82e721b90a3d80252a88e7a650c9396
Add "device name" member to AudioPort.
Moved unique device ID from DevicePort to AudioPort.
Straighten out confusion between "name" and "address"
Created string constants for Intent "extra" data keys.
Combine card/address data into "address" at sender.Add additional info to AudioPort for enum/selection API.
Parse out USB Device name in UsbCardsParser.
Change-Id: Ifd76b0298312090a8f39e638339f993b86d47080
Wait until after encrypted volume has been mounted.
Also eliminate warning by starting UsbDebuggingActivity as owner.
Fixes bug 19217173.
Change-Id: I6da530259bb02eb1892509ec5085a471f9893714
This allows the android device to appear as a USB MIDI device to
a USB host (like a Mac or a PC) using the f_midi USB gadget driver.
Change-Id: I14f1ba73bcce2c894e77efb8810beac4ffe246d8
Instead of attempting to package exactly one MIDI message in each call to
MidiReceiver.onPost(), we now pass messages as a raw stream of bytes.
This means we may now receive multiple MIDI messages in MidiReceiver.onPost().
We make this change to avoid the complexity of taking the single message approach
with SysEx and realtime messages. This shifts some of the burden of parsing
MIDI messages to the client application. But the parsing is best handled in the
application anyway, rather than having the framework impose its own policy
on how the messages are parsed.
Change-Id: Idb6c200037f827cc618bc7d9455a7aa864b494a7
- fix off by one error that caused failure handling one byte messages
- poll thread now terminates properly in UsbMidiDevice
- fix cleanup logic in MidiDeviceServer
Change-Id: I0c13a98b6542cfb271b51678e81d1822c8da2985
MIDI ports are now implemented as file descriptors directly between the sender
and receiver, so the MidiService is no longer in the message path.
To facilitate the above, each port has its own file descriptor, rather than multiplexing
all ports on a device through a single socket.
Added a new class MidiDeviceServer, which is used by implementors of MIDI devices.
This replaces the MidiVirtualDevice class (which only was included in changes that were reviewed but never submitted).
The USB MIDI implementation has moved from the MIDI service to the USB service.
The USB MIDI implementation uses MidiDeviceServer as its interface, so we now have a common
interface for all MIDI device implementations.
Change-Id: I8effd1583f344beb6c940c3a24dbf20b477a6436
Attach/Detach logic
Decoupling card# and list index
Modern loop constructs
Consistent logging flags
Add class/type flags to device "address" string.
Factored UsbAudioDevice out of UsbAudioManager.
Bug: 18399845
Bug: 18717784
Change-Id: I6f185e1c24091d4c0d21eb7e922a1496748d32c3
Still to do:
Add MidiInputPort and MidiOutputPort classes
Schedule sending MIDI events in the future
Security/permissions
Reconsider interface for virtual devices
Look into performance optimizations
Change-Id: I9b7d63b196996a04be0a830efa913043da1328a8
The user restriction DISALLOW_USB_FILE_TRANSFER has to be respected
when switching USB function set.
Bug: 18532487
Change-Id: I16fda6358027a659e3bfa0c5f3bf6b3918d0bced
If the restriction UserManager.DISALLOW_DEBUGGING_FEATURES is enforced,
then any attempt to set ADB_ENABLED will result in a SecurityException.
This can result in the device not being able to boot.
Bug: 18433477
Change-Id: I21e4b406ad0fa89b7d4b678eac1baf212a3c7acd
(cherry picked from commit ba45b96a378623e3392da65e81e67dabdf4f0678)
An invalid adb public key can cause a system server crash.
AndroidRuntime: *** FATAL EXCEPTION IN SYSTEM PROCESS: android.fg
AndroidRuntime: java.lang.IllegalArgumentException: bad base-64
AndroidRuntime: at android.util.Base64.decode(Base64.java:161)
AndroidRuntime: at android.util.Base64.decode(Base64.java:136)
AndroidRuntime: at com.android.server.usb.UsbDebuggingManager.getFingerprints(UsbDebuggingManager.java:235)
AndroidRuntime: at com.android.server.usb.UsbDebuggingManager.access$500(UsbDebuggingManager.java:49)
AndroidRuntime: at com.android.server.usb.UsbDebuggingManager$UsbDebuggingHandler.handleMessage(UsbDebuggingManager.java:210)
AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:102)
AndroidRuntime: at android.os.Looper.loop(Looper.java:135)
AndroidRuntime: at android.os.HandlerThread.run(HandlerThread.java:61)
AndroidRuntime: at com.android.server.ServiceThread.run(ServiceThread.java:46)
Process : Sending signal. PID: 824 SIG: 9
Bug: 17389885
Change-Id: Id20d7c0ee35229b14c800fd9e07716239179989c
Previously, disconnecting any USB device would terminate USB audio playback.
Also moved USB audio support to a separate class and did some prep work for
multiple USB audio device support.
Bug: 18203024
Change-Id: I49822c2c47428e658c853b2ec83c7313e626a1cb
For ACTION_HEADSET_PLUG (already in SDK):
- duplicated definition in AudioManager and moved
javadoc there. Javadoc in Intent points to AudioManager.
- the String value is not changed
For ACTION_HDMI_AUDIO_PLUG (being added in SDK):
- moved defintion from Intent to AudioManager
- updated String value to reflect package name "android.media"
instead of using "android.intent"
- added definition of the extras, but removed "name".
For ACTION_ANALOG_AUDIO_DOCK_PLUG,
ACTION_DIGITAL_AUDIO_DOCK_PLUG,
ACTION_USB_AUDIO_ACCESSORY_PLUG,
ACTION_USB_AUDIO_DEVICE_PLUG, all hidden:
- moved definition from Intent to AudioManager,
- changed the value from "android.intent.*" to "android.media.*"
Updated AudioService, UsbDeviceManager and UsbHostManager
to refer to the actions in AudioManager, not Intent.
Bug 17289385
Change-Id: I61dd73140022d2bb9a676a57f595092c8fa89dcc
* commit 'ee5d512d624c15fa0c7e179ace24c7055a9f539d':
Allowed custom secure-adb confirmation via Activity or Service. It used to only be available via an Activity.
* commit '4980996bcc4e8065cf5dff1cf989d73face38281':
Allowed custom secure-adb confirmation via Activity or Service. It used to only be available via an Activity.
