Update device server's MidiDeviceStatus when a connection is made to one of its output ports.
After connecting an input port to an output port using MidiDevice.connectPorts(),
do not call IMidiDeviceServer.closePort() until MidiDevice.MidiConnection.close() is called.
While I was in there, added missing CloseGuard support to the MidiDevice.MidiConnection class.
This fixes a problem resulting in UsbMidiDevice closing the device's ALSA driver too soon.
Bug: 21850709
Change-Id: I0c120f76b42eec8a143161e46dba73fbec5e4f31
Notifications in which the icon resource ID is changed after
Builder.build() is called (even, and particularly, as the
last step in the current implementation of
setLatestEventInfo()) were not having their icons properly
parceled. In these cases we now attempt to catch this at
parcel time and construct the necessary Icon object.
But wait! Parceling does not require a Context. So we don't
actually know which package to load the resource from.
Therefore we now allow an Icon to be constructed with an
empty ("") package name, which allows us to complete this
parceling task despite the fact that a Notification does not
know its own package name. (In case you attempt to load a
drawable for such an Icon, loadDrawable will spot the ""
package and instead substitute the Context from its
parameters to try to load the resource.)
As it happens, even though the Notification does not know
its own package name, BaseStatusBar does, because it was
provided at NM.notify() time and is therefore included in
the StatusBarNotification structure. So we can actually
patch up the Icon (if it is TYPE_RESOURCE) and be sure to
get the icon loaded out of the correct package.
While we've got the hood open, this change fixes a couple of
related problems:
• Foreground service notifications synthetically
constructed for naughty icon==0 notifications (which we
are still allowing...FOR NOW) were losing the
FLAG_FOREGROUND_SERVICE flag (because we're
re-build()-ing them from scratch rather than rewriting
the provided Notification object). Now we set the flag
and hang onto the new notification for next time
setForeground() is called.
• We now allow media notifications to avoid getting bumped
to the top of the notification list if they're
PRIORITY_MIN. You might want to do that, I guess?
Bug: 21333763
Change-Id: Ia5d1f1acb594c7677bcc75ee3d624da4ffca671f
We used to give 50% of the cpu time of each app to any app holding a wakelock
while the screen is off.
Since we switched to the new kernel module for measuring app's cpu time, this distribution
was lost.
Bug:21876567
Change-Id: I42c294547f63d150d9929271ca0e27fedaaa9d77
The new assist panel (long press on home) was not centered in landscape
mode on phones. This was caused by ignoring the stable insets in the
PhoneWindowManager.
bug: 21708971
Change-Id: I97a968a41c2966b09eba496fbe57c840affdf9ec
These methods are generally useful for writing custom views, and by
exposing them we make it easier for custom view authors to still allow
app developers to use an OnHierarchyChangedListener since it will not
be occupied by a custom view's implementation.
Also move the actual dispatch to package-scoped dispatch methods so
that a developer forgetting to call super won't stop a listener from
functioning.
Bug 21866523
Change-Id: Ie2bb5e241d7c5a02a5033f33ecdaeb40aceb20b5
We were not taking into account configuration changes to update the
available space for the toolbar.
Bug: 21816857
Change-Id: I0f346e8eecb66ab788d1500239d5c1e020b87f97
Should be "with" and not "With". Has the side effect of fixing
a test that assumes that these names are case-sensitive. While the
test must be fixed separately, this is still good for consistency.
bug: 21870226
Change-Id: I884b4abdbb18be064210555aec8e0cd16b0d0bcb
Select only DNS servers that:
- are reachable, according to routes in the LinkProperties, AND
- have a "suitable" source address in the LinkProperites, meaning:
- IPv4 DNS server:
- only if LinkProperties has any IPv4 address
- IPv6 link-local DNS server:
- only if the server has a scopeId set
- assume for now that LinkProperties has a suitable
link-local address
- IPv6 non-link-local DNS server:
- only if LinkProperties has a global, preferred IPv6 address
Bug: 19470192
Bug: 20733156
Change-Id: Ibd95f3f7b33a4fb6c36d1cea4adb63c99068f657
This was introduced by Ifd15736b163ab,
performLayoutAndPlaceSurfacesLocked is called even if
computeNewConfigurationLocked() returns non-null object.
This is simply by mistake and now computeNewConfigurationLocked
never returns null. The only case we need to care is that
mDisplayReady is false, but there is nothing to do with that state.
Thus simply removes if segments from computeNewConfiguration.
Bug: 20823978
Change-Id: I527dfeddffb8d928d578f8d60d64f98557aa3dcb
This is fixed by avoiding calling toolbar.show() in PhoneWindow.
FloatingActionMode coordinates whether or not the toolbar should be
visible. PhoneWindow differs to it.
This CL also adds a new API:
ActionMode#onWindowFocusChanged(boolean)
Bug: 21617792
Change-Id: Ic49ce1000ce9c782d0f9e17e3d024d462c7b758b
It looks like the synchronization of the Bluetooth name and address
from the Bluetooth Adapter has been removed by the following commit
without an explanation:
Bluetooth LE background operation mode (2/2)
As a result, the BluetoothManagerService.mAddress was always null.
Bug: 20545952
Change-Id: I595f370e06e17b2c67ce511f793efdee7674598c
Since 2 clip paths is taking the intersection as the final clip, we should
separate this test case into 2 groups.
Prior to M release, the 2nd clip path is overriding the first one.
The behavior changed in this CL:
e9c01a40a2f0f0da195dfbb2909aaee5c005d1c6
b/16376848
b/19946683
Change-Id: Ib21c95e70f1317321725acbbe0ccf91713f748c3
