安卓binder源码（安卓 binder）
本文目录一览：
- 1、大牛们是怎么阅读 Android 系统源码的
- 2、android binder 怎么用
- 3、篇文章会先对照binder机制与linux的通信机制的区别，了解为什么android会另起炉灶
- 4、安卓中的Binder架构是什么？为什么要提供Binder
- 5、安卓代码里添加驱动设备的应用层函数怎么写
大牛们是怎么阅读 Android 系统源码的
在Android系统源码上摸索4年，说说我的看法：
显然Eclipse不是阅读Android源码的好工具，不流畅，搜索低效，继承性关系/调用关系都无法有效查看。推荐Source Insight，在这个工具帮助下，你才可以驾驭巨大数量的Android 源码，你可以从容在Java，C++,C代码间遨游，你可以很快找到你需要的继承和调用关系。
顺便，现在东家是Linux+Samba+Windows的工作模式，Linux+Samba用于代码的同步/编译/管理，Windows做代码编辑。
你需要先理解下这个图：Application层就是一个个应用程序，很好理解。Framework提供一个java的运行环境以及对功能实现的封装，简单点说，你家装修总要留很多水电之类的接口吧！Runtime/ART是一个java虚拟机，因为Android上层不是java吗，需要再编译一次成为低级一点的语言识别。从Libraries那些名字也可以看出来，这里有很多高端大气库，它是功能实现区，多媒体编解码，浏览器渲染啊，数据库实现啦，很多很多。Kernel部分负责陪硬件大哥玩，你那些功能实现的区域最终都要调硬件吧，Kernel这家伙已经和硬件很熟了，你就直接通过它来和冷冰冰硬件大哥打交道吧！
好了，上面这些内容很好理解对不对，现在的问题是：当你拿到一份几G的源码，该从哪里开始呢？经过上面的前言的洗礼，你应该能够很好理解下面这部分了
-------------------------------------------------------------------------------------------------------------------
1.宏观上看，Android源码分为功能实现上的纵向，和功能拓展上的横向。在阅读源码时需要把握好着两个思路。
譬如你需要研究音频系统的实现原理，纵向：你需要从一个音乐的开始播放追踪，一路下来，你发现解码库的调用，共享内存的创建和使用，路由的切换，音频输入设备的开启，音频流的开始。
譬如你要看音频系统包括哪些内容，横向：通过Framework的接口，你会发现，音频系统主要包括：放音，录音，路由切换，音效处理等。
2.Android的功能模块绝大部分是C/S架构
你心里一定需要有这个层级关系，你需要思路清晰地找到Server的位置，它才是你需要攻破的城，上面的libraries是不是很亲切的样子？看完它长成啥样后，然后你才能发现HAL和Kernel一层层地剥离。
很多研究源码的同学兜兜转转，始终在JAVA层上，这是不科学的，要知道libraries才是它的精髓啊。
3.Android的底层是Linux Kernel。
在理解1,2后，还是需要对Kernel部分有个简单的理解，起码你要熟悉kernel的基础协议吧！你要能看懂电路图吧！你要熟悉设备的开启和关闭吧！你要熟悉调寄存器了吧！这方面的书太多了，我建议根据实例去阅读，它并不复杂，不需要一本本厚书来铺垫。
在libraries和kernel间，可能还会有个HAL的东东，其实它是对kernel层的封装，方便各个硬件的接口统一。这样，如果我换个硬件，不用跑了长得很复杂的libraries里面改了，kernel调试好了后，改改HAL就好了。
--------------------------------------------------------------------------------------------------------------------
好了，你现在是不是跃跃欲试准备去找个突破口准备进攻了，但是好像每个宝库的入口都挺难找了
我大概在三个月前阅读完Android UI系统的源码，这是Android最复杂的部分，我要简单说下过程。
我需要先找宝库入口，我要研究UI，首先要找什么和UI有亲戚关系吧！
View大神跳出来了，沿着它往下找找看，发现它在贴图在画各种形状，但是它在哪里画呢，马良也要纸吧？
很明显它就是某个宝藏，但是世人只是向我们描述了它有多美，却无人知在哪里？我们需要找一张地图罗。
开发Android的同学逃不掉Activity吧！它有个setcontentview的方法，从这个名字看好像它是把view和activity结合的地方。赶紧看它的实现和被调用。，然后我们就发现了Window，ViewRoot和WindowManager的身影，沿着WM和WMS我们就惊喜会发现了Surface，以及draw的函数，它居然在一个DeCorView上画东西哈。借助Source Insight， UI Java层的横向静态图呼之欲出了。
完成这个静态UML，我觉得我可以开始功能实现上追踪了，这部分主要是C++的代码（这也是我坚定劝阻的放弃Eclipse的原因），我沿着draw函数，看到了各个层级的关系，SurfaceSession的控制和事务处理，SharedBuffer读写控制，彪悍的SurfaceFlinger主宰一切，OpenGL ES的神笔马良。FrameBuffer和FrameBufferDevice的图像输出，LCD设备打开后，开始接收FBD发过来的一帧帧图像，神奇吧。
android binder 怎么用
实现一个binder通信实例，需要经过以下步骤：
（1）获得ServiceManager的对象引用
（2）向ServiceManager注册新的Service
（3）在Client中通过ServiceManager获得Service对象引用
（3）在Client中发送请求，由Service返回结果。
下面看具体的代码如何实现。
3.1 libmyservice代码实现
（1）新建目录frameworks/base/myservice/libservice，进入该目录
view plain
$ cd frameworks/base
$ mkdir myservice
$ cd myservice
$ mkdir libmyservice
$ cd libmyservice
（2）编写libmyservice/myservic.h文件
view plain
#include utils/threads.h
#include utils/RefBase.h
#include binder/IInterface.h
#include binder/BpBinder.h
#include binder/Parcel.h
namespace android {
class MyService : public BBinder
{
mutable Mutex mLock;
int32_t mNextConnId;
public:
static int instantiate();
MyService();
virtual ~MyService();
virtual status_t onTransact(uint32_t, const Parcel, Parcel*, uint32_t);
};
}; //namespace
(2)编写libservice/myservice.cpp文件
view plain
#include "myservice.h"
#include binder/IServiceManager.h
#include binder/IPCThreadState.h
namespace android {
static struct sigaction oldact;
static pthread_key_t sigbuskey;
int MyService::instantiate()
{
LOGE("MyService instantiate");
// defaultServiceManager ()获得ServiceManager的对象引用，addService()可向ServiceManager注册新的服务
int r = defaultServiceManager()-addService(String16("android.myservice"), new MyService());
LOGE("MyService r = %d/n", r);
return r;
}
MyService::MyService()
{
LOGV("MyService created");
mNextConnId = 1;
pthread_key_create(sigbuskey, NULL);
}
MyService::~MyService()
{
pthread_key_delete(sigbuskey);
LOGV("MyService destroyed");
}
// 每个系统服务都继承自BBinder类，都应重写BBinder的onTransact虚函数。当用户发送请求到达Service时，系统框架会调用Service的onTransact函数，该函数分析接收到的数据包，调用相应的接口函数处理请求
status_t MyService::onTransact(uint32_t code, const Parcel data, Parcel* reply, uint32_t flags)
{
switch(code)
{
case 0: {
pid_t pid = data.readInt32();
int num = data.readInt32();
num = num + 100;
reply-writeInt32(num);
return NO_ERROR;
}
break;
default:
return BBinder::onTransact(code, data, reply, flags);
}
}
}; //namespace
（3）编写libservice/Android.mk文件
view plain
# File: Android.mk
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_SRC_FILES := myservice.cpp
LOCAL_C_INCLUDES := $(JNI_H_INCLUDE)
LOCAL_SHARED_LIBRARIES := libutils libbinder
LOCAL_MODULE_TAGS := optional
LOCAL_PRELINK_MODULE := false
LOCAL_MODULE := libmyservice
include $(BUILD_SHARED_LIBRARY)
（4）编译libmyservice.so动态库
在android源码主目录下
view plain
$ source build/envsetup.sh
including device/htc/passion/vendorsetup.sh
including device/samsung/crespo4g/vendorsetup.sh
including device/samsung/crespo/vendorsetup.sh
$ mmm frameworks/base/myservice/libmyservice/
编译成功后生成文件：out/target/product/generic/system/lib/libmyservice.so
篇文章会先对照binder机制与linux的通信机制的区别，了解为什么android会另起炉灶
1）从性能的角度
数据拷贝次数：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权限是如何控制？ -Gityuan的回答
传统IPC只能由用户在数据包里填入UID/PID；另外，可靠的身份标记只有由IPC机制本身在内核中添加。其次传统IPC访问接入点是开放的，无法建立私有通道。从安全角度，Binder的安全性更高。
说到这，可能有人要反驳，Android就算用了Binder架构，而现如今Android手机的各种流氓软件，不就是干着这种偷窥隐射，后台偷偷跑流量的事吗？没错，确实存在，但这不能说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下 开源与商业化共存的一个成功典范。
安卓中的Binder架构是什么？为什么要提供Binder
1）从性能的角度数据拷贝次数：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权限是如何控制？ -Gityuan的回答传统IPC只能由用户在数据包里填入UID/PID；另外，可靠的身份标记只有由IPC机制本身在内核中添加。其次传统IPC访问接入点是开放的，无法建立私有通道。从安全角度，Binder的安全性更高。说到这，可能有人要反驳，Android就算用了Binder架构，而现如今Android手机的各种流氓软件，不就是干着这种偷窥隐射，后台偷偷跑流量的事吗？没错，确实存在，但这不能说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 驱动是离不开 Linux 驱动的。Android 内核采用的是 Linux2.6 内核 （最近Linux 3.3 已经包含了一些 Android 代码）。但 Android 并没有完全照搬 Linux 系统内核，除了对Linux 进行部分修正，还增加了不少内容。android 驱动 主要分两种类型：Android 专用驱动 和 Android 使用的设备驱动（linux）。Android 专有驱动程序：1）Android Ashmem 匿名共享内存； 为用户空间程序提供分配内存的机制，为进程间提供大块共享内存，同时为内核提供回收和管理这个内存。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为用户空间程序提供分配内存的机制，为进程间提供大块共享内存，同时为内核提供回收和管理这个内存。设备节点：/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/*
