- Check consolidated zen policy in volume dialog, seek bar volumizer
and ZenModeControllerImpl instead of default notification policy
- Save ZenPolicy changes on restore
Test: atest ZenModeHelperTest
Test: atest ZenModeControllerImplTest
Bug: 111475013
Change-Id: I43b6dc8c6453739c50c874fe37415d425223d8c4
In PermissionManagerService and DefaultPermissionGrantPolicy.
This mirrors what the permission controller is doing. Better make sure
all modules changing app-ops for runtime permissions do it the same way.
Test: Looked at pre-grants after boot, changed permissions after boot
Change-Id: I88386ec6842324b28ab408ea5cd113c9cc7de9fe
This change adds simple APIs to watch for noted ops. We are now
reporting a callback for every note which could lead to too many
call but until this is found to be the case we stick to the simple
solution. We already have APIs to watch started and stopped ops
which in theory could have the same frequence as noted ops, so
this is consistent to our approach.
bug:117617221
bug:119323172
Test: atest androidx.test.runner.AndroidJUnitRunner
Change-Id: I46c4b00e765eb14df8c30471d2b80dda905b8125
This is often known by the system, though not always. But when
we do know it, it is really useful to maintain that info so we can
do queries like "give me all of the associations that package X is
involved with".
Bug: 121146315
Test: manual
Change-Id: I0dd7aeb9147ecfd65a510d3b2a8bb4a0fbab57e3
Add an optional parameter -user to provide ID of the user for which to
run backup/restore operation. Add robolectric test to verify the
new parameter is proccessed correctly.
Bug: 119908153
Test: 1) atest BackupTest
2) atest BackupManagerServiceTest
3) atest TrampolineTest
4) atest GtsBackupTestCases
5) atest GtsBackupHostTestCases
6) Manual:
- Run "adb backup -all" and verify that backup is successfull
- Run "adb restore" and verify that restore is successfull
- Run "adb backup -all -user 10" and verify that backup faield as
it's only currently supported for system user
- Run "adb restore -user 10" and verify that restore failed as it's
only currently supported for system user
Change-Id: I6dbf9c87eedd5a72da0446beff7d2551f98f2654
And replace it with something more battery friendly!
Test: CTS, runtest systemui-notification
Bug: 111474881
Change-Id: I45af94135fb8d2de050d5f7baaa9724b95bb1907
- Get rid of activity-level events.
- Renamed InteractionSessionId and InteractionContext to
ContentCaptureSessionId and ContentCaptureContext (and made them public)
- Create the explicit concept of ContentCaptureSesssion (and moved notification
APIs to it).
- Added APIs to let apps create new sessions (not implemented yet).
- Added APIs to remove user data based on some context properties (like URI).
The reasoning behind this change is to let app developers explicitly associate
the captured content with some app-level domain (and also let the app ask the
service to clear such data at user's request). For example, a browser app
(and WebView) can use these APIs to associate the content capture events with
the URL being rendered.
Bug: 117944706
Fixes: 121034139
Test: atest CtsContentCaptureServiceTestCases
Test: m update-api && m
Change-Id: I7841da303b6a39c825651b03a07e3081fbd0bdf5
Initial prototype disabling location/sensors and enabling airplane mode.
Camera/Mic will come in a followup.
Test: manual
Bug: 110842805
Change-Id: I26132fcc9ffea83e3e78a0e54882d23c99ee590c
Currently when an ActivityView is removed/released, any remaining
tasks on the display are moved to the main display. This change
causes those tasks to be destroyed instead.
Bug: 111236845
Test: manual, built and tested with ActivityView SystemUI plugin
Change-Id: Ifaa9df6fab05ce82e1bad4e2f5a19c4c7476aec6
DropBox and EventLogger provide hooks for use by framework to intercept
messages sent by libcore. However, neither of these mechanisms are
actually used by libcore so there is no point in framework code using
it.
Bug: 119748341
Test: make checkbuild, flash
Change-Id: I9dbd1b6dea92f7441efb6d0a579efd13bc0e5139
Implements the PackageManager's getModuleInfo and getInstalledModules
API. These APIs are now backed by XML metadata that's parsed from a
"module metadata" provider package. The package name for the module
metadata package is stored in the config_defaultModuleMetadataProvider
config value.
The module metadata provider must contain a <metadata> entry for its
<application> tag. The meta-data entry must contain a single key
android.content.pm.MODULE_METADATA whose value is a reference to an
XML resource that contains metadata about the list of modules on a
given device.
The XML document must consist of a single top level <module-metadata>
element with one or more children. Each of these children are <module>
elements. The <module> elements must contain each of the following
attributes :
name : A resource reference to a User visible package name, maps to
ModuleInfo#getName
packageName : The package name of the module, see ModuleInfo#getPackageName
isHidden : Whether the module is hidden, see ModuleInfo#isHidden
Example :
<module-metadata>
<module name="@string/resource" packageName="package_name" isHidden="false|true" />
<module .... />
</module-metadata>
The module metadata is parsed eagerly and cached during system server
startup.
Test: atest FrameworksServicesTests:com.android.server.pm.ModuleInfoProviderTest
Change-Id: I0251c3f7429c42e3cce863eeeea792579dffecfb
