Existing definition was inconsistent, so update it to be consistent
and match what implementations have actually done.
Test: Builds
Bug: 150331548
Change-Id: I037edfbf462ae9822194761d68bcfa34d27f79c6
Because callbacks are called from a looper thread, if the subscriber
unsubscribes and frees the callback, invalid memory access may occur from the
looper thread.
Address this by draining all pending callbacks at the time of listener
unregistration.
NOTE: There is rare chance that the wait on the condition times out,
still resulting in the original NPE issue. We intensionally allow that
to avoid deadlock, in case the application uses the same mutex lock for
callbacks and unregister functions.
Test: for i in {1..10}; do atest -it NativeImageReaderTest; done
Test: ACameraNdkVendorTest
Bug: 148976953
Change-Id: I92f5a02a4e3e63f2e72e8043ff4f4ac16c1eec5d
To better document how android.control.zoomRatio works, add examples to
illustrate its relationship with scalerCropRegion.
Test: Build and read docs
Bug: 144780745
Change-Id: Iab0e849b4d045fc1648fcf2ddc51d84c66249273
Migrate BOKEH_MODE_STILL_CAPTURE and BOKEH_MODE_CONTINUOUS to be 2 enums
of CONTROL_EXTENDED_SCENE_MODE.
Test: Camera CTS, VTS
Bug: 151759402
Change-Id: Ie56c6403cd7b530356d3a007088e30730906ec65
Implementation is not complete yet, so hide the feature for now.
Test: Adjusted camera CTS continues to pass
Bug: 150036107
Change-Id: Ie112d21121693336c77700b982fc547f5cba429b
Duration keys may be missing if the device doesn't support
corresponding capture feature.
Test: build (log only change)
Bug: 150900659
Merged-In: I83e122ff08bc581ddd4bb7e304f152f612817875
Change-Id: I83e122ff08bc581ddd4bb7e304f152f612817875
The onCameraOpened/onCameraClosed callbacks are used to notify camera
service client with CAMERA_OPEN_CLOSE_LISTENER permission that a certain
camera device has been opened/closed.
Test: Manually check callbacks are received in SystemUI app
Bug: 150540299
Change-Id: If6f3624c43927c30afef7df0a780eafe3ae4c527
Instead of requiring the user to call NewGlobalRef/DeleteGlobalRef
for keeping the java object alive when creating an NDK view into it,
reference count the real native data instead, so that there's no need
to keep track of the Java object lifecycle.
- Switch CameraMetadataNative to use std::shared_ptr internally
- Switch ACameraMetadata to use std::shared_ptr internally
- Always copy data in the ACameraMetadata copy constructor
Test: New CTS tests pass, fail without this CL
Bug: 148972471
Change-Id: I40a0ccb8b40c7a89ee7d3a6f7bac7c9c88d709f1
Also fixed missing implementation of Camera availability callbacks for
ExtendedAvailabilityCallback.
Test: Camera CTS, and vndk test
Bug: 148146086
Change-Id: I557d6db3900b2346b7bc7e12cd946bc4c2dc4076
Root cause was that jclass instances acquired from JNIEnv::FindClass are
not pinned and become invalidated due to Java garbage collection. Adding
a new global ref pins the pointer.
FIXED=148174094
Test: atest android.hardware.camera2.cts.CameraManagerTest#testCameraCharacteristicsNdkFromSdk android.hardware.camera2.cts.CaptureResultTest#testCameraCaptureResultAllKeys
Test: atest NativeCameraDeviceTest NativeCameraManagerTest NativeImageReaderTest NativeStillCaptureTest
Change-Id: Id0601b9c01e1a58485e3b039a87a5cf56a19e0af
The new provider callback version enables availability callback for
physical camera.
Test: Camera CTS
Bug: 119325027
Change-Id: I22e0b669c3d9891a431e1befc7f1c9f40b826a08
Camera clients must be aware of any configured streams
that can support offline processing mode.
A few corner cases that need to be considered:
- Composite streams can support offline mode only
when all internal streams support it as well.
- Streams that use the internal camera buffer manager
will not have support for offline mode.
- Shared streams are also unsupported in offline mode.
Bug: 135142453
Test: Camera CTS
Change-Id: Idde826a6fb18a8907850e87cfe593de7cb1c5f4a
Specifically, publicly commit to UNKNOWN being CLOCK_MONOTONIC, though
with loose accuracy guarantees.
Also document how to handle REALTIME timestamps for A/V sync purposes.
Test: Builds, docs-only change
Change-Id: I600b553c38f1b3490879630ae90d207bed0277b5
To better document the cropping specification for camera2, add diagrams
from source.android.com into the reference docs as well.
Test: Docs build, look correct
Change-Id: I624dac7dbdc9146fbb89ab57cf6fda4ae03c1214
- Add NDK API spec for the new zoom API
The new zoom API combines optical and digital zoom, and supports both
zoom-out and zoom-in with more precision.
- Add new NDK API to specify separate zoom ratio ranges for different
bokeh modes.
- Add ZoomRatioMapper in camera service to convert between
control.zoomRation to and from scaler.cropRegion.
Test: Camera CTS/ITS/CtsVerifier/ZoomRatioTest
Bug: 130025314
Change-Id: I4c7d867f840b5720bc73bb0485e8a9a93d2276b5
Bug: 136595429
Test: atest CtsAppOpsTestCases (now including two new test cases that
open a camera with a null and a non-null feature)
Change-Id: Idfb8f8049dff536525d4f081151c79d980d76c69
Introduce new bokeh mode metadata tags for camera device to enable bokeh
effect.
Test: Build and read docs
Bug: 118258123
Change-Id: Iadd7c2a0edcafc516411a5a5f49ad0563e3736be
We call disconnectLocked before stopping CameraDevice's looper, in order to avoid this situation:
1) Its possible that an OnResultReceived callback is received, and posts an
AMessage with sp<ACameraCaptureSession> on CameraDevice's looper.
2) Before the looper message is processsed, ACameraDevice_close() is
called by the client, which results in the looper being stopped and
cleared with device lock held.
3) When the looper is getting cleared, the AMessage containg the
ACameraCaptureSession pointer is destructed leading to
~ACameraCaptureSession running without knowing that the device is
being closed, as a result it tries to hold device lock, resulting in
a deadlock.
Bug: 141603005
Test: CTS native tests
Test: use camera2 vndk client for extended periods of time
Change-Id: Ia0d47fc2975981055cd1f2103c1cbe8d76642fe4
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
Since these were combined into libhidlbase.
Bug: 135686713
Test: build only (libhwbinder/libhidltransport are empty)
Change-Id: I6cc85a91afb603e31b85090917f9f3b59d82a4d1
Bug: 133508924
Bug: 138135733
android.permission.CAMERA and android.permission.SYSTEM_CAMERA are both
required by a client process to access system only cameras.
Test: Advertise the back camera as system only;
1) don't give Camera2 SYSTEM_CAMERA permissions,
Camera2 can't connect to the back camera
2) give Camera2 SYSTEM_CAMERA permissions, Camera2 successfully
connects.
3) 3P app can't connect to any camera if all cameras are
advertised as SYSTEM_ONLY_CAMERAs.
Test: CTS CameraDeviceTest, CameraManagerTest
Change-Id: I0309462f962d9c8c92564ef6781b2aae1485a933
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
This helps application developer be aware of availability of
postRawSensitivityBoost.
Test: Build and read docs
Bug: 119755308
Change-Id: I65778a17d98aa9a9bdbb4a452005c25dfae96950
It's possible that the following sequence happens:
1) hwbinder / binder thread T1: onResultReceived() starts -> promotes wp<CameraDevice> to sp<>;
2) Some other app thread T2 : ACameraDevice_close() -> delete ACameraDevice -> doesn't result in
CameraDevice's destructor running since mCameraDevice has another live
reference, app destroys some object O1.
3) T3 (callback looper thread): callback is received since looper is still running which accesses
dead app object O1 -> results in undefined behavior.
4) T1: onResultReceived completes and CameraDevice is destructed
We need to stop CameraDevice's looper thread (that waits for all callbacks queued to complete) in
~ACameraDevice() so we receive no callbacks after ACameraDevice is closed.
Bug: 135641415
Test: CTS native tests: no new failures
Test: AImageReaderVendorTest; enroll; while(1) auth;
Change-Id: Ia24de753f6ee409d941fff39616f09df2164880a
Merged-In: Ia24de753f6ee409d941fff39616f09df2164880a
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
(cherry picked from commit 174084011c)
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
It's possible that the following sequence happens:
1) hwbinder / binder thread T1: onResultReceived() starts -> promotes wp<CameraDevice> to sp<>;
2) Some other app thread T2 : ACameraDevice_close() -> delete ACameraDevice -> doesn't result in
CameraDevice's destructor running since mCameraDevice has another live
reference, app destroys some object O1.
3) T3 (callback looper thread): callback is received since looper is still running which accesses
dead app object O1 -> results in undefined behavior.
4) T1: onResultReceived completes and CameraDevice is destructed
We need to stop CameraDevice's looper thread (that waits for all callbacks queued to complete) in
~ACameraDevice() so we receive no callbacks after ACameraDevice is closed.
Bug: 135641415
Test: CTS native tests: no new failures
Test: AImageReaderVendorTest; enroll; while(1) auth;
Change-Id: Ia24de753f6ee409d941fff39616f09df2164880a
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
Eino-Ville Talvala
Shuzhen Wang
Yin-Chia Yeh
TreeHugger Robot
Jayant Chowdhary
Jiawen Chen
Emilian Peev
Philip P. Moltmann
Steven Moreland
Andrew Chant