Passing null to XmlPullParser.setInput forces it to do additional
work, which can be easily avoided if we know the charset beforehand.
bug: b/20849543
Change-Id: Iaff97be9df2d0f99d7af8f19f65934439c9658e2
Legacy apps can write their own entries in the system settings and
when they get uninstalled these are hanging around forever polluting
the settings table. We keep track of which settings an app added and
when the app is uninstalled we drop its custom entries. The trouble
was that we did the same thing for global and secure settings with
no explicit list of platform defined settings. Hence, if say a test
signed by the platform certificate touches platform defined global
or secure settings and is then uninstalled, we would drop the platform
defined entries portentially crippling the system.
bug:20113160
Change-Id: Ia21694f6326ad4a1795c4666027b366e26c05a23
(cherry picked from commit b128540dc741c424d4f652419686882b7a3bfa06)
When writing critical state to XML an excpetion can lead to creating
a malformed XML that is later parsed and may put the device in a bad
state. Hence, on any error while writing we should bail out and drop
the partially write state on the floor.
Corollary, any error on parsing can lead to having a partially read
state that is not consistent which may lead to writing this bad state
back to disk. Hence, on any error while parsing we should bail as
our current state may be unrecoverable.
Change-Id: Ia050c16198cb583f8a51263ad2035dbb948052b8
Will eventually be used by SystemUI and/or Settings.
Also fix SettingsProvider NPE.
Bug: 19993667, 19909433
Change-Id: Ie326849ac5f43ee35f728d9cc0e332b72292db70
The practice in the system server is to have lenient parsing code
to avoid the whole system being unusable due to a single XML error.
Change-Id: Idf44031edf5221966f3352ca2f83e284973ab95f
The restored set of enabled IMEs/subtypes is merged into the
current state of the system, rather than simply replacing it.
This is because we do not want to accidentally disable or
reconfigure something that the user is currently relying on.
There's a certain amount of repetitive activity here, rebuilding
the enabled-state data structures in a different format, but it's
important for maintainability that the restore code be able to
rely on the core InputMethodUtils implementation of reading/writing
the settings element.
Bug 19822542
Change-Id: If0104151b3526da6ecc669adde3119a239ecafeb
We do not want to accidentally disable the user's currently-enabled
accessibility service(s); presumably they turned them on during
setup for a reason. We now merge the prior + current states rather
than simply replacing the current state with the former.
Bug 19427367
Change-Id: I96eb47df57318c88066c5da6862f23f656639148
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
We were doing the work for persisting settings on a background
priority thread and as a result persistence was not happening
correctly on a low end devices. Now we use a worker thread with
normal priority.
bug:19611897
Change-Id: I378c6e324935f5e3def8b986bd48486bfab55265
A previous change added more whitespace to settings_global.xml to
improve human readability, but the parser is overly picky in ignoring
whitespace. This patch makes it accept all whitespace strings.
Bug: 19696812
Change-Id: I3ebb8f6df2e25f4e6b6841da743be3f3a91e2442
Backup the owner info string and whether or not
owner info is to be shown on the lockscreen.
Watch for changes to the two settings in LockSettingsService
and inform backup manager.
Bump up version numbers for the new entity.
Bug: 19300363
Change-Id: I35485c961d18b26be68873f4d5eeedc5ae513cc8
Settings provider has special handling for location providers. The
code to set the location providers was calling itself recursively
instead of updating the setting value.
bug:19361236
Change-Id: I1ef1932c7faa8226b52123aa3f23f38048258328
