We should stop using a bundle between BiometricPrompt (API),
AuthService/BiometricService, and AuthController (SystemUI)
For the below reasons
1) Bundles are too generic, and also less readable
2) Avoid needing to define default values everywhere
3) Cleaner interface
4) Convenience functions can be added within PromptInfo
We can consider having separate parcelables for
- BiometricPrompt->BiometricService
- BiometricService->AuthController
But that seems a bit overkill at the moment
Test: atest com.android.systemui.biometrics
Test: atest com.android.server.biometrics
Test: BiometricPromptDemo
Change-Id: I2911a876bf00197a13f6a406ab735a8bad5b960f
When using PROXIMITY_SCREEN_OFF_WAKE_LOCK and screen was turned off by proximity sensor,
input service should generate ACTION_CANCEL, same as display turned off by pressing power button.
Add power state in display view port and notify input service for
display power state change.
Bug: 154074380
Test: atest libgui_test
Change-Id: Icb65aead4b5544182c46101f4ba535f5955ebd6c
We should first remove halDeviceId since it's not used and adds
confusion.
Bug: 149067920
Test: atest com.android.server.biometrics
Test: enroll, auth (lockscreen), remove on fingerprint/face devices
Test: BiometricPromptDemo on fingerprint/face devices
Change-Id: Ic57ed3307225ae2653f8f83308a4119346428c26
Existing definition was inconsistent, so update it to be consistent
and match what implementations have actually done.
Test: Builds
Bug: 150331548
Change-Id: Ied8e78a36685f3f6416e431307970db3b6191497
The deviceId currently returned by the HAL is only used to determine
if the callback has successfully been set. Any state that it's being
used to track is currently redundant with the pointer to the actual
HAL (e.g. determing if the HAL is found, if it has crashed, etc).
Remove this information to reduce confusion.
Also removed enumerate callback, since only system server handles
enumeration results (upper layers never touch this)
Bug: 149067920
Test: Enroll, auth on fingerprint and face devices
Test: atest com.android.server.biometrics
Change-Id: I1275a91da6f773934be663731ddf1802e0161090
AChoreographer will consume these callbacks in lieu of going through SF
for the callbacks. This is so that DMS can update its view of display
configs before apps receive the refresh rate callback so that apps can
get consistent information.
Bug: 154874011
Test: ChoreographerNativeTest
Test: Manually verify that HWUI is receiving callbacks
Change-Id: I992c247fd16ef414f94a259bbd300bea3e4c9467
- Don't use reverse-JNI to access metadata ptr, pass it as an arg instead
- Use @FastNative since the calls are short and bounded in time
Performance improvement:
- On a 10-second trace of camera app running on sargo, percentage of
time used in CameraMetadataNative.get went from 4.36% to 3.77%, a 15%
reduction in time.
Test: atest CtsCameraTestCases
Bug: 150214459
Change-Id: I28d9428beaa7eada6292e24fe6ca1dbd9c2ff153
attach() may throw various kinds of runtime exceptions, and since there
is no way to represent them in attach() other than returning null (it
is not supposed to throw), we should catch them here and log them.
Bug: 153332815
Change-Id: Icbb7643c3abf6c6b0edc9d1eb9a74c38c731acdf
* changes:
Check for null HAT and add logging
6/n: Move logging into AuthSession
5/n: Remove requireConfirmation round trip
4/n: Remove unused parameter
3/n: Add AuthSession#STATE_AUTH_PAUSED_RESUMING
2/n: AuthSession should manage its own state
1/n: Move confirmationRequired logic into sub-modules
<Biometric>Service(s) only need to know about requireConfirmation
for FrameworkStatsLog logging. On the same note, AuthSession is the
source of truth for requireConfirmation, so <Biometric>Service(s) do
not need to pass the value back.
Bug: 149067920
Test: atest com.android.server.biometrics
Change-Id: I5212da7db4fde0bec84eaee83fd25ed0f0225b9a
Using byte for display port is error prone since ports
are in the range [0, 255] and bytes have the range [-128, 127].
This way we need to downcast from int to byte in order to write a
value to display port and also we need to call Byte.toUnsignedInt
every time we want to consume it.
Test: m services
Bug: 153334857
Change-Id: I4dce87c0a411c5d447f62cc5564eb4b8a8fb75f0
Add API (backed by Setting) to enable/disable volume changes via HDMI
CEC for HDMI CEC source devices.
This state is persisted via Settings.
If volume control is disabled, no incoming HDMI CEC commands related to
volume will be processed. If disabled, no HDMI CEC volume control
messages will be sent by the device.
Test: atest com.android.server.hdmi
Bug: 149800547
Merged-In: I83ae9b423122b540b9adb156fb1c6f5964dd6105
Change-Id: I83ae9b423122b540b9adb156fb1c6f5964dd6105
