Android BLE的總結-概念篇

Android BLE的總結

其實BLE是個通用的技術術語，與平臺無關的，即ios和Android以及一些嵌入式系統或單片機都可以有BLE模塊。在進行Android BLE相關的應用開發前，我們有必要去了解藍牙協議的一些知識。

藍牙協議

藍牙協議基礎概念

藍牙協議包括兩種技術：Basic Rate(簡稱BR)和Low Energy(簡稱LE)。這兩種技術，都包括搜索管理,連接管理等機制，但它們是不能互通的。

Basic Rate是正宗的藍牙技術，可以包括可選的EDR(Enhanced Data Rate)技術，以及交替使用的MAC(Media Access Control)層和PHY層擴展(簡稱AMP)。也就是說，BR和EDR是可以同時存在的，但BR/EDR和AMP只能二選一。其中在傳輸速率上：BR < EDR < AMP。因爲AMP借用了WIFI的MAC和物理層。

BR的發展路線是傳輸越快越好，但是功耗比較嚴重，而在某些場景下，是比較關注設備的功耗的，於是BLE就產生了，也即Bluetooth LE。

藍牙系統的組成涉及Bluetooth Application，Bluetooth Core,Bluetooth Host,Bluetooth Controller等。

藍牙協議規定了兩個層次的協議，分別爲藍牙核心協議(Bluetooth Core)和藍牙應用層協議(Bluetooth Application)。藍牙核心協議關注對藍牙核心技術的描述和規範，它只提供基礎的機制，並不關心如何使用這些機制。藍牙應用層協議，是在藍牙核心協議的基礎上，根據具體的應用需求定義出各種各樣的策略。

Bluetooth Core由兩部分組成，Host和Controller。這兩部分在不同的藍牙技術中(BR/EDR,AMP,LE)，承擔角色略有不同，但大致的功能是相同的。Controller負責定義RF,Baseband等偏硬件的規範，並在這之上抽象出用於通信的邏輯鏈路(Logical Link);Host複雜在邏輯鏈路的基礎上，進行更爲友好的封裝，這樣就可以屏蔽掉藍牙技術的細節，讓Bluetooth　Application 更爲方便的使用。

在一個藍牙系統中，Host只有一個，但Controller可以一個，也可以有多個。

協議架構

藍牙協議是通信協議的一種，爲了把複雜問題簡單化，任何通信協議都具有層次性，特點如下：

(1)從下到上分層，通過層層封裝，每一層只需要關心特定，獨立的功能，易於實現和維護。

(2)在通信實體內部，下層向上層提供服務，上層是下層的用戶

(3)在通信實體之間，協議僅針對每一層，實體之間的通信，就像每一層之間的通信一樣，這樣有利於交流，理解，標準化。

藍牙協議分爲四個層次：

(1)物理層(Physical Layer):負責提供數據傳輸的物理通道(通常稱爲信道)。通常情況下，一個通信系統中存在幾種不同類型的信道

(2)邏輯層(Logical Layer)：在物理層的基礎上，提供兩個或多個設備之間，和物理無關的邏輯傳輸通道

(3)L2CAP　Layer：L2CAP是邏輯鏈路控制和適配協議的縮寫，負責管理邏輯層提供的邏輯鏈路。基於該協議，不同Application可共享同一個邏輯鏈路

(4)應用層(APP Layer)：基於L2CAP提供的channel,實現各種各樣的應用功能。Profile是藍牙協議的特有概念，爲了實現不同平臺下的不同設備的互聯互通，藍牙協議不止規定了核心規範，也爲各種不同的應用場景，定義了各種Application規範，這些應用層規範稱作藍牙profile.

物理層又分爲物理信道(Physical Channel)與物理鏈路(Physical Link)。藍牙協議爲BR/EDR，LE和AMP三種技術定義了8種類型的物理信道：

1.AMP physical channel:主要用於已連接設備之間的數據通信。

2.BR/EDR Basic Piconet Physical Channel：主要用在處於連接狀態的藍牙設備之間的通信，使用全部79個跳頻點。

