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
Due to a binder limitation (b/150808347), any unexpected exception
thrown by a binder service while processing an RPC call, will be
silently discarded and the client will get back a default-initialized
result parcelable (i.e. in most cases, won't know that anything wrong
happened).
We work around this issue by throwing a ServiceSpecificException,
which does get delivered, having a special code to designate an
internal error. Errors resulting from a HAL malfunctions will result
in a HAL reboot, which leads to recovery.
Bug: 154089179
Test: Manual verification of basic error recovery scenarios by
injecting HAL error codes and crashes.
Change-Id: Ib5dbe08a362e545501c04204bebad5ab95f5d632
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
Change-Id: I83ae9b423122b540b9adb156fb1c6f5964dd6105
