When the caller attempts to generate a key via DevicePolicyManager
(using DevicePolicyManager.generateKeyPair), and specifies that
StrongBox should be used, throw the right exception indicating
StrongBox unavailability - the same one that is thrown if the same
parameters were passed to the KeyStore's key generation method.
This is achieved by catching the StrongBoxUnavailableException in
KeyChain, returning an error code indicating this particular failure
to the DevicePolicyManagerService, which then propagates it by
throwing a service-specific exception with a value indicating
StrongBox unavailability.
The DevicePolicyManager then raises StrongBoxUnavailableException.
Prior to this change the exception propagated from KeyChain would be
a generic failure so the caller would simply get a null result.
Bug: 110882855
Bug: 111183576
Bug: 111322478
Test: atest CtsDevicePolicyManagerTestCases:com.android.cts.devicepolicy.MixedDeviceOwnerTest#testKeyManagement
Change-Id: I9abe3f449b48eb5a960fafbc15c59b9b4ce7a966
This CL enables always on top to be restored/deferred when
stacks switch between freeform and fullscreen.
Bug: 110494387
Test: ActivityStackTests
Test: DisplayContentTests
Test: go/wm-smoke
Change-Id: Iccb9824f845dea4925fac5d5dcb5eeaab2acdfcd
Add 2 additional attirubte |isFocused| and |lastActivityTime| in
ActivityManager.RunningAppProcessInfo and pass them to Chrome via IPC
so Chrome can better prioritize ARC processes.
Bug: 29576205
Test: Ensure new process information is passed to Chrome.
Keeping the code in memory of the currently set home app is
important for latency as we don't have any kind of starting
window/splash screen when pressing the home app to hide any latency.
Memory impact:
Pinning dex/vdex:
In practical scenarios, this should be < 500kb.
The home app is usually profile-speed compiled, for which the
resulting dex/vdex files are about 2 mb. However, during regular
use, at least 1.5 MB of it is referenced in memory. This makes
sense: By definition profile-speed only compiles the things that
is usually frequently executed during regular execution.
Pinning apk:
With Launcher 3 in practical scenarios this should be about 3.7 MB,
as the APK is about 5.7 MB but 2 MB are usually referenced in any
case.
Bug: 111132016
Bug: 78585335
Test: Inspect "adb shell dumpsys pinner" after boot.
Test: Check for pinned files after updating camera/home.
Test: Check for pinned files after user switch with different
default apps.
Test: Check for pinned files after bg-dexopt.
Test: Check for pinned files after bg-dexopt + kill pid.
Change-Id: I6cdbc06d089efeb1c72a51216879ba0573502009
An Activity may not yet create on client side, there is another
launch request with flags to clear task, then a destroy transaction
is scheduled. If client side keeps blocking until destroy timeout,
the token on server side will be removed. When client begins to
handle the first creation, it will report its activity token to
server that causes IllegalArgumentException because there is no
matched ActivityRecord.
Bug: 32375307
Test: atest FrameworksCoreTests:TransactionExecutorTests
Change-Id: I1b7e0c2863b13091c3fd50df602ff31ae02ff38d
By using text textclassifier API, we classify entities like
email, phone, address in the notification and suggest the corresponding
actions.
Test: Manual test for now. Sideload GoogleExtServices. Write a sample app
to generate notification with phone number / address, etc, and finally
observe the smart actions.
BUG: 110527159
Change-Id: I02740cb07fa25a588d9e864990f95332d6830f12
This call can lead directly to Surface destruction, so it's only safe
to execute while the app renderer is paused. If the call is oneway and is
deferred we can end up in a scenario where the call is processed (destroying
the surface) after the client renderer has been unpaused for a different reason.
Bug: 80423392
Bug: 62536731
Test: Manual. go/wm-smoke.
Change-Id: Ide9da46a4ca7b6ef3b55c9966cc495b70b10fa46
This reverts commit af5451f0ac.
Reason for revert: Causes b/110976005
Exempt-From-Owner-Approval: Needed to avoid a widespread breakage
Change-Id: Ibe969726601d6e4ce9a66b1bf8998cb33a955619
Associations now keep track of the time they are
actively involved in impacting their target application.
This is based on the procstate propagating through the
association being the same as the procstate of its target
process... so it may count as active when there is
another reason for that process to be in the same state.
To do this, we now maintain a set of "tracking
associations" -- these are in-use associations that
we know we need to be tracking to determine whether
they are active. This list is built based on whether
we at all consider an association during an oom_adj
computation, and at the end of that walked to determine
which of those associations are currently active.
Also add tracking of associations through external
provider references, with a tag name now needing to be
passed through so we can mark up the reason for the
external reference.
Test: manual
Bug: 110957691
Change-Id: I426a499834e20a9d7f2b439faf9cb398d9792fa2
For testing we often need to run shell commands. This can be done
today via running a shell command from an instrumentation test
started from the shell. However, this requires adding shell commands
which are not in the API contract, involve boilerplate code, require
string parsing, etc.
This change allows an instrumentation started from the shell to
adopt the shell UID permission state. As a result one can call APIs
protected by permissions normal apps cannot get by are granted to
the shell. This enables adding dedicated test APIs protected by
signatures permissions granted to the shell.
Test: cts-tradefed run cts-dev -m CtsUiAutomationTestCases
-t android.app.uiautomation.cts.UiAutomationTest#testAdoptShellPermissions
bug:80415658
Change-Id: I4bfd4b475225125512abf80ea98cd8fcacb6a1be
Make calls from activity classes go through ActivityManagerInternal
interface to case UserController instead of calling AMS.mUserController
object directly. Note that calls to UserController should not hold the
AMS lock.
Bug: 80414790
Test: Existing tests pass
Change-Id: Ie56f08d10b62d609e9b5e31f45b5f0d6eed3a9d4
- RemoteViews specify an ActivityOptions when calling startIntentSender()
(for click handling), but if the PendingIntent being started also has an
ActivityOptions, the merging of the two options will fail since the
ActivityOptions properties are always written into the bundle (regardless
of whether they are actually set). Instead, only write non-default
values to the bundle (the defaults will be read out if not set when
restoring the options from the bundle anyways).
Bug: 72459081
Test: atest FrameworksServicesTests:ActivityOptionsTest
change-id: i1d6718d9db4b3f7056412c5b4c5347a19ffa7c09
Moved more stuff related to activities out of the current service to the new one.
Bug: 80414790
Fixes: 110988007
Test: Existing tests pass.
Change-Id: Iceed1da8a7441a26d11efebc6d9f692fd053bc7f
When an app starts becoming Direct Boot aware, it can be difficult
to track down all the places they're reading data from credential
protected storage.
When a user is locked, credential protected storage is unavailable,
and files stored in these locations appear to not exist, which can
result in subtle app bugs if they assume default behaviors or
empty states. Instead, apps should store data needed while a user
is locked under device protected storage areas.
Bug: 110413274
Test: atest cts/tests/tests/os/src/android/os/cts/StrictModeTest.java
Change-Id: Ia390318efa6fefda8f10ac684d0206e67aa1d3dc
Documentation is pretty vague:
https://developer.android.com/guide/topics/data/autobackup#XMLSyntax.
But there were a couple of issues:
* It was prematurely returning false without consuming the rest of the
includes (cause of the bug linked).
* It was using string comparison for checking if a file is in a
directory, which ended up flagging directories such as "a/b" as
containing files "a/b.txt".
Reviewers,
* Please, pay full attention to test cases.
* Since this is code move + code change, set diff as 2..latest to check
changes to the function.
Bug: 110720194
Test: atest BackupUtilsTest
Test: Backup and restore app w/ multiple directory includes, verify
everything restored
Change-Id: Ic0fea43156ce8fb641af69ae73679289a20c291c
In the Service layer, this change is pretty much the same as ag/4340638.
FingerprintService already extends BiometricService which contains all
of the common code. FaceService now does the same after this change.
Updated the Manager layer to use the infrastructure added in P, namely
- Private APIs for BiometricPrompt
- Removed FaceManager#CryptoObject, use biometrics/CryptoObject directly
- Few other BiometricAuthenticator things
Bug: 110387294
Test: enrolling FP still works
Test: removing FP still works
Test: changing FP name persists across reboots
Test: enumerating still works (extra framework fp, extra hw fp)
Test: keyguard still receives lockout reset callbacks
Change-Id: I2195b08e28d024a120df56fe87b0dd4f9b96505a
Add 2 additional attirubte |isFocused| and |lastActivityTime| in
ActivityManager.RunningAppProcessInfo and pass them to Chrome via IPC
so Chrome can better prioritize ARC processes.
Bug: 29576205
Test: Ensure new process information is passed to Chrome.
Change-Id: Ic88d5fca336f03bd6426e65f964236130bb83fb6
We're almost out of bits, and we don't really need to smash both
thread and VM policy into the same 32-bit value, so use the lower
16-bits for each policy type and the upper 16-bits for penalty.
ActivityManager is only consulting the penalty bits, so we can
remove getViolationBit() and switch CTS over to doing instanceof
checks.
Bug: 110413274
Test: atest cts/tests/tests/os/src/android/os/cts/StrictModeTest.java
Change-Id: I760e6a28f56da66dc75b7df9daf2167ff5bdff50
When an app starts becoming Direct Boot aware, it can be difficult
to track down all the places they're implicitly relying on
PackageManager filtering behavior.
For example, if the current Launcher isn't Direct Boot aware, we
hide it until the user is unlocked, which could confuse other Direct
Boot aware apps into thinking it had been uninstalled, which could
cause data loss.
This change helps apps track down places where they're implicitly
relying on the automatic filtering; they should instead carefully
choose a combination of MATCH_DIRECT_BOOT flags to decide on the
explicit matching behavior they want.
To implement this, we partially migrate the updateFlags() methods
out into ApplicationPackageManager, since the checking needs to
happen on the client side to correctly report StrictMode
violations. We don't currently mutate the flags, but we retain
the naming to keep that door open in the future.
Test: manual
Bug: 110413274
Change-Id: Iff6feba19da81ea1b4eeb3af821c3bdfbd9bf17c
One heavy dependence between the current AMS service and activities
is process management which is heavy affected by activities and their
current state. We introduce WindowProcessController and WindowProcessListener
objects as a structured way for the process changes in AM package to
be communicated to the WM package and WindowProcessListner for activity
changes in the WM package to the communicated back to the AM package.
The ProcessRecord object in AM will own the WindowProcessController object
and also implement the WindowProcessListener.
Test: Existing tests pass
Test: go/wm-smoke-auto
Bug: 80414790
Change-Id: I9e96e841b0f95e99a597cb4629fa5d2fe45760b6
