Android cabinet remote access and onsite handoff

Open the illustrated installation atlas and cabinet checklist.

Instructional illustration; screens and device details vary. Follow the exact steps and approved release record below.

Start with an existing, authorized manufacturer remote-support connection if the cabinet already has one. Otherwise, our recommended first access method is AnyDesk for Android with an onsite helper and the control plugin offered by the app. This is a practical first test, not a guarantee for every Android vending cabinet. Someone must normally perform initial installation and permission approval unless a working, authorized management agent is already provisioned.

Remote access has not yet been tested on the photographed VC EL cabinet. The user has no current physical access to it. Its installed software and controller remain unidentified, and its flicker has not been repaired. Use current verified downloads and machine-app selection when an approved software change is required; installing a remote-support app does not require replacing the vending application.

Choose the access method

1. An authorized vendor support agent already works

Recommended path: Use that established connection to collect identity and diagnostics.

Qualify it: Confirm the account owner, permitted support staff and actual screen/control access.

2. First visit to a generic Android cabinet

Recommended path: Use AnyDesk plus its suggested control plugin, with a helper present.

Qualify it: Record the exact Android version and ROM. Verify Accessibility permissions, a visible screen and working touch injection.

3. Supported ZHZN KioskX installation

Recommended path: Use Operator's native remote-screen workflow for the kiosk app where enabled and ready.

Qualify it: Verify current approved phone, backend and cabinet releases, account ownership, a fresh capture and successful input acknowledgement.

4. Routine unattended access to Android itself

Recommended path: Qualify AnyDesk on the exact ROM, or use an OEM-supported TeamViewer Host or managed support agent.

Qualify it: Start a successful new session after reboot without a local tap. Viewing alone does not qualify control.

5. Unidentified VC EL/Silkron candidate

Recommended path: Preserve the existing shopper app. Use attended support for identification first.

Qualify it: Collect About, package, OS, controller and license evidence before selecting any replacement software.

AnyDesk specifies Android 7.0 or later for remote control. The documented Reyeah RK3288 configuration runs Android 7.1.2, making AnyDesk a better initial candidate there than a current TeamViewer installation. TeamViewer's newer operating-system matrix requires Android 8 or later for both QuickSupport and Host; older individual help pages still mention lower versions. Check the current matrix and exact installer rather than relying on those older statements. AnyDesk Android requirements, TeamViewer current requirements.

First onsite AnyDesk session

Before starting, the cabinet owner and helper should agree a service window. Finish any shopper transaction and use the cabinet's existing service procedure to suspend new sales. Keep the existing app configuration and unresolved-order records.

1. From the official AnyDesk distribution, install/open the Android app on the cabinet. Follow its prompt for the appropriate control plugin; do not pick an unrelated plugin merely because its name looks similar. Official control-plugin guidance.
2. Enable the requested plugin in Android Accessibility and grant the required screen-sharing permissions locally. A universal plugin may provide only limited control; manufacturer restrictions can leave a device view-only.
3. Exclude both AnyDesk and its control plugin from battery optimization using the cabinet manufacturer's settings. Some plugins require a reboot; perform that only during the controlled acceptance procedure below. Official Android setup and troubleshooting.
4. Give the assigned support person the service name and AnyDesk ID/alias through the approved support channel. The helper accepts the first connection and any screen-capture prompt. The support person confirms the physical cabinet and software machine ID with the helper before interacting.
5. Begin with observation and a harmless navigation target. Confirm that a single remote tap reaches the intended control; compare the result with the helper's view. Do not use a paid purchase, dispense button or destructive setting as a touch test.
6. Record whether the connection provides view only, kiosk-app control, or Android system control. These are separate results. Keep the helper available until disconnect/reconnect has also been checked.

If installation or Accessibility is blocked, record the policy or error and involve the provisioning owner. This guide does not prescribe rooting, replacing the launcher, clearing app data or exposing Android debugging to the internet as a remote-access setup step.

Qualify unattended access

For AnyDesk, enable Unattended Access in the Android permission profile and set a unique cabinet password. Configure two-factor authentication. Android 10 and newer can still require a person at the cabinet to approve screen capture, even when that password is configured. AnyDesk unattended setup and Android limitation.

Android's MediaProjection API requires user consent for each projection session; Android 14 strengthens single-use token enforcement. Therefore an app that starts at boot and accepts a remote password does not, by itself, prove that a fresh screen-sharing session can start unattended. OEM-integrated capture agents must be assessed on their actual implementation. Android screen-capture requirements.

