android藍牙ble

⑴ Android BLE藍牙踩坑總結

自從 Android-BLE 庫開源了一段時間以來，越來越多的小夥伴問到了各種各樣的關於BLE的奇怪問題，在這里我想跟大家分享一下本人對於Android BLE藍牙的一些看法和解決方式，避免剛接觸的小夥伴再次踩坑。

很多人曾問過我這個問題，為什麼其他手機都沒什麼問題，就華為的一些手機老是連接不穩定，經常連接的很慢，而且連接上還經常斷開。的確，在這里強調一下華為的一部分手機確實很容易出現這種問題，有時候軟體、硬體都搞不定，而且經常性收到客戶投訴關於華為手機連接穩定性問題，這個的確沒有完全解決的辦法，只能靠App和硬體的優化，並不是想甩鍋給華為，咱也不敢問到底是什麼原因，而且我們公司專門針對各個Android版本的手機做過測試，包括藍牙傳輸速率的測試，最後發現華為P20的速度竟然跟小米8的速度差了好幾倍，按理說P20手機也不便宜啊，為什麼手機藍牙晶元不能做的再好一點呢？

BLE掃描濫用預防

AOSP-BLE掃描濫用說明

息屏狀態下，藍牙掃描日誌，因為掃描周期是12s，所以列印的時間戳間隔是12s，這里的日誌為系統日誌。

https://android.googlesource.com/platform/external/bluetooth/bluedroid/+/master/include/bt_target.h#1428

stackoverflow問答社區

⑵ Android-Ble藍牙開發Demo示例–掃描,連接,發送和接收數據,分包解包(附源碼)

萬物互聯的物聯網時代的已經來臨，ble藍牙開發在其中扮演著舉重若輕的角色。最近剛好閑一點，抽時間梳理下這塊的知識點。

涉及ble藍牙通訊的客戶端(開啟、掃描、連接、發送和接收數據、分包解包)和服務端(初始化廣播數據、開始廣播、配置Services、Server回調操作)整個環節以及一些常見的問題即踩過的一些坑。

比如
1、在Android不同版本或不同手機的適配問題，掃描不到藍牙設備
2、如何避免ble藍牙連接出現133錯誤？
3、單次寫的數據大小有20位元組限制，如何發送長數據

藍牙有傳統(經典)藍牙和低功耗藍牙BLE(Bluetooth Low Energy)之分，兩者的開發的API不一樣，本文主講Ble藍牙開發，傳統藍牙不展開，有需要的可以自行了解。

相對傳統藍牙，BLE低功耗藍牙，主要特點是快速搜索，快速連接，超低功耗保持連接和數據傳輸。

客戶端

服務端

Android4.3(API Level 18)開始引入BLE的核心功能並提供了相應的 API。應用程序通過這些 API 掃描藍牙設備、查詢 services、讀寫設備的 characteristics（屬性特徵）等操作。

BLE藍牙協議是GATT協議, BLE相關類不多, 全都位於android.bluetooth包和android.bluetooth.le包的幾個類:
android.bluetooth.
.BluetoothGattService 包含多個Characteristic(屬性特徵值), 含有唯一的UUID作為標識
.BluetoothGattCharacteristic 包含單個值和多個Descriptor, 含有唯一的UUID作為標識
.BluetoothGattDescriptor 對Characteristic進行描述, 含有唯一的UUID作為標識

.BluetoothGatt 客戶端相關
.BluetoothGattCallback 客戶端連接回調
.BluetoothGattServer 服務端相關
.BluetoothGattServerCallback 服務端連接回調

android.bluetooth.le.
.AdvertiseCallback 服務端的廣播回調
.AdvertiseData 服務端的廣播數據
.AdvertiseSettings 服務端的廣播設置
.BluetoothLeAdvertiser 服務端的廣播

.BluetoothLeScanner 客戶端掃描相關(Android5.0新增)
.ScanCallback 客戶端掃描回調
.ScanFilter 客戶端掃描過濾
.ScanRecord 客戶端掃描結果的廣播數據
.ScanResult 客戶端掃描結果
.ScanSettings 客戶端掃描設置

BLE設備分為兩種設備: 客戶端(也叫主機/中心設備/Central), 服務端(也叫從機/外圍設備/peripheral)
客戶端的核心類是 BluetoothGatt
服務端的核心類是 BluetoothGattServer 和 BluetoothLeAdvertiser
BLE數據的核心類是 BluetoothGattCharacteristic 和 BluetoothGattDescriptor

