summaryrefslogtreecommitdiffstats
path: root/packages/SettingsProvider
Commit message (Collapse)AuthorAgeFilesLines
...
| * Make sure settings writes are permission checked correctlyChristopher Tate2012-10-051-52/+45
| | | | | | | | | | | | | | | | | | | | | | | | The last bit of undoing the earlier tangle around query results having observers under the calling user's identity. We do *not* want to drop calling identity in the call() processing; we want the table-based permission checks at the point of the underlying db operations to be performed against that identity. Bug 7265610 Change-Id: Ie0c9331ebd0918262a0a32b5b03b876fc2a92ca3
* | Fix upgrade case for Settings.Secure.USER_SETUP_COMPLETE.John Spurlock2012-10-052-1/+31
| | | | | | | | | | | | | | | | | | Existing primary users were never being marked as complete, causing things that relied on this (e.g. showing the quick settings panel) to break. Bug:7282088 Change-Id: I9c8622f3cd0fb99a44477946d3db22fa2cbbc6fc
* | Settings (and general) restore fixesChristopher Tate2012-10-041-2/+8
|/ | | | | | | | | | | | | | | | | | Pro tem, we ignore wifi configuration data when restoring system settings. This is not ideal, but it *does* mean we do not bounce wifi off and on again during the extended restore process, which in turn means we don't interfere with things like the Play Store's download of applications. We do continue to back up wifi configuration, and will start using that data again when the new implementation that restores AP configurations without having to bounce wifi comes to pass. Also, this CL fixes a longstanding bug in BackupDataInput.skipEntityData() that was being reproduced reliably once settings restore was skipping the wifi-related entities in the restore stream. Bug 7249405 Change-Id: I61520a9a116b66ebdf95734d09d9afd46406df01
* Make sure to check write perms after rewriting destination tableChristopher Tate2012-10-041-1/+3
| | | | | | | | | | | The write-permission check must occur after any destination-table rewriting, otherwise any application would be able to write to any global setting, by supplying a fraudulent "system" namespace in the uri, but with a key name that will be redirected to global. Bug 7289965 Change-Id: I122098a64e40d14e00d3cb6608c50aeb74faf7ce
* Merge "Rewrite raw insert()s and some raw query()s of moved-to-global keys" ↵Christopher Tate2012-10-031-1/+22
|\ | | | | | | into jb-mr1-dev
| * Rewrite raw insert()s and some raw query()s of moved-to-global keysChristopher Tate2012-10-031-1/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Settings put*() APIs fix up references via the old namespaces, but the raw insert() interface didn't. Now it does. Also, when possible we fix up direct query() operations on the old namespace to point to the correct one. At present that is only done for query() operations with Uris of the form content://secure/adb_enabled There is no rewriting done on queries of the form content://secure WHERE name='adb_enabled' since the app-supplied WHERE clause can be arbitrarily complex. Bug 7267568 Change-Id: I5c8cecbea7f5b1da6247a53b1428d3effb0bbca5
* | Merge "Use myUserId() only in registerContentObserver()" into jb-mr1-devChristopher Tate2012-10-031-1/+11
|\ \
| * | Use myUserId() only in registerContentObserver()Christopher Tate2012-10-031-1/+11
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The reason for this is a bit subtle: we want to guarantee that when a content observer is registered using the public API, it is *always* bound to the host user's view of the data behind the observed Uri, never the calling user's. Now, the reason it was the calling user in the first place is that the Settings provider (and potentially any singleton provider) needs the observers underlying Cursors returned from query() to be tied to the caller's user, not the provider's host user. In order to accomplish that now that the public-facing behavior is always tied to the host user, the concrete class that implements the Cursor type handled by the Settings provider has been extended with a new hidden API for setting a notification observer tied to an arbitrary user; and then the provider explicitly downcasts the query result's Cursor to that class in order to register the notification observer. We can do this safely because this is platform code; if we change the way that these underlying cursors are constructed, we can just fix this point of call to follow along. If they get out of sync in the future, the Settings provider will scream bloody murder in the log and throw a crashing exception. Bug 7231549 Change-Id: I0aaceebb8b4108c56f8b9964ca7f9e698ddd91c8
* | fix settings data base upgrade for ringer modeEric Laurent2012-10-031-4/+20
|/ | | | | | | | | Ringer mode setting was moved from System to Global group but a db upgrade cleanup step was missing. Bug 7128886. Change-Id: Id20994fe74575afa2b68154a620aa3c8807e8304
* Make settings backup/restore work in the new multi-user worldChristopher Tate2012-10-022-175/+77
| | | | | | | | | | | | | | 1) Properly handle restores of settings elements that have been migrated to the new global namespace 1) Back up and restore the new global settings namespace 3) Make sure to back up / restore the global entity ENABLE_ACCESSIBILITY_GLOBAL_GESTURE_ENABLED Bug 7249405 Change-Id: Ibfa9930ea4d0e16c7635697e8c631b155e4c0cb2
* Migrate more System and Secure settings to Global.Jeff Sharkey2012-10-022-20/+67
| | | | | | | | Includes telephony, WindowManager, PackageManager, and debugging settings. Update API to point towards moved values. Bug: 7231764, 7231252, 7231156 Change-Id: I5828747205708872f19f83a5bc821ed0a801cb79
* Attempt to fix missing lock soundsJim Miller2012-10-011-4/+6
| | | | | | bug 7254629 Change-Id: I65eee674fe014a0e84d5ec20ead81abdec38f890
* Move bluetooth priorities from Secure to Global.Jeff Sharkey2012-10-011-1/+59
| | | | | Bug: 7231171 Change-Id: I836fdc2cfb8d67f984b4715559b9e92d0dc41c95
* Migrate more Secure settings to Global.Jeff Sharkey2012-09-272-25/+102
| | | | | | | | Migrate networking, storage, battery, DropBox, and PackageManager related Secure settings to Global table. Bug: 7232014, 7231331, 7231198 Change-Id: I772c2a9586a2f708c9db95622477f235064b8f4d
* First step towards cleaning up Global settings.Jeff Sharkey2012-09-262-96/+96
| | | | | | | Remove all @Deprecated @hide settings, and clean up any stragglers. Bug: 7232125 Change-Id: Ibf67093c728d4a28565129b923edb1701d3b2789
* Merge into jb-mr1-devJean-Baptiste Queru2012-09-251-1/+2
|\ | | | | | | Change-Id: Idf183be6a41ff37add5141a20e96d5190396d1a4
| * fix argument parser for global settings URLsDoug Zongker2012-09-241-1/+2
| | | | | | | | | | | | | | | | Make content://settings/global/setting_name URLs work like system and secure URLs. Bug: 7212535 Change-Id: I33e388a0cc80309453714eab726ce45b3f8fef73
* | Fix issue #7215984: java.lang.RuntimeException: Unable to create...Dianne Hackborn2012-09-241-7/+2
|/ | | | | | | | | | | | | | | | | | | ...service com.android.systemui.SystemUIService: java.lang.NullPointerException - Don't acquire the activity manager lock in handleIncomingUser(), there is really no need to do so. - Rework the settings provider client side cache code to not hold locks while calling into the provider. I also changed the way the settings provider uses system properties so that there is one property for all users. We can't do one per user, since the system property name space is limited with a fixed size. And we don't really need to do that; the worse that happens by combining all users is that if one running user changes one of its settings, all other running users will think they need to reload settings when they go to fetch them next. Change-Id: I13b90b832310d117eb6d721aacd122cfba7d749a
* Multiuser awareness in content observer infrastructureChristopher Tate2012-09-201-51/+53
| | | | | | | | | | | | | | | | | | Content observers are registered under the calling user's identity, not under the provider host's identity (unless the caller is using the new permissioned entry points that allow observers to be registered for a different user's view of the data). The most important implication of this is that when the settings provider is directly queried, the Cursor returned to the app is wired for change notifications based on that calling app's user. Note that it is not possible to use query() / insert() to read/write data for different users. All such manipulations should use the standard get* / put* methods in Settings.*. Bug 7122169 Change-Id: If5d9ec44927e5e56e4e7635438f4ef48a5430986
* Add support for remembering Wifi display devices.Jeff Brown2012-09-192-0/+4
| | | | | | | | | | | | | | Add a setting to globally disable Wifi display. Fixed a bug where the wifi display broadcast receiver was running on the wrong thread. Removed the wifi-display QuickSettings dialog, all functionality has been moved to Settings. Bug: 7178216 Bug: 7192799 Change-Id: I9796baac8245d664cf28fa147b9ed978d81d8ab9
* Settings provider needs to send notifications as itselfChristopher Tate2012-09-181-1/+6
| | | | | | | ... and not as its ultimate caller, who may be a less-privileged application. Fixes bug 7188309 Change-Id: Iffd37b8da84f683bf665bf3d48c0b7fbc8dd721d
* Per-user content observer APIsChristopher Tate2012-09-171-3/+5
| | | | | | | | | | | | | | | | | | | | Callers with INTERACT_ACROSS_USERS_FULL permission can now observe content for a given user's view (and can notify content uri changes targeted to a specific user). An observer watching for UserHandle.USER_ALL will see all notifications for the given uri across all users; similarly, a notifier who specifies USER_ALL will broadcast the change to all observers across all users. The API handles both USER_ALL or USER_CURRENT, and explicitly forbids any other "pseudouser" designations. This CL also revs the Settings provider to notify with USER_ALL for changes to global settings, and with only the affected user's handle for all other changes. Bug 7122169 Change-Id: I94248b11aa91d1beb0a36432e82fe5725bb1264f
* Fix default population of wifi settingsChristopher Tate2012-09-141-8/+9
| | | | | | | | | | | | | | | | | Various wifi settings that are explicitly defaulted did not get their default code properly converted to refer to the correct settings database table. A collection of moved-to-Global settings that had not yet been marked @deprecated in the Secure.* namespace are now so marked. Also updated the namespace used to refer to wifi settings from the Wifi Service. These changes are cosmetic, but they do eliminate a number of runtime log messages. Bug 7153671 Change-Id: I9e5b6464d025cfb480ef97373996e38e82f90593
* Merge "Fix Settings writes to a different user" into jb-mr1-devChristopher Tate2012-09-141-74/+70
|\
| * Fix Settings writes to a different userChristopher Tate2012-09-131-74/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Oops. Stacked bugs: first, the desired user handle was not properly being passed from the call() entry point to the database operations; then on top of that, the client-side cache management was still looking in the local user's cache for the data, so a request to read a different user's settings would return the local user's instead if that key was already known to the local user's cache. Reads and writes of a different user's settings are now uncached, so they're relatively much slower. They're rare, however, so this is not something to worry about unless we encounter a real world case where it's a significant factor. This CL also adds a bit of cross-user settings read/write testing to the existing provider suite. These new tests caught both the known wrong-user-write bug and discovered the client-side cache bug, so yay. Finally, the existing wholesale mutual-exclusion approach would deadlock in certain circumstances due to the fact that the settings database creation code might have to call out to the Package Manager while populating the bookmark/shortcut table, and the Package Manager would then call back into the settings provider in the course of handling that request. The synchronization regime has been significantly tightened up now: now the database code [which is known to deal with concurrency itself] is allowed to cope with multiple parallel openers of the same db; this allows the settings provider to avoid calling out to other parts of the system even implicitly while its internal lock is held. Change-Id: Ib77d445b4a2ec658cc5c210830f6977c981f87ed
* | Settings db upgrade steps only apply to the owner userChristopher Tate2012-09-131-63/+74
|/ | | | Change-Id: Ib74b42bcc2554edf721199f31f563daa9fc227a2
* Merge "Core accessibility settings should not be cleared on restore." into ↵Svetoslav Ganov2012-09-121-11/+21
|\ | | | | | | jb-mr1-dev
| * Core accessibility settings should not be cleared on restore.Svetoslav Ganov2012-09-121-11/+21
| | | | | | | | | | | | | | | | | | | | | | | | 1. The core accessibility settings required for a blind user to use the device should not be overwritten on restore. There could have been enabled via a global gesture from setup wizard, hence the user definitely needs them. Restoring disabled values for these settings render the device useless unless sighted help is sought. bug:7138401 Change-Id: Idc593889aa61fada65b0407623720517c827df53
* | Moved a few telephony settings from Secure to GlobalChristopher Tate2012-09-122-1/+24
|/ | | | | | | Also tidy up the bookkeeping for a few settings that were earlier moved to Global without the redirect tables being fixed up. Change-Id: I69275db3b2636cd6ba9c8c51b88e97d8ba4b7b7d
* Set up default (random) Android IDs for all usersChristopher Tate2012-09-111-18/+29
| | | | | | | | | | | Also correct some now-misleading terminology in a permission-check log message, and fix a bug in which a system component trying to write to a secondary user's settings would wind up writing the owner's settings instead. Bug 7132405 Change-Id: I5b8fafc35720390a01652e386ab5b7c0ad751abe
* Miscellaneous fixes for SettingsChristopher Tate2012-09-101-22/+6
| | | | | | | | | | (1) It's okay to write literal null as a settings element value (2) Properly convey the user handle in the put-for-user variant Bug 7137201 Bug 7139826 Change-Id: I0ed77d65e8377f0e0580a2668f10b7167ad34928
* Merge "Log all individual settings restored" into jb-mr1-devChristopher Tate2012-09-071-1/+1
|\
| * Log all individual settings restoredChristopher Tate2012-09-071-1/+1
| | | | | | | | | | | | Trying to get a handle on bug 7129406 Change-Id: If436c7888f0a8565d83c03024c54ea6ec83e7955
* | Move verification settings to Settings.Globalrich cannings2012-09-071-1/+18
|/ | | | | | | | | | | | Move Settings.Secure.PACKAGE_VERIFIER_ENABLE, Settings.Secure.PACKAGE_VERIFIER_TIMEOUT, Settings.Secure.PACKAGE_VERIFIER_DEFAULT_RESPONSE to Settings.Global.PACKAGE_VERIFIER_ENABLE, Settings.Global.PACKAGE_VERIFIER_TIMEOUT, Settings.Global.PACKAGE_VERIFIER_DEFAULT_RESPONSE, respectively. Bug: 7082362 Change-Id: I21fde031a330563891c0129132f3d6369ac5e7a5
* Further fixup of migration to global settingsChristopher Tate2012-09-072-17/+35
| | | | | | | | | | | | | | | | | | | | The Settings.System.STAY_ON_WHILE_PLUGGED element should have been migrated to the global table, but wasn't. This CL does a couple of things around dealing with this: (1) Tidies up the migration tables outright, so that they correctly reflect the intended final state (2) Introduces the option of doing a key migration only if the element has not yet been moved to the new table, to allow for safe retry- -with-ignore. This will make it easy to make any future alterations to the global vs per-user association of individual elements (3) Migrates the STAY_ON_WHILE_PLUGGED element if it hasn't been already. Bug 7126575 Change-Id: Ic5fa9ba45f11b09270bd5bc94c26fbbd84abc749
* Mark all settings upgrade transactions as successful along the wayChristopher Tate2012-09-061-1/+25
| | | | | | | If you don't, then the upgrade gets rolled back by the open helper, and Bad Stuff Happens. Change-Id: I191263e5cceb21b96ef413d28e7ee00a924acfc2
* Don't use toArray() inappropriatelyChristopher Tate2012-09-061-10/+7
| | | | | | HashSet<String>.toArray() does not give you an array of strings. Change-Id: I2053e714b12eab718aaf75d92bbc0625745b9932
* Screen magnification - feature - framework.Svetoslav Ganov2012-09-062-1/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change is the initial check in of the screen magnification feature. This feature enables magnification of the screen via global gestures (assuming it has been enabled from settings) to allow a low vision user to efficiently use an Android device. Interaction model: 1. Triple tap toggles permanent screen magnification which is magnifying the area around the location of the triple tap. One can think of the location of the triple tap as the center of the magnified viewport. For example, a triple tap when not magnified would magnify the screen and leave it in a magnified state. A triple tapping when magnified would clear magnification and leave the screen in a not magnified state. 2. Triple tap and hold would magnify the screen if not magnified and enable viewport dragging mode until the finger goes up. One can think of this mode as a way to move the magnified viewport since the area around the moving finger will be magnified to fit the screen. For example, if the screen was not magnified and the user triple taps and holds the screen would magnify and the viewport will follow the user's finger. When the finger goes up the screen will clear zoom out. If the same user interaction is performed when the screen is magnified, the viewport movement will be the same but when the finger goes up the screen will stay magnified. In other words, the initial magnified state is sticky. 3. Pinching with any number of additional fingers when viewport dragging is enabled, i.e. the user triple tapped and holds, would adjust the magnification scale which will become the current default magnification scale. The next time the user magnifies the same magnification scale would be used. 4. When in a permanent magnified state the user can use two or more fingers to pan the viewport. Note that in this mode the content is panned as opposed to the viewport dragging mode in which the viewport is moved. 5. When in a permanent magnified state the user can use three or more fingers to change the magnification scale which will become the current default magnification scale. The next time the user magnifies the same magnification scale would be used. 6. The magnification scale will be persisted in settings and in the cloud. Note: Since two fingers are used to pan the content in a permanently magnified state no other two finger gestures in touch exploration or applications will work unless the uses zooms out to normal state where all gestures works as expected. This is an intentional tradeoff to allow efficient panning since in a permanently magnified state this would be the dominant action to be performed. Design: 1. The window manager exposes APIs for setting accessibility transformation which is a scale and offsets for X and Y axis. The window manager queries the window policy for which windows will not be magnified. For example, the IME windows and the navigation bar are not magnified including windows that are attached to them. 2. The accessibility features such a screen magnification and touch exploration are now impemented as a sequence of transformations on the event stream. The accessibility manager service may request each of these features or both. The behavior of the features is not changed based on the fact that another one is enabled. 3. The screen magnifier keeps a viewport of the content that is magnified which is surrounded by a glow in a magnified state. Interactions outside of the viewport are delegated directly to the application without interpretation. For example, a triple tap on the letter 'a' of the IME would type three letters instead of toggling magnified state. The viewport is updated on screen rotation and on window transitions. For example, when the IME pops up the viewport shrinks. 4. The glow around the viewport is implemented as a special type of window that does not take input focus, cannot be touched, is laid out in the screen coordiates with width and height matching these of the screen. When the magnified region changes the root view of the window draws the hightlight but the size of the window does not change - unless a rotation happens. All changes in the viewport size or showing or hiding it are animated. 5. The viewport is encapsulated in a class that knows how to show, hide, and resize the viewport - potentially animating that. This class uses the new animation framework for animations. 6. The magnification is handled by a magnification controller that keeps track of the current trnasformation to be applied to the screen content and the desired such. If these two are not the same it is responsibility of the magnification controller to reconcile them by potentially animating the transition from one to the other. 7. A dipslay content observer wathces for winodw transitions, screen rotations, and when a rectange on the screen has been reqeusted. This class is responsible for handling interesting state changes such as changing the viewport bounds on IME pop up or screen rotation, panning the content to make a requested rectangle visible on the screen, etc. 8. To implement viewport updates the window manger was updated with APIs to watch for window transitions and when a rectangle has been requested on the screen. These APIs are protected by a signature level permission. Also a parcelable and poolable window info class has been added with APIs for getting the window info given the window token. This enables getting some useful information about a window. There APIs are also signature protected. bug:6795382 Change-Id: Iec93da8bf6376beebbd4f5167ab7723dc7d9bd00
* Per-user settingsChristopher Tate2012-09-062-193/+670
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Each user has its own Settings.System.* and Settings.Secure.* namespace now. In addition, this CL introduces the new Settings.Global.* namespace, which contains a number of previously-elsewhere named settings entities; these Global.* entities are common to all users. Because these elements have been moved from their prior existence in the other namespaces, attempts to access them under their old names and namespaces are detected and redirected (with appropriate compile-time and logging messages) to their new homes. The new Global.* namespace can only be written by system-level code, just like the existing Secure.* namespace. If an app attempts to write a key that was previously in the System.* namespace but has been moved to the Global.* namespace, then a warning is logged and no write is performed; the action is a no-op. (The app is explicitly not crashed, to avoid breaking well-behaved apps that can't know any better.) There is also now a hidden API for getting/setting settings entities associated with a user other than the caller's. Reading/writing data for a user other than yourself requires the signature-level INTERACT_ACROSS_USERS_FULL permission. Manipulating data for a different user cannot be done via the ContentProvider query() / insert() APIs; you must use the Settings.get/put APIs for that degree of control. In general, use of the get/set API is *strongly* preferred over query-type access to Settings. Bug 6985398 Change-Id: Ibee54ddff99fb847c8c2479c23b50f1e7524d724
* Add secure setting for package verificationrich cannings2012-09-062-1/+22
| | | | | | | | | | Framework changes to store and read a secure setting for package verification. Default is on/true. This setting will be turned on/off via the Settings app. Bug: 7082362 Change-Id: I6f93d3136add8af0dbbdc664f0473c5f5b7e3fee
* Restore original default Wifi sleep policy (always)Dmitry Shmidt2012-09-051-2/+2
| | | | | | | BUG: b/7092819 Change-Id: I6ee6755fd04df2f0169f8602e60542c3591038f3 Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
* Change default setting for dreams to 'when docked'John Spurlock2012-08-291-1/+1
| | | | | Bug:7078718 Change-Id: I4ec74cc9562ab728d6f86938758ede74c241c63b
* am 15e099cc: am 0e0942c7: Merge "Default WiFi sleep policy setting"Jean-Baptiste Queru2012-08-292-0/+4
|\ | | | | | | | | * commit '15e099cc09589f963933f046d7267552ba3ffad8': Default WiFi sleep policy setting
| * am 0e0942c7: Merge "Default WiFi sleep policy setting"Jean-Baptiste Queru2012-08-292-0/+4
| |\ | | | | | | | | | | | | * commit '0e0942c7209c758bc00939ae54059dc24bce3abb': Default WiFi sleep policy setting
| | * Default WiFi sleep policy settingErik Ljungberg2012-08-292-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Creates a defult.xml setting for WiFi sleep policy. It is now possible, through device overlays, to change the default sleep policy to e.g. never in order to improve user experience of WiFi. Change-Id: Ie459b8e70fdbc7c605452fe0692d7bc26460e939
| | * Create telephony-common and mms-common - DO NOT MERGEWink Saville2012-07-172-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These have been created to reduce the size and complexity of frameworks/base. mms-common was created by moving all of frameworks/base/core/java/com/google/android/mms to: frameworks/opt/mms telephony-common was created by moving some of frameworks/base/telephony to: frameworks/opt/telephony Change-Id: If6cb3c6ff952767fc10210f923dc0e4b343cd4ad
* | | Add framework support for multiple dreams.John Spurlock2012-08-222-2/+12
| | | | | | | | | | | | | | | Bug:7028665 Change-Id: I4fba6b8e39dc07af4490c621ac3bc7b3867371b2
* | | resolved conflicts for merge of 80c904df to jb-mr1-devSvetoslav Ganov2012-08-161-9/+63
|\ \ \ | |/ / | | | | | | Change-Id: Ic2f8d64cd716d04a533ca0685d1fb0d5e2a21933
| * | am 8631701b: Allow enabled accessibility service to toggle tocuh exploration ↵Svetoslav Ganov2012-08-161-5/+61
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | after an upgrade to JellyBean. * commit '8631701bb770f3a4e3b2a139dc282f2244fe86e6': Allow enabled accessibility service to toggle tocuh exploration after an upgrade to JellyBean.
| | * | Allow enabled accessibility service to toggle tocuh exploration after an ↵Svetoslav Ganov2012-08-151-5/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | upgrade to JellyBean. 1. Before JellyBean touch exploration was a global setting controlled by the user via the UI. However, if the enabled accessibility services do not handle touch exploration mode, enabling it makes no sense. Therefore, in JellyBean the services request touch exploration mode and the user is presented with a dialog to allow that and if she does we store that in the database. As a result of the above change a user that has enabled accessibility, touch exploration, and some accessibility services running a pre-JellyBean system version may lose touch exploration state, thus rendering the device useless unless sighted help is provided, since the enabled service(s) are not in the list of services to which the user granted a permission to put the device in touch explore mode. The fix is during a database upgrade to allow allow all enabled accessibility services to toggle touch exploration provided accessibility and touch exploration are enabled and no services can toggle touch exploration. Note that the user has already manually enabled the services and touch exploration which means the she has given consent to have these services work in touch exploration mode bug:6996354 Change-Id: I0af2dc578cc4fbcc90043341035163b876978ab2
generated by cgit v1.1 at 2025-03-29 01:48:06 +0000