RustDesk Android control requires the phone owner's consent, screen-sharing permission, and separate supported input permission. Start with viewing only, accept each connection in person, and close the active session before changing permissions or putting the phone away.

Key Takeaways:

Seeing the screen does not prove input control is permitted.

Use manual acceptance; do not share passwords or enable unattended access.

Permission changes may leave an established connection active.

Check both immediate disconnection and refusal of the next connection.

What does RustDesk Android control require?

The documentation scope is RustDesk 1.5.0, a Google Pixel 8 with stock Android 16, and a Windows 11 controller. These official-documentation steps have not undergone a complete end-to-end device test. Confirm actual input support; firmware, policies, and permission screens can differ.［1］［2］

Keep the unlocked phone within its owner's reach. Both parties need a trusted conversation channel and authority for the task. Stop on employer-owned devices or managed accessibility settings and consult the administrator. Do not bypass capture confirmation, restricted settings, protected screens, or the lock screen.

The self-hosting and networking framework separates permissions from infrastructure. Use the existing RustDesk service arrangement without installing ID/relay servers. For connection-establishment failures, start with the RustDesk connectivity checks.

Step 1: Agree on identity, task, and stopping

Confirm the helper's identity through a channel you already trust, such as a known phone number. Agree on the exact action, which apps may be opened, and an instruction such as “stop now.” An incoming RustDesk ID alone does not establish a person's identity; reject unexpected requests even if they mention your support issue.

Prepare a harmless test screen: an empty local note containing no personal information, or a non-sensitive settings page. Close private apps and avoid notifications exposing messages during sharing. Do not open banking, password managers, authentication codes, health records, or other people's conversations. The helper should explain each action before taking it.

Record initial RustDesk permissions, Android accessibility state, and approval settings without IDs, passwords, or account data. Avoid whole-configuration exports that may contain access secrets. End any existing support session before changing settings.

Step 2: Get official software and require acceptance

Download matching Android and Windows packages from the official 1.5.0 release: ARM64 for Pixel 8 and the appropriate architecture for the PC. Avoid nightly builds, repackaged installers, or unknown helpers' downloads. Compare both installed versions with the release.［2］

For an official APK, Android may require permission for your browser/file manager to install unknown apps. Grant only that source, then revoke the permission. Do not disable Play Protect or remove restrictions to force installation.［3］

On the phone, open Share Screen. In its upper-right approval menu, select the option requiring a manual click for incoming connections, represented in the official settings documentation by approve-mode=click. Do not leave password-only or password-or-click approval selected. Do not create a permanent password or send the displayed temporary password to the helper; this workflow relies on the owner's acceptance for each request. If the build does not expose the documented choice, stop rather than guessing that approval is required.［4］

Keep file transfer, audio capture, clipboard synchronization where exposed, and unattended access disabled. No server fields, router forwarding, or Windows inbound-control service need changing for the Windows computer to initiate this assistance session. Record the original approval setting so you can restore an authorized prior arrangement later.

Step 3: Separate RustDesk Android permissions

Enable Screen Capture only when the phone owner is ready. Read Android's system capture prompt and select the smallest sharing scope that still shows the agreed test screen, if the prompt offers a choice. Capture permission starts the sharing service; it is not the same as accepting a particular helper. Start with Input Control off.［1］

Have the helper enter the phone's RustDesk ID privately on Windows and request a remote-control connection. The owner checks the request against the helper they just contacted and accepts it on the phone. Do not broadcast the ID in a public screenshot, support forum, or chat group.

Verify that the harmless screen is visible and ask the helper to attempt one harmless tap. With input permission withheld, it should not change the phone. If input works unexpectedly, end the connection and inspect RustDesk's permissions and Android's active RustDesk accessibility service before proceeding. A controller's own “view only” option is useful but is not a substitute for withholding permission on the phone.

The guide to powerful app permissions explains capture and accessibility risks. Consent to see one setting does not authorize file access or unrelated account changes.

Step 4: Allow input only for the agreed action

Close the viewing session first. If input is genuinely needed and supported, the owner enables Input Control and follows the Android settings link to the RustDesk input accessibility service. Open Settings → Accessibility, or search Settings for RustDesk. The official guide illustrates Installed Services on another system; labels can differ. Read the Android warning before granting access.［1］［5］

If Android refuses the permission or the service is unavailable, keep the exercise view-only and let the owner perform the taps. Do not turn on restricted settings, install an unknown control plugin, root the phone, or bypass lock-screen and secure-window protections. A black protected screen is a reason to stop that action, not evidence that broader access should be granted.

The helper requests a new connection and the owner accepts it again. On the harmless screen, ask for one agreed tap or short non-private text entry, then check that the owner can still use the phone and reach RustDesk's stop control. Successful viewing alone cannot establish successful input.

If the screen is visible but input fails, check whether the expected accessibility service and RustDesk input permission are enabled. Do not repeatedly grant unrelated permissions. If the permission is enabled yet the harmless operation still fails, report that combination as view-only until supported behavior is confirmed. Use the general device troubleshooting order to isolate app and system conditions.