下面詳細講解下客戶端和服務端的開發步驟流程

安卓手機涉及藍牙許可權問題，藍牙開發需要在AndroidManifest.xml文件中添加許可權聲明：

在搜索設備之前需要詢問打開手機藍牙：

注意: BLE設備地址是動態變化(每隔一段時間都會變化),而經典藍牙設備是出廠就固定不變了！

通過掃描BLE設備，根據設備名稱區分出目標設備targetDevice，下一步實現與目標設備的連接，在連接設備之前要停止搜索藍牙；停止搜索一般需要一定的時間來完成，最好調用停止搜索函數之後加以100ms的延時，保證系統能夠完全停止搜索藍牙設備。停止搜索之後啟動連接過程；

BLE藍牙的連接方法相對簡單只需調用connectGatt方法；

參數說明

與設備建立連接之後與設備通信，整個通信過程都是在BluetoothGattCallback的非同步回調函數中完成；

BluetoothGattCallback中主要回調函數如下：

上述幾個回調函數是BLE開發中不可缺少的；

當調用targetdDevice.connectGatt(context, false, gattCallback)後系統會主動發起與BLE藍牙設備的連接，若成功連接到設備將回調onConnectionStateChange方法，其處理過程如下：

判斷newState == BluetoothGatt.STATE_CONNECTED表明此時已經成功連接到設備；

mBluetoothGatt.discoverServices();

掃描BLE設備服務是安卓系統中關於BLE藍牙開發的重要一步，一般在設備連接成功後調用，掃描到設備服務後回調onServicesDiscovered()函數，函數原型如下：

BLE藍牙開發主要有負責通信的BluetoothGattService完成的。當且稱為通信服務。通信服務通過硬體工程師提供的UUID獲取。獲取方式如下：

具體操作方式如下：

開啟監聽，即建立與設備的通信的首發數據通道，BLE開發中只有當客戶端成功開啟監聽後才能與服務端收發數據。開啟監聽的方式如下：

BLE單次寫的數據量大小是有限制的， 通常是20位元組 ，可以嘗試通過requestMTU增大，但不保證能成功。分包寫是一種解決方案，需要定義分包協議，假設每個包大小20位元組，分兩種包，數據包和非數據包。對於數據包，頭兩個位元組表示包的序號，剩下的都填充數據。對於非數據包，主要是發送一些控制信息。
監聽成功後通過向 writeCharacteristic寫入數據實現與服務端的通信。寫入方式如下：

其中：value一般為Hex格式指令，其內容由設備通信的藍牙通信協議規定；

若寫入指令成功則回調BluetoothGattCallback中的onCharacteristicWrite()方法，說明將數據已經發送給下位機；

若發送的數據符合通信協議，則服務端會向客戶端回復相應的數據。發送的數據通過回調onCharacteristicChanged()方法獲取，其處理方式如下：

通過向服務端發送指令獲取服務端的回復數據，即可完成與設備的通信過程；

當與設備完成通信之後之後一定要斷開與設備的連接。調用以下方法斷開與設備的連接：

源碼上傳在CSDN上了，有需要的可以借鑒。

=====> Android藍牙Ble通訊Demo示例源碼–掃描,連接,發送和接收數據,分包解包

BLE單次寫的數據量大小是有限制的，通常是20位元組，可以嘗試通過requestMTU增大，但不保證能成功。分包寫是一種解決方案，需要定義分包協議，假設每個包大小20位元組，分兩種包，數據包和非數據包。對於數據包，頭兩個位元組表示包的序號，剩下的都填充數據。對於非數據包，主要是發送一些控制信息。
總體流程如下：
1、定義通訊協議，如下(這里只是個舉例，可以根據項目需求擴展)

2、封裝通用發送數據介面(拆包)
該介面根據會發送數據內容按最大位元組數拆分(一般20位元組)放入隊列，拆分完後，依次從隊列里取出發送

3、封裝通用接收數據介面(組包)
該介面根據從接收的數據按協議里的定義解析數據長度判讀是否完整包，不是的話把每條消息累加起來

4、解析完整的數據包，進行業務邏輯處理

5、協議還可以引入加密解密，需要注意的選演算法參數的時候，加密後的長度最好跟原數據長度一致，這樣不會影響拆包組包

一般都是Android版本適配以及不同ROM機型（小米/紅米、華為/榮耀等）（EMUI、MIUI、ColorOS等）的許可權問題

藍牙開發中有很多問題，要靜下心分析問題，肯定可以解決的，一起加油；

