It might cause deadlock sometimes:
The locking order of setEventsMask is:
registerDisplayListener -> <DMG.mLock> -> setEventsMask -> <class lock>;
The Locking order of handleMessage is:
Looper.loop -> Looper.loopOnce -> Handler.dispatchMessage -> handleMessage -> <class lock>;
Therefore, when the registerDisplayListener is called by client,
the DisplayListenerDelegate.handleMessage also called by DMS's callback,
at this time, if the method with DMG.mLock is called in handleMessage(),
it will lead to deadlock.
Test: (For example)
Thread A:
DisplayListenerDelegate.handleMessage() -> <class lock>
DisplayListener.onDisplayChanged() -> DMG.getCompatibleDisplay() ->
DMG.getDisplayInfo() -> <DMS.mLock>
Thead B:
DMG.registerDisplayListener() -> <DMS.mLock> -> DisplayListenerDelegate.setEventsMask() -> <class lock>
Signed-off-by: jiayongqiang <jiayongqiang@xiaomi.com>
Change-Id: Ie1a8728339c16fa8f4c4f5c758821c836fa1c96b
Bug: 201045056
Test: Verified that BiometricPrompt shows an error message if the user
is using face authentication and camera privacy is enabled.
Change-Id: Idc2140062c4aa87e0bcffb14e07336dc6cd7d955
The JPEG size override is done only when the
android.os.Build.VERSION_CDOES.MEDIA_PERFORMANCE_CLASS is set to
31 or larger, and not necessarily for every MPC13 devices.
Bug: 209622756
Test: Build
Change-Id: I4d76db1780e0d777e8da68a06829ce0e424905d5
If the camera privacy sensor is enabled, show an error message
on Keyguard.
Test: Verified that the sensor privacy error is shown when privacy sensor is enabled.
Bug: 201045056
Change-Id: Ib7709596d378caa690a782294197a5b26e55857f
In case the camera client disconnects from an output surface referenced
by an active repeating request, a race could occur between the client
and camera service. Camera service will notify the client about the
failed repeating request and will reset the request id internally.
During this time period the client can also try to call "stopRepeating"
which will trigger an IAE, reset the client repeating request id value
and return immediately. Once the "onRepeatingRequestError" gets
scheduled or unblocked, the framework will just ignore it since it
doesn't have any information about an active repeating request.
The framework will be unable to track the last frame id in the repeating
sequence. The sequence will never complete and the 'onClosed' callback
will not get triggered as well.
To mitigate this, cache the request id in case of IAE during
"stopRepeating" and try to resume the last frame id sequence tracking
once "onRepeatingRequestError" arrives.
Bug: 205895636
Test: Camera CTS
Change-Id: I5da4a82d156227568aaebe74a5e0b2400de1d01e
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
