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
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
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
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
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)
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
When AChoreographer is the only callback registered with
DisplayManagerGlobal and there are no other display listeners,
DisplayManagerGlobal incorrectly skips callback registration with DMS.
Bug: 193945763
Test: atest DisplayManagerGlobalTest
Change-Id: I4b737fa0a91541fe331edcf3454724200e2db971
The message is empty, instead of null, to prevent apps from crashing but it will be changed to a more meaninful string in a future change.
Fix: 196176475
Test: N/A
Change-Id: I7823084238a87cb1b8892b8550c472cd8b40f556
Some preview extensions of the image processor type expect to recevive
'onOutputSurface' calls before the session is enabled by 'onEnableSession'.
Bug: 187341271
Test: atest -c
cts/tests/camera/src/android/hardware/camera2/cts/CameraExtensionSessionTest.java
Change-Id: I67147ec24553cf87d23e33c63692fa7e59c57e5f
Allow 'IRequestProcessorImpl' to return the camera sequence id
in response to capture requests.
Bug: 196090349
Test: atest -c
cts/tests/camera/src/android/hardware/camera2/cts/CameraExtensionSessionTest.java
Change-Id: I3d67e4ba1b4503cf71c31751920e916d014ef3ab
To avoid possible concurrency issues, always quit the handler
thread before releasing any extension resources.
In case camera is still running, camera callbacks can still
be handled during release which can result in concurrency
exceptions.
Bug: 195595369
Test: atest -c
cts/tests/camera/src/android/hardware/camera2/cts/CameraExtensionSessionTest.java
Change-Id: I473a4cb04e5ea27b5c8f8221a2390219a7915e73
If the system uid is being noted for mic or camera op, it will have to
be explicitely accounted for to show the user any sort of UI to unmute
the mic or camera.
Test: Add some logcat statements to verify the correct code paths are
being hit when placing and answering phone calls and when
trying to trigger hotword.
Bug: 195122900
Change-Id: I601458ea2dd7557e4a557eab32c2da15828ae4a7
Avoid overriding the native extension surface format when
retrieving the surface parameters.
The native surface format can later be used to configure
the device extension so the original value must be known.
Bug: 195366395
Test: atest -c
cts/tests/camera/src/android/hardware/camera2/cts/CameraExtensionSessionTest.java
Change-Id: I52d091fd782dc9ca2af60ba42ec1c5bbe080c1ca
With the new entries in sSetCommandMap, the private functions for
setting metering regions cast the input value to MeteringRegion[], which
can break some existing clients which pass in Object[] to
CameraMetadata.set(). We revert to the old behavior of letting Marshaler
handle conversion from Object[] -> MeteringRectangle[] internally.
Bug: 195095702
Test: GCA with different zoom (basic validity)
Test: ITS scene1_1
Test: Camera CTS
Change-Id: Iea372adf76d1c6f81f1c63ff2bd3553ab39f30e4
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
Instead of querying for the current user application side we can just
pass UserHandle.CURRENT_USER, this eliminates an IPC and the need for
INTERACT_ACCROSS_USERS permission which should not be needed for these
APIs.
Test: CtsSensorPrivacyTestCases
Bug: 194806109
Change-Id: I3a0aed0c403338aaebdfb4e2791a84b4e7e3cb3a
Default sensor mode capture requests would have their scaler crop
regions set to the default active / pre-correction array coordinate
system. Cameraserver needs to correct this for max res sensor pixel mode CaptureRequests.
In order to facilitate the correction, we add fwk-only CaptureRequest tags which are set when camera
clients set SCALER_CROP_REGION / metering regions.
Bug: 194143991
Test: CTS
Change-Id: I66393a1e6310f149138be4799f20ced377b11eb4
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
Adds this flag via FaceManager#authenticate (instead of other other
potential ways, such as reading the settings/config values from
system_server directly). This allows for a single source of truth.
Stores this flag in AuthenticationClient, which can then be retrieved
from the CoexCoordinator.
Also removes unnecessary FaceManager#authenticate method, as keyguard
is really the only supported client
Bug: 193089985
Test: atest KeyguardUpdateMonitorTest
Test: atest com.android.server.biometrics
Change-Id: I647c2e5926d1bb964b12dc580d2cd2178c30a790
On a secondary/guest user the mic/cam toggles show for user 0. We want
the user-free calls to reflect the state of the current user so things
like the UI is accurate. Before this change the user free calls always
checked for user 0 since the context was cached in SensorPrivacyManager.
This change also fixes some issues with removing listeners.
Test: use toggles on main, work profile, and secondary user
atest CtsSensorPrivacyTestCases --user-type secondary_user
Fixes: 178751362
Change-Id: Ieb90ea7ba4074446eb01d1093e280ac7018f9e73
Camera clients must be able to re-use the same output/outputs between
regular capture and extension sessions.
Re-shuffle the extension logic so that user registered outputs are
always accessed/connected to after the camera device configures its
streams.
Additionally disconnect any user registered outputs as soon as the
client requests a new regular capture session.
Bug: 194508189
Test: Partner testing,
Camera CTS
Change-Id: I112ad916e5d019d313767d3a0b0454165a6feb12
All parceled images need to include valid and correct
dimensions.
Bug: 194324683
Test: Manual using extensions sample application,
Camera CTS
Change-Id: I5ba90757e6edb0bb6bf1756d158c7ee402ce54ca
- Clarify raw capture behavior for logical camera with backward
compatible approach and MultiResolutionImageReader.
- Some logical camera devices may have identical physical cameras with
different focal length. Allow such logical camera to switch physical
cameras when outputing raw.
Bug: 182217158
Test: Build
Change-Id: I64458683f4eb8be6fc1e35270a8c22864d962be9
This reverts commit cff8340c84.
Reason for revert: Remove from July 2021 Android Security Bulletin due to break existing applications.
Bug: 176541017
Change-Id: Iacef744056630e85fb43d838a72abfae331cbaf4
Test: install WFD application and check whether it works normally.
