Fastboot non rileva il dispositivo: controlli su cavo, driver, USB e modalità

Un output vuoto di fastboot devices ha sei possibili cause e solo una è il driver. Tra il tuo comando e il telefono ci sono la modalità in cui ti trovi, il cavo, la porta, la versione di platform-tools, il modo in cui il sistema operativo del computer associa il dispositivo e il driver. Isolali in ordine e trovi la causa vera in circa dieci minuti.

Parti dalla modalità in cui ti trovi davvero

È il controllo che molti saltano, e saltarlo produce gli errori più difficili da interpretare.

Il fastboot del bootloader e fastbootd sono ambienti diversi. La documentazione dell'Android Open Source Project descrive fastbootd come un daemon e una modalità in userspace, introdotti quando l'implementazione di fastboot è passata dal bootloader allo userspace per supportare le partizioni ridimensionabili da Android 10 in poi. Entrambi mostrano “fastboot” sullo schermo. Entrambi usano lo stesso strumento fastboot dal computer. Gestiscono partizioni diverse e possono comportarsi in modo diverso sulla stessa macchina.

Sui dispositivi supportati, chiedi al dispositivo quale dei due è:

fastboot getvar is-userspace

Il risultato yes significa che sei in fastbootd. Il risultato no indica il fastboot del bootloader. Se non ottieni nessuna risposta, hai un problema di connessione e vale il resto dell'articolo.

La modalità Download di Samsung non è fastboot. I dispositivi Samsung di solito usano un'interfaccia di flashing separata, con un protocollo e strumenti propri. fastboot devices non trova un dispositivo Samsung in modalità Download, ed è un comportamento previsto, non un guasto. Se il dispositivo mostra la schermata Download, fastboot non è lo strumento giusto e nessun lavoro sui driver cambierà la situazione.

Nemmeno la recovery è fastboot. Un dispositivo in recovery risponde a adb devices, non a fastboot devices. Se vedi il menu della recovery, usa ADB. In Android si riavvia sempre in recovery trovi cosa significa quello stato.

La scala di isolamento

Procedi dall'alto in basso. Ogni gradino elimina un livello e ha un test specifico, così non vai a tentativi.

Il gradino 4 è quello che decide tutto. Un dispositivo che viene rilevato su USB ma non compare in fastboot devices ha un problema lato computer che puoi risolvere. Un dispositivo che non viene rilevato affatto è un altro caso e forse non è un problema software. Non saltarlo.

Cavo

Un cavo USB che carica non è per forza un cavo che trasmette dati. Esistono cavi solo ricarica e producono esattamente il sintomo che stai cercando di risolvere, senza messaggi di errore e senza indicare la causa.

Il test è pratico, non visivo: guardando non si capisce. Usa un cavo con cui hai trasferito file di persona, da qualsiasi dispositivo, su quel computer. Se non ne hai uno di cui puoi garantire il funzionamento, è la prima cosa da sistemare, perché con un cavo difettoso ogni gradino successivo dà risultati inaffidabili.

I cavi inoltre si deteriorano. Uno che funzionava l'anno scorso può avere un conduttore rotto, e il guasto spesso è intermittente, quindi sembra un problema del telefono.

Altre due note sul cavo: quello fornito col telefono è un buon punto di partenza, se ce l'hai ancora, e la lunghezza conta, perché un cavo lungo o sottile può essere al limite per i dati anche se carica bene.

Porta e hub

Hub USB, porte dei monitor, passthrough delle tastiere, dock e prolunghe aggiungono un livello che può far cadere la connessione o disturbare il rilevamento durante il cambio di modalità.

Usa una porta direttamente sul computer e, su un desktop, preferisci una porta posteriore a una sul frontale, perché i connettori frontali hanno cablaggi interni e causano più spesso connessioni al limite.

Vale la pena provare anche la generazione della porta. Alcuni dispositivi in modalità bootloader si sono comportati in modo diverso su controller USB di generazioni diverse. Non è universale né prevedibile, ed è proprio per questo che si prova: se hai sia una porta USB 2.0 sia una USB 3.x, prova entrambe. Non costa nulla e risolve una classe di problemi su cui nessuna reinstallazione dei driver ha effetto.

