A Guide to Android Bluetooth Low Energy

Bluetooth Low Energy (BLE) is well-known for its ability to take up very little power and still offer the best connectivity to link with small devices. This feature is attracting more and more people who are looking to develop Android apps. Regrettably, the Android SDK’s BLE API has plenty of undocumented pitfalls. Nevertheless, the BLE platform commands over 76% of the market share globally.  

In this post, we’ll cover the basics of BLE that is a must-know for Android developers, and take you through some of the common BLE operations on Android.

Difference between BLE from Bluetooth Classic

BLE’s “Low Energy” portion of the acronym is the key, while Bluetooth Classic is designed for communicating ongoing streams of data like music playback. BLE is enhanced for delivery power efficiency operations. Typically, a BLE device can operate on a small battery for weeks together, if not months or even years. Thus, it is very suitable for use cases based on sensors or the Internet of Things (IoT).

Another significant difference between BLE and Bluetooth Classic is that BLE is much more developer-friendly. BLE makes way for a world of limitless possibilities by letting the developers mention several custom profiles for various use cases. Bluetooth Classic principally supports the Serial Port Profile (SPP) for transmitting custom data. The Android Bluetooth API is also not very up-front to function with for Bluetooth Classic use cases owing to the below whys and wherefores:

• The Bluetooth Classic scanning API makes use of a BroadcastReceiver, which is quite messy, multicast in nature, and usually not used in current BLE Android app development.
  
• Before you can set up an RFCOMM link, the Android SDK needs Bluetooth Classic devices to be paired with Android, while this restriction is not imposed on BLE use cases.
  
• The Android SDK offers implementation only for a restricted number of Bluetooth Classic profiles.
  
• Once the pairing and connection are established, you need to sign up and handle a dedicated Android Thread object by yourself. Only then can you communicate with a Bluetooth Classic device through the BluetoothSocket object. It provides flexibility; however, it is also prone to errors at the same time.
  

The central-peripheral relationship in BLE

Your Android device behaving as a central element can link with several external BLE peripheral devices concurrently. Nevertheless, each BLE device in the peripheral place can typically interact only with one central device at a given time. Whenever a BLE device establishes a connection to a central device, the most common behavior is that it’ll halt advertising as a peripheral as it is no longer able to connect with it.

It also helps to think of the central, peripheral relationship between a BLE central and BLE peripheral devices similar to a client-server relationship. The peripheral server hosts a GATT database that offers information that the client, the central device, can access the information through BLE. It’s vital to note that your Android device can also act like a peripheral; however, for this post, we’ll focus on the much more popular setting of it behaving like a BLE central.

The overview of the possibilities with BLE communication can be categorized into three basic BLE operations:

• Write: bytes of information is written by the client (app) to a characteristic or descriptor present on the server (BLE device). The server’s firmware then processes the write, and certain server-side operations are performed in response to it. For instance, a smart thermostat may be capable of altering the target temperature when written to.
  
• Read: The value of a descriptor or a characteristic on the server-side (BLE device) is read by the client (app). It interprets the write depending upon a protocol that has been set up earlier. A smart thermostat may possess a characteristic whose value signifies the existing target temperature.
  
• Notify/Indicate: For mentioning the notifications or indications, the client (app) contributes to a characteristic and is informed by the server when the value of that particular characteristic is modified. A smart thermostat may possess a notifiable characteristic that will mention the variations in the ambient temperature when it is being subscribed.

Android Bluetooth Low Energy Best Practices

Here are some of the implementation examples to save time to portray the plain basics of functioning with Android BLE APIs.

• Strings displayed to the user on the UI screen are hardcoded in the form of string literals in code rather than extracting it into a localizable strings.xml file. It very much enhances the code readability and makes the intent simple to follow. You need to be extracting these strings into your strings.xml file for your BLE Android apps.
  
• The entire code belonging to a screen is fit into the Activity class on that screen. You should find out if some portion of the code is capable of being refactored out into a simple helper class or passed on to a separate entity, like a ViewModel class.
  
• Managing edge cases and UX are retained to a bare minimum, which is sufficient for the app to function smoothly and manage the errors. More advanced error-handling flows are necessary for a production-level app, and it must have the potential to educate the users on various error recovery methods.
  
• Kotlin’s error(…) function throws an IllegalStateException that’ll smash the app when prerequisites for particular operations are not encountered. Simply said, we assume that all the pieces of information are always present whenever it is required. In your own app, you should manage errors by displaying them to your users, rectifying them yourself, or by sensibly ignoring them.

Conclusion

The flow of a BLE is simple. Setting up BLE, Finding other BLE devices, establishing a connection to a GATT server, reading the BLE attributes, receiving notifications, and finally closing the client app. Always it is best not to perform BLE sequentially but to wait for a call back from the previous operation before commencing the next. As of Android 9, avoid using reflection to call private APIs. It is best to assume that any operation has a nonzero failure probability. You need to be aware of certain pitfalls while getting started with BLE development on Android. For more information on BLE android, get in touch with our experts.

Author BIO : 

Lisa Crisman is a Professional Digital Marketing Manager at BLE Mobile Apps. He would like to share content on different aspects of the IT industry like Beacon App, iBeacon App, Wearable Apps, BLE Android App, Eddystone Beacon App. He specializes in Web Development, Mobile App & Software related latest trending blogs.