diff options
| author | Christopher Tate <ctate@google.com> | 2015-02-17 12:15:25 -0800 |
|---|---|---|
| committer | Christopher Tate <ctate@google.com> | 2015-03-16 16:24:28 -0700 |
| commit | 6597e3435f8abfedbb9a4f1bfb10cc17ea7f38bf (patch) | |
| tree | 206ce9f7b2f09470356ebbb6bca7a16eec243707 /core/java/android/provider | |
| parent | dc16e24afcffef742bc48ac1047ad48e928d3489 (diff) | |
| download | frameworks_base-6597e3435f8abfedbb9a4f1bfb10cc17ea7f38bf.zip frameworks_base-6597e3435f8abfedbb9a4f1bfb10cc17ea7f38bf.tar.gz frameworks_base-6597e3435f8abfedbb9a4f1bfb10cc17ea7f38bf.tar.bz2 | |
Notification listener backup & restore
We now back up & restore the set of enabled notification listeners. Post-
restore, a listener that had been enabled on the ancestral device will be
enabled on the current device as soon as it's installed, matching the
user's previous configuration. After this has happened the enable/disable
state for that app is not "sticky"; disabling it again will work as
expected.
The infrastructure for accomplishing this is general: it can be leveraged
by any ManagedServices derivative. There's a bit of extra wiring in the
settings provider to support the restore-time information flow as well.
This is because ManagedServices -- like many other parts of the system --
monitors writes to the settings provider and does work in response to new
writes of the elements that it cares about. Unfortunately this means that
there is no way to use the BackupAgent's restoreFinished() hook to post-
process the restored data: by the time it is run, the ManagedService's
observers have already executed and culled any unknown components from
the description that was just pushed into settings.
As of this patch, the settings provider's restore logic knows that a
particular settings element will require a message to interested observers
about the restore-driven change. The message is delivered as a broadcast,
and is sent after the new value has been committed to the settings db.
Adding other system ManagedService handling that parallels this will only
require adding a new corresponding entry to the table of individual settings
for which the relevant "this settings element is being restored" broadcast
is sent, found in SettingsHelper.
(It isn't sent for all settings elements because very few settings elements
have semantics that require it; 3rd party code won't be running yet during
platform restore anyway; and sending up to hundreds of broadcasts during
setup & restore is far from ideal.)
Bug 19254153
Change-Id: Ib8268c6cb273862a3ee089d2764f3bff4a299103
Diffstat (limited to 'core/java/android/provider')
| -rw-r--r-- | core/java/android/provider/Settings.java | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/core/java/android/provider/Settings.java b/core/java/android/provider/Settings.java index 4c452aa..bb0959e 100644 --- a/core/java/android/provider/Settings.java +++ b/core/java/android/provider/Settings.java @@ -5374,6 +5374,7 @@ public final class Settings { ACCESSIBILITY_SCRIPT_INJECTION, BACKUP_AUTO_RESTORE, ENABLED_ACCESSIBILITY_SERVICES, + ENABLED_NOTIFICATION_LISTENERS, TOUCH_EXPLORATION_GRANTED_ACCESSIBILITY_SERVICES, TOUCH_EXPLORATION_ENABLED, ACCESSIBILITY_ENABLED, |