Android HIDL Migrate to AIDL

一、Android HIDL Migrate to AIDL

1、在Android开发中，HIDL（Hardware Interface Definition Language）和AIDL（Android Interface Definition Language）是用于实现跨进程通信的重要工具，二者均基于Binder机制。然而，在某些场景下，开发者可能会需要将HIDL接口迁移到AIDL，以提升代码的可维护性和兼容性。接下来，我们将分步骤介绍如何进行这一迁移。

2、首先，找到AIDL接口定义的目录。通常位于hardware/interfaces/路径下，这里包含了xx.aidl文件，文件中定义了数据类型、方法、类等抽象概念，比如回调函数。在这些定义基础上，客户端需要具体实现。

3、进行具体的文件修改时，需要删除依赖的libhidlbase和基于hidl接口编译的server端库文件，替换为基于aidl编译的库文件，如"android.hardware.thermal-V1-ndk"，同时添加"libbinder_ndk"。此外，需要将hidl头文件替换为aidl头文件，并且调整接口声明。

4、在aidl文件中，返回类型通常改为::ndk::ScopedAStatus。因此，需要声明并修改原先的hidl接口声明，将Return类型的返回值更改为ScopedAStatus::ok()，确保与新接口的兼容性。

5、对于指针类型，aidl中会定义为智能指针std_sharedptr，而原先的强指针sp需要进行相应的修改。这一系列调整旨在确保AIDL接口在不同环境下的稳定性和可扩展性。

6、获取server端服务句柄的方式也有所变化。在HIDL中，实现过程较为直接，而在AIDL中，需要定义远程服务的death回调函数、创建DeathRecipient指针，并通过AIBinder_DeathRecipient_new和AIBinder_linkToDeath函数进行绑定，同时引入ndk::SpAIBinder相关的函数。

7、最后，进行HIDL到AIDL的迁移时，需关注DeathNotification的实现。在HIDL中，使用hidl_death_recipient类实现较为简便，但在AIDL中，需手动定义远程服务死亡的回调函数和DeathRecipient指针，并通过相应的Binder函数完成绑定，涉及到ndk::SpAIBinder的使用。

8、完成上述步骤后，开发者需检查代码逻辑、接口调用及依赖关系，确保迁移过程中没有引入新的错误或遗漏。此外，参考官方文档进行验证和测试，可以有效提升迁移工作的成功率和稳定性。

二、一篇文章带你了解Android 最新Camera框架

本文将为您详解Android最新Camera框架，涵盖整体框架、Camera2与HAL3的基本了解。

Android Camera整体框架包含三个关键进程：app进程、camera server进程、hal进程。它们通过binder进行通信，其中app与camera server间使用AIDL，camera server与hal间则使用HIDL。Android框架层级大致为应用层->framework层->Hal层。

Android 8.0的Treble项目旨在简化设备更新流程，减少framework与HAL的耦合，引入HIDL概念。HIDL全称HAL interface definition language，用于定义HAL与用户之间的接口，实现框架在无需重新构建HAL的情况下进行替换。此设计优化了更新效率与降低开发成本。

最新Android Camera框架示意图清晰展示了各进程间关系。Camera2接口自Android 5.0引入，取代了简单但功能受限的Camera1接口。Camera2提供了更多高级特性，如检查相机信息、拍照时不需预览、一次拍摄多张不同格式图片、控制曝光时间、支持连拍等。

HAL3框架与Camera2配套使用，不同厂商支持程度分为LEGACY、LIMITED、FULL、LEVEL_3四个级别，表示功能支持范围。在Camera2 API中，Pipeline按顺序处理请求，且支持单次、多次、重复三种Capture模式。CameraManager负责查询相机连接，CameraCharacteristics提供相机信息，CameraDevice建立连接，Surface用于图像数据接收，CameraCaptureSession配置Pipeline实例，而CaptureRequest与CaptureResult分别用于提交与接收Capture操作结果。

代码实战展示了如何使用ImageReader与CaptureRequest拍摄单张照片。首先定义回调接口，创建ImageReader以指定尺寸获取JPEG图像数据，使用CaptureRequest.Builder构建包含拍照与预览Surface的CaptureRequest，最后通过ImageReader的回调获取图像数据，实现照片保存。

三、一文讲解Android车载系统camera架构 - EVS

本文将深入解析Android车载系统中为适应汽车环境而设计的EVS（Exterior View System）架构。在Android的camera开发中，广泛使用的camera2与cameraX架构主要针对手机移动端camera的流程，而EVS架构则专注于汽车外景系统，如倒车影像和360全景影像。本文将逐步剖析EVS架构的四个关键组件：EVS APP、EVS Manager、EVS HAL，以及Vehicle HAL。

EVS APP作为用户界面，接收并处理来自EVS Manager的底层HAL传递的camera数据。在Android 12中，EVS APP仅支持简单的图像预览。EVS APP的基本流程涉及枚举底层配置的video设备节点，筛选支持的格式，最后将符合条件的设备纳入sCameraList。在需要Vehicle HAL的前提下，EVS APP连接Vehicle HAL以订阅车辆挡位和转向灯信息，并在外部输入变化时通过回调处理这些数据。同时，EVS APP通过EvsStateControl状态更新线程调整运行状态，实现图像绘制。

EVS Manager作为EVS架构的中心，为APP提供与EVS HAL交互的接口。它实现与底层HAL驱动程序相同的API，支持多个客户端并发访问相机流。EVS Manager管理EVS Camera与EVS Display，并提供权限管理和诊断功能。EVS Manager对HAL接口进行封装，增加额外功能，如数据统计、诊断等，并支持虚拟Camera设备。

EVS HAL作为硬件抽象层，与内核驱动交互，获取摄像头数据。它提供EVS Camera与EVS Display两个抽象对象，是OEM厂商关注的核心部分。EVS HAL存在1.0与1.1两个版本，1.1版本在HIDL接口中增加了IEvsUltrasonicsArray.hal与IEvsUltrasonicsArrayStream.hal文件，为可能存在的超声波Sensor提供API，支持自动驾驶需求。

Vehicle HAL作为整体Android Automotive版本的通信桥梁，向下接入通信接口，向上服务于Java Framework和Native Framework。它定义和实现接口，用于汽车其他控制器之间的通信。

相较于camera2，EVS架构专注于车外摄像头，这些摄像头位置固定，视角较为统一，因此系统对摄像头的控制相对较少。而camera2则用于手机camera控制，提供更灵活的调节方法和参数设置。EVS架构强调快速启动、响应和低延迟，适合车载系统需求，而camera2架构则在Java Framework层提供了丰富API，简化应用开发。

EVS架构的开发难度相对较高，需要开发者构建Input管理、View子系统，并使用OpenGL ES API进行图像绘制。市面上关于camera2架构的资源较多，而关于EVS架构的分析较少，本文旨在提供基本介绍和分析，鼓励感兴趣的读者共同研究学习。

总结，EVS架构是针对汽车外景系统设计的camera架构，其组件包括EVS APP、EVS Manager、EVS HAL和Vehicle HAL。EVS架构在控制、启动速度和延迟方面满足车载系统需求，与camera2架构在应用场景、控制复杂度和开发难度上存在显著差异。未来，我们将对EVS架构的使用细节进行深入分析。