Developer hub / public basics / Article
Deployment staging and handover
Turn a signed application, device policy, accessory list and acceptance record into a repeatable staging batch with explicit ownership and rollback.
Discuss your projectTurn a signed application, device policy, accessory list and acceptance record into a repeatable staging batch with explicit ownership and rollback.
- Model scope
- Named device batch, application package, deployment destination and staging owner. Include country and network topology when TMS or MDM is involved.
- Android version
- Record Android per batch and follow the current SUNMI matrix; do not assume one policy covers devices with different Android generations.
- Firmware
- Record the exact SUNMI OS or firmware image, update baseline and exception list for every staged batch.
- SDK / interface
- OEMConfig, Kiosk and Software Management paths plus Android managed configurations, dedicated-device policy and the selected TMS or MDM topology.
- Application build
- Record the exact project build and hardware environment before deployment.
What the vendor documentation covers
- SUNMI documents OEMConfig, Kiosk and software-management paths for device preparation and managed settings.
- SUNMI deployment documentation covers TMS topology, TLS, MQTT and connectivity verification concepts.
- Android documents managed configurations and dedicated-device deployment patterns that contextualize the fleet workflow.
API surface
Signed application package, version and cryptographic hashOEMConfig managed configuration profileKiosk, System UI and Software Management policy where authorizedAndroid managed configurations, dedicated-device and enrollment stateTMS or MDM topology, TLS and connectivity verification record
Scope and prerequisites
- Signed package and release owner.
- Device batch, naming, MDM or TMS ownership and network diagram.
- OEMConfig, kiosk, application and accessory profiles.
- Pilot acceptance, exception log, rollback path and handover owner.
Permissions and ownership
- Enrollment, device-owner, kiosk and silent-install authority must be assigned to the project administrator or MDM owner.
- Keep signing keys, MDM tokens, TMS credentials, default-password rotation records and customer identifiers in controlled systems only.
- Public documentation should describe roles and fields, never real credentials or production endpoints.
Error handling
Record failed enrollment, unsupported policy key, package signature mismatch, connectivity failure, configuration drift, staging rework, replacement and rollback as handover exceptions with an owner.
Known limitations
- OEMConfig capability varies by MDM, device, firmware and app version.
- TMS topology and connectivity guidance must be adapted to the actual network and security architecture.
- Import, local delivery, warranty, repair and ongoing support are commercial terms, not implied by this checklist.
- This guide is a deployment handover baseline; a rollout conclusion belongs to a named project record.
Implementation path
- 01
Define the deployment destination, device batch, network topology, MDM or TMS owner, application owner and handover recipient.
- 02
Freeze the signed application package, package hash, configuration revision, device baseline and accessory bill of materials. Keep keys and credentials in the controlled delivery system.
- 03
Prepare a clean-device staging sequence: enrollment, network, time, language, policy, package, managed configuration, kiosk and peripheral pairing.
- 04
Use the vendor OEMConfig and Android managed-configuration paths for settings that are actually exposed by the selected MDM. Record unsupported keys as exceptions instead of silently substituting a local change.
- 05
Verify TMS or MDM connectivity using a redacted topology and rotate any default credentials during deployment. Do not reproduce example passwords in the handover document.
- 06
Run the acceptance smoke path and a recovery path on a pilot batch, then record exceptions, rework and rollback owner before staging volume.
- 07
Deliver a handover packet with package hash, policy revision, naming rule, device count, accepted exceptions, support boundary, replacement process and next review date.
Verification checklist
- Every staged device is associated with a named batch, model, Android, firmware and device-name rule.
- Package signature, hash, version and configuration revision match the approved record.
- Enrollment, network, time, policy, kiosk, peripheral and application startup checks pass on the pilot batch.
- Offline startup, reconnect, update failure, reset, replacement and rollback paths are exercised.
- Default credentials are rotated and no secret appears in screenshots, logs or handover attachments.
- Handover names the owner for updates, monitoring, support, repair, warranty and future acceptance.
Publication gate
A published note must link a public source, keep claims within that source, show a named acceptance result and exclude private or customer material.
- At least one public source is linked and its retrieval date is recorded.
- Implementation claims stay within the named model, API and vendor-documentation scope.
- UnitWeave test status is shown separately from manufacturer documentation status.
- No private SDK, credential, customer binary, serial number or production data is included.
- A project-specific compatibility or acceptance conclusion still requires a named test record.
License and provenance
Original UnitWeave editorial synthesis with source provenance. No vendor AAR, SO, APK, private SDK, customer binary or production data is redistributed.
Sample reference
No production topology, host, credential, package or customer device identifier is published. Use a redacted staging record and the public vendor references as the implementation baseline.
Source basis
Source provenance
The implementation content is maintained here in UnitWeave structure and wording. Source URLs remain in the provenance record for attribution and version checking; they are not a substitute for the guide.
- SUNMI OEMConfigSUNMI / Managed configuration controls for device, display, network, printer, scanner and kiosk policy. / Sources checked: 2026-08-30Open reference
External SUNMI documentation. Link to the current vendor page; do not redistribute vendor SDK binaries or assume every model shares the same implementation.
- Kiosk Management ModuleSUNMI / Kiosk application list, enablement, navigation policy and exit-control concepts. / Sources checked: 2026-08-30Open reference
External SUNMI documentation. API availability and device ownership requirements vary by device scope; never publish exit passwords or customer package names.
- Software Management ModuleSUNMI / Documented software management operations such as install, uninstall, enablement and default-app policy. / Sources checked: 2026-08-30Open reference
External SUNMI documentation. These are high-privilege operations; signing, ownership and policy prerequisites must be confirmed for the target project.
- Android Enterprise Reseller / Zero-touchSUNMI / SUNMI-described Android Enterprise zero-touch and reseller deployment path. / Sources checked: 2026-08-30Open reference
External SUNMI documentation. This reference does not establish that UnitWeave is a Google reseller or provide zero-touch enrollment services without a separate authorization record.
- Deployment Modes and Architectural TopologySUNMI / TMS topology, network placement, TLS, MQTT and high-availability planning concepts. / Sources checked: 2026-08-30Open reference
External SUNMI documentation. Apply the architecture to a redacted project diagram; never publish customer hosts, broker details or credentials.
- Deployment Verification and Connectivity TestingSUNMI / Connectivity and post-deployment verification sequence for a TMS installation. / Sources checked: 2026-08-30Open reference
External SUNMI documentation. The source contains example default credentials; this site intentionally does not reproduce them. Rotate defaults during deployment and keep secrets out of documentation and logs.
- SUNMI Device's Android VersionSUNMI / Model-specific Android version information; some models have multiple versions or configurations. / Sources checked: 2026-08-30Open reference
External SUNMI documentation. Link to the current vendor page; do not redistribute vendor SDK binaries or assume every model shares the same implementation.
- Managed configurationsAndroid Developers / Android Enterprise managed application configuration model. / Sources checked: 2026-08-30Open reference
External Android documentation. Apply the guidance to the target Android API level and device policy.
- Dedicated devices cookbookAndroid Developers / Dedicated-device and kiosk deployment concepts. / Sources checked: 2026-08-30Open reference
External Android documentation. Apply the guidance to the target Android API level and device policy.