308.CameraService 源码解读（二）：Client 创建与连接机制全链路详解

CameraService 源码解读（二）：Client 创建与连接机制全链路详解

关键词：
CameraService、connectDevice、CameraClient、Camera2Client、Camera3Device、ICameraDeviceUser、AIDL、Binder 连接、HAL session、图像请求通道

摘要：
本篇文章聚焦 Android Camera 系统中客户端连接流程的核心实现 —— CameraService 如何响应上层的相机连接请求并创建对应的 CameraClient 实例。基于 Android 14 最新 AOSP 源码，深入解析 connectDevice() 方法的调用链、权限检查、HAL 版本判断、Client 生命周期管理以及 Binder 会话结构的创建过程。同时结合实际工程中调试连接失败、Client 泄露、多实例冲突等常见问题，提供实用的源码路径与验证技巧，帮助读者系统掌握 Camera 框架下的客户端接入机制。

一、连接调用起点：ICameraService.connectDevice 的 AIDL 接口入口
二、权限验证与 UID 管控：安全模型下的多层连接限制机制
三、HAL 版本判断与 Client 类型选择：Camera1、Camera2、Camera3 分支策略
四、CameraClient 创建流程解析：构造器、状态同步与注册流程
五、Camera3Device 初始化与设备接口绑定：HAL session 启动全流程
六、ICameraDeviceUser Binder 对象封装：如何对接应用层控制接口
七、Client 生命周期与回收策略：连接断开、死亡监听与资源释放机制
八、实战排查技巧：连接失败、权限拒绝、死锁与 Session 初始化超时定位方法

一、连接调用起点：ICameraService.connectDevice 的 AIDL 接口入口

在 Android Camera 框架中，当应用调用 CameraManager.openCamera() 时，实际发起的是对 ICameraService 的跨进程调用，核心入口就是：

ICameraService.connectDevice(ICameraDeviceCallbacks callbacks, String cameraId, String opPackageName, int clientUid)

这个接口定义于 frameworks/av/camera/aidl/android/hardware/ICameraService.aidl，其 native 端由 CameraService 实现，承接上层所有的相机连接请求。

1.1 调用链总览（以 Camera2 为例）

从 App 发起连接到 Service 响应的完整调用链如下：

App (Java) 
  ↓
CameraManager.openCamera()
  ↓
ICameraService.connectDevice()    ← Binder 跨进程
  ↓
CameraService::connectDevice()
  ↓
CameraService::connectHelper()
  ↓
Camera2Client / Camera3Device 创建
  ↓
返回 ICameraDeviceUser Binder 接口供 App 使用

此流程建立了 Camera 应用与系统核心服务之间的 Binder 通道，成功后 App 即可通过 ICameraDeviceUser 进行 session 配置、帧请求、资源控制等操作。

1.2 接口参数解析

ICameraDeviceCallbacks callbacks：由 App 实现，用于接收帧完成、状态通知、错误回调等；
String cameraId：目标设备 ID，如 “0”（后摄）；
String opPackageName：调用者包名，用于权限校验、AppOps 分析；
int clientUid：调用方 UID，系统用于权限隔离、资源限制等。

这四个参数必须由上层 Java 层 CameraManager 准确传入，否则系统将拒绝连接请求。

1.3 实现入口：CameraService::connectDevice()

定义位置：

frameworks/av/services/camera/libcameraservice/CameraService.cpp

核心函数如下：

Status CameraService::connectDevice(
    const sp<ICameraDeviceCallbacks>& callbacks,
    const String16& cameraId,
    const String16& opPackageName,
    int clientUid,
    sp<ICameraDeviceUser>* outDevice) {

    return connectHelper(..., API_2, ...);
}

其中 API_2 表示使用 HAL3 架构（Camera2/CameraX 使用的方式），Camera1 会调用另一个入口。真正的连接与初始化逻辑被封装在 connectHelper() 中。

二、权限验证与 UID 管控：安全模型下的多层连接限制机制

为了保证系统安全性与用户隐私保护，CameraService 在处理连接请求之前必须执行一系列权限与身份校验。这些验证不仅来自 Android 权限系统（如 android.permission.CAMERA），还包括 AppOps 管理、安全策略、UID 白名单、系统状态监控等，确保只有合格应用才能建立 camera 会话。

2.1 核心权限校验点

在 CameraService::connectHelper() 中，系统依次执行以下权限校验：

if (!checkPermission(opPackageName, clientUid)) {
    return PERMISSION_DENIED;
}

