Prior change 199020 fixes it for instances of CarrierLabel;
this fixes it for customers of NetworkController.
Bug: 6639047
Change-Id: I69dada2298f4a3caf453f43d847cdb32fe7eaa9f
When the screen is off, we might not receive real vsync pulses from
the hardware which would cause posted Choreographer callbacks to not run.
This is bad because messages in the Looper might be blocked behind a barrier
that is scheduled to be removed by one of those Choreographer callback
(see ViewRootImpl.doTraversals). Until the barrier is removed, those messages
will not run. To prevent starvation of the Looper, we synthesize fake vsync
pulses at a reduced rate whenever the display hardware stops generating them.
This change should fix a variety of rare non-deterministic bugs where
the system might appear to be unresponsive while the screen is off,
and spurious ANRs reported shortly after the screen is turned back on.
Bug: 6574842
Bug: 6636995
Bug: 6643559
Change-Id: I263f2fdf979afd79e5ac47a0cc5d34a93b860c21
People generally expect, if they are using FLAG_KEEP_SCREEN_ON,
that the screen won't immediately dim after it is cleared, even
if it has been passed the user activity timeout since the last
user interaction. So include the flag to reset the user activity
timeout when releasing its wake lock.
Change-Id: If7a8fea8faef3edbf13dff10a2f248adc9e3ff0b
The foreground activity is stopped when the device goes to sleep,
and started again when the device is unlocked. We now distinguish
this case from a "normal" stop, and do not finish() a foreground
noHistory="true" activity inappropriately when the device sleeps.
We also detect the case where an activity is started while the
device is still asleep, in which case the foreground noHistory
activity is cleaned up as part of bringing the new activity to
the foreground.
Bug 6657549
Change-Id: I9c6a0830aed0e47e4207b62803b90067c8486112
* Accept a Context when fetching the names of routes and
categories. This lets string resources resolve at time of access
with the correct configuration. The older versions remain available
that will use the static resources from the application. (There are
enough cases where applications will populate this from external
data that requiring it each time even when it was not initialized
from a resource doesn't seem reasonable.)
* Remove the ability for apps to programmatically select non-user
routes.
* Make MediaRouter.Callback an abstract class instead of an interface.
This will make further extensions easier to keep compatible in the
future.
Change-Id: If981c511dfbdfaf41ef0d1cfe4a377fc14bb5600
Bug #6642475
When expanding the status bar, create one layer per notification instead of
a single giant layer for the pile of notifications. This prevents layer
creation failure when the total height of the notifications is larger
than the maximum allowed texture size in OpenGL ES 2.0.
This change only enables layers on notifications that will be visible
once the notification area is fully expanded.
Change-Id: I3c791a66cf5ac0973f3a65cfcd84b95209d580f3
Restricting to pkg="android" didn't filter out things like
open wifi networks, etc. So now we have a whitelist:
notifications must be sent the "android" pseudo-package,
*and* they must have one of these "kind" tags:
- android.system.imeswitcher (IME switcher, needed by SUW)
- android.system.update (OTAs)
Note that OTAs currently use a fullScreenIntent, so they
bypass this logic anyway, but for consistency's sake we now
allow OTA icons in the status bar explicitly.
Bug: 6645469
Change-Id: Ib2e2f22d7a0817a1acaf8137ed4f3c7d3ddf8af5
- Sometimes the black background would flash; changing
animation durations to make this much less likely
- Fixing issue in Recents where we sometimes forgot
to disable drawing caches on views after enabling them
1. Accessibility allows querying only of the active window.
The active window is the one that has input focus or the
one the user is touching. Hence, if the user is touching
a window that does not have input focus this window is
the active one and as soon as the user stops touching
it the active window becomes the one that has input
focus. Currently the active window is not updated properly
when the user lifts his finger. This leads to a scenario
of traversal actions sent to the wrong window and the user
being stuck.
The reason is that the last touch explored event that is
used to determine where to click is cleared when accessibility
focus moves but this event is also used to determine when to
send the hover exit and touch exploration gesture end events.
The problem is that the last hover event is cleared before
it is used for sending the right exit events, thus the event
stream is inconsistent and the accessibility manager service
relies on this stream to update the active window. Now we
are keeping separate copies of the last touch event - one
for clicking and one for determining the which events to
inject to ensure consistent stream.
bug:6666041
Change-Id: Ie9961e562a42ef8a9463afacfff2246adcb66303
The NavBar is always non-slippery, except when:
- the notification shade is showing
- the 3 buttons (back,home,recents) are disabled
Also fix unrelated bug that ignored the "show panel delay"
before the first config change.
Bug: 6614842
Change-Id: Ib40adaef122b563809398fdebbd8a88d8f0c7ffd
Moved some duplicate code from SearchPanelView and LockScreen
over to SearchManager to avoid creating yet another copy of it
in PhoneWindowManager.
Bug: 6594275
Change-Id: Ib4ebcd6817639d17548952ab2ce7cb876c05777c
1. We are deciding whether the user is performing a gesture or an exploration based
on the gesture velocity. If we are detecting gesture we do the recognition at the
gesture end which is when the finger goes up. This is better than having a mode
toggle gesture for exploring and gestures detection. However, it is possible that
the user really wanted to perform an exploration but was moving too fast and
unless he lifts his finger the device is in gesture detection mode. This is
frustrating since the user has no feedback and assumes exploration does not
work.
We want to perform gesture detection only for a maximal time frame and if the
user did not lift his finger we transition into touch exploration state.
bug:6663173
Change-Id: I954ff937cca902e31b51325d1e1dfce84d239624
1. AccessibilityInjector was returning true even if the underlying
JavaScript was not loaded/failed. This may lead to TalkBack getting
stuck in a web view. To avoid this TalkBack requires gran1ularity
change when getting into web view. This is neither advertised nor
shown in the tutorial and which is worse it is inconsistent with
the traversal of the app.
Now if the action fails, false is returned and also the timeout for
handling the action request is increased to 5s. Upon the completion
of this timeout TalkBack may decide to show a wait dialog or just
skip the web content. We are treating this as an ANR.
bug:6663344
Change-Id: Idf3d08fe928c495bb974a127f853de6f938e2f77
Previously, it was observed that while a SIM is being initialized
by the hardware the SIM may briefly be reported as being in an
ABSENT state before eventually transitioning into a READY,
PIN_REQUIRED, PUK_REQUIRED, PERM_DISABLE state.
While booting up, the phone might observe that the SIM is ABSENT and
therefore bypass the keyguard going straight to the home screen.
Later when the SIM was fully initialized, the phone would revert back
to the lock screen in order to ask for the PIN. The user might
turn on the phone, slide out the keyboard (bypassing the keyguard),
then a few moments later the keyguard would pop up prompting for a PIN.
The user experience could be somewhat jarring, so the keyguard was
changed to handle the transient case differently. While the SIM
was ABSENT, the keyguard would not be automatically bypassed
by opening the keyboard slider. Thus the user would be forced to
manually swipe away the keyguard before interacting with the
device. This would help to cover the time it would take before
the SIM was fully initialized and the keyguard could determine
whether the user would need to be prompted for a SIM PIN or PUK.
To prevent the keyguard from being bypassed automatically, we
hacked up the keyguard so that it would be considered to be in a
secure state while the SIM was ABSENT. It's worth noting that
considering the keyguard to be secure did not confer any
additional security properties to the system whatsoever.
If the user did not have a pattern lock, PIN or password set then
all it would take to access the phone is to swipe away the keyguard.
This old hack was all about devices with slide-out keyboards,
but it had some side-effects. Namely, it assumed that the SIM
ABSENT state was transient. But what about phones that are
being used without a SIM at all?
Considering the keyguard to be secure when the SIM is ABSENT
breaks stuff. In fact, it turns out that making the keyguard
secure isn't really what we want at all. What we want is a way
to prevent the keyguard from being automatically bypassed on
boot when the user opens up a sliding keyboard. But we don't
have those anymore... and in the worst case it was just a little
janky... and what's more, nowadays the keyguard provides useful
features so maybe we shouldn't bypass it anyhow... oh and actually,
I deleted the code that used to bypass the keyguard when the
keyboard slider was opened... so this does nothing useful at all.
Right...
This change removes the old hack thereby ensuring that non-secure
keyguard features like launching the Camera or Assistant or
application features like hands-free voice search will work
correctly on phones without a SIM.
Bug: 6022658
Change-Id: I019d1d8c65c55cbf4d10d4928e1d2b2b242162a6
