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
* 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
The different states are:
- No indicators enabled. Location is displayed using
LocationControllerImpl
- Only mic + camera indicators. Location is displayed using
LocationControllerImpl
- All indicators enabled. LocationControllerImpl is ignored.
Also, hardwire OP_MONITOR_HIGH_POWER_LOCATION as user sensitive.
Fixes: 162552566
Test: atest com.android.systemui.privacy
Test: manual
Change-Id: I1e7f62d6fccb4a3bc4fdf2a47a8d5c8a4f55421d
Merged-In: I1e7f62d6fccb4a3bc4fdf2a47a8d5c8a4f55421d
Add a null check for mResolverDrawerLayout in ChooserActivity
Bug: 162900698
Test: ChooserActivityTest
Change-Id: Id2b4442a0c5f22e1ecff04a1d20b48784ecc47dd
Uptime is a better estimate of time spent in cpu. Adding uptimeNanos to
SystemClock to get finer timestamps.
Test: Manual:
`adb shell dumpsys alarm` should show sensible information under 'Stats'
printed at the end.
Bug: 162791194
Change-Id: I4f1c9d41c53ec03fc414730d38fd7a2233bb0569
Add a null check for mResolverDrawerLayout in ChooserActivity
Bug: 162900698
Test: ChooserActivityTest
Change-Id: Id2b4442a0c5f22e1ecff04a1d20b48784ecc47dd
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
Change-Id: I805d16ae6f30c07270b743f7ae1e66cbbd121131
The different states are:
- No indicators enabled. Location is displayed using
LocationControllerImpl
- Only mic + camera indicators. Location is displayed using
LocationControllerImpl
- All indicators enabled. LocationControllerImpl is ignored.
Also, hardwire OP_MONITOR_HIGH_POWER_LOCATION as user sensitive.
Bug: 162552566
Test: atest com.android.systemui.privacy
Test: manual
Change-Id: I1e7f62d6fccb4a3bc4fdf2a47a8d5c8a4f55421d
