nRF Toolbox gathers BLE profile tools into one foreground service

A container for the standard Bluetooth profile set

The nRF Toolbox is a container app that stores your Nordic Semiconductor apps for Bluetooth Low Energy in one location, and the apps it contains demonstrate standard Bluetooth LE profiles.

The list is the product. Cycling Speed and Cadence, Running Speed and Cadence, Heart Rate Monitor, Blood Pressure Monitor, Health Thermometer Monitor, Glucose Monitor, Continuous Glucose Monitor, Universal Asynchronous Receiver/Transmitter, Throughput, nRF Distance Measurement, Blinky (LBS) Service, and Channel Sounding Service.

The set covers the health profiles, the two fitness profiles, a serial profile and several service-level tools. Each is a small application against a standard GATT profile, which is the point: a developer who needs to talk to a heart rate sensor does not have to write an Android app to read the Heart Rate Service, and a developer testing a prototype can use the same tool for the profile their device implements.

The note on platform support is specific. Android 6.0 or newer is required, and Android 5.0 was supported until version 4.1.4. Compatibility is described as covering nRF5 devices running samples from the Nordic SDK and other devices implementing standard profiles, so the tool is not limited to Nordic's own hardware even though the vendor is Nordic.

One profile is missing and the README is explicit about it. The Proximity profile is not included in this version, and the note points to the previous version, release 3.3.1, for anyone who needs it. That is a useful signal about how the app is curated: when a profile is dropped, the old release stays available rather than being deleted.

The releases are 4.3.5 in July 2026, 4.4.0 at the end of July and 4.4.1 in August, with the last push on 2026-10-13.

One foreground service holds every connection

The ProfileService is the architectural centre of the app, and the README describes it in engineering detail.

The service is responsible for managing Bluetooth Low Energy connections in a centralised way. It runs as a foreground service, maintaining connections to multiple devices, handling lifecycle events, and exposing device data to bound components such as activities or fragments.

The key property is that the connections are kept alive independently of the activity lifecycle. When the UI component unbinds from the service, the connections remain active, ensuring uninterrupted data flow. For a tool that is often used with the screen off or while you walk away from the phone, that is the difference between a usable tool and a tool that drops the connection every time you switch apps.

The features list spells out the rest. A single service for all devices, rather than a separate service per device. Connection lifecycle handling that starts a connection when onStartCommand is triggered with a device address, cleans up and disconnects gracefully when no devices remain connected, and publishes disconnection events with reasons for the UI to handle.

Device state management keeps a map of devices and their DeviceData, which covers address, state and services, tracks missing services, and notifies observers if required services are unavailable. That last point is worth noting, because a peripheral that advertises a profile but does not implement all its services is a common and confusing failure, and the tool tells you about it rather than showing an empty chart.

Service discovery happens after connection, and new profiles can be added by implementing a ServiceManager subclass. Logging integrates with nRF Logger to provide per-device logs, with each device connection initialising its own logger instance.

UART for prototyping, and DFU has moved out

The UART profile gets its own section because it does something different from the health monitors.

The README says the UART profile allows for fast prototyping of devices, and that the service itself is very simple, having just two characteristics, one for sending data and one for receiving. A UART preset configuration can be created as a separate profile, and each preset, when pressed, sends the stored command to the device. The UART profile is included in the profile list and is managed in the same way as the others.

That is a genuinely useful pattern for hardware work. A stored command that you can fire at a device in one tap is much faster than opening a terminal and typing a hex string every time, and the fact that a preset is a profile rather than a special case means it participates in the same connection machinery.

The other thing in this section is a removal, and it is the kind that matters for anyone upgrading. The Device Firmware Update feature has been removed from this application and is now offered in nRF DFU, for devices with Legacy and Secure DFU from the nRF5 SDK, or in nRF Connect Device Manager, for devices based on the nRF Connect SDK or Zephyr.

The split is a sensible one. DFU is a substantial feature with a security surface, and a Bluetooth Secure DFU implementation in a demo app is a liability. Moving it to a dedicated tool that covers both the legacy nRF5 path and the newer Zephyr based path is the right call, but it does mean that updating a device's firmware is now a two-app workflow rather than one.

The module layout separates the framework from the profiles

The repository layout shows a modular Android project, and the directory names are the clearest description of the design.

There are five lib_ directories. lib_analytics is the analytics layer, lib_service holds the service infrastructure, lib_storage is persistence, and lib_ui is shared UI. lib_utils holds utility code.

The profile side is split three ways. profile/ holds the profile implementations, profile_data/ holds the data model behind them, and profile_parsers/ handles parsing, which is where the per-profile wire format differences live. profile_manager/ sits above them and presumably owns the registry of available profiles.

Splitting the parsers out from the profile UI is the part worth noticing. Each standard profile has its own data layout, and a parser per profile keeps the shared UI code free of profile-specific conditionals. It also means adding a profile, which the README says you do by implementing a ServiceManager subclass, touches the profile layer and the parsers rather than the service.

The app/ directory holds the application itself, with build.gradle.kts and settings.gradle.kts at the top level, gradle.properties, the gradlew wrapper, and a fastlane/ directory, which is the release automation used to push builds to the Play Store. There is a renovate.json, so the dependency updates are automated, and a Gemfile at the root, which is usually there for fastlane's Ruby dependencies.

The primary language is Kotlin, and the licence is BSD-3-Clause with a LICENSE file at the top of the tree.

The dependency stack and what it means for an Android developer

The dependency list is short and each entry is named with a reason, which is what you want to see in a vendor's sample app.

The production version depends on the Kotlin BLE Library for Bluetooth LE connectivity, and on the Nordic Android Common Library, which contains utility classes such as the Bluetooth LE permission handler and the Bluetooth LE scanner. The Kotlin BLE Library may be cloned into the same root folder as this app, which is the usual arrangement when you want to work on the transport layer itself.

Then there is the nRF Logger API library, which allows the app to create log entries in nRF Logger, the separate Nordic app. The README says to read the library documentation on GitHub for more information about the usage and permissions, which is a reminder that the logging integration has its own permission model.

The Kotlin-Utils-Library is used for ByteArray operations during profile data parsing, which is exactly the kind of low level work that a shared utility library should own, since the profile parsers are where byte level handling concentrates.

The chart in the heart rate profile is built with MPAndroidChart v3.1.0, which the README credits as a contribution based on the Apache 2.0 licence. So the app itself is BSD-3-Clause and it pulls in an Apache 2.0 charting library, and the attribution is in the README rather than buried in a notices file.

The practical note for anyone importing the toolbox into Android Studio is that the BLE stack is a separate library with its own version, and that the app is not self-contained in the sense of having no external Nordic dependencies.

Editorial conclusion

nRF Toolbox suits a Bluetooth developer who wants to exercise several standard GATT profiles against real hardware without writing an app for each one, and it is the wrong tool if you need device firmware update, since the README says that feature has been removed and moved to nRF DFU and nRF Connect Device Manager. Before building against it, note that the Proximity profile is not in this version and that the README points to release 3.3.1 if you need it. Verify first that your target device implements a standard profile rather than a vendor specific one, since the app is built around the standard profile set.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. nordicsemi/Android-nRF-Toolbox on GitHub
3. Project website
4. README
5. Releases