← Screen2Screen home
CONSENT AND USER CONTROL

Support should be
clear on both sides.

Remote support should never leave a person guessing about who is connected or when their screen is visible. Screen2Screen makes the user part of the connection.

Read the Android user guide See the privacy policy for full data-handling details.
Stop if you do not recognize the technician

Start a session only when you requested help and trust the person connecting. Never share passwords, one-time security codes, banking details, or payment information during a support session.

01 BEFORE A SESSION

A request is not the same as sharing

A user can request help, or accept an invitation sent to an opted-in Always On device. Neither action alone exposes the screen. The user reviews the technician and approves Android’s screen-sharing prompt before the technician can view the screen.

Always On uses periodic check-ins and invitations. It does not silently capture the screen or override Android’s consent controls.

02 DURING A SESSION

The Android user chooses the access

  • ✓
    Screen, pointer, and touch

    View Only shares the approved screen. Pointer control adds visual guidance with Draw over other apps permission. Touch control uses the enabled Accessibility service for gestures, navigation, and text entry during the active session. Sent text replaces the focused field; the touch service does not read its existing text.

  • ✓
    One technician viewer

    The current assigned technician can see the approved session. An explicit newer authorized join takes over and disconnects the previous technician window; signing in to another browser alone does not automatically attach it to the device.

  • ✓
    Device and app details

    Technicians see reported device health, software versions, connection details, permission status, and launchable user-installed apps. Readings can be unavailable or limited by Android. Device information and screen video have separate freshness states.

  • ✓
    User-reviewed requests

    Open, Install, and Uninstall requests require the user’s review; app removal also needs Android confirmation. Wi-Fi requests require Android approval to save a network. Notifications depend on the phone’s notification permission.

  • ✓
    Stop sharing

    The Android user can stop in Screen2Screen or through Android’s screen-sharing controls. Either participant can end the session. Pending file-access, Wi-Fi, and app-request prompts and notifications are cleared through session cleanup.

Prepare before sharing: close private messages, account details, and other sensitive information you do not want visible.
03 FILE AND NETWORK PERMISSIONS

Choose the folder the technician can access

Remote file browsing begins only when a technician requests it during an approved session and the Android user has authorized a folder. The user can choose the folder on demand or pre-authorize it in Settings. That choice includes its subfolders and is remembered per account on that device across organizations. Change the folder or turn access off in Remote file access.

Uploads and downloads are limited to 20 MB per file. Existing files are not overwritten. Private app and system storage remains protected by Android. Once a file is saved or downloaded, revoking access cannot recall that copy.

Wi-Fi configuration sends the technician-entered network settings for the user to review. The password is used for that request and Android’s save dialog; it is not placed in notifications, session history, or diagnostic logs. Pending requests expire. A save can switch networks and temporarily interrupt support.

04 ORGANIZATION AND ACCOUNT ACCESS

Manage roles, authenticator requirements, and timeouts

Each organization manages its own owners, admins, technicians, and Android users. A technician invitation does not grant administration access, and membership in multiple organizations does not merge their people lists.

Enroll an authenticator voluntarily in Tech Settings, Admin Security, or Android Settings. Organizations can require MFA separately for administrators/owners, technicians, and Android users. Once enrolled, the factor applies to the same Screen2Screen account across its organizations and Google and email/password sign-ins.

Use your authenticator app’s sync or transfer feature for another phone, or remove the existing factor before enrolling a replacement. Existing setup keys cannot be displayed again. An authorized admin can reset another member’s MFA after verifying their identity; the reset affects that account across organizations. Locked-out admins should contact another authorized administrator or Screen2Screen support.

Organizations can set separate Admin and Tech inactivity timeouts. Inactivity can sign the person out and end an active technician session. Members should still sign out deliberately on shared computers.

05 SESSION AND ADMINISTRATION RECORDS

Use history for follow-up

Session records include IDs, participants, times, and statuses. Admin history records supported organization changes, including membership and MFA resets. History views offer paging and exports of loaded records; these are not screen recordings.

Connection history is typically purged after 365 days. A product support request includes the signed-in email, role, organization name, Organization ID, and submitted issue. Do not include secrets in the issue text. Read the Privacy Policy for data-handling and retention details.

06 SAFE SUPPORT PRACTICES

Keep support recognizable and specific

  • Use a help channel you trust and check the technician and organization before approving.
  • Choose a dedicated support folder rather than sharing unrelated documents.
  • Review app and Wi-Fi requests before accepting them.
  • Never reveal passwords, authenticator codes, payment details, or recovery phrases.
  • Close sensitive screens before sharing and end the session when support is complete.
See the Android approval and settings flow.Open the Android user guide →