BLE：BluetoothAdapter#getRemoteDevice()获设备与扫描对比及直连问题

Hey there, let's tackle your BLE questions head-on since Android 5.0's BLE stack can definitely throw some curveballs. I'll break this down into two clear sections: getting a solid direct connection, and comparing the two ways to grab a BluetoothDevice.

Android 5.0's BLE implementation has a few quirks, but follow these steps to boost your connection success rate:

• Lock in the right permissions: You'll need BLUETOOTH and BLUETOOTH_ADMIN permissions in your manifest. Unlike newer Android versions, API 21 doesn't require location permissions for BLE operations, so you can skip those for now.
• Ensure Bluetooth is active: Before attempting a connection, check if the BluetoothAdapter is enabled. If not, request the user to turn it on via startActivityForResult() with BluetoothAdapter.ACTION_REQUEST_ENABLE—don't try to enable it programmatically without user consent (it's bad practice and can cause stack instability).
• Avoid scan-connection conflicts: API 21's stack doesn't handle simultaneous scanning and connecting well. If you were scanning prior to connecting, explicitly stop the scan first using BluetoothLeScanner.stopScan() before calling connectGatt().
• Use the correct autoConnect flag: For your use case (connect, send a command, disconnect immediately), set autoConnect = false when calling device.connectGatt(context, false, gattCallback). The true value is meant for background reconnection (like keeping a persistent link to a smartwatch), and it can delay or fail immediate connection attempts.
• Handle connection state callbacks carefully: In your BluetoothGattCallback, pay close attention to onConnectionStateChange(). If you get an error code like 133 (a common API 21 connection failure), implement a limited retry logic with a 1-2 second delay—don't spam retries, as this can clog the BLE stack.
• Validate the MAC address: Double-check that the device's MAC address is in the correct format (e.g., AA:BB:CC:DD:EE:FF, uppercase or lowercase works, but no extra characters). Passing an invalid address to getRemoteDevice() will throw an IllegalArgumentException.
• Watch for stack caching issues: API 21 sometimes caches old device data. If you're seeing persistent connection failures after a device reboot, try restarting Bluetooth on the tablet or your app to clear the cache.

Let's break down the key differences and when to use each:

BluetoothAdapter.getRemoteDevice(String macAddress) #

• How it works: Creates a BluetoothDevice object directly using the device's MAC address, no scanning required. This doesn't check if the device is actually in range or broadcasting—it just creates the object.
• Best for your scenario: This is perfect for your use case! Since you know the device is always broadcasting and you likely have its MAC address (either pre-configured, stored after a first-time scan, or provided by the user), you can skip scanning entirely. It's faster, uses less battery, and avoids the overhead of scanning.
• Gotchas:
  • You must have a valid MAC address—invalid formats will throw an exception.
  • Even if the device is out of range, the object will be created, but your connection attempt will fail. Always handle connection failure callbacks gracefully.

Scanning for BluetoothDevice #

• How it works: Uses BluetoothLeScanner.startScan() (API 21+) to listen for BLE broadcast packets. You get a ScanResult containing the BluetoothDevice plus extra data like the device name, service UUIDs, and manufacturer-specific data.
• When to use it:
  • You don't know the device's MAC address (e.g., dynamic random MAC addresses, or you're discovering new devices).
  • You need to verify the device is actively broadcasting before connecting (useful if the device might be offline).
  • You need to filter devices by broadcast data (e.g., only connect to devices advertising a specific service UUID).
• Gotchas:
  • Scanning drains battery, so stop the scan as soon as you find your target device.
  • While API 21 doesn't require location permissions, newer Android versions do—if you plan to upgrade later, keep that in mind.
  • Scanning can take time (depending on broadcast intervals), so it's slower than using a known MAC address.

Since your device is always broadcasting and you need a quick connect-send-disconnect flow, use getRemoteDevice() with the known MAC address. It's the most efficient approach and avoids the pitfalls of scanning for your specific use case. Just make sure to handle connection failures with a small number of retries, and always clean up the BluetoothGatt instance properly after disconnecting (call close() to free up stack resources).

内容的提问来源于stack exchange，提问作者Robert