⑶ Android 低功耗藍牙(Ble) 開發總結

Android 從 4.3(API Level 18) 開始支持低功耗藍牙，但是只支持作為中心設備（Central）模式，這就意味著 Android 設備只能主動掃描和鏈接其他外圍設備（Peripheral）。從 Android 5.0(API Level 21) 開始兩種模式都支持。

低功耗藍牙開發算是較偏技術,實際開發中坑是比較多的,網上有很多文章介紹使用和經驗總結,但是有些問題答案不好找,甚至有些誤導人,比如 :獲取已經連接的藍牙,有的是通過反射,一大堆判斷,然而並不是對所有手機有用,關於Ble傳輸速率問題的解決,都是默認Android每次只能發送20個位元組,然而也並不是,,,下面進入正文。

這里用的是 Android5.0 新增的掃描API，

這里說一下，如果做藍牙設備管理頁面，可能區分是否是已連接的設備,網上又通過反射或其他挺麻煩的操作,也不見得獲取到,官方Api 就有提供

與外圍設備交互經常每次發的數據大於 mtu的，需要做分包處理，接收數據也要判斷數據的完整性最後才返回原數據做處理，所以一般交互最少包含包長度，和包校驗碼和原數據。當然也可以加包頭，指令還有其他完整性校驗。下面分享幾個公用方法:

我自己封裝的一個BleUtil ，因為涉及跟公司業務關聯性太強（主要是傳輸包的協議不同）就先不開源出來了，如果這邊文章對大家有幫助反饋不錯，我會考慮上傳個demo到github供大家使用，
在這先給大家推薦一個不錯 Demo ，裡面除了沒有分包，協議，和傳輸速率。基本的功能都有，而且調試數據到列印到界面上了。最主要是它可以用兩個個手機一個當中心設備一個當外圍設備調試。

首先傳輸速率優化有兩個方向，1 外圍設備傳輸到Android 。2 Android傳輸到外圍設備。
我在開發中首先先使用上面那位仁兄的demo調試，兩個Android 設備調試不延時，上一個成功馬上下一個，最多一秒發11個20位元組的包。

後來和我們的藍牙設備調試時發現發送特別快，但是數據不完整，他藍牙模塊接收成功了，但是透傳數據到晶元處理時發現不完整，我們的硬體小夥伴說因為 波特率 限制（差不多每10位元組透傳要耗時1ms）和藍牙模塊的buff （列印時是最多100byte，100列印的）限制，就算藍牙模塊每包都告訴你接收成功，也是沒透傳完就又接收了。後來通過調試每次發20K數據，最後是 Android 發是 20位元組/130ms 穩定。給Android 發是 20位元組/ 8ms 。 （天殺的20位元組，網上都是說20位元組最多了）

後來看了國外一家物聯網公司總結的 Ble 吞吐量的文章（上面有連接），知道Android 每個延時是可以連續接收6個包的。就改為 120位元組/ 16ms (為啥是16ms，不是每次間隔要6個包嗎，怎麼像間隔兩次，這時因為波特率影響，多了5個包100位元組，差不多 我們的單片機透傳到藍牙模塊要多耗時不到10ms )
而Android 發數據可以申請 我們設備的mtu 來得到最多每次能發多少位元組。延時還是130ms，即：241位元組/ 130ms 提高12倍，這個速度還可以。

根據藍牙BLE協議， 物理層physical layer的傳輸速率是1Mbps，相當於每秒125K位元組。事實上，其只是基準傳輸速率，協議規定BLE不能連續不斷地傳輸數據包，否則就不能稱為低功耗藍牙了。連續傳輸自然會帶來高功耗。所以，藍牙的最高傳輸速率並不由物理層的工作頻率決定的。

在實際的操作過程中，如果主機連線不斷地發送數據包，要麼丟包嚴重要麼連接出現異常而斷開。

在BLE裡面，傳輸速度受其連接參數所影響。連接參數定義如下：

1）連接間隔。藍牙基帶是跳頻工作的，主機和從機會商定多長時間進行跳頻連接，連接上才能進行數據傳輸。這個連接和廣播狀態和連接狀態的連接不是一樣的意思。主機在從機廣播時進行連接是應用層的主動軟體行為。而跳頻過程中的連接是藍牙基帶協議的規定，完全由硬體控制，對應用層透明。明顯，如果這個連接間隔時間越短，那麼傳輸的速度就增大。連接上傳完數據後，藍牙基帶即進入休眠狀態，保證低功耗。其是1.25毫秒一個單位。

