| 97e5130234bcdc1c4a705be4e548302934499bd4 |
|
16-Aug-2017 |
Svetoslav Ganov <svetoslavganov@google.com> |
Properly compute default and system set flag on an upgrade
We added the notions of a default value and whether this default is set
by the system for a setting which is needed for experiments since in
case a bad value is pushed we should be able to incrementally rollback
to a stable state. If a system component sets a setting value this
automatically becomes the default. System components are the platform
package, the special UIDs (telephony, etc), apps singed with the
platform cert, system installed persistent apps, and SUW.
In N we did not have the notion of a default and during an upgrade need
to adjust the default and whether this default is set by the system.
This migration runs as the system UID and was incorrectly computing that
the package that changed the settings last was a part of the system and
setting the current value as its default set by the system. This
resulted in taking more storage space as we also count the default which
led the package which changed the setting to go over the quota and that
throws. If the first caller into the settings provider is the system
main
thread (almost certain) we end up throwing an exception on the system
main thread - crashing the system server.
Test: flash N, install an app abusing sys settings, update to O
Merged-In:I8e2c578cb564b2bc2de7c793eb40dea2639fa04e
bug:64718888
Change-Id: I82f0d52fd7984fb2d0da1fd91399a0c914dfa24b
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| f42dd913563e7022d7c9b499b473825fa5340b65 |
|
06-Jun-2017 |
Mark Rathjen <mrathjen@google.com> |
Update Android ID (SSAID) to exclude package name in generation.
Test: GTS tests pass, manual testing
Bug: 62135316
Change-Id: Ia42bb79a017fc6c784c13d02ee48437d0acc7835
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| b569eedf377fb0339a979d938839e99a735c3013 |
|
11-May-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Adding a new config and Setting for WiFi Wakeup." into oc-dev
|
| 45caa2538e1ef829dc2ac2d154485685d49266e8 |
|
04-May-2017 |
Jeremy Joslin <jjoslin@google.com> |
Adding a new config and Setting for WiFi Wakeup.
Created a new config for WiFi Wakeup (config_wifi_wakeup_available)
and defaulted it to NOT_AVAILABLE.
Also added a new global Settings constant (WIFI_WAKEUP_AVAILABLE)
and defaulted it to the value of the new config noted above.
Bug: 37987491
Bug: 38036968
Test: Built, flashed and confirmed proper config value.
Test: runtest --path frameworks/base/core/tests/coretests/src/android/provider/SettingsProviderTest.java
Change-Id: I0cdca4262a0ef473fcbbf7da8d960c41dfafb11f
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 96c99460b335c820f5c6e35707207da5f0169f6a |
|
05-May-2017 |
Svet Ganov <svetoslavganov@google.com> |
Hide from the world that ssaid is in a dedicated table
Test: manual
bug:37793918
Change-Id: I7c7405c7bd192d528f1f87095a03a2d21953dbc8
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 20e0dc38628875408e7f0e7f4f0e4c47088792d9 |
|
29-Apr-2017 |
Chad Brubaker <cbrubaker@google.com> |
Add overlay for Instant Apps Settings whitelists
Some non-platform settings may need to be exposed to Instant Apps. To
enable that config_allowed{Global,System,Secure}InstantAppSettings has
been added to supplement the hardcoded platform whitelist in Settings.
Bug: 37765840
Test: Run instant app from b/37765840
Change-Id: Ie1e9c645068db1d3d961d2f597c6ee2dfa158843
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| a6830e748dff42e91b73873fcc46d4ac5647a321 |
|
29-Apr-2017 |
Chad Brubaker <cbrubaker@google.com> |
Revert "Allow Instant Apps to read Settings defined by apps"
This reverts commit 7e794b7d22ab38713f0af9e6dabb127725f9d4c3.
Bug: 37765840
Test: builds
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 7e794b7d22ab38713f0af9e6dabb127725f9d4c3 |
|
28-Apr-2017 |
Chad Brubaker <cbrubaker@google.com> |
Allow Instant Apps to read Settings defined by apps
This is a temporary solution, in the future we will investigate adding
an API that requires the app adding a setting to specify if the setting
should be visible to Instant Apps or not.
Test: run instant app from b/37765840, see denials are gone.
Bug: 37765840
Change-Id: Ib256d375d2a07f743b360c61ed25c9857aafa36c
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 0d277a7b189c8807d142b69dd8d00b17978a49a5 |
|
13-Apr-2017 |
Chad Brubaker <cbrubaker@google.com> |
Change ANDROID_ID for Instant Apps
ANDROID_ID for Instant Apps now has the following properties:
1) per-app scoped
2) reset if the user clears the Instant App
3) remains the same if the Instant App gets upgraded to an installed
app.
Note that if the user goes instant -> installed_1 -> uninstall ->
installed_2 the ANDROID_ID at installed_1 will not be the same as
installed_2. This was deemed better than the id changing on the upgrade
step.
Test: manual
Change-Id: I532975c50049c94ff80902a897e001dd35a69f9f
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 781fdfaf5bb6bdfc6882f854e08761c5c61efeff |
|
06-Apr-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Don't call the Package Manager when holding the settings lock" into oc-dev
|
| b218e768f84ceb9c2facc43f221f2fa65f21075d |
|
06-Apr-2017 |
Christopher Tate <ctate@google.com> |
Don't call the Package Manager when holding the settings lock
The package manager sometimes has to call into the settings provider with
its own lock held in the course of processing queries, so it's vitally
important not to call into it with the settings provider's internal lock
already held.
In this case, the SSAID lazy-generation path was fetching the signatures
of the calling package from inside the settings lock. Now it doesn't.
Bug 36863412
Test: manual
Change-Id: Ic9d53397b5bddb883c5d73aff253ca280a5e93c0
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| ff35509ee9ef89f42607d1424fa6b4df8de98a90 |
|
03-Apr-2017 |
Felipe Leme <felipeal@google.com> |
Adds a config for default autofill service.
Change-Id: I4d2d8637617439c5df3f62426e9bc45a78edc2e3
Fixes: 35708268
Bug: 36790693
Test: manual verification
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 5d0922f78a549533c8fd368a363a82140728a357 |
|
27-Mar-2017 |
Stephen Chen <stewchen@google.com> |
Enable Wifi Wakeup Setting by default.
Bug: 36385983
Bug: 32913119
Test: runtest --path frameworks/base/core/tests/coretests/src/android/provider/SettingsProviderTest.java
Change-Id: I99f9aea6f85675eb1c92fe16f99755117110636a
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 71934ecb194e9e85a36858a1c52f52c7493d24d1 |
|
25-Mar-2017 |
Guang Zhu <guangzhu@google.com> |
Revert "Enable Wifi Wakeup Setting by default."
Bug: 36385983
Bug: 32913119
Bug: 36604943
This reverts commit abb947ac24b316a188965c341599973a1f7a3de9.
Change-Id: I484534dd6c24f5b2c2839781fc6a71d9e976a859
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| abb947ac24b316a188965c341599973a1f7a3de9 |
|
24-Mar-2017 |
Stephen Chen <stewchen@google.com> |
Enable Wifi Wakeup Setting by default.
Bug: 36385983
Bug: 32913119
Test: runtest --path
frameworks/base/core/tests/coretests/src/android/provider/SettingsProviderTest.java
Change-Id: Ia9205d28d7c215fd8c407560513036565e36537d
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 3945202dc861cf0cadea3dbe22ccd37a31ae055b |
|
21-Mar-2017 |
Amith Yamasani <yamasani@google.com> |
Some logging for settings reset
If settings db gets reset because it disappeared/got corrupted,
then write the Build.ID of the OTA, so we know when it was reset.
Bug: 36365648
Test: manual
Change-Id: I499a7f65f07a61c0e4651dbd046fc5b16408c09d
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 73360ab2d12645a177e8e3d860dec3407839ad76 |
|
17-Mar-2017 |
Makoto Onuki <omakoto@google.com> |
Fix deadlock between activity manager and settings provider
Test: manual
Bug 36028906
Change-Id: I20344608d79d174b468506056789c04d3bde510f
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| f0fa8534c65c200936fa2f3ed5c4ea0b29bd3093 |
|
23-Feb-2017 |
Chad Brubaker <cbrubaker@google.com> |
Always use calling uid for package lookup.
Change-Id: I61949aa4a261d6cd18d7c9878a29dc40364afac0
Fixes: 35656125
Test: `adb shell settings list global`
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 1991f5723070d9464c06f2bb8dc6bf3a2432f9fd |
|
03-Mar-2017 |
Alex Klyubin <klyubin@google.com> |
Restrict access from apps to bluetooth_address setting
BluetoothManagerService for some reason leaks the Android's Bluetooth
MAC address via Settings.Secure which is normally readable by all
apps. This lets apps bypass the restriction on access to Bluetooth MAC
address from apps.
This commit fixes the issue by restricting access to bluetooth_address
secure setting (Settings.Secure). Only packages which hold the
android.permission.LOCAL_MAC_ADDRESS permission retain access.
This commit accordingly grants LOCAL_MAC_ADDRESS permission to the
system Shell app because a number of scripts (including Android CTS)
use "adb shell settings get secure bluetooth_address" as a convenient
way to query the device's Bluetooth MAC address over ADB. This is
acceptable because the user of the device can see the Bluetooth MAC
address and thus it's fine for shell to be able to see the address as
well.
Test: See CTS test added in the cts project in this topic.
Test: "adb shell settings get secure bluetooth_address" returns the
Bluetooth MAC address of the Android.
Test: "adb shell settings list secure | grep bluetooth_address"
returns the Bluetooth MAC address of the Android.
Test: Bluetooth works (toggling off/on, pairing, file transfer)
Bug: 33701414
Change-Id: I17b110b96eb3794b25c1661e93d29a7a003e3c9a
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 28a7194d2584665287c7b628422bf4633d7e657b |
|
23-Feb-2017 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Ensure default and system set bits grandfathered"
|
| 137015599e666b0a6dc5bfd696025ad61b17d6c7 |
|
23-Feb-2017 |
Svet Ganov <svetoslavganov@google.com> |
Ensure default and system set bits grandfathered
We added the notion of a default and whether the system set
the setting. This is used for resetting the internal state and we need
to make sure this value is updated for the existing settings, otherwise
we would delete system set settings while they should stay unmodified.
Test: manual
bug:35317326
Change-Id: Iaffde2e7acab53653fd38e669a644e654cc7cd7d
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 798cccb659321dc60ef4dab87e64834b6c891620 |
|
23-Feb-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Don't copy ringtones when profile sync goes off"
|
| 7af9a7443162d78ea6b1df5fc7a6362d7e6e72b5 |
|
20-Feb-2017 |
Robin Lee <rgl@google.com> |
Don't copy ringtones when profile sync goes off
Experimentally, it makes more sense to more people to have the parent
setting as an overlay not a concrete thing.
Test: make cts -j30 && cts-tradefed run cts --module CtsDevicePolicyManagerTestCases --test 'com.android.cts.devicepolicy.ManagedProfileTest#testRingtoneSyncAutoDisableRingtone' </dev/null 2>&1
Bug: 34730524
Change-Id: I5f804713def9e54921b90e4f5cea742ba8aaa685
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| ad0d9e0157ba5fc890be2712104819064e298b3c |
|
15-Feb-2017 |
Julia Reynolds <juliacr@google.com> |
Grant notification listener access to overlay pkgs
Test: manual
Change-Id: I935b701507cd8eafec991b03ac67364e9830d757
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| fb924fa981f79dac7719a35b63fcfae81bdd421a |
|
22-Feb-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Fix 'Modifying dpm.setSecureSetting call for install_non_market_apps'"
|
| 0b1356ff1f3cd2fd06d770af1ad466822173cc3a |
|
21-Feb-2017 |
Suprabh Shukla <suprabh@google.com> |
Fix 'Modifying dpm.setSecureSetting call for install_non_market_apps'
The previous change was reverted as it broke work profile provisioning.
Clearing binder calling identity before calling into settings provider
should fix the issue.
Test: runtest managed-provisioning
Test: runtest -x services/tests/servicestests/src/com/android/server/devicepolicy/DevicePolicyManagerTest.java
Test: Manually tested that work profile is inflated with expected values
of install_non_market_apps
Bug: 33947615
Bug: 35590590
Change-Id: I3c31a73fef0c25c0e682e18f637272adad39b28d
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| d2876544fb5e09cafc571e95c68abbb8d676ecdc |
|
22-Feb-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Deprecate "speak passwords" setting."
|
| 385912ee2d78e0e557704cfd5f8c7dbe2b7fd280 |
|
10-Feb-2017 |
Phil Weaver <pweaver@google.com> |
Deprecate "speak passwords" setting.
This will now be controlled by individual accessibility services.
We'll provide the password information to them, and they can
present or hide the information as it makes sense for their users.
Password information was anyway provided when a headset was
connected.
Bug: 28139568
Test: Manually verified that TalkBack now speaks passwords on the
lock screen and in text views. Since I'm removing functionality
that didn't have tests, it's tricky to have specific tests.
Change-Id: Ic3c724ccce5762ee9dcd9e7dcbd4eae6734dd05e
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| cac64f616feeef06e497613b8d2aa8ce5ce50509 |
|
21-Feb-2017 |
Svetoslav Ganov <svetoslavganov@google.com> |
Handle location enabled setting null value
We have the notion of a null value object whose internal
value is null. If it happens that the setting was never
populated we get back the null object whose value is null
and the code does not expect null and crashes.
bug:35368238
Test: manual
Change-Id: I02c3771b94a45b4ee53e2141711eed134542ea0c
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 3ed1b905c4f9eae2444d720ea3501c0ab0c65cb7 |
|
20-Feb-2017 |
Chad Brubaker <cbrubaker@google.com> |
Merge "Use requesting userId for ApplicationInfo lookup"
|
| 5663e051099cdf442bc3316a88e1a7600c58aaaa |
|
20-Feb-2017 |
Victor Chang <vichang@google.com> |
Revert "Modifying dpm.setSecureSetting call for install_non_market_apps"
This reverts commit 2e7d6d64b9b16ea27634bc0e8843717a465142b4.
Bug: 35590590
Fix: 35590106
Test: runtest managed-provisioning
Test: manual verified that work profile can be inflated
Change-Id: Ie780b94053e65bca2f96b32055937c0c9e8beae8
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 7fe0a5ac562d6063b6562ccc5fc5877da9a86e17 |
|
18-Feb-2017 |
Chad Brubaker <cbrubaker@google.com> |
Use requesting userId for ApplicationInfo lookup
Change-Id: I4f29f31e48d66d16181fb415fd864de2746def94
Fixes: 34771610
Test: runtest --path
frameworks/base/services/tests/servicestests/src/com/android/server/pm/UserManagerTest.java
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| dd903d4f0ee4cebcef03e54f5b07f4bcc14c5dbc |
|
18-Feb-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Modifying dpm.setSecureSetting call for install_non_market_apps"
|
| 2e7d6d64b9b16ea27634bc0e8843717a465142b4 |
|
10-Feb-2017 |
Suprabh Shukla <suprabh@google.com> |
Modifying dpm.setSecureSetting call for install_non_market_apps
Starting from O, install_non_market_apps is deprecated and will not be
checked by the package installer. Device admin apps should be using the
user restriction instead.
Since on managed profiles, the default value blocked install from
unknown sources, the system will set the user restriction on behalf of
the profile owners (if the profile has one).
For non-managed profiles, the user had access to the settings to change
the value of install_non_market_apps. So going forward, any request to
change it's value by dpm#setSecureSetting in such users is going to be
ignored.
Test: Manually tested that:
1. For a profile with PO, when install_non_market_apps was set to 0,
user restriction is set on upgrade
2. For a profile with PO, when install_non_market_apps was set to 1,
user restriction is not set on upgrade
3. After upgrade, newly created managed profiles with PO have user
restriction set
Bug: 33947615
Change-Id: I063e9ee608b52086ffdf8ed2b24e2928574c58cd
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| be0b8896d1bc385d4c8fb54c21929745935dcbea |
|
15-Feb-2017 |
Todd Kennedy <toddke@google.com> |
Revert "Revert "Per user setting for instant app""
This reverts commit be9ffa15af9e1906e9ffb505768328d62d4a3793.
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.EphemeralTest
Change-Id: Ib21321cf157a79890de487060a093840f7182047
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 27d14c46a7528194d5eda468ac16837933f0fe18 |
|
15-Feb-2017 |
Jeremy Joslin <jjoslin@google.com> |
Define a new config key for the recommendation provider app.
Created a new config key and removed the previous key that
was defined in default.xml. Also removed the SettingsProvider logic
as we'll set the default in NetworkScoreService in a follow-up CL.
Bug: 35095406
Test: build and install.
Change-Id: I2893be31fd526af8a66d6d1b7d8978adf7e32c0f
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| be9ffa15af9e1906e9ffb505768328d62d4a3793 |
|
15-Feb-2017 |
Guang Zhu <guangzhu@google.com> |
Revert "Per user setting for instant app"
Bug: 35390781
This reverts commit 2f5811dcfd840e149851a9333e27ef3cdddf7a46.
Change-Id: Ibb1c8dacbdc6908fc7fa2bc5dca664f2455162bf
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 2f5811dcfd840e149851a9333e27ef3cdddf7a46 |
|
30-Jan-2017 |
Todd Kennedy <toddke@google.com> |
Per user setting for instant app
The same application can run as either an instant app or an installed
app. Store this setting per-user instead of based upon the install
location.
Bug: 25119046
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.EphemeralTest
Change-Id: Iff565bb1ac10d631499f0bd0f69b401cb073c10e
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| c9eb3c46511a80a7ad9d297d232c579886d55a97 |
|
08-Feb-2017 |
Jeremy Joslin <jjoslin@google.com> |
Add a new setting to store the network recommendation app.
Test: manual
Bug: 35095406
Change-Id: I3d0b7f3b977c0862969d61a4e46f12151eb15417
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| e3745eed8b9599de6f413d48a81098209fd41791 |
|
03-Feb-2017 |
Suprabh Shukla <suprabh@google.com> |
Deprecating secure setting install_non_market_apps
Apps targetting Android O or higher should use the new api
canRequestPackageInstalls in package manager. The secure setting
INSTALL_NON_MARKET_APPS which was used is set to 1 to make the
change transparent to apps who are already querying for this setting's
value.
Test: adb shell am instrument -e class\
'com.android.providers.settings.InstallNonMarketAppsDeprecationTest' -w\
'com.android.providers.setting.test/android.support.test.runner.AndroidJUnitRunner'
Bug: 33947615
Change-Id: Ie38d130bfccd022483a566270fce071acbdb00b7
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 096d304ae3d85c1bfcda1a1d9cd4eb13d0815500 |
|
31-Jan-2017 |
Svetoslav Ganov <svetoslavganov@google.com> |
Add instant cookie APIs
This change adds APIs for instant apps to store cookie data
that is presisted across instant installs and across the
upgrade from an instant to a standard app. Standard apps
can use the cookie APIs but when they are uninstalled the
cookie is also deleted. The cookies are kept longer than
the instant apps as they are much smaller - 16KB by default.
We can change the cookie size via a system setting i.e.
after we ship we can increase size if needed.
We also add internal APIs to surface information about
installed and uninstalled instant apps which should be
used for showing them in the UI. For this puporse we store
the icon, permissions, and label of uninstalled apps. If
the app is re-installed we drop this meta-data but keep
the cookie around. If we have cookie data stored and the
signing cert of the app changes when it gets re-intalled
we wipe the cookie.
Test: CTS tests pass; hiddent APIs tested manually
Change-Id: If145c0440cc61a5303e2cbb70228d235d36037a5
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 5fb405ba60dc6daca54d507909b68b5ad8144920 |
|
27-Jan-2017 |
Svetoslav Ganov <svetoslavganov@google.com> |
Ensure settings provider joins the rescue party
The settings provider has logic to incrementally reset state
in an effort to recover from pushing a bad value putting the
system in a bad state. The settings provider was not force
persisting its state after a reset so after the reboot we
lost the reset changes. Also while resetting we were also
resetting the package name leading to a promotion of the reset
value to being set by the system. Updated the tests and while at
this added logic to synchronously persist critical settings
such as device provisioned.
Test: All tests pass. Manually tested end-to-end rescue party
bug:34677175
Change-Id: Ib240072df2fa549dae39c301008adf48cdf1573a
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 8bd8564a18c5fefb4299610a09a55c5e633c5e38 |
|
25-Jan-2017 |
Mark Rathjen <mrathjen@google.com> |
Merge "Resolve Android security comments for Android ID migration."
|
| 7599f1366e8a08781f415e73f65cf270aae36868 |
|
23-Jan-2017 |
Mark Rathjen <mrathjen@google.com> |
Resolve Android security comments for Android ID migration.
- Use 32 byte key instead of 16 byte.
- Use HMAC-SHA256 instead of SHA256 for ssaid generation.
- Update HMAC with all package signatures.
- Use delimiter in between digest arguments.
This change will cause the ssaid of non-legacy installed apps (apps installed
post Android ID migration OTA) to change after an uninstall and reinstall sequence.
Bug: 34395671
Test: Unit tests, CTS tests, Manual tests
Change-Id: I19dec57947368ee5000c2c630b1e4030d46a4ab3
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| d72c39709d2f0a850dc32544324bfe4729ce81c6 |
|
28-Dec-2016 |
Eugene Susla <eugenesusla@google.com> |
Add ability to dump settings as proto buf
Test: Extracted the result via proto bug and as text and compared,
ran new CTS Setting incident test
Change-Id: Icf7b54b9c5c0a613dfd413ad575001c7b637ca01
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 6ba5dccd50d098d8ae1c5fac8e83be7f61c70018 |
|
20-Jan-2017 |
Chad Brubaker <cbrubaker@google.com> |
Merge "Add ephemeral whitelist for SettingsProvider"
|
| 97bccee6d640a62c78676b5e2a1eb3bbe29072af |
|
06-Jan-2017 |
Chad Brubaker <cbrubaker@google.com> |
Add ephemeral whitelist for SettingsProvider
Currently the list is small, only whats required to launch a basic
ephemeral app. It will expand in followup CLs.
Note that the goal of this is not to completely shut down all ways that
an ephemeral app could learn the value (or part of) of a setting not in
the set. The goal is to limit the raw access to settings to a small set that
includes settings that ephemeral apps should have access to directly
System APIs that are exposed to ephemeral apps may allow for
ephemeral apps to learn the value of settings not in the directly
exposed set and that is OK and _not_ a security issue.
This contains a hack to support code in system system server that in
the process of a binder transaction reads a setting using a
ContentReceiver with a system package name. This was previously not an
issue but causes an exception to be thrown from getCallingPackage which
reading a setting now calls.
Bug: 33349998
Test: Boots, functions as normal for regular apps.
Test: cts-tradefed run cts -m CtsProviderTestCases -t
android.provider.cts.SettingsTest
Change-Id: Icc839b0d98c725d23cdd395e8cb76a7b293f8767
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| ea617597c78e3a28304a85cfb3f790e1e36bca76 |
|
19-Jan-2017 |
Mark Rathjen <mrathjen@google.com> |
Fix NPE in SettingsProvider.
Bug: 34387347, 34396959, 34395671
Test: CTS tests passed, Manual testing passed
Change-Id: I333dfba05f9a4706af22b850b8a010cf391350fc
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| d891f01d96cbaa3b1329c3d476084f3fedb30a89 |
|
19-Jan-2017 |
Mark Rathjen <mrathjen@google.com> |
Roll forward SSAID Migration to be Per App/User Unique Values.
SSAID is currently shared across all applications for each
user on the device, giving developers the ability to track
users across multiple applications. Using SSAID for tracking
is an abuse of the original intention of the SSAID and has
inherent privacy concerns.
This change will make the SSAID unique per application, per
user on a device. To not affect applications installed prior
to this change they will retain the legacy SSAID value until
uninstalled and reinstalled again.
Across subsequent installations the application will receive
the same SSAID as long as the package name and signature remain
consistent.
Tested manually the following cases:
- App retains the legacy sssaid after OTA.
- App gets a new ssaid upon post-OTA installation.
- App retrieves same ssaid across post-OTA unistall/reinstalls.
- Different Apps receive different ssaids.
- Factory reset removes ssaid data and generates a different
ssaid after App install.
- System retains legacy ssaid.
Bug: 34395671
Test: CTS tests passed, Manual testing passed
This reverts commit be43257005d086ff7d93c15dae22ac40bc0d545e.
Change-Id: Ibf20e7949304c30d65bb8aa24cdbbe6e104b1002
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| be43257005d086ff7d93c15dae22ac40bc0d545e |
|
19-Jan-2017 |
Mark Rathjen <mrathjen@google.com> |
Revert "SSAID Migration to be Per App/User Unique Values."
This reverts commit 5514fb7aba781d8eabbbfc27a5d27a6b3a447b40.
Change-Id: I0d6b9b9ef3ecda3b7ec1b7160c492ec16c65b125
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 5514fb7aba781d8eabbbfc27a5d27a6b3a447b40 |
|
12-Jan-2017 |
Mark Rathjen <mrathjen@google.com> |
SSAID Migration to be Per App/User Unique Values.
SSAID is currently shared across all applications for each
user on the device, giving developers the ability to track
users across multiple applications. Using SSAID for tracking
is an abuse of the original intention of the SSAID and has
inherent privacy concerns.
This change will make the SSAID unique per application, per
user on a device. To not affect applications installed prior
to this change they will retain the legacy SSAID value until
uninstalled and reinstalled again.
Across subsequent installations the application will receive
the same SSAID as long as the package name and signature remain
consistent.
Tested manually the following cases:
- App retains the legacy sssaid after OTA.
- App gets a new ssaid upon post-OTA installation.
- App retrieves same ssaid across post-OTA unistall/reinstalls.
- Different Apps receive different ssaids.
- Factory reset removes ssaid data and generates a different
ssaid after App install.
- System retains legacy ssaid.
Bug: 30979321
Test: CTS tests passed, Manual testing passed
Change-Id: I4acc190c14ec249e6365e05e7943148ed6f17f71
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| e080da9ee027fcd030aa92ea26fd0ed9f031674f |
|
22-Dec-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Settings recovery support
This change allows the system to perform iterative reset
of changes to settings in order to recover from bad a
state such as a reboot loop.
To enable this we add the notion of a default value. The
default can be set by any package but if the package that
set it is a part of the system, i.e. trusted, then other
packages that are not a part of the system, i.e. untrusted,
cannot change the default. The settings setter APIs that
do not take a default effectively clear the default. Putting
a setting from a system component always makes it the
default and if the package in not trusted then value is
not made the default. The rationale is that the system is
tested and its values are safe but third-party components
are not trusted and their values are not safe.
The reset modes from the least intrusive are: untrusted
defaults - reset only settings set by untrusted components
to their defaults or clear them otherwise; untrusted clear
- clear settings set by untrusted components (or snap to
default if provided by the system); trusted defaults - reset
all settings to defaults set by the system or clear them
otherwise.
Also a package can reset to defaults changes it made to
the global and secure settings. It is also possible to
associate a setting with an optional token which can then
be used to reset settings set by this package and
associated with the token allowing parallel experiments
over disjoint settings subsets.
The default values are also useful for experiment (or
more precisely iterative tuning of devices' behavior in
production) as the stable configuration can be set to
the "graduated" safe defaults and set the values to the
experimental ones to measure impact.
Test: tests pass
Change-Id: I838955ea3bb28337f416ee244dff2fb1199b6943
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 8bdad345ccb834aceff725272c8d32f81b36fc13 |
|
14-Dec-2016 |
Jeremy Joslin <jjoslin@google.com> |
Migrate the NETWORK_SCORER_APP to NETWORK_RECOMMENDATIONS_ENABLED.
If NETWORK_SCORER_APP has a non-null value then enabled
NETWORK_RECOMMENDATIONS_ENABLED.
Test: runtest --path frameworks/base/packages/SettingsProvider/test/src/com/android/providers/settings/SettingsProviderTest.java
BUG: 32913919
Change-Id: Ibea34f0a17539e9c583898dc336f807f92b33c54
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| a46f009bbfc693319290c273b4e647dea2eebe10 |
|
04-Nov-2016 |
Phil Weaver <pweaver@google.com> |
Merge "Add tests for MagnificationController."
|
| 89e3ffc66c5a05f188ff9748b48abebc247f664b |
|
19-Sep-2016 |
Phil Weaver <pweaver@google.com> |
Add tests for MagnificationController.
Also refactoring the class to make it easier to test and
chaning behavior where the current behavior seemed poorly
defined.
Refactoring:
- Combined all handlers into one.
- Simplified animation to use a ValueAnimator.
- Eliminated ACCESSIBILITY_DISPLAY_MAGNIFICATION_AUTO_UPDATE
setting. Move rest of settings reading into mockable class.
- Move callbacks from WindowManager into the main class.
- Pulled out my instrumented Handler from the
MotionEventInjectorTest into its own class so I can reuse
it.
Behavior changes:
- Always constraining out-of-bounds values rather than
refusing to change them.
- Constraining offsets on bounds changes. We previously
left them alone, even if they were out of bounds.
- Keeping track of the animation starting point. We were
interpolating between the current magnification spec
and the final one. This change means the magnification
animates to a different profile.
Test: This CL adds tests. I've also run a11y CTS.
Bugs: 31855954, 30325691
Change-Id: Ie00e29ae88b75d9fe1016f9d107257c9cf6425bb
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 32f40ee1a2d4185282543efe8db709e779ea2f63 |
|
21-Oct-2016 |
Dianne Hackborn <hackbod@google.com> |
Implement Binder shell command for settings provider.
The provider now published a system service, through which you
can do direct shell commands. The commands are a copy of what
the existing "settings" command does (in a follow-up, that will
be converted to a simple script that calls this).
Also improved a few things in the provider:
- Don't allow implicit creation of settings data for users that
don't exist.
- Improve dump to include the package name that applied each setting
and remove misleading stuff from historical data (and this is now
available through "dumpsys settings" instead of the provider dump).
Test: manual
Change-Id: Id9aaeddc76cca4629d04cbdcbba6a311e942dfa6
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 69741a2eb83546f55c4128699c9305a65b499e34 |
|
21-Oct-2016 |
Adrian Roos <roosa@google.com> |
Ambient: If user turned off ambient, keep it off after split
The split ambient settings default to on - which is a bad experience
if the user explicitly turned it off before the split.
Change-Id: I986d35a1a28e97f4c8d7d3d47ed5658e1836a44f
Fixes: 32332195
Test: Flash angler to NYC, disable ambient, upgrade to NYC-MR1, check if "Lift to check phone" is still off.
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| ec7a118950543dfa89cb2c85cc1c79443d93e200 |
|
18-Oct-2016 |
Keun-young Park <keunyoung@google.com> |
add default overlay for END_CALL_BEHAVIOR
- for automotive, default END_CALL_BEHAVIOR should be 0.
- automotive product should have overlay overriding it.
- default value is the same as now
bug: 31926624
Test: manual (check dumpsys window policy)
Change-Id: Ice7b3c1374dfccf8a03c13c73201fa1615acab5f
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 046249d9dcfd79e7013b9c17438849b3df910f3b |
|
27-Aug-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Store the event of settings db downgrade am: 264c7a90c7 am: f813a5a1c4
am: 11bd5718a1
Change-Id: I8831eac6d99ba00a80f6e9064b0cc09143b3f9d8
|
| f813a5a1c4e155dd238ea1661f2d0de20f959d07 |
|
25-Aug-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Store the event of settings db downgrade
am: 264c7a90c7
Change-Id: I5b9d5a9bd3c2df337776921a34960ceef8fda1ce
|
| 264c7a90c7c18acb8e884f2fcd63759a030eb141 |
|
25-Aug-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Store the event of settings db downgrade
bug:30561721
Change-Id: I8f2252bbf99603976c7efc32c54aa88b314ba815
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 3fa139c7b2fc638424955d0bb07d692f576cccb5 |
|
04-Aug-2016 |
Andre Lago <andrelago@google.com> |
[media] Separate ringtones for managed profiles
Separate the default system ringtone settings for managed profiles,
which previously used the same default ringtones as the personal profile
they belong to
Bug: 30658854
Change-Id: I22c69c7b8d31c7c424f5e00a3d9febac98b93d74
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| ea35e07e1b71dd22309baefdd1d621f6f91ad2f0 |
|
04-Aug-2016 |
Andre Lago <andrelago@google.com> |
[Settings] Added setting SYNC_PARENT_SOUNDS
Added a setting that specifies wether a managed profile's ringtones
should be the same as its parent
Change-Id: I90e20cee111640404c3758030f41d5b2b5af1c28
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| f0976121d91744ea98651de073b6eee2b55ede18 |
|
05-Aug-2016 |
Anthony Hugh <ahugh@google.com> |
Add panic detection to back button am: 96e9cc5700
am: c1de1b6dde
Change-Id: I523e7719483840c4fb4fe39827b3a6652bdc1a39
|
| c1de1b6dde21dda28176a4e0b086ad71c2c122f5 |
|
05-Aug-2016 |
Anthony Hugh <ahugh@google.com> |
Add panic detection to back button
am: 96e9cc5700
Change-Id: I60553d88e1e1c42c11dae92d35c4ad761d188fda
|
| bfacf7ce2e74b205b14fd1147e872f7c690a6c56 |
|
05-Aug-2016 |
Anthony Hugh <ahugh@google.com> |
Merge "Add panic detection to back button" into cw-f-dev
|
| c8f418b347acaeabeb87495b3627aea8e728a804 |
|
04-Aug-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Add historical logging to settings provider am: a340bfd7a1 am: ba92753043
am: 6ad9366b74
Change-Id: I2d64c7c97e6956fe5dc0011c8aefbca979f726a9
|
| a340bfd7a1e639bb50125a62cfb1a14e2565607e |
|
03-Aug-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Add historical logging to settings provider
This change adds historical operations to the dump state
of the settings provider. The historica operations are
currently appended only on user-debug and eng builds.
These change is needed to help diagnose the referred
bug and improve the settings provider's maintenance.
bug:30561721
Change-Id: I58a1ba0d598c4d28adcb5e654ebb78cf947e94db
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 96e9cc5700c63c872f29f488129daf34f95292d2 |
|
13-Jul-2016 |
Anthony Hugh <ahugh@google.com> |
Add panic detection to back button
Adds "panic" detection to the back button. Implemented solution
uses 4x button presses in a short duration to detect for "panic".
The value used to determine the duration between key up and key down
that still count as a multi-button press is configurable via the
Settings Provider.
BUG: 28027764
Change-Id: Ibf1370ff3cb539a9a54002a8704922744a3ca5d7
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 2ab02e2cb2ec09f91546edd6824dd55bf12c9554 |
|
28-Jul-2016 |
Robin Lee <rgl@google.com> |
Pass userId through to singleton ContentProviders
System content providers like SettingsProvider run as singleUser but
on receipt of a call make decisions based on the calling user ID.
This is right up until the caller is a system service or a cross-user-
-aware app like Settings, where putStringForUser etc. provide a
workaround for most settings but not for the few files SettingsProvider
exposes.
Change-Id: I90060c9c13e274edd71f8a16ab3a026a58b98e3e
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 428b3bdca87a1483dfe5fedc548a6365f3b2e328 |
|
22-Jul-2016 |
Benjamin Franz <bfranz@google.com> |
Block user from setting safe boot setting via adb am: 0ff13fce6f
am: c86e8c3442
Change-Id: Ie9e1f4d447dd61ef7f5ef191d1309377fbbf4559
|
| 36eb7a13709073111e2397c9f542cb6f64f3f2b9 |
|
22-Jul-2016 |
Benjamin Franz <bfranz@google.com> |
Block user from setting safe boot setting via adb
am: 0ff13fce6f
Change-Id: I50db586478eb52d0a2f43e9150cc663c96e5779b
|
| 71f85e91941029cb554cc4a0dc2b0e8d17b3c478 |
|
20-Jul-2016 |
Dan Sandler <dsandler@android.com> |
Decrease default longpress timeout to 400ms.
If the device being upgraded happens to have a timeout of
500ms it will be reset to 400. If the value is something
else it will be left alone upon upgrade.
Bug: 30159825
Change-Id: Ifec70e458ce0199b61d36f7504aea02b4a974990
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 0ff13fce6fa4caa0cc61dae555881c4568020327 |
|
12-Jul-2016 |
Benjamin Franz <bfranz@google.com> |
Block user from setting safe boot setting via adb
Bug: 29900345
Change-Id: Id3b4472b59ded2c7c29762ddf008ee8486009dbb
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| e293b0cd0027741222299bbad6ea365982d2b357 |
|
13-Jul-2016 |
Victor Chang <vichang@google.com> |
Disallow shell to mutate always-on vpn when DISALLOW_CONFIG_VPN user restriction is set
Fix: 29899712
Change-Id: I38cc9d0e584c3f2674c9ff1d91f77a11479d8943
(cherry picked from commit 9c7b706cf4332b4aeea39c166abca04b56685280)
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 5bd9ea82d2ab79911abadc7afbdf208f79e9d160 |
|
13-Jul-2016 |
Julia Reynolds <juliacr@google.com> |
Merge "Whitelist default apps for DND access." into nyc-mr1-dev
|
| e05b35db0d309b41edfe30e415b5fa746f7964a2 |
|
13-Jul-2016 |
Victor Chang <vichang@google.com> |
Merge "Disallow shell to mutate always-on vpn when DISALLOW_CONFIG_VPN user restriction is set" into nyc-mr1-dev
|
| 1f721e113b995012a1afd10e942f825d095c3c91 |
|
11-Jul-2016 |
Julia Reynolds <juliacr@google.com> |
Whitelist default apps for DND access.
Bug: 29606962
Change-Id: I0a94004cf08a51ab17813f99aabddbceb95ac8f0
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 9c7b706cf4332b4aeea39c166abca04b56685280 |
|
13-Jul-2016 |
Victor Chang <vichang@google.com> |
Disallow shell to mutate always-on vpn when DISALLOW_CONFIG_VPN user restriction is set
Fix: 29899712
Change-Id: I38cc9d0e584c3f2674c9ff1d91f77a11479d8943
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 3d9805d50281882b4420ee2d4ede8a8bdd94d455 |
|
07-Jul-2016 |
Mahaver Chopra <mahaver@google.com> |
Added UM.DISALLOW_OEM_UNLOCK, Removed Global.OEM_UNLOCK_DISALLOWED.
Currently we used global setting to restrict user from enabling oem
unlock. As global settings can be chagned using adb, using user
restrictions instead.
Bug: 29893399
Change-Id: Ic83112a4838b8279bf50408a29ae205e0b8639ee
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 23d729deb8d78d5806dec60453174ccfa28b843d |
|
16-May-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Use the correct handler when persisting the settings state." into nyc-dev
am: 967fcfa593
* commit '967fcfa5939403017a6edc6d365b2996b915685d':
Use the correct handler when persisting the settings state.
Change-Id: I53fea39e5097512f080f62f3510cc6c7acf87e3c
|
| 9205749cfe9c36fb740bb067805351fb8abf9c8f |
|
16-May-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Use the correct handler when persisting the settings state.
bug:28784358
Change-Id: Iba9d569bae67c7ba0c3ab0a486ae14efa84a7acf
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| e333b2eb81958cc8d27eb687ebd84844a84919ea |
|
13-May-2016 |
Steven Ng <stevenckng@google.com> |
Merge "Add a Global setting for disabling OEM unlocking setting" into nyc-mr1-dev
|
| 00749aeb15d52151fcc9f9051b525840c49e14ce |
|
12-May-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Persist settings on a dedicated background thread" into nyc-dev
|
| 83fec0069787263ce1ed2f3f75ccf2eadc67705e |
|
11-May-2016 |
Phil Weaver <pweaver@google.com> |
Fix a race in settings update.
Need to invalidate caching before notifying of changes.
Bug: 28621277
Change-Id: I2820b15d2364ecaad7666a820c0c7280ac6b7b4c
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| a8f9026d22dae7fcb385bd06ed475a5dd36993c3 |
|
10-May-2016 |
Svet Ganov <svetoslavganov@google.com> |
Persist settings on a dedicated background thread
Settings were persisted on the system background thread but during
first boot the device is under heavy load and persisting settings
competes with other system components using the shared background
thread. As a result persisting settings can be delayed much longer
than the expected 200ms. This can cause issues with setup wizard
being skipped/went over and its component disaabled being persisted
but the setting whether the device is provisioned not being
persisted - now if the device boots it will have no SUW but also
the home button would be missing. Generally, we need a tansactional
abstraction in the system process to peform all delayed operations
atomically.
bug:25472484
Change-Id: I8e0cf7ffa32e86e36e777964eb0c3cc7de02d3c3
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 5537ce1f94ef1851d316ecf029e13ef7833f6c3a |
|
10-May-2016 |
Guang Zhu <guangzhu@google.com> |
Revert "Persist settings on a dedicated background thread"
Bug: 25472484
This reverts commit 82b8c92b97d3c7006d7a9f67a9cdb83263d6bf2c.
Change-Id: I1a8c2e186ad74d78f1c82fe508c6f71c438177dc
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 82b8c92b97d3c7006d7a9f67a9cdb83263d6bf2c |
|
09-May-2016 |
Svet Ganov <svetoslavganov@google.com> |
Persist settings on a dedicated background thread
Settings were persisted on the system background thread but during
first boot the device is under heavy load and persisting settings
competes with other system components using the shared background
thread. As a result persisting settings can be delayed much longer
than the expected 200ms. This can cause issues with setup wizard
being skipped/went over and its component disaabled being persisted
but the setting whether the device is provisioned not being
persisted - now if the device boots it will have no SUW but also
the home button would be missing. Generally, we need a tansactional
abstraction in the system process to peform all delayed operations
atomically.
bug:25472484
Change-Id: Icf38e72403b190a8fa9d0554b8dd83ce78da3bc8
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| dc20ba69bf5f6e1017202555b6159abaf67b855c |
|
26-Apr-2016 |
Steven Ng <stevenckng@google.com> |
Add a Global setting for disabling OEM unlocking setting
+ By default, OEM unlocking setting is enabled.
+ Add a check to prevent oem unlock being flipped if the setting isn't
enabled.
Bug: 28163088
Change-Id: I087d8d5a1d99a611a8f66ff71a92ec9ea1da4e9f
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 83a1f7fe91816959715067987dd7f4727492f129 |
|
27-Apr-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Add a missing null object check
We now have a null object instead of null values and
there was a place where we returned null instead of
the correct null object.
bug:28423485
Change-Id: I2626768acdf8d19fc94aa5e978eb057818450fa5
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 6e5b602552b15ab95dc7b1e4e824f8da6a951fcf |
|
27-Apr-2016 |
Seigo Nonaka <nona@google.com> |
Fix unexpected null check condition flipping.
With I5a40675dd226564c0ee190d0d6f7eb2a7e4673b0, isNull() is used for
null check but accidentally the condition is flipped.
Bug:28406262
Change-Id: I776a6c259765210a7b334a81876233b594fd25ed
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 6f8a10bd14d927f9603823c06a3e53f56392ba95 |
|
27-Apr-2016 |
Svet Ganov <svetoslavganov@google.com> |
Add a missing null check
We no longer have a null settings value - instead it is a
null object. This change adds a missing null check that is
not changed to check against the null object.
bug:28406262
Change-Id: I5a40675dd226564c0ee190d0d6f7eb2a7e4673b0
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| fedb230213177e8403f3f87efadd61cff20fbbb1 |
|
27-Apr-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Replace null checks is null object checks
A recent change replaced the null state during a setting
lookup with a null object, however missed to update some
null checks to be null object ones.
bug:28405145
Change-Id: I80f0fb3ac6e64f4283b6c617283a009e97a40efe
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 53a441ca8eda5a3e6209a952b1bbd32a39e19a1c |
|
20-Apr-2016 |
Svet Ganov <svetoslavganov@google.com> |
Ensure local settings caches are not stale
We used the system proterties as a shared memory mechanism
to propagate information to local settings caches when the
content has changed and the cache should be cleared. The
system properties are unfortunately updated asynchronously
leading to cases where clients may read stale data.
This change adds a simple int array data structure backed
by shared memory which guarantees individual values are
atomically read and updated without memory tear. Multi-
index opearations are not synchronized between each other.
The settings provider is using the new data structure to
propagate the settings generation which drives when caches
are purged.
We have a single memory array keeping the generation for
different settings tables per user. Since memory array is
not a compact data structure and the user space exceeds
the memory array size we use an in-memory map from keys
to indices in the memory array where the generation id of
a key is stored. A key is derived by the setting type in
the 4 most significant bits and the user id in the 28 least
significant bits.
The mapping from a key to an index is cleared if the user is
removed and the corresponding index in the memory arry is
reset to make it available for other users. The size of the
memory array is derived from the max user count that can be
created at the same time.
bug:18826179
Change-Id: I64009cc5105309ef9aa83aba90b82afc8ad8c659
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| c9d064a380084796217d08fb459c9ecab022f596 |
|
13-Apr-2016 |
Suprabh Shukla <suprabh@google.com> |
Added null check in appendSettingToCursor
Added check for null setting before adding to MatrixCursor.
Bug: b/27908871
Change-Id: I0b71c3d5347cad705b8def98fda7e9e463c295e2
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 4c74334c4425e43dfb53bc2ef707eebb1bef7d5b |
|
11-Apr-2016 |
Fyodor Kupolov <fkupolov@google.com> |
Merge "Added getProfileIds method returning array of userIds" into nyc-dev
|
| 02ba61203e6cee1936affb9015c7857c03125079 |
|
01-Apr-2016 |
Daniel U <uda@google.com> |
Copy lockscreen notification settings upon upgrade
Copy the primary values of LOCK_SCREEN_SHOW_NOTIFICATIONS and
LOCK_SCREEN_ALLOW_PRIVATE_NOTIFICATIONS into managed profile upon upgrade.
Bug:27673591
Change-Id: I3207b7e5bf844f0df534324220082edbdabe8444
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 7f98aa4aa93497692f200c553d2d6fff402e3de2 |
|
07-Apr-2016 |
Fyodor Kupolov <fkupolov@google.com> |
Added getProfileIds method returning array of userIds
Previously many usages of UserManager.getProfiles and getEnabledProfiles
were only using ids of returned users. Given that the list of users needs
to be parceled and unparceled for Binder calls, returning array of ids
minimizes memory usage and serialization time.
A new method getProfileIds was introduced which returns an array of userIds.
Existing method calls were updated where appropriate.
Bug: 27705805
Change-Id: Ic5d5decd77567ba0f749e48837a2c6fa10e812c0
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 98576cf949a1ffbece3722451713aac01ed27968 |
|
08-Mar-2016 |
Ruben Brunk <rubenbrunk@google.com> |
Grant default permissions to preinstalled VrListenerServices.
- While explicitly bound, the package for a single pre-installed
VrListenerService will be granted permission to access
notification policy, be bound as a notification listener service,
and draw system overlays.
Bug: 22855417
Change-Id: I568d5d9c032e0926e47c8ef4b46e3910b6bdf766
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| a04c7a7c6442b8c6f87f5dd11fc5659cdb92decc |
|
18-Mar-2016 |
Jeff Sharkey <jsharkey@android.com> |
Mark more Bundles as being defusable.
They're destined for the system, so they're okay to look inside.
Bug: 27726127
Change-Id: Ic85c308a8efe6f9b8652952717c72b3c663d328a
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| d136e51a99df5275eaafdde407e89e78c02b829b |
|
10-Mar-2016 |
Jeff Sharkey <jsharkey@android.com> |
Defuse Bundles parsed by the system process.
It's easy for apps to throw custom Parcelables into Bundles, but
if the system tries peeking inside one of these Bundles, it triggers
a BadParcelableException. If that Bundle was passed away from the
Binder thread that delivered it into the system, we end up with a
nasty runtime restart.
This change mitigates this trouble by "defusing" any Bundles parsed by
the system server. That is, if it encounters BadParcelableException
while unpacking a Bundle, it logs and delivers an empty Bundle as
the result.
Simultaneously, to help catch the system process sticking its
fingers into Bundles that are destined for other processes, a Bundle
now tracks if it's "defusable." For example, any Intents delivered
through ActivityThread are marked as being defusable, since they've
arrived at their final destination. Any other Bundles are considered
to be "in transit" and we log if the system tries unparceling them.
Merges several Parcel boolean fields into a flags int. Add better
docs to several classes.
Bug: 27581063
Change-Id: I28cf3e7439503b5dc9a429bafae5eb48f21f0d93
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| fbcaea877c152e1c82dfd09c356cfaa636f0bbf0 |
|
08-Mar-2016 |
Prathmesh Prabhu <pprabhu@google.com> |
Merge "SettingsProvider: Add default value for SHOW_IME_WITH_HARD_KEYBOARD." into nyc-dev
|
| bf2ef61770b147aa2a229500131ca5cb4be17919 |
|
08-Mar-2016 |
Amith Yamasani <yamasani@google.com> |
Reorder migration of settings from db to xml
Make sure we commit the Global table last, so that if the
runtime was restarted before the others were written, we don't
get into an inconsistent state of migration.
Not sure if this fixes the following bug, but it's one thing
that stood out as a possibility.
Bug: 27335488
Change-Id: I4166a157e9ff542b1d5e32797693417375e40581
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| de16b869308b1d667743bac3deba5d7b2b3c5889 |
|
05-Mar-2016 |
Prathmesh Prabhu <pprabhu@google.com> |
SettingsProvider: Add default value for SHOW_IME_WITH_HARD_KEYBOARD.
Allow OEMs to override default behaviour wrt. showing IME with a
hardware keyboard is connected. Current behaviour remains unchanged.
BUG: 27503877
BUG: 27484734
Change-Id: I7ed70b195c3ae98471e413b3eecc5d8fcd3dee26
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 67a8d3516c80c71d81352318b33cba95f8b4cc0b |
|
02-Mar-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fix a regression in SettingsProvider
bug24990012
Change-Id: I1631d125df029f559ffc059ffcb73067389184e8
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 413573ac59bb9904c3bd28c03843054fee7478a6 |
|
23-Feb-2016 |
Jeff Sharkey <jsharkey@android.com> |
Offer to cache ringtones in system DE storage.
Ringtones often live on shared media, which is now encrypted with CE
keys and not available until after the user is unlocked. To improve
the user experience while locked, cache the default ringtone,
notification sound, and alarm sound in a DE storage area.
Bug: 26730753
Change-Id: Ie6ad7790af4c87dd25759df3ed017e3b91a2fb87
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 87648756e3d6746ae1e42b471f7d10d06507d0fa |
|
08-Jan-2016 |
Mahaver Chopra <mahaver@google.com> |
Handle null pointer exception
Handle null pointer exception, just in case calling entitity doesn't
check.
Change-Id: I1b4809476cc689ad3dfd426e123a64e9a0336c87
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| dea471ef548f09e04e178c5ec2d71a4b79bdb8f8 |
|
17-Dec-2015 |
Mahaver Chopra <mahaver@google.com> |
Added Data roaming user restriction
Added new user restriction DISALLOW_DATA_ROAMING, can only be set
by device owners.
Bug: 24890464
Change-Id: Ic4cb37dd5f9bbffa35f921751488ef7c7ff99452
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| bd17928afcbead00b498a75a92a0a32a6cca7fee |
|
18-Dec-2015 |
Bryce Lee <brycelee@google.com> |
resolve merge conflicts of 6b9e5bf0c2 to master.
Change-Id: Idada49313619533bfeb375ee232c942589457fa4
|
| ec85f34812b0f66715ad5ae4d1485f98a690746c |
|
16-Dec-2015 |
Bryce Lee <brycelee@google.com> |
Add setting for declaring disabled bluetooth profiles.
Bug: 25900899
Change-Id: I420a7c590d72ba10f3e466d15dccfdbb520e810a
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 269c11eee1ceed0b5959dce3f5d139ea3ac02ce8 |
|
03-Dec-2015 |
Suprabh Shukla <suprabh@google.com> |
Added default config to enable adding users from lockscreen
A config value is added for enabling/disabling the ability
to add users while screen is locked. The config value, currently false,
is read and applied to the setting only if the user has not set the
value as true/false explicitly.
Bug-Id: b/24662310
Change-Id: Ie00ab0952c64cbc9805794bc0dde350920750026
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 28da2e3490cff619157578c85d32a73ff979d554 |
|
20-Nov-2015 |
Makoto Onuki <omakoto@google.com> |
Fix "some user restrictions not working" issue
SettingsProvider used to prevent any changes to certain settings
when the corresponding user restriction is set, which isn't really what
these restrictions mean.
Even if a user restriction is set, it should still changing in the more
restricting direction.
Also stop setting "" to LOCATION_PROVIDERS_ALLOWED, which will simply
be ignored.
Bug 25614198
Change-Id: Ifa8edc2927e21e6c6174620c8c874c86c1dc0f75
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| d8d25e00386dd768a59e38eb3e1ae0cec0e797b2 |
|
20-Nov-2015 |
Svetoslav <svetoslavganov@google.com> |
Use resolved calling user id
bug:25476216
Change-Id: I0093a5c071affaa5f3ca8eeb0e3a7a36b66a3c1f
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 43765b77a0286403fd9f7f5305219f0d9a10c953 |
|
31-Aug-2015 |
Xiaohui Chen <xiaohuic@google.com> |
Cleanup USER_OWNER in SettingsProvider[Test]
Fixed up the tests and re-enabled it.
Still suppressed one test because what it relies on Settings.Bookmarks
is broken because Settings query format changed.
Fixed a bug in SettingsProvider that the package query is using the
wrong user id.
Bug: 19913735
Change-Id: Ied86a261defba2706f726a13bc32f385f7d93787
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 7e0683b3bd096a4436ebe15431b70a89d2403257 |
|
04-Aug-2015 |
Svetoslav <svetoslavganov@google.com> |
Notify settings URI change without a lock held
bug:22469552
Change-Id: Ie4a42ceef07e3a8e593fe2b1374420239242ce7b
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 6ad2d66072795dd9836350b273dcde52910ab4c3 |
|
18-Jul-2015 |
Billy Lau <billylau@google.com> |
Bug: 21589105 Rescope WRITE_SETTINGS permission (framework services perm check
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
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 50184147fc35d5d441ae24661531819cc6cc025f |
|
29-Jul-2015 |
Martijn Coenen <maco@google.com> |
Merge "Resource for setting default NFC payment component." into mnc-dev
|
| 7ab4b7fd500c3c21b0329faa29e74eac4ef638af |
|
27-Jul-2015 |
Martijn Coenen <maco@google.com> |
Resource for setting default NFC payment component.
Bug: 22756856
Change-Id: If97e0faead995fb95893a128c1890b61bbe86ce5
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 310e1eeb352e6e65e83a108c66bbea9f441ba58d |
|
02-Jul-2015 |
Nicolas Prevot <nprevot@google.com> |
Notify the profile when cloned settings are changed.
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
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 45146493c6cbb3f39d92b41e5bc8742fb1e04ff6 |
|
25-Jun-2015 |
Svetoslav <svetoslavganov@google.com> |
Add missing conditional in settings provider
Change-Id: I717e8b87eccbedf1a1abead77e7856a2aa2405fa
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| f41334bb155383c1a3fb7e5cf540160aa9ab883a |
|
23-Jun-2015 |
Svetoslav <svetoslavganov@google.com> |
System settings can be changed by system apps.
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
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 3a2c3578ba5bf8642c994fa357a96eaa4a38cdc9 |
|
18-Jun-2015 |
Makoto Onuki <omakoto@google.com> |
Allow binary value in SettingsProvider
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
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 1f450dbfbc60512e66733d1b95dad5237c997155 |
|
12-Jun-2015 |
Fyodor Kupolov <fkupolov@google.com> |
Fixed NPE when dumpSettings is called with a null cursor
Bug: 20070414
Change-Id: I15d5d2ae27a7892807221421778082e0f29a36ff
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 7ec28e85139a6134592902a7399bed108d01e2fa |
|
21-May-2015 |
Svetoslav <svetoslavganov@google.com> |
Do not call out of the settings provider with a lock held
bug:20443441
Change-Id: I704520b75f5deaeeb1b4098cda0783c667e8cdd1
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 27bbb2d0a1c8a3bb38768511ac840c3388b0fb03 |
|
31-Mar-2015 |
Jason Monk <jmonk@google.com> |
Add control for double tap to wake setting
Bug: 16875464
Change-Id: Ic1ad910dd38acbc68ef040b2acdf3696ec2c2e4e
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| e11ae116314a32ff1570f023b95e0ece3dbcc2e9 |
|
11-May-2015 |
John Spurlock <jspurlock@google.com> |
Zen: Reset zen + ringer modes on upgrades to M.
Bug: 20886649
Change-Id: I79d0b4a31eb9d54c5e5d4cd80236fdb8340dfeb2
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 8de348095f0967ffaa09d2448dc1ccff72a4e284 |
|
27-Apr-2015 |
Svet Ganov <svetoslavganov@google.com> |
DO NOT MERGE Do not clean up global/system settings on package unintalls.
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)
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 1b8ef7e3165ff9aa52a4905dafc8d0f83e7403f9 |
|
04-Apr-2015 |
Jeff Sharkey <jsharkey@android.com> |
Parcelable objects for Disk/Volume.
Will eventually be used by SystemUI and/or Settings.
Also fix SettingsProvider NPE.
Bug: 19993667, 19909433
Change-Id: Ie326849ac5f43ee35f728d9cc0e332b72292db70
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| fd93eaf278ad2f58bb23d3141da1342f872c473c |
|
03-Apr-2015 |
Jeff Brown <jeffbrown@google.com> |
Merge "Clarify settings update code."
|
| c9755bc4f2183d6d8e035e6a448b2c948dcd3a01 |
|
28-Mar-2015 |
Svet Ganov <svetoslavganov@google.com> |
Fix a regression in settings parsing
Change-Id: I222bac482a843112ae031b00c83e3765ea6b456c
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 503cffc18121cdbb7d969b3a4de3168f13c75459 |
|
27-Mar-2015 |
Jeff Brown <jeffbrown@google.com> |
Clarify settings update code.
Change-Id: I650ff827bc31eacff2efcdba84e6ef41016ad51c
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| b596a2c5bf01ee3e716df08dfe19faea6d9ef9e5 |
|
18-Feb-2015 |
Svetoslav <svetoslavganov@google.com> |
Location settings not properly set.
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
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 85b880035daf6a9100f5d1b66f4382f6f21497f8 |
|
18-Feb-2015 |
Svetoslav <svetoslavganov@google.com> |
Merge "Add dump support to the settings provider"
|
| b505ccc90667ad69a1b122f025a415a3b2aee6af |
|
17-Feb-2015 |
Svetoslav <svetoslavganov@google.com> |
Add dump support to the settings provider
Change-Id: I1338af4c660e3ecc412954a7cb9b820952aae523
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 2849465ee19febd5135cb6ab8cb548a3c8ac6a24 |
|
12-Feb-2015 |
Svetoslav <svetoslavganov@google.com> |
Handle a missed case in query the settings provider
bug:19361521
Change-Id: Ibf4731b5d665563bb87ef93a4cf63e4c4d2e46a4
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 683914bfb13908bf380a25258cd45bcf43f13dc9 |
|
15-Jan-2015 |
Svetoslav <svetoslavganov@google.com> |
Rewrite of the settings provider.
This change modifies how global, secure, and system settings are
managed. In particular, we are moving away from the database to
an in-memory model where the settings are persisted asynchronously
to XML.
This simplifies evolution and improves performance, for example,
changing a setting is down from around 400 ms to 10 ms as we do not
hit the disk. The trade off is that we may lose data if the system
dies before persisting the change.
In practice this is not a problem because 1) this is very rare;
2) apps changing a setting use the setting itself to know if it
changed, so next time the app runs (after a reboot that lost data)
the app will be oblivious that data was lost.
When persisting the settings we delay the write a bit to batch
multiple changes. If a change occurs we reschedule the write
but when a maximal delay occurs after the first non-persisted
change we write to disk no matter what. This prevents a malicious
app poking the settings all the time to prevent them being persisted.
The settings are persisted in separate XML files for each type of
setting per user. Specifically, they are in the user's system
directory and the files are named: settings_type_of_settings.xml.
Data migration is performed after the data base is upgraded to its
last version after which the global, system, and secure tables are
dropped.
The global, secure, and system settings now have the same version
and are upgraded as a whole per user to allow migration of settings
between these them. The upgrade steps should be added to the
SettingsProvider.UpgradeController and not in the DatabaseHelper.
Setting states are mapped to an integer key derived from the user
id and the setting type. Therefore, all setting states are in
a lookup table which makes all opertions very fast.
The code is a complete rewrite aiming for improved clarity and
increased maintainability as opposed to using minor optimizations.
Now setting and getting the changed setting takes around 10 ms. We
can optimize later if needed.
Now the code path through the call API and the one through the
content provider APIs end up being the same which fixes bugs where
some enterprise cases were not implemented in the content provider
code path.
Note that we are keeping the call code path as it is a bit faster
than the provider APIs with about 2 ms for setting and getting
a setting. The front-end settings APIs use the call method.
Further, we are restricting apps writing to the system settings.
If the app is targeting API higher than Lollipop MR1 we do not
let them have their settings in the system ones. Otherwise, we
warn that this will become an error. System apps like GMS core
can change anything like the system or shell or root.
Since old apps can add their settings, this can increase the
system memory footprint with no limit. Therefore, we limit the
amount of settings data an app can write to the system settings
before starting to reject new data.
Another problem with the system settings was that an app with a
permission to write there can put invalid values for the settings.
We now have validators for these settings that ensure only valid
values are accepted.
Since apps can put their settings in the system table, when the
app is uninstalled this data is stale in the sytem table without
ever being used. Now we keep the package that last changed the
setting and when the package is removed all settings it touched
that are not in the ones defined in the APIs are dropped.
Keeping in memory settings means that we cannot handle arbitrary
SQL operations, rather the supported operations are on a single
setting by name and all settings (querying). This should not be
a problem in practice but we have to verify it. For that reason,
we log unsupported SQL operations to the event log to do some
crunching and see what if any cases we should additionally support.
There are also tests for the settings provider in this change.
Change-Id: I941dc6e567588d9812905b147dbe1a3191c8dd68
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 3b566b84708eea887ab3e1e1bbba4b2242b261d6 |
|
12-Nov-2014 |
Jeff Sharkey <jsharkey@android.com> |
Move ringtone redirection to MediaPlayer.
Way back in API 1 we defined Settings.System.DEFAULT_NOTIFICATION_URI
which redirects through SettingsProvider before finally ariving at
the real underlying ContentProvider, usually MediaStore.
With new SELinux rules, we're no longer allowing the system_server
to hold open FDs to shared storage devices, which causes these
proxied openFile() calls to fail.
To work around this, teach MediaPlayer to resolve the final ringtone
Uri without going through the system.
Bug: 18226181
Change-Id: I40c68617c952c0bb3e939e5084f5b68a35e31ae3
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 67f175cf07ff52c5bee30536caad2e97800ab5b8 |
|
03-Oct-2014 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #17811029: Settings provider race when removing users
Change-Id: Ia40d0a9c161b765d1340db5390d0acdbfc050b81
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 3de09018a9611b1791cc29ed5200b7d9694189a9 |
|
02-Oct-2014 |
Kenny Guy <kennyguy@google.com> |
Merge "SettingsProvider should use correct cache when redirecting to user 0." into lmp-dev
|
| 8d05172112436a81bed6e4a0810f8914509d8a4d |
|
01-Oct-2014 |
Dianne Hackborn <hackbod@google.com> |
More work on issue #17656716: Unhandled exception in Window Manager
Fix Slog.wtf to not acquire the activity manager lock in its code
path, so that it can never deadlock. This was the original intention
of it, but part was missed.
Now we can put back in the code to detect when strict mode data is
getting large (a little more targeted now to the actual problem),
and use Slog.wtf to report it. And as a bonus, when this happens
we will now clear all of the collected violations, to avoid getting
in to the bad case where IPCs start failing. So this should be
good enough for L to fix the problem, with wtf reports for us to
see if the underlying issue is still happening.
Finally, switch a butch of stuff in the system process from Log.wtf
to Slog.wtf, since many of those are deadlocks waiting to happen.
Oh and fix a crash in the settings provider I noticed in APR.
Change-Id: I307d51b7a4db238fd1e5fe2f3f9bf1b9c6f1c041
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| a37d000c2b4acfc72f5a5e75e5cd711fd10acaa8 |
|
01-Oct-2014 |
Kenny Guy <kennyguy@google.com> |
SettingsProvider should use correct cache when redirecting to user 0.
SettingsProvider reads secure and system settings for managed
profiles from user 0 instead. However it still checks the cache
for the managed profile not user 0.
Bug: 17736586
Change-Id: I15d44b8a5779b01e6b9032e528dc34f5c5602449
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| ccc7cb9bdb3eb5f86d81e223b82e04dab21ad5fa |
|
23-Sep-2014 |
Amith Yamasani <yamasani@google.com> |
Return masked location mode for managed profiles
If there's a user restriction on location sharing in a
managed profile, always return empty string for location
providers so that location can be disabled by the admin
even if the primary user has location enabled.
Also fix an incorrect update of the cache. Shouldn't update
the primary user's cache when the caller is the managed profile.
Bug: 17478855
Change-Id: Icab3459ae351c5cfc287e21df6a5ba1df9dfbdb4
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 35349352732fd6d889b8d718dd29f068ebbf1021 |
|
11-Sep-2014 |
Zoltan Szatmary-Ban <szatmz@google.com> |
Leave SettingsProvider running if cloning of a setting fails
Cloning of settings to managed profiles could fail due to security restrictions. This caused
Settings app crash. Instead the exception is now caught inside SettingsProvider, logged,
and we leave the app running.
Bug:17450158
Change-Id: I7525d634e57701db304117f4b2035faf53977836
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| b53453fae037d67e421011936c8fdffe7ba43922 |
|
22-Aug-2014 |
Julia Reynolds <juliacr@google.com> |
Audio/Micrphone user restriction/multiuser updates.
1. Persist microphone mute state.
2. Set mute state for correct user.
3. Check for settings restrictions as the correct user.
Bug: 17177502
Bug: 16701642
Change-Id: Id8b6cd90c5caceb67fbec862f90aac7ec7a00b3c
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 4f7e2e334e4ca5f1a67baf4bdd40cd080b954161 |
|
15-Aug-2014 |
Amith Yamasani <yamasani@google.com> |
Copy certain settings to the managed profile
All reads of those specific settings will go to the primary user.
Inserts to primary also go to managed profiles in order to notify
any observers.
This enables Location settings to be shared by both profiles.
Also some other settings related to IME and Accessibility since
those services are shared across the profiles.
Bug: 16457210
Change-Id: Ib8fd697b5c78027fcbaf245d82dda5e6d6aab4f0
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 25838509d84a139d0f0bc1f74ea674fcfba76629 |
|
10-Jul-2014 |
Julia Reynolds <juliacr@google.com> |
INSTALL_NON_MARKET_APPS lives in Secure again.
Change-Id: Ib3c7a48b8dc2d649f2f6c8e8cd822ab342634afd
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 5e458dd6b4b92c369865e59c81a02c8ce8c342f6 |
|
07-Jul-2014 |
Julia Reynolds <juliacr@google.com> |
Apply user restrictions to SettingsProvider.
Change-Id: If68c715bc688bf0df63591e0b8f8bf8a2b6dd118
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 0da1357f9827b6a2df24a449dbb8eba12484095c |
|
14-Oct-2013 |
Christopher Tate <ctate@google.com> |
Log noisily on uid vs user-handle confusion in the settings provider
Make sure that we catch any attempts to pass a uid to the settings
provider's "for this user" code paths.
Bug 11087584
Bug 11208808
Change-Id: I1cc025b2aade9072b4a61b4499d02c82b0085fa2
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 911d7f411f36f2279aae44c89ff1d33a29140046 |
|
06-Sep-2013 |
Jeff Sharkey <jsharkey@android.com> |
Provide calling package to ContentProviders.
The calling package is important for ContentProviders that want to
grant Uri permissions as a side effect of operations, so offer it
through a new API. Validates the provided package against the
calling UID before returning.
Bug: 10626527
Change-Id: I7277880eebbd48444c024bcf5f69199133cd59e4
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 38e7a60fd7fecdf1c6593724111a92147b4c50ff |
|
04-Sep-2013 |
Christopher Tate <ctate@google.com> |
Sanity check users before committing new Android ID
In creation/deletion cycling we can wind up racing and attempting
to establish the Android ID on first access *after* the user has
already been deleted. Cope gracefully with this outcome.
Bug 10608503
Change-Id: I169d5052e5a2e354ce0e1f61258e45e31f5ba171
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 7f50ef7ddafc6dc7d6419e312185160995047256 |
|
28-Jun-2013 |
Amith Yamasani <yamasani@google.com> |
am 3f0decd7: am 16a2268f: am e6304a9c: Merge "When a new user AID is generated, dump it to dropbox" into jb-mr2-dev
* commit '3f0decd7dff8b4c12544c24b2d19a41d4eaacd03':
When a new user AID is generated, dump it to dropbox
|
| 5cdf7f5b2a75455e8024a4cb892ac38bcd8e9582 |
|
28-Jun-2013 |
Amith Yamasani <yamasani@google.com> |
When a new user AID is generated, dump it to dropbox
Bug: 9595851
Change-Id: I6fde757eed84d7914db180e80c9d68448b3e5780
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 853ad6fbe34fa26e81e4b7325309a034d7a1b038 |
|
30-Apr-2013 |
Mike Lockwood <lockwood@google.com> |
Remove obsolete OMA-DRM support
Change-Id: Ic6008d4c9f8b9cd9fd4efec070260227af70559c
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 27db46850b708070452c0ce49daf5f79503fbde6 |
|
31-Mar-2013 |
Amith Yamasani <yamasani@google.com> |
Block access to accounts for limited users.
Make sure that apps that have access to restricted accounts can see them.
If they don't have access, they shouldn't be able to add a new account either.
Show an error message in the account picker if the user/app is not authorized.
Change-Id: I117c0b14d7d06c5ac4e66506df156b174567f5f3
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 1095d9ac5df839408b9a549cc638c2909d98dfac |
|
07-Feb-2013 |
Maggie Benthall <mbenthall@google.com> |
Merge "Fix for SettingsProvider to query for correct user."
|
| d2726582f135383e56661bc41d750966642dab45 |
|
04-Feb-2013 |
Maggie Benthall <mbenthall@google.com> |
Fix for SettingsProvider to query for correct user.
insertForUser takes a specified user and attempts to adjust that user's
settings, first looking at their existing settings to determine the difference.
However it was querying the settings for the calling user, rather than for
the user whose settings were being changed.
Also add a test that exercises the fix.
Change-Id: I6ed6fd79154ac1b6e6ab880769ac9081dfff6b80
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 961321fe4ed4431a6362d729d9e4ea26bdecde61 |
|
06-Feb-2013 |
Dianne Hackborn <hackbod@google.com> |
App ops: add op for writing settings.
Also fix a build.
And fix a bug that I think was introduced in the multi-user work
that removed the permission check for writing to settings...!
Change-Id: I5945682faa789ffc78fd3546c0df7d03693f106d
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 40e9f2922cae76ffcbc521481e5be8e80e8744ef |
|
28-Nov-2012 |
Dianne Hackborn <hackbod@google.com> |
Quiet down a lot of logging.
Also fix a little problem where the USER_STARTED broadcasts
were not being sent as ordered broadcasts(!).
Change-Id: I3aa3e0a9b3900967cdd2d115ee103371b0a50c41
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 61695ffcbccc6cca210e869eb3bc6e97127c2357 |
|
05-Oct-2012 |
Christopher Tate <ctate@google.com> |
Make sure settings writes are permission checked correctly
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
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 34637e57fc5bce01029806a67cf0cc2ef049e13b |
|
05-Oct-2012 |
Christopher Tate <ctate@google.com> |
Make sure to check write perms after rewriting destination table
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
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 35dd752238d3ce3b83e78eb4b00a85ea3d067088 |
|
04-Oct-2012 |
Christopher Tate <ctate@google.com> |
Merge "Rewrite raw insert()s and some raw query()s of moved-to-global keys" into jb-mr1-dev
|
| c221d2be7d2bf57373d43457b18483266f88f9a6 |
|
04-Oct-2012 |
Christopher Tate <ctate@google.com> |
Rewrite raw insert()s and some raw query()s of moved-to-global keys
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
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| afccaa84c8d1b9aa45040ddeb0edd42ba80e80d6 |
|
04-Oct-2012 |
Christopher Tate <ctate@google.com> |
Use myUserId() only in registerContentObserver()
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
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 66488d64df8c3cf8722b8bf282398617cf3c0551 |
|
02-Oct-2012 |
Christopher Tate <ctate@google.com> |
Make settings backup/restore work in the new multi-user world
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
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 6e2bee75cea415621165698fdd9ce857bbb8872e |
|
01-Oct-2012 |
Jeff Sharkey <jsharkey@android.com> |
Migrate more System and Secure settings to Global.
Includes telephony, WindowManager, PackageManager, and debugging
settings. Update API to point towards moved values.
Bug: 7231764, 7231252, 7231156
Change-Id: I5828747205708872f19f83a5bc821ed0a801cb79
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 625239a05401bbf18b04d9874cea3f82da7c29a1 |
|
27-Sep-2012 |
Jeff Sharkey <jsharkey@android.com> |
Migrate more Secure settings to Global.
Migrate networking, storage, battery, DropBox, and PackageManager
related Secure settings to Global table.
Bug: 7232014, 7231331, 7231198
Change-Id: I772c2a9586a2f708c9db95622477f235064b8f4d
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| bdfce2ec05a3e9ca6acd6711de6133e06f2446e6 |
|
27-Sep-2012 |
Jeff Sharkey <jsharkey@android.com> |
First step towards cleaning up Global settings.
Remove all @Deprecated @hide settings, and clean up any stragglers.
Bug: 7232125
Change-Id: Ibf67093c728d4a28565129b923edb1701d3b2789
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| d33646008948db439ea8cde8dfc0188aced6436d |
|
25-Sep-2012 |
Jean-Baptiste Queru <jbq@google.com> |
Merge into jb-mr1-dev
Change-Id: Idf183be6a41ff37add5141a20e96d5190396d1a4
|
| 139748fd724b482e2c012a6ec44d1c5abc0c0e97 |
|
24-Sep-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #7215984: java.lang.RuntimeException: Unable to create...
...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
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 5bcb55186ebda12d9e4308043898f7aa3ac5c952 |
|
24-Sep-2012 |
Doug Zongker <dougz@google.com> |
fix argument parser for global settings URLs
Make content://settings/global/setting_name URLs work like system and
secure URLs.
Bug: 7212535
Change-Id: I33e388a0cc80309453714eab726ce45b3f8fef73
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| b7564454297ba1706670ccab0562cac6676d0a77 |
|
20-Sep-2012 |
Christopher Tate <ctate@google.com> |
Multiuser awareness in content observer infrastructure
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
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| c8459dc85e53a9275c89190b35f1da35cd996e46 |
|
18-Sep-2012 |
Christopher Tate <ctate@google.com> |
Settings provider needs to send notifications as itself
... and not as its ultimate caller, who may be a less-privileged
application. Fixes bug 7188309
Change-Id: Iffd37b8da84f683bf665bf3d48c0b7fbc8dd721d
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 16aa9736175f5bbe924a6e5587a2ca47c2dd702b |
|
18-Sep-2012 |
Christopher Tate <ctate@google.com> |
Per-user content observer APIs
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
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 78d2a66ac12e4c8f1303225514f573fb53af1dd9 |
|
14-Sep-2012 |
Christopher Tate <ctate@google.com> |
Fix Settings writes to a different user
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
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| c868b645b46685574955eaff9f8d46d9262a3357 |
|
13-Sep-2012 |
Christopher Tate <ctate@google.com> |
Moved a few telephony settings from Secure to Global
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
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 4dc7a68dbeaa0edd8815b2105915753310d58343 |
|
11-Sep-2012 |
Christopher Tate <ctate@google.com> |
Set up default (random) Android IDs for all users
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
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| d5fe1479248fa597efc7ccb0b36df0b520bbc2a3 |
|
11-Sep-2012 |
Christopher Tate <ctate@google.com> |
Miscellaneous fixes for Settings
(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
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 9219874be99cc07660807cc5dc94b0d157ef8808 |
|
07-Sep-2012 |
Christopher Tate <ctate@google.com> |
Further fixup of migration to global settings
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
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 06efb530a479ea12398c1b3ee4b80e2ac85a1680 |
|
25-Aug-2012 |
Christopher Tate <ctate@google.com> |
Per-user settings
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
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 47847f3f4dcf2a0dbea0bc0e4f02528e21d37a88 |
|
23-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Support enabling WAL using a flag when DB is opened.
Using enableWriteAheadLogging() to enable WAL is inefficient because
we previously disabled WAL mode when the database was opened.
Switching from WAL to PERSIST then back to WAL is inefficient
and could slow down application launch time. It would be better
to leave the database in WAL mode when we open it to begin with.
To do that, we need to know ahead of time whether we will want to
have WAL enabled for the newly opened database.
Using this flag also reduces the chance that we will encounter
an error enabling WAL mode due to there being other open connections
to the database.
Bug: 6124556
Change-Id: I38ec7a528baeda9f1ef77e25e88b3ca4b6296200
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 32c80a27dae4a3094f647bb4d97b27a0eb3b985e |
|
26-Feb-2011 |
Jesse Wilson <jessewilson@google.com> |
Handle rename of LruCache.entryEvicted to entryRemoved
Change-Id: I50e5a8d8c35c4431f42c7483172447ba0e4e125b
http://b/3461302
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 0c7faeee47e7629f2d23a2e3b25bc4f121252080 |
|
10-Feb-2011 |
Jesse Wilson <jessewilson@google.com> |
Adopt LruCache in SettingsProvider.
Change-Id: I223ed2a4bd90234ea7e3447f19e18c68beae2763
http://b/3184897
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 01a479ccc4c8d13dc56a2eced4055a7864a7abc3 |
|
11-Jan-2011 |
Vasu Nori <vnori@google.com> |
bug:3339065 enable sqlite concurrency enhancing feature on settingsprovider
why is settingsprovider doing getReadbleDatabase() in onCreate() method?
it shoul do getWritableDatabse() so that sqlite's WAL
feature can be enabled on it.
Change-Id: I60e46ce240a6474bbb50ab26fb1d979242b0c9ad
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 9bb4ec484b9b9518bf5b17484dcb50727c58b5d1 |
|
24-Sep-2010 |
Nick Kralevich <nnk@google.com> |
Use the default SecureRandom provider.
Don't be tricky when trying to set the seed for the secure
random number generator. Setting the seed manually eliminates
the internal randomization the SecureRandom class does automatically,
reducing randomness. Just use the default seed, which is designed
to be safe.
Change-Id: I5747c2b3a10cf04e33d2202195951ed5cb82b2fe
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 3a2952baf1151f3d96d46cb3bbed600a087e14e8 |
|
27-Aug-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Fix some bugs in SettingsProvider that I introduced the other day.
BUG=2953979
Change-Id: Ic9813e0ce629c56050d626ed52de67e6ab1ab07e
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| f366a9b007909cc6d214fbee26a97e880734a094 |
|
25-Aug-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Negatively cache settings and proactively slurp settings into cache.
The settings database cache is tiny (or should be tiny) and can be
slurped into memory. Once it's in memory and we know we have it all
we can avoid going to disk at all for keys not in the cache.
This is a big percentage of the StrictMode violations & latency.
Change-Id: I649411be0c40d348f58376ccfb3eda059fd69fbc
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| a695cbc94355017d02a3a6c17d866776a8eee24c |
|
19-Aug-2010 |
Doug Zongker <dougz@android.com> |
am 0fe27cf5: make android_id random seed depend on time as well as ro.serialno
Merge commit '0fe27cf5bd1407bc7b4eabefaa91ff535582badc' into gingerbread
* commit '0fe27cf5bd1407bc7b4eabefaa91ff535582badc':
make android_id random seed depend on time as well as ro.serialno
|
| 0fe27cf5bd1407bc7b4eabefaa91ff535582badc |
|
19-Aug-2010 |
Doug Zongker <dougz@android.com> |
make android_id random seed depend on time as well as ro.serialno
Change-Id: I0a48aacd8da30896d91fa05b7791335e6ed751e5
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| e339464f1c8efe7e53b761cf44ff5be6e537ecad |
|
13-Jul-2010 |
Dianne Hackborn <hackbod@google.com> |
am 1bcb6658: Merge "Fix issue #2834005: Android Settings.Secure bypass" into froyo
Merge commit '1bcb665825dc97789e8c1b892ec4298fd0b8c552' into gingerbread
* commit '1bcb665825dc97789e8c1b892ec4298fd0b8c552':
Fix issue #2834005: Android Settings.Secure bypass
|
| 24117ce3ae32c40798d2d9bda80675814f76730d |
|
13-Jul-2010 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #2834005: Android Settings.Secure bypass
Change-Id: Ic4f14e2ff5c2b4f623405d30389863a9e3e82572
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 5ebaf10693725c9dc48219c3c65945b84d74692f |
|
22-Apr-2010 |
The Android Open Source Project <initial-contribution@android.com> |
merge from open-source master
Change-Id: I2a3a06f0bd3530f9c0d3cb64ca6a87913649d64b
|
| bdc7f891cf47c077c26ef418dbea23c04820c152 |
|
22-Apr-2010 |
Mike Lockwood <lockwood@android.com> |
Fix broken logic in SettingsProvider.parseProviderList.
We were accidentally stripping both leading and trailing commas
when removing a provider from the enabled provider list.
Signed-off-by: Mike Lockwood <lockwood@android.com>
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 547a96bc12f25f585271c678395d4c991f08c52d |
|
10-Mar-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
SettingsProvider: dup-suppress from cache.
On insert(), check to see if the value is redundant by checking if
it's the same value already in our cache (but without faulting it in
to check). If so, avoid hitting sqlite or spamming all the
notification listeners with such uselessness.
This reportedly is happening a fair bit.
Change-Id: If58feb3ff1d00027dd927e0900087388cbcd72ae
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 342984a17ddd010381c462066e33e18354b79e4f |
|
10-Mar-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
SettingsProvider: defensively cap size of settings kept cached in memory.
Change-Id: I50289ece2d7f5f50d2ea2efbacac7a0bb1483bf6
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 1bd62bd3ca4d098196e91b43799d4010c1d26623 |
|
09-Mar-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Cache hot settings in-memory in the SettingsProvider.
This brings down Settings lookups to 0.5 ms on sholes. (down from
~10.5 ms originally, and ~2.5 ms after the ContentProvider.call()
interface)
Change-Id: Ibde7c3d21e0b0e5714714a2075f314726edfc19d
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 4528186e0d65fc68ef0dd1941aa2ac8aefcd55a3 |
|
06-Mar-2010 |
Christopher Tate <ctate@google.com> |
Refactor android.backup => android.app.backup
Change-Id: I0b21316ff890d7f3c7d4b82837bb60670724c2e8
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 1877d0158b529663b8315482e7346a7bcaa96166 |
|
05-Mar-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Add "call" method on ContentProvider.
This permits implementing interfaces which are faster than using
remote Cursors. It then uses it for Settings & SettingProvider, which
together account for ~50% of total ContentProvider event loop stalls
across Froyo dogfooders.
For fetching Settings this looks like it should reduce average
Settings lookup from 10 ms to 0.4 ms on Sholes, once the
SettingsProvider serves most gets from in-memory cache. Currently it
brings the Sholes average down from 10ms to 2.5 ms while still using
SQLite queries on each get.
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 21f1bd17b2dfe361acbb28453b3f3b1a110932fa |
|
20-Feb-2010 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #2438980: Implement package watcher for voice recognizer service setting
I am getting tired of writing package monitor code, realized this is missing in
a number of places, and at this point it has gotten complicated enough that I
don't think anyone actually does it 100% right so:
Introducing PackageMonitor.
Yes there are no Java docs. I am still playing around with just what this
thing is to figure out what makes sense and how people will use it. It is
being used to fix this bug for monitoring voice recognizers (integrating the
code from the settings provider for setting an initial value), to replace
the existing code for monitoring input methods (and fix the bug where we
wouldn't remove an input method from the enabled list when it got
uninstalled), to now monitor live wallpaper package changes (now allowing
us to avoid reverting back to the default live wallpaper when the current
one is updated!), and to monitor device admin changes.
Also includes a fix so you can't uninstall an .apk that is currently enabled
as a device admin.
Also includes a fix where the default time zone was not initialized early
enough which should fix issue #2455507 (Observed Google services frame work crash).
In addition, this finally introduces a mechanism to determine if the
"force stop" button should be enabled, with convenience in PackageMonitor
for system services to handle it. All services have been updated to support
this. There is also new infrastructure for reporting battery usage as an
applicatin error report.
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 4f8ff39c1e2448d44ac900e04f9348f9d2aeaaf5 |
|
03-Feb-2010 |
Doug Zongker <dougz@android.com> |
use device serial number to seed RNG for generating ANDROID_ID
Change-Id: I1bcc55f1309cb908803bc42084846a046041eda6
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| aed8f8eb1491a21c8c71d39258b70edb74533a62 |
|
08-Jan-2010 |
Doug Zongker <dougz@android.com> |
remove Settings.Gservices
Move the last few keys to secure settings, and delete the Gservices
table.
Change-Id: Ie3ba45aa8c1f220824aa027c547cb82884452eb5
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| edc5189c33de03f3e2f5f73edc0e007992b933c9 |
|
07-Jan-2010 |
Doug Zongker <dougz@android.com> |
change remaining frameworks/base Gservices to Secure settings
Change-Id: I61bdb05a2526523700c2833154d5a4133881ef10
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| c70239e84d5024c65728ba74fe74c7394b34ac65 |
|
17-Dec-2009 |
Fred Quintana <fredq@google.com> |
changed SettingsProvider to manage the androidid itself
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 69f593ccb7414ee98991b1da1a4bfbd9951e3570 |
|
28-Jul-2009 |
Marco Nelissen <marcone@google.com> |
Support for selection of silent ringtone from the ringtone picker.
This doesn't actually enable that, but adds the necessary code to make it work when enabled, and cleans up some ringtone related code.
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| c6f81c6716c634317c69343fc2fd9a2fe6a2c034 |
|
09-Jul-2009 |
Android (Google) Code Review <android-gerrit@google.com> |
am d1e5e3ff: Merge change 6639 into donut
Merge commit 'd1e5e3ffc22478bad8525dec4f1c6d57fe0ad368'
* commit 'd1e5e3ffc22478bad8525dec4f1c6d57fe0ad368':
Restore audio settings and wifi.
|
| d158214511a3c04753de04fa6389e46d33135c38 |
|
09-Jul-2009 |
Amith Yamasani <yamasani@google.com> |
Restore audio settings and wifi.
Optimize backups by writing an entity only if the checksum of the data has changed.
Call into the hidden AudioService API to apply changed audio settings.
After restoring wifi data, make sure that the permissions and ownership are set
properly for the supplicant process to access it.
Locale isn't restoring properly - TODO added.
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 2eac99ccbcdcc91b69c04ea2eb03f4cba961c17c |
|
08-Jul-2009 |
-b master <yamasani@google.com> |
resolved conflicts for merge of d6fe243c to master
|
| 8823c0a8c68fe669c21c539eef9fc6541f0c7494 |
|
07-Jul-2009 |
Amith Yamasani <yamasani@google.com> |
Backup / Restore locale preference.
Also backup development settings MOCK_LOCATION and USB_DEBUGGING.
Backup and restore more of the Audio settings. Won't work yet without a reboot.
Disable Wifi supplicant restore temporarily. It seems to be disabling Wifi due to
permissions problems.
Don't restore Ringtones.
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 501eec92f9f4f206ad7972c63f2d0ef0285d8e34 |
|
06-Jul-2009 |
-b master <yamasani@google.com> |
Revert "hand rolled out 220f4d633be1098e7887dbd06f179138bf19f1ad due to interface changes on master, the change will need to be made again"
This reverts commit f8e3ba5bfad14f3037d72eb6243258c13169cbd8.
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| f8e3ba5bfad14f3037d72eb6243258c13169cbd8 |
|
03-Jul-2009 |
The Android Open Source Project <initial-contribution@android.com> |
hand rolled out 220f4d633be1098e7887dbd06f179138bf19f1ad due to interface changes on master, the change will need to be made again
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 133ec72f2480a65a02c8e1e5d9540796a0d05895 |
|
03-Jul-2009 |
Android (Google) Code Review <android-gerrit@google.com> |
am 288fe16c: Merge change 6043 into donut
Merge commit '288fe16c20e2c20556839046d38c487b0b18735c'
* commit '288fe16c20e2c20556839046d38c487b0b18735c':
System and Secure settings backup.
|
| 220f4d633be1098e7887dbd06f179138bf19f1ad |
|
02-Jul-2009 |
Amith Yamasani <yamasani@google.com> |
System and Secure settings backup.
This backs up the basic system and secure settings. THe restoration doesn't
take effect immediately. You many need to restart the runtime to see all
restored values take effect.
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 6976dca6c89d4d3ff986e46b6eedebdbdd656b0c |
|
19-Jun-2009 |
Android (Google) Code Review <android-gerrit@google.com> |
am 6afe8133: Merge change 4720 into donut
Merge commit '6afe81339ed973f1ef4a6c30110d5ce3b001ea4c'
* commit '6afe81339ed973f1ef4a6c30110d5ce3b001ea4c':
Fix string formatters in SettingsProvider SecurityException message.
|
| 31a88fac91cbdddb2ba63b0557cfd18b31d5eaac |
|
19-Jun-2009 |
Brett Chabot <brettchabot@android.com> |
Fix string formatters in SettingsProvider SecurityException message.
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 6be4025b1290e257a8d9142caba5bc7df72afab3 |
|
19-Jun-2009 |
Android (Google) Code Review <android-gerrit@google.com> |
am 2810f681: Merge change 4694 into donut
Merge commit '2810f681991d1beb5ceb3515159f9fad3cc341d5'
* commit '2810f681991d1beb5ceb3515159f9fad3cc341d5':
Make SettingsProviders SecurityException messages more verbose.
|
| 16dd82cfdc879b7c3e51b19e54c70dbf78e8d697 |
|
19-Jun-2009 |
Brett Chabot <brettchabot@android.com> |
Make SettingsProviders SecurityException messages more verbose.
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 48554fc78e981590708cc2cb78ce3c09642e2c4d |
|
03-Apr-2009 |
Mike Lockwood <> |
Merge branch 'readonly-p4-master'
|
| bd2a7126e5b42e022228c6aac25e95b671e5263b |
|
03-Apr-2009 |
Mike Lockwood <> |
AI 144415: am: CL 144372 Cleanup Settings support for enabling and disabling location providers:
LocationManagerService now listens for changes to settings,
making LocationManager.updateProviders() unnecessary.
Removed LocationManager.updateProviders()
Added Settings.Secure.setLocationProviderEnabled(), which is a thread-safe way
of enabling or disabling a single location provider.
This is safer than reading, modifying and writing the LOCATION_PROVIDERS_ALLOWED directly.
BUG=1729031
Original author: lockwood
Automated import of CL 144415
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 9637d474899d9725da8a41fdf92b9bd1a15d301e |
|
03-Apr-2009 |
Mike Lockwood <> |
AI 144372: Cleanup Settings support for enabling and disabling location providers:
LocationManagerService now listens for changes to settings,
making LocationManager.updateProviders() unnecessary.
Removed LocationManager.updateProviders()
Added Settings.Secure.setLocationProviderEnabled(), which is a thread-safe way
of enabling or disabling a single location provider.
This is safer than reading, modifying and writing the LOCATION_PROVIDERS_ALLOWED directly.
BUG=1729031
Automated import of CL 144372
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 2a73de7b21a89aa2ba4c254d28658b49793425b2 |
|
18-Mar-2009 |
Jean-Baptiste Queru <jbq@google.com> |
Merge commit 'remotes/korg/cupcake' into merge
Conflicts:
core/java/android/view/animation/TranslateAnimation.java
core/jni/Android.mk
core/res/res/values-en-rGB/strings.xml
libs/audioflinger/AudioFlinger.cpp
libs/surfaceflinger/LayerScreenshot.cpp
packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 9066cfe9886ac131c34d59ed0e2d287b0e3c0087 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| d83a98f4ce9cfa908f5c54bbd70f03eec07e7553 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 074da8f9aa424b25d84f4e4eb762ca534ea96716 |
|
25-Feb-2009 |
James Wylder <jbob0823@gmail.com> |
Change scope on SettingsProvider.mDatabaseHelper and DatabaseHelper
This change will allow the DatabaseHelper to be inheritted and extended
without the need to make futher changes to the existing implementation.
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| d24b8183b93e781080b2c16c487e60d51c12da31 |
|
11-Feb-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@130745
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| f013e1afd1e68af5e3b868c26a653bbfb39538f8 |
|
18-Dec-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Code drop from //branches/cupcake/...@124589
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|
| 54b6cfa9a9e5b861a9930af873580d6dc20f773c |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsProvider.java
|