Come risolvere l'errore adb non riconosciuto in Windows

ADB non riconosciuto in Windows: il problema quasi sempre è nel percorso, non nel telefono

Quando Windows risponde con “adb non è riconosciuto come comando interno o esterno”, il punto non è quasi mai Android in sé. Nella maggior parte dei casi il sistema non trova l’eseguibile adb.exe, oppure lo trova ma da una cartella diversa da quella che stai usando nel terminale. Il telefono può essere perfettamente collegato, il cavo può funzionare, il debug USB può essere attivo: se il comando non è nel percorso giusto, il prompt non lo vede.

Vale la pena partire da una distinzione pratica: ADB non funziona non significa automaticamente che il bridge sia rotto. Può voler dire che adb.exe non è installato, che la variabile d’ambiente PATH non include la cartella corretta, che stai lanciando il comando da una directory sbagliata, oppure che Windows ha un conflitto con più copie di ADB installate in punti diversi. Il fix giusto dipende da quale di questi scenari stai vedendo.

Prima verifica: il comando esiste davvero?

La prima cosa da fare è semplice: capire se adb.exe è presente sul disco e se il terminale lo può risolvere. Apri Prompt dei comandi o PowerShell e prova questi controlli.

where adb

Se tutto è a posto, Windows restituisce il percorso completo, per esempio qualcosa come C:\\Android\platform-tools\adb.exe. Se invece compare un messaggio del tipo INFO: Could not find files for the given pattern, il comando non è nel PATH oppure non è installato. Questo è già un indizio forte: il problema è lato sistema, non lato dispositivo.

Se hai installato Android Studio, il file di solito si trova dentro la cartella platform-tools. La posizione tipica è una di queste:

• C:\Users\<utente>\AppData\Local\Android\Sdk\platform-tools\adb.exe
• C:\Android\platform-tools\adb.exe
• D:\Android\Sdk\platform-tools\adb.exe

Se non sai dov’è, non indovinare: cerca il file direttamente da Esplora file o usa la ricerca di Windows su adb.exe. Se non lo trovi da nessuna parte, devi installare i Platform Tools.

La causa più comune: platform-tools non installato o PATH incompleto

ADB fa parte dei Android SDK Platform Tools, non del solo driver USB. Questa distinzione crea confusione perché molti installano il driver del produttore o i driver Google, ma poi si accorgono che il comando da terminale continua a non esistere. Il driver serve a Windows per vedere il dispositivo; adb.exe serve a te per inviare i comandi.

Se hai Android Studio, puoi verificare l’installazione da SDK Manager:

1. Apri Android Studio.
2. Vai su Tools → SDK Manager.
3. Nel tab SDK Tools controlla Android SDK Platform-Tools.
4. Se non è spuntato, installalo.

Se non usi Android Studio, puoi scaricare il pacchetto ufficiale dei Platform Tools dal sito Android e scompattarlo in una cartella stabile, senza spostarlo ogni due giorni. Una volta fatto, hai due strade: eseguire adb.exe da quella cartella oppure aggiungerla al PATH.

Fix corretto: aggiungere ADB al PATH di Windows

La soluzione più pulita è mettere la cartella platform-tools nel PATH. Così adb funziona da qualsiasi finestra di terminale, senza dover ogni volta entrare nella directory giusta. È il classico intervento piccolo che evita errori ripetuti.

Procedura da interfaccia grafica:

1. Apri Impostazioni di sistema avanzate.
2. Clicca su Variabili d’ambiente.
3. Nel riquadro Variabili utente o Variabili di sistema, seleziona Path e scegli Modifica.
4. Aggiungi la cartella che contiene adb.exe, non il file singolo.
5. Conferma con OK fino alla chiusura di tutte le finestre.

Per esempio, se il file è in C:\Android\platform-tools\adb.exe, nel PATH devi inserire C:\Android\platform-tools. Non adb.exe, non la cartella padre generica, non un collegamento. Il punto deve essere la directory che contiene l’eseguibile.

Dopo la modifica, chiudi e riapri il terminale. Questo passaggio viene saltato spesso e poi si pensa che il PATH non abbia funzionato. In realtà il vecchio processo non ha ricaricato le variabili d’ambiente.

where adb
adb version

Se il PATH è corretto, il primo comando deve mostrare il percorso completo e il secondo deve restituire la versione del tool, ad esempio una riga con Android Debug Bridge version. Se where adb trova più percorsi, hai più installazioni in giro: non è sempre un errore, ma è un campanello d’allarme perché potresti usare una versione diversa da quella che pensi.

Quando il PATH c’è ma ADB continua a non partire

Se where adb restituisce un percorso valido ma il comando fallisce comunque, il problema si sposta su altri due livelli: conflitto tra versioni oppure avvio da shell che non eredita correttamente il PATH. Qui conviene fare una verifica molto concreta.

Prova a eseguire ADB con percorso assoluto:

