[移动开发]Settings的蓝牙搜索过程分析

1.界面触发扫描

在Android原生的系统设置里面，点击添加新设备的“加号”按钮后，就会触发BluetoothScanningDevicesGroupPreferenceController的状态改变，然后去开启扫描：

protected void updateState(PreferenceGroup preferenceGroup) {
        super.updateState(preferenceGroup);
        if (shouldEnableScanning()) {
            enableScanning();   //打开扫描
        } else {
            disableScanning();
        }
    }

private void enableScanning() {
        mIsScanningEnabled = true;
        if (!mBluetoothAdapter.isDiscovering()) {
            mBluetoothAdapter.startDiscovery();
        }
		........
    }

意料中地会去调用BluetoothAdapter的开启扫描的方法。而BluetoothAdapter会通过Binder去远程调用Bluetooth协议栈里面的方法，发起扫描：

public boolean startDiscovery() {
    ......
            if (mService != null) {
                return mService.startDiscovery(getOpPackageName(), getAttributionTag());
            }
      .......
    }

这里的mService，就是IBluetooth的客户端代理，也就是说发起扫描的操作，是直接跟Bluetooth协议栈通信的，并没有经过BluetoothManagerService。

2.协议栈执行扫描

在Bluetooth里面会调到AdapterService里面的startDiscovery，经过一系列的权限检查之后，进入到native方法：

boolean startDiscovery(String callingPackage) {
       
        .......
            if (!Utils.checkCallerHasFineLocation(this, mAppOps, callingPackage, callingUser)) {
                return false;
            }
            permission = android.Manifest.permission.ACCESS_FINE_LOCATION;
        } else {
            if (!Utils.checkCallerHasCoarseLocation(this, mAppOps, callingPackage, callingUser)) {
                return false;
            }
            permission = android.Manifest.permission.ACCESS_COARSE_LOCATION;
        }

        synchronized (mDiscoveringPackages) {  //添加过的进程，才能收到后续的扫描结果
            mDiscoveringPackages.add(new DiscoveringPackage(callingPackage, permission));
        }
        return startDiscoveryNative();
    }

在JNI层就是通过bt_interface_t去操作hw硬件执行搜索扫描的动作了。

3.扫描结果反馈

在经过一阵搜索之后，如果有发现可用的设备，JNI层会通过JniCallbacks的deviceFoundCallback回调方法上来 :

void deviceFoundCallback(byte[] address) {
        mRemoteDevices.deviceFoundCallback(address);
    }

而管理远程设备的RemoteDevices则会把扫描到的设备信息通过广播发送给发起扫描的应用：

 void deviceFoundCallback(byte[] address) {
       ......
        Intent intent = new Intent(BluetoothDevice.ACTION_FOUND);
        intent.putExtra(BluetoothDevice.EXTRA_DEVICE, device);
        intent.putExtra(BluetoothDevice.EXTRA_CLASS,
                new BluetoothClass(deviceProp.mBluetoothClass));
        intent.putExtra(BluetoothDevice.EXTRA_RSSI, deviceProp.mRssi);
        intent.putExtra(BluetoothDevice.EXTRA_NAME, deviceProp.mName);

		//这里就是只会把广播发送给调用过搜索的应用
        final ArrayList<DiscoveringPackage> packages = sAdapterService.getDiscoveringPackages();
        synchronized (packages) {   
            for (DiscoveringPackage pkg : packages) {
                intent.setPackage(pkg.getPackageName());
                sAdapterService.sendBroadcastMultiplePermissions(intent, new String[]{
                        AdapterService.BLUETOOTH_PERM, pkg.getPermission()
                });
            }
        }
    }

这个时候我们再来看看设置应用接收广播的地方。

4.SettingsLib里面的逻辑

如果你只是单纯地看android/packages/Settings里面的代码，你会发现并没有广播接收的踪迹。
原来，这部分的代码是在android/frameworks/base/packages/SettingsLib 这里面，这样做的目的也是为了解耦和复用，把数据逻辑层封装好，可以对应多个业务层的应用。目前android系统里面的原生系统设置，除了有位于android/packages/Settings这个设置外，还有一个针对于Car的位于android/packages/Car/Settings，这是汽车系统里面的原生系统设置。

那接下来进入SettingsLib，接收扫描结果的是BluetoothEventManager这个类，其中定义了DeviceFoundHandler和ScanningStateChangedHandler这两个内部类，前一个是处理扫描到的设备，后一个是处理扫描状态的改变逻辑。

先看看DeviceFoundHandler：

private class DeviceFoundHandler implements Handler {
        public void onReceive(Context context, Intent intent,
                BluetoothDevice device) {
            short rssi = intent.getShortExtra(BluetoothDevice.EXTRA_RSSI, Short.MIN_VALUE);
            String name = intent.getStringExtra(BluetoothDevice.EXTRA_NAME);
          
            CachedBluetoothDevice cachedDevice = mDeviceManager.findDevice(device);
            if (cachedDevice == null) {
            	//缓存集合中添加新设备，并回调通知
                cachedDevice = mDeviceManager.addDevice(device);   
            } else if (cachedDevice.getBondState() == BluetoothDevice.BOND_BONDED
                    && !cachedDevice.getDevice().isConnected()) {
             //通知发现已绑定的设备
                dispatchDeviceAdded(cachedDevice);
                Log.d(TAG, "DeviceFoundHandler found bonded and not connected device:"
                        + cachedDevice);
            } else {
                Log.d(TAG, "DeviceFoundHandler found existing CachedBluetoothDevice:"
                        + cachedDevice);
            }
            cachedDevice.setRssi(rssi);
            cachedDevice.setJustDiscovered(true);
        }
    }

这里的处理大致分为两种情况，一种是新扫描到的设备，那么会在通过dispatchDeviceAdded回调给到应用；另一种是执行到cachedDevice.setRssi(rssi)时候，如果Rssi有变换，也会触发属性的改变：

void setRssi(short rssi) {
        if (mRssi != rssi) {
            mRssi = rssi;
            dispatchAttributesChanged();
        }
    }

上层的界面逻辑在收到接口的回调后，自然就是刷新UI界面。不过现在Android新版本Q(29)，源码里面已经是使用了prefrence的机制，使得数据自动关联起来，所以你会看到设置里的回调接口中虽然有参数，但是并没有使用：

 @Override
    public final void onDeviceAdded(CachedBluetoothDevice cachedDevice) {
        refreshUi();
    }

属性改变的回调接口写法，还是用了JAVA8的新特性，差点让我找不到：

public class BluetoothDevicePreference extends ButtonPreference {
	......
	private final CachedBluetoothDevice.Callback mDeviceCallback = this::refreshUi;
	......
}

5.Settings的循环扫描

再看看ScanningStateChangedHandler，它其实就是做了一个透传，就到上层的BluetoothScanningDevicesGroupPreferenceController里面了：

 public void onScanningStateChanged(boolean started) {
        if (!started && mIsScanningEnabled) {
            enableScanning();
        }
    }

这里其实就是在做一个循环的扫描操作。started为false，那就意味着本次扫描结束了，如果用户没有操作停止，那么mIsScanningEnabled就会是true，那么就会发起新一轮的扫描操作，这样不停的扫描，才能发现搜索到更多更完整的蓝牙设备。