- 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
Moved more stuff related to activities out of the current service to the new one.
Test: Existing tests pass
Test: go/wm-smoke-auto
Bug: 80414790
Change-Id: I16863dd977bf09136cc23b0ab3aa197c613879ea
This is a do-nothing TimeZoneDetectorService that can be
populated in following commits. A temporary method has been
added so the service has one method.
Unit tests can be run with:
atest FrameworksServicesTests:TimeZoneDetectorServiceTest
Test: build / boot
Test: See above
Change-Id: I565fb5dd2f18b7aac2e5779d346bfe69e9da02af
This is useful because logs are batched every 1.5-2hrs if there are
not enough logs to fill up a batch. The command is throttled at
10 seconds as a spam prevention measure.
Bug: 62251154
Test: in adb shell run dpm force-network-logs. Observe a new batch
being created in the phone directory
/storage/emulated/0/Android/data/com.afwsamples.testdpc/files/. Also
observe a fresh batch is being displayed on the phone in the TestDPC
app, under "Retrieve network logs".
Change-Id: I5ff9d5c78497ea81533b5248816b4d6e160d338f
The previous logic doesn't have the logic to distinguish "off" and
"undefined" for mFlags. This CL solves this issue by introducing
a variable dedicated to always on top. See b/110383970 for more
background.
Bug: 110383970
Test: atest WindowConfigurationTests
Test: go/wm-smoke
Change-Id: Ia4fe8f43e5f6d65d68b1257951b1770a49af35bc
Add basic functionalities for always on top feature.
- Add a new flag to WindowConfiguration to represent a task wanting to
be on top.
- Update the logic on changing the z-order of windows to make sure
always on top windows are placed above other windows.
Bug: 69370884
Test: go/wm-smoke
Test: atest DisplayContentTests
Test: Used ArcCompanionLibDemo app to verify that when always-on-top is
set, the app is above the other Android apps and Chrome windows.
Change-Id: Ie8edeb8ceeed0b9ec154b6031ed6cbe7ecc65b12
Objects that contain or represent activities like ActivityRecord can
no longer rely on ActivityManagerService as it is going to be in a
different package.
Test: Existing tests pass
Test: go/wm-smoke-auto
Bug: 80414790
Change-Id: I7eabc9b80e494367d79ff7452c88ba82ff216bcd
3rd step in unifying the window hierarchy that is currently split
within AM and WM packages. We separate the the internal interface used
to communicate within system server dealing with activities and their
containers (tasks, stack, display) from the rest of AM internal
interface.
Test: Existing tests pass
Test: go/wm-smoke-auto
Bug: 80414790
Change-Id: Idad77721c1fe10621b9be5dced42a0a11f0183e5
Second step in unifying the window hierarchy that is currently split
within AM and WM packages. We move some of the API implementation for
activities from ActivityManagerService.java to
ActivityTaskManagerService.java.
Test: Existing tests pass
Test: go/wm-smoke-auto
Bug: 80414790
Change-Id: I23dcd924493d8ad1e0b6e3a55386fd72b0146605
