| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Change-Id: I61591ecfb78bae60091771b015e0898570f55abe
Auto-generated-cl: translation import
|
|\
| |
| |
| |
| | |
* commit '5d05a24cff5be83dc7b03deccfb7f52b0066b34e':
Fix wifi disable during restore
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The main looper needs to run freely for a moment after disabling
wifi in order for various signals (content observers, broadcast) to
propagate to all the listeners that need to take action for the
wifi stack to shut all the way down. This patch breaks up the
disable-and-rewrite-config sequence of wifi AP restore in to two
distinct operations separated by a moment so as not to block those
necessary messages.
Bug 22979342
Change-Id: I271766cad0e454669a194652fb67f835bb022cd1
|
|\ \
| |/
| |
| |
| |
| |
| | |
the config" into mnc-dev
* commit 'c376afb472d1d4f0fba4a03ac4cf05b498866d64':
Wait a bit longer for wifi to shut down before rewriting the config
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We've seen case of it taking longer than 1500ms for the wifi system to
actually shut down after the triggering settings element is written,
so extend the wait time a bit. We've seen it take more than 1500ms
but not more than 2500ms, so that's the new heuristic.
This will of course all become happily obsolete once we start
applying restored AP definitions programmatically rather than by
filesystem-level operations.
Bug 22979342
Change-Id: I6acf1baac23d4100124093128b82abf242b11a0e
|
|\ \
| |/
| |
| |
| | |
* commit 'ac8c98614cb8260615795b2042699d93b21a1097':
Notify settings URI change without a lock held
|
| |
| |
| |
| |
| |
| | |
bug:22469552
Change-Id: Ie4a42ceef07e3a8e593fe2b1374420239242ce7b
|
|\ \
| |/
| |
| |
| |
| |
| | |
(framework services perm check changes)" into mnc-dev
* commit 'a6706627a9bf749cc591605272810e03983a9eea':
Bug: 21589105 Rescope WRITE_SETTINGS permission (framework services perm check changes)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
changes)
AppOpsManager:
Changed the default operating mode for WRITE_SETTINGS to MODE_DEFAULT from
MODE_ALLOWED.
packages/SettingsProvider:
We no longer do static permission checks for WRITE_SETTINGS in early checks and
defer that to app op when MODE_DEFAULT is returned. For some operations,
checking against WRITE_SECURE_SETTINGS is sufficient.
ActivityManagerService & PowerManagerService:
Incorporated app op checks and handled the MODE_DEFAULT case.
provider/Settings:
Added helper function to do checks on whether app ops protected operations
can be performed by a caller. This includes checks for WRITE_SETTINGS and
SYSTEM_ALERT_WINDOW.
Also added a public API (with javadocs) for apps to query if they can modify
system settings.
Changed the javadocs description for ACTION_MANAGE_WRITE_SETTINGS and
ACTION_MANAGE_OVERLAY_PERMISSION.
Added public API (with javadocs) for apps to query whether they can draw overlays or not,
and also javadocs description on how to use that check.
Change-Id: I7b651fe8af836c2074defdbd6acfec3f32acdbe9
|
|/
|
|
|
| |
Change-Id: Ie86135b25283948fc05f3e0d412c43546e2a743b
Auto-generated-cl: translation import
|
|\ |
|
| |
| |
| |
| |
| | |
Bug: 22756856
Change-Id: If97e0faead995fb95893a128c1890b61bbe86ce5
|
| |
| |
| |
| |
| | |
Change-Id: I54d30125585b48fa3d419a991802ce6152b9cbcd
Auto-generated-cl: translation import
|
|/
|
|
|
|
|
|
|
|
| |
In SettingsProvider, for settings that are cloned from the parent
to the profile:
When the parent value is changed, notify ContentObservers in the
profile as well.
BUG:21414456
Change-Id: Ie0560d1332174499d067db9978553843b640a161
|
|\ |
|
| |
| |
| |
| | |
Change-Id: I717e8b87eccbedf1a1abead77e7856a2aa2405fa
|
|\ \
| |/
|/|
| | |
mnc-dev
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Permission checks are enforced within the SettingsProvider specifically
for SECURE/SYSTEM/GLOBAL. Now WRITE_SETTINGS is runtime, so it shouldn't
apply to all the settings types.
Bug: 22044704
Change-Id: I9ed25d96b2fa4f46d3d049efa4300cd1d37bbd24
|
|/
|
|
|
|
|
|
|
|
|
| |
The system settings permission is going away and the user will
be able to choose which apps have access to system settings in
the UI. So, if an app is white-listed by the user or being on
the system image, we allow access to system settings. Also if
the caller has the stronger write secure settings permission
we allow changes of the less sensitive system settings.
Change-Id: I7aca958fd0ad2c588117b8c6e44d78eb16d648bc
|
|
|
|
|
|
|
|
|
|
|
| |
Now a text value will be written to "value" but a binary value will be encoded
in base64 and stored in "valueBase64".
A null value will have neither value nor valueBase64.
Bug 20202004
Change-Id: I1eae936ff38e3460dc76ca20cc38f8d7e5ec6215
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
No longer needs this as carrier config manager handles it now.
Bug: b/21347654
Change-Id: I26d34cde0d31ae53a6e5a25cd555ed2ff7600f38
|
|/
|
|
|
| |
Bug: 20070414
Change-Id: I15d5d2ae27a7892807221421778082e0f29a36ff
|
|\ |
|
| |
| |
| |
| |
| |
| | |
21280155
Change-Id: I354ebac8fc91d8f28eec6016474a9521ff2a490d
|
|/
|
|
|
| |
Change-Id: I6fbaa6bb785894851b344f414fe5c8f830adbde3
Auto-generated-cl: translation import
|
|
|
|
|
|
| |
bug:20443441
Change-Id: I704520b75f5deaeeb1b4098cda0783c667e8cdd1
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Change-Id: Ie70f9077c3e51b08528ca37c3614b065ab44c68b
Auto-generated-cl: translation import
|
|
|
|
|
| |
Bug: 16875464
Change-Id: Ic1ad910dd38acbc68ef040b2acdf3696ec2c2e4e
|
|
|
|
|
| |
Bug: 20886649
Change-Id: I79d0b4a31eb9d54c5e5d4cd80236fdb8340dfeb2
|
|
|
|
|
| |
Change-Id: I3ceb55bbf8af3bae4922724c7afb0f503f806349
Auto-generated-cl: translation import
|
|
|
|
|
| |
Bug: 18931518
Change-Id: Ib03f37df9135f0324a998c62d165d8eea46328c8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
| |
Change-Id: Ic375b06aab79b9b7d17754eba4dd9d182a669734
Auto-generated-cl: translation import
|
|
|
|
| |
Change-Id: I3bbbc3159930d80e2e1f28fa9c0035ae5029d4b8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
Adds:
- Communication to GKService
- password upgrade flow
- enroll takes previous credential
Change-Id: I0161b64642be3d0e34ff4a9e6e3ca8569f2d7c0a
|
|
|
|
|
|
|
|
|
| |
Will eventually be used by SystemUI and/or Settings.
Also fix SettingsProvider NPE.
Bug: 19993667, 19909433
Change-Id: Ie326849ac5f43ee35f728d9cc0e332b72292db70
|
|\ |
|
| |
| |
| |
| | |
Change-Id: I650ff827bc31eacff2efcdba84e6ef41016ad51c
|
| |
| |
| |
| | |
Change-Id: I222bac482a843112ae031b00c83e3765ea6b456c
|
|/
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Change-Id: I0acc044f88445fe6d48f84bcaee6a971409ad144
Auto-generated-cl: translation import
|
|
|
|
|
|
| |
This reverts commit d289e64a2d7c8efba78b9066b647ee321eba701a.
Change-Id: Ic9455b538e0be8b9a4e4672f99b14978e70d2911
|
|
|
|
|
|
|
|
|
|
|
| |
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
|