Android l ble Central (small) cow test, androidble

Android l ble Central (small) cow test, androidble

Reprinted please indicate by: http://blog.csdn.net/lansefeiyang08/article/details/46482073

Yesterday I wrote a simple example of android l ble Peripheral. Today I will talk about the update of BLE Central.

People who have worked on android4.4 will certainly be familiar with the startLeScan function of javasthadapter, but this interface has been abandoned in android L. However, this interface can still be used to be compatible with previous versions. However, Google has independently developed the android. bluetooth. le class to process BLE operations, so I suggest using the latest interface development. To be compatible with versions earlier than L, you can use android. OS. Build. VERSION. SDK_INT or android. OS. Build. VERSION. RELEA to add a VERSION. Now let's get to know about the update of BLE notebook.

In android L Central, a total of six scan-related classes (four advertise-related classes) are added. These six classes detail the scan-related sections. According to the previous Peripheral idea, we still learned this class according to the scan startup process.

1. I will not write the code to determine whether Bluetooth and BLE are supported. Below I will only post the code that supports BLE centrial:

mBluetoothLeScanner = mBluetoothAdapter.getBluetoothLeScanner();

This code is similar to Peripheral's getjavasthleadvertiser. Generally, mobile phones support BLE and support Central unless it is a Peripheral device. This is not hard. I will not waste my time.

2. The scan action is directly entered here. The new interface divides scan into two types:

    /**     * Start Bluetooth LE scan with default parameters and no filters. The scan results will be     * delivered through {@code callback}.     * <p>     * Requires {@link android.Manifest.permission#BLUETOOTH_ADMIN} permission.     *     * @param callback Callback used to deliver scan results.     * @throws IllegalArgumentException If {@code callback} is null.     */    public void startScan(final ScanCallback callback) {        if (callback == null) {            throw new IllegalArgumentException("callback is null");        }        startScan(null, new ScanSettings.Builder().build(), callback);    }

You will understand from the function. This is to directly search for all the surrounding peripheral devices. Of course, you need to enter callback here.

The second type is:

    /**     * Start Bluetooth LE scan. The scan results will be delivered through {@code callback}.     * <p>     * Requires {@link android.Manifest.permission#BLUETOOTH_ADMIN} permission.     *     * @param filters {@link ScanFilter}s for finding exact BLE devices.     * @param settings Settings for the scan.     * @param callback Callback used to deliver scan results.     * @throws IllegalArgumentException If {@code settings} or {@code callback} is null.     */    public void startScan(List<ScanFilter> filters, ScanSettings settings,            final ScanCallback callback) {        startScan(filters, settings, callback, null);    }

This is obviously a customized function because we need to input filtering conditions. Here, ScanFilter and ScanSettings are two scan classes. Of course, the purpose of these two classes is to allow some people to develop applications for a product separately and add filter conditions, for example, DeviceName or a Service UUID can be used to search for devices with specific Peripheral features.

How can we use them with two conditions? I want to write something for you. You can refer to what I wrote and add it by yourself:

// add a filter to only scan for advertisers with the given service UUID        List<ScanFilter> bleScanFilters = new ArrayList<>();        bleScanFilters.add(                new ScanFilter.Builder().setServiceUuid(SAMPLE_UUID).build()        );        ScanSettings bleScanSettings = mBleScanSettingsBuilder.build();        Log.d(TAG, "Starting scanning with settings:" + bleScanSettings + " and filters:" + bleScanFilters);        // tell the BLE controller to initiate scan        mBluetoothLeScanner.startScan(bleScanFilters, bleScanSettings, mBleScanCallback);

Looking at these two new interfaces separately, some may be confused. Should this be the case soon? In fact, before Andoid L, the scan interface is not like this, it only has two types

    @Deprecated    public boolean startLeScan(LeScanCallback callback) 

@Deprecated    public boolean startLeScan(final UUID[] serviceUuids, final LeScanCallback callback) 

You will find that the original scan can only be searched through the service UUID, but not any other conditions, so the new version of the interface provides great convenience for our custom application.

3. After the search is complete, you will get the scan callback. Here, I will use the first format.
ScanCallBack has three Callbacks. Of course, callback is also a separate class. Here I will only talk about the onScanResult (int callbackType, ScanResult result) that is useful to us. For your understanding, I will show you the search results:

<span style="font-size:14px;">callbackType:1ScanResult{mDevice=B4:52:7E:9A:41:A8,mScanRecord=ScanRecord [mAdvertiseFlags=6,mServiceUuids=[00001804-0000-1000-8000-00805f9b34fb,00001802-0000-1000-8000-00805f9b34fb,00001803-0000-1000-8000-00805f9b34fb,00000200-37cb-11e3-8682-0002a5d5c51b],mManufacturerSpecificData={}, mServiceData={},mTxPowerLevel=0, mDeviceName=××××],mRssi=-43, mTimestampNanos=352640634804615}</span>

From this result, we can see that the results returned by scan are significantly increased. In fact, you can understand the results as well. What parameters can be set for filtering in the second setting.

If you see these results, you must be dizzy. How can we take them out? The last two classes of the Scan-related class ScanResult and ScanRecord are used. These two classes are mainly used to parse the data after your scan. I also post a bit of code here. If you need other results, refer:

        BluetoothDevice device = result.getDevice();        Log.d(TAG, "Device name: " + device.getName());        Log.d(TAG, "Device address: " + device.getAddress());        Log.d(TAG, "Device service UUIDs: " + device.getUuids());        ScanRecord record = result.getScanRecord();        Log.d(TAG, "Record advertise flags: 0x" + Integer.toHexString(record.getAdvertiseFlags()));        Log.d(TAG, "Record Tx power level: " + record.getTxPowerLevel());        Log.d(TAG, "Record device name: " + record.getDeviceName());        Log.d(TAG, "Record service UUIDs: " + record.getServiceUuids());        Log.d(TAG, "Record service data: " + record.getServiceData());

The result here is the return value of onScanResult (int callbackType, ScanResult result.

4. The last step is stop. You should be familiar with it. Use postdelay as follows:

        // post a future task to stop scanning after (default:25s)        mHandler.postDelayed(new Runnable() {            @Override            public void run() {                stopScanning();            }        }, DEFAULT_SCAN_PERIOD);

Or call stop directly. The stopScanning implementation here is as follows:

    private void stopScanning() {        if (mBluetoothLeScanner != null) {            Log.d(TAG, "Stop scanning.");            mBluetoothLeScanner.stopScan(mBleScanCallback);        }    }

The rest is connectGatt. This is the same as before and remains unchanged.

OK. The package android. bluetooth. le added by google is completely parsed. We will see how it is implemented in the android L system in the next few days.