Run this acceptance while a helper remains onsite. Mark every result pass / fail / not tested, with time, cabinet/ROM/app versions and evidence:

Call a cabinet unattended accepted only for the exact configuration that passed the new-session and reboot checks without a helper approving access or capture. Otherwise record attended support required. A failed boot test is not a reason to leave the site assuming the connection will recover later. Firmware, Android, plugin or remote-app changes require the affected checks again.

What each machine family can currently provide

ZHZN KioskX: native screen capture reads the application's own window. It is useful for its storefront and service UI, but does not establish visibility/control of Android Settings, boot screens or other applications. Older Android capture paths may omit separately rendered video surfaces. The optional remote-screen feature, agent readiness and current installed releases must be verified for that machine. See ZHZN operation and release evidence.

For the native workflow, require a fresh screen and reported readiness before sending input. Stale, expired or unready controls must be refused; a request queued by the server is not proof that a tap happened. Follow the after-input inspection procedure, including its matching acknowledgement and screenshot. Native text input is limited to supported Android text fields; do not assume text injection into the shopper WebView. Treat these as acceptance requirements on the installed phone/backend/cabinet combination, not evidence that an older APK has these safeguards.

Reyeah JD: stock Reyeah 1.2.8 removed bundled gotoagent remote control. Its vending app remains com.ruiye.jd. An optional KioskX screen companion is a separate, headless role; its exact role value is companion, with companionMachineNo matching the existing Reyeah software machine number. Set that role before first launch through approved provisioning. It requires a validated privileged/root firmware arrangement for capture and input; installing the app does not install or grant root. Keep the vendor app responsible for dispensing. A normal ZHZN kiosk-role install is not a substitute. See Reyeah operation and limits.

VC EL / possible Silkron: retain the existing vending APK until its identity is established. A reseller sticker or Android touchscreen is insufficient to identify Vendron. If Vendron is confirmed and its authorized cloud service is already connected, use the supported vendor diagnostics. Silkron advertises screenshot requests across its editions, but the named Cloud “Remote Control” feature covers lockdown/shutdown/restart and is marked Windows-only for Advanced/Ultimate; that is not an Android desktop-control guarantee. Silkron feature availability, integration requirements.

Companion provisioning and readiness contract

The following contract is verified in the prepared Android/backend source. It requires the matching approved releases; check downloads and release evidence before provisioning. It is not evidence that an older companion authenticates or that any cabinet has passed acceptance.

The provisioning owner sets the private app preferences role=companion and companionMachineNo for the exact Reyeah machine, or uses an approved build configured with that role and machine number. The new client reads companion-credentials.json from its private Android filesDir. This is a protected provisioning file, not a file to publish on downloads or attach to a ticket.

Provision only the approved credential mode, keep values in the vault/protected device storage, and arrange device-key rotation/recovery with the credential owner. Do not copy a ZHZN fleet secret or infer automatic key enrollment/rotation from this file format. With no usable credential, the new client makes no HTTP request. Invalid credentials must be refused by the server. The cabinet serial, an Operator login and a service PIN are not substitutes for this credential.

The new client retains a returned x-device-witness in private app preferences using a checked persistent write. It binds that saved witness to a SHA-256 fingerprint of the provisioned device key: subsequent requests with the same key use the saved witness instead of the initial JSON value, while a replacement key ignores the old saved witness. An authenticated response can advance the witness even when its body reports an error. This maintains the witness chain; it does not enroll or rotate the device key. Include this behavior in credential/reconnect acceptance and keep all witness values out of tickets.

For the new companion, input readiness requires the remote-screen feature to be enabled, successful root-user verification, and a valid full-device PNG capture with original dimensions within the preceding 30 seconds. It reports screenScope=device only while ready; otherwise the scope is unknown. For native ZHZN the scope remains app, with its own foreground window required. This difference matters when diagnosing Android Settings or a display fault.

The new input contract uses a 15-second execution deadline and records attempted command IDs to suppress repeated delivery. Outcomes distinguish capture/upload failure, input failure/timeout, expiry and duplication from a submitted input or captured frame. injected confirms input submission, not that the intended business action or physical vend completed. Companion shell text is limited to printable ASCII; use supported local entry when that is insufficient. Check these behaviors, credential refusal and reboot recovery on the installed releases before enabling unattended control.

After each Operator input

