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
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
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
Bug: 31602449
Test: verified adaptive brightness no longer varies with twilight with
"brightness_use_twilight" set to "1".
Change-Id: I6b5f7310020b2128c2b292414a205b6052270a0a
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
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
- 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
Test: Extracted the result via proto bug and as text and compared,
ran new CTS Setting incident test
Change-Id: Icf7b54b9c5c0a613dfd413ad575001c7b637ca01
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
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
In preparation for removing junit classes from the Android API
the legacy-test target will be removed from the
TARGET_DEFAULT_JAVA_LIBRARIES. This change adds explicit
dependencies on junit and/or legacy-android-test to ensure that
modules will compile properly once it is removed.
Bug: 30188076
Test: make checkbuild
Change-Id: I13e88297731253420e4e5f5291d503f13a39a156
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
System property ro.com.android.wifi-watchlist is automatically copied
into Settings.Secure.WIFI_WATCHDOG_WATCH_LIST which has been
deprecated and unused since API Level 16 (if not 14). Neither the
system property not its Settings.Secure counterpart is used anywhere.
This commit thus removes the automatic copying of the system property
into Settings.Secure.
Test: Device boots, Wi-Fi works
Bug: 33700679
Change-Id: If27149b863f41fed6c09b62145d5cfd96ae8e6de
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
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
MemoryIntArray was using the size of the undelying
ashmem region to mmap the data but the ashmem size
can be changed until the former is memory mapped.
Since we use the ashmem region size for boundary
checking and memory unmapping if it does not match
the size used while mapping an attacker can force
the system to unmap memory or to access undefined
memory and crash.
Also we were passing the memory address where the
ashmem region is mapped in the owner process to
support cases where the client can pass back the
MemoryIntArray instance. This allows an attacker
to put invalid address and cause arbitrary memory
to be freed.
Now we no longer support passing back the instance
to the owner process (the passed back instance is
read only), so no need to pass the memory adress
of the owner's mapping, thus not allowing freeing
arbitrary memory.
Further, we now check the memory mapped size against
the size of the underlying ashmem region after we do
the memory mapping (to fix the ahsmem size) and if
an attacker changed the size under us we throw.
Tests: Updated the tests and they pass.
bug:33039926
bug:33042690
Change-Id: Ib8e50afcdb5475123968572ac9696e8ed4031631
Set the flag default to false. This addition is for the
Android Wi-Fi Snooze project:
https://docs.google.com/document/d/1zewDZ6Ne-qH7zKFDtcSx55f9jPauZwT5VvOs1uVNXf8/edit#
Bug: 32920000
Bug: 32913119
Test: runtest --path
frameworks/base/packages/SettingsProvider/test/src/com/android/providers/settings/SettingsProviderTest.java
Change-Id: I597d5dd643e8044315cc6d7553ae5740485a0552
Bug: 32849428
* goog/cw-f-dev: (98 commits)
Revert "Catch KeyStoreException for setting profile lock"
Fix createConfirmDeviceCredentialIntent for wear for CTS.
Fix default dialog background colour for watch devices.
Catch KeyStoreException for setting profile lock
Add cross-links between FINE and COARSE location permissions. bug: 25371600
Fixed a bug with the emergency affordance in multi user
Zygote: Additional whitelists for runtime overlay / other static resources.
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Zygote : Block SIGCHLD during fork.
colors: add missing accent_material_{700,50} resources.
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Zygote : Block SIGCHLD during fork.
DO NOT MERGE ANYWHERE Revert "DO NOT MERGE ANYWHERE libhwui: make setSurface asynchronous"
...
Change-Id: I63468da5bfa21ed9ac5985bbdbf3a61d4c389aa0
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