Versione di platform-tools

Usa il pacchetto ufficiale attuale Android SDK Platform Tools dal sito per sviluppatori di Google. Non un bundle “minimal ADB and fastboot” riconfezionato, non una copia arrivata con un'utility di flashing e non una scaricata tre anni fa.

Qui possono andare storte due cose.

La versione è troppo vecchia per il tuo dispositivo. I dispositivi più recenti e i nuovi schemi di partizioni richiedono strumenti più nuovi. Un binario fastboot di una release precedente può non capire ciò che gli comunica un dispositivo attuale.

Sul computer c'è più di una copia. Le utility di flashing installano le proprie copie incluse e, se una è nel PATH, il comando che digiti può non avviare il binario che pensi. Controlla quale viene eseguito davvero:

fastboot --version

Su Windows, where fastboot. Su macOS o Linux, which -a fastboot. Se compare più di un percorso, vale la pena risolvere la situazione prima di fare qualsiasi altra verifica.

Stato dei driver su Windows

Windows associa un driver a un dispositivo USB in base a come si identifica, e un telefono in modalità bootloader si identifica in modo diverso dallo stesso telefono con Android avviato. Per questo un dispositivo può funzionare perfettamente per i trasferimenti di file ed essere invisibile a fastboot, sullo stesso computer e con lo stesso cavo.

Apri Device Manager e osservalo mentre colleghi il telefono in modalità bootloader. Ciò che vedi indica la soluzione:

• Un'interfaccia Android bootloader col nome corretto. Il driver è associato. Il problema è altrove: torna al gradino degli strumenti.
• Un dispositivo sconosciuto o con un simbolo di avviso. Il driver non è associato. È il caso classico.
• Quando colleghi non compare né scompare nulla. Nessun rilevamento. Il sospetto cade su cavo, porta o dispositivo, non sul driver.
• La voce compare e poi sparisce. Il dispositivo si riavvia o perde alimentazione. Prova un'altra porta e un altro cavo prima di trarre conclusioni.

Se serve installare un driver, usa il pacchetto driver USB ufficiale del tuo marchio oppure il driver USB di Google per Pixel e Nexus, entrambi dal sito del produttore. Evita i pacchetti di driver di terze parti dei portali di download.

Alcune procedure di installazione dei driver suggeriscono di disattivare l'imposizione della firma dei driver di Windows. È una vera impostazione di sicurezza del sistema. Se la disattivi, sappi cosa fa e riattivala dopo.

macOS e Linux

Nessuna delle due piattaforme richiede un driver nel senso di Windows. I problemi sono diversi.

macOS. Non serve installare driver. Verifica se il dispositivo viene rilevato in System Information, sotto USB, mentre è collegato in modalità bootloader. Se compare lì ma fastboot devices è vuoto, il problema è nel gradino degli strumenti, non nel sistema. Nelle versioni recenti di macOS, anche le richieste di autorizzazione al primo avvio dei binari scaricati possono interferire: controlla che lo strumento sia autorizzato.

Linux. Di solito il dispositivo viene rilevato senza configurazioni, ma il tuo account utente può non avere i permessi per accedervi. Conferma il rilevamento con lsusb prima e dopo il collegamento. Se il dispositivo compare in lsusb ma non in fastboot devices, guarda prima i permessi. Si risolve con le regole udev per i dispositivi Android che molte distribuzioni includono o che mantiene il progetto android-udev-rules.

Diagnosi rapida: se lo stesso comando eseguito con privilegi elevati trova il dispositivo e come utente normale no, hai confermato che il problema sono i permessi e non la connessione. Risolvi con regole udev corrette, non eseguendo tutto con privilegi elevati.

Macchine virtuali e WSL. Il passthrough USB in una VM o in WSL è un livello in più con problemi propri, soprattutto nei cambi di modalità: quando entra o esce dal bootloader, il dispositivo si scollega e si ricollega con un'altra identità USB e il passthrough può non seguirlo. Se stai risolvendo il problema dentro una VM, prova direttamente sull'host prima di concludere qualcosa.

