Android Vending Controllers: Freeze the Hardware Baseline Before Building the App
WEIMI INSIGHTS / SOFTWARE INTEGRATION
Build against a named configuration.
An operating-system version and screen size are only the beginning of an integration specification.
IDENTIFY
Record the actual board and system build.
CONNECT
Map the peripherals and supported interfaces.
CONTROL CHANGE
Review substitutions before they reach production.
“Android controller with a touchscreen” does not define a reproducible development target. Agree the exact hardware and software baseline before integration begins.
01 / BUYER NOTES
Turn a headline specification into a baseline
A buyer may request a particular Android version, a screen dimension and access to an SDK. Those details help start a discussion, but they do not identify the complete environment in which the vending application must run. Different boards and system builds can expose different interfaces despite sharing the same operating-system label.
Create a configuration record with the board model, system build identifier, memory and storage specification, display configuration and relevant peripheral versions. Record what is confirmed and what is still proposed. A sample supplied for development should be traceable to that record.
02 / BUYER NOTES
Map the boundary between the app and machine control
The touchscreen application may present products and payment steps while another controller operates motors, locks or sensors. Identify which component owns each action and how the application receives the result. A graphical interface demonstration alone does not show that the required machine-control path is available.
Ask for documented commands, responses and error states for the agreed integration. Clarify whether the supplied SDK covers payment, dispensing, status reporting or only a subset. Treat unsupported functions as open engineering questions rather than assuming that access to Android grants control over every peripheral.
03 / BUYER NOTES
Include the display details that affect the interface
A diagonal screen measurement does not describe resolution, orientation, usable area or touch behaviour. The interface should be tested on the actual display arrangement, including any reserved areas used by the system or payment application. Text that fits on a developer’s monitor can become cramped on the installed screen.
Use realistic product names, supported languages, prices and error messages in the trial. Check physical access to controls and readability in the intended installation. This evaluation should produce specific issues to fix, not an unsupported claim that one screen size works for every customer and venue.
04 / BUYER NOTES
Make peripheral connections explicit
List the devices the app depends on and the confirmed communication method for each. Examples may include a payment reader, scanner or machine controller, but the available connections must come from the proposed hardware documentation. A visible connector does not prove a supported software interface or permission to use it.
Record cable arrangements, assigned interfaces and any relevant configuration in the baseline. This gives the service team a way to compare a replacement assembly with the original. Without it, a seemingly minor substitution can become a difficult fault that appears only when an external device is used.
05 / BUYER NOTES
Agree how replacements and updates are assessed
A supplier may need to replace a discontinued board or update a system build. Decide how the change is communicated and which tests must pass before it is accepted for the project. The aim is controlled compatibility, not a promise that an operating-system version will remain unchanged forever.
Separate app updates from underlying system changes in the release record. Include a documented recovery approach appropriate to the supplied equipment. Do not assume that a consumer Android backup method or an app package alone can restore a complete vending configuration.
06 / BUYER NOTES
Use one acceptance record for the complete build
Run the agreed customer and service journeys on the named baseline: startup, normal selection, supported payment, successful dispensing, failed dispensing and recovery from the documented interruption cases. Record the observed result and the configuration used for the trial.
Keep the sample, test record and delivered configuration connected. If production hardware differs, identify the difference and the additional review required. This makes an approval meaningful and helps both sides diagnose later faults without arguing about what the original demonstration actually contained.
Three layers to identify
Application
Record: Version and required functions.
Verify: User journeys and error handling.
System and controller
Record: Board, build and controller versions.
Verify: Supported interfaces and recovery.
Peripherals
Record: Models, connections and configuration.
Verify: End-to-end operation on the delivered build.
PRACTICAL ANSWERS
Questions worth asking before you order
Does the same Android version guarantee compatibility?
No. Hardware, system build, permissions and peripheral interfaces can still differ.
Does an SDK cover every vending function?
Only the supplied documentation and demonstrated implementation establish its scope. Confirm each required function.
Should a supplier promise never to change hardware?
A practical agreement should address change notification, compatibility review and acceptance rather than rely on an indefinite freeze.
YOUR NEXT STEP
Share the intended software boundary
Send the application requirements and peripheral list to WEIMI so the controller configuration and documented integration options can be reviewed.
Explore equipment →Discuss your requirements →