淺談「Bluetooth」的權限管理與掃描機制

Android：Android APPs

RICK

18 min readJul 29, 2020

目的

了解如何在「Android」系統開發藍牙功能與其該具備的相關知識。

概要

「Bluetooth」，中文翻譯為「藍牙」，是一種無線通訊技術標準，是目前主流的通訊標準之一，廣泛地應用在「IOT」領域。

事實上，早期的藍牙由於規格的紊亂與技術的限制，在應用上並不理想，但隨著時間發展，藍牙的技術已趨於成熟，並且目前有關於藍牙的標準、規格皆由「藍牙技術聯盟」統一制定與維護。

備註：藍牙技術聯盟，英文全名為「Bluetooth Special Interest Group」，縮寫為「SIG」。

而本文要介紹的就是如何在 Android OS 上實作藍牙功能與應用。

正文

藍牙功能大致可以根據規格區分為兩大類，分別為「傳統藍牙：Bluetooth，BT」以及「低耗電藍牙：Bluetooth Low Energy，BLE」，其比較如下：

同樣地，在「Android」藍牙功能的開發也會依照當前設備所支援的規格不同而有使用不同的「API」，詳細可以參考「Google 官方文件」：

事實上，雖然「傳統藍牙」與「低耗電藍牙」是不同的機制，但同為「藍牙通訊」，其在開發上仍有著相當多類似的地方。

因此，在本文中，筆者會將兩者合併探討，並指出其相異的部份。

藍牙權限的管理

首先，是權限的部份。

由於安全性的考量，「Android」在「API 23」以後導入了權限管理的機制，因此，不論是「傳統藍牙」或是「低耗電藍牙」，只要是在「Android 6.0」以後，都會受到權限機制的影響。

與「藍牙功能」相關的權限，主要有以下三項，其分別為「BLUETOOTH」和「BLUETOOTH_ADMIN」以及「LOCATION」。

「BLUETOOTH」

如上圖所描述，與藍牙通訊中的「連線」有關，屬於「normal」等級的權限。

「BLUETOOTH_ADMIN」

如上圖所描述，與藍牙通訊中的「搜尋」、「配對」有關，屬於「normal」等級的權限。

「LOCATION」

根據官方文件所描述，因為藍牙功能可以用來蒐集或暴露位置相關的資訊，因此，若我們要使用藍牙功能，我們需要宣告「LOCATION」。

而根據規定，在「API 28」後，我們必需取得「ACCESS_FINE_LOCATION」的位置權限。

但在其之前的版本，我們可以用「ACCESS_COARSE_LOCATION」權限來取代「ACCESS_FINE_LOCATION」權限。

但不論上述而者，其皆屬於「危險級別」的權限。

備註：「ACCESS_FINE_LOCATION」和「ACCESS_COARSE_LOCATION」皆屬於「LOCATION」的「權限組」。

而權限加入的方式是在「AndroidManifest.xml」中，用「uses-permission」標籤進行宣告，如下：

<manifest ... >
  <uses-permission android:name="android.permission.BLUETOOTH" />
  <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" /><!-- If your app targets Android 9 or lower, you can declare
       ACCESS_COARSE_LOCATION instead. -->
  <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" /></manifest>

牽強的解釋

為什麼藍牙功能需要位置權限，上圖為「Google」在官方文件中的解釋。

但許多開發者認為「Google」的理由過於牽強，並不買單，事實上，該問題也曾在「Google」的「IssueTracker」上有過相關的「討論」。

同樣地，該問題也曾在「StackOverFlow」被討論過，可以參考「連結」，如下圖：

或是參考「此篇」，如下：

此外，雖然在官方文件中的描述是，使用「藍牙功能」需要取得「位置權限」。

但根據筆者的實際經驗，在某些「Android」設備中，使用「傳統藍牙」即使沒有取得「定位權限」，亦可以正常運作。

為什麼會這樣呢？

事實上，會有這麼多開發者指責「Google」，是有一定緣由的。

若讀者對這議題有興趣，筆者推薦這篇「A Curious Relationship: Android BLE and Location」，或許在你讀完了以後，你就會對「為什麼僅有『BLE』需要『位置權限』，而又為什麼有那麼多『開發者』指責『Google』？」。

但不論立場為何，筆者認為既然「Google」都已經在官方文件中明確表示使用「藍牙功能」須具備「定位權限」。

