Custom Android applications / workflow engineering

Custom Android Apps for SUNMI POS and Kiosks

We build focused Android applications for SUNMI POS terminals, self-service kiosks, handhelds and payment devices when a generic app leaves an important part of the workflow unresolved. The work can cover the operator interface, device actions, business rules, API boundary, offline behavior, fleet controls and release handover.

Custom Android app

Custom Android applications / workflow engineering

Build the application around the work, not around a feature list.

A custom app is useful when the operator must complete a small number of important tasks quickly and reliably: take an order, scan an item, print a label, capture proof of delivery, run a self-service flow or move a payment request through a defined state. We turn that workflow into a named application scope and connect it to the exact device configuration under review.

01 / INPUT01

Your workflow

Roles, tasks, exceptions, data and acceptance criteria become the product brief.

02 / BUILD02

The device surface

Screens, printer, scanner, display, drawer, network and Android lifecycle are treated as one system.

03 / HANDOVER03

A repeatable release

Signed builds, configuration, test evidence and deployment instructions travel with the app.

What we can build

A focused application can own the moments that generic software misses.

The list below describes common building blocks, not an unlimited promise. We select only the pieces required by the named workflow, then make the ownership and integration boundary explicit.

Operator screens and task flow

Create a clear Android interface for the person doing the work, with role-based actions, predictable states and a short path from input to confirmation.

Task map and screen states
Role and permission model
Responsive layouts, language and accessibility review

Printing, scanning and peripherals

Connect the app to the device actions that make a commercial terminal useful, while handling timeouts, duplicate events, reconnects and operator recovery.

SUNMI printer or scanner interface
Cash drawer or customer display boundary
Result, retry, reprint and failure states

Business rules and APIs

Implement the rules that decide what can happen next and connect the app to the approved backend, ERP, POS, order, inventory or field-service system.

API contract and data mapping
Authentication and session handling
Validation, audit events and ownership notes

Offline-first work and sync

Keep defined tasks usable when connectivity is imperfect, with an explicit local queue, conflict rule, retry policy and visible sync state.

Offline scope and data lifetime
Queue, retry and idempotency behavior
Conflict, recovery and support diagnostics

Kiosk and managed-device mode

Prepare a restricted experience for self-service or fleet use, including startup, reset, update, device naming and the MDM policy assumptions.

Kiosk navigation and exit rules
Preload, signing and version profile
MDM, recovery and replacement checklist

Release, testing and handover

Turn a working build into something another team can operate: versioned packages, test evidence, configuration records and a clear maintenance owner.

Acceptance build and regression checklist
Release notes and configuration reference
Deployment guide and support escalation map

The application system

Four layers keep the scope honest.

A screen that works in a demo can still fail in a store, warehouse or vehicle. We review the application as a chain of responsibilities so that the device, data and operational owner are visible before the first release.

Workflow layer

What the operator must accomplish and what the customer or next system receives.

Happy path and exception path
Roles, permissions and acceptance criteria

Application layer

Screens, state, business rules, local data, API calls and diagnostic messages.

Loading, empty, error and retry states
Session, security and data ownership

Device layer

Android version, firmware, model variant, printer, scanner, display, drawer and network behavior.

Named interface and accessory configuration
Lifecycle, sleep, reconnect and power behavior

Fleet layer

How the signed package is configured, installed, updated, monitored, replaced and supported across locations.

MDM, preload and release ownership
Recovery, rollback and handover records

How we work

From rough idea to an application someone can operate.

Each stage produces a reviewable output. That keeps the project moving while making it possible to stop, narrow the scope or hand ownership to another team without losing context.

01
Discover the job
Walk through the current process, users, data, exceptions, devices and systems. Identify the smallest useful first release.
Output: workflow brief, roles, assumptions and open decisions.
02
Define the device contract
Name the SUNMI model, variant, Android, firmware, accessories and integration surfaces. Separate public vendor facts from project evidence.
Output: device profile, interface map and validation plan.
03
Shape the experience
Agree the screen states, navigation, permissions, offline behavior, language, accessibility and recovery messages before implementation expands.
Output: screen map, acceptance criteria and API questions.
04
Build and prove
Implement the agreed workflow, connect the named interfaces and exercise the important paths on the exact application and device setup.
Output: release candidate, test notes, known limitations and evidence state.
05
Prepare the handover
Package the signed build, configuration, deployment sequence, MDM assumptions, update route and support ownership for the operating team.
Output: deployment profile, handover pack and next-release boundary.

What arrives with the work

A custom app is more than an APK.

The exact pack depends on scope, but a useful delivery includes the information needed to review, install, operate and maintain the result.

01
A named product brief with workflow, roles, data and acceptance criteria
02
Screen and state map covering normal, empty, offline, error and recovery paths
03
Application source, build instructions and dependency or license notes where included in the agreement
04
Device integration notes for the exact model, Android, firmware and accessory setup
05
Signed release candidate, configuration reference and versioned release notes
06
Test record with method, date, environment, reviewer, result and known limitations
07
Deployment and handover guide covering preload, MDM, updates, rollback and support ownership

Fit and boundaries

Know when a custom app is the right tool.

We are a good fit when the workflow is specific, the device decision matters and the team needs a usable path from build to deployment. We scope adjacent work separately so a small application does not quietly become an unowned platform programme.

Evidence state

A POS, ERP or field system needs a focused device-side workflow rather than a full replacement
A product company needs a branded Android companion app for a defined hardware bundle
A kiosk, handheld or payment workflow needs device-specific screens and peripheral behavior
A multi-site rollout needs a controlled package, configuration, acceptance record and handover

Scope separately:

Large backend or ERP replacement programmes, data migration and ongoing data operations
Payment acquiring, certification, regulated approvals or country-specific financial obligations
Private credentials, production customer data, private SDK binaries or signing keys in public materials
24/7 monitoring, local field service, unlimited changes or ongoing maintenance without a written scope

Before the first brief

Questions that shape the build.

01Can you build a complete POS or ERP?

We can scope a focused Android application or a device-side workflow. A complete POS, ERP, backend replacement or data migration is a different programme and needs its own product, data, security and support scope.

02Can you use our existing APIs and application?

Yes, when the integration boundary, authentication method, data contract and software owner are available. We can extend an existing system, create a device-side companion or connect a qualified third-party platform.

03Can the app print and scan?

Printing and scanning can be included when the exact SUNMI model, variant, firmware, interface and accessory path are named. The project record covers triggers, result states, timeouts, retries and the acceptance method.

04Can you build payment features?

We can scope application screens and approved integration boundaries around a payment workflow. Acquirer integration, certification, transaction security and market approval remain separate responsibilities and must be confirmed for the country and provider.

05Who owns the source code and future changes?

Ownership, repository access, signing, third-party licenses, maintenance, release approval and support are written into the proposal. They are not inferred from a demo build or a public sample.

06Can you deploy the app to a fleet?

Yes, deployment engineering can cover preload, device naming, MDM policy, staging batches, update sequencing, rollback and handover. The fleet owner, MDM tenant and recovery responsibilities remain explicit.

Ready to define the first release?

Bring the workflow. We will map the smallest useful application.

Tell us who uses the device, what must happen on screen, which SUNMI model or peripherals are in consideration, where the data comes from and how success will be accepted.

Custom Android app Compatibility Deployment