1、蓝牙核心技术了解（蓝牙协议、架构、硬件和软件笔记） - 推酷
1、蓝牙核心技术了解（蓝牙协议、架构、硬件和软件笔记）
声明： 这篇文章是楼主beautifulzzzz学习网上关于蓝牙的相关知识的笔记，其中比较多的受益于xubin341719的蓝牙系列文章，同时还有其他网上作者的资料。由于有些文章只做参考或统计不足，如涉及版权请在下面留言~
。同时我也在博客分类中新建一个蓝牙通信分类，用来研究分享蓝牙相关技术。
主要参考资料的来源：
xubin341719[下面是该前辈的BT系列文章]
下载连接：
&（基本涵盖所有蓝牙协议）、
（三蓝牙版本的核心协议v2.1\v3.0\v4.0）、
（蓝牙协议相关初学者必读，开发者参考）
有道笔记分享链接：/share/?id=950d00cefa9b7fd3c559eec&type=note
下面是摘抄笔记内容：
蓝牙，是一种支持设备短距离通信（一般10m内）的
技术。能在包括移动电话、PDA、无线耳机、
、相关外设等众多设备之间进行无线信息交换。利用“蓝牙”技术，能够有效地简化
终端设备之间的通信，也能够成功地简化设备与因特网Internet之间的通信，从而
变得更加迅速高效，为
拓宽道路。蓝牙采用
结构以及快跳频和短包技术，支持点对点及点对多点通信，工作在全球通用的2.4GHz ISM（即工业、科学、医学）
。其数据速率为1Mbps。采用
传输方案实现
Bluetooth的系统构成
1、无线射频单元(Radio)： 负责数据和语音的发送和接收，特点是短距离、低功耗。蓝牙天线一般体积小、重量轻，属于微带天线。
2、基带或链路控制单元(LinkController)： 进行射频信号与数字或语音信号的相互转化，实现基带协议和其它的底层连接规程。
3、链路管理单元(LinkManager)： 负责管理蓝牙设备之间的通信，实现链路的建立、验证、链路配置等操作。
4、蓝牙软件协议实现：如上图紫色部分，这个后面我们做详细说明。
低耗电蓝牙相关规范
（二）蓝牙协议组成
2.1 蓝牙协议架构
蓝牙协议体系中的协议按SIG的关注程度分为四层：
1.核心协议：BaseBand、LMP、L2CAP、SDP；
2.电缆替代协议：RFCOMM；
3.电话传送控制协议：TCS-Binary、AT命令集；
4.选用协议：PPP、UDP/TCP/IP、OBEX、WAP、vCard、vCal、IrMC、WAE。
除上述协议层外，规范还定义了主机控制器接口（HCI），它为基带控制器、连接管理器、硬件状态和控制寄存器提供命令接口。在图1中，HCI位于L2CAP的下层，但HCI也可位于L2CAP上层。
蓝牙核心协议由SIG制定的蓝牙专用协议组成。绝大部分蓝牙设备都需要核心协议（加上无线部分），而其他协议则根据应用的需要而定。总之， 电缆替代协议、电话控制协议和被采用的协议在核心协议基础上构成了面向应用的协议 。&
蓝牙协议栈允许采用多种方法，包括&RFCOMM&和&Object Exchange&（OBEX&）， 在设备之间发送和接收文件。如果想发送和接收流数据（而且想采用传统的串口应用程序，并给它加上蓝牙支持），那么&RFCOMM&更好。反过来，如果想发送对象数据以及关于负载的上下文和元数据，则&OBEX&最好。
蓝牙应用程序活动图，如下：
2.1.1 &串口仿真RFCOMM介绍
找到服务，RFCOMM是通过不同的频道（channel）来提供不同的Profile的，所以需要找到要用的服务在设备上的哪个频道上，这是通过同一个软件包里的sdptool来完成的，就是SDP，服务发现协议
2.2 蓝牙profile
2.2.1 蓝牙profile概述
从3.0版本开始（据说2.1也是支持的？TBD），蓝牙才开始支持BluetoothProfile。BluetoothProfile是蓝牙设备间数据通信的无线接口规范。想要使用蓝牙无线技术,设备必须能够翻译特定蓝牙配置文件,配置文件定义了可能的应用.
蓝牙配置文件表达了一般行为,蓝牙设备可以通过这些行为与其他设备进行通信.
蓝牙技术定义了广泛的配置文件,描述了许多不同类型的使用安全.按蓝牙规格中提供的指导,开发商可创建应用程序以用来与其他符合蓝牙规格的设备协同工作.在最低限度下,各配置文件规格应包含下列主题的相关信息.
① 与其他配置文件的相关性
② 建议的用户界面格式
③ 配置文件使用的蓝牙协议堆栈的特定部分.
为执行其任务, 每个配置文件都使用堆栈各层上的特定选项和参数 .若需要,也可包括必需的服务记录概要。ProfilesAPI层则分别对Audio、Data、Control等提供了不同的模块。目前已规范有四大类、十三种协议规格。
Bluetooth的一个很重要特性，就是所有的Bluetooth产品都无须实现全部的Bluetooth规范。为了更容易的保持Bluetooth设备之间的兼容，Bluetooth规范中定义了Profile。
Profile定义了设备如何实现一种连接或者应用，你可以把Profile理解为连接层或者应用层协议。
? 常用的profile介绍请参考“
”，几种种最基本的配置文件为：
1.通用访问配置文件(Generic Access Profile, GAP)
GAP是所有其他配置文件的基础,它定义了在蓝牙设备间建立基带链路的通用方法.除此之外,GAP还定义了下列内容:
① 必须在所有蓝牙设备中实施的功能
② 发现和链接设备的通用步骤
③ 基本用户界面术语.
GAP确保了应用程序和设备间的高度互操作性,还允许开发人员利用现有的定义更加容易地定义新的配置文件.GAP处理未连接的两个设备间的发现和建立连接过程.此配置文件定义了一些通用的操作,这些操作可供引用GAP的配置文件,以及实施多个配置文件的设备使用.GAP确保了两个蓝牙设备可通过蓝牙技术交换信息,以发现彼此支持的应用程序.不符合任何其他蓝牙配置文件的蓝牙设备必须与GAP符合以确保基本的互操作性和共存.
2.服务发现应用配置文件(Service Discovery Application Profile, SDAP)
SDAP描述了应用程序如何使用SDP发现远程设备上的服务.由于GAP的要求,任何蓝牙设备都应能够连接至其他蓝牙设备.基于此,SDAP要求任何应用程序都应当能够发现它要连接的其他蓝牙设备上的可用服务.此配置文件可承担搜索已知和特定服务及一般的任务.SDAP涉及了称为“服务发现用户应用程序”的一个应用程序,这是蓝牙设备查找服务所必需的.此应用程序可与向/从其他蓝牙设备发送/接收服务查询的SDP相接.SDAP依赖于GAP,并可以重新使用部分GAP.
3.串行端口配置文件(Serial Port Profile, SPP)
SPP定义了如何设置虚拟串行端口及如何连接两个蓝牙设备.SPP基于ETSI TS 07.10规格,使用RFCOMM协议提供串行商品仿真.SPP提供了以无线方式替代现有的RS-232串行通信应用程序和控制信号的方法.SPP为DUN,FAX,HSP和LAN配置文件提供了基础.此配置文件可以支持最高128kb/s的数据率.SPP依赖于GAP.
4.通用对象交换配置文件(Generic Object Exchange Profile, GOEP)
GOEP可用于将对象从一个设备传输到另一个设备.对象可以是任意的.如:图片,文档,名片等.此配置文件定义了两个角色:提供拉提或推送对象位置的服务器及启动操作的客户端.使用GOEP的应用程序假定链路和信道已按GAP的定义建立.GOEP依赖于串行端口配置文件.GOEP为使用OBEX协议的其他配置文件提供了通用蓝图,并为设备定义了客户端和服务器角色.对于所有的OBEX事务.GOEP规定应由客户端启动所有事务.但是此配置文件并没有描述应用程序就如何定义要交换的对象或如何实施交换.这些细节留给属于GOEP的配置文件.即OPP,FTP和SYNC去完成.通常使用此配置文件的蓝牙设备为笔记本电脑,PDA,手机及智能电话.
蓝牙1.1版本规范所有蓝牙设备的最小实现必须支持通用访问配置文件,服务发现应用配置文件和串行端口配置文件.
在两台电脑或者Labtop之间就可以建立这种连接，如下图所示：&
SPP是基于RFCOMM的，spp&协议处于rfcomm的上层，spp的应用需走rfcomm层。如果你使用RFCOMM能够实现，那么也就不需要使用SPP，而却速度还会比SPP来做快，因为省略了采用profile的一些数据包头等。不过，还是推荐采用SPP来做，兼容性有保证，这也是为什么蓝牙本质上数据和语音的传送却出现HFP，HSP，SPP，OPP等诸多具体应用profile的原因。
2.2.2 蓝牙profile框架
每个attribute属性被UUID（通用唯一标识符）唯一标识 ，UUID是标准128-bit格式的ID用来唯一标识信息。attributes 被 ATT 格式化characteristics和services形式进行传送。
特征（Characteristics）
— 一个characteristics包含一个单独的value值和0 –n个用来描述characteristic 值（value）的descriptors。一个characteristics可以被认为是一种类型的，类似于一个类。
描述符(descriptor)
—descriptor是被定义的attributes，用来描述一个characteristic的值。例如，一个descriptor可以指定一个人类可读的描述中，在可接受的范围里characteristic值，或者是测量单位，用来明确characteristic的值。
服务（service）
—service是characteristic的集合。例如，你可以有一个所谓的“Heart RateMonitor”service，其中包括characteristic，如“heart rate measurement ”。你可以在&
找到关于一系列基于GATT的profile和service。
如上图所示： 蓝牙设备可以包括多个Profile，一个Profile中有多个Service，一个Service中有多个Characteristic，一个Characteristic中包括一个value和多个Descriptor。
2.3 蓝牙4.0和4.1&
? 蓝牙4.0实际是个三位一体的蓝牙技术，它将传统蓝牙、低功耗蓝牙和高速蓝牙技术融合在一起，这三个规格可以组合或者单独使用。
也就是说 BLE是蓝牙4.0增加的，之前没有？（TBD）
蓝牙4.0专门面向对成本和功耗都有较高要求的无线方案，其主打特性就是省电、省电、省电。极低的运行和待机功耗使得一粒纽扣电池甚至可连续工作一年之久。它有低功耗、经典、高速三种协议模式。其中：高速蓝牙主攻数据交换与传输；经典蓝牙则以信息沟通、设备连接为重点；低功耗蓝牙以不需占用太多带宽的设备连接为主。这三种协议规范能够互相组合搭配，从而适应更广泛的应用模式。正因为有了三种可以互相组合搭配的协议，蓝牙4.0因此成为唯一一个综合协议规范。它有着极低的运行和待机功耗。此外，低成本和跨厂商互操作性，3毫秒低延迟、AES-128加密等诸多特色，可以用于计步器、心律监视器、智能仪表、传感器物联网等众多领域，大大扩展蓝牙技术的应用范围。
蓝牙4.1主打IOT（Internet Of Things全联网），最新的蓝牙4.1标准是个很有前途的技术，其智能、低功耗、高传输速度、连接简单的特性将适合用在许多新兴设备上。
蓝牙4.1设备可以同时作为发射方和接受方,并且可以连接到多个设备上。举个例子，智能手表可以作为发射方向手机发射身体健康指数，同时作为接受方连接到蓝牙耳机、手环或其他设备上。蓝牙4.1使得批量数据可以以更高的速率传输，当然这并不意味着可以用蓝牙高速传输流媒体视频，这一改进的主要针对的还是刚刚兴起的可穿戴设备。例如已经比较常见的健康手环，其发送出的数据流并不大，通过蓝牙4.1能够更快速地将跑步、游泳、骑车过程中收集到。 因为新标准加入了对IPv6专用通道联机的支持，通过IPv6连接到网络，实现与Wi-Fi相同的功能，解决可穿戴设备上网不易的问题。
蓝牙4.0和蓝牙4.1的比较
2.3.1 蓝牙4.0低功耗(BLE)
① 低功耗蓝牙Bluetooth Low Energy（BLE）是蓝牙4.0增加的。（？TBD） ，苹果系列都支持4.0.
② Android4.3（API级别18）引入内置平台支持BLE的central角色，同时提供API和app应用程序用来发现设备，查询服务，和读/写characteristics。与传统蓝牙（
）不同，蓝牙低功耗（BLE）的目的是提供更显著的低功耗。这使得Android应用程序可以和具有低功耗的要求BLE设备，如接近传感器，心脏速率监视器，健身设备等进行通信。
③ BLE低功耗蓝牙软件有2个主要组成： OSAL操作系统抽象层和 HAL硬件抽象层，多个Task任务和事件在OSAL管理下工作，而每个任务和事件又包括3个组成：BLE 协议栈，profiles和应用程序。
BLE蓝牙协议栈结构
附图1 BLE蓝牙协议栈结构图
分为两部分：控制器和主机。对于4.0以前的蓝牙，这两部分是分开的。所有profile（姑且称为剧本吧，用来定义设备或组件的角色）和应用都建构在GAP或GATT之上。下面由结构图的底层组件开始介绍。&
附图 2 BLE低功耗蓝牙系统架构图，图中的Task用附图1BLE蓝牙协议栈结构图来描述
通用属性规范（GATT）—GATTprofile是一个通用规范用于在BLE链路发送和接收被称为“属性（attributes）”的数据片。目前所有的低功耗应用 profile都是基于GATT。
蓝牙SIG定义了许多profile用于低功耗设备。Profile（配置文件）是一个规范，规范了设备如何工作在一个特定的应用场景。注意：一个设备可以实现多个profile。例如，一个设备可以包含一个心脏监测仪和电池电平检测器。
主从机连接建立过程:
2.3.2 蓝牙4.0(BLE)主从通信透传模块
低功耗蓝牙模块主透传协议是针对低功耗蓝牙模块从透传协议设计的，通过本协议模块可替代手机设备与从透传协议模块连接，实现透传功能或直驱控制功能。此协议模块可用作从透传协议模块开发过程中的辅助工具。
BLE主透传协议模块（以下简称MTTM）可以工作在透传模式（TTM）或指令模式（CM）。
MTTM上电启动后，处于待机模式（SBM），此时处于空闲状态，无睡眠，需要用户通过AT指令控制模块连接从设备。在成功与从设备建立链接后，MTTM会自动查找从设备的透传通道，如果从设备属于BLE从透传协议模块（以下简称STTM），MTTM默认进入透传模式，否则默认进入指令模式。
透传模式下，用户CPU可以通过模块的通用串口与STTM进行双向通讯。 从MTTM串口输入的数据将转发到STTM，并从STTM的串口输出；从STTM输入的数据将转发到MTTM，并从MTTM的串口输出，从而实现透明传输功能，用户数据的具体含义由上层应用程序自行定义。&
透传中数据的格式也是profile，或蓝牙标准profile或自定义simple profile。基本结构依然是：
1、profile &
profile可以理解为一种规范，一个标准的通信协议，它存在于从机中。蓝牙组织规定了一些标准的profile，例如 HID OVER GATT ，防丢器 ，心率计等。每个profile中会包含多个service，每个service代表从机的一种能力。
2、service
service可以理解为一个服务，在ble从机中，通过有多个服务，例如电量信息服务、系统信息服务等，每个service中又包含多个characteristic特征值。每个具体的characteristic特征值才是ble通信的主题。比如当前的电量是80%，所以会通过电量的characteristic特征值存在从机的profile里，这样主机就可以通过这个characteristic来读取80%这个数据
3、characteristic
characteristic特征值，ble主从机的通信均是通过characteristic来实现，可以 理解为一个标签，通过这个标签可以获取或者写入想要的内容。
UUID，统一识别码，我们刚才提到的service和characteristic，都需要一个唯一的uuid来标识
每个从机都会有一个叫做profile的东西存在，不管是上面的自定义的simpleprofile，还是标准的防丢器profile，他们都是由一些列service组成，然后每个service又包含了多个characteristic，主机和从机之间的通信，均是通过characteristic来实现。
实际产品中，
每个蓝牙4.0的设备都是通过服务和特征来展示自己的， 服务和特征都是用UUID来唯一标识的
。一个设备必然包含一个或多个服务，每个服务下面又包含若干个特征。特征是与外界交互的最小单位。
蓝牙设备硬件厂商通常都会提供他们的设备里面各个服务(service)和特征(characteristics)的功能，比如哪些是用来交互(读写)，哪些可获取模块信息(只读)等 。
比如说，一台蓝牙4.0设备，用特征A来描述自己的出厂信息，用特征B来与收发数据等。
4.0中profile的存在是干嘛用的呢，只是一种组织形式存在？
服务和特征都是用UUID来唯一标识的，UUID的概念如果不清楚请自行google,国际蓝牙组织为一些很典型的设备(比如测量心跳和血压的设备)规定了标准的service UUID(特征的UUID比较多，这里就不列举了)
4.0 BLE数据传输可参考下述系列：
（三）Android Bluetooth 架构
1、面向库的架构视图
2、面向进程的架构视图
iOS 有两个框架支持蓝牙与外设连接。
一个是 ExternalAccessory。从ios3.0就开始支持，也是在iphone4s出来之前用的比较多的一种模式，但是它有个不好的地方，External Accessory需要拿到苹果公司的MFI认证。
另一个框架则是本文要介绍的CoreBluetooth，在蓝牙4.0出来之后（注意，硬件上要4s以上，系统要ios6以上才能支持4.0），苹果开放了BLE通道，专门用于与BLE设备通讯（因为它的API都是基于BLE的）。这个不需要MFI，并且现在很多蓝牙设备都支持4.0,所以也是在IOS比较推荐的一种开发方法。现 CoreBluetooth 在的开发几乎全部基于该框架，本节只介绍 CoreBluetooth。
1，CoreBluetooth介绍
CoreBluetooth框架的核心其实是两个东西，peripheral和central, 可以理解成外设和中心。对应他们分别有一组相关的API和类，如下图所示:
如果你要编程的设备是手机的central，那么你大部分用到peripheral API。反之亦然，设备是peripheral，iphone手机是central,所以将大部分使用central API。使用peripheral编程的例子也有很多，比如像用一个ipad和一个iphone通讯，ipad可以认为是central，iphone端是peripheral,这种情况下在iphone端就要使用上图右边部分的类来开发了。
作为一个中心（central）要实现完整的通讯，一般要经过这样几个步骤：
（1）建立中心角色—
（2）扫描外设（discover）（通过接收从设备广播来扫描、发现设备，获得peripheral ID）—& & &&
a, 如果数据中已经和某些蓝牙设备绑定，可以使用BluetoothAdapter.getBondedDevices();方法获得已经绑定的蓝牙设备列表。通过指定特定的peripheral的UUID,central只会discover这个特定的设备。
b, 搜索周围的蓝牙设备受用BluetoothAdapter.startDiscovery()方法
c, 搜索到的蓝牙设备都是通过广播返回，so..。需要注册广播接收器来获得已经搜索到的蓝牙设备
（3）连接外设(connect)（根据peripheral ID连接指定的外设）—
（4）扫描外设中的服务和特征(discover)（一个设备里的服务和特征往往比较多，一般会在发现服务和特征的回调里通过service、characteristic UUID去匹配我们关心那些）—
（5）与外设做数据交互(explore and interact)—
（6）断开连接(disconnect)。
2,&设备ID描述DID
每个与苹果设备兼容的蓝牙接入都必须：支持蓝牙设备ID描述，1.3版本或者更高；使用蓝牙SIG分配的Assigned Numbers文档中的公司标识作为他的Vendor ID值，也就是VID，如果生产商没有蓝牙SIG公司标识，那么蓝牙HID描述接入可能会使用USB Implementers Forum分配的VID；使用他的VID值来标识最终的产品生产商；使用版本值来唯一标识软件的版本；使用ProductID值唯一标识产品。Device ID描述使得苹果产品能够识别远程的蓝牙接入，该信息可以用来在与远程接入交互的时候连接蓝牙描述间的交替互操作。因此Device ID中的信息记录非常重要。
理想情况下，这两个设备应该有不同的产品ID。但是，当他们拥有完全相同的硬件、软件和特性的时候拥有相同的ProductID也是可以允许的。如果他们有任何的不同，就都应该有不同的Product ID。
3，IOS的蓝牙低功耗
蓝牙4.0标准引入了蓝牙低功耗，一种针对有限电池资源的蓝牙接入的无线技术。如果支持蓝牙低功耗的话，接入点需要支持下面的这些特性。（这里更多的是蓝牙芯片商要做的事情）
蓝牙接入需要实现蓝牙4.0标准中定义的外围角色
蓝牙接入需要在所有三个广告通道中针对每个广告事件进行广告
蓝牙接入需要使用如下广告PDU中的一个：ADV_IND；ADV_NOCONN_IND；ADV_SCAN_IND。其中ADV_DIRECT_IND不推荐使用。
由蓝牙接入发送的广告信息应该至少包含蓝牙4.0标准中包含的如下信息：Flags；TX Power Level；Local Name；Services。如果需要降低电量消耗或者并不是所有的广告数据都适合放入到广告PDU中的时候，接入点可能将Local Name和TX Power Level数据方知道SCAN_RSP PDU中。需要注意的是根据它的状态，苹果产品可能不会总是执行激活扫描。主要的服务应该总是放在广告PDU中进行广告。次要的服务不应该进行广告。对于接入点不重要的服务信息可能会因为广告PDU中的空间不足而被忽略。广告数据和SCAN_RSP PDU中的扫描响应数据应该遵循蓝牙4.0标准中的格式。
蓝牙接入的广告间隔应该慎重考虑，因为他会影响到发现和连接的性能。对于低功耗的接入，电池资源也应该被考虑在内。为了能够被苹果产品发现，蓝牙接入应该首先使用推荐的广告间隔20ms，并持续至少30秒。如果在这30秒内没有被发现，那么接入点可能会选择节省电池电量然后增加广告间隔，苹果推荐使用如下依次延长的事件间隔来发现蓝牙接入点：645 ms；768 ms；961 ms；1065 ms；1294 ms
蓝牙接入负责用来LE连接的连接参数。接入点需要请求合适的连接参数来在合适的时候发送一个L2CAP连接参数跟新请求。如果他没有符合如下规则，那么连接参数请求可能会被拒绝：Interval Max * (Slave Latency + 1) ≤ 2 seconds；Interval Min ≥ 20 ms；Interval Min + 20 ms ≤ Interval Max；Slave Latency ≤ 4；connSupervisionTimeout ≤ 6 seconds以及Interval Max * (Slave Latency + 1) * 3 & connSupervisionTimeout。苹果设备不会读取或者使用Peripheral Preferred Connection Parameters特性中的参数。
蓝牙接入应该在任何情况下都能够满足Resovable Private Address。因为私隐方面的考虑，苹果设备将会使用蓝牙4.0标准中定义的随机设备地址。
蓝牙接入不需要请求特殊的授权，如配对、认证或加密等来发现服务和特性。只有在获取特性值或者描述值的时候可能会需要特殊的授权。9
蓝牙接入不应该请求配对。如果处于安全考虑，接入点需要与Central建立绑定关系，外围可以使用Insufficient Authentication错误码在必要的时候拒绝ATT请求。因此苹果设备可能会需要按照既定的安流程程来执行过程。配对可能会需要基于苹果产品的用户认证。
通用接入描述服务：蓝牙接入应该实现按照蓝牙标准4.0中的Device Name特性
通用属性描述服务：只有当接入有能力在生命周期内更改他的服务的时候，该接入点才需要实现Service Changed特性。苹果产品可以使用Service Changed服务特性来决定它是否可以使用之前读取的或者缓存的来自设备的信息。
设备信息服务：蓝牙接入应该实现设备信息服务。服务的UUID不应该包含在广告数据当中。如下的特性需要被支持：Manufacturer Name String；Model Number String；Firmware Revision String；Software Revision String
4，IOS APP开发 的蓝牙操纵API
手机APP要想获得蓝牙设备的一些额外的信息如电量或者操作蓝牙设备，必须通过IOS API。那么IOS底层必然有某种方式来与蓝牙设备交互。 那么电量通过什么来读写呢？自定义 service characteristic？
任何免提的蓝牙耳机都可以在iOS设备的状态栏中显示一个用来标识他电池电量的图标。这个特性被所有的iOS设备所支持，包括iPhone、iPod和iPad。耳机的蓝牙知识通过两个iOS蓝牙HFP AT命令：HFP Command AT+XAPL
HFP命令AT+XAPL
描述：允许通过耳机自定义AT命令
发起者：耳机
格式：AT+XAPL=[vendorID]-[productID]-[version],[features]
vendorID: 标识生产商的vendor ID的十六进制表示，但是没有0x前缀
productID: 标识生产生的product ID的十六进制表示，但是没有0x前缀
version: 软件的版本
features: 用10进制标识的位标识:
1 = 耳机支持电池电量报告
2 = 耳机暂停或者正在充电
其他值保留
例子: AT+XAPL=ABCD-
响应: +XAPL=iPhone,[features]
HFP命令AT+IPHONEACCEV
描述：报告耳机的状态变更
发起者：耳机
格式：AT+IPHONEACCEV=[Number of key/value pairs ],[key1 ],[val1 ],[key2 ],[val2 ],...
Number of key/value pairs : 接下来参数的数量
key: 被报告状态变化的类型
1 = 电量等级
2 = 暂停状态
val: 更改的值
Battery events:0-9之间数字的字符串 A string value between '0' and '9'.
Dock state: 0 = undocked, 1 = docked.
Example: AT+IPHONEACCEV=1,1,3
（五）硬件接口
一般蓝牙芯片通过UART、USB、SDIO、I2S、PcCard和主控芯片通信。如下图所示，通过UART和主控芯片通信。
：大家有好的的蓝牙通信的资料链接在下面留言分享下~多谢?(^?^*)&
已发表评论数()
已收藏到推刊！
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
排版有问题
没有分页内容
视频无法显示
图片无法显示Android开发之Android体系架构介绍
在Android中，整个框架由应用、应用框架、原生库、Android实时库、硬件抽象层、Linux内核等若干部分组成。
其中最核心的Android虚拟机部分也已经开放。对开发者而言，如果期望在深度定制的基础上开发出差异化、高度竞争力的产品，需要在应用框架、原生库、硬件抽象层、Linux内核等方面有较深入的理解。图1显示了Android的体系架构。
图1 Android体系架构
1、核心服务
所谓Android的核心服务主要包括熵服务（Entropy Service）、电源管理器（Power Manager）、Activity管理器（Activity Manager）、通话寄存器（Telephony Registry）、包管理器（Package Manager）、账户管理器（Account Manager）、内容管理器（Content Manager）、内容提供器（System Content Providers）、电池服务（Battery Service）、光线服务（Lights Service）、振动服务（Vibrator Service）、闹钟管理器（Alarm Manager）、看门狗（Init Watchdog）、窗口管理器（Window Manager）、蓝牙服务（Bluetooth Service）等。这些服务和应用程序密切相关，但通常应用程序不能直接接入核心服务。早期版本中的硬件服务（Hardware Service）和传感器服务（Sensor Service）已经被移除，光线服务和振动服务在核心服务通过系统服务器来启动。系统服务器的实现位于SystemServer.java中。
2、原生服务
在Android中，上层的应用是基于Java开发的，但是框架层的服务很多是基于C/C++的，为了说明的方便，在本书中，将基于C/C++的服务称为原生服务。目前，Android提供的和多媒体相关的原生服务主要有渲染管理器（Surface Flinger）、音频管理器（Audio Flinger）、Camera服务（Camera Service）、媒体播放服务（MediaPlayer Service）、音频策略服务（Audio Policy Service）等。
Android的原生库主要是基于C\C++实现的一些原生组件，包括C库Bionic、浏览器引擎Webkit、多媒体引擎OpenCORE、SQL数据库SQLite、3D渲染引擎OpenGL ES、位图和字体矢量渲染引擎FreeType、2D图像渲染引擎SGL（Skia Graphics Library）、互联网安全协议SSL和TSL等。
4、运行时组件
在Android中，比较重要的Java组件包括Java核心库、Dalvik虚拟机等，两者一起构成了Android的应用环境基础。
5、硬件抽象层
在Android中，考虑到并非所有组件都具有标准的Linux内核驱动接口，而且基于GPL V20许可的Linux驱动内核会暴露出专用IP核的细节，另外Android对硬件驱动也有些特殊的需求。为了屏蔽底层实现的细节，实现硬件逻辑和硬件接口的分离，Google定义了一个硬件抽象层的接口HAL（Hardware Abstraction Layer）。
HAL在为商业开发带来便利的同时，对系统的性能略有阻碍，更多的层次会导致系统变慢，在桌面Ubunut Linux中，为了加快系统的启动速度，就彻底抛弃了HAL的理念。
6、Linux内核
Android平台是基于Linxu内核搭建的，Linux内核的优势在于大内存管理、进程管理、基于权限的安全模型、统一的驱动模型、共享库支持、代码开源等。
Android平台在设计过程中，针对移动终端资源有限的特点，对Linux进行了一定程度的裁剪：砍掉了原生的窗口系统、去除了对GNU Libc的支持（引入了更高效、针对嵌入式优化过的Bionic）、裁剪掉了一些标准Linux工具的部分特性等。
另外Android针对移动终端的特点还对Linux内核在闹钟（Alarm）、Low Memory Killer、Ashmem、内核调试（Kernel Debugger）、进程间通信（Binder）、日志（Logger）、电源管理（Power Management）等方面做了大量的优化。
其中Low Memory Killer相对于Linux标准OOM（Out Of Memory）机制更加灵活，它可以根据需要杀死进程来释放需要的内存。Low Memory Killer的实现主要位于aurora\msm\msm drivers/staging/android/lowmemorykiller.c文件中。
Ashmem为进程间提供大块共享内存，同时为内核提供回收和管理这个内存的机制。 Ashmem的实现位于system\core\libcutils\ashmem-dev.c文件中。（摘自华清远见系列图书《Android多媒体从初学到精通》）}