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 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
When always on top is set, the position of the stack must be
changed in ActivityDisplay and in DisplayContent. This CL
introduces this logic in ActivityStack.setAlwaysOnTop().
Bug: 69370884
Test: go/wm-smoke
Test: atest DisplayContentTests
Test: atest WindowContainerTests
Change-Id: Ie7efe175175a4db209a6b0f3476d9dfc27432df5
This change is cherry-picked and rebased from AOSP
https://android-review.googlesource.com/c/platform/frameworks/base/+/660242
Add face recognition as an identification method, following fingerprint
design. Unlike fingerprint, only one face template can be enrolled per
user, and a vendor message is passed from the HAL all the way to the
client callback to allow GUI indication about the enrolled face
templates.
Add FaceAuthenticationManager and FaceService.
Add face authentication capability to TrustManager and Keyguard.
Modify TrustManager and KeyguardUpdateMonitorCallback fingerprint code
to support generic biometric method to eliminate duplications.
Add BiometricSourceType enum to keep track of the specific biometric
method.
Test: biometric authentication still works on the device
Fixes: 110385761
Change-Id: I5d04fe69a112c13d3ef7330b9c08c146e36c5335
Signed-off-by: Gilad Bretter <gilad.bretter@intel.com>
Secondary user's WallpaperInfo would always be null otherwise.
Test: manual, switch between users with different live wallpapers
Change-Id: I32d5e04281aa38b00f5350569ef86b5d74de8f07
Fixes: 110275658