Step 5: Check viewing, refusal, and control separately

Use the table to record your own observations privately. It contains expected behavior, not results obtained by the author. Each permission change below begins with closing the old session and ends with a newly requested connection.

Check method	Expected observation	If it fails
Accept a request with capture on and input withheld	Harmless screen visible; helper cannot operate it	End session; inspect phone-side permissions and accessibility
Enable supported input, then accept a new request	Agreed harmless tap works; owner retains local control	Keep view-only if the system cannot provide input
Close session, withhold input, then reconnect	Helper can view only after acceptance and cannot tap	Stop service; inspect remaining input authorization
Owner closes the established connection	Helper loses the live screen and cannot keep operating	Stop sharing service and Android capture immediately
Stop service and revoke permissions, then request again	No new screen or input access is granted	Keep disconnected; find remaining services or credentials

A frozen frame does not prove live capture continues: check harmless screen changes and input without revealing private content. Network failure cannot prove rejection. Test manual refusal with a reachable service and a fresh request.

Distinguish the app connection from system proxy or TUN traffic. The comparison of proxy and TUN capture helps explain that distinction; changing network routing does not grant Android input permission. Do not alter a working VPN or proxy just to make a permission test pass.

Step 6: Make RustDesk stop screen sharing

The phone owner closes the active connection in RustDesk; the helper closes that Windows session. Then stop the phone's sharing service and check Android's capture indicator. If capture remains active, use Android's system stop-sharing control as well. Keep the phone in hand until live viewing and input have ended.［1］

Do not merely toggle Input Control off while leaving the session open. The official Android guide says permission toggles other than Screen Capture affect new connections, not established ones. Closing first prevents a change intended for the next connection from being mistaken for revocation of the current helper.［1］

If the stop control fails or RustDesk becomes unresponsive, use Android Settings → Apps → RustDesk → Force stop, then check that capture and remote interaction have ended. This ends the app rather than solving the underlying fault; do not start another session until the stopping problem is understood. Android's app troubleshooting guidance documents force stopping.［6］

Step 7: Revoke access and check the next request

With no active session, turn off RustDesk capture/input permissions and disable the RustDesk input accessibility service in Android Settings. Remove any temporary permissions you enabled, including the package install-source permission. Restore only permissions that were present before and remain explicitly authorized; do not re-enable old unattended access merely because it existed.［1］［3］［5］

Ask the known helper to try once more while the sharing service is stopped. Confirm no live screen or input is obtained. If you later restart RustDesk, require new capture consent and manual acceptance; declining that fresh request must not reveal the screen. Never send a password as a workaround for the refusal check.

Keep a private note of app/OS versions, permissions, observations, stopping, and next-request refusal. Do not collect credentials or private screens. If access persists, stay disconnected and inspect permanent credentials or other remote-support apps before seeking help.

Summary

Begin with an identified helper, a narrow task, and a harmless screen.
Grant viewing and input separately, and accept each connection locally.
Close the current connection before changing its permission boundary.
Stop the service, revoke temporary access, and check the next request.

FAQ

Can RustDesk control every Android phone?

No universal input guarantee applies. Actual control depends on the system and permitted accessibility service; use viewing only when the documented permission cannot be granted normally.

Is Screen Capture enough for remote taps?

No. Screen Capture permits sharing, while input needs its separate supported authorization. Confirm both on a harmless screen rather than inferring control from a visible image.

Must I share a RustDesk password with the helper?

No. This attended workflow uses click-only approval and a local acceptance for each request, without sending temporary passwords or configuring permanent access credentials.

Does disabling Input Control end an existing session?

Do not assume so. Official documentation says most permission toggles apply to new connections; close the established session before changing input authorization.

What if Android blocks the accessibility permission?

Keep the session view-only, or stop assistance if viewing is unsuitable. Do not bypass restricted settings, organizational policy, or protected screens to obtain control.

Does closing the Windows window finish cleanup?

It is only one part. The phone owner should end the connection, stop sharing, revoke temporary permissions, and check that another request cannot regain access.

Should I change relay servers when input fails?

Not merely because taps fail on a visible screen. Check phone-side input authorization first; ID and relay troubleshooting belongs to connection-establishment failures.

Disclaimer: The device combination is a documentation scope, not a completed test. Assist only with informed consent and stop when identity, permission, or termination cannot be verified.

Sources:

RustDesk Android — https://rustdesk.com/docs/en/client/android/
RustDesk 1.5.0 — https://github.com/rustdesk/rustdesk/releases/tag/1.5.0
Google Get Apps on Your Android Device — https://support.google.com/android/answer/9457058
RustDesk Advanced Settings — https://rustdesk.com/docs/en/self-host/client-configuration/advanced-settings/
Google Android Accessibility Overview — https://support.google.com/accessibility/android/answer/6006564
Google Fix an Installed Android App That Isn't Working — https://support.google.com/android/answer/2668665

Sources checked 11 October 2026.

Related Articles:

RustDesk Android Control: Consent, Permissions, and Stop