Android-DFU-Library: how Nordic ships BLE firmware updates to nRF5 devices

The library targets a bootloader, not a chip family alone

This is a firmware update path, and the unit of compatibility is the bootloader rather than the silicon. The README states that the DFU is designed to update firmware of nRF51 or nRF52 Series SoCs having either an nRF5 SDK Secure Bootloader, version 12.0.0 or newer, or an nRF5 SDK Legacy Bootloader, version 4.3.0-11.0.0. Everything else in the repository is downstream of that statement.

The concrete use case is a product already in the field. The nRF5x chips are flash based SoCs, and the README describes over the air device firmware upgrade as the mechanism that lets OEMs fix bugs and introduce features in products that are already on the market. The transport is Bluetooth Low Energy, which is why the library lives on Android and why the whole repository is a phone side tool.

The audience is therefore narrower than a generic OTA updater. You need an Android phone or tablet, a peripheral running the DFU bootloader, and a firmware package built with nRF Util. If your device fleet is controlled by a backend or an iOS app, this library does nothing for you, and if your devices use a different Nordic bootloader generation you are outside the documented range. The repository also carries an app module alongside the library, so the same codebase serves both an embeddable component and a standalone phone tool.

Secure DFU and Legacy DFU differ in how a failed update recovers

The two bootloader generations are not just version numbers, they behave differently mid transfer, and the README's DFU history section spells out why. Legacy DFU began at SDK 4.3.0 with application update support. By SDK 6.1.0 the bootloader could update the SoftDevice and the bootloader itself, and those two could be sent and installed together because the updated bootloader may depend on the new SoftDevice. Buttonless update support for non bonded devices arrived in that same release. From SDK 7.0.0 the extended init packet is required, and it carries validation information: device type and revision, application version, compatible SoftDevices and the firmware CRC. From SDK 8.0.0 the bond information may also be included.

The retry section then draws the practical line. The README states that Secure DFU will be resumed after it has been interrupted from the point it stopped, while the Legacy DFU will start again. On a device on a wall or in a vehicle, where the phone moves out of range mid update, that is the difference between a short continuation and a full retransmission.

Getting into bootloader mode is also part of the flow. The README notes that if a device uses the Nordic Buttonless Service for switching from app mode to DFU bootloader mode, the library handles the switch automatically. When the bootloader is configured to advertise with an incremented MAC address, which happens with Secure DFU on a device that is not bonded, the library has to scan for the new BluetoothDevice instead. That scanning detail drives a surprising amount of the Android permission handling.

Adding the library to an Android project

The lib_dfu module holds the library source and is published to Maven Central, so adding it is a single dependency line in your Gradle build file:

implementation 'no.nordicsemi.android:dfu:2.11.0'

That version matches the latest release listed for the project, 2.11.0, published on 2026-02-11. Two older lines exist for older Android targets. The README states that the latest version targeting API lower than 31 is 1.11.1, and that projects not migrated to Android Jetpack should use version 1.8.1. The same paragraph warns that those versions are not maintained anymore, and that all new features and bug fixes will be released on the latest version only.

If your build runs Proguard or R8, the library gives you the keep rule it needs:

-keep class no.nordicsemi.android.dfu.** { *; }

The README notes that this should be added automatically, which is worth checking rather than trusting, since a stripped or renamed class in a release build produces failures that will not show up in a debug build.

No other setup is documented. There is no manifest entry to copy for the library itself, no configuration file format, and no sample application in the repository that shows a call site. The API documentation is published separately, and the repository keeps its own documentation folder, so the entry point for your first integration is the published API reference rather than a worked example.

Android permission rules change three times across API levels

The permissions section is the longest part of the README, and it changes shape depending on the Android version you target. On Android 4.3 to 11, two manifest permissions were required, BLUETOOTH and BLUETOOTH_ADMIN. If your app targets API 31 or newer, the README says to set android:maxSdkVersion="30" on them, because on API 31 they were replaced by the runtime permissions BLUETOOTH_CONNECT and BLUETOOTH_SCAN.

The scan requirement is where the trouble concentrates. From Android 6 to 11, location permission is required and has to be granted at runtime before DFU is started, because the library must scan for a new BluetoothDevice when the bootloader advertises with an incremented MAC address. The README also notes that starting from Android 8.1.0 all scans done without a scan filter while the screen is turned off return no results, and that ACCESS_BACKGROUND_LOCATION would additionally be required to trigger a successful DFU while the screen is off, mainly to receive scan results when scanning and connecting to the peripheral in bootloader mode.

From Android 12 onward the location permission is no longer needed and BLUETOOTH_CONNECT is required instead, with BLUETOOTH_SCAN also required when buttonless service is used and the MAC address changes. The README says that permission can be used with the neverForLocation flag.

That is three permission regimes for one feature. If your application supports Android 6 through 12, you are shipping a runtime location permission request and a screen on requirement for older devices, which is a cost users notice, not just a manifest detail.