Quando ADB funziona e fastboot no

È la versione più comune del problema e confonde perché il telefono si collega chiaramente.

La spiegazione è che Android in funzione e il dispositivo in modalità bootloader, per il computer, sono due dispositivi USB diversi. Identificatori diversi, interfaccia diversa, magari un'associazione di driver diversa. Che ADB funzioni dimostra che cavo e porta vanno bene, ed è utile, ma non dimostra nulla sulla connessione in modalità bootloader.

Quindi, se succede, tieni questo risultato. Cavo e porta sono esclusi. Passa subito ai gradini 5 e 6: associazione del driver per l'interfaccia bootloader su Windows, udev su Linux, versione degli strumenti ovunque.

Se la scala non lo trova

A quel punto la domanda utile cambia da “perché il mio computer non lo vede” a “in che stato è il dispositivo”. Sono problemi diversi.

Prendi il risultato del gradino 4 e confrontalo con soft brick vs hard brick. Un dispositivo rilevato come qualcosa di non identificato è in una situazione molto diversa da uno che non viene rilevato per niente, e la differenza cambia sia ciò che è possibile sia il costo.

Prima di concludere che il guasto è del dispositivo, fai un'ultima cosa: prova un secondo computer, meglio se con un altro sistema operativo. Elimina in un solo test un'intera categoria di problemi lato computer ed è più rapido che continuare a lavorare sulla macchina di partenza.

Domande frequenti

Perché adb devices funziona ma fastboot devices non mostra nulla? Perché per il computer sono due dispositivi USB diversi. Android in funzione e il dispositivo in modalità bootloader si presentano con identità diverse e possono usare driver diversi. Che ADB funzioni conferma cavo e porta, e nient'altro.

Devo attivare USB debugging per fastboot? No. USB debugging è un'impostazione di ADB dentro Android. Fastboot opera nel bootloader, sotto il sistema operativo, e non ne dipende. Conta quando il dispositivo non si avvia: USB debugging non si può attivare a posteriori su un telefono che non arriva mai alle impostazioni.

fastboot devices mostra il mio dispositivo ma i comandi falliscono. È un altro problema. Il rilevamento funziona. Probabilmente c'è un bootloader bloccato, una partizione non accessibile nella modalità attuale o un comando che richiede fastbootd invece del fastboot del bootloader. Leggi il testo completo dell'errore: di solito ne indica il motivo.

Un cavo da USB-C a USB-C funziona? In genere sì, se trasmette dati. Il tipo di connettore non è la variabile. Contano se il cavo ha i conduttori dati e se le porte a entrambe le estremità supportano la connessione.

Il telefono deve essere carico? Deve avere carica sufficiente per restare acceso per tutta l'operazione. Un dispositivo con carica molto bassa può perdere la connessione prima che l’operazione sia completata, e un flash interrotto è peggio di nessun flash. Caricalo prima di iniziare.

Si può risolvere da remoto? I livelli lato computer di solito sì, perché driver, strumenti e permessi si gestiscono tutti sul tuo computer. Lo facciamo spesso con una sessione remota, e qui trovi esattamente cosa comporta e cosa possiamo e non possiamo vedere. Se il dispositivo stesso non viene rilevato su nessun computer con nessun cavo, non è un problema lato computer e il lavoro da remoto non lo risolve.

---

Da leggere anche: Soft brick vs hard brick · Risolvere un bootloop senza perdere dati · Flash di Magisk fallito · Android si riavvia sempre in recovery · Cosa significa ogni sintomo nella schermata di avvio

Fonti: Android Open Source Project, documentazione su fastboot in userspace. Android SDK Platform Tools, release ufficiale.

Ultima verifica: 28 agosto 2026. Comportamento USB, requisiti dei driver e modalità disponibili variano per produttore, modello e sistema operativo del computer. Controlla la documentazione ufficiale del tuo dispositivo.