# Via Android (Google) Code Review (1) and Svetoslav (1)
* commit 'ec695824af7ab263eaae613b87f2c0b24f176f91':
Remove "enhance web scripts" from settings and make it requested by plug-ins.
Currently we have an "enhance web accessibility" setting that has to be
enabled to make sure web content is accessible. We added the setting to
get user consent because we are injecting JavaScript-based screen-reader
pulled from the Google infrastructure. However, many users do not know
that and (as expected) do not read the user documentation, resulting in
critique for lacking accessibility support in WebViews with JavaScript
enabled (Browser, Gmail, etc).
To smoothen the user experience now "enhance web accessibility" is a
feature an accessibility plug-in can request, similarly to explore by
touch. Now a user does not need to know that she has to explicitly
enable the setting and web accessibility will work out-of-the-box.
Before we were showing a dialog when a plug-in tries to put the device
in a touch exploration mode. However, now that we have one more feature
a plug-in can request, showing two dialogs (assume a plug-in wants both
features) will mean that a user should potentially deal with three
dialogs, one for enabling the service, and one for each feature. We
could merge the dialogs but still the user has to poke two dialogs.
It seems that the permission mechanism is a perfect fit for getting
user permission for an app to do something, in this case to enable
an accessibility feature. We need a separate permission for explore
by touch and enhance web accessibility since the former changes the
interaction model and the latter injects JavaScript in web pages. It
is critical to get user consent for the script injection part so we
need a well-documented permission rather a vague umbrella permission
for poking accessibility features. To allow better grouping of the
accessibility permissions this patch adds a permission group as well.
bug:8089372
Change-Id: Ic125514c34f191aea0416a469e4b3481ab3200b9
Bug #8066455
ViewRootImpl was properly detecting that the renderer was not
ready to draw but would simply schedule another frame, thus sending
the systemui into an inifite redraw loop. This change reinitializes
the renderer if needed (if the renderer is requested but not enabled.)
This CL also fixes an issue caused by the default wallpaper. Since it
never calls eglTerminate(), managed contexts are never reclaimed.
Change-Id: Idb8caa672be8ee35f6e6a7e942d9abd8aa100967
# Via Android (Google) Code Review (1) and Fabrice Di Meglio (1)
* commit 'de71ce1ab3cda6030b5838f4cadb4fe974d522c2':
Fix recent apps item text position in RTL mode
# Via Android (Google) Code Review (1) and Fabrice Di Meglio (1)
* commit '5e3b0452667e2f73b16bfffde873334525582308':
Fix SystemUI navigation bar in RTL mode
# Via Android (Google) Code Review (1) and Dianne Hackborn (1)
* commit 'd8ba6cc9217e2e042106870e9d2e70cfd80426d6':
Add new API to propagate contextual data to the assist action
When launching an assist, we have a new API allowing the
current foreground activity/application to provide additional
arbitrary contextual information that is stuffed in the
assist intent before it is launched.
Change-Id: I0b2a6f5a266dc42cc0175327fa76774f814af3b4
In LTR mode the navigation bar is:
- portrait (from left to right) : Back | Home | Recent Apps | Menu
- landscape (from top to bottom) : Menu | Back | Home | Recent Apps
This is kinda horizontally / vertically "pivoting +90 degrees" around the Recent Apps button.
In RTL mode, we had:
- portrait: Menu | Recent Apps | Home | Back
- landscape: Menu | Recent Apps | Home | Back
to make it similar to the LTR mode, we should have a rotation of -90 degrees around the Recent Apps button:
- landscape: Menu | Back | Home | Recent Apps
Change-Id: I9de511383b632ae8dea1396e9152109cc8a57c27
- load the correct landscape asset when needed (the portrait one was used in
both portrait and landscape modes)
Change-Id: I27d2aad993ee78c5a0c4a5f834e2a7f1f852cfa9
