Android camera transitions from camera HAL1 to camera HAL3

This article is the source of their own reading a bit summary, transfer Please specify the source thank you.

Welcome to communicate with you. qq:1037701636 Email:gzzaigcn2[email protected]

Software: System Source Android5.1

1. Historical progress of the camera module version number in Android system

/** * All module versions <= hardware_module_api_version (1, 0xFF) must be treated * as CAMERA_MODULE_API_VERSION_1_0 * * #define CAMERA_MODULE_API_VERSION_1_0 hardware_module_api_version (1, 0) #define Camera_module_api_version_2_0 Hardware_module_api_version (2, 0) #define Camera_module_api_version_2_1 hardware_module_api_version (2, 1) #define Camera_module_api_version_2_2 hardware_module_api_version (2, 2) #define Camera_module_api_version_2_3 HARDWARE_ Module_api_version (2, 3) #define Camera_module_api_version_current camera_module_api_version_2_3/** * all device Versions <= hardware_device_api_version (1, 0xFF) must be treated * as CAMERA_DEVICE_API_VERSION_1_0 */#define Camera_d Evice_api_version_1_0 hardware_device_api_version (1, 0) #define CAMERA_DEVICE_API_VERSION_2_0 HARDWARE_DEVICE_API_ VERSION (2, 0) #define Camera_device_api_version_2_1 hardware_device_api_version (2, 1) #define Camera_device_api_ Version_3_0 hardware_device_api_version (3, 0) #define Camera_device_api_version_3_1 HARDWARE_device_api_version (3, 1) #define Camera_device_api_version_3_2 hardware_device_api_version (3, 2)//DEVICE VERSION 3.2 Is current, older HAL camera device versions was not//recommended for new devices. #define Camera_device_api_version_curre NT Camera_device_api_version_3_2

From the definition of the camera version above, Android divides the entire camera module into module and device two parts, which have control over the latter, which is directly the implementation of the camera HAL interface represented.

The difference between the module APIs is that the Set_callbacks interface is added after 2.1 for the HAL to detect the current module's working state, and the lower version of the module does not need to be implemented.

In addition, the module API version number is higher than 2.2 can support the get_vendor_tag_ops,framework call after the class to obtain the vendor's own extended definition of the tag ops, easy to operate the manufacturer's own privately defined camera required metadata information, Similarly, the lower version of the module does not need to implement the interface.

Additionally, the Open_legacy interface is added for version 2.3 of the module API:

    Int (*open_legacy) (const struct hw_module_t* module, const char* ID,            uint32_t halversion, struct hw_device_t** device );

He describes a DEVICE version that can be based on his or her choice, such as a camera HAL that supports and implements CAMERA_DEVICE_API_VERSION_1_0 and camera_device_api_version_3_. 22 versions of the HAL interface implementation, only the module API is defined by the version 2.3, in the framework can be used to open_legacy () to specify the hal_version, to obtain different versions of the HAL The implementation interface of the device is hw_device_t. But for now, Android provides this interface, but the framework layer does not give a direct call, in addition to the visible Hal module api2.3 version, also will not implement the interface. Indicates that the open that hw_module_t belongs to is still the only path and method to gain control of camera device, and perhaps implementing a version of the interface for a camera device is sufficient and cumbersome.

2 Camera Client

For Cameraservice related content, refer to the blog post Android4.2.2 cameraservice service launch and application-side camera initialization records to comb the entire camera.so module loading and processing process. The camera on each application side will exist as a camera client in connect to Cameraservice, which inherits and implements an inner class of cameraservice::client, Interact with the application side through an anonymous binder service. When the Camerservice is started and established, a camera.xxx.so module is automatically loaded to extract the handle associated with the module.

Whenever connect, Cameraservice executes a getdeviceversion function:

int cameraservice::getdeviceversion (int cameraid, int* facing) {    struct camera_info info;    if (Mmodule->get_camera_info (Cameraid, &info)! = OK) {        return-1;    }    int deviceversion;    if (mmodule->common.module_api_version >= camera_module_api_version_2_0) {        deviceversion = Info.device_ version;    } else {        deviceversion = camera_device_api_version_1_0;    }    if (facing) {        *facing = info.facing;    }    return deviceversion;}

That is, for those versions of Module_api_version less than 2.0, the so-called 1.0 version, the other module corresponding to the device version number, the HAL in its sole discretion, the decision to obtain the HAL supported by Get_camera_info Camera_ Information about info, including device_version. The 1.0 version of module directly defaults to the Device_verison 1.0 version.

     Case CAMERA_DEVICE_API_VERSION_1_0:            client = new Cameraclient (this, cameraclient,                    Clientpackagename, Cameraid,                    facing, Callingpid, Clientuid, Getpid (), legacymode);            break;          Case CAMERA_DEVICE_API_VERSION_2_0: Case          camera_device_api_version_2_1: Case          camera_device_api_version_3_ 0: Case          camera_device_api_version_3_1: Case          camera_device_api_version_3_2:            client = new Camera2client ( This, cameraclient,                    clientpackagename, Cameraid,                    facing, Callingpid, Clientuid, Getpid (), legacymode);// Cameraservice terminal new Camera2client break            ;

