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
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
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
