Prefer USB for the live critical path​

If the room has questionable Wi-Fi, USB is the cheapest insurance policy. Run dry rehearsal on the exact cable and port you will use; front-panel ports and long passive extensions are frequent culprits when “it worked at my desk.”

When wireless is unavoidable, read Wireless debugging pitfalls before you bet the roadmap review on hotel conference Wi-Fi.

Windowing and readability​

On a projector, UI density beats raw pixel count. Use Window settings (where available) to keep chrome predictable, and consider slightly lower resolution with crisp scaling over native res that the room cannot resolve anyway.

If you present from a laptop mirrored to HDMI, remember macOS/Windows display scaling affects how large the NearMirror window feels to viewers—test full stack, not just the phone.

Video tuning for motion​

Fast scrolling demos need stable frame pacing. If you see micro-stutters, drop bitrate a notch before you chase exotic OS flags—see Video Settings and Tuning quality and latency.

Have a backup story​

Live demos fail for boring reasons: sleep, low battery, OS update prompts. Keep a 15-second screen recording clip as offline fallback if network mirroring dies mid-slide—but ask policy before recording sensitive screens.

Stakeholders remember smooth more than 4K. Optimize for their eyes and your nerves, not benchmark bragging rights.

Same Wi-Fi really means same L2 domain​

Phone and PC must see each other at LAN scope. Guest Wi-Fi, captive portals, and client isolation (APs that forbid Wi-Fi-to-Wi-Fi traffic) all look “online” from a browser test yet block ADB pairing traffic.

If pairing fails instantly at the office, try USB once to prove the device is healthy, then ask IT whether peer-to-peer Wi-Fi is blocked on your VLAN.

IP churn and sleep​

DHCP leases can change addresses. Some OEMs aggressively sleep wireless debugging when the screen is off. For long sessions, keep the device plugged in, disable overly strict battery savers for your mirroring session if your OEM allows it, and reconnect after router reboots.

VPNs and split tunnels​

A full-tunnel VPN on the desktop can hairpin what “local network” means. If wireless debugging targets a RFC1918 address on your LAN, but the VPN sends all traffic elsewhere, pairing packets never arrive. Split-tunnel or pause VPN only if your security policy allows it for lab networks.

Pairing codes and fat fingers​

Android shows a pairing port and six-digit code for a limited time. Typos, stale dialogs, and trying to reuse yesterday’s port are common. When in doubt: forget pairing, regenerate in Developer options, and enter the fresh values once—rarely does hammering the old port help.

Step-by-step device setup lives in Getting Started; connection patterns are covered in Connecting Devices. For the bigger picture on USB versus Wi-Fi tradeoffs, read USB vs wireless ADB.

Wireless debugging is a sharp tool—respect your network topology and it stays boringly reliable.

When live mirroring is enough​

• Interactive debugging: stepping through UI, reproducing taps, watching Logcat while you drive the app.
• Pair programming where a partner watches in real time and does not need a file artifact.

Keep Video tuned for responsiveness over cinematic bitrate if nobody will archive the session.

When recording pays off​

• Bug reports where stakeholders want a timestamped clip with audio.
• Compliance or training where a durable artifact must exist after the session.
• Flaky repros that only appear once every dozen attempts—rolling capture beats human reflexes.

NearMirror’s recording options are documented under Recording. Plan disk space on the desktop: high-resolution, long captures add up fast on laptops with small SSDs.

Audio and privacy​

Recording device audio alongside video is powerful for game or media bugs, but remember consent norms for calls or meetings in your jurisdiction and company policy. When in doubt, record silent repros or use a test account without real customer data.

Why “local” matters​

When mirroring uses local USB or LAN paths, your data stays inside the environment you control: your desk, your router, your cables. That is different from remote-support tools that intentionally route video through vendor servers.

What still leaves the device​

Anything you choose to upload—cloud drives, email attachments, chat uploads—behaves the same as without mirroring. Mirroring does not replace normal caution about what apps send outbound.

Permissions and trust​

ADB-level access is powerful. Only authorize debugging on machines you trust, and turn USB debugging off on phones you lend out if you are not comfortable with that trust boundary.

Logs and diagnostics​

If you open a Logcat window while debugging an app, you are looking at system and app logs—not a replacement for a privacy policy, but a reminder that verbose logging can include package names, URLs, or tokens if apps log poorly. Treat shared logs like shared crash dumps. NearMirror’s Logcat doc explains how the viewer fits into the app; scrub before you paste into public tickets.

A plain-language threat model​

Local mirroring means pixels and audio are not intentionally routed through a vendor’s screen-recording cloud. It does not mean your laptop is magically safe:

• A stolen or unlocked desktop can read whatever is on disk—including recordings you made while mirroring.
• Malware on the PC has the same power as malware always had: keyloggers, clipboard sniffers, and screen capture.
• Shoulder surfing still works; mirroring can make a 27-inch monitor easier to read from across a room.

ADB trust is bilateral: the phone trusts this debugging host, and you should only grant that on machines you administer.

