Ensure that the user has had a chance to see it for a few
seconds after screen recording has ended.
Bug: 19121797
Change-Id: I52b69b2029439d42163ead5dc8748889b4f61934
(cherry picked from commit 8fd25bf7711aabffe73213ba1f9056f285270695)
When 2 notifications were posted as the summary of the same
group, then the system would eventually crash.
Bug: 23676310
Change-Id: Ia8f95e624f3f43d1b55169dd8102e3c89427dc76
Previously the notification effects were not correctly cleared in certain
cases and the user could end up in a state where the notification light would
always blink.
Bug: 22931139
Change-Id: I9a71e56cf4479354a9d773b5b6f0edd7693f2b05
Also clear identity when measuring ASEC sizes to relax a second
permission requirement.
Bug: 23600574
Change-Id: Ib3a104426758e0e8f35dff0e504fe874bed7311f
If the given app name is too long for the permissions dialog, then
it can push the warning that the application will be able to record
the screen below the fold, letting the app basically set its own
dialog message in a way that a user would be difficult to detect as
fraudulant.
Bug: 23345192
Change-Id: If5881ca75d5c155ef5174351d245dbc3abdaa584
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
The main looper needs to run freely for a moment after disabling
wifi in order for various signals (content observers, broadcast) to
propagate to all the listeners that need to take action for the
wifi stack to shut all the way down. This patch breaks up the
disable-and-rewrite-config sequence of wifi AP restore in to two
distinct operations separated by a moment so as not to block those
necessary messages.
Bug 22979342
Change-Id: I271766cad0e454669a194652fb67f835bb022cd1
We've seen case of it taking longer than 1500ms for the wifi system to
actually shut down after the triggering settings element is written,
so extend the wait time a bit. We've seen it take more than 1500ms
but not more than 2500ms, so that's the new heuristic.
This will of course all become happily obsolete once we start
applying restored AP definitions programmatically rather than by
filesystem-level operations.
Bug 22979342
Change-Id: I6acf1baac23d4100124093128b82abf242b11a0e
- 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
This allows the both the ssid and connection info to be verified when
updating wifi info.
Bug: 22797622
Change-Id: I82d771a299e17469683516c6b1077cb260981812
When the device is lost or stolen, it's safer to
fall back to strong authentication (pin, pattern or
password). This disables fingerprint like we do with
trust agents.
Fixes bug 21620081
Change-Id: I7bbe54be3721b2f160b783daeb3acbe434705046
