commit efa6f355b06675aa4d0879fd279e22c16d5c046c
Author: Mikhail Naganov <mnaganov@google.com>
Date: Wed Aug 10 12:25:13 2016 -0700
MIDI: Use server-side socket in blocking mode for virtual devices
Since virtual MIDI servers may misbehave, blocking mode will throttle
them if clients are not coping with their sending speed.
Bug: 29413812
Change-Id: I9c4a2a7a7ea3ea060c93fedc7d0f033427c557c9
commit 755dfb5f83749d3963c63d98d692307f8271c804
Author: Mikhail Naganov <mnaganov@google.com>
Date: Fri Jul 8 13:26:19 2016 -0700
Protect MIDI framework against client blocks in MidiReceiver.onSend
Make the server-side socket non-blocking when creating MidiOutputPort
for clients. Thus if a client ceases to read from its side of the
socket pair, the server will just fail to write instead of blocking.
One drawback is that the MidiOutputPort on the client can't indicate
that it has become dysfunctional, but it's not possible without
changing the API.
Bug: 29413812
Change-Id: I9dfcbdd214a815cea8fd1365324fd78ca459268a
commit c740b13953761f58233ac651a0b5227733b1bdcc
Author: Mikhail Naganov <mnaganov@google.com>
Date: Fri Jun 17 04:11:25 2016 -0700
UsbMidiDevice: Clean up terminology and fix comments
When working with physical MIDI devices, an *input* stream is used
for reading from *output* port of the device, and vice versa. Thus,
using "input" and "output" without specifying whether it's a stream
or a port is confusing.
Clarify names of counter variables, and fix a couple of comments
that were incorrect due to this confusion. No functional changes.
Change-Id: If561eaca4bade94e9296d2c703c9fcebc91296e2
commit 4269c6417287737624f6165a8bbeb5aa427de9a0
Author: Glenn Kasten <gkasten@google.com>
Date: Thu May 5 18:49:16 2016 -0700
Update MIDI package summary
Bug: 28625060
Change-Id: If552ca8e1a0666d402b5f536699bf3fb09c1e324
commit 862d40b73168bde7d0be5280d997985c18061014
Author: Phil Burk <philburk@google.com>
Date: Tue Apr 19 15:56:24 2016 -0700
MidiDevice: do not open ports on closed device
Fix involves client side mIsDeviceClosed flag.
Bug: 24949216
Change-Id: I666284a787fbb9a710d2372fb424e8e54f6a2825
Signed-off-by: Phil Burk <philburk@google.com>
commit 6f1de358b9f2616e03f4655f01454770915ddd66
Author: Phil Burk <philburk@google.com>
Date: Mon Apr 18 16:05:28 2016 -0700
MidiService: fix resource leak
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>
commit f7386bd535bb8a1d7f8df8f44a1748ab770c991a
Author: Phil Burk <philburk@google.com>
Date: Tue Apr 5 14:19:53 2016 -0700
MidiDevice: fix connectPorts for same Process
If connectPorts() was called for a device in the same process then
the connection would die when the ParcelFileDescriptor was closed.
Bug: 26406775
Change-Id: Id0538452593b4761ac2a93d366ade76d2e35ce73
Signed-off-by: Phil Burk <philburk@google.com>
Change-Id: I4dfc2a2cbaf04bf1a790ae2cb39bf74fb5bb16ac
The proxy MidiReceiver in the USB device was not forwarding the flush
command to the event scheduler.
Bug: 25511696
Change-Id: I6a4759b71bc8f9ae3e20aed1238f62a2ed405e24
Signed-off-by: Phil Burk <philburk@google.com>
The devices with USB PD support can have the data role and the power role of
their USB-C port reversed. Ensure the title of the notification and the content
of the USB selection dialog is correct in this case.
Testing done on Ryu with the following accessories:
- legacy A-C cable
- USB-C charger (5X)
- USB-PD charger (Zinger)
- Pixel 2 (in both roles)
- Type-C Macbook (in both roles)
- Nexus 5X (in both roles)
- Apple AV HDMI accessory
- LG USB-C screen/dock
- Honeybuns dock
Bug: 28310685
Bug: 24137353
Change-Id: Id7f358c40d8714fae68ca98a7eb067f62f18b0af
(cherry picked from commit 0be6800b0feba50fa2c1be7852ee2eb02c38afc0)
The proxy MidiReceiver in the USB device was not forwarding the flush
command to the event scheduler.
Bug: 25511696
Change-Id: I6a4759b71bc8f9ae3e20aed1238f62a2ed405e24
Signed-off-by: Phil Burk <philburk@google.com>
This will let us see in bug reports if the USB device in question
is ACTUALLY recognized and added/removed from the audio system.
Bug: 27812441
Change-Id: Id3eb4d4f3f0b1e66a24999706ba589c0962eba58
If you use USB type C, you can charge Android from USB power or you can
supply power from Android to the other connected device.
Previously Android showed the notification saying "USB for charging".
The CL updates the text so that it shows the current power direction
explicitly.
Change-Id: Ic15ba70eaf8ade028283d8f490ac36e8d5e4db21
FIXED: 27706939
Previously UsbModeChooser activity is automatically closed when Android
is connected to another Android and works as host. This is because
ACTION_USB_STATE intent does not include the information whether Android
is connected as host and UsbModeChooser regards Android is not connected
USB devices.
The CL introduce the HOST_CONNECTED extra to ACTION_USB_STATE so that
UsbModeChooser can refer it.
BUG=27535640
Change-Id: Ie29583b78319078430f6d9a8390787780410ac8c
Previously MtpDocumentsProvider opens a device just after device is
connected to Android. But MtpDocumentsProvider should open MTP device on
demand so that other applications can open device if user starts to use
the application before using MtpDocumentsProvider.
BUG=26625708
Change-Id: I6083b8c7cef49ee6e9fb0d15ca4adc129734f3eb
The CL adds launch notification that are shown after MTP/PTP device is
connected to Android device. By tapping the notification, Users can
launch an applicaiton that can handle USB_DEVICE_ATTACHED intent of MTP
device.
BUG=26611224
Change-Id: I6fd179ccd436531dfff6ff9a50dc2b754c20f190
Previously it skips the device permission check by referring package
name. The CL removes the special case and use general MANAGE_USB
system-only permission to skip USB device permission dialog.
BUG=26048722
Change-Id: I3702393a50696209499d1e5f6549dab9fb2cefe4
The UID is used by MtpDocumentsProvider that is a system component and
needs to access MTP devices.
BUG=25983848
Change-Id: Iaa20a849cb9e7a86bde6c5bf8abbb15e65ced6c3
in the same was as we allow then to turn of debuging notificaitons
this is useful for screenshots and demos
Change-Id: I6e95addec2917abdd619086ed68910097fb5b8aa
In some cases when the USB microphone is disconnected,
audio stack does not switch to the built-in microphone.
It gets stuck in a state where it still recognizes the
USB mic is still connected. Current device removal
implementation only considers USB output devices such
as headset. The same process should be used for input
USB devices (microphone).
Bug: 24932354
Change-Id: Ic2089ef5a9a318cb47336ade405f79eccd7129f8
Signed-off-by: Alejandro Ochoa <alejandro.ochoa@intel.com>
Also added some additional logging functions as we are not done
looking at connect/disconnect issues.
Leaving in tact the multi-device connect/disconnect logic (neeeds to
be revisited)
Bug: 24906368
Change-Id: Iff91c51a9c7013dde56182059f3747e1d6cd727b
When switching users, USB stack shouldn't be restarted if mUsbDataUnlocked =
false, e.g. device is in charge only mode.
Bug: 24611765
Change-Id: I3b12f8c8926235546fe916a200aa57ed618193de
On some devices, setting system properties takes too long and we end up
with races where adbd gets killed and never comes back. With this
change we avoid a small optimization that checks the previous value of
the config, instead opting to set it every time.
Bug: 23631400
Change-Id: I7567cc2efb3d5d15c45334bd66b28877a2af0ac3
This change modifies UsbDeviceManager such that the ongoing
system notification for USB charging state is controlled by a
config flag.
Bug: 23409719
Change-Id: I2ef24fe74923170a6e8dd02375b973b4025281e4
Modify UsbDeviceManager.updateUsbStateBroadcast to broadcast
ACTION_USB_STATE intent only when any of the USB states have
changed.
By doing this, the processes that receive ACTION_USB_STATE intent
(e.g. android.process.media) are not launched during boot
unnecessarily.
This change reduces boot time by about 200 ms.
BUG: 22163689
Change-Id: I1853a23b0263d9ff608b02d6bc98fe58f584cc19
As discussed in b/21429947 (commit
674019065bceb4150190bfb1aa63cda9de0a8560), MTP must always be
enabled, even if access to the underlying MTP data is disabled.
Otherwise, Android will not enumerate on the USB bus, and won't
receive notifications from the kernel about USB state changes. This
effectively prevents using MTP functionality on user builds, or
on userdebug/eng builds with adb turned off.
Always ensure that MTP is the default driver mode.
Move the DISALLOW_USB_FILE_TRANSFER filtering of mUsbDataUnlocked from
setting time to the time we post the sticky broadcast.
Remove isUsbDataUnlocked(). It essentially duplicates data in the sticky
broadcast.
Bug: 22447614
Bug: 21429947
Change-Id: I9d0d94cadbf6db6281ebd77bfb7162f9d06520c2
This will improve the accuracy of recorded MIDI performances.
Bug: 22801515
Change-Id: Ib78bc929224f2f27938c83a815eaa62f6b5f9560
Signed-off-by: Phil Burk <philburk@google.com>
This causes various problems with our testing infrastructure.
This reverts commit b210026e3d5c955628ca8b8b9191ade08891e9ef.
Bug: 22447614
Bug: 21429947
Change-Id: I57623e3d993e65b6ad89e7a7d28e9575cf638994
As discussed in b/21429947 (commit
674019065bceb4150190bfb1aa63cda9de0a8560), MTP must always be
enabled, even if access to the underlying MTP data is disabled.
Otherwise, Android will not enumerate on the USB bus, and won't
receive notifications from the kernel about USB state changes. This
effectively prevents using MTP functionality on user builds, or
on userdebug/eng builds with adb turned off.
Always ensure that MTP is the default driver mode.
Get rid of one use of the persistent property. The persistent property
was already pulled from a number of devices, and as explained in
commit fcf10f7c12cb3107bdfedce6f76a8c866d154f3c, the intent was that
the persistent property would only hold the persistent adb state.
Bug: 22447614
Bug: 21429947
Change-Id: I8b3690a1bafb7cea0d5a69d73c1065c7fc64c653