Retries exist but are off by default

Retrying is supported and switched off, which surprises people who read the feature list before the configuration note. The README says that starting from version 1.9.0 the library is able to retry a DFU update in case of an unwanted disconnection, but that to maintain backward compatibility the feature is by default disabled. The number of attempts is set on the initiator:

initiator.setNumberOfRetries(int)

The semantics differ by protocol, as described earlier: Secure DFU resumes from the point it stopped, and Legacy DFU starts again. In practice that means a retry policy is safe to enable for Secure DFU devices, while on Legacy DFU a retry repeats the whole transfer.

The API shape itself is worth a look before you wire it in. The library exposes an initiator object with a setter for the retry count, and the surrounding API documentation is published online. The README does not describe the transfer state machine, the error callbacks, or the recovery behaviour when a device reboots into the application instead of the bootloader, so a team that needs to surface precise failure states to its users will have to read the API reference and the repository documentation folder rather than the README.

The companion app, the zip package and the deep link

Alongside the library, the repository builds a phone application, nRF Device Firmware Update, published on Google Play under the package id no.nordicsemi.android.dfu. The app is described as a mobile app for updating nRF5 SDK firmware using Bluetooth Low Energy as a transport, with a welcome screen, a main screen and a settings screen.

Firmware has to arrive in the right shape. The README states that the firmware should be in .zip file format, prepared using nRF Util, and it can be selected from local storage on the Android device or downloaded from the cloud using a deep link.

The deep link format is fixed:

https://www.nordicsemi.com/dfu/?file=link_to_file

The application opens links in this format for both http and https. Clicking a link opens the app automatically, the download is saved in the Download folder on the phone, and the downloaded file is then displayed in the app ready to use. One practical note from the README: keep in mind to replace '&' with '%26' in the link_to_file value, which matters when the target URL carries query parameters of its own.

Taken together, the app and library cover the same protocol from two directions. The app is useful for field engineers and for acceptance testing, while the library lets you put the update flow inside your own product with your own screens and your own error handling.

nRF Connect SDK firmware is explicitly out of scope

The most important limitation is stated in a callout near the top of the README: the DFU Library cannot be used to update firmware developed with the nRF Connect SDK. The README directs you to nRF Connect Device Manager instead, which is a separate repository, Android-nRF-Connect-Device-Manager.

This is a hard boundary and it is not a configuration difference. The library covers nRF51 and nRF52 devices with an S-Series SoftDevice and the DFU bootloader flashed on, and it supports application, SoftDevice and bootloader updates across the Legacy and Secure bootloader ranges listed earlier. Firmware built with a different SDK, on a different bootloader, or on a newer chip family falls outside that description entirely.

The alternative is therefore a straight swap of tool rather than a different configuration of the same tool. nRF Connect Device Manager handles the nRF Connect SDK side, while this library and app handle the nRF5 SDK side. Teams whose product roadmap moves from nRF5 SDK to nRF Connect SDK should plan for the update mechanism to change with it, and for the in app update flow to be rewritten rather than reconfigured.

There is a second alternative axis worth weighing. Because the library talks to a documented Bluetooth LE bootloader, you can also implement the protocol yourself against the same bootloader, which some teams do to control the exact protocol versions they support. The cost of that route is that you give up the tested retry, resume and permission handling that this library already encodes.

Release cadence and the BSD-3-Clause licence

The repository is licensed under BSD-3-Clause, with the licence text in a LICENSE file at the root. The README itself points to the licence without spelling out terms, so anyone embedding the library in a shipped application should read that file directly and treat it as the source of truth rather than the summary.

On the release side, the recent history shows a 2.x line: 2.10.0 and 2.10.1 both in October 2025, and 2.11.0 on 2026-02-11. The last push to the repository was on 2026-10-17, and the repository is not archived, so commits have continued well after the newest tagged build. In other words, work is landing on main that is not yet in a released artifact, which is normal for a library with an active release process and worth remembering when you pin a version.

The upgrade cost for a consumer is modest. The dependency coordinate changes only in the version segment, and the public API is stable enough that the README does not describe breaking changes between minor releases. The real work sits on the Android side, since each new Android version changes the Bluetooth permission model and the screen off scanning restrictions described earlier. Read the permission section again at each platform bump rather than assuming the manifest entries from your previous release still apply.

Editorial conclusion

Adopt the Android-DFU-Library when your product ships an nRF51 or nRF52 with an nRF5 SDK bootloader and you want firmware updates without your own user interface. Skip it if your hardware runs nRF Connect SDK firmware, since the README states the library cannot update it and points to nRF Connect Device Manager instead, and skip it if you need an update channel that is not Bluetooth LE. Verify three things before you commit: the bootloader version flashed on your devices, whether your app must keep working on Android 6 to 11 with runtime location permission, and whether the Proguard keep rule for no.nordicsemi.android.dfu survives your release build.

Frequently asked questions

Official sources

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