Also reorganized the FrameTrackerTest a bit
Bug: 162927074
Test: manual - statsd_testdrive to verify statsd logging + run
FrameTrackerTest
Change-Id: Iec1fcafcd6c8373ebdeebbbd829eb94967c2bfb8
The alarms inside alarm manager service are stored in a variety of
different lists, the main one being an array list of Batch objects. Over
time due to various policy changes, it has caused a lot of coupling
between the service's business logic and the management of these data
structures.
This change introduces an interface to store alarms (a.k.a. AlarmStore)
and attempts to create a well defined boundary across which the service
interacts with this data structure. The interface presently supports
the following operations:
- add: to add an alarm.
- remove: to remove any alarms described by a predicate.
- removePendingAlarms: to remove any alarms that are due at a given
time.
- getNextDeliveryTime: the next upcoming alarm's delivery time.
- getNextWakeupDeliveryTime: the next upcoming wakeup alarm's delivery
time.
- recalculateAlarmDeliveries: to adjust the alarm deliveries in a way
described by the caller.
All the times are interpreted in the elapsed timebase.
The details of how the alarms are stored and managed, such as their
relative ordering and the complexity of each of the supported operations
is left to the implementations to decide. The expectation is that
this will make it easier to change and optimize these aspects of the
data structure in the future, while also making it simpler to make
changes to the service side policies.
Apart from the above, some formatting was corrected, obsolete or dead
code was removed and a bug where we were missing a rebatch was fixed.
Test: atest FrameworksMockingServicesTests:com.android.server.alarm
atest CtsAlarmManagerTestCases
Bug: 161497385
Change-Id: I8ac475d6c6a827500bf93be982cd40897f6743ae
Only on userdebug and eng builds for now.
Bug: 131859447
Test: manual - flashed the phone and verified the atoms with statsd_testdrive
Change-Id: I1a97dfe4ad062740f7c30558930de455cac07d9c
The aot infrastructure for instrumenting CUJs.
The usage is like below:
AlwaysOnTraceManager.init(view /* one in the view tree */);
AlwaysOnTraceManager.begin();
...
AlwaysOnTraceManager.end();
Bug: 158756171
Bug: 163514962
Bug: 162483077
Test: Manually
Test: atest FrameworksCoreTests
Change-Id: I570a760d4f3b71e86f19172d8f595e558369ff65
When rendering the requested image, the updated scrollDelta was not
being accounted for, resulting in rendering the wrong vertical
position. This would happen if the view scrolled as a result of the
request.
Also adds a call invalidate() on the target view after scrolling to
ensure that DisplayLists are correctly rebuilt when rendered here
since there is no synchronization with the render thread.
Test: atest ScrollViewCaptureHelperTest
Change-Id: I1e6aec8dd4352b4ae610657537581689a04b725b
- Refactor out base protolog impl so that shell can have it's own
implementation which takes a different viewer config (from the resources
directly instead of a separate file in /system/etc)
- Setup the protolog transform for shell classes
- Add some basic protologs for displayarea/task organizer controller
& shell task org (for now only text logging)
Bug: 161980327
Test: adb shell wm logging enable-text WM_DEBUG_WINDOW_ORGANIZER
Test: adb shell dumpsys activity service SystemUIService WMShell enable-text-logging WM_SHELL_TASK_ORG
Test: atest ProtoLogImplTest \
ProtoLogViewerConfigReaderTest \
WmTests:ProtoLogIntegrationTest \
LogDataTypeTest \
protologtool-tests
Change-Id: I4c3fd6aaea04987c26ac56e9baf9fc8ab75a3f34
Signed-off-by: Winson Chung <winsonc@google.com>
When the file is deleted, renamed or moved, revoke all uri
permissions with the file
Bug: 157474195
Test: manual test with DocumentsUI
Test: atest DocumentsTest#testAfterMoveDocumentInStorage_revokeUriPermission
Change-Id: I4ffb183630aadb2d87b0965e8cecf88af15f4534
Allows overriding the configured keychord delay (the time it takes,
after both the power button and volume down have been pressed, for
a screenshot to be registered/taken). If not set, reads from the
config file (as before). Can be updated with
adb shell device_config put systemui screenshot_keychord_delay <n>
where <n> is the desired timeout, in ms.
Bug: 165267251
Test: manual -- tried setting multiple values, ensured that deleting
the override reverts to the configured value
Change-Id: I2f86abe0332f8072ab4f53baa55f1999aed3865a
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
