ARM平台上蓝牙协议栈Bluez的移植使用和配置

t，PC的发行版通常都会有一些基于各种图形库的passkey_agent，对于嵌入式系统，这部分代码可以想象，应该是要按照相应的API自己实现一个，为了测试，我直接使用了bluez-utils/daemon 目录下的passkey-agent
这是一个命令行下的可以使用预先设定的pin code进行配对的程序

为了使用它，我的文件系统里 /etc/Bluetooth/hcid.conf 中 option一节类似如下 ：

# HCId options
options {
# Automatically initialize new devices
autoinit yes;

# Security Manager mode
# none - Security manager disabled
# auto - Use local PIN for incoming connections
# user - Always ask user for a PIN
#
security user;

# Pairing mode
pairing multi;

# Do the same as "hciconfig hci0 down" when SetMode("off")
# is called.
offmode devdown;

# Default PIN code for incoming connections
passkey "1234";
}

4.2 关于自动配对和请求的发起

配对的发起，这里主要是从请求的发起者是谁的角度来说。

通常可能不需要关心配对请求是由本地还是由远端发起的，使用passkey_agent都能够正确处理。

不过如果在hcid.conf中将 Security Manager mode 设置为 auto，则Bluez会将passkey后面的字符串作为默认的Pin code，自动答复远端发起的配对请求。这是在没有使用passkey_agent的情况下的一种配对方式。

在这种情况下，Bluez可以处理远端的配对请求，但是对于本地发起的配对请求，将无法正确处理，我没有仔细的分析原因，或许是代码特意设计成这种工作方式。所以在无法明确知道谁将会主动先发起配对请求的情况下，使用Atuo模式，可能就会出现有些时候设备能绑定有些时候不能绑定的现象。

通常如果是由本地设备搜索发现的新设备，配对绑定的操作应该也是由本地发起。

另外可以观察到，对远端一个非PC类的蓝牙设备，如蓝牙耳机，如果上次绑定过，在耳机启动时会主动发起连接请求，如果本地的link key丢失了，也就会再走一次绑定的流程，这种情况下配对请求就是由远端设备发起的。


5 A2DP
A2DP蓝牙立体声应该是蓝牙最常见的Profile之一。
2.x版本的Bluez，对A2DP的支持是通过BTSCO来实现的，3.22的版本通过bluetoothd-service-audio来支持。
对Bluez A2DP profile的支持，还依赖于Alsa或Gstreamer。
5.1 配置
测试A2DP的时候，我使用的是aplay，同时在相关的配置文件里面写死了蓝牙耳机的地址
主要的配置文件包括：

/etc/asound.conf ：

pcm.bluetooth{
type bluetoot
h
device 00:02:5B:00:C1:A0
profile "hifi"
}

/etc/bluetooth/audio.conf ：

[General]
# disable=Sink
SCORouting=PCM

[Headset