When the unbind request came in before the service was actually
bound, we dropped the unbind request because mPrewarmBound was still
false. Fix that by tracking whether a bind is pending and if a unbind
event comes in during that time, set another flag to unbind it
directly again when the service is actually bound. In addition, don't
allow binding again if any of the previous events are still pending.
Bug: 23143748
Change-Id: I2b8ace86e35479a9848668a3462a2ce687835413
In PowerNotificationWarnings, where it dispatches notifications
with UserHandle.ALL:
mNoMan.notifyAsUser(TAG_NOTIFICATION, R.id.notification_power, n, UserHandle.ALL);
The fix is to have RingtonePlayer check the incoming userId argument to playAsync(),
and change USER_ALL to USER_OWNER.
BUG=22516181
BUG=22992637
Change-Id: Ia3f8aaa2bee7fb15c24542e2331b2bc5a877e715
When in ambient display mode, we didn't get a callback to
onStartedWakingUp, thus the time was never refreshed. Since
broadcasts are disabled in this low-power state, we need to refresh
the clock manually before turning on the screen, because we can't
rely on the broadcasts to be delivered.
Bug: 23171638
Change-Id: I249f4195a14995f7c1467e73ac2aa400b871f80e
Since bluetooth connection state has a mind of its own... If we
think we are connected, but we don't actually know about any devices
that are currently connected, we probably aren't. So set the state
that way, and let everyone know.
Bug: 22977827
Change-Id: I9266f5394b179a3917b3818839f7c6b2dc238376
- It appears that there is contention between startActivityAsUser() and
removeTask() (called on two separate threads) which can cause jank when
a user removes all the tasks from their recents list. This CL ensures
that startActivityAsUser() is always run first so it is not blocked
by the other call (which should be able to run in the background
uninterrupted).
Bug: 22760556
Change-Id: I7564a2f0e43414686419d3657379bbd0ca6b4152
This shouldn't happen, since there are many places where
invalid icons should already have been either fixed (in the
case where there's an .icon but no .mSmallIcon) or rejected
(if they're both null or invalid). But if a notification
makes it all the way to SystemUI without a valid icon, let's
crash the sender.
Bug: 23011305
Change-Id: Ifaebec57d59baa1defb4520178b5815d47ed5712
Initialize current network name to correct value from the
SubscriptionInfo until we get a broadcast about its current state.
Bug: 22212693
Change-Id: I17fa4378cc7a540c81268f8c4d5aa6a505f3ee40
- We did not expect RecentsActivity to be launched without going through
the normal SystemUI controls, but when the home activity is in the foreground
and killed (via a normal apk update), the RecentsActivity stores the old
launch configuration and believes that it was launched from home and awaits
the animation-complete callback to animate the tasks in.
- This CL adds a workaround where the configuration is reset whenever
RecentsActivity is stopped, which allows the tasks to be shown immediately
if the User is kicked back into Recents due to an update.
Bug: 22542869
Change-Id: I2b4168ccecfbf868fa6d544fe89109dfa74f51df
Cancellation messages can come from a variety of sources
and are not user-actionable. As a result, we just shouldn't
show them.
Fixes bug 22863862
Change-Id: I2154c774fd5ac7477e01d1cbf3bdde2d1929363b
- Also fixes issue with tapping outside bounds not working to dismiss recents
Bug: 21774486
Bug: 22241587
Change-Id: Ib50f6fece8fb150929a1f8cdb01b8e8fe7b665cd
Some references to notifications were still
kept around while timing out, leading to small
leaks and sometimes crashes.
Bug: 22819475
Change-Id: I1429b5669366521c6374efbcae6c26d6e407d8cc
When QS was open while the we started with expansion, we
immediately notified about expansion finsihed again, which led to all
kinds of weird states. The change that introduced these bugs was to
fix another bug in which onExpandingFinished was not call. Make sure
to call in exactly that case and no other case to not risk
regressions.
Bug: 22806817
Bug: 22807359
Bug: 22807372
Change-Id: Id7daf37ef4a772f724971bf79c61084ff4279f31
The problem is that, for 12-hour locales, we cut the "a"
part of the time format out to show it in a separate
TextView so it can be animated independently of the actual
time. Unfortunately, while TTS is smart enough to pronounce
"1:15 AM" as /wʌn fɪftin eɪ ɛm/, "AM" on its own looks like
the English word "am" and is pronounced /æm/.
To fix this, a TextClock must be able to accept separate
formats for its content description than its presentation.
With this capability we can place the complete 12-hour time
format (including am/pm) in one of the views and suppress
the other one, so that the utterance creates an identical
experience to visual inspection: "1:15 AM" for all users.
Bug: 21718000
Change-Id: Ic9920d71ae4d4ad41ba86d7bd96f9a19b07e2108
In addition to cleaning up some bare references to the icon
slot, we now apply updates to notification RemoteViews in
the context of the supplying app's package. This ensures we
can find the drawables inside any Icon objects that were
constructed without a proper package name, such as is the
case with Actions (because the builder and constructor are
Context-free and so don't know the package name).
This CL also makes clear what was previously only implied:
Non-resource action icons are not actually supported yet
since they can't be pushed to TextView compound drawables
using today's RemoteViews APIs. That will require an API
change.
Bug: 22600607
Change-Id: Ie6b88aed36e4db05be35f843ea3bc1898d4a5c96
- Add callback to inform SysUI when the screen has been unblocked
and turned on.
- Cleanup inconsistent messaging about device interactive/screen on
and off.
- Add callbacks to inform SysUI about screen states
- Implement a quick fade for the scrim after touch, wake, and unlock.
First, start with a black scrim on top of everything, and then fade
it out.
- Make sure we play the normal unlock animation when device is pulsing
- Override navigation bar animations for touch, wake and unlock: Fade
in the same manner as the scrim.
Bug: 22571198
Bug: 21855614
Change-Id: I8ff08d72cced1e0f03c78d71ff710d8a4f6b848c