Developer hub / public basics / Technical article

Multi-device compatibility matrix

Compare one application build across named SUNMI devices by keeping Android, firmware, peripherals, method and evidence state visible in every row.

Discuss your project

Compare one application build across named SUNMI devices by keeping Android, firmware, peripherals, method and evidence state visible in every row.

v1.0.0 / Technical articleSources checked: 2026-08-30

Model scope: V2s, V2s PLUS, P3, L2s PRO, K2 or any additional named devices. A family label is not a compatibility cell.
Android version: Current public baseline includes V2s and V2s PLUS Android 11, L2s PRO Android 12, P3 Android 11 Go, V3 and V3 MIX Android 13, CPad and L3 Android 14, and K2 Android 7.1, 9 or 13 by configuration.
Firmware: Every row must carry the exact SUNMI OS or firmware revision; no common firmware value is inferred.
SDK / interface: Record the exact printer, scanner, Customer API, Intent, native bridge or standard Android interface used in the row.
Application build: Record the exact project build and hardware environment before deployment.

What the vendor documentation covers

The SUNMI Android version matrix supplies a model-specific baseline, not a test result for an application.
Peripheral documentation distinguishes built-in, external and scan-head-specific behavior.
Android package visibility and permission behavior must be evaluated against each API level in the matrix.

API surface

Matrix row: model, variant, Android, SUNMI OS or firmware and app build
Peripheral columns: printer, scanner, drawer, display and payment boundary
Interface column: Intent, SDK, AIDL, standard Android or native bridge
Evidence column: manufacturer-supported, tested-by-us, customer-validated, partial or not-supported
Method and acceptance references for each cell

Scope and prerequisites

Frozen app build and a named release owner.
Target device inventory, batches, Android and firmware records.
Peripheral, network, country and payment-boundary assumptions.
Reusable test script, result storage and evidence reviewer.

Permissions and ownership

Record permissions per row when Android API level or device policy changes the application behavior.
Management, kiosk and silent-install permissions belong to the device-owner record, not to a generic compatibility claim.
Use synthetic or redacted data; serial, IMEI, MAC, credentials and production records are not matrix fixtures.

Error handling

Capture per-row failures, fallback behavior, release-blocking criteria, environmental exceptions and rerun requirements. Do not collapse an intermittent or unsupported result into a generic pass.

Known limitations

The vendor Android matrix does not test the customer application or its peripherals.
A result on one firmware, batch, scan head or app build cannot be generalized to another row.
Some models have multiple Android versions or configuration-dependent hardware.
This guide describes a matrix method; a project conclusion belongs to a named revision and acceptance record.

Implementation path

01
Define the workflow and one application build that will be compared. Freeze the release candidate before populating result rows.
02
Build the device inventory from the current SUNMI Android matrix, including variant, batch and country assumptions. Keep K2 Android versions as separate rows.
03
Add one row per exact combination of model, Android, firmware, app build, peripheral and interface. Never fill a row with a family-level assumption.
04
Run the same scripted smoke path on every row, then add interface-specific cases for printing, scanning, display, drawer, permissions, lifecycle and offline behavior.
05
Store raw result, summary result, repetition count, date, reviewer and known limitation next to the row. Keep manufacturer facts in a source column rather than blending them into test output.
06
Promote a row only when the evidence state and acceptance criteria are explicit. Do not publish a conclusion without a recorded result.
07
When firmware, app build, accessory or SDK changes, create a new matrix revision or rerun the affected rows.

Verification checklist

Every row has model, variant, Android, firmware, app build, peripheral and interface values.
Every row has a reproducible method, date, reviewer, repetitions and raw result.
The same core workflow and failure cases run on each target row.
Rows with different K2 Android versions or scan heads are not merged.
No manufacturer specification is labelled as a UnitWeave test result.
Published conclusions identify the exact matrix revision and remaining scope questions.

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 matrix, device identifiers or production result is published. Use the row schema with synthetic values, then attach controlled evidence to the project record.

Source basis

Source provenance

Sources checked: 2026-08-30

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 Device's Android VersionSUNMI / Model-specific Android version information; some models have multiple versions or configurations. / Sources checked: 2026-08-30
External SUNMI documentation. Link to the current vendor page; do not redistribute vendor SDK binaries or assume every model shares the same implementation.
Open reference
SUNMI Integration GuideSUNMI / General integration entry point and vendor documentation navigation. / Sources checked: 2026-08-30
External SUNMI documentation. Link to the current vendor page; do not redistribute vendor SDK binaries or assume every model shares the same implementation.
Open reference
Introduction to SUNMI Printing ServicesSUNMI / Built-in and external printer paths, connection types, modes and device configuration. / Sources checked: 2026-08-30
External SUNMI documentation. Link to the current vendor page; do not redistribute vendor SDK binaries or assume every model shares the same implementation.
Open reference
Code Scanner Engine (Infrared scan code)SUNMI / Model and scan-head dependent infrared scanner modes, symbologies, output encodings and triggers. / Sources checked: 2026-08-30
External SUNMI documentation. Link to the current vendor page; do not redistribute vendor SDK binaries or assume every model shares the same implementation.
Open reference
Overview of SUNMI Customer API SDKSUNMI / Customer API modules, asynchronous service connection and model or device-scope boundaries. / Sources checked: 2026-08-30
External SUNMI documentation. Link to the current vendor page; do not redistribute vendor SDK binaries or assume every model shares the same implementation.
Open reference
Android package visibilityAndroid Developers / Package visibility and manifest queries for Android 11 and later. / Sources checked: 2026-08-30
External Android documentation. Apply the guidance to the target Android API level and device policy.
Open reference