This procedure applies to the matching prepared Operator, web, backend and cabinet implementations. Verify their approved release evidence and installed behavior before accepting control.

1. Start only from a fresh, decoded image with current readiness. After sending one input, further input stays blocked while its outcome is pending. An HTTP response accepting or queueing a command does not confirm execution.
2. Match the input acknowledgement to that command's ID. For a terminal success or failure acknowledgement, the backend requests one follow-up screenshot while remote screen is enabled. The input result's lastResult.captureId identifies that capture (after- followed by the command ID). The client must load and decode that exact fresh frame, from the latest frame or retained history. An unrelated live-stream frame is insufficient: it may show the screen before the input ran. A capture acknowledgement is separate and cannot replace the input result.
3. Only a matching successful input result and its fresh, decoded follow-up frame allow further control, subject to current readiness. A failed result stops Control even if a diagnostic follow-up image is available. Inspect the image and reported outcome before explicitly starting Control again; do not replay the failed action automatically.
4. A missing verdict, transport timeout, or server expiry before an acknowledgement leaves the result uncertain. A command may already have partly affected the screen. Stop and inspect fresh state and the original action before any explicit resumption. Use the client's inspection/recovery step when offered; do not assume that a new random frame or the absence of an acknowledgement means nothing happened. If a matching frame cannot be obtained, keep Control stopped and investigate capture/connectivity or use attended support.

For a purchase, dispense or refund, screen inspection alone cannot resolve physical delivery or provider settlement. Preserve the original transaction reference and follow the relevant reconciliation procedure. These safeguards have not yet passed physical acceptance on the photographed cabinet.

TeamViewer and managed vendor alternatives

TeamViewer QuickSupport is appropriate for attended help. Host is designed for unattended access and is assigned to a TeamViewer account; supported remote control still depends on the manufacturer. The Universal add-on belongs to QuickSupport and cannot be used to claim unattended Host compatibility. Choose Host only after confirming support for the exact Android/OEM configuration and completing the same reboot acceptance. Android Host, Universal add-on limits.

A manufacturer-approved management agent can be a better fleet choice when its firmware integration is already deployed and supported. Obtain the manufacturer's supported model/ROM list, enrollment procedure, account ownership and recovery procedure. “MDM installed,” “Android device owner” or a shared chipset name is insufficient evidence that full remote viewing and touch will survive reboot.

This is business use. AnyDesk requires licensing on clients that initiate commercial connections; receiving-only clients do not need their own license, although managed-device and concurrency limits depend on the plan. TeamViewer's published commercial mobile-support guidance requires an appropriate license and Mobile Device Support add-on. Confirm the applicable current plan before rollout; no purchase is implied by this guide. AnyDesk licensing, TeamViewer commercial mobile support.

Credentials and support handoff

Use company-controlled support identities, individual staff access and two-factor authentication. For AnyDesk, restrict incoming access to approved IDs/aliases using its Access Control List. Store each unique unattended password in the approved credential vault and reference the vault record in the handoff; do not place passwords, recovery codes, enrollment tokens or payment credentials in chat or screenshots. Revoke access when the assignment ends. AnyDesk access restrictions.

Record these non-secret fields in the authorized service ticket:

VC EL onsite identification and flicker checklist

1. Photograph the cabinet rating/serial labels and record the software's own machine ID. Reconcile the two; do not assume a barcode is the cloud ID.
2. Through the authorized service procedure, capture About/app name, package, version, Android version/build, controller model/firmware and configured protocol/serial settings. If the software appears to be Vendron, record its edition and license/API activation status without sharing license secrets. Do not open live electrical assemblies to collect a label.
3. Observe the display directly and take a short camera recording with a timestamp. Obtain a remote image from the same period when possible; record whether it is an app-only capture or the whole Android display.
4. Note whether the symptom occurs in the shopper app, advertising area, Android Settings or startup screen. A stable remote image while the physical display flickers suggests investigation of the display path, but capture timing, video-layer omissions and camera banding prevent that comparison from proving a failed part. App reloads visible in both views warrant software/restart evidence.
5. Preserve pending sales and service records. Before any approved reboot, confirm there is no active or unresolved purchase/dispense and no update in progress. Record uptime/restart evidence where available, then check kiosk and support recovery together.
6. Hand over the non-secret fields above and the evidence for the VC EL diagnostic and commissioning procedure. Remote visibility alone does not certify repair, controller compatibility, payment settlement or physical product delivery.