该函数内部结合了多种机制：

SELinux 策略审查：判断调用进程是否有 camera domain 访问权限；
AppOps 权限核查：使用 AppOpsManager 查询调用方是否被禁止访问 CAMERA 功能；
PackageManager 权限验证：确认调用者是否声明并获取了 android.permission.CAMERA；
角色限制检查：部分设备可限制特定 UID（如非 system_app）访问特定 camera ID。

2.2 UID 资源隔离机制

CameraService 会对 UID 进行独立管理，避免以下问题：

同一 UID 多实例竞争：同一个 UID 多次打开同一个 Camera，可能会触发资源冲突或拒绝；
UID 泄漏识别：App 使用其他包名伪装身份；
UID 与 Binder Caller 不一致：系统强制检查传入 UID 与实际调用者是否一致（需 CAPTURE_SECURE 权限方可代开）。

校验实现如下：

int callingUid = IPCThreadState::self()->getCallingUid();
if (clientUid != USE_CALLING_UID && callingUid != clientUid) {
    return PERMISSION_DENIED;
}

系统允许 system 级服务为其他 UID 打开 camera，但一般应用需使用 USE_CALLING_UID 表示自身 UID。

2.3 活跃连接限制与并发控制

系统限制每个 UID 最多同时拥有一个活跃 camera client，通过：

mActiveClientManager->hasClientForUid(clientUid);

若已存在活跃连接，系统将拒绝新的连接请求或强制清除旧连接。

2.4 特权 UID 白名单

以下 UID 默认可访问所有 camera：

system_server（UID 1000）
cameraserver
shell
media

同时系统允许厂商通过配置文件或编译标志添加自定义白名单。

2.5 调试建议与验证命令

验证权限拒绝时的 logcat：

logcat -s CameraService PackageManager AppOps

示例输出：

CameraService: Permission check failed for package com.abc.app uid 10234

dumpsys 查看当前活跃 UID 状态：

dumpsys media.camera

输出：

Active clients:
  UID 10234 (com.abc.app)
  State: CONNECTED

通过上述机制，CameraService 在客户端连接前完成了权限、身份、状态的多重验证，有效防止了 camera 被恶意调用或非预期竞争，在企业设备管理、系统多用户、相机沙箱等场景中尤为重要。

三、HAL 版本判断与 Client 类型选择：Camera1、Camera2、Camera3 分支策略

在 CameraService 接收到上层连接请求（connectDevice）之后，系统需要根据目标 camera 的底层 HAL 类型（HAL1、HAL2、HAL3）判断使用哪种 Client 类型进行封装与管理。该策略确保系统能够根据设备兼容性选择合适的访问路径，实现对老旧设备与现代 ISP 架构的统一支持。

3.1 HAL 类型的判定机制

每个 camera 设备在初始化阶段（CameraProviderManager 加载时）都会记录其 HAL 版本信息，保存在 DeviceInfo 中。CameraService 在连接时会调用：

hardware::camera::common::V1_0::CameraDeviceStatus status =
    mCameraProviderManager->getDeviceVersion(cameraId, &version);

常见 HAL version 值示例：

HAL 类型	Version 值	描述说明
HAL1	CAMERA_DEVICE_API_VERSION_1_0	legacy 接口，仅支持固定流配置
HAL3	CAMERA_DEVICE_API_VERSION_3_2~3_7	modern ISP 架构，支持动态配置、metadata pipeline

如果 HAL 类型为 1.x，系统将分支到 CameraClient，否则使用 Camera2Client（HAL2 少见，通常直接跳到 HAL3）。

3.2 客户端类型选择逻辑

调用路径如下：

if (deviceVersion == CAMERA_DEVICE_API_VERSION_1_0) {
    client = new CameraClient(...);  // HAL1 legacy 路径
} else {
    client = new Camera2Client(...);  // HAL3 主路径
}

这两种 Client 均继承自 CameraService::BasicClient，但封装结构和控制方式完全不同：

CameraClient（HAL1）

使用旧版 ICamera AIDL 接口；
控制流通过 CameraHardwareInterface 完成；
预览、拍照逻辑硬编码；
无法支持可配置 Session、metadata、异步流控；
Android 10 之后基本废弃，仅保留极少数老设备支持。

Camera2Client（HAL3）

使用现代 ICameraDeviceUser 接口；
底层接入 Camera3Device；
支持 CaptureRequest、Session 重配置、异步帧流；
支持多 stream、动态控制、AI pipeline；
适用于所有主流设备（高通/MTK/海思等平台都基于 HAL3）。

