Home | History | Annotate | Download | only in camera
      1 lpage.title=Camera Version Support
      2 @jd:body
      3 
      4 <!--
      5     Copyright 2016 The Android Open Source Project
      6 
      7     Licensed under the Apache License, Version 2.0 (the "License");
      8     you may not use this file except in compliance with the License.
      9     You may obtain a copy of the License at
     10 
     11         http://www.apache.org/licenses/LICENSE-2.0
     12 
     13     Unless required by applicable law or agreed to in writing, software
     14     distributed under the License is distributed on an "AS IS" BASIS,
     15     WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
     16     See the License for the specific language governing permissions and
     17     limitations under the License.
     18 -->
     19 <div id="qv-wrapper">
     20   <div id="qv">
     21     <h2>In this document</h2>
     22     <ol id="auto-toc">
     23     </ol>
     24   </div>
     25 </div>
     26 
     27 <p>This page details version differences in Camera HALs, APIs, and associated
     28 Android Compatibility Test Suite (CTS) tests. It also covers several
     29 architectural changes made to harden and secure the camera framework in Android
     30 7.0 and the updates vendors must make to support these changes in their camera
     31 implementations.</p>
     32 
     33 <h2 id=glossary>Terminology</h2>
     34 
     35 <p>The following terms are used on this page:</p>
     36 
     37 <dl>
     38 
     39 <dt>Camera API1</dt>
     40 <dd>The app-level camera framework on Android 4.4 and earlier devices, exposed
     41 through the <code>android.hardware.Camera</code> class.</dd>
     42 
     43 <dt>Camera API2</dt>
     44 <dd>The app-level camera framework on Android 5.0 and later devices, exposed
     45 through the<code> android.hardware.camera2</code> package.</dd>
     46 
     47 <dt>Camera HAL</dt>
     48 <dd>The camera module layer implemented by SoC vendors. The app-level public
     49 frameworks are built on top of the camera HAL.</dd>
     50 
     51 <dt>Camera HAL3.1</dt>
     52 <dd>Version of the camera device HAL released with Android 4.4.</dd>
     53 
     54 <dt>Camera HAL3.2</dt>
     55 <dd>Version of the camera device HAL released with Android 5.0.</dd>
     56 
     57 <dt>Camera API1 CTS</dt>
     58 <dd>Set of camera Compatibility Test Suite (CTS) tests that run on top of Camera
     59 API1.</dd>
     60 
     61 <dt>Camera API2 CTS</dt>
     62 <dd>Additional set of camera CTS tests that run on top of Camera API2.</dd>
     63 
     64 </dl>
     65 
     66 
     67 <h2 id=camera_apis>Camera APIs</h2>
     68 <p>Android includes the following camera APIs.</p>
     69 
     70 <h3 id=camera_api1>Camera API1</h3>
     71 
     72 <p>Android 5.0 deprecated Camera API1, which continues to be phased out as new
     73 platform development focuses on Camera API2. However, the phase-out period will
     74 be lengthy, and Android releases will continue to support Camera API1 apps for
     75 some time. Specifically, support continues for:</p>
     76 
     77 <ul>
     78 <li><em>Camera API1 interfaces for apps</em>. Camera apps built on top of Camera
     79 API1 should work as they do on devices running earlier Android release versions.
     80 </li>
     81 <li><em>Camera HAL versions</em>. Includes support for Camera HAL1.0.</li>
     82 </ul>
     83 
     84 <h3 id=camera_api2>Camera API2</h3>
     85 
     86 <p>The Camera API2 framework exposes lower-level camera control to the app,
     87 including efficient zero-copy burst/streaming flows and per-frame controls of
     88 exposure, gain, white balance gains, color conversion, denoising, sharpening,
     89 and more. For details, watch the
     90 <a href="https://www.youtube.com/watch?v=92fgcUNCHic&feature=youtu.be&t=29m50s">Google
     91 I/O video overview</a>.</p>
     92 
     93 <p>Android 5.0 and later includes Camera API2; however, devices running Android
     94 5.0 and later may not support all Camera API2 features. The
     95 <code>android.info.supportedHardwareLevel</code> property that apps can query
     96 through the Camera API2 interfaces reports one of the following support
     97 levels:</p>
     98 
     99 <ul>
    100 <li><code>LEGACY</code>. These devices expose capabilities to apps through the
    101 Camera API2 interfaces that are approximately the same capabilities as those
    102 exposed to apps through the Camera API1 interfaces. The legacy frameworks code
    103 conceptually translates Camera API2 calls into Camera API1 calls; legacy devices
    104 do not support Camera API2 features such as per-frame controls.</li>
    105 <li><code>FULL</code>. These devices support all of major capabilities of Camera
    106 API2 and must use Camera HAL 3.2 or later and Android 5.0 or later.</li>
    107 <li><code>LIMITED</code>. These devices support some Camera API2 capabilities
    108 (but not all) and must use Camera HAL 3.2 or later.</li>
    109 </ul>
    110 
    111 <p>Individual capabilities are exposed via the
    112 <code>android.request.availableCapabilities</code> property in the Camera API2
    113 interfaces. <code>FULL</code> devices require the <code>MANUAL_SENSOR</code> and
    114 <code>MANUAL_POST_PROCESSING</code> capabilities, among others. The
    115 <code>RAW</code> capability is optional even for <code>FULL</code> devices.
    116 <code>LIMITED</code> devices can advertise any subset of these capabilities,
    117 including none of them. However, the <code>BACKWARD_COMPATIBLE</code> capability
    118 must always be defined.</p>
    119 
    120 <p>The supported hardware level of the device, as well as the specific Camera
    121 API2 capabilities it supports, are available as the following feature flags to
    122 allow Google Play filtering of Camera API2 camera apps.</p>
    123 
    124 <ul>
    125   <li><code>android.hardware.camera.hardware_level.full</code>
    126   <li><code>android.hardware.camera.capability.raw</code>
    127   <li><code>android.hardware.camera.capability.manual_sensor</code>
    128   <li><code>android.hardware.camera.capability.manual_post_processing</code>
    129 </ul>
    130 
    131 <h2 id=cts_requirements>CTS requirements</h2>
    132 
    133 <p>Devices running Android 5.0 and later must pass the Camera API1 CTS, Camera
    134 API2 CTS, and CTS Verifier camera tests.</p>
    135 
    136 <p>Devices that do not feature a Camera HAL3.2 implementation and are not
    137 capable of supporting the full Camera API2 interfaces must still pass the Camera
    138 API2 CTS tests. However, the device will be running in Camera API2
    139 <code>LEGACY</code> mode (in which the Camera API2 calls are conceptually mapped
    140 to Camera API1 calls) so any Camera API2 CTS tests related to features or
    141 capabilities beyond Camera API1 will be automatically skipped.</p>
    142 
    143 <p>On legacy devices, Camera API2 CTS tests that are not skipped use the
    144 existing public Camera API1 interfaces and capabilities with no new
    145 requirements. Bugs that are exposed (and which cause a Camera API2 CTS failure)
    146 are bugs already present in the devices existing Camera HAL, and thus would
    147 be found by existing Camera API1 apps. We do not expect many bugs of this nature
    148 (however, any such bugs must be fixed to pass the Camera API2 CTS tests).</p>
    149 
    150 <h2 id=hardening>Camera framework hardening</h2>
    151 
    152 <p>To harden media and camera framework security, Android 7.0 moves camera
    153 service out of mediaserver. Vendors may need to make changes in the camera HAL
    154 depending on the API and HAL versions in use. The following sections detail
    155 architectural changes in AP1 and AP2 for HAL1 and HAL3, as well as general
    156 requirements.</p>
    157 
    158 <h3 id=hardening_api1>Architectural changes for API1</h3>
    159 <p>API1 video recording may assume camera and video encoder live in the same
    160 process. When using API1 on:</p>
    161 
    162 <ul>
    163 <li>HAL3, where camera service uses BufferQueue to pass buffers between
    164 processes, <strong>no vendor update</strong> is necessary.
    165 <p><img src="images/ape_camera_n_api1_hal3.png" alt="Android 7.0 camera and media
    166 stack in API1 on HAL3" id="figure1" /></p>
    167 <p class="img-caption"><strong>Figure 1.</strong>Android 7.0 camera and media
    168 stack in API1 on HAL3.</p>
    169 </li>
    170 <li>HAL1, which supports passing metadata in video buffers, <strong>vendors must
    171 update the HAL to use kMetadataBufferTypeNativeHandleSource</strong>.
    172 (<code>kMetadataBufferTypeCameraSource</code> is no longer supported in Android
    173 7.0.)
    174 <p><img src="images/ape_camera_n_api1_hal1.png" alt="Android 7.0 camera and media
    175 stack in API1 on HAL1" id="figure1" /></p>
    176 <p class="img-caption"><strong>Figure 2.</strong>Android 7.0 camera and media
    177 stack in API1 on HAL1.</p>
    178 </li>
    179 </ul>
    180 
    181 <h3 id=hardening_api2>Architectural changes for API2</h3>
    182 <p>For API2 on HAL1 or HAL3, BufferQueue passes buffers so those paths continue
    183 to work. The Android 7.0 architecture for API2 on:</p>
    184 
    185 <ul>
    186 <li>HAL1 is not affected by the cameraservice move, and <strong>no vendor
    187 update</strong> is necessary.</li>
    188 <li>HAL3 <em>is</em> affected, but <strong>no vendor update</strong> is
    189 necessary:
    190 <p><img src="images/ape_camera_n_api2_hal3.png" alt="Android 7.0 camera and
    191 media stack in API2 on HAL2" id="figure1" /></p>
    192 <p class="img-caption"><strong>Figure 3.</strong>Android 7.0 camera and media
    193 stack in API2 on HAL3.</p>
    194 </li>
    195 </ul>
    196 
    197 <h3 id=hardening_general>Additional requirements</h3>
    198 <p>The architectural changes made for hardening media and camera framework
    199 security include the following additional device requirements.</p>
    200 
    201 <ul>
    202 <li><strong>General</strong>. Devices require additional bandwidth due to IPC,
    203 which may affect time-sensitive camera use cases such as high-speed video
    204 recording. Vendors can measure actual impact by running
    205 <code>android.hardware.camera2.cts.PerformanceTest</code> and the Google Camera
    206 App for 120/240 FPS high speed video recording. Devices also require a small
    207 amount of additional RAM to create the new process.</li>
    208 <li><strong>Pass metadata in video buffers</strong>(<em>HAL1 only</em>). If HAL1
    209 stores metadata instead of real YUV frame data in video buffers, the HAL must
    210 use <code>kMetadataBufferTypeNativeHandleSource</code> as the metadata buffer
    211 type and pass <code>VideoNativeHandleMetadata</code> in video buffers.
    212 (<code>kMetadataBufferTypeCameraSource</code> is no longer supported on Android
    213 7.0.) With <code>VideoNativeHandleMetadata</code>, camera and media frameworks
    214 are able to pass the video buffers between processes by serializing and
    215 deserializing the native handles properly.</li>
    216 <li><strong>Buffer handle address does not always store the same buffer</strong>
    217 (<em>HAL3 only</em>). For each capture request, HAL3 gets addresses of buffer
    218 handles. HAL cannot use the addresses to identify buffers because the addresses
    219 may store another buffer handle after HAL returns the buffer. You must update
    220 the HAL to use buffer handles to identify the buffers. For example: HAL receives
    221 a buffer handle address A, which stores buffer handle A. After HAL returns
    222 buffer handle A, buffer handle address A may store buffer handle B next time the
    223 HAL receives it.</li>
    224 <li><strong>Update SELinux policies for cameraserver</strong>. If
    225 device-specific SELinux policies give mediaserver permissions to run the camera,
    226 you must update the SELinux policies to give cameraserver proper permissions. We
    227 do not encourage replicating the mediaserver's SELinux policies for cameraserver
    228 (as mediaserver and cameraserver generally require different resources in the
    229 system). Cameraserver should have only the permissions needed to perform camera
    230 functionalities and any unnecessary camera-related permissions in mediaserver
    231 should be removed.</p>
    232 
    233 <h3 id=hardening_validation>Validation</h3>
    234 <p>For all devices that include a camera and run Android 7.0, verify the
    235 implementation by running Android 7.0 CTS. Although Android 7.0 does not include
    236 new CTS tests that verify camera service changes, existing CTS tests will fail
    237 if you have not made the updates indicated above.</p>
    238 
    239 <h2 id="version-history">Camera HAL version history</h2>
    240 <p>For a list of tests available for evaluating the Android Camera HAL, see the
    241 <a href="{@docRoot}compatibility/cts/camera-hal.html">Camera HAL Testing
    242 Checklist</a>.</p>
    243 
    244 <h3 id="34">3.4</h3>
    245 
    246 <p>Minor additions to supported metadata and changes to data_space support:</p>
    247 
    248 <ul>
    249 <li>Add <code>ANDROID_SENSOR_OPAQUE_RAW_SIZE</code> static metadata as mandatory
    250 if <code>RAW_OPAQUE</code> format is supported.</li>
    251 <li>Add <code>ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE</code> static
    252 metadata as mandatory if any RAW format is supported.</li>
    253 <li>Switch <code>camera3_stream_t data_space</code> field to a more flexible
    254 definition, using the version 0 definition of dataspace encoding.</li>
    255 <li>General metadata additions which are available to use for HALv3.2 or newer:
    256   <ul>
    257   <li>
    258   <a href="https://developer.android.com/reference/android/hardware/camera2/CameraMetadata.html#INFO_SUPPORTED_HARDWARE_LEVEL_3"><code>ANDROID_INFO_SUPPORTED_HARDWARE_LEVEL_3</code>
    259   </a></li>
    260   <li><code>ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST</code></li>
    261   <li><code>ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE</code></li>
    262   <li><code>ANDROID_SENSOR_DYNAMIC_BLACK_LEVEL</code></li>
    263   <li><code>ANDROID_SENSOR_DYNAMIC_WHITE_LEVEL</code></li>
    264   <li><code>ANDROID_SENSOR_OPAQUE_RAW_SIZE</code></li>
    265   <li><code>ANDROID_SENSOR_OPTICAL_BLACK_REGIONS</code></li>
    266   </ul>
    267   <li>
    268 </ul>
    269 
    270 <h3 id="33">3.3</h3>
    271 
    272 <p>Minor revision of expanded-capability HAL:</p>
    273 
    274 <ul>
    275   <li>OPAQUE and YUV reprocessing API updates.</li>
    276   <li>Basic support for depth output buffers.</li>
    277   <li>Addition of <code>data_space</code> field to
    278   <code>camera3_stream_t</code>.</li>
    279   <li>Addition of rotation field to <code>camera3_stream_t</code>.</li>
    280   <li>Addition of camera3 stream configuration operation mode to
    281   <code>camera3_stream_configuration_t</code>.</li>
    282 </ul>
    283 
    284 <h3 id="32">3.2</h3>
    285 
    286 <p>Minor revision of expanded-capability HAL:</p>
    287 
    288 <ul>
    289 <li>Deprecates <code>get_metadata_vendor_tag_ops</code>. Use
    290 <code>get_vendor_tag_ops</code> in <code>camera_common.h</code> instead.</li>
    291 <li>Deprecates <code>register_stream_buffers</code>. All gralloc buffers
    292 provided by framework to HAL in <code>process_capture_request</code> may be new
    293 at any time.</li>
    294 <li>Add partial result support. <code>process_capture_result</code> may be
    295 called multiple times with a subset of the available results before the full
    296 result is available.</li>
    297 <li>Add manual template to <code>camera3_request_template</code>. Applications
    298 may use this template to control the capture settings directly.</li>
    299 <li>Rework the bidirectional and input stream specifications.</li>
    300 <li>Change the input buffer return path. The buffer is returned in
    301 <code>process_capture_result</code> instead of
    302 <code>process_capture_request</code>.</li>
    303 </ul>
    304 
    305 <h3 id="31">3.1</h3>
    306 
    307 <p>Minor revision of expanded-capability HAL:</p>
    308 
    309 <ul>
    310 <li><code>configure_streams</code> passes consumer usage flags to the HAL.</li>
    311 <li>flush call to drop all in-flight requests/buffers as fast as possible.</li>
    312 </ul>
    313 
    314 <h3 id="30">3.0</h3>
    315 
    316 <p>First revision of expanded-capability HAL:</p>
    317 
    318 <ul>
    319 <li>Major version change since the ABI is completely different. No change to the
    320 required hardware capabilities or operational model from 2.0.</li>
    321 <li>Reworked input request and stream queue interfaces: Framework calls into HAL
    322 with next request and stream buffers already dequeued. Sync framework support
    323 is included, necessary for efficient implementations.</li>
    324 <li>Moved triggers into requests, most notifications into results.</li>
    325 <li>Consolidated all callbacks into framework into one structure, and all setup
    326 methods into a single <code>initialize()</code> call.</li>
    327 <li>Made stream configuration into a single call to simplify stream management.
    328 Bidirectional streams replace STREAM_FROM_STREAM construct.</li>
    329 <li>Limited mode semantics for older/limited hardware devices.</li>
    330 </ul>
    331 
    332 <h3 id="20">2.0</h3>
    333 
    334 <p>Initial release of expanded-capability HAL (Android 4.2) [camera2.h]:</p>
    335 
    336 <ul>
    337 <li>Sufficient for implementing existing <code>android.hardware.Camera</code>
    338 API.</li>
    339 <li>Allows for ZSL queue in camera service layer.</li>
    340 <li>Not tested for any new features such as manual capture control, Bayer RAW
    341 capture, reprocessing of RAW data, etc.</li>
    342 </ul>
    343 
    344 <h3 id="10">1.0</strong></h3>
    345 
    346 <p>Initial Android camera HAL (Android 4.0) [camera.h]:</p>
    347 
    348 <ul>
    349 <li>Converted from C++ CameraHardwareInterface abstraction layer.</li>
    350 <li>Supports <code>android.hardware.Camera</code> API.</li>
    351 </ul>
    352 
    353 <h2 id=module_version>Camera module version history</h2>
    354 
    355 <p>This section contains module versioning information for the Camera hardware
    356 module, based on <code>camera_module_t.common.module_api_version</code>. The two
    357 most significant hex digits represent the major version, and the two least
    358 significant represent the minor version.</p>
    359 
    360 <h3 id="24">2_4</h3>
    361 
    362 <p>This camera module version adds the following API changes:</p>
    363 
    364 <ol>
    365  <li><em>Torch mode support</em>. The framework can turn on torch mode for any
    366  camera device that has a flash unit, without opening a camera device. The
    367  camera device has a higher priority accessing the flash unit than the camera
    368  module; opening a camera device will turn off the torch if it had been enabled
    369  through the module interface. When there are any resource conflicts, such as
    370  <code>open()</code> is called to open a camera device, the camera HAL module
    371  must notify the framework through the torch mode status callback that the torch
    372  mode has been turned off.</li>
    373 
    374  <li><em>External camera (e.g. USB hot-plug camera) support</em>. The API
    375  updates specify the camera static info is available only when camera is
    376  connected and ready to use for external hot-plug cameras. Calls to get static
    377  info will be invalid calls when camera status is not
    378  <code>CAMERA_DEVICE_STATUS_PRESENT</code>. The framework counts solely on
    379  device status change callbacks to manage the available external camera list.
    380  </li>
    381 
    382  <li><em>Camera arbitration hints</em>. Adds support for explicitly indicating
    383  the number of camera devices that can be simultaneously opened and used. To
    384  specify valid combinations of devices, the <code>resource_cost</code> and
    385  <code>conflicting_devices</code> fields should always be set in the
    386  <code>camera_info</code> structure returned by the <code>get_camera_info</code>
    387  call.</li>
    388 
    389  <li><em>Module initialization method</em>. Called by the camera service
    390  after the HAL module is loaded to allow for one-time initialization of the HAL.
    391  It is called before any other module methods are invoked.</li>
    392 </ol>
    393 
    394 <h3 id="23">2_3</h3>
    395 
    396 <p>This camera module version adds open legacy camera HAL device support.
    397  The framework can use it to open the camera device as lower device HAL version
    398  HAL device if the same device can support multiple device API versions.
    399  The standard hardware module open call (common.methods->open) continues
    400  to open the camera device with the latest supported version, which is
    401  also the version listed in <code>camera_info_t.device_version</code>.</p>
    402 
    403 <h3 id="22">2_2</h3>
    404 
    405 <p>This camera module version adds vendor tag support from the module, and
    406 deprecates the old <code>vendor_tag_query_ops</code> that were previously only
    407 accessible with a device open.</p>
    408 
    409 <h3 id="21">2_1</h3>
    410 
    411 <p>This camera module version adds support for asynchronous callbacks to the
    412 framework from the camera HAL module, which is used to notify the framework
    413 about changes to the camera module state. Modules that provide a valid
    414 <code>set_callbacks()</code> method must report at least this version number.</p>
    415 
    416 <h3 id="20">2_0</h3>
    417 
    418 <p>Camera modules that report this version number implement the second version
    419 of the camera module HAL interface. Camera devices openable through this
    420 module may support either version 1.0 or version 2.0 of the camera device
    421 HAL interface. The <code>device_version</code> field of camera_info is always
    422 valid; the <code>static_camera_characteristics</code> field of
    423 <code>camera_info</code> is valid if the <code>device_version</code> field is
    424 2.0 or higher.</p>
    425 
    426 <h3 id="10">1_0</h3>
    427 
    428 <p>Camera modules that report these version numbers implement the initial
    429 camera module HAL interface. All camera devices openable through this
    430 module support only version 1 of the camera device HAL. The
    431 <code>device_version</code> and <code>static_camera_characteristics</code>
    432 fields of <code>camera_info</code> are not valid. Only the
    433 <code>android.hardware.Camera</code> API can be supported by this module and its
    434 devices.</p>
    435