Android Camera驱动分析
2012-04-03 14:11
579 查看
先上图:
![](http://www.kandroid.org/online-pdk/guide/images/camera_video2.gif)
由上图可以看出, Android的Camera驱动流程经过了一长串的系统调用后才进入内核,网上对于HAL的分析总是停留在CameraService,往下的流程总是不了了之。真正操作 内核提供给用户空间设备节点的HAL层代码一般都是平台相关的,可能也是基于这个原因网上对此部分的分析总是浅尝辄止。
都说 CameraHardwareInterface 完成一个 camera 的所有操作,但其实它并不是直接跟内核打交道的类。纵观整个CameraHardwareInterface,所有的方法都是基于一个类型为 camera_device_t 的变量*mDevice来实现的,例如 takePicture 方法:
status_t takePicture()
{
LOGV("%s(%s)", __FUNCTION__, mName.string());
if (mDevice->ops->take_picture)
return mDevice->ops->take_picture(mDevice);
return INVALID_OPERATION;
}
camera_device_t 在 hardware\libhardware\include\hardware\camera.h中定义,该结构体定义如下:
typedef struct camera_device {
hw_device_t common;
camera_device_ops_t *ops;
void *priv;
} camera_device_t
其中hw_device_t common 参数就是android应用空间中位于最低层 -- HAL层的信息。
稍微向上看一下,回到CameraSevice.cpp 的类定义中,有一个connect方法,它是通过以下方式获取HAL的模块的:
hw_get_module(CAMERA_HARDWARE_MODULE_ID, (const hw_module_t **)&mModule)
CAMERA_HARDWARE_MODULE_ID 就是我平台上camera的HAL ID。
作为1名设备驱动调试开发者,必须弄清楚内核空间提供给用户空间的设备节点(当然可以通过其他方式)是在哪里操作的。通过上面的分析,我们知道一个android camera 的应用程序的操作最终到了HAL层实现,那么我们顺理成章的就应该进入camera的HAL层代码一看究竟。
在我所使用的平台中,我的SOC的camera的HAL层是处于以下位置:
hardware\我的平台\common\libcamera\
其中一个xxxCameraHal_Module.cpp文件实现了我们上面分析的的hw_device_t common(经过了封装)和所有的open,ioctl,mmap,close, open等等操作,加载模块库所使用的识别IDCAMERA_HARDWARE_MODULE_ID 和其他信息都在此文件定义。
在我的平台中,SOC厂家还进行了一次抽象,真正操作设备节点的是在一个xxx_V4l2_Camera.cpp的文件中。在该文件中,对设备节点的所有操作都一览无遗。到此,android到linux的所有的camera操作才算真正的露出水面。
PS: 以上代码分析基于android4.0 和telechip平台,并不具备通用性。
![](http://www.kandroid.org/online-pdk/guide/images/camera_video2.gif)
由上图可以看出, Android的Camera驱动流程经过了一长串的系统调用后才进入内核,网上对于HAL的分析总是停留在CameraService,往下的流程总是不了了之。真正操作 内核提供给用户空间设备节点的HAL层代码一般都是平台相关的,可能也是基于这个原因网上对此部分的分析总是浅尝辄止。
都说 CameraHardwareInterface 完成一个 camera 的所有操作,但其实它并不是直接跟内核打交道的类。纵观整个CameraHardwareInterface,所有的方法都是基于一个类型为 camera_device_t 的变量*mDevice来实现的,例如 takePicture 方法:
status_t takePicture()
{
LOGV("%s(%s)", __FUNCTION__, mName.string());
if (mDevice->ops->take_picture)
return mDevice->ops->take_picture(mDevice);
return INVALID_OPERATION;
}
camera_device_t 在 hardware\libhardware\include\hardware\camera.h中定义,该结构体定义如下:
typedef struct camera_device {
hw_device_t common;
camera_device_ops_t *ops;
void *priv;
} camera_device_t
其中hw_device_t common 参数就是android应用空间中位于最低层 -- HAL层的信息。
稍微向上看一下,回到CameraSevice.cpp 的类定义中,有一个connect方法,它是通过以下方式获取HAL的模块的:
hw_get_module(CAMERA_HARDWARE_MODULE_ID, (const hw_module_t **)&mModule)
CAMERA_HARDWARE_MODULE_ID 就是我平台上camera的HAL ID。
作为1名设备驱动调试开发者,必须弄清楚内核空间提供给用户空间的设备节点(当然可以通过其他方式)是在哪里操作的。通过上面的分析,我们知道一个android camera 的应用程序的操作最终到了HAL层实现,那么我们顺理成章的就应该进入camera的HAL层代码一看究竟。
在我所使用的平台中,我的SOC的camera的HAL层是处于以下位置:
hardware\我的平台\common\libcamera\
其中一个xxxCameraHal_Module.cpp文件实现了我们上面分析的的hw_device_t common(经过了封装)和所有的open,ioctl,mmap,close, open等等操作,加载模块库所使用的识别IDCAMERA_HARDWARE_MODULE_ID 和其他信息都在此文件定义。
在我的平台中,SOC厂家还进行了一次抽象,真正操作设备节点的是在一个xxx_V4l2_Camera.cpp的文件中。在该文件中,对设备节点的所有操作都一览无遗。到此,android到linux的所有的camera操作才算真正的露出水面。
PS: 以上代码分析基于android4.0 和telechip平台,并不具备通用性。
相关文章推荐
- S5PV210 camera 驱动分析(android)
- S5PV210 camera 驱动分析(android)
- S5PV210 camera 驱动分析(android)
- Android 4.0 Camera架构分析之Camera初始化
- android从应用到驱动之—camera(1)---程序调用流程
- Android wifi驱动--偏下层的分析
- android系统中alarm驱动框架分析
- android电池(四):电池 电量计(MAX17040)驱动分析篇
- WinCE6.0 Camera驱动源码分析(二)
- android 电容屏(四):驱动调试之驱动程序分析篇 -- FocalTech
- 从驱动层分析android的Binder机制-android学习之旅(83)
- Android Camera 系统架构源码分析(5)---->Camera数据Buf的传递方式及相关类
- 高通camera驱动分析
- Android休眠唤醒驱动流程分析(四)
- Android5.1.1Camera 系统架构源码分析(2)---->Camera的startPreview和setPreviewCallback
- Android 4.0 Camera架构分析之Camera初始化
- Wince5.0 Camera 驱动分析
- Android S5PV210 fimc驱动分析 - fimc_capture.c
- android从应用到驱动之—camera(2)---cameraHAL的实现
- Android Camera OMXCameraAdapter.cpp初始化分析