Android Camera API2中采用CameraMetadata用于从APP到HAL的参数交互
2016-07-13 11:23
621 查看
前沿:
在全新的Camera API2架构下,常常会有人疑问再也看不到熟悉的SetParameter/Paramters等相关的身影,取而代之的是一种全新的CameraMetadata结构的出现,他不仅很早就出现在Camera API1/API2结构下的Camera2Device、Camera3Device中用于和HAL3的数据交互,而现在在API2的驱使下都取代了Parameter,实现了Java到native到hal3的参数传递。那么现在假如需要在APP中设置某一项控制参数,对于Camera
API2而言,涉及到对Sensor相关参数的set/control时又需要做哪些工作呢?
1. camera_metadata类整体布局结构
主要涉及到的源文件包括camera_metadata_tags.h,camera_metadata_tag_info.c,CameraMetadata.cpp,camera_metadata.c。对于每个Metadata数据,其通过不同业务控制需求,将整个camera工作需要的参数划分成多个不同的Section,其中在camera_metadata_tag_info.c表定义了所有Camera需要使用到的Section段的Name:
?
对于每个Section端而言,其都占据一个索引区域section_bounds,比如ANDROID_CONTROL Section他所代表的control区域是从ANDROID_CONTROL_START到ANDROID_CONTROL_END之间,且每个Section所拥有的Index范围理论最大可到(1 << 16)大小,完全可以满足统一Section下不同的控制参数的维护。
以ANDROID_CONTROL为列,他的Section index = 1,即对应的section index区间可到(1<<16,2<<16),但一般以实际section中维护的tag的数量来结束,即ANDROID_CONTROL_END决定最终的section index区间。对于每一个section,其下具备不同数量的tag,这个tag是一个指定section下的index值,通过该值来维护一个tag所在的数据区域,此外每个tag都有相应的string name,在camera_metadata_tag_info.c通过struct
tag_info_t来维护一个tag的相关属性:
?
其中tag_name为对应section下不同tag的name值 ,tag_type指定了这个tag所维护的数据类型,包括如下:
?
对每一个section所拥有的tag_info信息,通过全局结构体tag_info_t *tag_info[ANDROID_SECTION_COUNT] 来定义。
下图是对整个Camera Metadata对不同section以及相应section下不同tag的布局图,下图以最常见的android.control Section为例进行了描述:
![](https://oscdn.geek-share.com/Uploads/Images/Content/202010/16/454ac868e858147296b0bc073734670f)
2. CameraMetadata通过camera_metadata来维护数据信息
假设现在存在一个CameraMetadata对象,那么他是如何将一个tag标记的参数维护起来的呢?
?
?
一个CameraMetadata数据内存块中组成的最小基本单元是struct camera_metadata_buffer_entry,总的entry数目等信息需要struct camera_metadata_t来维护:
?
对于每一个entry主要记录他的所代表的TAG,以及这个TAG的需要存储的数据类型,此外还需要记录这个entry是否是需要一个union offset来表示他当前数据量过大时的数据存储位置,
?
![](https://oscdn.geek-share.com/Uploads/Images/Content/202010/16/75bf38b1d2b22e305ec4bd1581d2b0c4)
3. update更新并建立参数
CameraMetadata支持不同类型的数据更新或者保存到camera_metadata_t中tag所在的entry当中去,以一个更新单字节的数据为例,data_count指定了数据的个数,而tag指定了要更新的entry。
?
首先是通过checkType,主要是通过tag找到get_camera_metadata_tag_type其所应当支持的tag_type(因为具体的TAG是已经通过camera_metadata_tag_info.c源文件中的tag_info这个表指定了其应该具备的tag_type),比较两者是否一致,一致后才允许后续的操作,如这里需要TYPE_BYTE一致。
updataImpl函数主要是讲所有要写入的数据进行update操作。
?
主要分为以下几个过程:
a.通过tag_type存储的数据类型,由calculate_camera_metadata_entry_data_size计算要写入的entry中的数据量。
b. resizeIfNeeded通过已有entry的数量等,增加entry_capacity,或者重建整个camera_metadata_t,为后续增加数据创建内存空间基础。
c. 通过find_camera_metadata_entry获取一个entry的入口camera_metadata_entry_t,如果存在这个tag对应的entry,则将camera_metadata_buffer_entry_t的属性信息转为camera_metadata_entry_t。
?
d .add_camera_metadata_entry完成全新的entry更新与写入,即这个TAG目前不存在于这个camera_metadata_t中;update_camera_metadata_entry则是直接完成数据的更新。
3. Java层中CameraMetadata.java和CameraMetadataNative.java
下面以API2中java层中设置AF的工作模式为例,来说明这个参数设置的过程:
?
其中CONTROL_AF_MODE定义在CaptureRequest,java中如下以一个Key的形式存在:
?
?
在CameraMetadataNative.java中Key的构造
?
其中CONTROL_AF_MODE_CONTINUOUS_PICTURE定义在CameraMetadata.java中
?
逐一定位set的入口:
a. mPreviewBuilder是CaptureRequest.java的build类,其会构建一个CaptureRequest
?
?
mSetting建立的是一个CameraMetadataNative对象,主要用于和Native层进行接口交互,构造如下
?
b. CaptureRequest.Build.set()
?
?
考虑到CaptureRequest extend CameraMetadata,则CaptureRequest.java中getNativeKey
?
mKey即为之前构造的CameraMetadataNative.Key.
?
?
首先来看key.getTag()函数的实现,他是将这个key交由Native层后转为一个真正的在Java层中的tag值:
?
?
是将Java层的String交由Native来转为一个Java层的tag值。
再来看writeValues的实现,同样调用的是一个native接口,很好的阐明了CameraMetadataNative的意思:
?
相关native层的实现在下一小节说明。
4. Native层的CameraMetadata结构完成camera参数的传递
在描述万了CameraMetadata数据的相关操作之后,可明确的一点是SECTION下的TAG是操作他的核心所在。
这里先说明一个在API1 Camera2Client 参数传递的过程,他采用的逻辑是还是在Java层预留了setParameters接口,只是当Parameter在设置时比起CameraClient而言,他是将这个Parameter根据不同的TAG形式直接绑定到CameraMetadata mPreviewRequest/mRecordRequest/mCaptureRequest中,这些数据会由Capture_Request转为camera3_capture_request中的camera_metadata_t
settings完成参数从Java到native到HAL3的传递。
但是在Camera API2下,不再需要那么复杂的转换过程,在Java层中直接对参数进行设置并将其封装到Capture_Request即可,即参数控制由Java层来完成。这也体现了API2中Request和Result在APP中就大量存在的原因。对此为了和Framework Native层相关TAG数据的统一,在Java层中大量出现的参数设置是通过Section Tag的name来交由Native完成转换生成在Java层的TAG。
对于第三小节中提到的native层的实现,其对应的实现函数位于android_hardware_camera2_CameraMetadata.c中,如CameraMetadata_getTagFromKey是实现将一个Java层的string转为一个tag的值,他的主要原理如下:根据传入的key string值本质是由一个字符串组成的如上文中提到的android.control.mode。对比最初不同的Section name就可以发现前面两个x.y的字符串就是代表是Section name.而后面mode即是在该section下的tag数值,所以通过对这个string的分析可知,就可以定位他的section以及tag值。这样返回到Java层的就是key相应的tag值了。
如果要写数据,那么在native同样需要一个CameraMetadata对象,这里是在Java构造CameraMetadataNative时实现的,调用的native接口是nativeAllocate():
?
最终可以明确的是CameraMetadata相关的参数是被Java层来set/get,但本质是在native层进行了实现,后续如果相关控制参数是被打包到CaptureRequest中时传入到native时即操作的还是native中的CameraMetadata。
在全新的Camera API2架构下,常常会有人疑问再也看不到熟悉的SetParameter/Paramters等相关的身影,取而代之的是一种全新的CameraMetadata结构的出现,他不仅很早就出现在Camera API1/API2结构下的Camera2Device、Camera3Device中用于和HAL3的数据交互,而现在在API2的驱使下都取代了Parameter,实现了Java到native到hal3的参数传递。那么现在假如需要在APP中设置某一项控制参数,对于Camera
API2而言,涉及到对Sensor相关参数的set/control时又需要做哪些工作呢?
1. camera_metadata类整体布局结构
主要涉及到的源文件包括camera_metadata_tags.h,camera_metadata_tag_info.c,CameraMetadata.cpp,camera_metadata.c。对于每个Metadata数据,其通过不同业务控制需求,将整个camera工作需要的参数划分成多个不同的Section,其中在camera_metadata_tag_info.c表定义了所有Camera需要使用到的Section段的Name:
?
以ANDROID_CONTROL为列,他的Section index = 1,即对应的section index区间可到(1<<16,2<<16),但一般以实际section中维护的tag的数量来结束,即ANDROID_CONTROL_END决定最终的section index区间。对于每一个section,其下具备不同数量的tag,这个tag是一个指定section下的index值,通过该值来维护一个tag所在的数据区域,此外每个tag都有相应的string name,在camera_metadata_tag_info.c通过struct
tag_info_t来维护一个tag的相关属性:
?
?
下图是对整个Camera Metadata对不同section以及相应section下不同tag的布局图,下图以最常见的android.control Section为例进行了描述:
2. CameraMetadata通过camera_metadata来维护数据信息
假设现在存在一个CameraMetadata对象,那么他是如何将一个tag标记的参数维护起来的呢?
?
?
?
3. update更新并建立参数
CameraMetadata支持不同类型的数据更新或者保存到camera_metadata_t中tag所在的entry当中去,以一个更新单字节的数据为例,data_count指定了数据的个数,而tag指定了要更新的entry。
?
updataImpl函数主要是讲所有要写入的数据进行update操作。
?
a.通过tag_type存储的数据类型,由calculate_camera_metadata_entry_data_size计算要写入的entry中的数据量。
b. resizeIfNeeded通过已有entry的数量等,增加entry_capacity,或者重建整个camera_metadata_t,为后续增加数据创建内存空间基础。
c. 通过find_camera_metadata_entry获取一个entry的入口camera_metadata_entry_t,如果存在这个tag对应的entry,则将camera_metadata_buffer_entry_t的属性信息转为camera_metadata_entry_t。
?
3. Java层中CameraMetadata.java和CameraMetadataNative.java
下面以API2中java层中设置AF的工作模式为例,来说明这个参数设置的过程:
?
?
?
?
a. mPreviewBuilder是CaptureRequest.java的build类,其会构建一个CaptureRequest
?
?
?
?
?
?
再来看writeValues的实现,同样调用的是一个native接口,很好的阐明了CameraMetadataNative的意思:
?
4. Native层的CameraMetadata结构完成camera参数的传递
在描述万了CameraMetadata数据的相关操作之后,可明确的一点是SECTION下的TAG是操作他的核心所在。
这里先说明一个在API1 Camera2Client 参数传递的过程,他采用的逻辑是还是在Java层预留了setParameters接口,只是当Parameter在设置时比起CameraClient而言,他是将这个Parameter根据不同的TAG形式直接绑定到CameraMetadata mPreviewRequest/mRecordRequest/mCaptureRequest中,这些数据会由Capture_Request转为camera3_capture_request中的camera_metadata_t
settings完成参数从Java到native到HAL3的传递。
但是在Camera API2下,不再需要那么复杂的转换过程,在Java层中直接对参数进行设置并将其封装到Capture_Request即可,即参数控制由Java层来完成。这也体现了API2中Request和Result在APP中就大量存在的原因。对此为了和Framework Native层相关TAG数据的统一,在Java层中大量出现的参数设置是通过Section Tag的name来交由Native完成转换生成在Java层的TAG。
对于第三小节中提到的native层的实现,其对应的实现函数位于android_hardware_camera2_CameraMetadata.c中,如CameraMetadata_getTagFromKey是实现将一个Java层的string转为一个tag的值,他的主要原理如下:根据传入的key string值本质是由一个字符串组成的如上文中提到的android.control.mode。对比最初不同的Section name就可以发现前面两个x.y的字符串就是代表是Section name.而后面mode即是在该section下的tag数值,所以通过对这个string的分析可知,就可以定位他的section以及tag值。这样返回到Java层的就是key相应的tag值了。
如果要写数据,那么在native同样需要一个CameraMetadata对象,这里是在Java构造CameraMetadataNative时实现的,调用的native接口是nativeAllocate():
?
相关文章推荐
- Android 中this、 getApplicationContext()、getApplication()之间的区别
- android camera接口介绍
- android camera HAL v3.0详细介绍(二)
- android camera HAL v3.0详细介绍(一)
- android camera系统3A模式及其状态转换(二)
- Android-BroadcastReceiver
- android camera系统3A模式及其状态转换(一)
- Swift - 属性观察者(willSet与didSet)
- android camera HAL v3.0中元数据及其控制
- android camera接口介绍
- 使用WKWebView替换UIWebView
- (转)linphone-android-客户端APP-工程解读
- iOS 多语言 浅析
- Android Camera系统
- Android Camera Framework Stream(一)
- android:clipChildren属性的分析——是否剪裁子View
- Android-ContentProvider
- 判断是否为微信浏览器的JS代码
- Android封装好的类似于RadioGroup的底部导航或顶部导航、仿微信底部导航
- Android camera系统开发之IPC (四)