summaryrefslogtreecommitdiff
path: root/test-mock/src/android/test/mock/MockPackageManager.java
AgeCommit message (Collapse)Author
2020-02-04Make TCS.getDefaultTextClassifierImplementation returns a ...Tony Mak
SystemTextClassifier that is backed by ExtServices 1. The default textclassifier is always provided by config_servicesExtensionPackage (i.e. ExtServices) 2. OEM can specify a system text classifier by specifying config_defaultTextClassifierPackage. 3. System text classifiers can get an instance of the default textclassifier by calling TCS.getDefaultTextClassifierImplementation(), so that they can add their customization on top of the default TCS. 4. If config_systemTextClassifierPackage is set, the specified package is used to process requests from apps and the platform. Otherwise, the default textclassifier is used. 5. For testing and droidfooding purpose, text classifier service package can be overridden. If the overridden package is neither the default one nor the system one, the package is considered as a untrusted text classifier, which can only see requests from itself. Test: m mts && mts-tradefed run mts-extservices Test: Not setting config_defaultTextClassifierPackage. Select some text and make sure smart selection works. Run dumpsys textclassification to make sure the default TCS is bound. Test: Setting config_defaultTextClassifierPackage and repeat the above. Make sure the specified OEM text classifier is used. Test: Set the service override config to be ExtServices. Run dumpsys textclassification to make sure everything is unbound. Select some text and make sure ExtServices is bound. Test: Set the service override to be AiAi and repeat the above. Test: Set the service to be something invalid and repeat the above. Observe that no TC is bound and fallback to NO_OP. BUG: 148049185 Change-Id: Ia2fb549fda49363e0d0ebc4b7e0d31cb76e11ee0 Make TCS.getDefaultTextClassifierImplementation returns a ... SystemTextClassifier that is backed by ExtServices 1. The default textclassifier is always provided by config_servicesExtensionPackage (i.e. ExtServices) 2. OEM can specify a system text classifier by specifying config_defaultTextClassifierPackage. 3. System text classifiers can get an instance of the default textclassifier by calling TCS.getDefaultTextClassifierImplementation(), so that they can add their customization on top of the default TCS. 4. If config_systemTextClassifierPackage is set, the specified package is used to process requests from apps and the platform. Otherwise, the default textclassifier is used. 5. For testing and droidfooding purpose, text classifier service package can be overridden. If the overridden package is neither the default one nor the system one, the package is considered as a untrusted text classifier, which can only see requests from itself. Test: m mts && mts-tradefed run mts-extservices Test: Not setting config_defaultTextClassifierPackage. Select some text and make sure smart selection works. Run dumpsys textclassification to make sure the default TCS is bound. Test: Setting config_defaultTextClassifierPackage and repeat the above. Make sure the specified OEM text classifier is used. Test: Set the service override config to be ExtServices. Run dumpsys textclassification to make sure everything is unbound. Select some text and make sure ExtServices is bound. Test: Set the service override to be AiAi and repeat the above. Test: Set the service to be something invalid and repeat the above. Observe that no TC is bound and fallback to NO_OP. BUG: 148049185 Change-Id: Ia2fb549fda49363e0d0ebc4b7e0d31cb76e11ee0
2019-04-07Restricted permission mechanism - frameworkSvet Ganov
This change adds a mechanism for restricting permissions (only runtime for now), so that an app cannot hold the permission if it is not white listed. The whitelisting can happen at install or at any later point. There are three whitelists: system: OS managed with default grants and role holders being on it; upgrade: only OS puts on this list apps when upgrading from a pre to post restriction permission database version and OS and installer on record can remove; installer: only the installer on record can add and remove (and the system of course). Added a permission policy service that sits on top of permissions and app ops and is responsible to sync between permissions and app ops when there is an interdependecy in any direction. Added versioning to the runtime permissions database to allow operations that need to be done once on upgrade such as adding all permissions held by apps pre upgrade to the upgrade whitelist if the new permisison version inctroduces a new restricted permission. The upgrade logic is in the permission controller and we will eventually put the default grants there. NOTE: This change is reacting to a VP feedback for how we would handle SMS/CallLog restriction as we pivoted from role based approach to roles for things the user would understand plus whitelist for everything else. This would also help us roll out softly the storage permisison as there is too much churm coming from developer feedback. Exempt-From-Owner-Approval: trivial change due to APi adjustment Test: atest CtsAppSecurityHostTestCases:android.appsecurity.cts.PermissionsHostTest Test: atest CtsPermissionTestCases Test: atest CtsPermission2TestCases Test: atest RoleManagerTestCases bug:124769181 Change-Id: Ic48e3c728387ecf02f89d517ba1fe785ab9c75fd
2018-12-31Add RollbackManagerServiceRichard Uhler
This change adds RollbackManagerService as a new system service for managing apk level rollbacks. To work properly this requires additional selinux policy changes. Fails gracefully in case of selinux denials, until we have a chance to sort out the proper selinux policy. Bug: 112431924 Bug: 116512606 Test: atest RollbackTest, with selinux enforcement off. Test: atest CtsPermission2TestCases:PermissionPolicyTest Change-Id: Id72aae9c4d8da9aaab3922ec9233ba335bc0198f
2018-07-24Always review permissions before <M app is started the first timePhilip P. Moltmann
This splits the - review permissions - individually control permissions - consent to manage wireleess (wifi + bluetooth) properties. Almost all code cares only for the first and it is now always true. Hence a lot of code can be simplified. Bug: 110431654 Test: atest PermissionsHostTest started pre-M app Change-Id: I733cd476ccd0bf5eaa59e9a9506db34f57c6baee
2018-03-22Merge "APIs to suspend packages with SUSPEND_APPS permission" into pi-devTreeHugger Robot
2018-03-22APIs to suspend packages with SUSPEND_APPS permissionSuprabh Shukla
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
2018-03-20Add SoundTriggerDetectionServicePhilip P. Moltmann
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
2018-02-20Shortcut permissions for default text classifierMakoto Onuki
- Add two shortcut related permissions as SystemAPI for the default text classifier. - The default text classifier package name still comes from the system resource. Bug: 73083596 Bug: 71555985 Test: atest CtsPermission2TestCases Test: Manual test with a test package, with the following in config.xml <string name="config_defaultTextClassifierPackage" translatable="false">com.example.android.pm.shortcutlauncherdemo</string> Change-Id: I19081d9d6ba0b33eb25d19aa55b4fe2f26a75897
2018-01-24Merge "Add API to expose signing certificate proof-of-rotation."TreeHugger Robot
2018-01-23Add API to expose signing certificate proof-of-rotation.Daniel Cashman
With the addition of APK Signature Scheme v3, the platform now can support key rotation by using the proof-of-rotation provided by the new scheme. Create a new API which allows checking of the entire provided history of an APK's signing certificates, not just the current signer. This should allow for changes of APK signing certificates without fear of losing access to resources that would have been provided under the old signing certificate. Change getPackageInfo(GET_SIGNATURES) to return the oldest signing certificate in the chain so that apps which do programmatic checks, but are not updated to use the new API, still get the same information they would have gotten had there been no rotation. Bug: 64686581 Test: Builds, boots. Change-Id: I8982fd4cce60f5d85a6180d157a6e2a661b1a6d7
2018-01-18Adding a new category to mark car-optimized launcher activityRoberto Perez
Test: TBD Bug: 70681347 Change-Id: I81ea7f9f3021e8a9d25fa980a8687d66765469c5
2018-01-11Implement harmful app warning at activity launchBen Gruver
Bug: 63909431 Test: manual Change-Id: I8a5497421cb8130af8cdd5129b0f6e1707a01e36
2018-01-04Use modern install method in backup servicePhilip P. Moltmann
Test: adb backup -apk myApp -f backup ; adb restore backup Change-Id: I2bbcb0487ecc525a6dc8a2693b15ce624db275b0
2017-12-04Add SystemApis to expose runtime profile informationCalin Juravle
The API allows a system apps which acquired {@code android.permission.READ_RUNTIME_PROFILE} to snapshot the runtime profiles of installed packages. The API is implemented in a new service class (AndroidRuntimeManager) accessible from the context using context().getPackageManager().getAndroidRuntimeManager(). The main functionality is exposed as a one way call into the AndroidRuntimeManager with the result being posted on a callback. The profile is available to the caller as a read-only ParcelFileDescriptor. This CL only adds the API interfaces and validation. It does not fully implement the functionality. oneway void snapshotRuntimeProfile(in String packageName, in String codePath, in ISnapshotRuntimeProfileCallback callback) Bug: 30934496 Test: gts-tradefed -m GtsAndroidRuntimeManagerHostTestCases Change-Id: Iaa6be4715840f24508acba3162ea9c1ab725bd38
2017-11-16Remove one legacy install pathPhilip P. Moltmann
Also removed everything needed only for this path Test: Installed app via package installer, adb, google play store Bug: 65261282 Change-Id: Ia8a03fa5900687cd2adf844ba7e6c07e0537382e
2017-11-16Separate android.test.mock from test-runner sourcePaul Duffin
Extracts the source for the android.test.mock library from the frameworks/base/test-runner directory into its own frameworks/base/test-mock directory. They are already treated separately at runtime and compile time so this just makes the separation complete. Bug: 30188076 Test: make checkbuild Change-Id: I20e5b06ba79677e76117c82e9f9e2ecd15e5fed6