3.BR/EDR Adapted Piconet Physical Channel：也是主要用在處於連接狀態的藍牙設備之間的通信，但是使用較少的RF跳頻點，但跳頻數目不能少於20個

4.BR/EDR Page Scan Physical Channel：用於藍牙設備的發現操作，即我們常用的搜索其它藍牙設備(discover)以及被其它藍牙設備搜索(discoverable)

5.BR/EDR Inquiry Scan Physical Channel：用於藍牙設備的連接操作，即我們常用的連接其它藍牙設備(connect)以及被其它藍牙設備連接(connectable)。

6.BR/EDR Synchronization Scan Channel：可用於無連接的廣播通信。

7.LE Piconet Channel：採用跳頻技術用在處於連接狀態的藍牙設備之間的通信

8.LE Advertisement Broadcast Channel用於在設備間進行無連接的廣播通信，這些廣播通信可用於藍牙的設備的發現，連接操作，也可用於無連接的數據傳輸。而物理鏈路則是對這些物理信道的進一步封裝。物理鏈路只是一個虛擬概念，不對應協議中任何的實體，數據包封包/解包的過程中不被體現。大家只需要知道物理鏈路是對於物理信道的抽象封裝，以便上層使用。

邏輯層也可以分爲兩部分，分別爲Logic Links 和Logic Transports。邏輯層的主要功能，是在已連接的藍牙設備之間，基於物理鏈路，建立邏輯信道。藍牙邏輯信道的劃分依據是傳輸類型，主要包括下面3類：

1.用於管理底層物理鏈路的控制類傳輸，包括AMP-C,ACL-C,PSB-C,LE-C,ADVB-C

2.傳輸用戶數據的用戶類傳輸，包括AMP-U,ACL-U,PSB-U,LE-U,ADVB-U.

3.其它比較特殊的傳輸類型，包括流式傳輸(stream),PBD（Profile Broadcast Data）
以上每種Logic Link都會在下層對應一個Logic Transport,這些Logical Transport具有一些屬性值，如流控，應答/重傳機制等。

L2CAP是Logical Link Control and Adaptation Protocol(邏輯鏈路控制和適配協議)的縮寫。對下，它在用戶類XXX-U Logical Link的基礎上，抽象出和具體技術無關的數據傳輸通道(包括單播和廣播兩類),至此用戶就不再需要關心繁雜的藍牙技術細節。對上，它以L2CAP channel endpoints的概念,爲具體的應用程序(profile)提供獨立的數據傳輸通道.

profile是藍牙Application的代指，也可以翻譯爲服務，爲了實現不同平臺下的不同設備的互聯互通，藍牙協議爲各種可能的，有通用意義的應用場景，都制定了規範。

藍牙規範有兩類：一類是藍牙核心規範，由Bluetooth Core Specification定義，囊括到L2CAP層，以及相關的核心profile；另一類是藍牙Application規範，包含了各種各樣的profile規範。

至此爲止，關於協議的東西就不在這裏闡述了，因爲東西比較多，而且不是很好理解，這個東西我們只需要簡單的瞭解一下有個印象，當工作環境中遇到藍牙協議相關的任務或者問題時，再深入研究是比較合理的做法。

下面簡要概述兩點：1.BLE廣播包的格式2.BLE的地址

(1)BLE廣播包格式：

1.BLE中有兩種角色Central和Peripheral,也就是中心設備和外圍設備。中心設備可以主動連接外圍設備，外圍設備發送廣播或者被中心設備連接。外圍通過廣播被中心設備發現，廣播中帶有外圍設備自身的相關信息。廣播包有兩種：廣播包(Advertising Data)和響應包(Scan Response),其中廣播包是每個設備必須廣播的，而響應包是可選的。每個包都是31字節，數據包中分爲有效數據(significant)和無效數據(non-significant)兩部分。

