A vendor source describes the capability, interface or configuration. This is not a UnitWeave test result and does not guarantee your application.
Test lab / compatibility
SUNMI POS, Kiosk and Self-Service Compatibility
This matrix separates what SUNMI publishes from what UnitWeave has actually recorded. A vendor fact can tell you that an interface or capability exists; it cannot tell you that your application build, firmware, accessory combination and operating environment will work. That conclusion needs a dated test or customer acceptance record.
Discuss your projectRead the evidence column by column
A compatibility row is a named setup, not a product promise.
This matrix separates what SUNMI publishes from what UnitWeave has actually recorded. A vendor fact can tell you that an interface or capability exists; it cannot tell you that your application build, firmware, accessory combination and operating environment will work. That conclusion needs a dated test or customer acceptance record.
| Model | Workflow starting point | Vendor-published baseline | Integration surface to review | Next validation step |
|---|---|---|---|---|
| V2s PLUSSunmi Devices | Mobile checkout, order taking and receipt or label output. | Vendor-published baseline
| Printer path, scanner variant, Android Intent or SDK, battery and reconnect behavior. | Name the variant, firmware, app build, paper, scanner path and acceptance steps. |
| L2s PROSunmi Devices | Warehouse scanning, inventory, delivery capture and field service. | Vendor-published baseline
| Scan trigger, decoded data, Intent or SDK, offline queue, battery swap and device policy. | Name the memory variant, firmware, symbology set, trigger method and offline acceptance criteria. |
| P3Sunmi Devices | Payment acceptance, assisted checkout and restaurant order entry. | Vendor-published baseline
| Approved payment boundary, provider SDK or Intent, network recovery, receipt path and country requirements. | Confirm the payment provider, market, exact configuration, certification responsibility and test owner. |
| T2sSunmi Devices | Attended countertop checkout and restaurant counter operations. | Vendor-published baseline
| Printer, cash drawer, customer display, Android version, firmware and application lifecycle. | Confirm the firmware, app build, connected peripherals and acceptance workflow for the rollout configuration. |
| K2Sunmi Devices | Self-service ordering, ticketing, check-in and queue management. | Vendor-published baseline
| Kiosk policy, screen reset, card pairing, network recovery, MDM and remote recovery. | Name the enclosure, holder, payment pairing, Android, firmware, MDM policy and reset acceptance. |
The evidence vocabulary
“Supported” needs a source and an owner.
The same word can hide very different levels of confidence. These states explain what the record means and what it does not mean.
A dated UnitWeave record names the model, OS, firmware, app build, accessories, method, result and reviewer.
A named customer acceptance record confirms the agreed workflow for its environment. It is not automatically a universal result.
Some paths pass and a defined limitation remains. The supported path and failed or excluded path must both be written down.
A named record says the requested setup is outside the confirmed scope or fails the agreed acceptance criteria.
What a real validation record contains
The test object is bigger than the device.
Before we publish a tested-by-us result, the record must be reproducible by someone who did not run the first test. That is why model names alone are never enough.
01
Target identity
Record the model, exact variant, Android release, firmware, application package, version and build. Do not use a family name as a substitute for the tested configuration.
02
Connected setup
Name the printer, scanner, drawer, customer display, holder, paper, payment sandbox, network path and power assumptions used during the run.
03
Test method
Write the preconditions, test data, expected result, steps, repetitions and observed result. Include cold start, reconnect and relevant offline paths when they are part of the workflow.
04
Recovery and limits
Capture permissions, errors, logs or screenshots, recovery behavior, known limitations and excluded paths. Keep customer data, credentials and production binaries out of the public record.
05
Decision and owner
State the evidence level, acceptance result, test date, reviewer, evidence location, support owner and next action. A result remains scoped until a new record extends it.
What this page does not claim
A catalog capability is a starting point for validation.
The matrix helps you ask better questions before purchase or rollout. It does not certify payment, guarantee software compatibility, promise local service or replace the written project acceptance record.
- Vendor documentation is attributed to the vendor and kept separate from UnitWeave test evidence.
- A result for one model, firmware, application build or accessory set does not silently cover another.
- Payment certification, acquiring, tax, import, data migration and local support need their own responsible owner.
- The quotation or contract controls commercial scope, availability, warranty, delivery and support commitments.
Compatibility
Need a compatibility answer for your application?
Send the application build, target model, firmware assumptions, peripherals, country and acceptance criteria. We will turn the open question into a named validation brief.