Look for non-BLE transport devices
Look for Service UUIDs indicative of non-MIDI devices
Bug: 222388547
Bug: 216498842
Bug: 221079216
Test: Connect BT headset, examine log for no MIDI connect
Conect BLE-MIDI devices, examine log for MIDI connect
Listen in headphones, Play a MIDI synth with BLE-MIDI controller.
Signature:
MidiManager: openBluetoothDevice() XX:XX:XX:XX:XX:XX
MidiService: openBluetoothDevice()
Change-Id: Ibaadc26edb1ea9fdfab7891eda1f260fefb9757e
Devices got created twice because I forgot to remove a
debugging statement
Bug: 220168245
Test: MidiKeyboard and MidiScope
Change-Id: I2bd7b28bec3025e62dce39fcd500350a9ca6de8d
Merged-In: I2bd7b28bec3025e62dce39fcd500350a9ca6de8d
As a follow-up to ag/16835029, adding GuardedBy annotation
to new USB specific classes. This should help with identifying
potential races
Bug: 219763493
Test: Tested on MIDI 2.0 keyboard
Change-Id: I3d77db0d741cca8f79a759d2dcc99e8254b0298c
ALSA has multiple bugs related to MIDI 1.0. This CL removes
Android's dependency on ALSA for MIDI 1.0 USB Host mode. MIDI to
USB MIDI conversion is done in UsbMidiPacketConverter.java
ALSA is still used for peripheral mode.
Bug: 217392573
Test: Ran local unit tests with UsbMidiPacketConverter
Test: MidiScope/MidiKeyboard with multiple MIDI keyboards
Change-Id: I0b86f9bd26e4c9a50576f704deb6b53fc9a5c130
Also limit number of listeners and connections.
Bug: 210864154
Test: see bug for repro steps
Test: Check status with: adb shell dumpsys midi
Test: Test: atest CtsMidiTestCases
Test: https://source.android.com/devices/audio/midi_test.html
Change-Id: If5ab4518873f52136f52d8ac654b78a72717838a
If a MIDI device is marked private then make sure
the status can only be obtained by the owner.
Bug: 203549963
Test: see bug for repro steps
Test: atest CtsMidiTestCases
Test: https://source.android.com/devices/audio/midi_test.html
Change-Id: Ibe92f1ca58c7971855453f1794564e95bfb9380d
Bug: 25689266
Test: Connect to various BT MIDI peripherals and test function
with software synthesizer (DRC)
Change-Id: I1df2f3bfbc6302eb9d139546e825f2eb9b4abdd5
Adding MIDI 2.0 host mode support to Android. MIDI 2.0 peripherals
create an alternative setting for Universal Midi Packets (UMP).
UMP packets can be passed directly through as the host has full
control. Instead of going through the ALSA, UMP packets can be
sent directly through a UsbDeviceConnection.
This CL also adds public apis to expose whether the pipe supports
UMP. This for MidiDeviceInfo in Java and AMidi in c++.
Bug: 201003646
Bug: 214447324
Test: Verified that the MIDI 1.0 path still works as before.
Test: Tested that MIDI 2.0 packets are passed through the pipe
with MIDIScope and MIDIKeyboard
Test: atest MidiSoloTest
Test: atest CtsMidiTestCases
Test: NativeMidiEchoTest
Change-Id: Idff8a3b9bdd05857239260fc3e6af7253f8f992f
This can help prevent MIDI input ports from getting
stuck in the open position.
Bug: 210724686
Test: see bug for repro steps
Test: atest CtsMidiTestCases
Test: https://source.android.com/devices/audio/midi_test.html
Test: Check status with: adb shell dumpsys midi
Change-Id: I9fe45eeb2d51356d114ae5a1a175e3d1f6977328
Try to prevent a NullPointerException caused
by scanning the array while devices were being removed
by another thread.
Bug: 193278370
Test: atest CtsMidiTestCases
Change-Id: I8560cf6f39654037d5ccdc0f6922fa8bdb719c2f
We've been writing many new framework-specific Error Prone checkers
to help detect obscure platform bugs, and this change starts enabling
those checkers for more packages across the platform.
Bug: 155703208
Test: manual
Exempt-From-Owner-Approval: trivial blueprint changes
Change-Id: I1db3412b0be40f6f78c68331ae01756887192071
The recently added AndroidFrameworkBinderIdentity Error Prone checker
examines code to ensure that any cleared identities are restored to
avoid obscure security vulnerabilities.
This change is a purely mechanical refactoring that adds the "final"
keyword to the cleared identity to ensure that it's not accidentally
modified before eventually being cleared. Here's the exact command
used to generate this CL:
$ find . -name "*.java" -exec sed -Ei \
's/ (long \w+ = .+?clearCallingIdentity)/ final \1/' \
{} \;
Bug: 155703208
Test: make
Exempt-From-Owner-Approval: trivial refactoring
Change-Id: I832c9d70c3dfcd8d669cf71939d97837becc973a
This is just a plain refactoring: the removed methods in the changed
classes were called by default by the new methods in the superclass
(SystemService).
Test: m
Test: atest NotificationManagerServiceTest BackupManagerServiceRoboTest
Fixes: 161943081
Exempt-From-Owner-Approval: refactoring without side-effects
Change-Id: Ifd8df592eb4494cc0922b7e0b2ff20187b8a8b3e
Over the years we've had several obscure bugs related to how SDK level
comparisons are performed, specifically during the window of time
where we've started distributing the "frankenbuild" to developers.
Consider the case where a framework developer shipping release "R"
wants to only grant a specific behavior to modern apps; they could
write this in two different ways:
1. if (targetSdkVersion > Build.VERSION_CODES.Q) {
2. if (targetSdkVersion >= Build.VERSION_CODES.R) {
The safer of these two options is (2), which will ensure that
developers only get the behavior when *both* the app and the
platform concur on the specific SDK level having shipped.
Consider the breakage that would happen with option (1) if we
started shipping APKs that are based on the final R SDK, but are
then installed on earlier preview releases which still consider R
to be CUR_DEVELOPMENT; they'd risk crashing due to behaviors that
were never part of the official R SDK.
Bug: 64412239
Test: ./build/soong/soong_ui.bash --make-mode services RUN_ERROR_PRONE=true
Exempt-From-Owner-Approval: trivial blueprint changes
Change-Id: Ia20181f8602451ac9a719ea488d148e160708592
See build/soong/README.md for more information.
Test: m checkbuild
Exempt-From-Owner-Approval: trivial conversion
Change-Id: I417409281c928ea667d937090d2a0d9d72a449a2
This method is called from MidiService in system server, must be
oneway.
Remove the call to IMidiDeviceServer.getDeviceInfo from
MidiService. It seems to be redundant. The reason is that
MidiDeviceInfo is only created by MidiService (to maintain
unique IDs), and after creation, it is pushed both to a remote
MidiDeviceServer, and to a local MidiService.Device class
simultaneously inside addDeviceLocked method. Thus, if
MidiService.Device.mDeviceInfo is still null, there is no chance
that remote MidiDeviceServer can hold a non-null
MidiDeviceInfo. So the call to IMidiDeviceServer.getDeviceInfo
will also return null, and thus can be avoided.
Note that only for BT MIDI devices can MidiService.Device receive
MidiDeviceInfo later in the lifecycle. All other types of devices
receive MidiDeviceInfo upon construction.
Bug: 37535382
Test: Used BT MIDI keyboard with MidiSynthDemo app
Change-Id: I5378207922187866f3c43e01f1ed30f042720167
This change introduces new methods on DumpUtils that can check if the
caller has DUMP and/or PACKAGE_USAGE_STATS access. It then moves all
existing dump() methods to use these checks so that we emit
consistent error messages.
Test: cts-tradefed run commandAndExit cts-dev -m CtsSecurityTestCases -t android.security.cts.ServicePermissionsTest
Bug: 32806790
Change-Id: Iaff6b9506818ee082b1e169c89ebe1001b3bfeca
The proxy object was being used to match when adding or removing objects.
But they are different each time. So now we use an asBinder() object.
Bug: 28153736
Change-Id: I1bccebf1e9464668db757ff08b41902d0cf0e3a7
Signed-off-by: Phil Burk <philburk@google.com>
This will give an app an opportunity to learn whether an input port is busy
before the user tries to connect and then fails.
Bug: 22825043
Change-Id: Ifede60f166dfe66ea15453044fce06f4a8452b18
Signed-off-by: Phil Burk <philburk@google.com>
Add a remote call addBluetoothDevice() using AIDL.
This was needed because onBind() is only called once.
Bug: 23219556
Bug: 23760886
Change-Id: Id7554ca55d596352d11dbd6ae3e403138a29c864
Signed-off-by: Phil Burk <philburk@google.com>
This made it unsafe to open ports on a device from the MidiManager onDeviceOpened callback
Bug: 21760692
Change-Id: I536acdf574a3ccecdb66a8fde87089538e8bb1ef
Previously when a MidiManager client opened a virtual or Bluetooth device,
the client bound directly to the virtual device's MidiDeviceService
or BluetoothMidiDevice's IMidiDeviceServer for the given BluetoothDevice.
Only USB devices were opened in MidiService.
Now opening any type of MIDI device is done via IMidiManager.openDevice() or
IMidiManager.openBluetoothDevice(). MidiService tracks all connnections between
clients and devices.
Services that implement virtual devices must now require android.permission.BIND_MIDI_DEVICE_SERVICE
so only MidiService can bind to these services.
Bug: 21044677
Change-Id: I7172f7b1e0cbfe4a2a87dff376c32dc9b41aa563
Rename MidiDeviceInfo.getPortList() to getPorts()
Rename MidiManager.getDeviceList() to getDevices()
Rename MidiReceiver.onReceive() to onSend()
Replace MidiManager.DeviceOpenCallback and BluetoothOpenCallback
with new interface MidiManager.OnDeviceOpenedListener
Add MidiSender.onConnect() and onDisconnect()
Add MidiReceiver.onFlush()
Ensure that MidiReceiver max message size is immutable
Bug: 21044677
Change-Id: I7711734a45e831e9744849a6f569e906feff9f80
- Include each device's port status from MidiDeviceStatus
- MidiDeviceInfo.toString() now outputs all the names and values in the properties Bundle
Change-Id: Ic9329153e4ae4d5619e274d27a420943473377e5
The Bluetooth MIDI devices are handled in the BluetoothMidiService APK.
Apps wishing to connect to Bluetooth MIDI devices call MidiManager.openBluetoothDevice()
which binds to BluetoothMidiService in a similar way as virtual devices are implemented.
Change-Id: Ie3fbca757928fd7873a009f9bf9e0ce0be487da6
