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
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
1. Every accessibility services targeting JellyBean or higher has
to request a special permission for the system to bind to it.
Change-Id: I6e579326bdf3597f148d6c67317455701ec8af68
Bug: 6505722
When we scroll the base layer we do so by calling scrollTo on the view,
which handles all the scrollbar logic for us. Remove the custom keep alive
code which floods the handler queue, as well as remove the unnecessary
invalidate and awakenScrollbar calls (View does that for us)
Change-Id: Ia2503c549a22ec71d99295fe62b676fecc367ea3
This makes a noticeable improvement in cases where applications
post messages that need to be processed between animation frames.
Bug: 6418353
Change-Id: If225742e37aeaf3f0ca9710f9bf43dbb03bcde12
- Horizontal layout
- At most 2 are shown
- Tombstones are now shown (if the intent is null, the
button is disabled; use it for quick feedback of an
action's effect)
Bug: 6418617 (tombstones)
Bug: 6482237 (action separators)
Change-Id: Ie0c613006227bbfe1c0ec6eab1cda4f3782a05f2
1. View is checking if the accessibility focus is its
descendant it clears the accessibility focus state
in ViewRootImpl. The check in View was missing the
case that the descendant may be the view itself. In
such a case we want the normal clearing code to run.
2. The check whether a view has iterable text for
accessibility was inverted and text nav was not
working.
Change-Id: I1a13b6809fb7f205fff76ca09cd449179d06e530
Bug #6485955
If an invalidate gets scheduled right before the EGL surface is destroyed,
the next draw pass is done in software. This causes the software renderer
to connect to the surface forever which prevents the hardware renderer
from coming back when the screen is turned back on.
The fix here is to ignore the draw request when hw acceleration is requested
but not yet available. Proper software fallback will still happen when an
error is encountered with hardware rendering (in which case hw acceleration
will not be marked as requested anymore.)
Change-Id: I1edc4a51c8dd38240aa2345092a18a081a756fc1