有效數據部分：包含若干個廣播數據單元，稱爲AD Structure。AD Structure的組成是：第一個字節是長度值Len，表示接下來的Len個字節是數據部分。數據部分的第一個字節表示數據的類型AD Type,剩下的Len-1個字節是真正的數據AD data。其中AD type非常關鍵，決定了AD Data的數據代表的是什麼和怎麼解析。

無效數據部分：因爲廣播包的長度必須是31個byte，如果有效數據部分不到31字節，剩下的就用0補全。這部分的數據是無效的，解釋的時候，可以忽略。

下面簡單看一下主要的幾個AD Type的類型：

1.Flags:type=0x01.這個數據用來標識設備LE物理連接的功能。DATA是0到多個字節的Flag值，每個bit上用0或者1來表示是否爲True.如果有任何一個bit不爲0,並且廣播包是可連接的，就必須包含此數據。各bit的定義如下：
bit 0: LE有限發現模式
bit 1: LE普通發現模式
bit 2: 不支持BR/EDR
bit 3:　對Same　Device　Capable(Controller)同時支持BLE和BR/EDR
bit 4:　對Same Device Capable(Host)同時支持BLE和BR/EDR
bit 5~7: 預留。

2.Service UUID：廣播數據中一般都會把設備支持的GATT Service廣播出來,用來告訴外面本設備所支持的Service。有三種類型的UUID：16bit,32bit,128bit。廣播中，
每種類型有兩個類別：完整和非完整的。這樣就共有6種AD Type。
非完整的16 bit　UUID列表:TYPE=0x02;
完整的16 bit UUID列表: TYPE=0x03;
非完整的32 bit UUID列表：TYPE=0x04;
完整的32 bit UUID列表:TYPE=0x05;
非完整的128 bit UUID列表：TYPE=0x06;
完整的128 bit UUID列表：TYPE=0x07;

3.Local Name:設備名字,DATA是名字的字符串。Local Name可以是設備的全名, 也可以是設備名字的縮寫,其中縮寫必須是全名的前面的若干字符。
　設備全名：TYPE=0x08;
　設備簡稱：TYPE=0x09;
　

5.廠商自定義數據:TYPE=0xFF,廠商自定義的數據中，前兩個字節表示廠商ID，剩下的是廠商自己按照需求添加，裏面的數據內容自己定義。

(2)BLE的地址：

BLE設備有多種類型的設備地址，如Public Device Address,Random Device Address,Static Device Address,Private Device Address等等。有一點需要大家知道的是一個BLE設備可以使用兩種類型的地址(一個BLE設備可同時具備兩種地址):Public Device Address和Random Device Address。而Random　Device Address又分爲static Device Address和Private Device Address兩類。其中Private Device Address 又可以分爲Non-resolvable Private Address和Resolvable Private Address。

1.Public Device Address:該地址可以理解爲TCP/IP網絡中的MAC地址，是設備的唯一標識地址， 該地址是需要花錢買的,由IEEE保證地址的唯一性。

2.Random Device Address:BLE協議新增的一種地址，該地址不是固定分配的，而是在設備啓動後隨機生成的。該類型地址可以分爲Static Device Address 和Private Device Address兩類。該類地址的產生原因主要是Public Device Address需要購買，管理也比較麻煩。

3.Static Device Address:設備在上電時隨機生成的地址，在一個上電週期內保持不變，下一次上電的時候可以改變。但不是強制的，因此也可以保持不變。如果改變，上次保存的連接等信息，將不再有效。

4.Private Device Address:Static Device Address通過地址隨機生成的方式，解決了部分問題，Private Device Address則更進一步，通過定時更新和地址加密兩種方法，提高藍牙地址的可靠性和安全性。根據地址是否加密，Private Device Address又分爲兩類，Non-resolvable private address和Resolvable private address。

5.Non-resolvable private address:Non-resolvable private address 和Static Device　Address類似，不同之處在於，Non-resolvable private address會定時更新。更新的週期是由GAP規定的，稱作T_GAP(private_addr_int)，建議值是15分鐘。

