转载和创作优秀的博客

1. 打开动态链接库： #include <dlfcn.h> void *dlopen(const char *filename, int flag); 该函数返回操作句柄，如： void *pHandle = dlopen(strSoFilePath, RTLD_LAZY);2. 取动态对象地址： #include <dlfcn.h> void *dlsym(void *pHandle, char *symbol); ...

一、概述HAL层是Android系统架构里介于Linux内核和系统运行库层之间的一个层，个人认为这个层存在的目的主要是为了避免GPL协议所带来的开源问题。Android系统会统一加载硬件抽象层模块，负责加载硬件抽象层模块的函数是hw_get_module函数。二、hw_get_module1、hw_get_module原型在Android硬件抽象层中，负责加载硬件抽象层模块的函数是hw_get_module，当调用者需要加载这些模块时，只要指定它们的ID值就可以了。它的原型如下：1 /**

Android HAL概述Android HAL(Hardware Abstract Layer)硬件抽象层，从字面意思可以看出是对硬件设备的抽象和封装，为Android在不同硬件设备提供统一的访问接口。HAL处于Android framework和Linux kernel driver之间，HAL存在的意义有以下2个方面：HAL屏蔽了不同硬件设备的差异，为Android提供了统一的访问硬件设备的接口。不同的硬件厂商遵循HAL标准来实现自己的硬件控制逻辑，但开发者不必关心不同硬件设备的差异，只需要按

Android系统应用场景中，Camera的使用场景变得越来越重要，在手机端不管是牌照美颜， 还是拍小视频上传小视频平台。在其他领域，如车载，倒车视频， 360全景影像也同样会用到Camera接口。那我们这个系列就拿Camera来分析了， 我们主要就是android camera流程进行一个分析，对于照片美颜， 视频上传这些就不在我们关注的范围了。那我们分析还是带着问题去分析吧， Camera就..

Android P HIDL 以及 CameraProvider一. 相关文件// 须要本身实现的Service.cpp (hardware\interfaces\camera\provider\2.4\default) 1264 2019-6-19CameraProvider.cpp (hardware\interfaces\camera\provider\2.4\default) 23897 2019-6-19javascript// 经过HIDL自动生成CameraProviderA

AndroidO Treble 架构之 CameraProvider 分析相关的文件如下：hardware/interfaces/camera/provider/2.4/default/service.cpphardware/interfaces/camera/provider/2.4/default/android.hardware.camera.provider@2.4-service.rchardware/interfaces/camera/provider/2.4/default/Came

HIDL接口定义创建hidl目录在aosp中的hardware/interfaces目录下创建自己的hal目录mkdir -p hardware/interfaces/qmiller/1.0/default创建hal文件在我们刚才创建的hardware/interfaces/qmiller/1.0/目录下新建IQmiller.hal文件,传入string name，返回string类型的result。package android.hardware.qmiller@1.0; ...

Android-HAL与HIDL分析使用总结HAL接口定义语言（简称HIDL）适用于指定HAL和其用户之间的接口的一种接口描述语言（IDL）,HIDL允许指定类型和方法调用。HIDL旨在用于进程间通信（IPC）。进程之间的通信经过Binder化。对于必须与进程相关联的代码库，还可以使用直通模式。HIDL可指定数据结构和方法签名，这些内容会整理归类到接口中，而接口会汇集到软件包中。尽管HIDL具有一系列不同的关键字，C++和JAVA程序员对HIDL的语法并不陌生。此外，HIDL还是用JAVA样式和注

最近在项目中遇到一个问题, 要对某个节点(dev/xxx)进行写操作, 但这个设备节点只允许root用户才能进行写操作, 因此不能通过Java或者JNI方式直接去访问, 因此想到了两种方法:通过在init.rc中监听一个系统属性的值, 当属性变为某个值时, 触发一个可执行文件进行读写 编写一个Native Service, 然后以root的身份运行, 通过跨进程调用, 在Service中进行写操作最后通过第一种方式解决了问题, 原因是写的频率很低, 基本一个手机就一次, 所以没必要弄成服务, 但本着

想了解HIDL介绍的可以参考《HIDL概述》，本篇文章主要介绍HIDL的详细编译流程及简单的客户端应用（C++跟Android客户端的应用）。一、准备工作整一套源码，Android O或者Android P的保证全套代码已经全编译，原生代码全编译命令source build/envset.shlunchmake 3、hidl-gen工具已经安装，安装命令make hidl-gen二、hidl-gen工具介绍系统定义的所有的.hal接口，都是通过hidl-gen工具转换成对应...

HIDL接口定义创建hidl目录在aosp中的hardware/interfaces目录下创建自己的hal目录mkdir -p hardware/interfaces/qmiller/1.0/default创建hal文件在我们刚才创建的hardware/interfaces/qmiller/1.0/目录下新建IQmiller.hal文件,传入string name，返回string类型的result。package android.hardware.qmiller@1.0;

cameraprovider进程是Camer HAL所在进程，在分析HAL启动流程前，必须先分析下cameraprovider的启动流程本文在此对cameraprovider的启动流程作简要的分析javarc启动脚本：linux//hardware\interfaces\camera\provider\2.4\default\android.hardware.camera.provider@2.4-service.rcservice camera-provider-2-4 /vendor/bi

camera API2的ICameraDeviceUser.aidl接口ICameraService.aidl定义了ICameraService 接口，实现主要通过CameraService类来实现，主要接口如下： • getNumberOfCameras： 获取系统中支持的Camera 个数 • connectDevice()：打开一个Camera 设备 • addListener(): 添加针对Camera 设备以及闪光灯的监听对象ICameraDeviceC...

api 调用获取CameraManager对象CameraManager mCameraManager = (CameraManager) context.getSystemService(Context.CAMERA_SERVICE);openCameramCameraManager.openCamera(cameraId, callback, handler);调用的是 CameraManager 中的 openCameraDeviceUserAsync 方法 pri

背景这几天在天天在写Context.getSystemService()获取系统服务，例如在获取窗口服务的时候都会这样写：WindowManager manager = (WindowManager) context.getSystemService(Context.WINDOW_SERVICE);突然有人问我说，就是getSystemService() 每次获取的对应的WindowManager是否是同一个，还是每次生成新的？直接翻看了下源码，事实上还是比较简单的，以下做一下记录：分析

Context.getSystemService流程拿获取TelephonyManager实例举例： TelephonyManager tm = (TelephonyManager) mContext.getSystemService(Context.TELEPHONY_SERVICE);其中mContext是Context的一个实例frameworks/base/core/java/android/content/Contex

1 前言Android 11 引入了在 Android 中使用 AIDL 实现 HAL 的功能。这样就可以在不使用 HIDL 的情况下实现 Android 的部分代码。Power HAL模块即可以采用AIDL方式来实现。在Android 11中已经引入这个Power AIDL Interface，源码位于：/hardware/interfaces/power/aidl/在学习这部分之前，推荐阅读AIDL的相关知识，特别是Android 10之后引入的对稳定的 Android 接口定义语言 (AI

手机相机的未来与发展Android相机发展至今，通过开发者对框架的不断优化，算法人员对图像处理算法的不断提升，硬件工程师对硬件性能地不断调教，换来了在某些领域完全可以媲美专业相机的成像效果，这些成绩是有目共睹的，但是我们不能仅仅着眼于过去，试着将眼光放得长远些，如何将Android相机推向更高的维度，使其成为手机相机的王者，想必这是每一个热衷于技术的开发者都需要反复思考的问题，当然就我个人而言，对于它的未来，有着我自己的思考。Android相机，首先是基于Android系统，所以对于系统端的优化，我

安卓相机架构总结Android 相机体系庞大且复杂，在我刚开始接触到该框架的时候，如盲人摸象一般，一点一点地在代码的世界中探索，在很长的一段时间内，都只能局限于某一个特定的区域，而且在解决问题的过程中，虽然通过对代码的深入梳理，最终都会顺利解决难题，但是到最后依然缺乏一个对于整个框架的理解，正如管中窥豹一般，只见细节而无法把握全貌。但是进入现在的公司之后，通过与相机前辈的沟通，我发现框架思维能力尤为重要，针对整个框架结构需要做到掌控全局，这样在遇到问题的时候便可以迅速定位，此时再进行代码层面的深入研究，

相机硬件层一、简介相机的硬件层，作为整个框架的最底层，通过硬件模块接收来自客观世界的真实光影效果，将其转换为计算机所熟知的数字信号，并按照一定的数据格式向上源源不断提供成稳定并成像效果优秀的图像数据，整个部分复杂且高效，可以说是，一个优秀的硬件基础，就好比为整个相机框架的地基，拥有一个好的地基，便使得建造一座摩天大厦成为可能，接下来我们来详细介绍下，这部分各个组件的基本情况。二、基本硬件结构而今的相机硬件系统纷繁复杂，但是如果仔细深入研究的话，你会发现，其实核心组件无外乎镜头、感光器、图像处理器

一、概览利用了V4L2可扩展这一特性，高通在相机驱动部分实现了自有的一套KMD框架，该框架通过V4L2标准方法在系统中创建设备节点，将控制接口直接暴露给UMD CSL进行访问，而其内部主要定义了一系列核心模块，包括CRM(Camera Request Manager)，用于管理整个KMD的Session/Link的创建销毁以及Request的在子设备间的流转，该模块创建video0设备节点暴露关键接口给UMD，此外还包括了Sync模块，主要负责了UMD/KMD之间的数据同步与传输，创建video1设备节点

一、概览相机驱动层位于HAL Moudle与硬件层之间，借助linux内核驱动框架，以文件节点的方式暴露接口给用户空间，让HAL Module通过标准的文件访问接口，从而能够将请求顺利地下发到内核中，而在内核中，为了更好的支持视频流的操作，早先提出了v4l视频处理框架，但是由于操作复杂，并且代码无法进行较好的重构，难以维护等原因，之后便衍生出了v4l2框架。按照v4l2标准，它将一个数据流设备抽象成一个videoX节点，从属的子设备都对应着各自的v4l2_subdev实现，并且通过media con.

一、概览回顾高通平台Camera HAL历史，之前高通采用的是QCamera & MM-Camera架构，但是为了更精细化控制底层硬件(Sensor/ISP等关键硬件)，同时方便手机厂商自定义一些功能，现在提出了CamX-CHI架构，由于在CamX-CHI中完全看不到之前老架构的影子，所以它完全是一个全新的架构，它将一些高度统一的功能性接口抽离出来放到CamX中，将可定制化的部分放在CHI中供不同厂商进行修改，实现各自独有的特色功能，这样设计的好处显而易见，那便是即便开发者对于CamX并不是很了解

相机硬件抽象层一、概览始于谷歌的Treble开源项目，基于接口与实现的分离的设计原则，谷歌加入了Camera Provider这一抽象层，该层作为一个独立进程存在于整个系统中，并且通过HIDL这一自定义语言成功地将Camera Hal Module从Camera Service中解耦出来，承担起了对Camera HAL的封装工作，纵观整个Android系统，对于Camera Provider而言，对上是通过HIDL接口负责与Camera Service的跨进程通信，对下通过标准的HAL3接口下发针对C

一、简介Camera Service被设计成一个独立进程，作为一个服务端，处理来自Camera Framework 客户端的跨进程请求，并在内部进行一定的操作，随后作为客户端将请求再一次发送至作为服务端的Camera Provider，整个流程涉及到了两个跨进程操作，前者通过AIDL机制实现，后者通过HIDL机制实现，由于在于Camera Provider通信的过程中，Service是作为客户端存在的，所以此处我们重点关注AIDL以及Camera Service 主程序的实现。二、Camera AI

一、概览相机应用处于整个框架的上层，在现实生活中，为了满足各式各样的应用场景，会加入很多业务处理逻辑，但是一旦当我们拨开繁杂的业务逻辑，便会发现其核心部分依然是通过调用谷歌制订的一系列Camera Api接口来完成的，而所有的相机行为都包含在该接口中。起初，相机系统采用的是Camera Api v1接口，它通过一个Camera 类以及该类中的几个标准方法来实现整个相机系统的预览、拍照以及录像功能，控制逻辑比较简单，同时也比较容易理解，但也正是这种简单，导致了它无法逐帧控制底层硬件，无法通过元数据进行修

Android系统利用分层思想，将各层的接口定义与实现分离开来，以接口作为各层的脉络连接整体框架，将具体实现的主导权交由各自有具体实现需求的平台厂商或者Android 开发者，这样既做到把控全局，也给予了众多开发者足够大的创作空间，这体现出了一个优秀的开源系统应有的胸怀和远见。其中，谷歌根据职能的不同将Camera框架一共划分成了五层，分别是App、Service、Provider、Driver以及Hardware，下面的Camera的整体架构图很清晰地显示出了其五层架构以及相互的关联接口。Came.

相机简史几千年来，人类主要通过文字以及绘画的方式记录着对于客观世界的认知，为了更直观地呈现客观世界的图景，摄影技术应运而生。摄影是一门光与影的艺术，通过透镜将光线导入并依靠其折射特性，将光线最终导向到感光器件中，而感光器件在收到光线刺激之后进行一定的转换，进而形成影像，而这一系列的硬件设备的组合统一被称之为相机系统，同时由于现代计算机科学的迅猛发展，该系统依托其强大的传播力，彻底改变和提升了人类感知客观世界的方式和速度。与现在相比，早期的相机系统十分简陋，同时成像效果也一直是灰白色调为主，但随着技术

序言Android系统自2007年底被Google推出问世以来，已经走过13个春夏秋冬，历经多次的大大小小的迭代重构、架构调整，虽然时代年轮依旧滚滚，虽然每年技术依然在不断地推陈出新，但是到目前为止，依然可以窥见其接口与实现相分离的核心设计理念，所以其架构设计的优越性可见一斑，另外，随着智能手机的快速普及，面对这一庞大终端市场，作为系统中最重要的几个组件之一的相机系统也必定会作为主要战场在手机市场中与其它厂商展开竞争。近几年，谷歌针对相机框架体系进行了多次迭代优化，就而今的相机框架而言，整体架构设计十分优

某车机平台，使用高通soc，基于Android P。底层通路已经由芯片供应商打通，移植的是Android v4l2的代码。Android原生的v4l2 code路径：hardware\libhardware\modules\camera\3_4Soc供应商复用了大部分代码+少量修改，实现了Camera功能。问题：Camera的测试app在进行测试时，偶发camera HAL crash。概率大约50%左右。下面记录解决步骤：Camera的流程梳理调用过程大致如下系统中存在2个camera.

总览预览打开完毕后，就进入了持续预览阶段。Camera API2 架构下，采用一个 Request 对应一个 Result 的规范，所以在预览期间是需要持续下 Request 来获取预览数据的，而仍然采用 API1 相机应用在 Framework 中也会被转换成这样的形式。其中，与 Request 密切相关的一个线程是 Camera3Device::RequestThread，它负责持续下预览 Request。Result 从底层返回时，会先回到 Camera3Device，触发 proces

总览三方应用调用 Camera API1 的 startPreview 接口时， Framework 部分的时序图如下，其中注意几个点：API1 转 HAL3 的主要逻辑都在 Camera2Client 中，只有在底层 HAL3 的情况下调用 API1 会走到这（在 openCamera 时会有相关的实例化逻辑）；Camera3Device 相当于 HAL3 架构下 Framework 层中与 HAL 层进行对接的实例，这部分不区分 API1 还是 API2；startPreview 只打开一路

总览三方应用调用 Camera API1 的startPreview接口时， Framework 部分的时序图如下，其中注意几个点：API1 转 HAL3 的主要逻辑都在 Camera2Client 中，只有在底层 HAL3 的情况下调用 API1 会走到这（在 openCamera 时会有相关的实例化逻辑）；Camera3Device 相当于 HAL3 架构下 Framework 层中与 HAL 层进行对接的实例，这部分不区分 API1 还是 API2；startPreview 只打开一..

正文HAL3 强制升级已经有一年左右了，和 HAL3 搭配的 Camera API2 目前已经改用的三方相机应用还并不算多，所以为了更好地 debug 三方相机相关的卡顿问题，我近期花时间专门研究了 Android Framework 层提供的 API1 转 API2 连接 HAL3 的逻辑（以启动预览、预览数据流为例），以便对转换过程有一个总体认识，并且对经常遇到的两个由于 API 逻辑转换导致的卡顿问题进行更细致的分析。先说说目前几个项目经常碰到的两种卡顿现象：启动预览后出现短暂预览卡顿现象

一、Camera MetaData 作用简介简单来说，Camera 设置参数，以前都是调用 SetParameter()/Paramters() 来实现下发或获取参数。而现在新的 Camera API2 / HAL3 架构，则修改为使用 Camera MetaData 的形式来下发或获取参数。Camera MetaData 就是将参数以共享内存的形式，将所有的Camera 参数以 有序的结构体的形式 保存在一块连接的内存中。在API2 中，Java层中直接对参数进行设置并将其封装到Captur

前言上一篇文章大概介绍了一下Camera的整体架构，先回顾一下：上图是Google官方的Camera架构，Google封装了HAL层接口：ICameraProvider, ICameraDevice, ICameraDeviceSession。这几个接口的作用如下：ICameraProvider：用于枚举单个设备并管理其状态。ICameraDevice：相机设备接口。ICameraDeviceSession：活跃的相机设备会话接口。MTK HAL3结构主要实现了这几个接口，

（1）Hal3架构分析（A）应用框架应用代码位于应用框架级别，它使用 Camera 2 API与相机硬件进行交互。在内部，这些代码会调用相应的 Binder 接口，以访问与相机互动的原生代码。（B）AIDL（Binder IPC 接口）与 CameraService 关联的 binder 接口可在 frameworks/av/camera/aidl/android/hardware 中找到。生成的代码会调用较低级别的原生代码以获取对实体相机的访问权限，并返回用于在框架级别创建 Ca.

vivi代码v4l2测试代码step 5 : 设置缓存1，申请缓存struct v4l2_requestbuffers req; req.count = nr_bufs; //缓存数量req.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;req.memory = V4L2_MEMORY_MMAP; if (ioctl(fd, VIDIOC_REQBUFS, &req) < 0)这里会调用到v4l_reqbufsstatic in.

V4L2接口解析操作步骤应用程序通过V4L2接口采集视频数据步骤打开视频设备文件，通过视频采集的参数初始化，通过V4L2接口设置视频图像属性。申请若干视频采集的帧缓存区，并将这些帧缓冲区从内核空间映射到用户空间，便于应用程序读取/处理视频数据。将申请到的帧缓冲区在视频采集输入队列排队，并启动视频采集。驱动开始视频数据的采集，应用程序从视频采集输出队列中取出帧缓冲区，处理后，将帧缓冲区重新放入视频采集输入队列，循环往复采集连续的视频数据。停止视频采集。具体实现如下图图中文字打开视.

上一篇文章讲到传输图像的方式： 方法1：通过【帧IO】访问方式 使用read和write的方式，通过read读取每一帧数据，数据需要在内核和用户之间拷贝，这种方式访问速度会非常慢。 方法2：通过【流IO】访问方式： 内存映射缓冲区(V4L2_MEMORY_MMAP)：在内核空间开辟缓冲区，应用通过mmap()系统调用映射到用户地址空间 用户空间缓冲区(V4L2_MEMORY_USERPTR)：在用户空间的应用中开辟缓冲区，用户与内核空间之间交换缓冲区指针。 因此stream(流