Application: Nomid Remote
Document: V2.1.0
Last updated: 07/08/2026
Application version: Current portal-managed version
Editorial owner: Nomid MDM Documentation
Last editorial review: 07/08/2026
Editorial language: en-US
Remote Access lets an authorized portal user open and control a supported Android device or Pico headset from the browser. The current portal launches the session from a device action or device details; it does not require the administrator to install a separate controller application or manually copy the device access code.
The flow depends on three layers working together: the portal must expose the action to the operator, the policy must deliver the tech.nomid.remote helper application, and the device must start the service and allow the required local permissions.
This guide documents only behavior available in the current portal. Voice chat, file transfer, session recording, and multiple simultaneous controller sessions are not documented portal capabilities and must not be promised without functional confirmation.
tech.nomid.remote app, and reported its Remote Access identifier to the portal.Open the device policy in Policies and enable Remote configuration. Publishing this configuration adds the tech.nomid.remote helper application, forces its installation, delivers managed configurations, and grants the Android permission required for device identification when supported by policy.
Review the remote configuration fields before publishing:
Publish the policy and allow the device to synchronize before testing a session. Do not tell administrators to download a controller application as the standard portal setup. If the policy helper is absent or has not synchronized, the portal cannot establish the managed session.
Important: First-time permission release may vary by manufacturer, Android version, management mode, and applied policy. When a permission is denied, the portal may open the session without remote input or may be unable to display the screen.





Some Android versions or manufacturers block Display over other apps for this app or show that the feature is unavailable. Record this condition as a device limitation. Do not promise overlay support when Android blocks it; validate whether the session still displays the screen and whether remote input works with Accessibility enabled.
Use assisted access when someone at the device can accept screen capture, full control, or temporary authorization prompts. This mode is best for support with explicit consent at the time of service.
Use previously authorized access only when the company, policy, and device support the combination of start on boot, screen capture confirmation, permanent password, or automatic synchronization. Even in this mode, Android may still require an initial Accessibility or full control approval on the device.
In a VR/Pico policy, enable Remote Access and keep the remote apps automatically added by the solution as required. Saving the policy prepares distribution; the portal action becomes available only after the headset synchronizes and reports every readiness requirement.
If any requirement is missing, Remote Access remains hidden or unavailable to prevent a session without image or control. Check the applied policy, remote-app versions, connectivity, and latest status report; do not bypass the block with a manually entered code.
The Accessibility and full control sequence shown in this article's images is for Android. On a ready Pico headset, use Remote Access from the device page or policy drawer and wait for the browser session; do not look for the same phone Accessibility menus.
The browser overlay supports refreshing the stream, choosing Performance, Balanced, or Quality presets, minimizing or expanding the session, reconnecting after a recoverable interruption, and ending the session. Availability of remote input depends on device-side permissions and policy state.
Features such as voice chat, file transfer, recording, and multiple sessions may exist in complementary clients or legacy flows, but they are not part of the current portal procedure. Use them only if they are enabled for the company and confirmed by the functional owner.
tech.nomid.remote app is installed, the service has started, and Nomid Remote Input is enabled.Ending the portal session closes the active connection, but it does not automatically remove policy preparation or local permissions. When temporary support is complete:
Confirm the company capability and the user's Device Remote Access permission. If either is missing, changing unrelated Library or application permissions will not enable the action.
Confirm that Remote configuration is enabled in the assigned policy, that tech.nomid.remote is installed, and that the device has synchronized after the policy was published. The portal explains this policy state instead of opening an empty session.
For a Pico headset, also confirm that the VR/Pico policy has Remote Access enabled and that the device reported capture, input, and unattended capabilities. An ID without these capabilities does not release the session.
Open the NomidRemote app, tap Start Service, and accept screen capture/sharing when Android asks. If the app returns to Service is not running, review connectivity, applied policy, local permissions, and manufacturer restrictions.
Enable Nomid Remote Input in Accessibility and accept the full control warning. Without this permission, support may be able to view the screen but not send touches or commands.
Start the service again and accept the request on the device. If Android indicates that Display over other apps is unavailable, treat it as a version/manufacturer limitation and validate a compatible device before broad rollout.
Confirm that the device is online and retry once. If repeated attempts fail, record the device name, approximate time and time zone, policy name, and the message shown by the portal. Do not expose access passwords or managed configuration secrets in a support request.
Use Remote Access only for an authorized support purpose. The Accessibility permission grants sensitive device control and must be released only for the tech.nomid.remote app delivered by policy. Access to managed passwords is separately permission-gated and audited. Never place Remote Access passwords, HMAC values, or device secrets in chat or wiki content.