This is an alternative to ag/16124814 with the additional fix for udfps.
Fix: 203789357
Test: atest SidefpsControllerTest
Test: manual (open settings and verify no overlay shown with list of fingerprint)
Test: manual (open settings and verify overlay shown during enrollment)
Change-Id: Iee33cbb66d86d4f033d6acc9cf2284a3845f22de
If the posture changes while AOD is running, make sure
sensors are unregistered + registered properly.
Test: manual, enable AOD and then close/open and check that
correct sensors are registered (dumpsys sensorservice)
Test: atest DozeScreenBrightnessTest DozeSensorsTest
Fixes: 192805135
Fixes: 199344667
Change-Id: I5093dc43e062144adca757c94fa708f51be57a44
The device state manager doesn't seem to be present on all
devices.
Catch any ISEs and handle this corner case appropriately.
Bug: 202597641
Test: atest
CtsGraphicsTestCases:android.graphics.cts.CameraVulkanGpuTest#testCameraImportAndRendering
-- --module-parameter instant_app
Change-Id: I6e6c7266b268835f3138cbb22a6f2df606742300
Use "DeviceStateSensorOrientationMap" to avoid possible
association with other common orientation states such as
Portrait and Landscape.
Bug: 202832229
Test: atest -c
cts/tests/camera/src/android/hardware/camera2/cts/ExtendedCameraCharacteristicsTest.java#testDeviceStateSensorOrientationMapCharacteristics
Change-Id: I6fc9d452f0bb4099389e30d0404e1c6c20dff8ff
Change-Id: Icde1a8eb25b15b237812f583de8f7a46b6576772
The advanced extension session request processor must not hold the
'mInterfaceLock' when calling the camera device implementation as it
could result in a deadlock with the camera device close that can
run at the same time and try to acquire the same locks in reverse order.
The request processor will only read from 'mCameraConfigMap' which is
initialized only once during session setup and will not change during
the session lifetime.
A sample stack trace will look like this:
Service thread:
1) android.hardware.camera2.impl.CameraCaptureSessionImpl.stopRepeating
2) android.hardware.camera2.impl.CameraAdvancedExtensionSessionImpl$RequestProcessor.stopRepeating
Client thread:
1) android.hardware.camera2.impl.CameraAdvancedExtensionSessionImpl.release
2) android.hardware.camera2.impl.CameraDeviceImpl.close
Bug: 202074988
Test: Manual using application,
Camera CTS
Change-Id: If992667a7d7e54be5bea1fcc4b1d71ec1b895ca0
CaptureFailure is created with a "dropped" parameter. But what's passed
in is mayHaveBuffers, which is opposite of "dropped".
Test: Camera CTS, GoogleCamera
Bug: 201967385
Change-Id: I42eb2daa78f116502cb1c5943015ea3f4af3f1e3
Allow foldable devices to advertise the mapping between device fold
state and sensor orientation.
Additionally return the current sensor orientation
based on the specific device fold state.
Bug: 201005727
Test: Manual using AOSP Camera2 application,
Camera CTS
Change-Id: Idc76903da22567d29cc55d991b41df7e19490aa3
Some postures don't need to register for a prox sensor
Test: manual, atest PostureDependentProximitySensorTest
Bug: 192805135
Change-Id: I5c5fbed6d3faff6ba690f67f592bb0b8082062d5
Currently DisplayModeDirector casts Vote.PRIORITY_HIGH_BRIGHTNESS_MODE
based on whether High Brightness Mode (HBM) is allowed, rather than
based on whether HBM is actually active. This can lead to cases where
the HBM refresh rate vote is cast when HBM is allowed but not actually
used.
This change corrects this behavior, and makes DisplayModeDirector check
that HBM is both allowed (enabled) and actually in use (active).
Bug: 200851199
Test: atest DisplayModeDirectorTest
BrightnessLevelPreferenceControllerTest
HighBrightnessModeControllerTest
Change-Id: I8cb8f023a6bca11de976866259032143f43d9a4f
Currently, DisplayModeDirector listens to brightness changes from Settings.
However, brightness value in Settings is overridden for various reasons
inside DisplayPowerController before being propagated to HALs. As a
result, the brightness value that DisplayModeDirector is acting on isn't
always the brightness value that gets applied to the display.
This change,
- Changes DisplayPowerController so that the final brightness value (after all
modifications) is saved.
- Changes DisplayModeDirector to use DisplayManager.DisplayListener to
observe brightness changes and then retrieve and act on the final
brightness value saved in DisplayPowerController.
Bug: 199955532
Test: atest DisplayModeDirectorTest
Change-Id: Ia6dd7d194b6913d2942bea9c29a2011b8058beef
Depending on the posture, SystemUI can register for
different brightness sensors on AOD.
Test: manual, atest DozeSensorsTest
Bug: 192805135
Change-Id: I85e458623ae9cf868af80e0c02154fb0be11c615
Allow setting a different refresh rate for High Brightness Mode for HDR
and for Sunlight.
Bug: 196691596
Test: atest DisplayModeDirectorTest
Test: Manual:
1. Ensure HBM for HDR takes presedence over HBM for Sunlight
2. Ensure app refresh rate votes override bothHBM for Sunlight
Change-Id: I4a29c47f218046d0852178ad5dc7484a86ef8607
The native Jpeg encoder expects rotation in counter
clockwise direction. However according to the Camera2 specification
clients need to pass the Jpeg rotation in clockwise direction.
Flip the client rotation value before passing to the Jpeg encoder.
Bug: 200890552
Test: Manual using sample application,
atest -c
cts/tests/camera/src/android/hardware/camera2/cts/CameraExtensionSessionTest.java
Change-Id: Ib70a8f5b5165d8319d89c2ed4b7509929c2faa71
Implements multi-stage enrollment for UDFPS. This implementation
supports both highlighting the progress bar when a help message is
received and configuring the progress thresholds between enroll stages
via an XML resource.
Test: Manual
Bug: 198928407
Bug: 200076382
Change-Id: I6f6111ab0ed29ca7f1be01303f0457764d5afe01
Merged-In: I6f6111ab0ed29ca7f1be01303f0457764d5afe01
Implements multi-stage enrollment for UDFPS. This implementation
supports both highlighting the progress bar when a help message is
received and configuring the progress thresholds between enroll stages
via an XML resource.
Test: Manual
Bug: 198928407
Bug: 200076382
Change-Id: I6f6111ab0ed29ca7f1be01303f0457764d5afe01
During Camera2 Extensions initialization we need to check
if the Camera Extensions Proxy service supports advanced
extensions. Now we're not only waiting
for the service to connect but were also waiting for
the query for advanced extensions to finish.
Fixes: 198818625
Change-Id: I8040eab80a4b97f77b551152b3f76f93f9b8af88
For all possible states a device can assume, the DisplayManagerService
provides the DisplayInfo associated with that layout of the logical
display. WindowManager applies each possible rotation to these
DisplayInfo. This, in turn, is used to calculate the possible max
WindowMetrics on the device.
Done:
* Display stack builds collection of DisplayInfo, for all
possible display states (folded, unfolded on jumbo)
* Display stack pushing set of DisplayInfos to WindowManager
* WindowManager calculates max bounds for all possible
(display layouts x rotations)
Not started:
* WindowManager calculates insets for each rotation
Bug: 181127261
Test: atest DeviceStateManagerGlobalTest
Test: atest DeviceStateManagerServiceTest
Test: atest LogicalDisplayMapperTest
Change-Id: I3a407262e755cb57c506b7255eb5c067523381d3
This is a temporary workaround and the overlay properties can be removed
when the information is available from the HAL.
Bug: 174868353
Fix: 188690214
Test: manual (enroll and verify icon location)
Change-Id: I2b6826756814727368007e55bfc88d28c4a78bea
During high speed recording mode, it was observed that there was a
memory leak due to too many nodes at mPendingFrameNumbersWithOtherType
list. After ag/1962479 added batching for HFR it only updates the
FrameNumberTracker every 4 or 8 frames during high speed recording. This
change fixes that by updating every frame. A map is used to store
requestIds which have batchOutput. For every such requests we update
each frame in the batch in a for loop.
bug: 194618660
Test: 1. Did validity check with the change. Now frameNumber is incremented
by 1 instead of every 4 or 8 in FrameNumberTracker.
2. The mPendingFrameNumbersWithOtherType for otherType is empty during
HFR recording.
3. Verified using other modes of camera and did not observe any
crashes.
4. CTS tests Pass.
Change-Id: I2638e6663e7b70e4ef7a29dfeb27d423c9c7137d
(cherry picked from commit 236ed73e26)
Follow on from ag/15684817, where the WindowContext is cached in
MediaProjection. To allow multiple VirtualDisplays to be created
from the same MediaProjection, instead create a new WindowContext
for each one, and associate with that VirtualDisplay.
As before, the WindowContext must be stored in a field to prevent
it from being garbage collected.
Bug: 197579637
Bug: 198415847
Test: manual
Change-Id: If3f84b3778104bf12617d224876700f8ee3b2b45
The CancellationSignal passed into the authentication methods is not
associated with the request and can be used to cancel the current
operation, even if it is more recent. The new id prevents outdated
signals from being using.
Note that there are still issues with the Callbacks that are not
addressed (see bug for details).
Bug: 194405579
Bug: 189451155
Bug: 191716671
Test: atest com.android.systemui.biometrics com.android.server.biometrics
Change-Id: Id71be912cc88ae90df8087eb8f1a6fc3e110f883
