Its for support lib expansion in the future, not for dev use.
Bug: 68378561
Test: atest cts/tests/tests/slice
Change-Id: Ifc73e56c391bd4abed3b8db3c597d7dc794c1a3c
This is in preparation for sliders, also add some hints/types that
will be used for sliders.
Test: atest cts/tests/tests/slice
Bug: 68378584
Change-Id: I8f6a8bb7c80854b51c421a437318975f517a2169
- Also unhide setKeepUninstalledPackages
- installExistingPackage accpets delegation API because all app
managemnet PIs did the same, including setKeepUninstalledPackages and
enableSytemApp
Bug: 70017947
Bug: 65842106
Test: Install apps already installed in u0 in shared user should succeed
Test: Install apps in setKeepUninstalledPackages cache in shared user
should succeed
Test: Install apps via delegated package should succeed
Test: Install apps via unaffiliated profile owner should fail
Test: Install apps not installed in any user or in APK cache shoudl fail
Change-Id: Iba563b2050abd0d1f46bfa06cfc0526b7b476b3b
Bug: 67580550
Test: The AP returns false in primary user.
Test: Create ephemeral user with createAndManageUser, ensure the API return true.
Change-Id: I1e670ca8a8c6171ddb94a1e4b1cb1a958f12919d
Behaves pretty much the same as @IntDef, but now supports "suffix"
in addition to "prefix" when matching constants.
Test: manual docs output looks sane
Bug: 70406696
Change-Id: I35064b0f9f36f1f13ccdb40302d818a004014f15
In the same bit of code, fix a system restore issue: in the
course of setup + restore, we reestablish permission grants and
notification state up front for the to-be-restored app, and
then bring in its data. However, a data wipe is part of the
prologue for that data delivery -- so we were inadvertently
unwinding the permission grants and notification state restore
that we'd just performed. Now, we distinguish the restore flow
from other clear-data operations so we don't unwind that operation.
Finally take the opportunity to elide a lot of copypasta code into
a single predicate-driven implementation.
Bug: 67508896
Bug: 69538432
Test: atest android.app.cts.AlarmManagerTest
Change-Id: I15c912c3c99645599ae9bd6fb7337fa86b4e5757
Tidy up changes for timezone update code:
1) Remove some TODOs
2) Fix some logging
3) Remove ClockHelper in favor of java.time.Clock /
SystemClock.elapsedRealtimeClock()
No functional changes intended.
Bug: 31008728
Test: PTS: run pts -m PtsTimeZoneTestCases
Change-Id: Ib1ae04cbadfe71e4e340a0572e82f0bc3f68ef30
This change adds support for VR-only IMEs in InputMethod framework.
In order to set this VR IME, setVrInputMethod(ComponentName) should be
called by VrManager.
When VrManager calls setVrInputMethod(), IMMS changes updates
the selected input method in a transient way i.e. it doesn't
update the Settings or input history. Once VR mode finishes,
it restores last input from settings.
Bug: 63037786
Test: Manually using the sample app in bug.
Change-Id: I1db7981b5198e7e203d4578cae7e5b6d20037d0d
We need to expose the CANT_SAVE_STATE importance for CTS to use.
I also found a serious issue with how instrumentation ApplicationInfo
is set up, where it doesn't have lots of important stuff like the
targetSdkVersion! This is now fixed... though ghod knows how this
will impact existing CTS tests, there could certainly be stuff relying
on code thinking it is running as targetSdk 0. :(
Finally delete the CantSaveState tests here, they are going to CTS.
Bug: 63937884
Test: ran new CTS tests
Change-Id: I42a73e0e83d799f8e5ff8ac4d4704a74ab5aab3e
Lifecycler currently creates a lot of extra objects for transactions
and transaction items. This change adds an object pool, so that all
objects that are used in lifecycler will be reused as soon as a
transaction is scheduled.
This also fixes parcelling/unparcelling of IVoiceInteractor in launch
activity transaction item.
Bug: 64797980
Bug: 69977460
Test: android.app.servertransaction.ObjectPoolTests
Change-Id: I49125e28447f3565338b61dab6de843fcc1ca9cd
Change to a sensible name which doesn't conflict with legacy RTT
service.
Bug: 65108607
Test: unit test, integration test
Change-Id: I54855635061c09e8d4bd2e97bac049f2893de123
This is the crux of the Verified Access feature implementation:
Adding the ability to generate KeyChain keys directly by the
secure hardware, rather than installing software-generated keys
into KeyChain.
Add generateKeyPair to the DevicePolicyManager, which delegates key
generation (via the DevicePolicyManagerService) to the KeyChainService.
Design highlights:
* The key generation is delegated via the DevicePolicyManagerService to
check that only authorized callers request key generation in KeyChain.
* KeyChainService performs the actual key generation so it owns the key
in Keystore outright.
* DevicePolicyManagerService then grants the calling app access to the
Keystore key, so it can actually be used.
* Loading the public/private key pair, as well as attestation
certificate chain, is done in the client code (DevicePolicyManager)
to save parceling / unparceling those objects across process
boundaries twice (for no good reason).
NOTE: The key attestation functionality (that includes Device ID) is
missing/untested. Will be added in a follow-up CL as this one is quite
big already.
HIGHLIGHT FOR REVIEWERS:
* API: New API in DevicePolicyManager.
Bug: 63388672
Test: cts-tradefed run commandAndExit cts-dev -a armeabi-v7a -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement -l DEBUG; adb shell am instrument 'android.security.tests/android.support.test.runner.AndroidJUnitRunner' (After building the KeystoreTests target and installing the apk)
Change-Id: I73762c9123f32a94d454ba4f8b533883b55c44cc
Created when the notification is marshalled and then unmarshalled
across process boundaries, since there are multiple references to the
same image from different places and they all get sent as separate
objects.
Fix: 70152868
Test: make FrameworksCoreTests -j30 && adb install -r ${ANDROID_PRODUCT_OUT}/data/app/FrameworksCoreTests/FrameworksCoreTests.apk && adb shell am instrument -e class android.app.NotificationTest -w com.android.frameworks.coretests/android.support.test.runner.AndroidJUnitRunner
Change-Id: I0a8c95207ab42260d88e5c206a04ab8386376ac4
This adds TransactionExecutor class, that takes care of executing
a multi-stage ActivityManager client transaction in correct order.
First it executes all callbacks, while also making sure to transition
to the right pre- and post-execution state if requested.
In the end it cycles to the final requested lifecycle state.
This also switches activity launch process to use lifecycler - it
initializes activity launch and sets final desired state in the same
transaction.
Bug: 64797980
Test: android.app.servertransaction.TransactionExecutorTests
Change-Id: I306f9396fab263682f580cc8c924a3cedb40ef89
So, UMS can start the target once user is unlocked.
Test: No secure lock. Try turn off and on work mode by tapping work app.
Test: Have secure lock. Try turn off and on work mode by tapping work app.
Test: Turn off work mode. Reboot. Try to tap on any work app to turn on work mode.
BUG:69926710
Change-Id: Iaaccd5d763f7e36e5a43bad5261f1eb16060f9d6
Historically, if a service returns null from onBind(), the binding app
gets no information about the outcome: the ServiceConnection is never
invoked. We now introduce a new connection callback, onNullBinding(),
for apps that need to detect this situation. When the service rejects
the binding by returning null, the onNullBinding() callback in the
associated ServiceConnection is invoked instead of onServiceConnected().
onNullBinding() has an empty default implementation, so there is no
binary-compatibility impact of this new interface method.
Bug: 67377345
Test: atest android.app.cts.ServiceTest
Change-Id: I224512c118f7d6e5c1c2bb69eca1902882e73594
Apps seem to rely on this undocumented behavior so that the
threaded sync adapter doesn't crash an app. That's really
bad on the app side, but we will have to live with it.
Bug: 67986472
Bug: 70122540
Test: m
Test: Device boots
Test: m cts && cts-tradefed run commandAndExit cts-dev --module CtsContentTestCases -c android.content.cts.SharedPreferencesTest
Change-Id: I1ee4dfba4ad29c4f66fa60d3c8f8a99900b3447a
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