3.3 特殊平台 HAL 混合实现

部分平台（如 MTK、Spreadtrum）为了兼容 legacy 应用，可能提供 HAL3 接口，但通过 metadata 标记支持“legacy-only”访问模式，此时系统仍强制分配 CameraClient，此逻辑见：

if (deviceInfo->isLegacyMode()) {
    client = new CameraClient(...);
}

开发过程中需根据实际平台 HAL 层实现判断是否存在此兼容策略，避免 Client 类型分配错误。

四、CameraClient 创建流程解析：构造器、状态同步与注册流程

在确定了使用哪种 Client 类型（如 Camera2Client）后，CameraService 会调用对应类的构造函数，完成对 HAL 设备、流状态、权限上下文等的封装，并完成注册、线程绑定、死亡监听等操作。Client 的创建与生命周期管理是整个 camera 框架的关键部分，关系到资源释放、安全性与异常恢复机制。

4.1 Camera2Client 构造器解析

构造函数路径：

frameworks/av/services/camera/libcameraservice/api2/Camera2Client.cpp

构造原型如下：

Camera2Client::Camera2Client(
    const sp<CameraService>& cameraService,
    const sp<ICameraDeviceCallbacks>& remoteCallback,
    const String16& packageName,
    const String8& cameraId,
    int api1CameraId,
    int cameraFacing,
    int clientPid,
    uid_t clientUid,
    int servicePid)

主要构造行为包括：

保存调用方 UID/PID，用于权限控制；
绑定 client 的回调 Binder（如 onCaptureStarted, onError）；
创建 Camera3Device 对象，用于接入 HAL；
初始化 Client 状态机，设置为 INITIALIZED；
构建 stream 配置、Metadata 初始模板等。

4.2 与 HAL 层绑定（Camera3Device）

构造阶段中，Camera2Client 会持有一个 Camera3Device 成员：

mDevice = new Camera3Device(cameraId);

随后在 initialize() 中进行 HAL session 的建立与设备能力读取：

status_t status = mDevice->initialize(mCameraProvider, mCameraDeviceCallback);

这一步将通过 AIDL 或 HIDL 向 HAL 层发送 open()、initialize() 请求，并完成 Metadata 初始化（如 AE 模式、分辨率支持、Frame duration）。

初始化失败将导致 client 连接失败并返回 ERROR 状态给 App。

4.3 客户端注册与同步

构造完成后，CameraService 会调用：

mActiveClientManager->add(client, clientUid);

将 client 加入 UID 下的 client 池中，同时构建死亡监听（Binder::linkToDeath()），确保 client 异常退出时资源能被系统正确释放。

此外，还将发起一次状态广播通知：

notifyStatusChange(STATUS_NOT_AVAILABLE, cameraId, clientPid, clientUid);

标记该 Camera 已被占用，Java 层会触发 onCameraUnavailable() 事件，用于控制 UI 状态刷新。

4.4 返回控制 Binder 接口

连接完成后，CameraService 返回 ICameraDeviceUser 接口句柄供 App 控制：

*outDevice = static_cast<sp<ICameraDeviceUser>>(client->getRemote());

App 后续的 createCaptureSession()、submitRequest()、close() 等所有控制操作都将通过这个 Binder 接口与底层 Client 保持交互。

通过 Client 创建流程的封装，CameraService 实现了对相机访问的全栈资源控制：从调用者身份验证，到 HAL 会话建立，再到状态同步、生命周期监听，形成了完整的权限闭环与通信路径，是 Camera 系统安全稳定运行的基础。开发者如需扩展 Client 功能（如 AI pipeline 注入、权限监控、日志采集等），都需从此流程入手精确定位与注入。

五、Camera3Device 初始化与设备接口绑定：HAL session 启动全流程

在 Camera2Client 成功构造后，下一步关键任务是初始化 Camera3Device，这是 HAL 层 session 的正式启动入口。此过程将完成与 provider 的连接、HAL camera 打开、HAL callback 绑定、Metadata 模板构建等一系列操作，属于 camera 子系统正式可用的起点。

5.1 Camera3Device 初始化入口

初始化调用链如下：

Camera2Client::initialize()
└── Camera3Device::initialize()
    ├── CameraProvider 接入与 HAL 打开
    ├── HAL callback 设置
    ├── static metadata 获取
    └── stream 配置模板构建

函数路径：

frameworks/av/services/camera/libcameraservice/device3/Camera3Device.cpp

核心函数签名：

