Developer hub / public basics / Technical article

Scanner Intent and SDK integration

Choose between the SUNMI OS scanner Intent, the camera-based decoding SDK and an infrared scan engine, then normalize data and trigger behavior in the host app.

Discuss your project

Choose between the SUNMI OS scanner Intent, the camera-based decoding SDK and an infrared scan engine, then normalize data and trigger behavior in the host app.

Source basisSUNMI official documentation
Public references6
Publication statePublished
v1.0.0 / Technical articleSources checked: 2026-08-30
Model scope
V2s, V2s PLUS, L2s PRO or another named SUNMI configuration. Scan-head availability, symbologies and output mode must be confirmed for the exact device.
Android version
Use the target device matrix. Android 11 and later package-visibility rules apply when the app queries documented scanner components.
Firmware
Not fixed by the public note. Record the exact image because scanner component names, settings and supported output paths are device-specific.
SDK / interface
Scanner Intent components, camera-based ImageScanner SDK and infrared Code Scanner Engine; select one path rather than treating them as interchangeable.
Application build
Record the exact project build and hardware environment before deployment.

What the vendor documentation covers

  • SUNMI documents an OS-integrated scanner Intent path and a separate camera preview plus decoding SDK path.
  • The Code Scanner Engine page distinguishes scan-head vendors and device-specific symbology support.
  • USB and serial scanners can expose keyboard-like or broadcast output and have separate encoding and trigger settings.

API surface

  • Documented scanner packages: com.sunmi.scanner and com.sunmi.sunmiqrcodescanner
  • Scanner Intent result Bundle fields: data, TYPE and VALUE
  • Camera SDK: ImageScanner, libsunmiscan.so and sunmiscan.jar
  • USB scanner broadcast: com.sunmi.scanner.ACTION_DATA_CODE_RECEIVED
  • Scanner setting action: com.sunmi.scanner.ACTION_BAR_DEVICES_SETTING

Scope and prerequisites

  • Named physical scanner path and scan-head model.
  • Required symbologies, trigger mode, output mode and character encoding.
  • Application receiver or native bridge owner and a sample data set.
  • Offline, duplicate-event, timeout and malformed-input acceptance rules.

Permissions and ownership

  • Camera-based decoding needs the Android camera permission and a runtime request flow appropriate to the target API level.
  • Package visibility declarations may be needed for scanner component discovery on Android 11 and later.
  • USB, Bluetooth or serial transport permissions depend on the accessory and Android policy; confirm them on the target image.

Error handling

Handle no component, denied camera permission, trigger timeout, empty decode, malformed Bundle, unsupported encoding, duplicate event, decoder contention and scanner disconnect as distinct states.

Known limitations

  • The supported barcode list varies by scan-head vendor and device configuration.
  • The official camera path describes ImageScanner as a single-instance, non-reentrant decoder; concurrent calls are not supported.
  • The documented legacy action spelling should be tested against the target image because component naming can differ by generation.
  • This guide is a scanner integration baseline; a compatibility conclusion belongs to a named project record.

Implementation path

  1. 01

    Classify the physical input first: built-in camera scanner, infrared scan head, USB scanner or serial scanner. The setup determines the API, trigger and encoding contract.

  2. 02

    For the OS scanner path, use the Intent action and component documented for the target image, read the returned data, TYPE and VALUE fields, and make the receiver tolerant of a missing or malformed result.

  3. 03

    If targeting Android 11 or later, declare package visibility for the scanner package that the application actually queries. Do not assume that a package name from one device image exists on another.

  4. 04

    For camera decoding, keep the preview within the vendor guidance, feed the decoder the grayscale image data used by the sample path, keep ImageScanner single-instance and non-reentrant, and call destroy() when the scanner is released.

  5. 05

    For infrared, USB or serial input, configure the named scan head, trigger mode, output mode and character encoding. The supported barcode set must come from the scan-head and model documentation.

  6. 06

    Normalize one decoded event at the application boundary. Apply duplicate suppression, focus rules, field length checks and encoding conversion before submitting a transaction.

  7. 07

    The vendor page lists a legacy action spelling com.summi.scan. Treat it as a compatibility path to verify on the target image, not as permission to silently replace the documented action with a guessed name.

Verification checklist

  • Record model, scan-head or scanner accessory, firmware, Android version and application build.
  • Test every barcode family required by the workflow, including damaged, low-contrast, long and non-ASCII values.
  • Test hardware trigger, software trigger, continuous mode, timeout, cancel and reconnect behavior.
  • Verify that rapid scans do not create duplicate or out-of-order application submissions.
  • Verify UTF-8, GBK, ISO-8859-1 or Shift-JIS handling only when the selected scanner output is configured for that encoding.
  • Record the result per device and scan path; a code list from one scan head is not a result for the whole product family.

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 private decoder library or native binary is published here. Obtain the current scanner distribution from SUNMI or the authorized project channel and use the public documentation to define the bridge.

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 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
  • Using Camera-Based Barcode Scanner SDKSUNMI / Built-in scanner Intent path and camera preview plus SDK decoding path. / 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
  • Barcode Scanner User GuideSUNMI / USB and serial scanner output, broadcast actions, software triggers and encoding choices. / 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 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
  • 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