2）連接延遲。其是為了低功耗考慮，允許從機在跳頻過程中不理會主機的跳頻指令，繼續睡眠一段時間。而主機不能因為從機睡眠而認為其斷開連接了。其是1.25毫秒一個單位。明顯，這個數值越小，傳輸速度也高。

藍牙BLE協議規定連接參數最小是5，即7.25毫秒；而Android手機規定連接參數最小是8，即10毫秒。iOS規定是16，即20毫秒。

連接參數完全由主機決定，但從機可以發出更新參數申請，主機可以接受也可以拒絕。android手機一部接受，而ios比較嚴格，拒絕的概率比較高。

參考:
在iOS和Android上最大化BLE吞吐量
最大化BLE吞吐量第2部分：使用更大的ATT MTU

⑷ android藍牙BLE（三） —— 廣播

​ 在藍牙開發中，有些情況是不需要連接的，只要外設廣播自己的數據即可，例如蘋果的 ibeacon 。自 Android 5.0 更新藍牙API後，手機可以作為外設廣播數據。

廣播包有兩種：

其中 廣播包是每個外設都必須廣播的，而響應包是可選的 。每個廣播包的長度必須是 31個位元組 ，如果不到 31個位元組 ，則剩下的全用 0 填充 補全，這部分的數據是無效的

廣播包中包含若干個廣播數據單元，廣播數據單元也稱為 AD Structure 。

廣播數據單元 = 長度值Length + AD type + AD Data。

長度值 Length 只佔 一個位元組 ，並且位於廣播數據單元的 第一個位元組 。

概念的東西有些抽象，先看看下面的廣播報文：

​ 0x代表這串字元串是十六進制的字元串。 兩位十六進制數代表一個位元組 。因為兩個字元組成的十六進制字元串最大為 FF ，即255，而Java中byte類型的取值范圍是-128到127，剛好可以表示一個255的大小。所以兩個十六進制的字元串表示一個位元組。

​ 繼續查看報文內容，開始讀取第一個廣播數據單元。讀取 第一個 位元組: 0x07 ,轉換為十進制就是7，即表示後面的7個位元組是這個廣播數據單元的數據內容。超過這7個位元組的數據內容後，表示是一個新的廣播數據單元。

​ 而第二個廣播數據單元，第一個位元組的值是 0x16 ,轉換為十進制就是22，表示後面22個位元組為第二個廣播數據單元。

​ 在廣播數據單元的 數據部分 中， 第一個位元組 代表 數據類型 （AD type），決定數據部分表示的是什麼數據。（即廣播數據單元第二個位元組為AD type）

AD Type 的類型如下：

​ 這bit 1~7分別代表著發送該廣播的藍牙晶元的物理連接狀態。當bit的值為1時，表示支持該功能。
例：

藍牙廣播的數據格式大致講了一下，有助於下面的廣播操作的理解。

先看看廣播設置（ AdvertiseSettings ）如何定義：

（1）、通過 AdvertiseSettings.Builder#setAdvertiseMode() 設置廣播模式。其中有3種模式：

（2）、通過 AdvertiseSettings.Builder#setAdvertiseMode() 設置廣播發射功率。共有4種功率模式：

（3）、通過 AdvertiseSettings.Builder#setTimeout() 設置持續廣播的時間，單位為毫秒。最多180000毫秒。當值為0則無時間限制，持續廣播，除非調用 BluetoothLeAdvertiser#stopAdvertising() 停止廣播。

（4）、通過 AdvertiseSettings.Builder#setConnectable() 設置該廣播是否可以連接的。

之前說過，外設必須廣播廣播包，掃描包是可選。但添加掃描包也意味著廣播更多得數據，即可廣播62個位元組。

可見無論是廣播包還是掃描包，其廣播的內容都是用 AdvertiseData 類封裝的。

（1）、 AdvertiseData.Builder#setIncludeDeviceName() 方法，可以設置廣播包中是否包含藍牙的名稱。

（2）、 AdvertiseData.Builder#setIncludeTxPowerLevel() 方法，可以設置廣播包中是否包含藍牙的發射功率。

（3）、 AdvertiseData.Builder#addService UUID (Parcel UUID ) 方法，可以設置特定的 UUID 在廣播包中。

（4）、 AdvertiseData.Builder#addServiceData(Parcel UUID ，byte[]) 方法，可以設置特定的 UUID 和其數據在廣播包中。