status_t Camera3Device::initialize(sp<CameraProviderManager> manager, sp<CameraDeviceCallback> callback)

此处传入的 manager 是设备发现期间注册的 CameraProviderManager，callback 则用于后续向 CameraService 上报错误与帧状态。

5.2 HAL 打开：HAL session 的核心握手

Camera3Device 会首先向 provider 查询 HAL 接口，并执行 open 流程：

res = manager->openSession(cameraId, this /* CameraDeviceCallback */, &mInterface);

这里的关键动作包括：

获取 HAL 中的 ICameraDeviceSession 接口（通过 AIDL/HIDL）；
注册 HAL 回调（如 processCaptureResult, notify）；
设置 session buffer 管理接口；
建立 HAL 层内部 pipeline 控制结构。

若 HAL 返回失败（如设备占用、ISP crash、权限限制），会立即中断初始化流程，并向上层抛出错误。

5.3 静态 Metadata 获取

随后会通过 HAL 查询当前 camera 支持的所有能力：

mDeviceInfo = mInterface->getCameraInfo();
mDeviceInfo.static_metadata;

该 metadata 包含：

AE/AF/AWB 支持模式；
stream 格式与尺寸；
传感器帧率与时序；
input/output 支持路径；
HAL pipeline 深度与延迟约束。

metadata 会被存储在 Camera3Device 和 Camera2Client 中，并提供给 App 上层查询（即 CameraCharacteristics）。

5.4 模板构建与 Pipeline 启动

Camera2 框架要求支持如下标准模板：

TEMPLATE_PREVIEW
TEMPLATE_STILL_CAPTURE
TEMPLATE_RECORD
TEMPLATE_MANUAL

Camera3Device 会调用 HAL 的：

constructDefaultRequestSettings(templateId)

生成默认 CaptureRequest，这些模板会被 App 端作为默认拍照或预览请求构建基础。

初始化成功后，Camera3Device 状态被标记为 INITIALIZED，可接受后续 configureStreams()、submitRequest() 等操作。

六、ICameraDeviceUser Binder 对象封装：如何对接应用层控制接口

CameraService 通过构造 Client 并初始化 Camera3Device 后，需向应用层返回一个标准控制接口 —— ICameraDeviceUser，这是 Java/Native 应用与 camera 子系统交互的核心通道，承担了几乎所有下发请求、接收事件、控制资源等关键任务。

6.1 接口定义与调用者视角

ICameraDeviceUser 是一个 AIDL 接口，定义路径为：

frameworks/av/camera/aidl/android/hardware/ICameraDeviceUser.aidl

主要方法包括：

submitRequest()：发送一帧或多帧 CaptureRequest；
beginConfigure() / endConfigure()：配置 stream pipeline；
flush()：中断正在进行的帧；
disconnect()：主动释放资源；
createDefaultRequest()：获取默认模板；
getCameraInfo()：查询静态能力；
setTorchMode()：控制闪光灯；
deleteStream()：手动释放流。

6.2 接口实现与封装路径

实现类为：

frameworks/av/services/camera/libcameraservice/api2/CameraDeviceClient.cpp
class CameraDeviceClient : public BnCameraDeviceUser

该类内部持有 Camera3Device 引用，通过 AIDL 接口转发上层请求：

status_t CameraDeviceClient::submitRequest(...) {
    return mDevice->submitRequest(requestList, &lastFrameNumber);
}

所有 ICameraDeviceUser 方法都是对 Camera3Device 方法的封装，附加权限校验、状态保护与流控管理。

6.3 Client 和 User 的绑定流程

在 CameraService::connectHelper() 中，构造完 Camera2Client 后：

sp<CameraDeviceClient> client = new CameraDeviceClient(...);
*outDevice = client->getRemote(); // 返回 ICameraDeviceUser binder

这里的 getRemote() 会返回：

sp<ICameraDeviceUser> mRemote = static_cast<ICameraDeviceUser*>(this);

即，CameraDeviceClient 本身就是 AIDL 服务端，实现了 ICameraDeviceUser，系统将其直接暴露给调用者。

6.4 Java 层的调用路径

在应用中，Java 层使用如下接口控制：

CameraDevice device;
device.createCaptureSession(...)
device.capture(request, callback, handler);

这些操作内部会通过 JNI 进入 native 层 CameraDeviceClient，最终转为对 HAL 的帧请求操作。

6.5 调试建议与数据验证

可通过以下方式确认绑定成功：

dumpsys media.camera

输出应包含：

