- 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
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
- When Accessibility is turned on, Android Wear devices become unusable.
Add an option to disable animations, will be disabled in an overlay.
Bug: 24985771
Change-Id: If5fc44705d56579b305abd48a0d820f306b9be10
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.
The split ambient settings default to on - which is a bad experience
if the user explicitly turned it off before the split.
Change-Id: I346a53b0dc9cdf578c238113f4f33056ba0f3aea
Merged-In: I986d35a1a28e97f4c8d7d3d47ed5658e1836a44f
Fixes: 32332195
Test: Flash angler to NYC, disable ambient, upgrade to NYC-MR1, check if "Lift to check phone" is still off.
- 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