What mirroring does not change​

• Clipboard and drag-and-drop paths follow normal OS rules—sensitive tokens in the clipboard are still sensitive.
• Apps that phone home keep doing so; mirroring is not a network firewall for your phone’s outbound traffic.
• Backups and sync (photos, chat history) behave as configured regardless of mirroring.

“Device unauthorized” or no RSA prompt​

Unplug and replug, revoke old keys if you have been swapping machines: Developer options → Revoke USB debugging authorizations, then reconnect and accept the prompt on the phone while it is unlocked.

Device never appears in the desktop app​

1. Confirm USB debugging is on—see Developer Options.
2. Try another cable (data-capable, ideally OEM).
3. Try another USB port; some front-panel ports are underpowered or flaky.

Wireless: “offline” or endless pairing​

Double-check same Wi‑Fi as the PC, correct pairing port/code for wireless debugging, and that the phone is not switching networks due to weak signal. Firewalls on corporate VLANs sometimes block ADB ports between Wi‑Fi clients; USB is the quickest isolation test.

adb devices shows nothing (if you use CLI)​

Install or repair USB drivers on Windows; on macOS/Linux, rule out bad cables first. On Linux, udev rules for your vendor ID may be required for non-root access.

NearMirror’s Getting Started path is designed so you do not need the CLI, but the same physical and authorization issues apply to every mirroring stack built on ADB.

device offline or flaky state changes​

offline usually means the host can see the gadget layer but adbd is not conversing cleanly—bad cable/port, USB hub in the path, or the device dropped authorization mid-session. Remove hubs temporarily, try another port, unlock the phone, and watch for the authorize prompt. If you toggled File transfer / MTP recently, reconnect once; some stacks are picky until the USB mode settles.

USB mode (MTP, PTP, “charge only”)​

Android’s USB notification can silently land on charge only after an update. Pick File transfer / Android Auto or the mode your OEM labels for data—exact names vary—then replug. This is not “magic,” but it eliminates a boring class of “worked yesterday” reports.

Windows: OEM and Google drivers​

Generic Windows drivers cover many phones, but not all. If the device never enumerates, install the OEM USB driver package for Samsung, Google, Xiaomi, etc., or the Google USB Driver for Pixel-class devices. Device Manager “unknown device” entries are your hint before you blame mirroring software.

Linux: udev rule pattern​

Non-root adb needs permission on the USB node. Rules are vendor-specific; you will see an 18d1 (Google) style id or your phone vendor’s USB id in lsusb. A typical pattern (replace 0xXXXX with your vendor id from lsusb -v) looks like:

SUBSYSTEM=="usb", ATTR{idVendor}=="XXXX", MODE="0666", GROUP="plugdev"

Reload rules and replug. Distro docs differ slightly (udevadm control --reload-rules && udevadm trigger).

Corporate Wi‑Fi and VLANs​

Even when the phone and laptop are “on Wi‑Fi,” client isolation or inter-VLAN firewall rules can block the TCP ports wireless debugging uses. If USB works instantly but wireless never completes pairing, grab IT with “peer-to-peer blocked on SSID X” language—or use USB on that network.

For device-specific flows, keep Connecting Devices open next to this checklist.

Video side​

Higher resolution and bitrate look sharper but cost more bandwidth—especially over Wi‑Fi—and can increase decode and render time on the desktop. If motion feels mushy or input lags behind the cursor, try stepping down one notch and compare.

NearMirror exposes these controls in the docs under Video Settings. Use them when you change networks or when you switch from a flagship phone to a mid-range device.

Network side (wireless)​

• Prefer 5 GHz Wi‑Fi when available; 2.4 GHz is more crowded.
• Avoid VPN tunnels on the same machine if they force traffic through remote exits you do not need for local mirroring.
• Reduce other heavy LAN use (large LAN backups, etc.) during sensitive demos.

Device side​

Thermal throttling and background sync can steal frames. For important sessions, close heavy games temporarily, pause large uploads, and keep the phone cool—metal desks and direct sunlight heat phones faster than people expect.

Latency is never “zero,” but a stable, slightly lower bitrate stream usually feels faster than a maxed-out setting that stutters.

Bitrate vs resolution (plain language)​

Resolution is how many pixels each frame contains. Bitrate is how much data per second you allow the encoder to spend describing motion and detail. Raising both at once on a weak link is the most common recipe for hitching: the encoder or the network cannot keep up, so frames arrive late and the desktop has nothing new to draw.

If picture looks blocky but motion is smooth, you are often bitrate-starved—try a modest bump in bitrate before jumping resolution. If motion stutters, try lowering one step in resolution or bitrate first, not both at once, so you can see which knob mattered.

Ordered checklist when something feels “off”​

