Android Studio installs platform-tools automatically the first time a project builds against it, but a fresh install, a moved SDK folder, or a corrupted SDK Manager cache can leave the folder empty even though the SDK Manager's checklist shows it as installed. The symptom is confusing: adb commands fail with "not found" even though Android Studio itself opens and builds projects normally.
platform-tools subfolder exists and actually contains an adb or adb.exe binary, not just an empty directory.A surprisingly common cause: the SDK path shown in Android Studio does not match the path a terminal's ANDROID_HOME or ANDROID_SDK_ROOT environment variable points to, because the SDK was reinstalled at a new location at some point and the old environment variable was never updated. Both locations can appear to "have" an SDK while only one actually contains a working platform-tools folder.
This forces Android Studio to redownload the package rather than trusting a local manifest that may be out of sync with what is actually on disk — the actual root cause in most "installed but missing" reports.
When the graphical SDK Manager itself is unresponsive or stuck, the bundled command-line tool bypasses it entirely:
sdkmanager "platform-tools"This binary lives under cmdline-tools/latest/bin/ inside the SDK folder. If it is not on the PATH, run it with the full path instead, or cd into that folder first. A successful run prints a license acceptance prompt on first use for that SDK installation.
On a CI machine or a fresh install where licenses were never interactively accepted, package installation can fail silently or be skipped without an obvious error in the Android Studio UI. Accept all pending licenses explicitly:
sdkmanager --licensesThis prompts yes/no for each outstanding license in turn; accepting all of them before retrying the platform-tools install resolves failures that otherwise look like a network or permissions problem.
On a machine where the SDK folder lives under a system-wide path (common on shared lab computers or a corporate-imaged Windows machine), Android Studio may lack write permission to actually create the platform-tools subfolder, even though it reports the package as selected for install. Moving the SDK location to a folder fully owned by the current user account, then repointing Android Studio's SDK Location setting to the new path, avoids this permissions conflict entirely.
Once platform-tools genuinely exists with a working adb binary inside it, add that exact folder to the system PATH so adb and fastboot work from any terminal, not only from within Android Studio's own embedded terminal window, which sometimes uses a different environment than a regular shell.
Some third-party antivirus products flag adb.exe heuristically, since command-line tools capable of installing arbitrary APKs and reading device data resemble the behavior pattern of certain malware families closely enough to trigger a generic heuristic match. If platform-tools installs successfully through the SDK Manager but adb.exe disappears from the folder shortly after, check the antivirus quarantine log before assuming the SDK Manager itself is broken; adding an exclusion for the platform-tools folder resolves this without needing to disable protection entirely.
On a corporate machine behind a restrictive proxy, the SDK Manager's download can fail silently or time out without a clear error dialog, particularly if the proxy requires authentication that Android Studio's built-in HTTP proxy settings were never configured to supply. Setting the proxy explicitly under Settings > Appearance & Behavior > System Settings > HTTP Proxy resolves this in most managed corporate environments where the default "No proxy" setting silently fails against a locked-down network.