（5）、 AdvertiseData.Builder#addManufacturerData(int，byte[]) 方法，可以設置特定廠商Id和其數據在廣播包中。

​ 從 AdvertiseData.Builder 的設置中可以看出，如果一個外設需要在不連接的情況下對外廣播數據，其數據可以存儲在 UUID 對應的數據中，也可以存儲在廠商數據中。但由於廠商ID是需要由Bluetooth SIG進行分配的，廠商間一般都將數據設置在廠商數據。

另外可以通過 BluetoothAdapter#setName() 設置廣播的名稱

先看一個例子，我們分別在 廣播包 和 掃描包 中設置 AdvertiseData.Builder 的 每一種廣播報文參數 ，得到一下報文內容：

(1)、Type = 0x01 表示設備LE物理連接。

(2)、Type = 0x09 表示設備的全名

(3)、Type = 0x03 表示完整的16bit UUID 。其值為0xFFF7。

(4)、Type = 0xFF 表示廠商數據。前兩個位元組表示廠商ID,即廠商ID為0x11。後面的為廠商數據，具體由用戶自行定義。

(5)、Type = 0x16 表示16 bit UUID 的數據，所以前兩個位元組為 UUID ,即 UUID 為0xF117，後續為 UUID 對應的數據，具體由用戶自行定義。

最後繼承 AdvertiseCallback 自定義廣播回調。

初始化完畢上面的對象後，就可以進行廣播：

​ 廣播主要是通過 BluetoothLeAdvertiser#startAdvertising() 方法實現，但在之前需要先獲取 BluetoothLeAdvertiser 對象。

BluetoothLeAdvertiser 對象存在兩個情況獲取為Null:

所以在調用 BluetoothAdapter#getBluetoothLeAdvertiser() 前，需要先調用判斷藍牙已開啟，並判斷在 BluetoothAdapter 中獲取的 BluetoothLeAdvertiser 是否為空（測試過某些華為手機 mBluetoothAdapter.() 為 false , 但是能發送ble廣播）。

​ 與廣播成對出現就是 BluetoothLeAdvertiser.stopAdvertising() 停止廣播了，傳入開啟廣播時傳遞的廣播回調對象，即可關閉廣播：

​ 雖然通過廣播告知外邊自身擁有這些Service,但手機自身並沒有初始化Gattd的Service。導致外部的中心設備連接手機後，並不能找到對應的 GATT Service 和 獲取對應的數據。

Service類型有兩個級別：

創建 BluetoothGattService 時，傳入兩個參數： UUID 和Service類型：

​ 我們都知道Gatt中， Service 的下一級是 Characteristic ， Characteristic 是最小的通信單元，通過對 Characteristic 進行讀寫操作來進行通信。

​ 特徵屬性表示該 BluetoothGattCharacteristic 擁有什麼功能，即能對 BluetoothGattCharacteristic 進行什麼操作。其中主要有3種：

許可權屬性用於配置該特徵值所具有的功能。主要兩種：

Characteristic 下還有 Descriptor ，初始化 BluetoothGattDescriptor 時傳入： Descriptor UUID 和 許可權屬性

為 Service 添加 Characteristic ，為 Characteristic 添加 Descriptor ：

​ 通過藍牙管理器 mBluetoothManager 獲取 Gatt Server ，用來添加 Gatt Service 。添加完 Gatt Service 後，外部中心設備連接手機時，將能獲取到對應的 GATT Service 和 獲取對應的數據

​ 定義 Gatt Server 回調。當中心設備連接該手機外設、修改特徵值、讀取特徵值等情況時，會得到相應情況的回調。

最後開啟廣播後，用nRF連接後看到的特徵值信息如下圖所示：（加多了一個只能都的特徵值）

android藍牙BLE（一） —— 掃描

android藍牙BLE（二） —— 通信

android藍牙BLE（三） —— 廣播

android藍牙BLE（四） —— 實戰

⑸ 如何使用android原生BLE藍牙進行操作

之前的涉及的物聯網項目中使用的: BLE 低功耗藍牙(藍牙4.0), 支持android 4.3以上的手機
主從關系: BLE低功耗藍牙只能做從端設備 ,一個藍牙主端設備，可同時與7個藍牙從端設備進行通訊

1)低功耗
低功耗的原理:
1低功耗藍牙僅使用了3個廣播通道,傳統藍牙技術採用 16~32 個頻道
2每次廣播開啟時間也由傳統的 22.5ms 減少到 0.6~1.2ms(毫秒)

