android5.0 (Lollipop) BLE Central Kind

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

Yesterday wrote the simple use of the Android L ble peripheral, today talk about the BLE central update.

People who have done android4.4 are certainly not unfamiliar with Bluetoothadapter's Startlescan function, but this interface is deprecated in Android L, but this interface is still available for compatibility with previous versions. But Google has taken out the Android.bluetooth.le class to handle BLE operations alone, so I recommend using the latest interface. If you want to be compatible with the previous version of L, you can use Android.os.Build.VERSION.SDK_INT or Android.os.Build.VERSION.RELEA plus a version to judge. Here's a formal look at the update for BLE scanner.

A total of 6 scan related classes (4 advertise related classes) have been added to the Android L Central, and these 6 classes make the scan related sections very thin. In accordance with the previous peripheral idea, we still follow the start of the scan process to learn this class.

1, about the decision whether to support Bluetooth, support BLE code I will not write, below I only paste the support ble centrial code:

[Java]View Plaincopy

1. Mbluetoothlescanner = Mbluetoothadapter.getbluetoothlescanner ();

This code and peripheral getbluetoothleadvertiser basically similar, general phone support BLE will support Central, unless it is itself just peripheral devices. This is not difficult, I will not waste time.

2, here directly into the scan action, the new interface to scan into two categories, one for:

[Java]View Plaincopy

2. /**
4. * Start Bluetooth LE scan with default parameters and no filters. The scan results'll be
6. * Delivered through {@code callback}.
8. * <p>
10. * Requires {@link Android. Manifest.permission#bluetooth_admin} permission.
12. *
14. * @param callback callback used to deliver scan results.
16. * @throws illegalargumentexception If {@code callback} is null.
18. */
20. Public void Startscan (final Scancallback callback) {
22. if (callback = = null) {
24. throw New IllegalArgumentException ("callback is null");
26. }
28. Startscan (null, new Scansettings.builder (). Build (), callback);
30. }

From the function you certainly understand, this is the direct search all around peripheral equipment, of course here you have to fill callback, specific I will speak below.

The second type is:

[Java]View Plaincopy

2. /**
4. * Start Bluetooth LE Scan. The scan results would be delivered through {@code callback}.
6. * <p>
8. * Requires {@link Android. Manifest.permission#bluetooth_admin} permission.
10. *
12. * @param filters {@link scanfilter}s for finding exact BLE devices.
14. * @param settings settings for the scan.
16. * @param callback callback used to deliver scan results.
18. * @throws illegalargumentexception If {@code settings} or {@code callback} is null.
20. */
22. Public void Startscan (list<scanfilter> filters, scansettings settings,
24. Final Scancallback callback) {  
26. Startscan (filters, settings, callback, null);
28. }

This is obviously a custom function, because he needs us to enter filter conditions. Here Scanfilter and scansettings are two scan classes, of course, the purpose of these two classes is mainly for some people want to develop applications for a product alone, filter conditions, such as devicename or a service UUID, etc. You can search for devices that target only specific peripheral features.

Take two conditions how do we use it, I write a bit for everyone, you can refer to my writing to add:

[Java]View Plaincopy

2. Add a filter to only scan for advertisers with the given service UUID
4. list<scanfilter> blescanfilters = new arraylist<> ();
6. Blescanfilters.add (
8. new Scanfilter.builder (). Setserviceuuid (Sample_uuid). Build ()
10. );
14. Scansettings blescansettings = Mblescansettingsbuilder.build ();
18. LOG.D (TAG, "Starting scanning with settings:" + blescansettings + "and filters:" + blescanfilters);
22. //Tell the BLE controller to initiate scan
24. Mbluetoothlescanner.startscan (Blescanfilters, blescansettings, Mblescancallback);

Looking at these two new interfaces alone, some people may be confused, should it be so soon? In fact, before the andoid L, the scan interface is not like this, it only a bit of two

[Java]View Plaincopy

1. @Deprecated
2. Public Boolean Startlescan (Lescancallback callback)

[Java]View Plaincopy

1. @Deprecated
2. Public Boolean Startlescan (final uuid[] Serviceuuids, final Lescancallback callback)

You will find that the original scan only through the service UUID to search, other conditions are not, so the new version of the interface for our custom application provides a great convenience.

3, search finished, that will get scan of the callback. In this case, I'll take the first format.
Scancallback has three callbacks, of course callback is also a separate class, here I only talk about our useful onscanresult (int callbacktype, scanresult result), for everyone to understand, I'll show you the results of my search directly:

[Plain]View Plaincopy

1. <span style= "FONT-SIZE:14PX;" >callbacktype:1
2. Scanresult{mdevice=b4:52:7e:9a:41:a8,mscanrecord=scanrecord [madvertiseflags=6,mserviceuuids=[ 00001804-0000-1000-8000-00805F9B34FB,
3. 00001802-0000-1000-8000-00805f9b34fb,00001803-0000-1000-8000-00805f9b34fb,00000200-37cb-11e3-8682-0002a5d5c51b ],
4. mmanufacturerspecificdata={}, Mservicedata={},mtxpowerlevel=0, mdevicename=xxxx],mrssi=-43, mTimestampNanos= 352640634804615}</span>

From this result can be seen, now scan returns the results obviously increased, in fact, from the results should be able to understand, the second set of filters will have what parameters can let you set.

You see these results you must faint, how to take out, this is used in the scan related classes of the last two classes Scanresult and Scanrecord. These two classes are mainly used to parse your scan data, I also put a little bit of code here, if you need other results, you can refer to:

[Java]View Plaincopy

2. Bluetoothdevice device = Result.getdevice ();
4. LOG.D (TAG, "Device name:" + device.getname ());
6. LOG.D (TAG, "Device address:" + device.getaddress ());
8. LOG.D (TAG, "Device service UUIDs:" + device.getuuids ());
12. Scanrecord record = Result.getscanrecord ();
14. LOG.D (TAG, "Record advertise flags:0x" + integer.tohexstring (Record.getadvertiseflags ()));
16. LOG.D (TAG, "Record Tx Power level:" + record.gettxpowerlevel ());
18. LOG.D (TAG, "Record device Name:" + record.getdevicename ());
20. LOG.D (TAG, "Record service UUIDs:" + record.getserviceuuids ());
22. 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, this people should be very familiar with a postdelay as follows:

[Java]View Plaincopy

1. Post a future task to stop scanning after (default:25s)
2. Mhandler.postdelayed (new Runnable () {
3. @Override
4. public Void Run () {
5. Stopscanning ();
6. }
7. }, Default_scan_period);

or call stop directly, where the stopscanning is implemented as follows:

[Java]View Plaincopy

1. Private void stopscanning () {
2. if (mbluetoothlescanner! = null) {
3. LOG.D (TAG, "Stop scanning.");
4. Mbluetoothlescanner.stopscan (Mblescancallback);
5. }
6. }

The rest is Connectgatt. This is the same as before and there is no change at the moment.

OK, for Google's newly added android.bluetooth.le this package is resolved, the next few days to see how the Android L system is implemented.

android5.0 (Lollipop) BLE Central Kind