Name the exact phone and the exact Windows host
Before touching a single setting, write down which Android device and which Windows computer you intend to use. Record the phone model, the Android version shown in Settings, and the Windows edition and version. This matters because a workflow that fails on one machine may simply be a different host than the one you configured earlier, and mixing two phones or two cables makes every later check ambiguous.
Keep that record next to the test plan. If a colleague hands you a device, confirm the serial or a unique label rather than trusting a similar-looking model. When you later see a device appear in a tool, you can compare it against your written record instead of guessing. This single habit prevents most confusion about whether a permission problem is real or just a mismatch between the phone in your hand and the phone the computer is talking to.
Verify developer options and USB debugging safely
Open Settings, find the About phone section, and locate the build number. Tapping it repeatedly is the standard way to reveal developer options, but the exact number of taps and menu names vary by manufacturer, so follow the on-screen prompts rather than a fixed count. Once developer options appear, open them and confirm the USB debugging toggle is on. If the toggle is greyed out or missing, stop and check whether a device management profile or work account restricts it.
When you connect the cable, the phone should show a prompt asking whether to allow USB debugging from this computer. Read the fingerprint shown on the phone and compare it with what the Windows tool reports if it displays one. Choose to allow only if you recognize the computer. Avoid selecting always-allow on a shared or unfamiliar machine. If no prompt appears, unplug and replug the cable, then check the notification shade for a USB mode selector and set it to file transfer or the mode your tool expects.
Separate a physical USB link from an authorized control session
A cable that charges the phone is not proof that a debugging session is authorized. Windows may show the device in Device Manager while the Android debugging bridge still reports it as unauthorized. Treat these as two different states: physical connection, and permission to run commands. Check each one separately so you know which layer is failing.
On Windows, open a terminal and list connected devices with the Android debugging bridge if it is installed. An entry marked unauthorized means the phone has not accepted the computer yet, so look at the phone screen for the prompt. An entry marked offline usually points to a stale connection or a cable or port problem. An empty list means the host does not see the device at all, which is a driver, cable, or USB mode issue rather than a permission issue. Record which of these three states you observe before changing anything.
Stop repeating commands while the state is unknown
When a command fails, the instinct is to run it again immediately. Resist that. Repeated attempts while the connection state is unclear can produce misleading errors, trigger additional authorization prompts, or leave a half-open session that confuses the next check. Instead, pause and re-read the last output. Note the exact wording, then decide whether the problem is physical, permission-related, or a targeting mistake.
A simple rule helps: one observation, one change, one recheck. If you toggle a setting or swap a cable, confirm the new state before issuing another command. Keep a short log of what you changed and what the tool reported afterward. This log turns a frustrating loop into a sequence you can reason about, and it makes it far easier to explain the situation to someone else if you need help.
Document a safe manual recovery and recheck
If authorization is stuck, a safe recovery starts with the phone, not with repeated host commands. Disconnect the cable, revoke USB debugging authorizations in developer options, then reconnect and watch for a fresh prompt. Approve it deliberately. On the Windows side, confirm the device appears and is marked as authorized before running anything else. If the device still does not appear, try a different cable and a direct rear port rather than a hub.
After recovery, recheck the same three states you recorded earlier: physical visibility, authorization status, and correct device targeting when more than one device is attached. Write the final state in your log with the date. If the problem returns, compare the new log against the old one to spot what changed. This disciplined recheck keeps the workflow predictable and avoids assuming a fix worked before you have confirmed it.