Android remote control taps not working in file picker on Rockchip devicesSolved

This behavior usually points to an OS-level input restriction rather than a general Hexnode remote control issue.

Since remote control works across the rest of the device but fails only inside the native Android file picker, the file picker is likely running through Android’s Storage Access Framework or a secure system component where injected accessibility touch events are not accepted by the OEM Android build.

A few indicators support this:

1. Remote taps work elsewhere on the device.
2. Physical touch on the device selects the file successfully.
3. The same workflow works on Samsung devices.
4. The issue occurs even outside kiosk mode.

Samsung devices can support deeper remote input capabilities through Samsung Knox APIs when using the dedicated Hexnode remote control service. On generic or non-standard Android builds, Hexnode Assist depends on how the manufacturer has implemented accessibility-based input handling. Some OEM builds block injected taps inside file picker or secure overlay screens.

If the goal is to avoid physical interaction during setup, the best workaround is to bypass the file picker where possible. For example, if the configuration file can be placed in a known path, you can upload it under Content > My Files and deploy it using an Android File Management policy to the exact destination path expected by the app.

That makes sense. What is the practical difference between Hexnode Remote View and Hexnode Assist for Android remote control? I’ve seen both mentioned and wasn’t sure which one applies here.

For Samsung devices, Hexnode can use the dedicated remote control service with Samsung Knox capabilities. This allows stronger system-level remote input support on supported Samsung Knox devices.

For non-Samsung Android devices, including many OEM or Rockchip-based devices, Hexnode Assist is used. It relies on Android accessibility services for remote input. Whether every screen accepts injected input depends on the device manufacturer’s Android build.

That is why the same file picker workflow may work on Samsung but fail on a generic Rockchip device, even though the rest of the remote session works normally.

The File Management policy workaround is useful only if the file can be pre-staged or copied into a predictable location before the app asks for it. If each device generates a unique file during first install, a static fleet-wide file push will not be suitable.

In our case the file is unique for each kiosk and gets created during the first install, so pushing the same .txt file to every device would not work. I tried renaming the old installation file and then reinstalling the kiosk app. Since the app no longer saw the old file, it installed cleanly and generated a new one. That got the kiosk functional again.

That is a valid recovery workaround for this scenario.

If the app can regenerate the installation or configuration file when the old one is renamed or removed, that avoids the blocked file picker interaction entirely. For a production fleet, test the rename or removal workflow on a small number of affected Rockchip devices first before applying it broadly.

To summarize the recommended approach:

1. Confirm that remote control works outside the native file picker.
2. Confirm the issue is reproducible outside kiosk mode.
3. Treat the blocked file selection as an OEM Android file picker limitation.
4. If the file is static, deploy it with Hexnode File Management to the expected path. 5.
5. If the file is unique per device, use the app-supported recovery method, such as renaming or removing the old generated file so the app creates a fresh one.

Hexnode cannot force all OEM Android file picker screens to accept injected remote taps if the OS blocks them, but avoiding the file picker usually resolves the deployment workflow.