Developer hub / public basics / Article
Existing POS migration checklist
Map an existing POS, ERP or field workflow onto named SUNMI hardware by separating application behavior, device interfaces, peripherals, payment certification and rollout scope.
Discuss your projectMap an existing POS, ERP or field workflow onto named SUNMI hardware by separating application behavior, device interfaces, peripherals, payment certification and rollout scope.
- Model scope
- Any named SUNMI device and existing POS or ERP application. The migration result belongs to the named application build and peripheral topology, not to a generic product family.
- Android version
- Use the current SUNMI model matrix and the application minimum and target SDK. Do not assume a single Android version across a product family or K2 batch.
- Firmware
- Record the exact SUNMI OS or firmware for each migration cohort.
- SDK / interface
- Select only the interfaces used by the workflow: standard Android, printer LineApi or CommandApi, scanner Intent or SDK, Customer API, display or device-management modules.
- Application build
- Record the exact project build and hardware environment before deployment.
What the vendor documentation covers
- SUNMI provides public documentation for printing, scanning, device information, management and model Android versions.
- Android permissions and package-visibility behavior remain platform constraints for the existing application.
- Payment provider, acquiring, tax and local certification are separate workstreams and are not inferred from a SUNMI device integration.
API surface
Existing application workflow and package or build contractSUNMI printer LineApi, CommandApi and QueryApi where printing is requiredSUNMI scanner Intent, camera SDK or external scanner broadcast pathSUNMI Customer API modules only when the target device and policy authorize themAndroid lifecycle, permission, display and package-visibility APIs
Scope and prerequisites
- Existing software owner, source or release owner and target application build.
- Named device, Android, firmware, peripherals, payment provider and destination country.
- Workflow acceptance criteria, offline rules, data boundary and rollback plan.
- A redacted test fixture and evidence owner.
Permissions and ownership
- Request only application permissions required by the selected Android and peripheral path, and document the user or device-owner decision.
- Device-management or silent-install functions require separate policy and ownership authority.
- Keep payment credentials, signing material, customer data and production identifiers outside the public guide and test fixtures.
Error handling
Track hardware discovery, permission denial, print and scan failure, payment handoff failure, offline queue, sync conflict, duplicate event, app crash and rollback as separate acceptance outcomes.
Known limitations
- A migration checklist does not prove that an arbitrary POS, ERP or payment application is compatible.
- Payment certification, backend development, tax behavior, data migration and local service are separate scope.
- The correct interface can vary by model, Android version, firmware, accessory and application build.
- This guide is a migration planning baseline; a compatibility conclusion belongs to a named project record.
Implementation path
- 01
Inventory the current workflow by user action: sign-in, item or order entry, payment handoff, print, scan, sync, refund, offline mode and closeout.
- 02
Create an interface map that names every device action, the current application contract and the selected SUNMI or Android boundary. Keep payment and backend contracts separate from hardware commands.
- 03
Choose the smallest native adapter surface and hide model-specific printer, scanner, drawer and display differences behind capability checks and explicit fallback behavior.
- 04
Audit Android target SDK, runtime permissions, package visibility, lifecycle, orientation, sleep or wake and background restrictions on the named device image.
- 05
Run the application with representative data and peripherals, including empty, malformed, offline, duplicate and recovery cases. Do not use production records in the test fixture.
- 06
Document what the manufacturer says, what the project team tested and what the customer accepted as separate evidence entries.
- 07
Plan migration rollback, data ownership, payment certification and post-rollout support before calling the migration complete.
Verification checklist
- Record existing app package, build, minimum and target SDK, target model, Android, firmware and peripherals.
- Exercise the complete happy path and each workflow exception from login through receipt, sync and closeout.
- Verify printer, scanner, drawer, display and payment handoff independently before testing the end-to-end workflow.
- Test permission denial, app restart, sleep or wake, network loss, duplicate events and device replacement.
- Compare output, timing, data integrity and operator recovery against written acceptance criteria.
- Assign separate owners for application changes, vendor configuration, acquiring certification, backend migration and field support.
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 customer application, package, database or payment credential is published. Use a redacted project fixture and the linked public vendor references during validation.
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 Integration GuideSUNMI / General integration entry point and vendor documentation navigation. / 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.
- 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.
- APIs for Printing Thermal ReceiptsSUNMI / LineApi operations for text, barcodes, QR codes, bitmaps, columns and print transactions. / 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.
- Using Camera-Based Barcode Scanner SDKSUNMI / Built-in scanner Intent path and camera preview plus SDK decoding path. / 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.
- Overview of SUNMI Customer API SDKSUNMI / Customer API modules, asynchronous service connection and model or device-scope boundaries. / 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.
- Request app permissionsAndroid Developers / Runtime permission request and user-decision handling. / Sources checked: 2026-08-30Open reference
External Android documentation. Apply the guidance to the target Android API level and device policy.
- Android package visibilityAndroid Developers / Package visibility and manifest queries for Android 11 and later. / Sources checked: 2026-08-30Open reference
External Android documentation. Apply the guidance to the target Android API level and device policy.