aljaz/Android-nRF-Toolbox
1
0
Fork 0
mirror of https://github.com/aljazceru/Android-nRF-Toolbox.git synced 2026-01-08 01:04:20 +01:00
Code Issues Packages Projects Releases Wiki Activity

Update README

Browse Source
This commit is contained in:
Sylwester Zieliński
2022-01-31 15:23:14 +01:00
parent 80fb980c38
commit 71126125ab
2 changed files with 115 additions and 301 deletions
Download Patch File Download Diff File Expand all files Collapse all files

230
README.md
View File

@@ -1,232 +1,92 @@
# nRF Toolbox
The nRF Toolbox is a container app that stores your Nordic Semiconductor apps for Bluetooth Low Energy
in one location.
The nRF Toolbox is a container app that stores your Nordic Semiconductor apps for Bluetooth Low Energy
in one location.
It contains applications demonstrating standard Bluetooth LE profiles:
* **Cycling Speed and Cadence**,
* **Running Speed and Cadence**,
* **Heart Rate Monitor**,
* **Blood Pressure Monitor**,
* **Health Thermometer Monitor**,
It contains applications demonstrating standard Bluetooth LE profiles:
* **Cycling Speed and Cadence**,
* **Running Speed and Cadence**,
* **Heart Rate Monitor**,
* **Blood Pressure Monitor**,
* **Health Thermometer Monitor**,
* **Glucose Monitor**,
* **Continuous Glucose Monitor**,
* **Proximity Monitor** - supports multiple connections.
* **Proximity Monitor**
Since version 1.10.0 the *nRF Toolbox* also supports the **Nordic UART Service** which may be used
Since version 1.10.0 the *nRF Toolbox* also supports the **Nordic UART Service** which may be used
for bidirectional text communication between devices.
**Note:** To get a smaller version, with only the DFU profile, switch to the *only_dfu* branch
(this branch is not maintained anymore, so you have to update it on your own).
### How to import to Android Studio
The production version of nRF Toolbox depends on
[Android BLE Library](https://github.com/NordicSemiconductor/Android-BLE-Library/) and demonstrates
use of the Android BLE Common Library (ble-common module), which provides parsers for common profiles
adopted by Bluetooth SIG. Both libraries are available on jcenter.
The production version of nRF Toolbox depends on
[Android BLE Library](https://github.com/NordicSemiconductor/Android-BLE-Library/) and demonstrates
use of the Android BLE Common Library (ble-common module), which provides parsers for common profiles
adopted by Bluetooth SIG.
You may also include the BLE Library and BLE Common Library as modules. Clone the library project
You may also include the BLE Library and BLE Common Library as modules. Clone the library project
to the same root folder.
If you are having issue like [#40](https://github.com/NordicSemiconductor/Android-nRF-Toolbox/issues/40)
or [#41](https://github.com/NordicSemiconductor/Android-nRF-Toolbox/issues/41), the correct folders
If you are having issue like [#40](https://github.com/NordicSemiconductor/Android-nRF-Toolbox/issues/40)
or [#41](https://github.com/NordicSemiconductor/Android-nRF-Toolbox/issues/41), the correct folders
structure should look like this:
![Folders structure](resources/structure.png)
If you prefer a different name for BLE library, update the
[*settings.gradle*](https://github.com/NordicSemiconductor/Android-nRF-Toolbox/blob/master/settings.gradle)
[*settings.gradle*](https://github.com/NordicSemiconductor/Android-nRF-Toolbox/blob/master/settings.gradle)
file.
*DFULibrary* folder is optional, as the library is downloaded from jcenter repository automatically.
Clone it only when you want to modify the code (not recommended).
If you get ["Missing Feature Watch" error](https://github.com/NordicSemiconductor/Android-nRF-Toolbox/issues/41#issuecomment-355291101),
If you get ["Missing Feature Watch" error](https://github.com/NordicSemiconductor/Android-nRF-Toolbox/issues/41#issuecomment-355291101),
switch the configuration to 'app'.
### BleManager and how to use it
There are 4 different solutions how to use the manager shown in different profiles.
The very basic approach is used by the BPM, HRM and GLS profiles. Each of those activities holds a
static reference to the manager. Keeping the manager as a static object protects from disposing it
when device orientation changes and the activities are being destroyed and recreated. However, this
approach does not allow to keep the connections in background mode and therefore is not a solution
There are 4 different solutions how to use the manager shown in different profiles.
The very basic approach is used by the BPS nd GLS profiles. Each of those activities holds a
static reference to the manager. Keeping the manager as a view model object protects from disposing it
when device orientation changes and the activities are being destroyed and recreated. However, this
approach does not allow to keep the connections in background mode and therefore is not a solution
that should be used in any production-ready application.
A better implementation may be found in CSC, RSC, HTM and CGM. The `BleManager` instance is maintained
by the running service. The service is started in order to connect to a device and stopped when user
decides to disconnect from it. When an activity is destroyed it unbinds from the service, but the
service is still running, so the incoming data may continue to be handled. All device-related data
are kept be the service and may be obtained by a new activity when it binds to it in order to be
A better implementation may be found in CGMS, CSC, HRS, HTS, PRX, RSCS, UART. The `BleManager` instance is maintained
by the running service. The service is started in order to connect to a device and stopped when user
decides to disconnect from it. When an activity is destroyed it unbinds from the service, but the
service is still running, so the incoming data may continue to be handled. All device-related data
are kept by the service and may be obtained by a activity when it binds to it in order to be
shown to the user.
As a third, the Proximity profile allows to connect to multiple sensors at the same time. It uses a
different service implementation but still the `BleManager` is used to manage each connection.
If the [useAutoConnect(boolean)](https://github.com/NordicSemiconductor/Android-BLE-Library/blob/e95a814f4c0ecd08a75e5f0e53c68e2b8dbdf70c/ble/src/main/java/no/nordicsemi/android/ble/ConnectRequest.java#L198)
method returns `true` for a connection, the manager will try to reconnect automatically to the device
if a link was lost. You will also be notified about a device that got away using
`onDeviceDisconnected(ConnectionObserver.REASON_LINK_LOSS)`.
The `BleMulticonnectProfileService` implementation, used by Proximity profile, does not save addresses
of connected devices. When the service is killed it will not be able to reconnect to them after it's
restarted, so this feature has been disabled. Also, when user removes the nRF Toolbox app from
Recents, the service will be killed and all devices will be disconnected automatically. To change
this behaviour a service would have to either save the addresses and reconnect to devices after it
has restarted (but then removing the app from Recents would cause disconnection and immediate
reconnection as the service is then killed and moved to another process), or would have to be
implemented in a way that is using another
[process](https://developer.android.com/guide/topics/manifest/service-element.html#proc).
Then, however, it is not possible to bind to such service and data must be exchanged using a
[Messenger](https://developer.android.com/reference/android/app/Service.html#RemoteMessengerServiceSample).
Such approach is not demonstrated in nRF Toolbox.
At last, the `BleManager` can be accessed from a `ViewModel`
(see [Architecture Components](https://developer.android.com/topic/libraries/architecture/index.html)).
Check out the [Android nRF Blinky](https://github.com/NordicSemiconductor/Android-nRF-Blinky) app
for sample code.
### Nordic UART Service
The UART profile allows for fast prototyping of devices. The service itself it very simple, having
just 2 characteristics, one for sending data and one for receiving. The data may be any byte array
but it is very often used with just text. Each UART configuration in the nRF Toolbox consists of
9 programmable buttons. Each of them, when pressed, will send the stored command to the device.
You may export your configuration to XML and share between other devices. Swipe the screen to
The UART profile allows for fast prototyping of devices. The service itself is very simple, having
just 2 characteristics, one for sending data and one for receiving. The data may be any byte array
but it is very often used with just text. Each UART configuration can be created as a separate profile.
Each of them, when pressed, will send the stored command to the device.
You may export your configuration to XML and share between other devices. Swipe the screen to
right to show the log with all events.
Since nRF Toolbox version 1.16.0 the UART profile supports also Google Wear OS devices (watches).
If you have a Wear OS watch, the application will automatically be installed on it after you install
or update the application on the phone. Before you start playing with the watch, please open the
UART profile on the phone so it could share your configurations to all wearables.
Android Wear 2.0 support has been added in nRF Toolbox version 2.2.2. Now, after installing the app
on the phone, you will be notified on the watch to download the watch-APK onto the watch. The app on
the watch is not standalone. UART configurations must be configured on the phone.
The wearable application may work in 2 modes: as a remote control of the phone, or directly connected
to a UART device.
1. Connect your phone to the UART device. After few seconds you should get a notification on the
watch that your device is now connected. Swipe it left to see Disconnect button (will send a message
to the phone to terminate the connection with UART target) and Open button. Click the Open button to
see a list of your UART configurations. Click one and see the list of active buttons. When pressed
the button will send a message to the phone using Google Play Services and the phone will send the
command to the target device. In this mode you may have more than one watch connected to the phone
and use both as remote controls.
![Scenario 1](resources/scenario_1.png)
2. Open the applications menu on Android Wear watch and click nRF Toolbox. The watch will now scan
for all nearby Bluetooth LE devices and show you them on a list. Select your UART device to connect
to it. A list of your configurations will be shown, like in 1. As that was a direct connection from
the watch to the UART target the phone, or any other watch will not be notified about it.
![Scenario 2](resources/scenario_2.png)
### Device Firmware Update
The **Device Firmware Update (DFU)** profile allows you to update the application, bootloader
and/or the Soft Device image over-the-air (OTA). It is compatible with Nordic Semiconductor nRF5
devices that have the SoftDevice and DFU Bootloader flashed. From version 1.11.0 onward, the
nRF Toolbox has allowed to send the init packet (required since SDK 7.0). More information about
the init packet may be found here:
[init packet handling](https://github.com/NordicSemiconductor/Android-nRF-Connect/tree/master/init%20packet%20handling).
The DFU has the following features:
- Scans for devices that are in DFU mode.
- Connects to devices in DFU mode and uploads the selected firmware (soft device, bootloader
and/or application).
- Allows HEX or BIN file upload through your phone or tablet.
- Allows to update a soft device and bootloader from ZIP in one connection.
- Pause, resume, and cancel file uploads.
- Works in portrait and landscape orientation.
- **Secure DFU** is supported since nRF Toolbox 1.17.0.
#### DFU Settings
To open the DFU settings click the *Settings* button in the top toolbar when on DFU profile.
**Packet receipt notification procedure** - This switch allows you to turn on and off the packet
receipt notification procedure. During the DFU operation the phone sends 20-bytes size packets to t
he DFU target. It may be configured that once every N packets the phone stops sending and awaits
for the Packet Receipt Notification from the device. This feature is required by Android to sync
sending data with the remote device, as the callback `onCharacteristicWrite(...)` that follows
calling method `gatt.writeCharacteristic(...)` is invoked when the packet is written to the outgoing
queue, not when physically transmitted. With this procedure disabled it may happen that the outgoing
buffer will be overloaded and the communication stops. The same error may happen when the N number
is too big, about 300-400. The receipt notification ensures that the outgoing queue is empty and
the DFU target received all packets successfully.
*Note:* Android 6.0 and newer does not require this option to be enabled. The buffer overflow is
now handled correctly and the upload speed is much higher with this option disabled.
**Number of packets** - This field allows you to set the N number describe above. By default it is
set to 12. Depending on the phone model, devices may send and receive different number of packets
in each connection interval. Nexus 4, for instance, may send just 1 packet (and receive 3 notifications)
while Nexus 5 or 6 send and receive up to 4 packets. By customizing this value you may check which
value allows for the fastest transmission on your phone/tablet.
**MBR size** - This value is used only to convert HEX files into BIN files. If your packet is
already in the BIN format, this value is ignored. The data from addresses lower then this value
are being skipped while converting HEX to BIN. This is to prevent from sending the
MBR (Master Boot Record) part from the HEX file that contains the Soft Device. The compiled
Soft Device contains data that starts at address 0x0000 and contains the MBR. It is followed by the
jump to address 0x1000 (default MBR size) where the Soft Device firmware starts. Only the Soft Device
part must be sent over DFU.
**Keep bond information** - When upgrading the application on a bonded device the DFU bootloader
may be configured to preserve some pages of the application's memory intact, so that the new
application may read them. The new application must know the old data format in order to read
them correctly. Our HRS DFU sample stores the Long Term Key (LTK) and the Service Attributes in two
first pages. However, the DFU Bootloader, by default, clears the whole application's memory when the
new application upload completes, and the bond information is lost. In order to configure the number
of pages to be preserved set the **DFU_APP_DATA_RESERVED** value in the *dfu_types.h* file in the
DFU bootloader code (line ~56). To preserve two pages the value should be set to 0x0800.
When your DFU bootloader has been modified to keep the bond information after updating the
application set the switch to ON. Otherwise the bond information will be removed from the phone.
**External MCU DFU** - The DFU service from the library, when connected to a DFU target, will check
whether it is in application or in DFU bootloader mode. For DFU implementations from SDK 7.0 or newer
this is done by reading the value of DFU Version characteristic. If the returned value is equal to
0x0100 (major = 0, minor = 1) it means that we are in the application mode and jump to the
bootloader mode is required.
However, for DFU implementations from older SDKs, where there was no DFU Version characteristic,
the service must guess. If this option is set to false (default) it will count number of device's
services. If the count is equal to 3 (Generic Access, Generic Attribute, DFU Service) it will assume
that it's in DFU mode. If greater than 3 - in app mode.
This guessing may not be always correct. One situation may be when the nRF chip is used to flash
update on an external MCU using DFU. The DFU procedure may be implemented in the application,
which may (and usually does) have more services. In such case set the value of this property to true.
**DFU is now available as a separate application**
https://github.com/NordicSemiconductor/Android-DFU-Library
### Dependencies
nRF Toolbox depends on [Android BLE Library](https://github.com/NordicSemiconductor/Android-BLE-Library/)
which has to be cloned into the same root folder as this app. If you prefer a different name,
nRF Toolbox depends on [Android BLE Library](https://github.com/NordicSemiconductor/Android-BLE-Library/)
which has to be cloned into the same root folder as this app. If you prefer a different name,
update the [*settings.gradle*](https://github.com/NordicSemiconductor/Android-BLE-Library/blob/master/settings.gradle) file.
In order to compile the project the **DFU Library is required**. This project may be found here:
https://github.com/NordicSemiconductor/Android-DFU-Library.
Since version 1.16.1 it is imported automatically from *jcenter* repository and no special
configuration is needed. If you want to make some modifications in the DFU Library, please clone
the DFU Library to the same root as nRF Toolbox is cloned and name the library's folder **DFULibrary**.
Add the dfu module in Project Structure and edit *app/build.gradle* file and *settings.gradle*
files as describe in them.
The nRF Toolbox also uses the nRF Logger API library which may be found here:
https://github.com/NordicSemiconductor/nRF-Logger-API. The library is included in dependencies
in *build.gradle* file. This library allows the app to create log entries in the
[nRF Logger](https://play.google.com/store/apps/details?id=no.nordicsemi.android.log) application.
The nRF Toolbox also uses the nRF Logger API library which may be found here:
https://github.com/NordicSemiconductor/nRF-Logger-API. The library is included in dependencies
in *build.gradle* file. This library allows the app to create log entries in the
[nRF Logger](https://play.google.com/store/apps/details?id=no.nordicsemi.android.log) application.
Please, read the library documentation on GitHub for more information about the usage and permissions.
The graph in HRM profile is created using the [AChartEngine v1.1.0](http://www.achartengine.org)
The graph in HRM profile is created using the [MPAndroidChart v3.1.0](https://github.com/PhilJay/MPAndroidChart)
contributed based on the [Apache 2.0 license](http://www.apache.org/licenses/LICENSE-2.0).
### Note
- Android 4.3 or newer is required.
- Compatible with nRF5 devices running samples from the Nordic SDK and other devices implementing
- Android 5.0 or newer is required.
- Compatible with nRF5 devices running samples from the Nordic SDK and other devices implementing
standard profiles.
- Development kits: https://www.nordicsemi.com/Software-and-tools/Development-Kits.
- The nRF5 SDK and SoftDevices are available online at http://developer.nordicsemi.com.

186
moustache/README.mo
View File

@@ -1,138 +1,92 @@
# nRF Connect Device Manager
# nRF Toolbox
This repository is a fork of the [McuManager Android Library](https://github.com/JuulLabs-OSS/mcumgr-android),
which has been DEPRECATED. All new features and bug fixes will be added here. Please, migrate to the
new version to get future updates.
The nRF Toolbox is a container app that stores your Nordic Semiconductor apps for Bluetooth Low Energy
in one location.
The sample application has been named nRF Connect Device Manager and is available on
[Google Play](https://play.google.com/store/apps/details?id=no.nordicsemi.android.nrfconnectdevicemanager).
It contains applications demonstrating standard Bluetooth LE profiles:
* **Cycling Speed and Cadence**,
* **Running Speed and Cadence**,
* **Heart Rate Monitor**,
* **Blood Pressure Monitor**,
* **Health Thermometer Monitor**,
* **Glucose Monitor**,
* **Continuous Glucose Monitor**,
* **Proximity Monitor**
nRF Connect Device Manager library is compatible with Mcu Manager, a management subsystem supported
by nRF Connect SDK, Zephyr and Apache Mynewt.
Since version 1.10.0 the *nRF Toolbox* also supports the **Nordic UART Service** which may be used
for bidirectional text communication between devices.
---
### How to import to Android Studio
# McuManager Android
The production version of nRF Toolbox depends on
[Android BLE Library](https://github.com/NordicSemiconductor/Android-BLE-Library/) and demonstrates
use of the Android BLE Common Library (ble-common module), which provides parsers for common profiles
adopted by Bluetooth SIG.
A transport agnostic implementation of the McuManager protocol. Contains a default implementation for BLE transport.
Minimum required Android version is 5.0 (Android Lollipop) due to a requirement for high MTU.
You may also include the BLE Library and BLE Common Library as modules. Clone the library project
to the same root folder.
## Gradle Install
If you are having issue like [#40](https://github.com/NordicSemiconductor/Android-nRF-Toolbox/issues/40)
or [#41](https://github.com/NordicSemiconductor/Android-nRF-Toolbox/issues/41), the correct folders
structure should look like this:
[ ![Download](https://maven-badges.herokuapp.com/maven-central/no.nordicsemi.android/mcumgr-ble/badge.svg?style=plastic) ](https://search.maven.org/search?q=g:no.nordicsemi.android)
![Folders structure](resources/structure.png)
#### McuManager BLE (Recommended)
Contains the core and a BLE transport implementation using Nordic's [Android-BLE-Library v2](https://github.com/NordicSemiconductor/Android-BLE-Library).
If you prefer a different name for BLE library, update the
[*settings.gradle*](https://github.com/NordicSemiconductor/Android-nRF-Toolbox/blob/master/settings.gradle)
file.
```groovy
implementation 'no.nordicsemi.android:mcumgr-ble:{{VERSION}}'
```
If you get ["Missing Feature Watch" error](https://github.com/NordicSemiconductor/Android-nRF-Toolbox/issues/41#issuecomment-355291101),
switch the configuration to 'app'.
The core module will be included automatically.
### BleManager and how to use it
#### McuManager Core
Core dependency only. Use if you want to provide your own transport implementation.
There are 4 different solutions how to use the manager shown in different profiles.
The very basic approach is used by the BPS nd GLS profiles. Each of those activities holds a
static reference to the manager. Keeping the manager as a view model object protects from disposing it
when device orientation changes and the activities are being destroyed and recreated. However, this
approach does not allow to keep the connections in background mode and therefore is not a solution
that should be used in any production-ready application.
```groovy
implementation 'no.nordicsemi.android:mcumgr-core:{{VERSION}}'
```
A better implementation may be found in CGMS, CSC, HRS, HTS, PRX, RSCS, UART. The `BleManager` instance is maintained
by the running service. The service is started in order to connect to a device and stopped when user
decides to disconnect from it. When an activity is destroyed it unbinds from the service, but the
service is still running, so the incoming data may continue to be handled. All device-related data
are kept by the service and may be obtained by a activity when it binds to it in order to be
shown to the user.
### Migration from the original repo
### Nordic UART Service
When migrating from the version 0.12 and older, change
```groovy
implementation 'io.runtime.mcumgr:mcumgr-ble:0.XX.X'
```
to the above.
The UART profile allows for fast prototyping of devices. The service itself is very simple, having
just 2 characteristics, one for sending data and one for receiving. The data may be any byte array
but it is very often used with just text. Each UART configuration can be created as a separate profile.
Each of them, when pressed, will send the stored command to the device.
You may export your configuration to XML and share between other devices. Swipe the screen to
right to show the log with all events.
# Introduction
### Device Firmware Update
McuManager is an application layer protocol used to manage and monitor microcontrollers running
Apache Mynewt and Zephyr. More specifically, McuManager implements over-the-air (OTA) firmware upgrades,
log and stat collection, and file-system and configuration management.
**DFU is now available as a separate application**
https://github.com/NordicSemiconductor/Android-DFU-Library
## Command Groups
### Dependencies
McuManager are organized by functionality into command groups. In _mcumgr-android_, command groups
are called managers and extend the `McuManager` class. The managers (groups) implemented in
_mcumgr-android_ are:
nRF Toolbox depends on [Android BLE Library](https://github.com/NordicSemiconductor/Android-BLE-Library/)
which has to be cloned into the same root folder as this app. If you prefer a different name,
update the [*settings.gradle*](https://github.com/NordicSemiconductor/Android-BLE-Library/blob/master/settings.gradle) file.
* **`DefaultManager`**: Contains commands relevant to the OS. This includes task and memory pool
statistics, device time read & write, and device reset.
* **`ImageManager`**: Manage image state on the device and perform image uploads.
* **`StatsManager`**: Read stats from the device.
* **`ConfigManager`**: Read/Write config values on the device.
* **`LogManager`**: Collect logs from the device.
* **`FsManager`**: Download/upload files from the device file system.
The nRF Toolbox also uses the nRF Logger API library which may be found here:
https://github.com/NordicSemiconductor/nRF-Logger-API. The library is included in dependencies
in *build.gradle* file. This library allows the app to create log entries in the
[nRF Logger](https://play.google.com/store/apps/details?id=no.nordicsemi.android.log) application.
Please, read the library documentation on GitHub for more information about the usage and permissions.
# Firmware Upgrade
The graph in HRM profile is created using the [MPAndroidChart v3.1.0](https://github.com/PhilJay/MPAndroidChart)
contributed based on the [Apache 2.0 license](http://www.apache.org/licenses/LICENSE-2.0).
Firmware upgrade is generally a four step process performed using commands from the `image` and
`default` commands groups: `upload`, `test`, `reset`, and `confirm`.
This library provides a `FirmwareUpgradeManager` as a convenience for upgrading the image running on a device.
### Example
```java
// Initialize the BLE transporter with context and a BluetoothDevice
McuMgrTransport transport = new McuMgrBleTransport(context, bluetoothDevice);
// Initialize the FirmwareUpgradeManager
FirmwareUpgradeManager dfuManager = new FirmwareUpgradeManager(transport, dfuCallback)
// Start the firmware upgrade with the image data
dfuManager.start(imageData);
```
To update multi-core device, use:
```java
List<Pair<Integer, byte[]>> images = new ArrayList<>();
images.add(new Pair<Integer, byte[]>(0, appCoreImage));
images.add(new Pair<Integer, byte[]>(1, netCoreImage));
dfuManager.start(images);
```
You may also use `ZipPackage` class from `utils` package in Sample app, which can unpack the ZIP file
generated by `west` in Zephyr or nRF Connect SDK.
## FirmwareUpgradeManager
A `FirmwareUpgradeManager` provides an easy way to perform firmware upgrades on a device.
A `FirmwareUpgradeManager` must be initialized with an `McuMgrTransport` which defines the transport
scheme and device. Once initialized, a `FirmwareUpgradeManager` can perform one firmware upgrade at a time.
Firmware upgrades are started using the `start(byte[] imageData)` of `start(List<Pair<Integer, byte[]>> images)`
methods and can be paused, resumed, and canceled using `pause()`, `resume()`, and `cancel()` respectively.
### Firmware Upgrade Mode
McuManager firmware upgrades can actually be performed in few different ways. These different upgrade
modes determine the commands sent after the upload step. The `FirmwareUpgradeManager` can be
configured to perform these different methods using `setMode(FirmwareUpgradeManager.Mode mode)`.
The different firmware upgrade modes are as follows:
* **`TEST_AND_CONFIRM`**: This mode is the **default and recommended mode** for performing upgrades
due to it's ability to recover from a bad firmware upgrade.
The process for this mode is `UPLOAD`, `TEST`, `RESET`, `CONFIRM`.
* **`CONFIRM_ONLY`**: This mode may be used for devices with revert disabled. If the device fails
to boot into the new image, it will not be able to recover and will need to be re-flashed.
The process for this mode is `UPLOAD`, `CONFIRM`, `RESET`.
* **`TEST_ONLY`**: This mode is useful if you want to run tests on the new image running before
confirming it manually as the primary boot image.
The process for this mode is `UPLOAD`, `TEST`, `RESET`.
### Firmware Upgrade State
`FirmwareUpgradeManager` acts as a simple, mostly linear state machine which is determined by the `Mode`.
As the manager moves through the firmware upgrade process, state changes are provided through the
`FirmwareUpgradeCallback`'s `onStateChanged` method.
The `FirmwareUpgradeManager` contains an additional state, `VALIDATE`, which precedes the upload.
The `VALIDATE` state checks the current image state of the device in an attempt to bypass certain
states of the firmware upgrade. For example, if the image to upload is already in slot 1 on the
device, the `State` will skip `UPLOAD` and move directly to `TEST` (or `CONFIRM` if `Mode.CONFIRM_ONLY`
has been set). If the uploaded image is already active, and confirmed in slot 0, the upgrade will
succeed immediately. The `VALIDATE` state makes it easy to reattempt an upgrade without needing to
re-upload the image or manually determine where to start.
## License
This library is licensed under the Apache 2.0 license. For more info, see the `LICENSE` file.
### Note
- Android 5.0 or newer is required.
- Compatible with nRF5 devices running samples from the Nordic SDK and other devices implementing
standard profiles.
- Development kits: https://www.nordicsemi.com/Software-and-tools/Development-Kits.
- The nRF5 SDK and SoftDevices are available online at http://developer.nordicsemi.com.