2)傳輸距離極大提高
傳統藍牙傳輸距離為 2~10m，而藍牙4.0的有效傳輸距離可達到 60~100m

3)安全性
使用AES-128 CCM加密演算法進行數據包加密和認證。
更多BLE藍牙的解析參考博客 : BLE4.0教程一 藍牙協議連接過程與廣播分析

添加許可權
打開藍牙
1.先拿到BluetoothManager bluetoothManager = (BluetoothManager) getSystemService(Context.BLUETOOTH_SERVICE);
2.再拿到BluetoothAdapter bluetoothAdapter = bluetoothManager.getAdapter();
判斷是否打開藍牙
未打開彈出 系統彈框 ，除了 魅族手機 是打開系統設置

設備/手機都是藍牙信號

在回調方法中:

一般在掃描的過程中,我們還會設置 設備過濾原則 (因為我只想要搜索到我們想要的設備,忽略無關設備)
如:從 scanRecord -- beacon -- beacon.type == 0xFF代表Manufacture,通過與嵌入式軟體定義 自己的 Manufacture值即可

用BluetoothDevice得到BluetoothGatt：

斷連:

關鍵問題:連接後一般要做什麼事?

( 必須在剛連接成功後2秒內app寫一個值給設備，否則會被設備斷開連接）

主要是讀寫 characteristic
gatt.wirteCharacteristic(mCurrentcharacteristic);

gatt.readCharacteristic(characteristic);

bluetoothGatt.setCharacteristicNotification(data, true);

真實工作中使用的藍牙庫BlueToothKit請參考我的另一篇博客:
android藍牙入門知識和優秀藍牙第三方庫BluetoothKit的使用

⑹ Android BLE藍牙連接異常處理

藍牙通信過程中異常很常見，大致有以下幾種：

1，連接

2，發現服務

3，讀寫

4，通知

連接失敗可能是設備端原因，也可能是手機端原因。不同的手機來自不同的廠家，用的不同的晶元和藍牙協議棧都會導致藍牙功能的表現不一致，這都會導致各式各樣的兼容性問題，可能有的手機連接成功率高，有的成功率低。設備端原因可能有些時候出現異常導致死機無響應，或某些參數設置得有問題。但對於Android應用層開發來說，能做的很有限，藍牙通信是在系統服務進程中處理的，我們無法跨進程改變系統的行為，如果是在一個進程我們還可能通過Hook等手段來調整其內在邏輯。另外應用層的介面只是將請求封裝傳遞給系統服務進程，並未做一些實質性的通信，所以應用層雖然是同一個進程的，但是Hook意義也不大。所以我們能做的僅僅是看怎樣調整介面的調用，使得整體穩定性更好一點而已。

連接失敗分兩種，一種是超時，一種是提前返回失敗。

關於超時，一般是設備不在周圍，或設備斷電未發廣播，或設備當前被其他人連接。系統默認超時為30s，通常返回133，我們也可以自己設置更短的超時時間，超時則closeGatt，然後重新連接。

關於提前返回失敗，一般是有明確的異常，可能是手機藍牙的異常或者設備異常。

這兩種情況建議closeGatt，延時500ms，然後重試。如果重試三次仍然失敗，則可以考慮提示用戶重啟手機藍牙，或者檢查設備是否正常工作。

還有一種情況，連接成功後沒過多久連接又斷開了，這有可能是設備主動斷開，連接成功後有的設備會等待鑒權，如果一定時間內手機端還未發起鑒權則設備端主動斷開。也可能連接信道不夠穩定導致斷開的，此時closeGatt並重新連接即可。

當連接斷開時，會收到onConnectionStateChanged回調，這個回調可能會有一定延時，甚至有5s以上。解決的辦法是輪詢，如每隔1s發起一次讀請求，如果連接斷了會立即返回失敗。

如果藍牙連接不穩定，可以考慮關掉WIFI，因為WIFI通常和藍牙共用一個天線。

有的手機上discoverService可能會回調不止一次onServiceDiscover，這個要注意防禦。

當連接建立後，可以由設備端發起更改連接間隔，這樣能加快後續發現服務以及數據讀寫的速度。有的手機discover service很慢，原因是connect interval太大了，有的手機會主動向設備發起更改connect interval，而有的手機卻不會。這樣的話connect interval相差就會很大，實踐中發現有的手機是7ms，有的手機是默認的50ms，所以發現service都要8s，甚至20s的都很尋常，這對用戶來說是無法忍受的。所以比較好的辦法是設備主動發起更改connect interval，而Android系統是沒有提供對應API的。

如果發現服務失敗，通常來說不用closeGatt，重試一下就好了。如果重試三次還失敗，建議清一下緩存，再closeGatt，重新連接。

讀寫失敗要看失敗的原因是什麼，如果是許可權問題，則需要和設備端確認是否開放了相應的讀寫許可權。也可能是要讀寫的character不存在，可能是設備端修改了固件，手機端需要刷新一下藍牙緩存，closeGatt再重新連接。如果是其它未知錯誤，則重試三次，仍然失敗則closeGatt。不過通常來說如果是因為連接出了問題導致讀寫失敗的，會收到onConnectionStateChanged回調，此時就不用再無謂的重試了，直接closeGatt，重新連接。

打開/關閉character的notify，必須等收到onDescriptorWrite回調之後才算結束，才能開始下一個任務。

如果打開notify失敗，則可以改成周期性輪詢的方式去查詢character的值。

可參考該文章

Android-BLE-Issues

⑺ Android BLE設置MTU大小（2020-08-20）

MTU是指在一個協議數據單元中（ Protocol Data Unit, PDU ) 有效的最大傳輸 Byte 。