"C:\Android\platform-tools\adb.exe" version

Se così funziona, il binario è sano e il problema resta nella risoluzione del comando. Se invece ricevi un errore diverso, per esempio relativo a librerie mancanti o permessi, allora non sei più nel caso “comando non riconosciuto”, ma in un problema di esecuzione del file.

Con più installazioni di ADB capita spesso questo scenario: Android Studio, un SDK vecchio, un pacchetto estratto a mano e magari un tool di terze parti mettono tutti una copia di adb.exe in giro. In quel caso controlla l’ordine del PATH con:

echo %PATH%

La copia che compare prima nel PATH è quella che Windows usa per prima. Se quella versione è vecchia o corrotta, puoi avere comportamenti incoerenti. Il rimedio è semplice: tieni una sola cartella platform-tools aggiornata e rimuovi i duplicati dal PATH.

Il telefono è visibile ma ADB non elenca dispositivi

C’è un secondo errore molto comune che viene confuso con “ADB non riconosciuto”: il comando parte, ma adb devices non mostra nulla oppure il dispositivo appare come unauthorized. Qui il problema non è più il PATH, ma l’autorizzazione del telefono o il driver USB.

Verifica in sequenza:

1. Nel telefono, Opzioni sviluppatore → Debug USB attivo.
2. Collega il cavo e sblocca lo schermo.
3. Controlla se compare il popup di autorizzazione RSA sul dispositivo.
4. Se il device è in stato unauthorized, revoca le autorizzazioni di debug USB e riconnetti.

Controlla anche il driver da Gestione dispositivi. Se il telefono appare con un triangolo giallo o come dispositivo sconosciuto, Windows non sta caricando il driver giusto. In quel caso il comando esiste, ma il bridge non riesce a parlare con il device.

adb devices

L’output atteso, quando tutto funziona, è una riga con il seriale del dispositivo e lo stato device. Se vedi unauthorized, il nodo da chiudere è l’autorizzazione sul telefono; se non vedi nulla, il focus passa al driver o al cavo.

Controllo rapido del cavo, della porta e della modalità USB

Non serve complicarsi la vita: un cavo solo carica ma non trasporta dati, una porta USB frontale può dare problemi, oppure il telefono può essere collegato in modalità solo ricarica. Prima di inseguire configurazioni strane, fai il test più banale.

Collega il dispositivo a una porta diversa, usa un cavo dati noto e controlla la notifica USB sul telefono. Se disponibile, imposta la modalità su Trasferimento file o comunque su una modalità dati. Questo non risolve un PATH rotto, ma elimina un falso positivo quando il comando è corretto e il device no.

Quando conviene reinstallare i Platform Tools

Se la cartella esiste, il PATH è giusto, ma il comportamento resta incoerente, la strada più pulita è reinstallare i Platform Tools in una directory nuova e pulita. È meglio di una modifica a tentativi su una cartella vecchia che magari contiene file parziali o versioni miste.

Approccio pratico:

1. Scarica i Platform Tools ufficiali.
2. Estrai tutto in una cartella stabile, per esempio C:\Android\platform-tools.
3. Rimuovi eventuali vecchie cartelle ADB dal PATH.
4. Aggiungi solo la cartella nuova al PATH.
5. Riapri il terminale e verifica con where adb e adb version.

Questa pulizia riduce anche il rischio di usare una versione troppo vecchia rispetto agli strumenti Android installati sul sistema. Con ADB, la coerenza della versione conta più di quanto sembri quando inizi a lavorare con più dispositivi o con versioni recenti di Android.

Fix minimo consigliato, senza andare a tentoni

Se vuoi una sequenza secca, questa è quella giusta:

1. Controlla se adb.exe esiste con where adb.
2. Se non esiste, installa i Platform Tools.
3. Se esiste ma non parte, prova il percorso assoluto.
4. Aggiungi la cartella corretta al PATH.
5. Riapri il terminale e verifica con adb version.
6. Se il comando funziona ma il device no, passa a driver, cavo e autorizzazione USB.

In altre parole: prima fai tornare il comando, poi fai parlare il telefono. È l’ordine corretto per non confondere un problema di sistema con un problema di collegamento.

Controlli finali e prevenzione

Quando hai risolto, conviene chiudere con due controlli rapidi. Il primo è la presenza del comando:

where adb
adb version

Il secondo è la visibilità del dispositivo:

adb devices

Se entrambi rispondono come previsto, il problema è chiuso. Per evitare di ritrovarlo tra qualche settimana, tieni una sola installazione di Platform Tools aggiornata, non spostare la cartella dopo averla messa nel PATH e verifica sempre che il terminale sia stato riaperto dopo ogni modifica alle variabili d’ambiente.

Assunzione operativa: qui si parte dal caso più comune, cioè ADB installato male o non presente nel PATH; se il comando esiste ma il dispositivo resta invisibile, il focus va su driver, autorizzazioni USB e stato del telefono.