Android虚拟摄像头实战：从零构建多应用共享摄像头方案

1. Android虚拟摄像头开发背景与核心挑战第一次接触虚拟摄像头需求是在三年前的一个视频会议项目中。客户需要实现多个应用同时调用同一个物理摄像头这在原生Android系统中是被严格禁止的。当时为了解决这个问题我几乎翻遍了AOSP的CameraService代码最终发现问题的根源在于CameraClientManager的冲突检测机制。Android系统对摄像头访问的控制比想象中严格得多。在原生实现中即使两个应用打开不同ID的摄像头系统也会强制关闭低优先级的应用。这种设计源于硬件资源独占性的考虑——摄像头作为敏感硬件同时被多个进程访问可能导致数据混乱或隐私泄露。但现实业务场景中视频会议与直播推流同时进行、AR导航与行车记录仪并行工作等需求越来越普遍。技术难点主要集中在三个层面Framework层的进程隔离机制会强制关闭冲突的摄像头客户端HAL层的硬件抽象接口默认不支持多路并发访问应用层的SurfaceView绑定关系导致预览数据难以共享我在MTK6762平台上的实测数据显示原生系统下第二个调用Camera.open()的应用会被立即终止错误码为CAMERA_ERROR_EVICTED。这直接印证了ClientManager的冲突检测逻辑在实际发挥作用。2. 突破Framework层的限制2.1 修改ClientManager冲突检测逻辑问题的突破口在frameworks/av/services/camera/libcameraservice/utils/ClientManager.h。这个类通过模板方式管理所有活跃的摄像头客户端其核心限制逻辑在wouldEvictLocked函数中for (const auto i : mClients) { const KEY curKey i-getKey(); bool conflicting (curKey key || i-isConflicting(key)); if (conflicting curPriority priority) { evictList.push_back(client); return evictList; } }通过将conflicting变量强制设为false可以绕过相同摄像头ID的冲突检测。但这样修改后会出现新问题——当多个应用尝试操作同一物理摄像头时HAL层会报错Device already opened。2.2 动态重定向摄像头ID更优雅的解决方案是在CameraService中动态修改摄像头ID。在connectHelper函数中添加如下逻辑auto current mActiveClientManager.get(cameraId); if (current ! nullptr) { cameraId 2; // 重定向到虚拟摄像头 if(mActiveClientManager.get(cameraId) ! nullptr) { cameraId 3; // 备用虚拟摄像头 } }这种方案的优势在于无需修改应用层代码真实摄像头仅被第一个应用独占后续应用自动分配到虚拟摄像头实例兼容现有的权限控制系统实测中这种方案在小米10Android 11上可实现多达5个应用同时访问同一摄像头源平均帧率保持在24fps以上。3. 构建虚拟摄像头HAL模块3.1 实现HAL接口框架虚拟摄像头的核心是创建一个符合HAL3标准的伪硬件模块。关键结构体定义如下camera_module_t HAL_MODULE_INFO_SYM { .common { .tag HARDWARE_MODULE_TAG, .module_api_version CAMERA_MODULE_API_VERSION_2_4, .hal_api_version HARDWARE_HAL_API_VERSION, .id virtual_camera, .name Virtual Camera HAL, .author Your Company, .methods moduleMethods }, .get_number_of_cameras getNumberOfCameras, .get_camera_info getCameraInfo, .set_callbacks setCallbacks };其中moduleMethods需要实现标准的open/close操作static struct hw_module_methods_t moduleMethods { .open openDevice }; static int openDevice(const hw_module_t* module, const char* id, hw_device_t** device) { int cameraId atoi(id); return gVirtualCameras[cameraId]-open(device); }3.2 数据共享机制设计虚拟摄像头与物理摄像头的数据桥梁采用共享内存实现。在MTK平台上的具体实现路径数据采集端修改DisplayClient.BufOps.cppvoid handleReturnBuffers(ImgBuf* pStreamImgBuf) { uint8_t* srcBuf (uint8_t*)pStreamImgBuf-getVirAddr(); memcpy(shm_ptr, srcBuf, buf_size); // 写入共享内存 }数据消费端在虚拟摄像头的processCaptureRequest中int processCaptureRequest(camera3_capture_request_t* request) { memcpy(dstBuf, shm_ptr, buf_size); // 从共享内存读取 camera3_capture_result_t result { .frame_number request-frame_number, .result NULL, .num_output_buffers 1, .output_buffers outBuffer }; mCallbackOps-process_capture_result(mCallbackOps, result); }性能优化要点使用双缓冲机制避免读写冲突采用POSIX共享内存ashmem而非普通malloc设置合理的FENCE信号量同步4. 数据格式转换与性能优化4.1 YUV到RGB的转换处理Android摄像头原始数据通常是YUV格式如NV21/YV12而Surface显示需要RGB数据。转换过程需要两步YV12转I420调整UV分量顺序void YV12ToI420(uint8_t* YV12, uint8_t* I420, int width, int height) { memcpy(I420, YV12, width*height); // Y分量 memcpy(I420 width*height, YV12 width*height width*height/4, width*height/4); // V→U memcpy(I420 width*height width*height/4, YV12 width*height, width*height/4); // U→V }I420转ARGB使用libyuv优化#include libyuv.h void ConvertToARGB(uint8_t* I420, uint8_t* ARGB, int width, int height) { I420ToARGB(I420, width, I420 width*height, width/2, I420 width*height*5/4, width/2, ARGB, width*4, width, height); }4.2 帧率控制策略多应用共享时容易出现帧率不稳的问题。我们采用自适应帧率调节算法监测共享内存的更新频率动态调整虚拟摄像头的MAX_FPS参数在constructDefaultRequestSettings中返回合适的帧率配置const camera_metadata_t* constructDefaultRequestSettings(int type) { CameraMetadata metadata; uint8_t fpsRange[] {15, 30}; // 动态调整此值 metadata.update(ANDROID_CONTROL_AE_TARGET_FPS_RANGE, fpsRange, 2); return metadata.release(); }实测数据显示在华为P40上采用该方案后多应用共享时的帧率波动从±8fps降低到±2fps。5. 生命周期管理与异常处理5.1 引用计数机制为避免主应用退出导致虚拟摄像头失效需要实现跨进程的引用计数物理摄像头引用计数属性方式实现// 打开时 property_set(persist.camera.phy.ref, 1); // 关闭时 if(property_get_int32(persist.camera.virt.ref, 0) 0) { realClose(); }虚拟摄像头引用计数void CameraClient::disconnect() { int virtRef property_get_int32(persist.camera.virt.ref, 0); property_set(persist.camera.virt.ref, std::to_string(virtRef - 1).c_str()); if(virtRef 1 property_get_int32(persist.camera.phy.ref, 0) -1) { realClosePhysicalCamera(); } }5.2 Surface异常处理当主应用移除Surface时需要创建替代Surface维持数据流void createFallbackSurface() { spIGraphicBufferProducer producer; spIGraphicBufferConsumer consumer; BufferQueue::createBufferQueue(producer, consumer); spSurface surface new Surface(producer); mHardware-setPreviewWindow(surface); }这个技巧在OPPO Find X3上测试时成功解决了后台应用被回收导致的预览中断问题。6. 平台适配经验与性能数据6.1 主流平台适配要点平台HAL版本数据获取位置注意事项高通HAL3mm-camera-interface需要绕过Secure Camera检查MTKHAL1DisplayClient.BufOps.cpp注意3A锁问题海思HAL3CameraSource.cpp需要处理智能ISP分流展锐HAL2CameraHardwareInterface.cpp注意YUV stride对齐要求6.2 性能对比数据测试环境小米12骁龙8 Gen11080P分辨率应用数量原生系统帧率虚拟摄像头方案帧率CPU占用增量130fps30fps0%2不支持28fps12%3不支持25fps18%4不支持20fps25%这些数据表明虚拟摄像头方案在保证功能性的同时性能损耗在可接受范围内。实际开发中还需要针对不同厂商的HAL实现进行特定优化比如高通的Titan ISP和MTK的PDAF处理都有特殊的缓冲区管理机制。