binder驱动源码（binder源码分析）

本文目录一览：

• 1、安卓代码里添加驱动设备的应用层函数怎么写
• 2、篇文章会先对照binder机制与linux的通信机制的区别，了解为什么android会另起炉灶
• 3、Android Binder是什么？binder属于一个驱动

安卓代码里添加驱动设备的应用层函数怎么写

说到 android 驱动是离不开 Linux 驱动的。Android 内核采用的是 Linux2.6 内核 （最近Linux 3.3 已经包含了一些 Android 代码）。但 Android 并没有完全照搬 Linux 系统内核binder驱动源码，除了对Linux 进行部分修正binder驱动源码，还增加了不少内容。android 驱动 主要分两种类型：Android 专用驱动 和 Android 使用的设备驱动（linux）。Android 专有驱动程序：1）Android Ashmem 匿名共享内存； 为用户空间程序提供分配内存的机制binder驱动源码，为进程间提供大块共享内存binder驱动源码，同时为内核提供回收和管理这个内存。2）Android Logger 轻量级的LOG（日志） 驱动；3）Android Binder 基于 OpenBinder 框架的一个驱动；4）Android Power Management 电源管理模块；5）Low Memory Killer 低内存管理器；6）Android PMEM 物理内存驱动；7）USB Gadget USB 驱动（基于 gaeget 框架）；8）Ram Console 用于调试写入日志信息的设备；9）Time Device 定时控制设备； 10）Android Alarm 硬件时钟；Android 上的设备驱动：1）Framebuff 显示驱动；2）Event 输入设备驱动；3）ALSA 音频驱动；4）OSS 音频驱动；5）v412摄像头：视频驱动；6）MTD 驱动；7）蓝牙驱动；8）WLAN 设备驱动； Android 专有驱动程序1.Android Ashmem为用户空间程序提供分配内存的机制binder驱动源码，为进程间提供大块共享内存，同时为内核提供回收和管理这个内存。设备节点：/dev/ashmen .主设备号 10.源码位置： include/linux/ashmen.h Kernel /mm/ashmen.c相比于 malloc 和 anonymous/named mmap 等传统的内存分配机制，其优势是通过内核驱动提供了辅助内核的内存回收算法机制（pin/unoin）2.Android Logger 无论是底层的源代码还上层的应用，我们都可以使用 logger 这个日志设备看、来进行调试。设备节点： /dev/log/main /dev/log/event /dev/log/radio源码位置：include/linux/logger.h include/linux/logger.c3.Android Binder IPC Binder 一种进程间通信机制。他的进程能够为其它进程提供服务 ----- 通过标准的 Linux 系统调用 API。设备节点 ：/dev/binder源码位置：Kernel/include/linux/binder.h Kernel/drivers/misc/binder.c4.Android Power Management 一个基于标准 linux 电源管理的轻量级 Android 电源管理系统，在 drivers/android/power.c kernel/power/5.Low Memory Killer它在用户空间中指定了一组内存临界值，当其中某个值与进程描述中的 oom_adj 值在同一范围时，该进程将被Kill掉（在parameters/adj中指定oome_adj 的最小值）。它与标准的Linux OOM机制类似，只是实现方法不同源码位置：drivers/misc/lowmemorykiller.c 6.Android PMEM PMEM 主要作用就是向用户空间提供连续的物理内存区域。1.让 GPU 或 VPU 缓冲区共享 CPU 核心。2.用于 Android service 堆。源码位置：include/linux/android_pmem.h drivers/android/pmem.c 7.USB Gadget 基于标准 Linux USB gaeget 驱动框架的设备驱动。源码位置：drivers/usb/gadet/8.Ram Console 为了提供调试功能，android 允许将调试日志信息写入这个设备，它是基于 RAM 的 buffer.源码位置： drivers/staging/android/ram_console.c9.Time Device 定时控制,提供了对设备进行定时控制的功能。源码位置：drivers/staging/android/timed_output.c(timed_gpio.c)10.Android Alarm 提供一个定时器，用于把设备从睡眠状态唤醒，同时它还提供了一个即使在设备睡眠时也会运行的时钟基准。设备节点：/dev/alarm源码位置：drivers/trc/alarm.c Android 设备驱动 1. Framebuffer 帧缓存设备Framebuffer 驱动在 Linux 中是标准的显示设备的驱动。对于 PC 系统，它是显卡的驱动 ； 对于嵌入式 SOC 处理器系统，它是 LCD 控制器或者其他显示控制器的驱动。它是一个字符设备，在文件系统中设备节点通常是 /dev/fbx 。 每个系统可以有多个显示设备 ， 依次用 /dev/fbO 、 /dev/fb l 等来表示。在 Android 系统中主设备号为 29 ，次设备号递增生成。Android 对 Framebuffer 驱动的使用方式是标准的 ， 在 / dev / graphie / 中的 Framebuffer 设备节点由 init 进程自动创建 ， 被 libui 库调用 。 Android 的 GUI 系统中 ， 通过调用 Framebuffer 驱动的标准接口，实现显示设备的抽象。 Framebuff的结构框架和实现 ：linux LCD驱动（二）--FrameBuffer Linux LCD驱动(四）--驱动的实现 2.Event输入设备驱动Input 驱动程序是 Linux 输入设备的驱动程序 ， 分为游戏杆 (joystick) 、 鼠标 (mouse 和 mice)和事件设备 (Event queue)3 种驱动程序。其中事件驱动程序是目前通用的程序，可支持键盘 、 鼠标、触摸屏等多种输入设备。 Input 驱动程序的主设备号是 l3 ，每一种 Input 设备从设备号占 用5 位 ， 3 种从设备号分配是 ： 游戏杆 0 ～ 61 ； Mouse 鼠标 33 ～ 62 ； Mice 鼠标 63 ； 事件设备 64 ～ 95 ，各个具体的设备在 misc 、 touchscreen 、 keyboard 等目录中。Event 设备在用户空问使用 read 、 ioctl 、 poll 等文件系统的接口操作， read 用于读取输入信息， ioctl 用于获取和设置信息， poll 用于用户空间的阻塞，当内核有按键等中断时，通过在中断中唤醒内核的 poll 实现。 Event 输入驱动的架构和实现：Linux设备驱动之——input子系统 3.ALSA音频驱动高级 Linux 声音体系 ALSA(Advanced Linux Sound Architecture ) 是为音频系统提供驱动 的Linux 内核组件，以替代原先的开发声音系统 OSS 。它是一个完全开放源代码的音频驱动程序集 ，除了像 OSS 那样提供一组内核驱动程序模块之外 ， ALSA 还专门为简化应用程序的编写提供相应的函数库，与 OSS 提供的基于 ioctl 等原始编程接口相比， ALSA 函数库使用起来要更加方便一些利用该函数库，开发人员可以方便、快捷地开发出自己的应用程序，细节则留给函数库进行内部处理 。 所以虽然 ALSA 也提供了类似于 OSS 的系统接口 ， 但建议应用程序开发者使用音频函数库，而不是直接调用驱动函数。 ALSA 驱动的主设备号为 116 ，次设备号由各个设备单独定义，主要的设备节点如下：/ dev / snd / contmlCX —— 主控制 ；/ dev / snd / pcmXXXc —— PCM 数据通道 ；/ dev / snd / seq —— 顺序器；/ dev / snd / timer —— 定义器。在用户空问中 ， ALSA 驱动通常配合 ALsA 库使用 ， 库通过 ioctl 等接口调用 ALSA 驱动程序的设备节点。对于 AIJSA 驱动的调用，调用的是用户空间的 ALsA 库的接口，而不是直接调用 ALSA 驱动程序。ALSA 驱动程序的主要头文件是 include / sound ./ sound . h ，驱动核心数据结构和具体驱动的注册函数是 include / sound / core . h ，驱动程序 的核心实现是 Sound / core / sound . c 文件。 ALSA 驱动程序使用下面的函数注册控制和设备：int snd _ pcm _ new (struct snd _ card * card ， char * id ， int device ， int playback _ count ， int capture _ count ， struct snd _ pcm ** rpcm) ；int snd ctl _ add(struct snd _ card * card ， struct snd _ kcontrol * kcontro1) ；ALSA 音频驱动在内核进行 menuconfig 配置时 ， 配置选项为 “ Device Drivers ” “ Sound c ard support ” 一 “ Advanced Linux Sound Architecture ” 。子选项包含了 Generic sound devices( 通用声音设备 ) 、 ARM 体系结构支持，以及兼容 OSS 的几个选项。 ALsA 音频驱动配置对应的文件是sound / core / Kconfig 。 Android 没有直接使用 ALSA 驱动，可以基于 A-LSA 驱动和 ALSA 库实现 Android Audio 的硬件抽象层； ALSA 库调用内核的 ALSA 驱动， Audio 的硬件抽象层调用 ALSA 库。4.OSS音频驱动OSS（Open Sound System开放声音系统）是 linux 上最早出现的声卡驱动。OSS 由一套完整的内核驱动程序模块组成，可以为绝大多数声卡提供统一的编程接口。OSS 是字符设备，主设备号14，主要包括下面几种设备文件：1） /dev/sndstat它是声卡驱动程序提供的简单接口，它通常是一个只读文件，作用也只限于汇报声卡的当前状态。（用于检测声卡）2）/dev/dsp用于数字采样和数字录音的设备文件。对于音频编程很重要。实现模拟信号和数字信号的转换。3）/dev/audio类似于/dev/dsp，使用的是 mu-law 编码方式。4）/dev/mixer用于多个信号组合或者叠加在一起，对于不同的声卡来说，其混音器的作用可能各不相同。5）/dev/sequencer这个设备用来对声卡内建的波表合成器进行操作，或者对 MIDI 总线上的乐器进行控制。OSS 驱动所涉及的文件主要包括：kernel/include/linux/soundcard.hkernel/include/linux/sound.h 定义 OSS 驱动的次设备号和注册函数kernel/sound_core.c OSS核心实现部分5.V4l2视频驱动V4L2是V4L的升级版本，为linux下视频设备程序提供了一套接口规范。包括一套数据结构和底层V4L2驱动接口。V4L2提供了很多访问接口，你可以根据具体需要选择操作方法。需要注意的是，很少有驱动完全实现了所有的接口功能。所以在使用时需要参考驱动源码，或仔细阅读驱动提供者的使用说明。V4L2的主设备号是81，次设备号：0~255，这些次设备号里也有好几种设备（视频设备、Radio设备、Teletext、VBI）。V4L2的设备节点： /dev/videoX, /dev/vbiX and /dev/radioX Android 设备驱动（下）MTD 驱动Flash 驱动通常使用 MTD （memory technology device )，内存技术设备。MTD 的字符设备：/dev/mtdX主设备号 90.MTD 的块设备：/dev/block/mtdblockX主设备号 13.MTD 驱动源码drivers/mtd/mtdcore.c：MTD核心，定义MTD原始设备drivers/mtd/mtdchar.c：MTD字符设备drivers/mtd/mtdblock.c：MTD块设备MTD 驱动程序是 Linux 下专门为嵌入式环境开发的新一类驱动程序。Linux 下的 MTD 驱动程序接口被划分为用户模块和硬件模块：用户模块 提供从用户空间直接使用的接口：原始字符访问、原始块访问、FTL （Flash Transition Layer）和JFS（Journaled File System）。硬件模块 提供内存设备的物理访问，但不直接使用它们，二十通过上述的用户模块来访问。这些模块提供了闪存上读、写和擦除等操作的实现。蓝牙驱动 在 Linux 中，蓝牙设备驱动是网络设备，使用网络接口。Android 的蓝牙协议栈使用BlueZ实现来对GAP, SDP以及RFCOMM等应用规范的支持,并获得了SIG认证。由于Bluez使用GPL授权, 所以Android 框架通过D-BUS IPC来与bluez的用户空间代码交互以避免使用未经授权的代码。 蓝牙协议部分头文件：include/net/bluetooth/hci_core.hinclude/net/bluetooth/bluetooth.h蓝牙协议源代码文件：net/bluetooth/*蓝牙驱动程序部分的文件：drivers/bluetooth/*蓝牙的驱动程序一般都通过标准的HCI控制实现。但根据硬件接口和初始化流程的不同，又存在一些差别。这类初始化动作一般是一些晶振频率，波特率等基础设置。比如CSR的芯片一般通过BCSP协议完成最初的初始化配置，再激活标准HCI控制流程。对Linux来说，一旦bluez可以使用HCI与芯片建立起通信(一般是hciattach + hciconfig)，便可以利用其上的标准协议(SCO, L2CAP等)，与蓝牙通信，使其正常工作了。WLAN 设备驱动（Wi-Fi）（比较复杂我面会专门写个wifi分析）在linux中，Wlan设备属于网络设备，采用网络接口。Wlan在用户空间采用标准的socket接口进行控制。WiFi协议部分头文件：include/net/wireless.hWiFi协议部分源文件：net/wireless/*WiFi驱动程序部分：drivers/net/wireless/*

篇文章会先对照binder机制与linux的通信机制的区别，了解为什么android会另起炉灶

1）从性能的角度

数据拷贝次数binder驱动源码：Binder数据拷贝只需要一次，而管道、消息队列、Socket都需要2次，但共享内存方式一次内存拷贝都不需要；从性能角度看，Binder性能仅次于共享内存。

（2）从稳定性的角度

Binder是基于C/S架构的，简单解释下C/S架构，是指客户端(Client)和服务端(Server)组成的架构，Client端有什么需求，直接发送给Server端去完成，架构清晰明朗，Server端与Client端相对独立，稳定性较好；而共享内存实现方式复杂，没有客户与服务端之别， 需要充分考虑到访问临界资源的并发同步问题，否则可能会出现死锁等问题；从这稳定性角度看，Binder架构优越于共享内存。

仅仅从以上两点，各有优劣，还不足以支撑google去采用binder的IPC机制，那么更重要的原因是：

（3）从安全的角度

传统Linux IPC的接收方无法获得对方进程可靠的UID/PID，从而无法鉴别对方身份；而Android作为一个开放的开源体系，拥有非常多的开发平台，App来源甚广，因此手机的安全显得额外重要；对于普通用户，绝不希望从App商店下载偷窥隐射数据、后台造成手机耗电等等问题，传统Linux IPC无任何保护措施，完全由上层协议来确保。

Android为每个安装好的应用程序分配了自己的UID，故进程的UID是鉴别进程身份的重要标志，前面提到C/S架构，Android系统中对外只暴露Client端，Client端将任务发送给Server端，Server端会根据权限控制策略，判断UID/PID是否满足访问权限，目前权限控制很多时候是通过弹出权限询问对话框，让用户选择是否运行。Android 6.0，也称为Android M，在6.0之前的系统是在App第一次安装时，会将整个App所涉及的所有权限一次询问，只要留意看会发现很多App根本用不上通信录和短信，但在这一次性权限权限时会包含进去，让用户拒绝不得，因为拒绝后App无法正常使用，而一旦授权后，应用便可以胡作非为。

针对这个问题，google在Android M做了调整，不再是安装时一并询问所有权限，而是在App运行过程中，需要哪个权限再弹框询问用户是否给相应的权限，对权限做了更细地控制，让用户有了更多的可控性，但同时也带来了另一个用户诟病的地方，那也就是权限询问的弹框的次数大幅度增多。对于Android M平台上，有些App开发者可能会写出让手机异常频繁弹框的App，企图直到用户授权为止，这对用户来说是不能忍的，用户最后吐槽的可不光是App，还有Android系统以及手机厂商，有些用户可能就跳果粉了，这还需要广大Android开发者以及手机厂商共同努力，共同打造安全与体验俱佳的Android手机。

Android中权限控制策略有SELinux等多方面手段，下面列举从Binder的一个角度的权限控制：

Android源码的Binder权限是如何控制binder驱动源码？ -Gityuan的回答

传统IPC只能由用户在数据包里填入UID/PID；另外，可靠的身份标记只有由IPC机制本身在内核中添加。其次传统IPC访问接入点是开放的，无法建立私有通道。从安全角度，Binder的安全性更高。

说到这，可能有人要反驳，Android就算用了Binder架构，而现如今Android手机的各种流氓软件，不就是干着这种偷窥隐射，后台偷偷跑流量的事吗binder驱动源码？没错，确实存在，但这不能说Binder的安全性不好，因为Android系统仍然是掌握主控权，可以控制这类App的流氓行为，只是对于该采用何种策略来控制，在这方面android的确存在很多有待进步的空间，这也是google以及各大手机厂商一直努力改善的地方之一。在Android 6.0，google对于app的权限问题作为较多的努力，大大收紧的应用权限；另外，在Google举办的Android Bootcamp 2016大会中，google也表示在Android 7.0 （也叫Android N）的权限隐私方面会进一步加强加固，比如SELinux，Memory safe language(还在research中)等等，在今年的5月18日至5月20日，google将推出Android N。

（4）从语言层面的角度

大家多知道Linux是基于C语言(面向过程的语言)，而Android是基于Java语言(面向对象的语句)，而对于Binder恰恰也符合面向对象的思想，将进程间通信转化为通过对某个Binder对象的引用调用该对象的方法，而其独特之处在于Binder对象是一个可以跨进程引用的对象，它的实体位于一个进程中，而它的引用却遍布于系统的各个进程之中。可以从一个进程传给其它进程，让大家都能访问同一Server，就像将一个对象或引用赋值给另一个引用一样。Binder模糊了进程边界，淡化了进程间通信过程，整个系统仿佛运行于同一个面向对象的程序之中。从语言层面，Binder更适合基于面向对象语言的Android系统，对于Linux系统可能会有点“水土不服”。

另外，Binder是为Android这类系统而生，而并非Linux社区没有想到Binder IPC机制的存在，对于Linux社区的广大开发人员，我还是表示深深佩服，让世界有了如此精湛而美妙的开源系统。也并非Linux现有的IPC机制不够好，相反地，经过这么多优秀工程师的不断打磨，依然非常优秀，每种Linux的IPC机制都有存在的价值，同时在Android系统中也依然采用了大量Linux现有的IPC机制，根据每类IPC的原理特性，因时制宜，不同场景特性往往会采用其下最适宜的。比如在Android OS中的Zygote进程的IPC采用的是Socket（套接字）机制，Android中的Kill Process采用的signal（信号）机制等等。而Binder更多则用在system_server进程与上层App层的IPC交互。

(5) 从公司战略的角度

总所周知，Linux内核是开源的系统，所开放源代码许可协议GPL保护，该协议具有“病毒式感染”的能力，怎么理解这句话呢？受GPL保护的Linux Kernel是运行在内核空间，对于上层的任何类库、服务、应用等运行在用户空间，一旦进行SysCall（系统调用），调用到底层Kernel，那么也必须遵循GPL协议。

而Android 之父 Andy Rubin对于GPL显然是不能接受的，为此，Google巧妙地将GPL协议控制在内核空间，将用户空间的协议采用Apache-2.0协议（允许基于Android的开发商不向社区反馈源码），同时在GPL协议与Apache-2.0之间的Lib库中采用BSD证授权方法，有效隔断了GPL的传染性，仍有较大争议，但至少目前缓解Android，让GPL止步于内核空间，这是Google在GPL Linux下 开源与商业化共存的一个成功典范。

Android Binder是什么？binder属于一个驱动

Android中使用Binder进行进程间通讯。ViewBinder应该是一个Binder类，上次应用调用到这个类，这个类再调用底层相应的库。