The above code logic shows that the upgrade of the camera client is determined by the underlying device API version. It is clear that 1.0 of the device APIs currently exist in the form of cameraclient, while more than 2.0 of the versions are present in the form of camera2client.

For different versions of the camera module DEVICE_API, the difference is essentially the interface that HAL needs to implement, respectively, by the following three versions of the device interface:

typedef struct CAMERA_DEVICE {    /**     * camera_device.common.version must be in the range     * HARDWARE_DEVICE_API _version (0,0)-(1,FF). CAMERA_DEVICE_API_VERSION_1_0 is     * recommended.     */    hw_device_t common;    camera_device_ops_t *ops;    void *priv;} camera_device_t;

corresponding to the 1.0 DEVICE_API, the current low version of the Android system in this way to achieve more.

typedef struct CAMERA2_DEVICE {    /**     * common.version must equal camera_device_api_version_2_0 to identify     * This device as implementing version 2.0 of the camera device HAL.     */    hw_device_t common;    camera2_device_ops_t *ops;    void *priv;} camera2_device_t;

The 2.0 version of OPS currently has fewer mainstream IC vendors to implement.

typedef struct CAMERA3_DEVICE {    /**     * common.version must equal camera_device_api_version_3_0 to identify this< c3/>* Device as implementing version 3.0 of the camera device HAL.     * *     Performance requirements:     *     * Camera open (Common.module->common.methods->open) should return in 200MS, and must return     * in 500ms.     * Camera Close (common.close) should return in 200ms, and must return in 500ms.     * * */    hw_device_t Common;    camera3_device_ops_t *ops;    void *priv;} camera3_device_t;

For 3.0, that is the so-called HAL3.0 is reflected here, now visible only Qualcomm, Samsung and so on the interface form has been implemented.

Essentially, three different versions are all upgraded in a holistic manner, and the focus is on HAL to implement the interface in accordance with the camerax_device_ops defined by Google in the framework layer, and the implementation of the interface is analyzed when analyzing the high-pass HAL Architecture.

3 Camera Device

For three different versions of the HAL layer interface, the process implemented in the camera framework is slightly different and can be divided into Device1, Device2, Device3.

For the 1.0 version of the device API, the cameraclient is created with Camerahardwareinterface (which can be considered a camera Device1) to maintain control of the team's entire camera device in the HAL layer, i.e. Camera_device_t is called by Camerahardwareinterface.

When you create a camera2client, the corresponding camera device is created through Cameradevicefactory::createdevice for the device API of version 2.0 and above.

sp<cameradevicebase> cameradevicefactory::createdevice (int cameraid) {Sp<cameraservice> svc =    Sservice.promote ();        if (svc = = 0) {aloge ("%s:no service registered", __function__);    return NULL;    } int deviceversion = Svc->getdeviceversion (Cameraid,/*facing*/null);    Sp<cameradevicebase> device;            Switch (deviceversion) {case Camera_device_api_version_2_0:case camera_device_api_version_2_1:            device = new Camera2device (cameraid);        Break            Case Camera_device_api_version_3_0:case Camera_device_api_version_3_1:case Camera_device_api_version_3_2:            device = new Camera3device (cameraid);        Break Default:aloge ("%s:camera%d:unknown HAL Device version%d", __function__, Cameraid, Devicev            Ersion);            device = NULL;    Break                      } alogv_if (Device! = 0, "Created a new camera device for version%d",    Deviceversion); return device;}

You can see that for camera2client, the version of Device API2.0, 2.1 is controlled by Camera2device for the underlying device, For more than 3.0 of the version through Camera3device to achieve, the former can be said to be called the camera HAL2.0 related camera2_device_t interface, the latter is called the camera HAL3.0 related Camera3_device_ The interface of T, of course, is that the internal implementation of the two different forms, the 3.0 version of the processing is more complicated.one of the camera Device API2.0 version from Android4.2 began to release, and API3 More is the former upgrade and replacement only in the 4.4.2 version of the CAs see.

4. Summary

Camera continuous transition, but also is the Android system source code, a large part of the change, although the framework layer core Cameraservice, camera and other implementation of the logic has not changed much, but the interaction with the underlying HAL has a qualitative variation. At present, the mainstream IC manufacturers are in the direction of the camera HAL3.0 development, all necessary to the 3.0 realization of the principle and nature of exploration and learning.

Photos: Camera changes in the Android framework layer

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Android camera transitions from camera HAL1 to camera HAL3