6.Resolvable private address:Resolvable private address比較有用，它通過一個隨機數和一個稱作identity resolving key(IPK)的密碼生成,因此只能被擁有相同IPK的設備掃描到，可以防止被未知設備掃描和追蹤。注意：Resolvable private address不能單獨使用，因此需要使用該類型的地址的話，設備要同時具備Public Device Address或者Static Device　Address中的一種.

Android 藍牙簡介

Android提供默認的藍牙協議棧是BlueDroid，分爲兩層：藍牙嵌入式系統(BTE)和藍牙應用層(BTA),BTE層主要實現藍牙的核心功能,BTA層則主要負責和Android框架通信.
我們在官網上可以看到下面兩幅圖：

Android 7.x and earlier architecture

藍牙系統服務通過JNI來與藍牙協議棧交互，通過Binder IPC來與應用層交互。系統服務給開發者提供各種藍牙Profile的訪問.Android中的藍牙總體架構主要分爲如下幾個部分：

1.應用框架層　Application framework在應用框架層是具體的藍牙相關應用的代碼，這裏使用android.bluetooth相關的API來和藍牙硬件交互。其內部實現是通過Binder IPC機制來調用Bluetooth進程的。

2.藍牙系統服務　Bluetooth system service藍牙系統服務位於packages/apps/Bluetooth,被作爲一個Android的系統App.它在Android框架層實現了藍牙的Service和Profile，並通過JNI調用到HAL層。編譯到系統中就是/system/app/Bluetooth.apk;

3.JNI與android.bluetooth對應的JNI代碼位於packages/apps/Bluetooth/jni,JNI層代碼調用到HAL層，並當發生某些藍牙動作的時候,接受來自HAL層的回調.

4.硬件抽象層HAL定義了android.bluetooth API和藍牙進程需要用到的標準接口，你必須實現這些接口來確保你的藍牙硬件正常工作。藍牙HAL相關的頭文件位於
hardware/libhardware/include/hardware/bluetooth.h
hardware/libhardware/include/hardware/bt_*.h;

5.藍牙協議棧:Android提供的默認藍牙協議棧位於external/bluetooth/bluedroid。這個協議棧實現了通用的藍牙HAL接口，並且可以通過擴展(Extentions)和配置(Configuration)來自定義。編譯到系統中就是/system/lib/hw/bluetooth.default.so；

6.供應商(Vendor extentions):供應商也可以通過創建libbt-vendor並指定這些模塊，來添加自定義擴展和HCI層跟蹤。

藍牙的HAL相關文件在hardware/libhardware/include/hardware/,包括但不侷限於以下的文件：
bluetooth.h:這裏包含藍牙硬件的接口定義;
bt_gatt.h,bt_gatt_client.h,和bt_gatt_server.h：這裏包含GATT profile相關的接口定義;
bt_hf.h:HEP profile相關接口的定義;
bt_hh.h:HID　host　profile相關接口的定義;
bt_hl.h:HDP　profile 相關接口的定義;
bt_mce.h:MAP profile 相關接口的定義;
bt_pan.h:PAN profile 相關接口的定義;
bt_rc.h:AVRCP　profile　相關接口的定義;
bt_sock.h:RFCOMM profile 相關接口的定義;

值得注意的是，Android中藍牙並不侷限於HAL中暴露的這些特性和Profile。BlueDroid是藍牙協議棧的默認是實現，它實現了默認的HAL以及額外的自定義特性。BlueDroid的代碼在external/bluetooth/bluedroid目錄.

Android 8.0 architecture

通過這兩幅圖我們可以看到，Android 8.0的藍牙架構和Android7.x以及之前版本還是有差別的。主要差別在供應商的擴展方式上，Android 8.0和以前版本之間的本地藍牙堆棧的最大變化是使用高音。Android 8.0中的供應商實現必須使用HIDL而不是libbt-vendor。

另外Android 8.0 通過增加以下功能，增強了平臺對藍牙的支持：
支持 AVRCP 1.4 標準，該標準支持音樂庫瀏覽。
支持藍牙低功耗 (BLE) 5.0 標準。
將 Sony LDAC 編解碼器集成到藍牙堆疊中。

