Previously checks for front stacks were looking among
stack on primary display only. This doesn't make any
sense for stacks on secondary screens, so let's always
check among other stacks on its current display.
Bug: 34862802
Test: Manual.
Change-Id: I29ee160d455719d75f4a5981a6ba9c60f3d90084
Commit https://android.googlesource.com/kernel/common/+/f0ce0eee added
CAP_SYS_RESOURCE as a capability check which would allow access to
sensitive /proc/PID files. system_server uses this capability to collect
smaps from managed processes. Presumably this was done to avoid the
implications of granting CAP_SYS_PTRACE to system_server.
However, with SELinux enforcement, we can grant CAP_SYS_PTRACE but not
allow ptrace attach() to other processes. The net result of this is that
CAP_SYS_PTRACE and CAP_SYS_RESOURCE have identical security controls, as
long as system_server:process ptrace is never granted.
Add CAP_SYS_PTRACE to the set of capabilities granted to system_server.
Don't delete CAP_SYS_RESOURCE for now. SELinux has blocked the use of
CAP_SYS_RESOURCE, but we still want to generate audit logs if it's
triggered. CAP_SYS_RESOURCE can be deleted in a future commit.
Bug: 34951864
Test: Device boots, functionality remains identical, no sys_resource
denials from system_server.
Change-Id: I2570266165396dba2b600eac7c42c94800d9c65b
- This fixes an issue where the last stack active time would be clobbered
when switching between users. With the policy in the phone/stack
recents, this is fine, but with the grid recents, it no longer only
applies when out of the historical window, so it is always wrong (it
would normally be wrong if switching back from another user after the
historical time of six hours).
This CL will migrate the last stack active time to a per-user secure
setting, which will be used going forward.
Bug: 35375206
Test: On the Ryu, launch some tasks, switch users, launch more tasks, and
return to the original user
Change-Id: I9941526de5d1dd52d1f9003e795995389064b19d
Take advantage of the new authentication flow in LockSettingsService
and allow PO or DO to provision escrow tokens on the device. The
escrow token grants them the ability to change device lockscreen
(if used by DO) or work profile challenge (if used by PO). The
new password reset mechanism is even usable before user unlocks,
and it preserves authentication-bound keys in keystore.
Test: runtest frameworks-services -c com.android.server.SyntheticPasswordTests
Test: runtest frameworks-services -c com.android.server.devicepolicy.DevicePolicyManagerTest
Test: cts-tradefed run cts-dev -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.MixedDeviceOwnerTest#testResetPasswordWithToken
Bug: 33126620
Change-Id: Iaa684c51946f726cbd909e9ac70ad3e9ca3de1ac
Escrow token provides an alternative way to derive synthetic password for a
given user. In the new flow, a pre-provisioned escrow token
should be able to do anything the user password can do, since they both
derives the synthetici password which is the master key in the new auth flow.
Test: runtest frameworks-services -c com.android.server.SyntheticPasswordTests
Bug: 33126414
Change-Id: Ib5ee38fd61f66de3245427ce992ebc12f1873a26
A icon could be invisible because we were not aborting the animation
in certain cases. This should be fixed now.
Change-Id: I8caf35034704a0df3d205205086c4622b60e0da9
Fixes: 35385932
Test: runtest systemui
The user password is used to unlock a per-user synthetic password which
serves the purpose of what the user password previsouly achieves (protect
keystore, vold disk encryption, auth token generation).
Test: runtest frameworks-services -c com.android.server.SyntheticPasswordTests
Test: manual
1. Start with fresh device, enable synthetic password with "adb shell cmd lock_settings sp 1"
1.1 add device lock, reboot and verify (positive & negative); change device lock, reboot and verify.
1.2 Inflate a work profile, reboot and verify device lock. check SID with "adb shell dumpsys lock_settings"
1.3 Un-unify and add work challenge, reboot and verify work challenge and SID.
1.4 Re-unify work challenge, reboot and verify.
1.5 Clear device lock, reboot and verify lock and SID.
2. Start with a fresh device, add a device lock and inflate a work profile.
2.1 Enable synthetic password, note current SID
2.2 Reboot and unlock device. Verify synthetic password is generated and SID remains.
2.3 Clear device lock, reboot and verify (SID should be cleared)
3. Start with a fresh device, inflate a work profile, add separate work challenge
3.1 Enable synthetic password, not current SID
3.2 Reboot and unlock device and profile. Verify synthetic password is generated.
3.3 Clear device lock only, reboot and verify (work profile SID should remain)
All steps tested on marlin (FBE) and bullhead (FDE)
Bug: 33126414
Change-Id: Idb9ebfc7bba2fe40670c5fee2189e873d9704540
readSessionsLocked depend on DPMS, so defer it until all system
service is started
Fix: 34663223
Test: Manual
1. Try to install an app and reboot before it is installed
(so the session is persisted in a file)
2. Observe that PackageInstallerService
read the persisted session in onSystemReady and
able to get the DPM instance.
3. Observe play can read the persisted session
Change-Id: Ia14ed09db08fcf59189fa29293f0ac5066650942
- The queued work processing thread might be sleeping while the main
thread is waiting for it to do work. Hence process the work in the main
thread.
- Carefully add logging so that slowness can be tracked.
- Fix usage of the wrong lock (sWork instead of sLock).
- Increase the time of the delay between apply and write to make
possible side-effects more visible
Test: SharedPrefencesTest, looked at logging
Bug: 30662828
Change-Id: Ie8a5d531e180dacec29c947ba0b59b170facf782
- Fixes issue with the incorrect calculation of configuration smallest
width for floating and always-fullscreen stacks. Fullscreen stacks
now have the smallest width matching the display, and floating stacks
are set to the smallest size of their bounds.
- This CL also ensures that we test the combined global/override configs
for changes in case changes when moving between stacks results in a
shift in the configuration between the parent to the override of the
child (ie. when going from fullscreen -> pinned)
- Also ensure that we are animating to the right fullscreen bounds for
the PiP transition, accounting for the insets when calculating the config
change the same way we would do for fullscreen tasks.
Bug: 33779483
Test: android.server.cts.ActivityManagerConfigChangeTests passes
Test: android.server.cts.ActivityManagerPinnedStackTests
Test: #testSingleConfigurationChangeDuringTransition
Change-Id: I2c2b695572cd17087d522cf6c8ebd105e57e08b8
