A message can now be shown on the keyguard bouncer
explaining why the bouncer is being shown.
Bug: 21618072
Change-Id: I25aea9cc242abbf6a133fb42cc4407f5c2f3f688
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
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
- When tapping home, we can't depend on the stack state to determine
whether or not hide recents since there can be translucent windows
above it. In this case, we just dismiss recents directly since the
receiver will only be registered while recents is visible.
Bug: 20110140
Change-Id: I6b796cc4cbd790aac9a0857549e34117adb808d8
- Fixing issue with accessibility focus being incorrect when animating from home
- Fixing issue with accessibility focus being reset too aggressively when the
list is scrolled
- Ensuring that recents handles forward/backwards scrolling
Bug: 19997561
Change-Id: I042666775862f4a20e8f22960e1f34e45fc5664e
Fixes a bug where the tile that was just clicked on
to go to the detail view would become visible and cause
confusion to accessibility services.
Bug: 20209718
Change-Id: I1678a4fc35e8d739b7c657e868b02a25eddcba1d
We only need to get the state if the tuning has actually changed.
Currently we hit this every time we open QS which breaks the alpha
animation on the mobile icon.
Bug: 21791609
Change-Id: I3d77a2d0f81d2d7bed600ccd7a2d2c2b4a262db7