AirSync協議

AirSync是微信硬件平臺提供的一種微信客戶端與藍牙設備間通訊的技術協議，它允許藍牙設備與微信客戶端之間收發數據，並支持通過微信客戶端透傳到遠程服務器。該技術在支持微信互聯的藍牙手環、血壓計、智能秤、血糖儀等設備上有比較多的應用.AirSync支持經典藍牙和BLE低功耗藍牙.同時AirSync協議又稱爲微信藍牙外設協議，具體的協議文檔在http://iot.weixin.qq.com/wiki/new/index.html?page=6-1 處下載。

下面我給出實現AirSync協議的測試工具的日誌，供相關開發人員進行參考調試：

*****************BLE： XXXXX******************
***** onTestBroadcastRecord *****
result = true, Has 0xfee7 or standard service in broadcast record
廣播包：02 01 18 0B 09 41 61 5A 45 4E 2D 33 43 44 35 09 FF 01 01 64 1B 13 45 97 93 03 03 E7 FE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
***** onTestManufatureData *****
resut= true, 廣播包中 manufacture specific data 字段中MAC地址校驗成功.
***** onDiscoverService *****
result = true, DiscoverService success
Discovered Services
ServiceUUID: 00001801-0000-1000-8000-00805f9b34fb
ServiceUUID: 00001800-0000-1000-8000-00805f9b34fb
ServiceUUID: 0000fee7-0000-1000-8000-00805f9b34fb
***** onTestHasWeChatService *****
result = true, has WeChatService or standard service
***** onTestHasIndicateCharacteristic *****
result = true, has WeChat Indicate Characteristic
***** onTestHasWriteCharacteristic *****
result = true, has Wechat Write Characteristic
***** onTestHasReadCharacteristic *****
result = true, Has WeChat read characteristic
***** onTestWriteCharacteristicPermisson *****
result = true, has Write permission
***** onTestIndicateCharacteristicPermisson *****
result = true, has Indication permission
***** onTestReadCharacteristicPermisson *****
result = true, Read Characteristic is read able
***** onTestStartIndicating *****
result = true, can Start Indicate
***** onConnected *****
result = true, connected
------onDataReceived------
data length = 8
data dump = FE 01 00 1A 27 11 00 01
data receive seq = 1
------onDataReceived------
data length = 18
data dump = 0A 00 18 81 8C 08 20 01 28 02 3A 06 64 1B 13 45 97 93
data receive seq = 2
***** onTestRecvAuthReqtWhenStartedIndicating *****
result = true, received auth request pack
***** onTestIsValidAuthReqPack *****
result = true, is a valid auth request pack
AuthRequestPack: FE 01 00 1A 27 11 00 01 0A 00 18 81 8C 08 20 01 28 02 3A 06 64 1B 13 45 97 93
has BaseRequest
no Md5DeviceTypeAndDeviceId field!
has MacAddress field, Mac Address = 64 1B 13 45 97 93
MacAddress BitLength = 48bit
Mac Address from broadcast record = 64:1B:13:45:97:93
Mac address checkout success
has ProtoVersion field, ProtoVersion = 132609
has AuthProto field, AuthProto = 1
has AuthMethod field, AuthMethod = EAM_macNoEncrypt
no AesSign field!
**** send auth response ****
data len = 14
data dump = FE 01 00 0E 4E 21 00 01 0A 02 08 00 12 00
------onDataReceived------
data length = 8
data dump = FE 01 00 13 27 13 00 01
data receive seq = 3
------onDataReceived------
data length = 11
data dump = 0A 00 12 01 01 1A 04 00 01 02 03
data receive seq = 4
***** onTestRecvInitReqPack *****
result = true, received init request pack
***** onTestIsValidInitReqPack *****
result = true, valid init request pack: has BaseRequest
has RespFieldFilter field, RespFieldFilter = 01
has Challenge field, Challenge = 00 01 02 03
**** send init request response ****
data len = 47
data dump = FE 01 00 2F 4E 23 00 01 0A 02 08 00 10 B4 24 18 F8 AC 01 20 93 8C E6 DD 08 5A 14 57 65 43 68 61 74 20 54 65 73 74 20 62 79 20 6D 61 74 74 21
------onDataReceived------
data length = 19
data dump = FE 01 00 13 27 12 00 01 0A 00 12 05 0A 03 08 C8 01 18 01
data receive seq = 5
***** onTestIsValidWristbandRequest *****
result = true, is a valid WristbandRequest pack.
has 1 StepDataItems
***********StepDataItemIndex: 0 ************
has field uint32 Step, Step = 200
*** receive SendDataRequest ****
date type = wxWristBand data
data len = 11
data dump = 0A 00 12 05 0A 03 08 C8 01 18 01
**** send SendData Response(echo request) ****
data len = 25
data dump = FE 01 00 19 4E 22 00 01 0A 02 08 00 12 0B 0A 00 12 05 0A 03 08 C8 01 18 01
***** onTestIsValidSendDataRequest *****
result = true, is a valid SendDataRequest pack: has BaseRequest field
has Data field, data = 0A 03 08 C8 01
has Type field, type = 1, wxWristBand data
**** send ManufactureSvr Push ****
data len = 22
data dump = FE 01 00 16 75 31 00 00 0A 00 12 08 31 32 33 34 35 36 37 38 18 00
**** send Html Push ****
data len = 23
data dump = FE 01 00 17 75 31 00 00 0A 00 12 08 31 32 33 34 35 36 37 38 18 91 4E
**** send wxWristBand Push ****
data len = 14
data dump = FE 01 00 0E 75 31 00 00 0A 00 12 00 18 01
**** send EnterDeviceChatView Push ****
data len = 14
data dump = FE 01 00 0E 75 32 00 00 0A 00 10 01 18 01
**** send Exit ChatView Push ****
data len = 14
data dump = FE 01 00 0E 75 32 00 00 0A 00 10 02 18 01
**** send Enter HtmlChatView Push ****
data len = 14
data dump = FE 01 00 0E 75 32 00 00 0A 00 10 01 18 02
**** send Exit HtmlChatView Push ****
data len = 14
data dump = FE 01 00 0E 75 32 00 00 0A 00 10 02 18 02
**** send enterBackground Push ****
data len = 12
data dump = FE 01 00 0C 75 33 00 00 0A 00 10 01
**** send enterForground Push ****
data len = 12
data dump = FE 01 00 0C 75 33 00 00 0A 00 10 02
**** send enterSleep Push ****
data len = 12
data dump = FE 01 00 0C 75 33 00 00 0A 00 10 03
*****Disconnected Device*****

