This CL adds the basics to set black, dark gray or light gray list
enforcement, rather than just black as before. It's not possible to
actually set the policy per-package yet.
PackageDexOptimizer still uses a single bit, for API checks on/off, rather
than the new enum. It assumes blacklist enforcement internally. This can
be improved in a follow up CL.
(cherry-picked from commit e52130ae4c)
Test: m
Test: Boot device
BUG: 73337509
Change-Id: Ieb4bd9cc439c6a5b8fb9424d8902d8b46aec309f
Merged-In: Idd73c9938592c5c4d67cfb9efefdffed0dd5f262
Added new broadcast actions MY_PACKAGE_SUSPENDED and
MY_PACKAGE_UNSUSPENDED, which are sent to the package that is affected
by the suspend state change. A suspended package also receives a bundle
of app extras to pass more information. This makes it easier for
packages to deal with being suspended/unsuspended.
Also updated some existing documentation to make it clearer.
Test: atest com.android.server.pm.SuspendPackagesTest
Bug: 75036698
Change-Id: I772cf0c023669bc946e07ced4ebccfa74f6835b2
For compatibility, had to continue returning null when drawables could
not be decoded. Fix annotation to match pre-P behavior (the behavior
was reverted separately).
Fixes: 69543526
Test: make
Partial revert of Ib01eca970c5c9969998ce5b265b120aa7048b41a
Change-Id: I5f612f47793c3f04cf9874e13efdc13397ddd4e8
Test: I solemnly swear I tested this conflict resolution.
Merged-In: Idd73c9938592c5c4d67cfb9efefdffed0dd5f262
Change-Id: I3d1aeb30b755ca05f32dcd3c46335d1611e0bb50
This CL adds the basics to set black, dark gray or light gray list
enforcement, rather than just black as before. It's not possible to
actually set the policy per-package yet.
PackageDexOptimizer still uses a single bit, for API checks on/off, rather
than the new enum. It assumes blacklist enforcement internally. This can
be improved in a follow up CL.
(cherry-picked from commit e52130ae4c)
Test: m
Test: Boot device
BUG: 73337509
Change-Id: Ic0d5b8fa631c2bd583b6fc52b2ee3708c8113f59
Merged-In: Idd73c9938592c5c4d67cfb9efefdffed0dd5f262
The Telephony Data Service is a privileged service
that provides Data capabilities *to* Telephony. A
data service that provides IWLAN may also use WiFi
as an underlying connection that tunnels Telephony
data services over WiFi using IPsec. The carrier-
config-driven permissions model causes the
framework to bind to an appropriate Telephony Data
Service, for a given carrier, and that Data Service
is responsible for providing Cellular data. Thus,
The TelephonyDataService needs sufficient
permissions to access cellular info necessary for
performing signalling for IWLAN. This includes
Phone state information and location information
such as the current Wifi access points and the
current cell towers. In addition, a Telephony
Data Service may require access to IPsec if the
data service uses the Android API to establish
IPsec, which is optional today.
Bug: 66955045
Test: wip
Merged-In: Ibe4f7806a47e2a50999376ff0a5a07dc5b332953
Change-Id: Ibe4f7806a47e2a50999376ff0a5a07dc5b332953
Changed the existing hidden api setPackagesSuspendedAsUser to a system
api setPackagesSuspended that can be called by apps with either
MANAGE_USERS or SUSPEND_APPS permission. Additionally, the suspending
app can now specify optional extra information meant to be used by the
suspended apps and the launcher to deal with this state.
The following other APIs are added:
- isPackageSuspended(): Apps can query whether they are in a suspended
state
- @SystemApi getPackageSuspendedAppExtras(String): Apps with permission
SUSPEND_APPS can get the appExtras passed to PM when suspending the
app.
- @SystemApi setPackageSuspendedAppExtras(String, PersistableBundle):
Apps with permission SUSPEND_APPS can update app extras for a
suspended package.
- getPackageSuspendedAppExtras(): Apps can call to get the appExtras
passed in to PM when they were suspended.
Test: Can be run via:
atest com.android.server.pm.PackageManagerSettingsTests
atest com.android.server.pm.PackageUserStateTest
atest com.android.server.pm.SuspendPackagesTest
Bug: 74336673
Change-Id: I3b9ed2c8478b34ee2e8986f5f5fddb2839d102e3
This reverts commit 1bc41d4c7d.
Reason for revert: Re-submitting after fixing tests.
Test: See original change
Change-Id: Idd73c9938592c5c4d67cfb9efefdffed0dd5f262
The service is meant to replace the PendingIntent based API. Once all
users of the PendingIntent based API switched the PendingIntent based API
will be removed.
To have as little as possible impact on the whole SoundTrigger framework
the RemoteSoundTriggerDetectionService class implements the same
interface as the PendingIntent based class. Hence the exising code has
very little change. Further once the old code can be removed the amount
of changed (and added) code is limited.
The RemoteSoundTriggerDetectionService -> SoundTriggerDetectionService
is a vanilla as possible service implementation. The special behaviors
are:
- The system holds a wakelock while service operations are in progress
and the service is bound as foreground. Hence the service can e.g.
listen to the microphone.
- Service operations have a certain amount of time they are allowed to
run. Once every operation is either finished or the the operation
exceeded the allotted time, the system calls onStopOperation for each
still pending operation. This is a similar model as for the commonly
used JobService.
Please note that if the time allowed for an operation is 15s and
op1 was run as 0si, and op1 was run at 5s, the service is allowed to run
until 20s. Hence _both_ onStopOperations will happen at 20s. This is
done for ease of implementation but should not give the service more
power than calling onStopOperation exactly 15s after each operation is
triggered.
- If an operation is done before the allotted time is reached, the
service can declare the operation as finished manually by calling
onOperationFinished. This is a call back into the system, hence a
'client' binder is sent to the service. If the operation is finished
by calling this method onStopOperation will not be called.
- As the service instance might be killed and restored between
operations we add a opaque bundle 'params' to each operations. The users
of the API can use this to send data from the start command to the
operations. It can also just be set to null. The params are not meant to
store changing state in between operations. Such state needs to be
persisted using the regular methods (e.g. write it to disk)
- A service can be used for multiple recognition sessions. Each
recognition is uniquelity defined by its sound model UUID. Hence each
operation gets at least tree arguments: Operation ID, sound mode UUID, params
- As a small optimization the params are cached inside of the service
instance.
The time allowed for each operation is in a @SystemAPI global setting,
so the service can make sure it finishes the operations before they are
stopped. It might take some time to deliver the operations via the
binder, hence it is not recommended to try to use every last ms of
allotted time.
Test: atest SoundTriggerDetectionServiceTest (added in separate CL)
atest android.provider.SettingsBackupTest
Change-Id: I47f813b7a5138a6f24732197813a605d29f85a93
Fixes: 73829108
This CL adds the basics to set black, dark gray or light gray list
enforcement, rather than just black as before. It's not possible to
actually set the policy per-package yet.
PackageDexOptimizer still uses a single bit, for API checks on/off, rather
than the new enum. It assumes blacklist enforcement internally. This can
be improved in a follow up CL.
Test: m
Test: Boot device
BUG: 73337509
Change-Id: I582bbb3ae63b4ef1c1f2af78930d153df7936075
Describe that AbstractThreadedSyncAdapter.onUnsyncableAccount should return
immediately and call it on main thread.
Test: atest android.content.cts.AccountAccessSameCertTest
android.content.cts.DeferSyncTest
android.content.cts.ContentResolverSyncTestCase
com.android.cts.content.CtsSyncAccountAccessOtherCertTestCases
Fixes: 73750859
Change-Id: Ie9e1aefafe3a4a1b3f0fe8a65803554f07a94c42
