USB V1.3 HAL include:
1. Add api to enable/disable USB data signaling
2. Add api to inquiry HAL version
Bug: 161414036
Test: build pass and functions are working normally
Signed-off-by: Albert Wang <albertccwang@google.com>
Change-Id: Idb946de553b63f1d9da565133306117a6a4a7dd8
Depending on timing the first captured buffer from an internal
repeating request can be incorrectly propagated to the client
preview surface. This can happen, if the first 'onCaptureStarted'
callback gets delayed and executes after the first buffer from the
internal request gets queued in the camera preview output surface.
Proactively switch the camera preview output image reader callback
to loopback after the current capture sequence ends.
Bug: 179450326
Test: Camera CTS
Change-Id: I8232ea5171a0205da5705b6af5fdd3cdab297335
Updates FaceManager to distinguish between face enrollment and
authentication when producing help messages, returning more detailed
messages for the former and less noisy ones for the latter.
Test: Manually tested face enrollment and authentication.
Bug: 179044580
Change-Id: I406b371804de94383e65a077380b26bfb9ecf5e7
Add default system implementation of vibrator manager service that uses
IVibratorManagerService to access the device vibrators.
Change implementation of SystemVibrator to use VibratorManagerService
and delete local service VibratorService.
Introduce missing public APIs for VibratorManager and Vibrator.getId.
Bug: 167946816
Test: VibratorManagerServiceTest, VibratorTest, VibrationEffectTest
Change-Id: I55cdeb72c7ca39ccf0c7b2fda60b16de1031801e
This adds a MAXIMUM_DEVICE_STATE and MINIMUM_DEVICE_STATE constant to
DeviceStateManager that contains the max allowed device state indentifier
which reserves any larger values for future defined constants in the
platform. The constant will be used by CTS to validate that the set
of supported states is in the range
[MINIMUM_DEVICE_STATE, MAXIMUM_DEVICE_STATE].
The values match the max allowed value returned by the default provider
impl which is defined in the XSD schema.
Bug: 159401801
Bug: 177235528
Test: atest DeviceStateTest
Change-Id: Ia5a8e2841bac19d36e9d6cd00950d09628a7f719
Adds plumbing to send acquired frame info from the onAuthenticationFrame
and onEnrollmentFrame AIDL callbacks to FaceManager. Currently,
FaceManager drops most of this data and only passes the acquireInfo and
vendorCode fields to appropriate authentication/enrollment callbacks.
Test: atest CtsBiometricsTestCases
Bug: 178414967
Change-Id: If997ddd13ce1d9bda2341df7c1f8d6347571f4e0
1) Existing metrics logging-ness can be derived from it
2) EnrollReason is clearer and can be used by other parts of the
system, such as SysUI
3) Do not show progressbar in SysUI if it's "find sensor"
Bug: 179447737
Test: Builds
Change-Id: I84f82b5c81a668e11c1a380e6fa4e3080db53dc9
For apps that are still using FingerprintManager, have the system show
BiometricPrompt when authenticating with a UDFPS sensor. This will
ensure that the user is directed to authenticate on the correct part of
the screen, rather than requiring the app to draw an authentication UI.
Test: FingerprintManager test app, Keyguard, and Settings.
Bug: 174490952
Change-Id: I60ba2dce983812996f6baa44557533575051e476
Merged-In: I60ba2dce983812996f6baa44557533575051e476
Extend Vibrator state and listener support to InputDevice vibrator.
InputDevice users can use the Vibrator listener API to register listener
to vibrator for state change.
Bug: 161634264
Test: atest InputDeviceVibratorTest
Change-Id: I991d3e79ad1734b5c6c99b802aab030bd1597daf
This change promotes DeviceStateManager to a TestApi and exposes three
additional methods:
- getSupportedStates: returns a list of state ids that can be used with
requestState().
- submitRequest: requests that the device enter the supplied state.
- cancelRequest: clears the current requested device state.
to be used initially in CTS tests.
Bug: 177235528
Bug: 177236115
Test: atest DeviceStateManagerServiceTest
Test: atest DeviceStateManagerGlobalTest
Change-Id: Ieae9208420ddecea641a5c44f1610d3cb7071b07
Updates the AIDL face sensor implementation to forward the
onAuthenticationFrame and onEnrollmentFrame events to appropriate
methods in the FaceAuthenticationClient and FaceEnrollClient monitors.
This implementation also converts the hardware AIDL models
AuthenticationFrame and EnrollmentFrame to equivalent framework classes
FaceAuthenticationFrame and FaceEnrollFrame, respectively. This will
allow the framework to define AIDL interface methods with these models.
Test: atest CtsBiometricsTestCases
Bug: 178414967
Change-Id: I093c4396dddab9cb9fb8fd8ec3426b4f3a81abeb
DisplayGroupListeners can now be added and will be informed of addition,
removal, and modification of DisplayGroups.
Bug: 138328918
Test: make
Change-Id: I1dcb52931a798288a0255acd2862f9188f5d83ff
Created new API methods that allow apps to access external battery info
of devices such as bluetooth connected gamepads.
Bug: 161633432
Test: atest android.hardware.input.cts.tests.SonyDualshock4BluetoothTest
atest android.hardware.input.cts.tests.SonyDualshock3UsbTest
Change-Id: Iba59fc9a259818b03c24ee8c2c49601952ed65a3
Merged-In: Iba59fc9a259818b03c24ee8c2c49601952ed65a3
Pass displayId through from brightnesscontroller to
settemporarybrightness on the correct displaypowercontroller.
Bug: 175286226
Test: atest frameworks/base/services/tests/servicestests/src/com/android/server/display
Test: atest ColorModeControls
Change-Id: Ibb65b8c5a70445702b711739551ffb9f727ef450
Attribution tags allow clients to denote if they are providers of
specific data in the system which can be useful when noting permissions
operations later.
Bug: 166846988
Test: compile
Change-Id: I7b0ba9a9ffc6a49f79f80e8078f50625404ddafe
Updates the ContextHub APIs to support notifying clients (either through
traditional callbacks or via PendingIntent) that their ability to
communicate with nanoapps has changed.
Also, adds the ability for clients to discover the permissions required
to communicate with nanoapps so they know whether their initial or
subsequent nanoapp messages will successfully be delivered.
Bug: 166846988
Test: compile
Change-Id: I37e475a1457a031890693d2858b5d5f7de34de26
This interface can be used to listen for addition, removal, or
modification of DisplayGroups.
Bug: 138328918
Test: make
Change-Id: I3a2f39838ab00808816366d2484190b401aabed0
There are two categories of color modes: the standard color modes, which
are defined and implemented in AOSP, and a reserved range of vendor color
modes, which are defined and implemented by the vendor. Currently, there
is no way to distinguish between two vendor's color modes that use the
same value within the reserved range. This will allow OEMs to specify a
hint as to which vendor's color mode definitions were used on the
original device. If the hint from the restored device matches the hint
on the new device, the color mode from the restored device can still be
considered valid for the new device if it is within the vendor reserved
range. If it does not match, the restored device's color mode value is
invalid on the new device, and must be replaced by the default on the
new device.
Bug: 167449433
Test: builds
Change-Id: Ie5ac0a2d783e1ea703e0342f5cdb41dca07d04d4
For TV panel and source devices.
Bug: 169121289
Test: atest HdmiCecLocalDevicePlaybackTest and HdmiCecLocalDeviceTvTest
Change-Id: I6e870a35bcaf55153eaa2274c9f2d8b8f7bf1dda
