Prepare a tested application package for the device's signature checks, then verify installation and operation with signature enforcement enabled. Developer Mode is available for an authorized development cycle on firmware that supports it; it is separate from the final signed-package acceptance test.

Applies to: RobustOS Devices implementing the RobustOS 5.6 application-signature mechanism, with an SDK target and package compatible with the exact model and firmware. Confirm applicability to the device release. Root-shell access and Developer Mode require separate authorization and firmware support; follow the device-shell access prerequisites before using shell commands.

Understand application signatures

For firmware implementing this signing mechanism, Robustel signs the application package and the device verifies it during installation. The mechanism uses a 32-byte SHA256 hash and an ECDSA signature of variable encoded length, approximately 70 or more bytes. Do not assume a fixed signature length when handling a package.

The private signing key is held on Robustel's secure server and is not distributed to customers or devices. The verification public key is stored on the device at /etc/ec.pubkey.

The signing service hashes the application content, signs that hash and appends the signature to the application file. The device reads the appended signature, hashes the application content excluding that signature and verifies the result using its public key. This description explains the workflow; it is not a binary-format specification for constructing a signature trailer.

Use Developer Mode only for the authorized development cycle

Warning: Developer Mode bypasses application-signature verification during application upgrade. Use it only on the approved development device while developing and debugging. Restore signature enforcement before production deployment.

After obtaining authorized root-shell access and confirming that the firmware supports this command, inspect the available command and current state in the device shell:

rbt-system-mgmt help
rbt-system-mgmt developer-mode help
rbt-system-mgmt developer-mode state

The state command reports enabled or disabled. Enabling the mode is a separate device change; it is not part of host or container setup. In the approved development workflow, run:

rbt-system-mgmt developer-mode enable

A successful command reports OK. Check the state again, then install and debug the unsigned development package through the device's application workflow. Do not treat Developer Mode as a solution to a wrong build target or incompatible firmware.

At the end of development, restore enforcement:

rbt-system-mgmt developer-mode disable
rbt-system-mgmt developer-mode state

The disable command reports OK; the state should report disabled. Future application upgrades on this path require a valid signature. Disabling the mode is not evidence that an already installed package was retroactively validated.

Prepare the final package for deployment

1. Complete target-build and device tests for the intended model, variant and firmware. Record the exact unsigned package submitted for signing.
2. Submit that final package to Robustel Technical Support through the agreed signing process. The SDK does not include the private signing key.
3. Receive and retain the returned signed package, recording its identity separately from the unsigned build artifact.
4. On the designated acceptance device, verify that Developer Mode is disabled and install the signed package using the normal application workflow.
5. Check the installed version, startup behavior, application function and logs. Repeat the relevant application checks after a restart if startup persistence is part of the feature.

Deployment evidence includes the signed package identity, target and firmware, successful installation with signature enforcement enabled, and the application's expected results. Completing a signing request alone does not demonstrate successful operation.

Treat firmware and whole-configuration changes as separate maintenance work

Applications can invoke firmware or configuration operations, but these affect more than the application's own files. Establish the device-specific package checks, backup, access-recovery and maintenance procedure before integrating them into an application. These commands are not part of the SDK environment setup or Hello World workflow.

The firmware-upgrade interface is sysupgrade -q <firmware-path>; -q selects quiet operation. The download, artifact validation, compatible upgrade path and failure recovery must come from the firmware release procedure. Do not infer those requirements from the existence of the command or automate an upgrade from this reference alone.

For whole-device XML configuration, the command sequence is import, save, apply:

uci import <XML_FILE_ON_DEVICE>
uci save
uci apply

Export uses uci export <XML_FILE_ON_DEVICE>. The output must be handled as potentially sensitive configuration. Importing and applying a file can change network access and service settings; use the firmware's approved backup and recovery procedure and a configuration confirmed for that device. File transfer, compatibility validation and rollback are separate steps, not supplied by uci import.

For narrower application settings, use the application configuration guide. It distinguishes configuration changes, persistence and runtime application instead of treating a successful API call as proof that all three occurred.

Related tasks

• Build and package SDK applications to produce the RPK and include its runtime dependencies.
• Debug an SDK application before submitting the final artifact for signing.
• Manage services with agd when release acceptance includes Guardian Service behavior.