PS:如果你正在Android系統上集成AirSync協議，看完了藍牙外設協議，內心有一萬頭神獸的話，這裏給你幾點建議：

1.把文檔多閱讀幾遍，最起碼得有3遍吧，什麼看了5遍還是無從下手，連個Demo都沒有，只有一些開發板的Demo,看不懂c,網上沒有相關有用的資料，於是一萬頭變兩萬頭。

2.無從下手怎麼辦，咦，官方給了一個測試工具apk，這個是Java實現的，就是它，反編譯它，扒光它，於是思路就有了，直接把裏面的部分代碼提煉出一部分，連數據包處理的代碼都有了。

3.”00002902-0000-1000-8000-00805f9b34fb”這個UUID文檔中是沒有，但是在開發中，這個又是必須的，這個UUID還是反編譯測試工具找到的，這個算是一個深坑，坑了我一整天。

具體的就不說太多了，BLE在Android開發中本來就很小衆，這個AirSync協議就小小衆，在開發過程中可以參考上面的測試完成的Log,有問題的可以留言，我會盡量回答。

藍牙精簡協議

微信藍牙精簡協議支持智能手環等計步類設備接入微信運動。微信藍牙計步器Profile協議是基於GATT的協議，該協議對設備的硬件能力要求較低，並且廠商不需要有和微信對接的後臺服務器(即只需要開發設備).該profile可以讓計步器和微信連接，並傳輸步數，公里數，卡路里，運動目標等.