Active clients:
  UID: 10234
  ICameraDeviceUser: connected
  Streams: 2 (Preview + Capture)

若绑定失败，常见原因包括：

App 回调未正确传入；
HAL 初始化失败；
Binder 权限不匹配；
client 被其他 UID 占用。

通过 Camera3Device 的底层初始化与 ICameraDeviceUser 的接口封装，CameraService 构建了一套完整、隔离、安全的 camera 连接机制，保证了 HAL 层能力可稳定暴露给应用，并支持高性能流式控制、AI pipeline 注入、多摄合流与权限动态分配等复杂场景，是现代移动设备摄像系统架构的核心支撑模块。

七、Client 生命周期与回收策略：连接断开、死亡监听与资源释放机制

在 Android Camera 架构中，每一个活跃的 camera client（如 Camera2Client）都代表着一个 App 与 HAL 之间的独占连接。CameraService 需要对这些 client 的生命周期进行严格管理，以防止资源泄漏、冲突访问、未释放硬件控制权等问题。系统通过多重策略保障 client 在异常退出或调用主动释放时，能够被安全及时地清理。

7.1 生命周期管理的核心组件

CameraService 内部使用 CameraClientManager 管理所有活跃的 client，按 UID 维度分组，保证资源控制不被滥用：

sp<CameraClientManager> mActiveClientManager;

每次连接成功后，系统将 client 注册至 manager：

mActiveClientManager->add(client, clientUid);

并在断开或错误时移除：

mActiveClientManager->remove(client);

该 manager 会维护 client 与 cameraId 的对应关系，避免同 UID 多次打开同一 camera。

7.2 Binder 死亡监听机制

为了处理 App 异常退出（crash、kill、ANR），系统通过 Binder 机制建立死亡回调链：

client->getRemote()->asBinder()->linkToDeath(this);

当 App 的 Binder 被回收时，系统触发：

CameraService::Client::binderDied()

此函数会自动调用：

disconnect();
mCameraService->removeByClient(this);

进而完成以下操作：

HAL session close（Camera3Device::disconnect()）；
回收所有 buffer；
移除 UID 的活跃 client；
发出设备可用状态广播。

7.3 主动释放机制：disconnect() 调用路径

当 App 主动释放 camera 时，会调用：

CameraDevice.close()

Java 层通过 AIDL 触发：

CameraDeviceClient::disconnect()
→ Camera3Device::disconnect()

清理内容包括：

停止所有 stream；
停止帧采集；
通知 HAL 结束 session；
清空 request pipeline；
回收 buffer allocator；
更新设备状态为 AVAILABLE。

7.4 超时保护与系统级回收策略

若 App 长时间占用 camera 未释放，在以下场景下系统会强制释放资源：

应用进入后台超过特定时间；
系统进入 Doze/Idle 模式；
thermal 限制触发；
权限变更（App 被禁用 CAMERA 权限）；
UID 被 kill。

CameraService 中实现了 UID 状态监听与 Camera usage 强制断开机制，保护系统稳定性与其他应用的使用权。

八、实战排查技巧：连接失败、权限拒绝、死锁与 Session 初始化超时定位方法

Camera 框架的连接链路涉及 App、Framework、CameraService、HAL、驱动多个模块，一旦出现连接异常，必须系统性定位问题原因。以下列出工程实践中高频遇到的连接失败类型及对应排查策略。

8.1 权限拒绝类错误

常见现象：

SecurityException in Java；
PERMISSION_DENIED in connectDevice()；
CameraService log: Permission check failed for UID...

排查路径：

logcat -s CameraService PackageManager AppOps

确认是否有如下日志：

CameraService: Permission check failed for package com.xxx uid=10345
AppOps: op_camera denied for uid=10345

解决方案：

确保 Manifest 中声明 CAMERA 权限；
App 已授权（Settings > App > Permissions）；
使用合规 UID，避免系统签名校验失败。

8.2 HAL 初始化失败（open 失败）

常见现象：

java.lang.RuntimeException: Failed to connect to camera service；
logcat 中出现 No camera HAL found for id X；
CameraProvider log: openSession failed for id=X

排查路径：

logcat -s CameraService CameraProviderManager
dumpsys media.camera
lshal | grep camera

确认是否缺少 HAL 设备或 Provider 返回失败。

解决方案：

检查 HAL 是否正确编译进镜像；
Vendor HAL service（如 camera_provider@2.5-service）是否正常启动；
USB 摄像头是否插入但未识别；
cameraId 映射表是否配置错误。

