We at Bitkey operate by dividing people’s life into three sectors—home, workspace, and experience (i.e. out-of-ordinary experiences)— and as part of our business, we develop a home-grown smart lock solution through which people can use their smartphones to open door locks. By retrofitting and expanding with our devices not only standard doors but also auto entrance doors and elevators, we provide consistent user experience tailored to diverse industry and business categories such as access control solutions for delivery services, homemaker services, and buildings.

One of our primary tech topics in achieving this value is BLE used in communication between Bitkey devices and smartphones. This article shares tips for handling BLE on Android and the structure we arrange to develop Android apps for home-grown devices.

Android BLE

Suggestions that appear when you type “Android BLE” in the search bar

“Terrible” or “unstable” are the keywords you see upon searching the term Android BLE. There are in fact countless articles and presentations chronicling the trouble people endured as to Android’s BLE, and they have been very useful for me too. Today I would like to present to you a certain specialist who might just overturn the poor reputation. That’s the NordicSemiconductor/Android-BLE-Library.

Screenshot of my post, where I realize nobody can beat specialists

A Norwegian BLE System-on-Chip developer called Nordic Semiconductor created this library. README starts with a reassuring line:

An Android library that solves a lot of Android's Bluetooth Low Energy problems.

This summarizes Android BLE-related hardships that this company must have survived. For instance, the library cleverly works around potential bugs that occur in the connectGatt method, depending on the SDK version.

Working around the connectGatt issue

The library offers even more, with its elaborate support for various interfaces. Support for LiveData (no.nordicsemi.android:ble-livedata) and Kotlin’s Suspend and Flow (no.nordicsemi.android:ble-ktx) allows for a smooth link-up with ViewModel and Jetpack Compose. For BLE-related problems, rely on BLE specialists, not web engineers.

BLE connection

As far as BLE connection (BleManager in the Android-BLE-Library) is concerned, lifetime and other features are different from data in typical Android development. ViewModel and its associated Repository/DataStore can handle the connection, but considering the behavior displayed upon switching to a different app or entering sleep mode, I recommend maintaining foreground service. Keep the connection as long as possible, though you do need to mind the power consumption of your device as it takes time to establish connection after initial device identification.

Create a connection pool when using a single Android terminal to simultaneously connect with multiple BLE devices. To keep things simple, I recommend managing the Android-BLE-Library BleManager with android.util.LruCache. If necessary, re-connect and disconnect at the timing of removal from LruCache. To dig deeper, I suggest mimicking connections with such databases as RDB.

Standard specifications commonly used in BLE, including GATT, typically serve some extent of roles equivalent to Internet protocols like TCP, UDP, or TLS. But an app developer would want a REST API layer to compensate missing elements. As such, my guess is that BLE device-developing companies have built a protocol of some sort upon GATT. At least that’s what we do. I recommend placing that protocol alongside Room or Retrofit.

Building a system to coordinate with device development

Some app developers work on business or user experience areas too, but I think BLE-related sectors should be a specialized area. Talented engineers capable of simultaneously addressing app and BLE issues are a rare find. I think this issue is manifesting as an organizational challenge, despite Bitkey having managed to get by since its founding.

A representative challenge of ours is the development of an app that mass-production plants use for inspections. Given our GATT-based protocol, we need to provide a dedicated app to the plant, but this process was personally handled by relevant staff members as a gesture of generosity.

There’s also a chicken-or-egg issue related to tests: we need our device to test the app, but the app is necessary for developing the device. Pairing up with firmware engineers involved in the device is a possible strategy, but from a broader perspective, a loose-coupled approach is the better solution if you consider engineering and scheduling aspects.

To solve these issues, Bitkey is moving to arrange a team that manages a feature covering multiple apps and BLE devices, while also supporting that feature and developing a tool for development/validation. By managing a feature and developing a tool simultaneously, we hope to take steps for our internal BLE engineering. Android has an advantage over iOS on this front as to home-grown tools leveraged internally or at plants. This is because the ability to operate terminals in relatively free ways and the easy control over releases allow us to make quick and flexible responses.

We want this team to efficiently connect smartphone app and device developers going further. I hope this vision turns into a reality and I get to share about it with a fancy name—perhaps SET, or maybe SRE.

Summary

• Using the NordicSemiconductor/Android-BLE-Library allows for avoiding various issues that arise when directly handling Android SDK’s BLE API.
• For BLE connection, we recommend managing with a connection pool in foreground service and developing a layer similar to Room or Retrofit.
• We are considering a dedicated BLE engineering unit as a plan for our organizational structure.

We at Bitkey actively use BLE as a means to connect smartphones with our home-grown devices that handle physical phenomena. Contact us if you’re interested at all in this type of Android and development endeavor.

About the author

Masatoshi Tsushima

I joined Bitkey in 2018. After primarily working on server-side development, I am now in charge of developing built-in software for devices. But I occasionally step out of my field of duty, as I did for this Android article.