Some HALs may advertise slightly larger min frame durations, which
makes the supported fps check fail. Then, some supported fps range
may be missing in the supported preview fps range list.
Bug: 32544699
Change-Id: I1ed62b97d3d39e5d7f0e7c407c6cc482b8968373
The advertised supported preview fps ranges need to be supported
by all preview sizes. This change does the check to make sure the
API1 doesn't over-advertise its capability.
Bug: 32360340
Change-Id: Iccd13967305f1d0a62b89da87070591bfb973bbf
* Add explicit keyword to conversion constructors.
Bug: 28341362
* Use const reference type for read-only parameters.
Bug: 30407689
* Use const reference type to avoid unnecessary copy.
Bug: 30413862
Test: build with WITH_TIDY=1
Change-Id: I71d3008da843ba5f1df1a73a320fb2af6ceffa16
Merged-In: I71d3008da843ba5f1df1a73a320fb2af6ceffa16
JpegProcessor::onBufferReleased is fired for both successful and failed
Jpeg captures, but only cares about the failures.
In success cases, onBufferReleased is always fired some time after
onFrameAvailable, and sometimes the thread scheduling pushes
onBufferReleased to be so late that preview restart has started, which
can cause a deadlock with onBufferReleased acquiring locks in the
opposite order that preview startup will.
To fix, move the JpegProcessor mutex acquire to only happen in the error
cases, in which case onFrameAVailable will not have fired, and the
camera state will still be STILL_CAPTURE, not STOPPED or mid-preview
startup.
Bug: 29524651
Change-Id: I3f103e070c3b39c38117b91824cd79c5dfc757ac
- Don't engage ZSL if picture size is too small
- Don't engage ZSL if picture size matches preview size
- Include ZSL choice in dumpsys
Bug: 29620318
Change-Id: Ie8e0c5a9e1ed9f177d701f22996c4c1f4b81a71e
Add new binder calls to pass video native handle so the video native
handle can be passed between 32-bit and 64-bit processes.
Remove problematic code that used IMemory to pass video native
handle because the sizes of VideoNativeMetadata are different in
32-bit and 64-bit processes.
Bug: 28403412
Change-Id: I3341b1812ecc41d61846bb72ca926ecb1674c9ec
After a device has been disconnected, should return consistent errors
to the caller if they invoke further device methods.
For API1, that's INVALID_OPERATION, and for API2, that's
ERROR_DISCONNECTED.
Change-Id: I0f3d889906a9818c0e03852702b146fd33c9e42a
Fixes: 27591189
Camera api1 doesn't have error notification if JPEG buffer is dropped.
Add retry logic to try again if such error happens.
Bug: 27074407
Change-Id: I646566c6ee5a064896b5a433d8e1797140f0d257
- Switch clients of camera devices to use new dataspace values
- For older HALs, map to legacy dataspace values
Bug: 27344373
Change-Id: Icabc345025383f987ef4472cd26182a580dc8b3c
Change Camera3Device to send partial results as soon as a
partial result is received from HAL so that 3A partial results
are not bundled.
Change FrameProcess to wait until all 3A states are received before
notify the client about 3A changes.
Bug: 17320166
Change-Id: I31a3e42081430ff4f7a482c4b2f1db272b8b2e4a
- Also fix error logging template inconsistency
- Also add a few error handling cases into camera2 NDK
to deal with previously-ignored error codes
Bug: 27149500
Change-Id: I8f1f4c72252dd48d652f24b595b642199f20c327
Workaround for b/27039775
Some camera device HAL v1 implementations expect that calling
preview_stream_ops->set_buffer_count resets the preview stream's flag
for whether any buffers have been queued up by the camera HAL, allowing
the HAL to dequeue all buffers in the stream again (instead of just its
own buffer count limit, which is lower).
The underlying buffer queue behavior has now changed, and that flag is
no longer reset on a change of buffer count, to support dynamic buffer
queue buffer count features.
To maintain backwards compatibility with HALv1 implementations that rely
on this implicit HAL interface behavior, add a disconnect/connect pair
to the set_buffer_count call, which will reset the dequeue flag, along
with all other preview stream parameters.
To maintain other parameters, cache them when they are originall
set (either by the HAL or by the higher-level camera client), and apply
them again after reconnecting.
Bug: 27039775
Change-Id: I9fa220b356715e7f8e48adc7acdffbfa598c329c
Modify StageFright's CameraSource to forward calling PID as
client PID when connecting to CameraService so CameraService
can check if the client PID has permission to use camera.
Change CameraService to check calling UID is trusted before
using the passed in client PID and client UID to verify permission.
Bug: 24511454
Change-Id: I4906ab73510e2c75714690bed675e3c13aca3ccf
The camera service may fail to release the camera hardware instance
in some use cases.
When an application unlocked the camera before disconnect, disconnect
from the application will not be accepted. And disconnect from media
server will not be accepted also. Then, the camera hardware instance
will not be released and a resource leak will be caused.
Allow media server to disconnect the camera at all times even if
the camera is unlocked.
Change-Id: Icd5ed81bed242fa5947aa40ca85e4ca7fa7286e7
Use a BufferQueue between Camera and StageFright to pass video
buffers for Camera HALv3 devices.
CameraSource in StageFright will try to use "buffer queue" mode
if it is supported by the camera device. In "buffer queue" mode,
CameraSource creates a buffer queue and a listener thread to recieve
video buffers from camera device. CameraSource then wraps the
ANWBuffer in MediaBuffer. If the camera device doesn't support
"buffer queue" mode, it falls back to "metadata in video buffer"
mode or "real YUV data" mode.
"Metadata in video buffer" mode is removed from Camera2Client and
only "buffer queue" mode is supported.
Bug: 24511454
Change-Id: Ice833b57bcd8d91852d6415402013f56f3e3970a
HALv2 only ever shipped with Nexus 10, and has been fully superceded by
HALv3. Remove it to allow for various code simplifications and cleanup.
- Remove Camera2Device
- Remove various special-case codepaths for supporting Camera2Device
- Remove CameraDeviceFactory, since it only creates Camera3Devices now
- Remove BurstCapture and associated CaptureSequence/Parameters code
- Remove old ZslProcessor and simplify ZslProcessor hierarchy to be
just ZslProcessor3, which is renamed to just ZslProcessor
- Add service-init-time check for unsupported device versions
- Fix assorted compiler warnings, some old, some new
- Remove references to HALv2 when possible
Bug: 25866588
Change-Id: Ia1063264d315f9b742ec5cdd0483539310894f5e
Meeting the condition
if (sceneModeOverrides.count !=
availableSceneModes.count * kModesPerSceneMode) {
results with ALOGE which describes the missmatch.
The description does not match the condition.
Signed-off-by: Hubert Rzezniczak <hubert.rzezniczak@gmail.com>
Send the camera proxy service in system server updates to
camera device state: opened/closed/active/idle.
Bug: 23393557
Change-Id: Id7c70f134821efa34af8f6e7b4caa4c2ab128ebc
If largest jpeg stream cannot sustain 30 FPS, don't
create jpeg stream until takePicture is called and remove
it after still capture is done.
Also, disable video snapshot for such sensors so video snapshot
won't slow down video recording.
Bug: 22231605
Change-Id: I2b34d2537c224694ae10f2006b5a46be45a1b1a6
Also switch use of ANativeWindow to Surface, to get to the
getConsumerName() method where necessary.
Surface can always be cast to ANativeWindow, but not the other way
around, so it's a better option anyway.
Change-Id: Ie5c2d30821c1a754f9e382699ff50b4b328288b3
- Support new set video format/dataspace command in camera service
- HALv3: Select gralloc usage flags based on format
- HALv1: Pass format command directly to HAL layer
- Use format/dataspace command in CameraSource
- Switch all API1 recording to use metadata mode
- Switch all >= HALv2 API1 recording to use kMetadataBufferTypeANWBuffer
Bug: 13222807
Change-Id: I2e609b92c65792611bb1dab09e0c41c363ebbc42
Previous implementation only notifies the callback when we receive
full capture result. This implementation notifies the callback
once HAL sends capture start callback.
Bug: 12530628
Change-Id: Ibf71d532b5cf649514b316e35683c217021698b4
Due to older HAL compatibility, we have been setting a tight crop region
that just bounds the current output streams. However, this did not take
into account any possible ZSL output stream, so correct application of
our stream cropping rules to ZSL results in double-crop scenarios, if
the ZSL stream aspect ratio does not match the aspect ratio of the other
output streams.
Since all current HALs follow the correct stream cropping rules (or
at least sufficiently ignore them for ZSL), simplify the cropping
substantially - now either calculate the crop region based purely
off the active array dimensions and zoom factor, or purely off
the preview stream and zoom factor. The former is used for setting
the request crop, and the latter is used for converting coordinates
for metering regions.
Bug: 20316691
Change-Id: I5a0bc2e7c09cf60fbae4220566540ca9e674d652
[Cause]
CallbackProcessor uses always same buffer to send preview data.
A buffer is written before it is read by user process.
[Solution]
Increment buffer index correctly.
Change-Id: I87a7e3dc6546448a419c96aa58ace3b7d086bf70
- This updates the CameraService to implement client
eviction behavior based on process priority.
Bug: 19186859
Change-Id: I646939b1cdf1a2237c4e5044164d55a2542cf36e
Switches all uses of IGraphicBufferConsumer::BufferItem (and
BufferQueue::BufferItem) to the BufferItem in libgui. Depends on
frameworks/native I699ed0a6837076867ca756b28d1ffb2238f7a0d9.
Change-Id: I187b3a7d05196b6289596afac8fb9a9d4aebff76
- Remove unused arguments from ICameraDeviceUser::createStream
- Add dataSpace as a stream parameter, plumb it through everything
Change-Id: I608cafe694785d1c512276e71b2016f8ac3b0ccb
Wrap camera module returned from HAL so get_camera_info returns
static_camera_characteristics processed by framework, which
generates keys added after HAL3.2 is released.
Change-Id: Ief423a1571cf06c7ef80b98b403a33969baf95f6
Requests queued in the pipeline have little meaning after the app
calls stopPreview(). Flushing will help improve the switch KPI.
bug 17340914
Change-Id: I899d69aa3b0fd41f028760290a81013297712fed
AF state mismatch while selecting ZSL candidate should not be treated
as a warning. This results into undesriable spam in the logs.
ALso, using ALOGVV is consistent with how AE state mismatch is handled
in ZslProcessor3.cpp
Bug: 18634318
Change-Id: Ia9d7f2bb98f784990b1a6f923983c35f622c3791
* Fix string literal concatenation to not be interpreted as UD
literals.
* Add constexpr compatibility for non-integral static members.
* Use __typeof__ instead of typeof (should become decltype once this
actually becomes C++11).
* Add an appropriate cast for atomic_uintptr_t, since moving to C++11
means moving from <stdatomic.h> to <atomic>, which has better
typechecking (hooray for not macros!).
Bug: 18466763
Change-Id: I9561dcb2526578687819ff85421ba80d8e1a9694
to use the new static version.
Change-Id: Ia7b10eb38ca55b72278bfd33d3bf647f338b4e6a
Conflicts:
media/libmedia/IAudioFlinger.cpp
media/libmedia/IMediaPlayer.cpp
media/libstagefright/CameraSource.cpp
Use android.scaler.cropRegion reported in the capture result to
normalize face rectangles instead of using the one in current capture
request.
Bug: 11460393
Change-Id: Id21834bf6ae1f7cc106b4dffb98f9f249a75034b
Passes the BufferItem for the queued buffer to the onFrameAvailable
callback so the consumer can track the BufferQueue's contents.
Bug: 18111837
Change-Id: If9d07229c9b586c668e5f99074e9b63b0468feb0
The threads shutting down may have callpaths that require taking the
binder interface mutex, so waiting to join them with that mutex held
can lead to deadlocks.
A specific instance is StreamingProcessor calling dataCallbackTimestamp,
which can immediately lead to a Camera2Client::releaseRecordingFrame call,
which requires the binder interface mutex. If this call happens right when
shutdown is occurring, and Camera2Client::disconnect is holding the mutex,
deadlock ensues.
Bug: 17997578
Change-Id: I71253cd5542b5920ad205976d315110ca0043d94
When mediaRecorder starts without an active preview stream, Camera2Client
starts preview then immediately start recording, which could cause the second
configure_streams to call into HAL before any preview request is sent. This
could cause HAL to run into bad state. This change work around this issue
by making sure the first preview request is submitted to the HAL before
start recording.
Bug: 17915062
Change-Id: I94ae64ee76487603695a469240da601ddcb29a66
- Do not idle device before video snapshot stream configuration, to
avoid deadlock during waiting.
- Do not tear down ZSL stream
- Don't refresh ZSL stream after deletion was requested.
The v2 HAL implementations really don't like the ZSL stream being
touched ever.
Bug: 17634430
Bug: 17628507
Change-Id: I36b44a395e697be9802c4bd917a82b77c8d04be2
Previously, we set FLASH_MODE_OFF for FLASH_MODE when a flash unit
isn't available. However, per the API documentation, the key has to
be null instead.
- Make sure that the flash mode and supported flash mode keys are null
if there's no flash unit on start
- Don't set flash mode in later setParameters calls if there is no
flash unit
- Map NULL value for flash mode key to FLASH_MODE_OFF for internal
consistency.
Bug: 17660716
Change-Id: I3033682f0b882b8c2004114e2afef31662caebda
ZSL counts on good auto focus (CAF). It is really tricky to enable ZSL for
manual focus mode. as it is bascically a locked focus mode, you can not tell
if the focus is good or not by reading the afstate.
Bug: 17577928
Change-Id: I68ff7d143e7d56f942bb00a8da6a9faea57b52a0
Update ZSL processing tags according the still capture template
Also cache the request template to avoid extra cost of querying
into HAL every time.
Bug: 17463102
Change-Id: I2eeffefb0a4131c99a85dd3e4484cc6f0f025efa
Don't allow uncalibrated cameras to list a fixed focus mode for
variable-focus cameras, since uncalibrated cameras cannot do INFINITY
focus.
Bug: 17492043
Change-Id: I5835efd6f21be0ebb74a9b7ea3ef5b2e7cf63e7a
Limit preview resolutions to a max of 1920x1920 instead of 1920x1080p,
so that any aspect ratio with a 1920 as the larger dimension can be used.
Also improve the initial preview/video size selection logic, to ensure
that the selected size is both a valid preview and video size, and not
too large.
Bug: 17458832
Change-Id: Iea006fadb5fbf0f03d23c3c5babb5b3611469688
After ZSL queue is cleared, don't add capture result to ZSL queue
if its corresponding buffer has been cleared.
Bug: 17185356
Change-Id: Iddac39ab09b2560e2ce9390895927217c1736d5a
1. Clear ZSL queue when focus mode is changed and autoFocus is
cancelled.
2. Do not check focus state is focus mode is fixed.
Bug: 17185356
Change-Id: I2cb10fb457b080f0db950c894e56995f638e147b
Bug: 15408128
- Lazily destroy ZSL stream when ZslProcessor is updated, or
when the camera client is disconnected, allowing HAL 2.*
devices that rely on the ZSL stream to capture video snapshots
to function correctly.
Change-Id: Ia5cf14c62acda4d9c640440dc5b8e0796dc0b3fa
When recording fails to start due to stream configuration failed,
try configure stream again by setting jpeg stream to video size.
Bug: 16162133
Change-Id: Ib20271e787ae07719ce419f0b15c7f86434f7ebb
It is legal to transit to CONVERGED or FLASH_REQUIRED after a AE precapture
trigger.
Bug: 17365185
Change-Id: Id041eff5eac564c32d09b547a0139d24807336f4
ZSLProcessor3 shouldn't acquire mInputMutex in onBufferReleased call for output
buffers, because the caller (Camera3Stream::returnBuffer) holds the camera3
stream lock already. This could cause deadlock for ZSL reprocess request as it
holds the ZSLProcessor3 input lock and try to acquire camera3 stream lock to
submit the request.
Bug: 17299038
Change-Id: I6a7bf8ebd7c2064852358c655f3a3e9a67769213
Zsl buffer needs to be longer than metadata queue to ensure that
oldest metadata can always find a match in buffer queue.
Since we don't want to add memory overhead, decrease metadata
queue size by one serves the same purpose.
bug 17264283
Change-Id: Ic53441cc29c98e57d3345f5845d92839d0ce6faf
As a workaround, duplicate CameraParameters into CameraParameters2 to
prevent ABI break for some camera HALs that directly link into
CameraParameters.
CameraParameters2 implements the real fixes needed in the framework,
while CameraParameters is left in to satisfy older camera HALs.
Bug: 12609188
Bug: 16654949
Change-Id: I82ea6f5de2183dd046d4bf5683600c97f37ab4da
When using the connectLegacy binder interface (available only
through an @hide java api), then consider the camera to be in the
camera2 api legacy mode.
In legacy mode, allow disabling the shutter sound unconditionally.
Bug: 17109582
Change-Id: Ieb3fc61ff111d792cc657c018e278349c25472cf
- Only one place calculating the jpeg size-the device layer, Camera2Device and
Camera3Device.
- Remove size argument for CameraDeviceBase and cleanup related code.
Bug: 14327010
Change-Id: I45d2ab4859ee0cc9273e579254f0569108c748f1
This fixes a crash if the camera was locked by the media recorder and
another process tried to get the legacy parameters (for the camera
characteristics).
Bug: 16695955
Change-Id: I945a16a686a6987150c8754b5296353e76e5afa0
Also override the disconnectLocked method in Camera3ZslStream to make sure the
Camera3ZslStream specific buffer queue is cleaned up properly.
Also revert 0be123df18, as it was not the right
fix.
Change-Id: I89bdcb2e206379ae1f2602421e7fdbcde9a31399
not clearing the queue here will eat up unnecessary memory every time
we switch from video to still mode.
Change-Id: I279ec709b485ca0dab672464e5b829be849bcaa5
- Enable the normal partial result path for HAL3.2, the quirk is only used
for the HAL version lower than HAL3.2. The partial quirks is no longer supported
for HAL3.2 or higher versions.
- Add CameraDeviceBase getDeviceVersion API.
- Fix some build warnings
Change-Id: I7a1b03d4d5fd5258d2addfba4368bee2ba691337
- Return input buffer in capture result. Per hal3.2 spec, we should return the
input buffer in process capture result rather than immediately after process
capture request.
- Make the depths of mZslQueue and mFrameList the same. It doesn't make sense
mFrameList depth is larger than mZslQueue depth.
- Set the depths of mZslQueue and mFrameList based on pipelineMaxDepth.
- Clear result queue while clearing zsl buffer queue.
- Hook up camera3 buffer listener with ZslProcessor3, make sure that adding the
same listener multiple times has no effect.
- Remove flush call in pushToReprocess, it is a guaranteed deadlock once
camera3 buffer listener is hooked up.
Change-Id: I285155ab4241e827145855d628f8e98b881c01d5
ZSL clients expect each received result as a complete result, and send back to
HAL as a reprocess capture request. CaptureSequencer client assumes results to
be non-partial too, it need look into some metadata that may not be present in
partial results.
Change-Id: Id716913fd6e1c914726abd6610fddf91141783c2
The following two tags are deprecated from HAL 3.2:
ANDROID_CONTROL_AF_TRIGGER_ID
ANDROID_CONTROL_AE_PRECAPTURE_ID
Trigger IDs are now internal to camera service.
Change-Id: Iaebd62ecb0905a811fa37fe7850e0221c38a0006
Starting from device version 3.2, the following tags:
ANDROID_SCALER_AVAILABLE_FORMATS
ANDROID_SCALER_AVAILABLE_JPEG_MIN_DURATIONS
ANDROID_SCALER_AVAILABLE_JPEG_SIZES
ANDROID_SCALER_AVAILABLE_PROCESSED_MIN_DURATIONS
ANDROID_SCALER_AVAILABLE_PROCESSED_SIZES
ANDROID_SCALER_AVAILABLE_RAW_MIN_DURATIONS
ANDROID_SCALER_AVAILABLE_RAW_SIZES
are deprecated and replaced by:
ANDROID_SCALER_AVAILABLE_STREAM_CONFIGURATIONS
Change-Id: Iadc34af0ea985a16a25759d7a9a3eb4845c486fd
A higher hal version device like HAL3.2 can be opened as HAL1.0 device
if HAL supports it. This only applies to camera API1.
Change-Id: I4ae9f59f4317158cc1bd7ed7726e4032cdd1fa07
It is dangerous to release all recording buffers when recording stream is
actively sending buffer to encoder. This change only releases all buffers when
recording stream is idle and recording stream is about to start.
Bug: 15667833
Change-Id: Ia4a84cac84a2062c13333467c66698273ffb0e23
Supported video sizes were generated from supported preview sizes, which
effectively filtered out sizes larger than 1080p. This change filters the
supported video sizes based on the media profiles supported h.264 max video
frame width and height.
Bug: 15287656
Change-Id: Ifbd9d37fb775371e2a4ee5cf80abbf83a75ffd65
* Instead of tracking CameraMetadata only, now we track both
CameraMetadata and CaptureResultExtras, which is not part of
the HAL metadata. This will enable the correct callback of
onCaptureStarted and onResultReceived given burst requests.
* Get last frame number in reply when submitting requests,
canceling requests, and flushing device. For repeating requests,
this frame number is the last frame number of the previous
request. For non-repeating requests, this frame number is the
expected last frame number of the current request. The goal
is provide frame number to Java side in order to trigger
onCaptureSequenceCompleted correctly.
* Fix notifyError so that onDeviceError can be called correctly.
Bug: 10749500
Change-Id: I2f3dda6c530090055d4a2ff9f0f087bbbe8d9257
Zhijun He
Chih-Hung Hsieh
Eino-Ville Talvala
Yin-Chia Yeh
Chien-Yu Chen
Shuzhen Wang
Wang, Jianfeng XA
Hubert Rzezniczak
Pablo Ceballos
daisuke jinno
Ruben Brunk
Dan Stoza
Ruchit Sharma
Dan Albert
Marco Nelissen
Igor Murashkin
Yuvraj Pasi
Jianing Wei