8.3 Client 死锁或连接阻塞

常见现象：

openCamera() 卡住无返回；
App 卡死在 createCaptureSession()；
无报错但也无响应。

排查路径：

kill -3 <app_pid>    # 打印 Java 堆栈
logcat -s CameraService CameraDeviceClient

观察是否有：

CameraService: connectDevice: waiting for previous client disconnect
Camera3Device: initialize timeout

解决方案：

检查是否有旧 client 未释放；
使用 dumpsys media.camera 确认是否存在 zombie client；
检查 HAL 是否响应慢或卡死，可用 dmesg 分析中断异常；
重启 cameraserver 尝试恢复状态。

8.4 session 初始化超时或 HAL 无响应

常见现象：

createCaptureSession() 抛出超时异常；
Preview 黑屏；
错误码 ERROR_CAMERA_DEVICE / ERROR_CAMERA_SERVICE;

排查路径：

logcat -s Camera3Device CameraProvider CameraService

关键日志：

Camera3Device: configureStreams - timed out
CameraProvider: processCaptureRequest failed: DEAD_OBJECT

解决方案：

检查 configureStreams() 是否参数异常（如 stream format、size）；
确认 HAL 是否返回错误（check HIDL/AIDL proxy 实现）；
避免在未完成的 session 上重复创建 stream；
捕获系统 trace，确认死锁/锁冲突是否存在。

通过结合 logcat + dumpsys + lshal + binder + trace 多层手段，可以精准还原 CameraClient 从连接 → 初始化 →控制的整个链路，快速定位异常点，提升调试效率，是平台 Bring-up、HAL 适配、App 开发稳定性保障的必要技能。

原文：https://zhxin.blog.csdn.net/article/details/149438163

如果觉得文章对你有用，请随意赞赏

308.CameraService 源码解读（二）：Client 创建与连接机制全链路详解

http://114.132.213.38:6250/archives/1754202833362

作者

枫叶先生的网络日志

发布于

2025-08-03

更新于

2025-08-03

许可协议

CC BY 4.0

308.CameraService 源码解读（二）：Client 创建与连接机制全链路详解

CameraService 源码解读（二）：Client 创建与连接机制全链路详解

目录：

一、连接调用起点：ICameraService.connectDevice 的 AIDL 接口入口

1.1 调用链总览（以 Camera2 为例）

1.2 接口参数解析

1.3 实现入口：CameraService::connectDevice()

二、权限验证与 UID 管控：安全模型下的多层连接限制机制

2.1 核心权限校验点

2.2 UID 资源隔离机制

2.3 活跃连接限制与并发控制

2.4 特权 UID 白名单

2.5 调试建议与验证命令

三、HAL 版本判断与 Client 类型选择：Camera1、Camera2、Camera3 分支策略

3.1 HAL 类型的判定机制

3.2 客户端类型选择逻辑

CameraClient（HAL1）

Camera2Client（HAL3）

3.3 特殊平台 HAL 混合实现

四、CameraClient 创建流程解析：构造器、状态同步与注册流程

4.1 Camera2Client 构造器解析

4.2 与 HAL 层绑定（Camera3Device）

4.3 客户端注册与同步

4.4 返回控制 Binder 接口

五、Camera3Device 初始化与设备接口绑定：HAL session 启动全流程

5.1 Camera3Device 初始化入口

5.2 HAL 打开：HAL session 的核心握手

5.3 静态 Metadata 获取

5.4 模板构建与 Pipeline 启动

六、ICameraDeviceUser Binder 对象封装：如何对接应用层控制接口

6.1 接口定义与调用者视角

6.2 接口实现与封装路径

6.3 Client 和 User 的绑定流程

6.4 Java 层的调用路径

6.5 调试建议与数据验证

七、Client 生命周期与回收策略：连接断开、死亡监听与资源释放机制

7.1 生命周期管理的核心组件

7.2 Binder 死亡监听机制

7.3 主动释放机制：disconnect() 调用路径

7.4 超时保护与系统级回收策略

八、实战排查技巧：连接失败、权限拒绝、死锁与 Session 初始化超时定位方法

8.1 权限拒绝类错误

常见现象：

排查路径：

解决方案：

8.2 HAL 初始化失败（open 失败）

常见现象：

排查路径：

解决方案：

8.3 Client 死锁或连接阻塞

常见现象：

排查路径：

解决方案：

8.4 session 初始化超时或 HAL 无响应

常见现象：

排查路径：

解决方案：

作者

发布于

更新于

许可协议

评论