Remove code that let these components be replaced by external
processes.
Bug: 33006669
Bug: 34106436
Test: manual. reboot device, play music, change volume,
view notifications
Change-Id: I458f11537ab9db6f23735487513815553004613f
This change saves and loads a different brightness setting when the user
goes in and out of VR Mode.
Bug: 30984614
Merged-In: Ie5578bbd6ea346f0eb34fe4abbfd604a5d7c0c93
Change-Id: Ie5578bbd6ea346f0eb34fe4abbfd604a5d7c0c93
This change saves and loads a different brightness setting when the user
goes in and out of VR Mode.
Bug: 30984614
Change-Id: Ie5578bbd6ea346f0eb34fe4abbfd604a5d7c0c93
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
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: I8c23b145d4f8ee0de2f29dedaa4641ac59343d6a
VisualVoicemailService can be implemennted by the default dialer to
provide a visual voicemail client similar to the OMTP visual voicemail
spec.
Other APIs such as the SMS filter and hidden text SMS sending are made
public and consolidated into the service interface.
Test: make. CTS tests in a follow up CL
Change-Id: Ib5e9aa15fc098f4c13b15e5dbecf9ab646e0e400
Test: IpConnectivityMetricsTest passes. Also manually changed the new
setting and verified the buffer size is as expected after flushing the
buffer.
Bug: 32198637
(cherry pick from commit 05686dbb6b)
Change-Id: Ie7ca1638533479601c5983bb6e54705003561b6c
Test: IpConnectivityMetricsTest passes. Also manually changed the new
setting and verified the buffer size is as expected after flushing the
buffer.
Bug: 32198637
(cherry picked from commit 05686dbb6b)
Change-Id: Iefbeac3a688b260fb3f92dfe0bfd9db28e26749d
* changes:
DO NOT MERGE: [CS] Remove timeout event after first available
DO NOT MERGE: ApfTest: tag tests with @SmallTest or @MediumTest
DO NOT MERGE: Unbreak TetherInterfaceStateMachineTest.
DO NOT MERGE: Move the connectivity tests to frameworks/base/tests/net.
DO NOT MERGE: De-guava BroadcastInterceptingContext and move it to testutils.
DO NOT MERGE: Move FakeSettingsProvider to a common location.
DO NOT MERGE: ConnectivityServiceTest: mark flaky test as such
DO NOT MERGE: Add option to skip and avoid captive portals.
DO NOT MERGE: ApfFilter: use elapsedRealTime for RA lifetime
DO NOT MERGE: Do not synchronize boolean reads/writes
DO NOT MERGE: ApfFilter: systematically use u8, u16, u32 getters
DO NOT MERGE: Add fuzzing tests to ApfFilter RA processing
DO NOT MERGE: Support timeouts for requestNetwork() invocations.
DO NOT MERGE: Silence the obnoxious MTU 0 error message that occur when no MTU is specified for a given network.
Test: ConnectivityServiceTest updated with test cases.
Test: Manually tested against att-wifi in B42.
Bug: 30222699
(cherry picked from commit be96da11cc)
Change-Id: I90c0f97fe0e41de4059bceae7b56ab3a70145696
Add Payload and PayloadType to the SearhIndexablesContract to support
the new Search architecture in Settings Search.
Change-Id: I07e411ead11d420c19c737fad79d459f44288681
Test: SettingsUnitTests
Bug: 33390556
This CL updates the information shown in Quick Settings when a device
is managed by a Device Owner and adds a "learn more" link that takes
the user to the Enterprise Privacy page in Settings.
Bug: 32692748
Bug: 25779452
Test: runtest --path frameworks/base/packages/SystemUI/tests &
runtest --path frameworks/base/core/tests/coretests
Change-Id: I8cbb6f2bb5c6da29ae581b6dcf7a01b1a4f2af2b
This flag enables the NetworkScoreService.requestRecommendations API,
defined in b/32909424.
Bug: 32913919
Bug: 32909424
Test: runtest --path
frameworks/base/packages/SettingsProvider/test/src/com/android/providers/settings/SettingsProviderTest.java
Change-Id: If592e4a2ec574929aa0c829c39ad4ce9b0317805
As part of fixing a recent security issue, DownloadManager now needs
to issue Uri permission grants for all downloads. However, if an app
that requested a download is upgraded or otherwise force-stopped,
the required permission grants are removed.
We could tell DownloadManager about the app being stopped, but that
would be racy (due to background broadcast), and waking it up would
degrade system health. Instead, as a special case we now only
consider clearing DownloadManager permission grants when app data
is being cleared.
Bug: 32172542, 30537115
Test: builds, boots, app upgrade doesn't clear grants
Change-Id: I7e3d4546fd12bfe5f81b9fb9857ece58d574a6b9
(cherry picked from commit 23ec811266)
