Previously, only the NDK enforced the default sensor type was wakeup and
if an app called the Java APIs it'd get a null value if there was only a
wakeup version of the hinge sensor.
Bug: 157581504
Test: Run on emulator and verify that getDefaultSensor returns the
sensor instance
Change-Id: Ica13c70a456780891f366394848e4c649f6ea70b
Adds a listener to receive updates to the state of the HDMI CEC volume
control features.
Interested parties can register and unregister to get notified about
state updates which are sent on every change to the value.
Test: atest HdmiControlServiceTest
Bug: 152018314
Change-Id: I342d748114bae99b3c3f236502d73bfeac9e9ac5
The current Android API will trigger strict mode
violations in case a context not bound to any
particular display tries to connect to the window
manager service.
To avoid such violations query the default display size
directly from the display manager.
Bug: 157167435
Test: Camera CTS
Change-Id: Icad19ec0227b4945da9e6fcacaec916c5799877f
- specifying the order of camera open and session configuration.
- explaining the use of CONTROL_ZOOM_RATIO with concurrent operation of cameras.
Bug: 151891611
Test: make doc-comment-check-docs
Change-Id: I3ee3f114f7295570aa6af5dbe35bb32db555811b
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
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
