OSDN Git Service

Remove "enhance web scripts" from settings and make it requested by plug-ins.
authorSvetoslav <svetoslavganov@google.com>
Tue, 29 Jan 2013 09:04:35 +0000 (01:04 -0800)
committerSvetoslav <svetoslavganov@google.com>
Tue, 29 Jan 2013 21:56:22 +0000 (13:56 -0800)
commit3822896e226567c6cd3ef84518d318abd33a7624
tree6e755134d69f6b6ecac12d0ee949124e42ed43a3
parent8c47e856b067057b5fcbb6eccfc79d1da4cff8f1
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
api/current.txt
core/java/android/accessibilityservice/AccessibilityServiceInfo.java
core/java/android/provider/Settings.java
core/res/AndroidManifest.xml
core/res/res/drawable-hdpi/perm_group_accessibility_features.png [new file with mode: 0755]
core/res/res/drawable-mdpi/perm_group_accessibility_features.png [new file with mode: 0755]
core/res/res/drawable-xhdpi/perm_group_accessibility_features.png [new file with mode: 0644]
core/res/res/values/attrs.xml
core/res/res/values/strings.xml
packages/SettingsProvider/src/com/android/providers/settings/DatabaseHelper.java
services/java/com/android/server/accessibility/AccessibilityManagerService.java