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
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
This is an attempt to speed up getting out of device idle. It groups
uid firewall rules in these child chains so we can attach/detach a whole
chain instead of individual uid rules.
BUG:21446713
Change-Id: Ie8f392da2deabe7cc86a9ecf4ed080163861d41e
On more careful reflection, the "indents" feature was not ready for
inclusion in the public API. It is still available at a lower level
in StaticLayout.
Also fix a minor typo in the doc for breakStrategy.
Bug: 20641996
Change-Id: I5cd976a536c48615980860396b1564b51b19e14a
To quote sendAccessibilityEvent(), "it is possible that this manager is
in the same process as the service but client using it is called through
Binder from another process."
Bug: 21737301
Change-Id: I8d4699a0ca8187a12235741ce420948061798f27
Changes to drawable dimensions were not propagated to cached dimension
values in ImageView. Now this is done when the drawable is invalidated.
Issue #18798152 ImageView caches wrong value of mDrawableWidth and mDrawableHeight
Change-Id: I8da7d82b0543fa02d8ef3d896595bd0e5ea2a61e
b/19904873
> Reason: to prevent TransactionTooLargeException from occuring when
binder transaction size goes over the limit.
Change-Id: I054cb161d235234f3ccdaadd70314163e690b0db
Previously, RelativeLayout's measure pass could crash if the view's
children were modified without calling requestLayout() prior to the
next measure pass. This avoids the issue by only looking at the most
recent set of sorted views and preserves the previous behavior where
onMeasure() could return incorrect data.
Bug: 21123292
Change-Id: If471d071d1d2e2729cf13854d95b1f517c1fe73a
For both PhoneWindow and VoiceInteractionSession, call
requestApplyInsets when the content view(s) change. This is generally
what the developer expects if the new view tree responds to insets in
any way.
Bug 21620924
Change-Id: I60a88af55bf85217c3587aa37f03fdc3fdce686d