不同的藍牙版本最大MTU不同，例如：藍牙4.2的最大MTU=247Byte（不一定正確，也有說是257Byte、也有說是241Byte），藍牙5.0的最大MTU=512Byte，有效的最大MTU還需要減去協議Byte、Opcode和Handler。
藍牙4.2：1Byte(Opcode)+2Byte(Handler)+244Byte(BATT)=247Byte（不一定正確）
藍牙5.0：512Byte不一定正確）

Added in API level 21
在 Android 中修改MTU很簡單只需要調用 BluetoothGatt#requestMtu（int MTU） 方法即可。 requestMtu（intMTU） 必須在發現藍牙服務並建立藍牙服務連接之後才能調用，否則 MTU 會默認為 20Byte 。如果調用成功會自定回調 BluetoothGattCallback 類中的 onMtuChanged(BluetoothGatt gatt, int mtu, int status) 方法。

注意：我看到一些文檔提到在 public void onServicesDiscovered(BluetoothGatt gatt, int status) { } 方法中設置 MTU ,但是親自嘗試之後不起作用。所以在連接成功之後立即設置 MTU ，成功之後再去搜索服務。

⑻ Android BLE低功耗藍牙開發極簡系列（二）之讀寫操作

這是Ble極簡系列的第二篇文章，上一篇 Android BLE低功耗藍牙開發極簡系列（一）之掃描與連接 主要是掃描連接，這一篇主要是讀寫操作。

在連接成功後，可以通過Gatt進行discoverServices()。

在mGattCallback 回調添加Servicest的相關回調

當返回的status == BluetoothGatt.GATT_SUCCESS時，進行讀寫以及通知相關的操作， 調用writeDescriptor()，注意設置setValue為ENABLE_INDICATION_VALUE，否則可能後續讀取不到數據。

設置成功，會在onDescriptorWrite方法進行回調，注意UUID_SERVICE，UUID_NOTIFICATION特徵值UUID，可以詢問公司固件端的開發人員，和開發人員配合修改。

讀取數據在onCharacteristicChanged方法中，注意進制間的轉換。

一定要進行讀寫開關操作，注意descriptor.setValue(BluetoothGattDescriptor.ENABLE_INDICATION_VALUE)，否則可能讀取不到數據。

喜歡可以關注博主 BleDemo

⑼ Android 6.0 掃描不到 Ble 設備需開啟位置許可權

最近總是有用戶反饋說APP掃描不到設備，讓我很費解了一段時間，尤其是華為和OPPO，公司還專門買了這款手機，然後測試沒問題，直到一個偶然，我把手機定位給關了，才發現這個問題，Android 6.0 掃描設備需開啟位置許可權，用戶突然一天把定位給關了，我們在掃描之前又沒檢測，唉，一個邏輯不嚴謹就會出現各種問題，現在記錄一下

許可權獲取

<uses-permission android:name="android.permission.BLUETOOTH"/> 使用藍牙所需要的許可權

<uses-permission android:name="android.permission.BLUETOOTH_ADMIN"/> 使用掃描和設置藍牙的許可權（申明這一個許可權必須申明上面一個許可權）

在Android5.0之前，是默認申請GPS硬體功能的。而在Android 5.0 之後，需要在manifest 中申明GPS硬體模塊功能的使用。