這個協議相比於AirSync協議在開發上就簡單許多，如果AirSync協議都實現了的話,這個一天就搞定了。

關於AirSync協議與藍牙精簡協議這裏說的比較簡單，但在開發過程中會遇到各種問題，比如，Android 沒有獲取廣播信道地址的API，Android　BLE的廣播信道地址是隨機的等問題，這個就需要大家看源碼和自己在framework層增加相應的API了。

最後同樣的給出一份Log:

*****************BLE： XXXXX******************

***** onTestBroadcastRecord *****
result = true, Has 0xfee7 in broadcast record

廣播包：02 01 18 0B 09 41 61 5A 45 4E 2D 33 43 30 31 09 FF 01 01 64 1B 13 6A 0D 52 03 03 E7 FE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

***** onTestManufatureData *****
resut= true, 廣播包中 manufacture specific data 字段中MAC地址校驗成功.

***** onDiscoverService *****
result = true, DiscoverService success
Discovered Services
ServiceUUID: 00001801-0000-1000-8000-00805f9b34fb
ServiceUUID: 00001800-0000-1000-8000-00805f9b34fb
ServiceUUID: 0000fee7-0000-1000-8000-00805f9b34fb


***** onTestHasWeChatService *****
result = 0
has WeChatService and has profile

***** onTestHasReadCharacteristic *****
result = true, has read characteristic

***** onTestPedometerMeasureCharacteristic *****
result = true, has WeChat PedometerMeasurement Characteristic

***** onTestPedometerTargetCharacteristic *****
result = true, Has Wechat PedometerTarget Characteristic

***** onTestReadCharacteristicPermisson *****
result = true, ReadCharacteristic can read

**** onTestMeasurementCharacteristicProperties ****
result = true, PedometerMeasureCharacteristic can indicate/notify and read !

****onTestTargetCharacteristicProperties****
result = true, PedometerTargetCharacteristic can write read and indcate!

------onDataReceived------
data length = 4
data dump = 00 00 04 7D
data receive seq = 1

*****onPedometerMeasurementIndicate*****
result = false,Received Data error:
數據格式不正確！

------onDataReceived------
data length = 4
data dump = 01 7D 04 00
data receive seq = 1

*****onPedometerMeasurementIndicate*****
result = true,Received Data:
步數：1149

------onDataReceived------
data length = 6
data dump = 64 1B 13 6A 0D 52
data receive seq = 1

*****onRecieveExtraData*****
result = false,Received Data error:
數據格式不正確！

***** onTestStartIndicating *****
result = true, can Start Indicate

***** onConnected *****
result = true, connected

------onDataReceived------
data length = 4
data dump = 01 7D 04 00
data receive seq = 1

*****onPedometerMeasurementIndicate*****
result = true,Received Data:
步數：1149//保證這個正確就可以，就可以在微信運動中看到自己的步數了

------onDataRead------
data length = 4
data dump = 01 7D 04 00

*****onPedometerMeasurementRead*****
result = true,Received Data:
步數：1149

------onDataReceived------
data length = 4
data dump = 01 10 27 00
data receive seq = 3

*****onPedometerTargetIndicate*****
result = true,Received Data:
步數：10000

------onDataRead------
data length = 4
data dump = 01 10 27 00

*****onPedometerTargetRead*****
result = true,Received Data:
步數：10000

*****onPedometerTargetWrite*****
result = true,Write Data:
數據包一共[4]字節 一共分成[1]數據包 每個數據大小爲[20]字節 全部數據包發送成功

以上內容如有任何不對的煩請指出。
轉載請註明出處：http://blog.csdn.net/android_jiangjun/article/details/77113883

參考資料：
http://www.wowotech.net/sort/bluetooth
https://race604.com/android-bluetooth-intro/
https://race604.com/ble-advertising/
http://iot.weixin.qq.com/wiki/new/index.html
https://source.android.com/devices/bluetooth/#architecture-android-80