summaryrefslogtreecommitdiff
path: root/test-mock/src
AgeCommit message (Collapse)Author
2021-01-18Expose Context#sendStickyBroadcast(Intent, Bundle)paulhu
Bug: 177223402 Test: atest FrameworksCoreTests:ContextTest Test: atest CtsContentTestCases:ContextTest Change-Id: Ic85419934cf2c9df4e0f9cc287585b3296cec819
2020-12-16Remove set no parent in OWNERS in mock packageCharles Chen
Test: manual Bug: 174932174 Change-Id: I47b7e9cee86986dfcbbb03e0d9b5abc8fa84bc2e
2020-12-15Make everyone able to modify mock packageCharles Chen
Previously, this package was set to no owners. However, it broke the new owner rule on gerrit. See https://gerrit.googlesource.com/plugins/code-owners/+/master/resources/Documentation/how-to-use.md#no-code-owners-found for details. Test: manual Bug: 174932174 Change-Id: I6bd2c3947cffdf7637b4c06dfb54d1b39b81e40e
2020-12-14Add more OWNERS coverages(2/n)Charles Chen
Test: manual Bug: 174932174 Change-Id: Id6a4c60734f24a3d8fdec27b11baead550296441
2020-06-26Don't use impl lib of android.test.[mock|base|runners]Jiyong Park
The java_sdk_library modules are now added with 'default_to_stubs: true' so that their impl libraries are not used even when the clients don't have sdk_version property set. This will allow us to replace the direct references to the stub libraries of the java_sdk_library modules with the references to the modules themselves (e.g. android.test.base.stubs -> android.test.base) in many of the CTS tests without unintentionally exposing the private APIs in the impl lib. As part of the change, MockContentProvider.getIContentProviderBinder() now returns an anonymous Binder object instead of throwing an exception. This is to eliminate the need for clients to override the now inaccessible method to escape from the exception. Also, InstrumentationTestRunner.addTestListener method is added to the stub because it is used by several tests (MtpServiceTests, etc.) Exempt-From-Owner-Approval: cherry-pick from master Bug: 157007292 Test: m Merged-In: I14cf217f21fd3534c920c3a6336cf2d14c02e60c (cherry picked from commit b4e458d1063a3ece9a7f539ed6dbaeb6fb9c495d) Change-Id: I14cf217f21fd3534c920c3a6336cf2d14c02e60c
2020-03-26Report incorrect context usage in ViewConfigurationChris Li
Before, the documentation said that the passed context is an application context, which is incorrect to get the density, window metrics, and window manager. We should use visual context to get these instead. Bug: 151474461 Test: StrictModeTest#testIncorrectContextUse_GetViewConfiguration Change-Id: Iea28d727cafbb3ec8536742c6a0e594f73fe5a51
2020-03-10Give hidden API behavior to legacy apps.Jeff Sharkey
Starting in R, there is a new public API overload that delivers a flags argument. Some apps may be relying on a previous hidden API that delivered a userId argument, and this change is used to control delivery of the new flags argument in its place. There are dozens of these hidden API users are in the system UID, either in the system process or the Settings app, so we hard-code giving them the legacy behavior, since refactoring would be messy between internal and AOSP branches. Also adjust incoming and outgoing method signatures to use slightly more flexible Collection<Uri>, which has handy methods like contains() and isEmpty(). Bug: 150939131 Test: atest --test-mapping packages/providers/MediaProvider Test: atest FrameworksServicesTests:com.android.server.devicepolicy.DevicePolicyManagerTest Exempt-From-Owner-Approval: trivial refactoring Change-Id: If6a77449e19215cf1c60d4217e62fc04b0959bfc
2020-02-26[API Review] Expose sendOrderedBroadcastPeter Wang
with appOp as String and options as Bundle Bug: 139077993 Bug: 146423958 Test: Build Change-Id: I5325e08d60016741139251813a5df9b42f2efc82 Merged-In: I5325e08d60016741139251813a5df9b42f2efc82
2020-02-20Merge "Add async version of "canonicalize""Dmitri Plotnikov
2020-02-20Exempt-From-Owner-Approval: Report non-visual Context misuseAndrii Kulian
Make obtaining a visual service from non-visual Context instance report a strict mode violation and print the stacktrace. Make calling getDisplay() throw an exception if called on an instance that is not associated with a display. For existing usages introduce a new internal method that does not perform the verification until the usages are properly fixed. Bug: 128338354 Test: StrictModeTest#testIncorrectContextUse_GetSystemService Test: StrictModeTest#testIncorrectContextUse_GetDisplay Change-Id: Id25d590eca6e10066e55d7ed6436d3bc9e433beb
2020-02-19Add async version of "canonicalize"Dmitri Plotnikov
Fixes: b/147699082 Test: atest FrameworksCoreTests:android.content.ContentResolverTest Change-Id: I2e851839a454ad5eabc981c76774d03b57a1aa09
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
2020-01-31Merge changes from topic "add_bundle_to_window_context"Andrii Kulian
* changes: Exempt-From-Owner-Approval: Fix usages of WindowManager.getDefaultDisplay() in f/b Add bundle options to Context#createWindowContext API
2020-01-28Add bundle options to Context#createWindowContext APIAndrii Kulian
Add Bundle parameter to createWindowContext method to allow passing window-related options. Bug: 128338354 Test: Build, auto test Change-Id: I19cf9335068ecf94c9d94a99be0e8f1021f78e34
2020-01-28Add async version of getProviderMimeTypeDmitri Plotnikov
Fixes: b/147646960 Test: atest FrameworksCoreTests:android.content.ContentResolverTest Change-Id: I04c15ac008fe14b215f954af150226dc94f22232
2020-01-22Introduce WindowContext APIAndrii Kulian
Test: atest WmTests CtsWindowManagerDeviceTestCases Bug: 128338354 Change-Id: I9c9dfc5e7f4edd4c968e60d2ffcbb19b5c72a853
2019-12-16Add the root of crates by Context.getCrateDirFelka Chang
Context.getCrateDir() creates and returns the File for the root of the crates for the application context. Any child directories under the crates root in Context.getDataFile() is called the crate directory. For example: /data/user/0/com.exmaple.app/crates/IAmCratedFolder/decentFiles /data/user/0/com.exmaple.app/crates/IAmCratedFolder/decentDirs Context.getCrateDir return the crate dir --> /data/user/0/com.exmaple.app/crates/IAmCratedFolder The crate dir --> IAmCratedFolder The decent directories or files are not crated folders --> decentFiles, decentDirs Test: atest CtsOsTestCases:android.os.storage.cts.StorageCrateTest Bug: 141660526 Change-Id: If3ec1e121fb8f72bab5571d6190378e3ae208832
2019-11-27[Telephony Mainline] Exposed sendOrderedBroadcastPeter Wang
with appOp as String and options as Bundle Bug: 139077993 Test: Build, GsmInboundSmsHandlerTest, CdmaInboundSmsHandlerTest and WapPushOverSmsTest Change-Id: I60e21c7202d1bc7c5d28dfad2e2edde902f28a15
2019-11-15Extend insert/update/delete to provide extras.Jeff Sharkey
A few releases ago we added ContentResolver.QUERY_ARG_* constants to query() as a new best-practice that will help wean us off raw SQL arguments. (For example, a provider could add their own custom arguments like QUERY_ARG_INCLUDE_PENDING to cause the query to reveal pending items that would otherwise be hidden.) This change expands update() and delete() to accept those arguments. This change also expand insert() to accept extras too, as part of preparing to support an upcoming MediaProvider feature that will let apps place new media "adjacent" to an existing media item. (Sending that adjacent item through extras is cleaner than trying to send it through escaped query parameters.) Bug: 131643582 Test: atest CtsContentTestCases Change-Id: I436296155b9b5f371b4cbe661feaf42070285fcc
2019-11-13Allow sending of bulk Uri change notifications.Jeff Sharkey
MediaProvider makes heavy use of Uri change notifications, which currently need to be delivered one at a time through the Binder interface. To optimize this, allow callers to provide a collection of multiple Uris to notify with a single Binder call. Bug: 134170767 Test: atest cts/tests/tests/content/src/android/content/cts/ContentResolverTest.java Change-Id: Ifef778e88bb772b5580f70929c6f2e9c166d1c0e
2019-11-07System API: Context#registerReceiverForAllUsersMeng Wang
Bug: 141193711 Test: make Change-Id: Ie692d2ac27474b9fe11f5548bc504aa00c5ad53c
2019-11-01Expose Context.sendOrderedBroadcast with appopJordan Liu
Bug: 143100231 Test: atest ContextTest#testSendOrderedBroadcastWithAppOp atest ContextTest#testSendOrderedBroadcastWithAppOp_NotGranted Change-Id: Ia75d0db11f337769eaf3cf5436e09a7d38b0564c
2019-10-29Note with featureId from ContentProviderPhilip P. Moltmann
This takes the Context#getFeatureId from the calling context and pipes it all way through to the noteOp calls done by the content provider. Bug: 136595429 Test: atest CtsAppOpsTestCases (new test added to capture this case) TelecomUnitTests:CallLogManagerTest ContentProviderClientTest TelecomUnitTests:MissedCallNotifierImplTest TelecomUnitTests:BasicCallTests MediaInserterTest PreferencesHelperTest RankingHelperTest PinnedSliceStateTest FrameworksCoreTests:ContentResolverTest Change-Id: I53b1035626229c920b353509a5bece157b52fb51
2019-10-14Explicitly take flags in createContextAsUser()Makoto Onuki
Bug: 142472686 Test: atest android.content.cts.ContextTest#testCreateContextAsUser Change-Id: Id2e3d5ffe5887a4916e0872a7e85d62cbb439744
2019-10-10Add Context.createContextAsUser()Makoto Onuki
Without it, apps (mainline modules) will need to use createPackageContext..., which is a bit painful. Bug: 142472686 Test: atest android.content.cts.ContextTest#testCreateContextAsUser Change-Id: Id640e03862462724df1a4a3101f0b08faafba22f
2019-07-12Detailed ContentProvider permissions checks.Jeff Sharkey
The new MediaProvider design has an internal dynamic security model based on the value stored in OWNER_PACKAGE_NAME, so the OS always needs to consult the provider when resolving Uri permission grants. Blocking calls from the system process like this are typically discouraged, but this is the best we can do with the limited time left, and there is existing precident with getType(). For now, use "forceUriPermissions" as a proxy for determining when we need to consult the provider directly. Bug: 115619667 Test: atest --test-mapping packages/providers/MediaProvider Test: atest android.appsecurity.cts.ExternalStorageHostTest Change-Id: I1d54feeec93fbb4cf5ff55240ef4eae3a35ed068
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
2019-03-06Add Context.bindService with executor parameterBo Liu
Allow app to control the thread where ServiceConnection methods are called on. Bug: 111434506 Test: Used new bindContext method in chrome and checked callbacks are on the correct thread. Change-Id: I480e5bd6773a530fb9e8e73e3a2a2a88b76569ec
2019-01-26Add Cursor.{set,get}NotificationUris.Sudheer Shanka
Bug: 120879205 Test: manual Test: atest cts/tests/tests/database/src/android/database/cts/AbstractCursorTest.java Change-Id: If3be228dc6b08ea58d24c9209822f9d8c2348082
2019-01-05Add Downloads.Impl.COLUMN_MEDIASTORE_URI & DownloadColumns.Description.Sudheer Shanka
Entries from DownloadProvider are added to MediaStore Downloads collection. COLUMN_MEDIASTORE_URI will be used to track corresponding entries in MediaProvider. We can't re-use COLUMN_MEDIAPROVIDER_URI for this purpose because it is updateable by apps. Bug: 120876251 Test: atest DownloadProviderTests Test: atest cts/tests/app/src/android/app/cts/DownloadManagerTest.java Test: atest MediaProviderTests Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore* Change-Id: Ifd252c54f4ee739a31be2866896efac6696a088e
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-12-08Extract common methods into ContentInterface.Jeff Sharkey
Existing APIs that accept a ContentResolver are too restrictive when the caller has their own ContentProviderClient already bound and configured, so we're in the market for a solution to open those existing APIs to accept a wider range of inputs. The solution we've come up with is to introduce a super-interface which contains the common ContentProvider APIs, and then make ContentProvider, ContentResolver, and ContentProviderClient all implement that interface for consistency. After this change lands, we can then safely relax existing APIs to accept this new ContentInterface, offering a clean path to solving the problem outlined above. Bug: 117635768 Test: atest android.content.cts Test: atest android.provider.cts Change-Id: Ic5ae08107f7dd3dd23dcaec2df40c16543e0d86e Exempted-From-Owner-Approval: keep tests working
2018-11-21Add new API to performing grouping and ordering of bindings.Dianne Hackborn
This will allow apps to better manage many isolated processes, telling the system how they are grouped together (so should be managed as one related entity within the LRU cache) and fine-tune the ordering within that group. The API is not yet tested... though in theory it is implemented. But the implementation done for that also fixes a *lot* of problems with activity LRU management that, even without groups, should make the ordering of processes in the LRU list much more consistently match how recently the user has interacted with it. Also clean up some of the new dumpsys output in the activity manager: move the new sections to before the process output (so it is still easy to see the process state at the end of the output), and add and document the command line options for controlling them. And add a new "lru" section that gives a clear view of what is going on with the raw LRU list. An upcoming change will add tests for the new grouping functionality, and probably some fixes resulting from that. Test: atest CtsAppTestCases:ServiceTest Bug: 111434506 Change-Id: I1f6b6b9de66ccde1573e1a0e9615e8c5f8e6c0d7
2018-11-13Implement naming of isolated service bindings.Dianne Hackborn
This allows clients to run multiple instances of the same manifest service declaration. It only works for isolated services, to avoid too much abuse temptation. This is part of the "Chrome site isolation" work, to allow chrome to have many more render processes running and help it manage them. Bug: 111434506 Test: atest CtsAppTestCases:ServiceTest Change-Id: I22e65758678a07075ed32ed6463082ddf846d3a4
2018-10-15Add Context.getDisplayId() to avoid possible IPCYohei Yukawa
ContextImpl has an internal rule that when ContextImpl#mDisplay is null the Context is associated with the default display. The problem is that, as discussed in Bug 117709581, when ContextImpl#mDisplay is null ContextImpl#getDisplay() tries to get some non-null Display object by making an IPC to the system server, which is redundant when the display ID is the only thing that the caller wants to know. By having an @hide method Context.getDisplayId(), we can ensure that display ID can be obtained without any IPC. This enables us to re-submit my CL [1] that aimed to instantiate InputMethodManager (IMM) for each display but then got reverted due to a performance regression (Bug 117434607). There should be no developer-observable behavior change. [1]: I7242e765426353672823fcc8277f20ac361930d7 c53d78e992694e471ddaae73f9a30977db9cdb75 Fix: 117712745 Test: atest FrameworksCoreTests:android.content.ContextTest Test: prebuilts/checkstyle/checkstyle.py -f \ frameworks/base/core/tests/coretests/src/android/content/ContextTest.java Change-Id: I2534530a5ce90e2620c5039d793a6454a0a1e154
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-04-27Require READ_CALL_LOG permission to see phone numbers in phone state.Tyler Gunn
Incoming and outgoing call phone numbers are visible in the phone state broadcast and via the PhoneStateListener. To enhance user privacy, change to require the READ_CALL_LOG permission in order to receive the call phone numbers. This means to see phone numbers: 1. android.intent.action.PHONE_STATE - requires READ_PHONE_STATE and READ_CALL_LOG permission. 2. PhoneStateListener#onCallStateChanged - now required READ_CALL_LOG permission. To support this new behavior, added sendBroadcastAsUserMultiplePermissions method to context to allow sending the broadcast to all users while requiring the two permissions. Bug: 78650469 Test: Created PHONE_STATE broadcast receiver in test app and verified that when no permissions are granted, the phone number is empty for incoming and outgoing calls. Test: Granted Phone state permission to test app and verified that phone number is not populated. Test: Granted test app read call log permission and verified that phone number is populated. Test: Created PhoneStateListener in test app and verified that when no permissions are granted, phone number is empty for incoming and outgoing. calls. Test: Granted read call log permission to test app and verified that both the incoming and outgoing numbers are populated. Change-Id: I857ea00cc58a0abbb77960643f361dd6dd9c8b56
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-09Add apis needed for android.test.legacyPaul Duffin
The long term goal of removing junit and dependent android.test classes from the android.jar is the removal of the runtime libraries that provide those classes. A key part of the strategy for migrating APKs off the runtime libraries is the android.test.legacy library which APKs can statically include in place of the runtime dependencies without having to change their source code. The longer term goal is for all tests to migrate from these classes altogther and to use the Android Test Support Library instead but that will require significant changes to the test source code. In order for it to be safe to statically include android.test.legacy in an APK it cannot use any internal APIs. This change adds the additional classes and methods needed to the android.test.mock API library. The additions are all marked as deprecated to try and avoid developers from using them in new tests. It also marks the AccountManager constructor used by MockAccountManager with the android.annotation.MockApi so that it is included in the mock stubs libraries against which the android.test.mock.stubs[-system] libraries build. Bug: 30188076 Test: make checkbuild Change-Id: I85417cc328cab898ab93b9b726648f4232555324
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-13Start accepting Executors instead of Handlers.Jeff Sharkey
After discussion in API council, our new best-practices are to have developers provide an Executor to dispatch callbacks/listeners on, instead of the previous guidance of using a Handler. Define Context.getMainExecutor() to easily obtain an Executor associated with the main thread of application. This allows new APIs to require a @NonNull Executor. Also define a new @CallbackExecutor auto-doc annotation that explains background and points developers at new Context method above. Test: cts-tradefed run commandAndExit cts-dev -m CtsContentTestCases -t android.content.cts.ContextTest#testMainLooper Test: cts-tradefed run commandAndExit cts-dev -m CtsContentTestCases -t android.content.cts.ContextTest#testMainExecutor Bug: 70348426 Change-Id: I536892bcd80fcfba1bb1ddf67648c08a26d7ddd2
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