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
- 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
Type-c ports can quickly toggle between connected/disconnected
states. Introduce debounce to prevent sending spurious notifications.
Bug: 34972898
Test: notification should not be queued for a pixel-c charger not connected
to the power outlet.
Change-Id: I4aa19f9f864fe5b77e65f6a07a3184d8aba1f5fc
UsbPort.POWER_ROLE_SINK is orthogonal to the type of the charger
attached. POWER_ROLE_SINK would be the case for AC charging and
USB charging. Therefore query BatteryManager for the charger
type.
Bug: 34972898
Test: Charging notification should not show for pixel-c chargers.
Change-Id: I8dddcd7727b6af973bd173d2c6e325aa4be2ca3a
We already does this on start. Now we also do the same when
the list of options changes.
Test: locally on device
Bug: 34470067
Change-Id: Ib184d67b532c5afd584fb9cd52daac69a7c50d0a
Bug: 34206215
Test: hwui unit tests passing, manual test of TextureView video playback
Always flush renderstate to the GlLayer's texture, regardless of
whether updateTexImage has ever been called.
Change-Id: I3974dce9d90633a0299e6bc4259b76c622717c90
This CL allows the default dialer to modify the voicemail ringtone.
All settings except the voicemail provider and voicemail nubmer can
be moved to the dialer after this CL.
Bug: 34626472
Fixes: 34626472
Test: CtsTelephonyTestCases TelephonyManagerTest
testVoicemailRingtoneSettings and testVoicemailVibrationSettings
Change-Id: I5dd1e5ac8c358b09ff9a98051c429dba758c04a4
We now turn on lazy preloading (see companion change 73c7df1bda76a0)
and explicitly preload zygote resources.
To provide the most benefit :
- We start the preload in the system_server, which means the system_server
starts quicker since it has one less preload to wait for. Morever, the
64 bit zygote also starts quicker because it has one less high
priority process to contend with for CPU and I/O.
- We start the preload after the core system services start up, since we
know no 32 bit zygote processes will be requested before that point.
- We start the preload ~1s before the webview factory preparation, to
ensure that it completes before the 32 bit relro process is forked
from the zygote. In the event that it takes too long, the webview
RELRO process will block, but it will do so without holding any locks.
I have not observed this happening in > 200 runs on marlin / sailfish
devices.
This change saves about 500ms in boot times, and sometimes even more.
AFTER:
successive-online : 16970.0,16668.0,16391.0,16498.0,17601.0,16736.0,16609.0,16820.0,16310.0,17557.0,
successive-online_avg : 16816.0
successive-boot : 28750.0,29520.0,29372.0,28424.0,30683.0,28523.0,29766.0,29779.0,29304.0,31607.0,
successive-boot_avg : 29572.8
BEFORE:
successive-online : 16678.0,18105.0,17197.0,16744.0,17453.0,16946.0,18068.0,16719.0,17453.0,16942.0,
successive-online_avg : 17230.5
successive-boot : 30855.0,32069.0,31223.0,30918.0,30284.0,29750.0,31036.0,30778.0,30310.0,30908.0,
successive-boot_avg : 30813.1
Note that successive-online is a little faster, as expected since we do
less work in the 32 bit zygote.
Test: manual, timings from tradefed.
Bug: 34810190
Change-Id: I90207a2706afda163b8134ff2af31f6917f3841b
Return null instead of triggering a NPE when there are no resource of
the asked type.
Test: RenderTests.testFonts
Change-Id: Ib45ebdf2178e62cbd987082512fcbb009de3f1b2
instant apps are no longer stored in a separate folder. they
are now stored along side other full apps in the apps directory.
Bug: 25119046
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.EphemeralTest
Change-Id: I6669be797987169a0b9cca78f80539c908812f9e
The class loader in Resources is now used to inflate drawables. Because
layoutlib was using the system class loader, the drawables would fail to
inflate.
With this change, Resources will use the layoutlib class loader instead
of the system one.
Test: Tested from the studio side
Change-Id: I933ff68e704f9d3599b69cd74e98e44bdca3c789