1. Network path (wireless): same SSID/subnet, 5 GHz if you can, move closer to the AP, pause huge LAN transfers.
2. Cable path (USB): swap cable/port; charge-only cables masquerade as “fine” until video starts.
3. Video settings: open Video Settings and reduce one notch; re-test before chasing exotic OS tweaks.
4. Phone load: close heavy background apps; let the device cool if it has been thermal-throttling.
5. Desktop load: other GPU-heavy apps can contend; a quick comparison with browsers/games paused is a fair test.

If it is stuttering, try this first​

• Wireless: drop bitrate one step or switch band/AP; do not immediately blame the mirroring app.
• USB: verify a data cable and a rear motherboard port on towers before touching software sliders.

Small, reversible changes beat random max settings—and they make support or bug reports easier because you can say exactly which knob helped.

When USB wins​

• Stability: USB avoids Wi‑Fi contention, neighbor networks, and flaky access points.
• Lower jitter: For typing, UI testing, or demos where micro-stutters are distracting, a good data cable often feels tighter than marginal Wi‑Fi.
• First-time setup: Many workflows still expect an initial wired path before wireless pairing is available.

Use a data cable—charge-only leads are a classic source of “device never appears.”

When wireless wins​

• Mobility: You can leave the phone on a stand across the room.
• Fewer cable swaps: Great if you mirror several devices through the day.
• Cleaner desk: No dongle spaghetti if your machine has limited ports.

Wireless debugging (Android 11+) or LAN-based pairing both ultimately run ADB over TCP. That means same subnet and solid Wi‑Fi matter more than raw ISP speed.

Practical rule of thumb​

Start on USB until everything is authorized and stable, then try wireless if you want freedom of movement. If wireless feels laggy, move closer to the access point or fall back to USB for sessions where responsiveness is critical.

At-a-glance: USB vs Wi‑Fi​

Android 11+ wireless debugging vs classic adb tcpip​

Wireless debugging in Developer options (Android 11 and later) gives you a pairing workflow and a port scoped to debugging—what most users should use today. Older USB-then-adb tcpip style workflows still float around in forum posts; they can work, but they assume you already had a working USB session and understood which IP/port to target. If you are new to mirroring, prefer the built-in wireless debugging UI and keep phone and PC on the same subnet.

Guest Wi‑Fi and AP isolation​

Many routers offer a guest SSID that blocks devices from seeing each other. That is great for untrusted visitors and terrible for wireless ADB: your PC and phone may both be “online” yet unable to open the debugging port. Use your main LAN (or a trusted lab VLAN that allows peer discovery) for wireless mirroring.

Tiny decision tree​

• Automating UI tests all afternoon? Prefer USB—or rock-solid 5 GHz with few neighbors.
• Watching a build on the couch? Wireless is fine if stutters do not matter.
• Office Wi‑Fi mystery failures? USB proves whether the phone and app are healthy before you fight IT policies.

See Connecting Devices for NearMirror-specific steps.

ADB in one sentence​

ADB is a small client–server protocol that lets a trusted computer talk to an Android device over USB or TCP (for example, wireless debugging on the same LAN). It was built for developers: install apps, run shells, forward ports, capture logs, and stream screen data when the right APIs are used.

Why mirroring uses it​

Screen mirroring is not a single “HDMI over Wi‑Fi” standard on every phone. Apps that mirror without root typically use debugging-oriented capture and control paths that are exposed when USB debugging is enabled and the desktop is authorized. That is the same trust model ADB uses.

What you should remember​

• USB debugging is the gate: without it, the desktop cannot establish the channel most mirroring stacks expect.
• Authorization matters: when Android shows “Allow USB debugging?”, you are pairing trust between that PC and the device.
• Wireless ADB (Android 11+) reuses the same idea over TCP after pairing—handy when cables are awkward, but your network quality still affects latency.

Host vs device: who runs what​

On the device, Android runs adbd, the ADB daemon. On the host (your Mac, PC, or Linux box), a client speaks the ADB wire protocol over USB or a TCP socket. When you authorize USB debugging, you are explicitly allowing that host’s key to talk to adbd. Mirroring tools use that same trusted channel; they are not bypassing the OS—they are using developer-facing plumbing you have turned on.

“ADB for shell” vs “ADB as transport”​

Many tutorials show adb shell or adb install. That is the interactive developer face of ADB. Mirroring stacks use ADB (or the same class of privileged connection) as a transport and control plane: start sessions, forward sockets, and coordinate capture—not something you need to type by hand. When docs say “ADB must be working,” they usually mean “the device shows up as authorized and stable,” not “you should live in a terminal.”

When the CLI is still useful​

You do not need the command line for NearMirror’s happy path. It can still help for narrowing failures:

• Does the device appear in adb devices at all? If not, you likely have cable, port, driver, or authorization issues—not an app-level bug.
• Does the state flip between device and unauthorized? That is almost always the RSA prompt or revoked keys.

If you have never enabled debugging before, follow Enabling Developer Options & USB Debugging first; guessing at adb flags without that foundation rarely saves time.

Quick glossary​

If you are setting up NearMirror for the first time, start with Installation and Getting Started; the concepts above are exactly what those guides walk you through.