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>
The cameraservice is only registered to service manager after onFirstRef
is returned. To reduce the probability of getBinderService() call
returning null, move pingCameraServiceProxy to end of onFirstRef().
Also add debug messages in onFirstRef and main() for better diagnoses.
Test: Camera CTS
Bug: 140414594
Change-Id: I52defd1c138ade57ebc5181c42aff30921fbeaeb
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>
<IfaceName>Default class was automatically generated, but a change in
the AIDL compiler is scheduled to generate the class only when the aidl
file is compiled with `-version` option, because the default class is
only useful for the versioned AIDL case.
Stop using ICameraServiceDefault since it will be removed. Instead use
ICameraService class instead.
Test: build
Change-Id: Ifa06e5580f62878d498d9773c81da910ee84acd1
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>