因此，筆者還是建議依照官方文件的敘述實作，以避免某些非預期的錯誤。

解套的「Companion Device Pairing」？

事實上，在權限這部份，「Google」在「API 26」以後，推出了「CDP」機制，在該機制中，就不再需要「位置權限」的取得。

其詳細介紹與實作方式可以參考小弟的另外一篇「文章」。

取得藍牙適配器

在處理權限的問題後，接著，就是要取得藍牙適配器。

就如同文件所描述，「BluetoothAdapter」是操作「藍牙功能」所必要的元件。

根據「設置藍牙」的敘述，「BluetoothAdapter」的取得可以藉由一靜態方法「BluetoothAdapter#getDefaultAdapter()」；若該方法返回「null」，則代表該設備不支援藍牙功能，如下：

但是，如果讀者們有特地去閱讀「BluetoothAdapter」的說明文件，就會發現它有這麼一段描述：

是的，它建議開發者們在「JELLY_BEAN_MR1，API 17」以下的版本才去使用「BluetoothAdapter#getDefaultAdapter()」來取得藍牙適配器；若版本高於「JELLY_BEAN_MR1」，則建議用「BluetoothManager#getAdapter()」的方式來取得「BluetoothAdapter」。

雖然這段敘述與「藍牙概覽」的內容並不衝突，但是就現行的專案來說，幾乎不會有專案會向下支援到「API 17」的版本。

下圖是「API 18」以上的支援程度：

下圖是「API 17」以上的支援程度：

是的，其「市占率不到 1%」，因此，筆者實在不懂為什麼「Google」不去修改其官方文件，也許是人力不足吧。

事實上，根據筆者實際經驗，即使 Android 的版本在「JELLY_BEAN_MR1」之上，同樣可以藉由靜態方法「BluetoothAdapter#getDefaultAdapter()」來取得藍牙適配器。

為什麼會有這樣的情況呢？

我們直接從源碼來分析，首先是「BluetoothManager#getAdapter」，其撰寫方式如下：

而我們接著去看「BluetoothManager」的是如何取得適配器，如下：

是不是突然懂了什麼？

是的，事實上，其兩者的差別僅在於對「Context」的管理。

而「getDefaultAdapter()」就如同文件講的，它是去獲取系統的「藍牙適配器」，如下：

源碼如下：

最後，還是那句老話，為了避免預期外的錯誤，筆者仍建議在實作上就遵循著官方文件的敘述。

確認設備是否具有藍牙功能

如上圖，如果「BluetoothAdapter」的回傳值為「null」即目前裝置的硬體設備不支援藍牙通訊的功能。

事實上，我們亦能根據「getDefaultAdapter()」的實作中知道這件事情。

啟用藍牙

在確認設備支援藍牙功能後，接著我們必須去確認藍牙是否被啟用。

但為什麼藍牙功能是可關閉？

因為早期的藍牙相當耗電，這是一件很嚴重的事情，尤其在行動裝置上。

在行動裝置的設計上，能源續航必然是最重要的課題之一，因此考量，藍牙的設計並非常駐，且預設幾乎都是關閉的。

但在藍牙第四代之後，藍牙耗電的情況被大幅改善，加上「IOT」的應用越發廣泛，因此，許多行動裝置的設計逐漸轉為「藍牙常駐」的設計。

當然，除了上述的原因之外，安全性的改善，也是使得「藍牙常駐」逐漸成為主流的原因之一。

但不論藍牙是否常駐，藍牙功能終究是可以被關閉的，因此，檢查藍牙功能是否啟動就是一件必須的事情。

在「Android」上，開發者可以透過「BluetoothAdapter#isEnabled()」來判斷，如下：

其結果等同於狀態「BluetoothAdapter.STATE_ON」，如下：

若目前設備的藍牙功能沒開啟，則有下列兩種方式開啟。

第一種是強制性的，藉由「BluetoothAdapter#enabled()」，但「Google」並不建議其用於一般產品的開發。

而另外一種則是透過帶有「ACTION_REQUEST_ENABLE」參數的「intent」去詢問使用者，實作代碼如下：

if (bluetoothAdapter?.isEnabled == false) {
    val enableBtIntent = 
     Intent(BluetoothAdapter.ACTION_REQUEST_ENABLE)
    startActivityForResult(enableBtIntent, REQUEST_ENABLE_BT)
}

同時，這也是「Google」建議的操作方式。