Bug: 6490959
Fixes the issue where we will show the old tap highlight
if webkit isn't quick enough to respond
Change-Id: Icd9864d276b6ad311e3f3dc4deaa7085e3769006
Bug 6507332
The IME must be informed whenever the selection or composing
region changes so that it can adjust its replacement regions
and suggestions.
Change-Id: I484b112a2fede6528b0bc506711284b59bd886d1
When XT stats are available, transition to prefer them over DEV,
since they aren't subject to hardware driver bugs. Only switches at
the first atomic XT bucket, and adds a Settings.Secure flag to force
back to DEV if needed. Includes tests to cover transition.
Fix tests where device overlay would change which network types
reflected data usage. Test both history and summary APIs. Fixed
collection timestamps to reflect full buckets.
Bug: 6504744
Change-Id: Idd7f3b2fdb064c36547c85c51c214fd938c59b7e
Make the WebCoreWatchdog aware of the WebViews it is monitoring
(rather than the Activity context which may become stale) and
ensure that the code for the prompt dialog is run on the UI
thread.
Bug: 6420310
Change-Id: Ied003938edb04858c85bcc2491c4b2c4c0ede6eb
Removing the code that delays a surface destruction when
WindowManager.FLAG_KEEP_SURFACE_WHILE_ANIMATING is set. The lock
screen that continued to animate after destroySurfaceLocked is no
longer used and this code was causing problems.
Also mDrawState was being set to NO_SURFACE in destroySurfaceLocked
even if the surface ended up not being destroyed. Later when it was
reused the false value of mDrawState was messing things up.
The screen lock bug referenced below no longer levaes the user stuck
with a black lockscreen. However it occasionally powers back up in the
launcher screen rather than the lock screen.
Fixes bug 6485955.
Change-Id: I684104c7e7c39c161a5118aa890889fbae92e635
This fixes a glitch caused by clearing the array of chevrons before
stopping the associated animations. The old animations were allowed to
complete which caused chevrons to move around erratically because they
were being controlled by multiple animators.
Change-Id: Iec1450dd83077a721930eb3cac19a621e7356980
1. Some accessibility actions should not be performed on disabled
views. For example, scrolling should not be permitted while
accessibility focus should be. Made a quick pass over the
actions we expose now.
Change-Id: I36626dfbc0d2f480309a910f58f1de64e9e05675
This cl ensures that we immediately route the user to the add account
activity if they don't have an account and their is only one relevant
account type. Also reordered the setContent logic to reduce flicker.
Note that as of this CL there is still some flicker remaining when
launching G+ without an account. But it appears to be fixed in other
apps.
Bug: 6455975
Change-Id: I91e33b4fb9618a31765b4a8651334b1c52640828
When using stable layouts, you are typically expected to hide and
show the status bar through the system UI fullscreen flag. This hides
both the status bar and the action bar. The stable layout assumed
that when not hiding the status bar through the system UI flags, that
the status bar would be visible.
This change makes things a little smarter, also looking at the
window's fullscreen flag (which only hides the status bar). If this
flag is set on the window, then the stable layout now assumes that
the status bar will never be shown. This allows us to position the
action bar correctly in the situation where the application has set
the window to fullscreen and requested a stable layout, instead of
always leaving room for the status bar above it.
Change-Id: I757072ae99cd3741753af7210dbf51afe94d3db5
