ContentResolver#openInputStream may return null, and may lead to
systemui keeps crashing, handle null to avoid this case.
Bug: 163412636
Test: manually
Change-Id: Ie149b75d4445b37afac82c8351a32cb17442936d
Expose the onEmergencyNumberListChanged method, which seems to have been
left hidden inadvertently when introduced.
Add a new version of onOutgoingEmergencyCall that supplies a
subscription ID and deprecate the old one. Along with this, send
emergency call events from any subscription to all listeners regardless
of which subscription the listener specified.
Test: atest CtsTelecomTestCases:OutgoingCallTest
Bug: 162647577
bug: 165660452
Change-Id: Ia0e10bfb3376ff82d03a6dbc4bf71c22b0ace366
Get the Profile Owner or Device Owner directly, rather than using the
ComponentName provided by the caller to look it up.
For DevicePolicyManager methods that are only callable by DO or PO,
there is no need to use the ComponentName to distinguish between
different potential admins, as there could be only one.
Bug: 163028934
Test: atest FrameworksServicesTests:DevicePolicyManagerTest
Test: atest com.android.cts.devicepolicy.MixedDeviceOwnerTest
Change-Id: I5fc3345101c8f61c12a9bbdbd224e95e719a0795
This allows 1) LockSettingsService to ensure the password isn't
valid forever. 2) Password to stay in system_server
Also, adds ILockSettings#removeGatekeeperPasswordHandle
so that callers can clean up after themselves.
Bug: 161765592
Run the following on face/fingerprint devices
Test: Remove credential
adb shell am start -a android.app.action.SET_NEW_PASSWORD
Set up credential + fingerprint
Test: Remove credential,
adb shell am start -a android.settings.FINGERPRINT_SETTINGS
This tests the ChooseLock* logic in FingerprintSettings
Test: Set up credential,
adb shell am start -a android.settings.FINGERPRINT_SETTINGS
This tests the ConfirmLock* logic in FingerprintSettings
Test: Remove device credential, enroll fingerprint/face. Succeeds.
This tests the ChooseLock* returning SP path from
BiometricEnrollIntro
Test: With credential and fingerprint/face enrolled, go to
fingerprint/face settings and enroll. This tests the
ConfirmLock* path in Fingerprint/FaceSettings
Test: Remove device credential, enroll credential-only, enroll
fingerprint/face separately. Succeeds. This tests the
ConfirmLock* returning SP path in BiometricEnrollIntro
Test: In SUW, set up credential, then biometric. This tests
the ChooseLock* path in SUW
Test: In SUW, set up credential, go back, then set up biometric.
This tests the ConfirmLock* path in SUW
Change-Id: I76534acc7af1e0f2e4d8af369fee31d1e19ddba9
* Add precondition checks to check the call authorization
and the calling user.
* Add CallerIdentity object and helper method to create
and return a CallerIdentity object.
* Add isDeviceOwner check which takes in a CallingIdentity
* Update setLocationEnabled to use new precondition check
Bug: 162825394
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest
atest com.android.cts.devicepolicy.DeviceOwnerTest#testSetLocationEnabled
Change-Id: I6054620aab661f302ebe0cb8c13bf906aad3cb68
There's a bug in ScreenshotHelper that causes the process not to
unbind properly. Now that the screenshot connection is kept track
of by the class, we don't need to compare its value at the
beginning and end of the started service before closing the
connection.
This also fixes an issue where screenshots didn't work right,
immediately after switching users (since the process is now
closed correctly, a new one can begin for the secondary user).
Bug: 158303623
Bug: 160355802
Fix: 158303623
Fix: 160355802
Test: manual; tested single screenshots and multiple in succession;
made sure that after switching users screenshots could be taken
immediately.
Change-Id: Idf25c6a60bdde8ab970c4af68884de798159ef3f
* changes:
Remove GenerateChallengeBlocking from FingerprintManager
Change GenerateChallengeCallback from abstract class to interface
3/n: Remove challenge from verifyCredential
2/n: Remove unnecessary RequestThrottledException for verify paths
1/n: Allow LockSettingsService to return Gatekeeper Password
Decouples the remainder of challenges from LockSettingsService.
Clients that require Gatekeeper HATs that wrap challenges should
request the Gatekeeper Password, then request LockSettingsService
to verify(GatekeeperPassword, Challenge). If the challenge is
biometric-related, it must be generated after LockSettingsService
completes verifyCredential, since LockSettingsService internally
does generateChallenge/resetLockout/revokeChallenge.
Bug: 161765592
Test: CtsVerifier biometric portion
Test: Reset fingerprint/face lockout
Test: atest com.android.server.locksettings
Change-Id: Icb384194ce5007b264068e697113d55cbf94945b
verifyCredential and verifyTiedProfileChallenge return a
VerifyCredentialResponse object instead of a byte[] now. Thus,
any/all information regarding the authentication attempt is
received by callers. We no longer need to use exceptions as a
method of returning an alternate non-byte[] result.
The RequestThrottledException cannot be completely removed yet
because checkCredential returns a boolean and has no way of
returning a timeout yet. See b/161956762
Bug: 161765592
Test: Accept/Reject/Lockout the following
1) Owner profile
2) Managed profile with separate challenge
3) Managed profile with unified challenge
Change-Id: Ia61c71bdde42dec34d8f2eac86d7ea964b1485c2
For certain scenarios, it's ideal if a single prompt for the user's
credential could generate multiple Gatekeeper HATs, each containing
a distinct challenge. To do so, we expose the gatekeeper password
to the caller, which can then be sent to LockSettingsService to
mint a Gatekeeper HAT with a challenge specified by the caller.
Functionally, this is split into two pieces:
1) ILockSettings#verifyCredential* has a new flags parameter,
which if contains VERIFY_FLAG_RETURN_GK_PW, returns the gatekeeper
password
2) ILockSettings introduces a new method, verifyGatekeeperPassword,
which takes the Gatekeeper Password and challenge, from which
Gatekeeper creates a HardwareAuthToken. This is different than
the rest of spBasedDoverifyCredential and __only__ requests
Gatekeeper to create the HardwareAuthToken. It does not proceed
to do other things such as unlocking keystore keys, unlocking
managed profiles, etc.
Slightly cleaned up VerifyCredentialResponse: moved to builder pattern,
cleaned up serialization/deserialization
Returning a VerifyCredentialResponse object (instead of a byte[])
also makes it easier to debug failure cases (e.g. credential was
verified but HAT was null, vs originally we have no idea). Similarly,
this allows us to remove RequestThrottledException, which can help
make it easier to reason about code flow (less unexpected nullness)
Test: Clients with VERIFY_FLAG_RETURN_GK_PW have correct "accept,
reject, timeout" behavior
Test: Current biometric enrollment works and not affected
Test: PIN/Pattern/Password verifyGatekeeperPassword works
(see ag/12222644)
Bug: 161765592
Change-Id: I6e2a7ea234aac1a278b35cdaff62b1c7e3e9f205
Argument order for westworld logging number of direct and app targets
provided by the app got turned around in the function call. Fixing the
order by moving the lines
Bug: 162982477
Test: manual
Change-Id: I23d0d2861c169b8e6eb26ce3040913db42f3e01f
(cherry picked from commit 6eb59aa87e)
Designed to work with both WM and WM-Shell
- source code is moved to com.android.internal.protolog, on contrast,
com.android.internal.logging is mainly used for uieventlogger
- the protolog-lib is defined in frameworks/base/Android.bp, similar to
uieventloggerlib as well
- to include protolog, reference what's in services/core/Android.bp
See also go/protolog-migration-s
Bug: 161561475
Test: atest ProtoLogImplTest \
ProtoLogViewerConfigReaderTest \
WmTests:ProtoLogIntegrationTest \
LogDataTypeTest \
protologtool-tests
Change-Id: I249a5675527d54778ac01529b4cb39fb09cb5d59
Argument order for westworld logging number of direct and app targets
provided by the app got turned around in the function call. Fixing the
order by moving the lines
Bug: 162982477
Test: manual
Change-Id: I23d0d2861c169b8e6eb26ce3040913db42f3e01f
Per go/uievent, migrated PiP logs to UiEvent and also in this change
- Deprecates counterpart proto definitions in metrics_constants
- Record PiP logs from SysUI only, deprecates what's used to be in WM
Changes to the actual logging
- No longer logs the actual aspect ratio
- Disables logging the change of aspect ratio since there are flood of
events can trigger this
- Splits menu visibility log to SHOW_MENU and HIDE_MENU
- Splits removal of PiP to TAP_TO_REMOVE and DRAG_TO_REMOVE
- No longer logs supportsEnterPipOnTaskSwitch
- Adds new RESIZE logging
Bug: 147508020
Test: $ANDROID_HOST_OUT/bin/statsd_testdrive -terse 90
Merged-In: I805d16ae6f30c07270b743f7ae1e66cbbd121131
Change-Id: I805d16ae6f30c07270b743f7ae1e66cbbd121131