<!-- Needed only if your app targets Android 5.0 (API level 21) or higher. -->

    <uses-feature android:name="android.hardware.location.gps" />

在 Android 6.0 及以上，還需要打開位置許可權。如果應用沒有位置許可權，藍牙掃描功能不能使用（其它藍牙操作例如連接藍牙設備和寫入數據不受影響）

<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION"/>

除了上面的設置之外，如果想設置設備只支持 BLE，可以加上下面這句話

<uses-feature android:name="android.hardware.bluetooth_le" android:required="true"/>

同樣，如果不想添加 BLE 的支持，那麼可以設置 required="false"

然後可以在運行時判斷設備是否支持 BLE，

// Use this check to determine whether BLE is supported on the device. Then

    // you can selectively disable BLE-related features.

    if (!getPackageManager().hasSystemFeature(PackageManager.FEATURE_BLUETOOTH_LE)) {

        Toast.makeText(this, R.string.ble_not_supported, Toast.LENGTH_SHORT).show();

        finish();

    }

打開定位 (Location)

首先檢查定位是否打開，可以像下面這樣操作：

/**

* Location service if enable

*

* @param context

* @return location is enable if return true, otherwise disable.

*/

public static final boolean isLocationEnable(Context context) {

    LocationManager locationManager = (LocationManager) context.getSystemService(Context.LOCATION_SERVICE);

    boolean networkProvider = locationManager.isProviderEnabled(LocationManager.NETWORK_PROVIDER);

    boolean gpsProvider = locationManager.isProviderEnabled(LocationManager.GPS_PROVIDER);

    if (networkProvider || gpsProvider) return true;

    return false;

}

如果定位已經打開，可以搜索到 ble 設備；如果定位沒有打開，則需要用戶去打開，像下面這樣：

private static final int REQUEST_CODE_LOCATION_SETTINGS = 2;

private void setLocationService() {

    Intent locationIntent = new Intent(Settings.ACTION_LOCATION_SOURCE_SETTINGS);

    this.startActivityForResult(locationIntent, REQUEST_CODE_LOCATION_SETTINGS);

}

進入定位設置界面，讓用戶自己選擇是否打開定位。選擇的結果獲取：

@Override

protected void onActivityResult(int requestCode, int resultCode, Intent data) {

    if (requestCode == REQUEST_CODE_LOCATION_SETTINGS) {

        if (isLocationEnable(this)) {

            //定位已打開的處理

        } else {

            //定位依然沒有打開的處理

        }

    } else super.onActivityResult(requestCode, resultCode, data);

}

⑽ Android ble （藍牙低功耗） 中的坑和技巧

new ScanFilter.Builder().setServiceUuid(ParcelUuid.fromString("00007777-0000-1000-8000-00805f9b34fb");

此時可以根據manfacturerData來匹配自己設定的外圍設備

在BluetoothGattCallback中的關於此問題有三步回調
1、 public void onConnectionStateChange(BluetoothGatt gatt, int status, int newState)

2、 public void onServicesDiscovered(BluetoothGatt gatt, int status)
mBluetoothGatt.discoverServices()執行後得到的callback，如果狀態為GATT_SUCCESS，則可以獲取ble旁支發起廣播的service和descriptor，把廣播設為enable

3、 public void onDescriptorWrite(BluetoothGatt gatt, BluetoothGattDescriptor descriptor, int status)
只有這一步status == BluetoothGatt.GATT_SUCCESS，才可以真正的傳輸數據，如果在第一步或者第二步就開始傳輸數據，會在某些特定的case下導致未知的bug或者空指針錯誤

所以，在中心設備跟外圍開始連接後，你可以設定一個超時時間，在超時時間過後，依然沒能回調onDescriptorWrite並獲得BluetoothGatt.GATT_SUCCESS，則此次過程失敗，你可以根據實際情況進行重連或者提示錯誤

如果要傳輸大於20位元組的數據怎麼辦？

1、 系統mtu可以支持修改到512位元組，完成大數據量的傳輸。但是由於涉及到中心和旁支都需要修改，會造成很大的局限性和底層修改量，而且會觸發比如某些設備第一次修改不生效，另一個設備一次連接中只能修改一次等bug，非常不可取，十分不建議。

2、分包傳輸，自己設計協議分包傳輸是最可取的方案，需要注意的是在分包後，每一個包之間寫入數據需要設置間隔，比如100ms。

在做好5和6的基礎上，依然會在一些設備上出現，由於系統原因，ble剛開始的發送第一個數據出現丟包，請對此做出特殊處理。