Risposta rapida
L’errore 10 di Google Sign-In, DEVELOPER_ERROR, significa che l’app Android non è configurata correttamente. Se l’accesso funziona in locale ma fallisce in un test chiuso di Play, controlla che lo SHA-1 di firma dell’app installata da Play e il suo nome del pacchetto finale siano registrati nel progetto Firebase o Google Cloud corretto, e che qualsiasi serverClientId o webClientId sia l’ID client dell’applicazione Web, non quello Android. Poi ripeti il test con la build installata da Google Play.
Scegli la tua configurazione
Hai già aggiunto lo SHA-1? Vai a cosa controllare dopo.
Qui ci occupiamo di un solo problema: l’accesso nativo con Google che si rompe nella copia distribuita da Google Play. Lo distinguiamo da altri errori simili, poi passiamo ai framework, agli altri provider di accesso e a cosa devono segnalare i tester. Ogni pagina di Google citata è stata verificata il 16 ottobre 2026, e le segnalazioni della community sono indicate come tali. Le fonti sono elencate alla fine.
In questa pagina
Correggi Google Sign-In nella build di Play
Fai corrispondere l’app installata dai tuoi tester al nome del pacchetto e allo SHA-1 di firma registrati per essa. Segui questi passaggi nell’ordine; i percorsi Firebase e Google Cloud vengono dopo.
Verifica quale copia fallisce
Verifica che il tester abbia installato l’app dal tuo test chiuso su Google Play e annota la versione che ha. Poi annota l’ID applicazione finale di quella build. La guida alla build di Android dice che l’ID applicazione è definito dalla proprietà applicationId, che può differire dal namespace del codice sorgente o ricevere un suffisso in un build flavor. Se il tester non riesce proprio a installare l’app, il problema è un altro: leggi perché un’app non è disponibile per i tester.
Apri la firma dell’app di Play
In Play Console, apri l’app e vai a Protected with Play. Google ha spostato lì la firma dell’app a maggio 2026, e la sua stessa guida indica il passaggio successivo in due modi (tabella sotto). Entrambi i percorsi portano alla stessa pagina.
| Percorso come lo scrive Google | Dove lo usa Google | Cosa aprire lì |
|---|---|---|
| Protected with Play > Play Store distribution > Go to Play app signing | Dove lo usa GoogleGuida di Play Console, Use Play App Signing, sezione sulla registrazione delle API | Cosa aprire lìApp signing key certificate, poi il valore SHA-1 |
| Protected with Play > Play Store protection > Manage Play app signing | Dove lo usa GoogleLe note di aggiornamento di maggio 2026 di Google Play e un’altra sezione della stessa pagina di guida | Cosa aprire lìLa stessa pagina; le etichette dei menu possono variare da un account all’altro |
Copia lo SHA-1 della chiave di firma dell’app
Apri la sezione App signing key certificate (certificato della chiave di firma dell’app), non il certificato della chiave di caricamento, e copia il suo SHA-1. Se Play elenca più di una chiave di firma per la tua app, registra ogni impronta pertinente (vedi più certificati di firma). Mantieni le impronte di debug e locali esistenti e aggiungi accanto quelle di Play. Non ruotare la chiave di firma per risolvere l’accesso.
Registralo dove la tua app esegue l’accesso
Usa il percorso Firebase o il percorso Google Cloud, a seconda di quale usa la tua app, e usa lo stesso progetto che ha emesso gli ID client presenti nella tua app.
Ripeti il test sulla build installata da Play
Se hai modificato solo una registrazione in Firebase o Google Cloud, riprova con la copia già installata da Play prima di creare qualsiasi build; alcuni sviluppatori hanno riferito che una correzione della sola registrazione ha funzionato senza un nuovo caricamento. Se hai modificato la configurazione inclusa nell’app, un ID client, il codice o una dipendenza, carica una nuova build sullo stesso canale chiuso e testa quella. Google non pubblica un tempo fisso perché una nuova impronta diventi effettiva, quindi ripeti il test invece di aspettare un numero prestabilito di ore.
Aggiungi il certificato di Play in Firebase
Seleziona l’app Android corrispondente prima di aggiungere la sua impronta di firma di Play. I passaggi seguono la guida di Firebase sulle impronte e la sua guida all’accesso con Google.
- Nella console Firebase, apri il progetto usato dalla tua app, poi Project settings > General.
- In Your apps, seleziona l’app Android il cui nome del pacchetto corrisponde alla build che fallisce.
- Fai clic su Add fingerprint, incolla lo SHA-1 della firma dell’app di Play e salva. Aggiungilo accanto alle impronte esistenti invece di sostituirle.
- In Authentication > Sign-in method, verifica che Google sia abilitato.
- Se Firebase ti chiede di scaricare un
google-services.jsonaggiornato, sostituisci il file nel tuo progetto. Firebase dice che il file “contains the OAuth client information required for Google sign-in” (contiene le informazioni del client OAuth necessarie per l’accesso con Google), quindi un file modificato significa una nuova build. Verifica che progetto e pacchetto corrispondano all’app che fallisce.
Aggiungi uno SHA-256 solo dove un servizio Firebase specifico lo richiede. L’autenticazione tramite telefono, per esempio, usa lo SHA-256 per il suo percorso Play Integrity; Google Sign-In in sé si basa sullo SHA-1.
Configura Google Cloud senza Firebase
Due client OAuth svolgono due compiti diversi. Il client Android registra la tua app; l’ID client Web è quello usato dalla tua richiesta di token.
| Tipo di client | Cosa contiene | Dove lo usi |
|---|---|---|
| Android | Cosa contieneIl nome del tuo pacchetto e lo SHA-1 del certificato di firma | Dove lo usiRegistra l’identità dell’app nativa. Questo ID client non va incollato in serverClientId. |
| Applicazione web | Cosa contieneL’ID client Web | Dove lo usiIl serverClientId o webClientId nella tua richiesta di token, e l’audience accettata dal tuo backend. Il codelab Sign in with Google di Google lo descrive come il client che agisce “as the backend client for the Google Sign-in service” (da client backend per il servizio Google Sign-In). |
- Seleziona il progetto che ha emesso i tuoi ID client, poi apri Google Auth platform > Clients (guida di Google Cloud).
- Cerca un client Android esistente con questo nome del pacchetto e questo SHA-1 prima di crearne un altro.
- Se manca, scegli Create Client, imposta Application type su Android, inserisci un nome, il nome del pacchetto e lo SHA-1 della firma dell’app di Play, poi Create. Il modulo Android ha un campo SHA-1; uno SHA-256 non va lì.
- Registra ogni coppia di pacchetto e certificato di cui hai bisogno, per esempio debug, release locale e Play.
- Lascia al suo posto il client Web per la richiesta di token, e non inserire mai un client secret nell’app.
Dimostra che la correzione funziona
Un singolo accesso riuscito non dimostra che la release sia corretta. Questa checklist è il test di accettazione che consigliamo, non una regola di Google; l’ultima riga conta perché il login di uno sviluppatore è riuscito una volta e poi è fallito all’accesso successivo, un problema di sessione che un solo controllo non avrebbe rilevato.
| Controllo | Prova che è superato | Se fallisce |
|---|---|---|
| App e versione corrette | Prova che è superatoIl tester conferma l’installazione da Play e la build previste | Se fallisceRisolvi prima la distribuzione della release o del canale |
| Primo accesso | Prova che è superatoDopo la scelta di un account si torna all’app con l’accesso eseguito | Se fallisceRegistra l’eccezione esatta e usa la tabella degli errori qui sotto |
| Funzione protetta | Prova che è superatoIl tester può usare una funzione che richiede l’accesso | Se fallisceControlla come l’app e il backend gestiscono il token |
| Esci e accedi di nuovo | Prova che è superatoUn secondo accesso funziona senza reinstallare | Se fallisceIndaga sulla gestione della sessione e dell’uscita dal provider |
| Dispositivo colpito in precedenza | Prova che è superatoLo stesso tester sullo stesso dispositivo ora riesce | Se fallisceConfronta certificato, sistema operativo, account e la build effettiva |
| Continuità del test | Prova che è superatoIl tester ha ancora attivato il test e tu hai annotato la correzione | Se fallisceRisolvi la partecipazione al test separatamente dall’accesso |
Perché l’accesso funziona in debug ma fallisce nel test chiuso?
L’app installata tramite Google Play può avere un firmatario diverso dall’APK che installi in locale. La guida all’autenticazione del client di Google osserva che “Android Studio automatically signs your app with a debug certificate” (Android Studio firma automaticamente l’app con un certificato di debug). Una release creata da te usa la chiave configurata per quella variante. Con Play App Signing, la tua chiave di caricamento firma il bundle che carichi, e Google firma gli APK ricevuti dai tuoi tester con la chiave di firma dell’app.
Queste chiavi hanno ruoli diversi, ma non sempre valori diversi: puoi fornire la tua chiave di firma, e alcune configurazioni usano una sola chiave per due ruoli. Confronta le impronte effettive invece delle etichette delle chiavi.
| Copia installata | Certificato da controllare | Prima azione |
|---|---|---|
| Installazione da Play in test interno, chiuso, aperto o in produzione con Play App Signing | Certificato da controllareIl certificato o i certificati di firma dell’app di Play, in Protected with Play | Prima azioneRegistra ogni SHA-1 di Play pertinente |
| Esecuzione di debug da Android Studio | Certificato da controllareIl certificato di debug di quel computer | Prima azioneRegistra quello SHA-1 per l’ID applicazione corrispondente |
| APK di release creato sul tuo computer | Certificato da controllareIl certificato configurato per quella variante di release | Prima azioneNon dare per scontato che “release” significhi il firmatario di Google |
| Link di condivisione interna dell’app | Certificato da controllareIl certificato di test proprio della condivisione interna dell’app | Prima azioneRegistralo a parte se i tester usano quel percorso |
La condivisione interna dell’app non è il test interno
La guida di Google sulla condivisione interna dell’app dice “Every APK is resigned with this test certificate” (ogni APK viene firmato di nuovo con questo certificato di test). Lo trovi in Test and release > Internal testing > Internal app sharing > Uploaders and testers > Internal test certificate. I canali di test interno e di test chiuso usano invece la tua chiave di firma dell’app di Play.
Leggi tu stesso le impronte
Per le build sul tuo computer, il signing report di Gradle stampa lo SHA-1 e lo SHA-256 di ogni variante, e keytool legge direttamente il keystore di debug (inserisci la password del keystore quando richiesta):
./gradlew signingReport
keytool -list -v -alias androiddebugkey -keystore ~/.android/debug.keystoreUn signing report locale non ti dice cosa ha firmato la copia di Play. Per controllare la build che fallisce, installala dal test chiuso su un dispositivo, estraila con adb e stampa i suoi certificati con apksigner, che secondo la documentazione di Google mostra “information about the APK's signing certificates” (informazioni sui certificati di firma dell’APK). Sostituisci il nome del pacchetto e usa il percorso stampato dal primo comando:
adb shell pm path com.example.app
adb pull /data/app/.../base.apk failing-play.apk
apksigner verify --print-certs failing-play.apkHo aggiunto lo SHA-1 e l’errore resta
Confronta il certificato dell’APK che fallisce, il suo ID applicazione finale e gli ID client prima di modificare altre impostazioni. Scendi lungo questa scala; ogni riga esclude un livello.
| Controllo | Cosa confrontare | Decisione |
|---|---|---|
| 1. Copia installata e canale | Cosa confrontareL’installazione da Play effettiva del tester rispetto alla versione che volevi testare | DecisioneUn signing report locale non prova chi sia il firmatario di Play |
| 2. Certificato | Cosa confrontareL’output di apksigner verify --print-certs sull’APK di Play che fallisce rispetto a quanto hai registrato |
DecisioneRegistra ogni firmatario necessario; conserva le voci più vecchie che servono ancora utenti con l’app installata |
| 3. ID applicazione finale | Cosa confrontareL’applicationId della variante creata, inclusi i suffissi dei flavor, rispetto al pacchetto registrato | DecisioneIl namespace del codice sorgente non conta |
| 4. Progetto e client Web | Cosa confrontareIl progetto e l’ID client Web usati davvero dalla tua build di release e dal backend | DecisioneUn errore di battitura qui rompe l’accesso anche con le impronte corrette |
| 5. Provider e client esistono | Cosa confrontareGoogle abilitato come provider, più i client Android e Web che lo supportano | DecisioneSe un altro progetto rivendica la coppia, leggi la nota sui conflitti qui sotto |
| 6. Famiglia dell’errore | Cosa confrontareCodice nativo 10, un annullamento di Credential Manager, un token rifiutato dal backend o un redirect del browser non corrispondente | DecisioneOgnuno è un ramo separato; vedi la tabella degli errori |
| 7. Problema di release del framework | Cosa confrontareRiduzione delle risorse (resource shrinking), la versione della libreria risolta e l’inizializzazione | DecisioneUsa i changelog e le correzioni confermate, non aggiornamenti o downgrade a caso |
La riga 4 non è teoria. In un caso Expo segnalato a settembre 2026, aggiungere le impronte non ha cambiato nulla; la soluzione era un errore di battitura nell’ID client accettato dal backend.
Più certificati di firma o chiavi aggiornate
Una sola app può aver bisogno di registrare più di un’identità di firma. L’attuale guida a Play App Signing di Google descrive la firma ibrida con tre chiavi di firma dell’app e ti chiede di registrare le impronte di ciascuna, e un’app che ha aggiornato la propria chiave di firma può avere ancora installazioni firmate con una chiave precedente. Registra le identità che le tue installazioni portano davvero e non eliminare le voci più vecchie che funzionano ancora. La rotazione delle chiavi esula da questa guida, e non è una soluzione per l’accesso.
Un altro progetto possiede già questo pacchetto e questo SHA-1
La guida di Firebase sui conflitti dice che una coppia di nome del pacchetto e SHA-1 “must be unique across all Firebase and Google Cloud projects” (deve essere univoca in tutti i progetti Firebase e Google Cloud). Se la console rifiuta la tua impronta perché la detiene un altro progetto, scopri quale progetto possiede quel client OAuth prima di eliminare qualsiasi cosa. L’assistenza Google può aiutarti a individuare il conflitto; non rimuovere client o progetti attivi andando a tentativi.
L’errore 10 è uguale a 12500, 12501 o canceled?
No. Leggi l’errore esatto e la libreria che lo ha prodotto prima di trattare ogni accesso fallito come un unico problema. Il riferimento di Google sui codici di stato comuni definisce DEVELOPER_ERROR = 10 come “The application is misconfigured.” (l’applicazione non è configurata correttamente). Gli altri codici qui sotto provengono dallo storico SDK play-services-auth 21.6.0 di Google.
| Cosa vedi | Cosa significa | Passo successivo |
|---|---|---|
ApiException: 10 o DEVELOPER_ERROR |
Cosa significaErrore di configurazione dell’app | Passo successivoConfronta firmatario, pacchetto, progetto e ID client |
12500 |
Cosa significaSIGN_IN_FAILED: “A non-recoverable sign in failure occurred” (si è verificato un errore di accesso non recuperabile) |
Passo successivoLeggi i log circostanti; non trattarlo come errore 10 |
12501 |
Cosa significaSIGN_IN_CANCELLED: “Sign in action cancelled” (azione di accesso annullata) |
Passo successivoScopri se l’utente ha annullato e quale API lo ha prodotto |
canceled di Credential Manager o Flutter |
Cosa significaUn vero annullamento o un problema di configurazione | Passo successivoEsamina i dettagli dell’eccezione e la configurazione; lascia che l’utente faccia un nuovo tentativo dopo la diagnosi |
NoCredentialException |
Cosa significaNessuna credenziale restituita; non è una diagnosi sul certificato | Passo successivoControlla la disponibilità dell’account e la configurazione della richiesta, oltre alla registrazione |
| Il token Google funziona, il backend lo rifiuta | Cosa significaUna fase successiva all’ottenimento della credenziale Google | Passo successivoControlla l’audience e gli ID client accettati dal tuo backend |
redirect_uri_mismatch |
Cosa significaUn redirect OAuth nel browser non corrisponde a un URI autorizzato | Passo successivoCorreggi la configurazione del callback per quel flusso |
| “Item not found” (elemento non trovato) sul link di Play | Cosa significaUn problema di installazione o di idoneità, non di accesso | Passo successivoSegui i controlli per l’app non disponibile |
Google Sign-In legacy e Credential Manager
Le note di rilascio di Play services di Google riportano il ritiro (deprecation) delle API di Google Sign-In in play-services-base il 16 aprile 2024, e Google ha annunciato il passaggio a Credential Manager l’11 settembre 2024. Le API sono state poi rimosse da play-services-auth 22.0.0 il 26 agosto 2026 e da play-services-base 18.11.0 il 17 settembre 2026, con la nota “Removed the APIs related to Google Sign-in.” (rimosse le API relative a Google Sign-In). Si tratta di una modifica dell’SDK; non stabilisce una data di spegnimento per le app già installate. Il nuovo codice e gli aggiornamenti dovrebbero seguire la guida alla migrazione di Google.
Le due API falliscono in modo diverso. Credential Manager non ha un errore 10; la sua guida alla risoluzione dei problemi avverte che “A high volume of "cancellations" may actually indicate a misconfiguration.” (un numero elevato di "annullamenti" può in realtà indicare una configurazione errata). Quindi un annullamento può essere un errore di configurazione o un annullamento reale, e NoCredentialException è ancora un altro segnale.
Controlli per Flutter, React Native, Expo e Unity
I controlli sull’identità nativa visti sopra valgono per ogni framework, ma configurazione, inizializzazione e impostazioni di build cambiano. Usa il percorso del tuo framework e la versione della libreria che la tua app risolve davvero.
| Framework | Controlli specifici | Non dare per scontato |
|---|---|---|
| Flutter | Controlli specificiL’implementazione Android, google_sign_in_android, è passata a Credential Manager nella 7.0.0. Passa l’ID client Web come serverClientId. Il suo changelog per la 7.2.16 “Keeps default_web_client_id resource from being stripped by resource shrinkers” (impedisce che la risorsa default_web_client_id venga rimossa dagli strumenti di riduzione delle risorse), il che conta per i fallimenti che si verificano solo in release. |
Non dare per scontatoChe ogni risultato canceled sia un problema di SHA, o che un downgrade sia una soluzione universale. |
| React Native | Controlli specificiIdentifica quale API della libreria usi, passa l’ID client Web come webClientId e controlla l’applicationId reale e l’APK che fallisce. La guida alla risoluzione dei problemi elenca “Login does not work when downloading from the Play Store” (il login non funziona quando si scarica dal Play Store) e offre un comando di verifica della configurazione (sotto). |
Non dare per scontatoChe una issue chiusa sul tracker dimostri una correzione. |
| Expo | Controlli specificiL’accesso nativo con Google richiede una development build o una build personalizzata; la guida di Expo dice “These libraries can't be used in Expo Go because they require custom native code.” (queste librerie non si possono usare in Expo Go perché richiedono codice nativo personalizzato). Tieni separato il certificato di firma EAS o locale da quello di firma dell’app di Play. | Non dare per scontatoChe Expo Go riproduca il flusso di release, o che una nuova build corregga un ID client del backend sbagliato. |
| Unity | Controlli specificiDecidi se usi Firebase Authentication o Unity Authentication, ottieni il token ID Google tramite l’integrazione di piattaforma supportata, poi scambialo con quel backend (guida Unity di Firebase). Il vecchio esempio di accesso per Unity di Google è stato archiviato il 19 aprile 2026. | Non dare per scontatoChe l’accesso a Play Games e l’accesso con l’account Google siano la stessa integrazione. |
Per React Native, i maintainer della libreria forniscono un controllo della configurazione che puoi eseguire dalla radice del progetto:
npx @react-native-google-signin/config-doctorCosa cambia con Supabase, Facebook, Apple o Auth0?
Il provider e il flusso di accesso determinano quale certificato, ID client o callback deve corrispondere. Uno SHA-1 di Google è la risposta per l’accesso nativo con Google; per altri provider può essere l’hash sbagliato, il formato sbagliato o del tutto irrilevante.
| Provider o flusso | Cosa deve corrispondere | Dove impostarlo |
|---|---|---|
| Google nativo con Firebase | Cosa deve corrisponderePacchetto installato e SHA-1, il client Web, Google abilitato come provider | Dove impostarloImpronte nelle Project settings di Firebase, più Authentication |
| Google nativo con Supabase | Cosa deve corrispondereL’identità Android nativa e l’ID client Web; la guida di Supabase dice “The Web client ID is the one used in your Android app.” (l’ID client Web è quello usato nella tua app Android) | Dove impostarloClient Google Android e Web, poi le impostazioni del provider Google in Supabase |
| OAuth di Supabase nel browser | Cosa deve corrispondereIl client Web, il callback di Supabase e il link di ritorno della tua app | Dove impostarloURI di reindirizzamento autorizzati in Google e impostazioni di redirect di Supabase; una correzione dello SHA non c’entra |
| Facebook su Android | Cosa deve corrispondereUn key hash in Base64 ricavato dai byte dello SHA-1 del certificato di firma, non l’esadecimale separato dai due punti | Dove impostarloImpostazioni dell’app Facebook, key hash Android (percorso come documentato nella guida Expo per Facebook) |
| Accesso web con Apple su Android | Cosa deve corrispondereIl Services ID, il dominio e l’URL di ritorno | Dove impostarloConfigurazione web di Sign in with Apple di Apple; non è il meccanismo DEVELOPER_ERROR di Google |
| Apple tramite Firebase su Android | Cosa deve corrispondereLa configurazione Apple più lo SHA-1 dell’app | Dove impostarloGuida Apple di Firebase: “Specify your app's SHA-1 fingerprint if you haven't already.” (specifica l’impronta SHA-1 della tua app, se non l’hai già fatto) |
| Auth0 su Android | Cosa deve corrispondereURL di callback consentiti e lo schema dell’app; l’identità degli app link dove usati | Dove impostarloImpostazioni dell’applicazione Auth0; il suo readme dell’SDK Android usa key hash SHA-256 per la configurazione degli app link |
| Autenticazione tramite telefono di Firebase | Cosa deve corrispondereSHA-256 per Play Integrity, SHA-1 per il fallback reCAPTCHA | Dove impostarloFirebase phone auth: un flusso separato dall’accesso con Google |
Non spostare l’accesso in una WebView
Far passare l’accesso con Google da una WebView incorporata non è un espediente valido. Le norme OAuth 2.0 di Google dicono che gli sviluppatori “must not direct a Google OAuth 2.0 authorization request to an embedded user-agent” (non devono indirizzare una richiesta di autorizzazione Google OAuth 2.0 verso uno user-agent incorporato).
Cosa devono inviare i tester allo sviluppatore?
Una segnalazione utile identifica la build di Play che fallisce e il punto esatto in cui l’accesso si blocca. Un tester non può riparare una registrazione OAuth riprovando, quindi il suo compito è raccogliere prove, non insistere. Copia questo modello e invialo ai tuoi tester:
App e link di test di Play:
Versione o build dell’app installata:
Installata da: test chiuso di Play / un altro percorso
Dispositivo e versione di Android:
Data, ora e fuso orario:
Testo esatto dell’errore o uno screenshot oscurato:
Dove si è bloccato: prima della scelta dell’account / dopo aver scelto un account / dopo il ritorno all’app
Un altro metodo di accesso ha aperto l’app?
Risultato e versione del nuovo test:Chiedi ai tester di mantenere attivo il test mentre risolvi il problema. Non chiedere mai password, token OAuth, chiavi private o accesso a Play Console. Dopo la tua modifica, chiedi allo stesso tester di aprire una funzione che richiede l’accesso, poi di uscire e accedere di nuovo, e di annotare la versione e il risultato.
L’errore 10 influisce sul mio test chiuso o sull’accesso in produzione?
Un errore di configurazione dell’accesso è separato dalla partecipazione al test. L’errore 10 non è un codice di rifiuto per violazione delle norme di Play, e nessuna regola di Google che abbiamo trovato dice che azzera il periodo di attivazione dei tuoi tester. La pagina sui requisiti di test di Google ti incoraggia a migliorare l’app durante il test chiuso, quindi mantieni attivi i tester e pubblica la correzione sullo stesso canale chiuso. Questa è una lettura delle regole pubblicate, non una promessa valida per ogni caso.
Un accesso non funzionante conta comunque. Le norme sulla funzionalità di Google Play dicono “We don’t allow apps that crash, force close, freeze, or otherwise function abnormally” (non consentiamo app che si arrestano in modo anomalo, si chiudono forzatamente, si bloccano o funzionano in modo anomalo), e un muro di login impedisce ai tester di raggiungere le funzioni che devono testare. Risolvilo prima di richiedere l’accesso in produzione, e fornisci ai revisori credenziali di accesso funzionanti. Se è già arrivato l’esito di una revisione, leggi il rifiuto per Broken Functionality.
Per contesto: gli account sviluppatore personali creati dopo il 13 novembre 2023 devono avere almeno 12 tester che abbiano attivato il test continuamente per 14 giorni prima di richiedere l’accesso in produzione per quell’app. Dopo la richiesta, Google dice: “In genere questa operazione richiede al massimo 7 giorni, ma a volte può essere necessario più tempo.” Se mancano tester dal conteggio, verifica come sono stati invitati prima di toccare l’accesso.
Ti servono tester reali per i 14 giorni?
I tester non possono correggere una registrazione OAuth, quindi prima fai funzionare l’accesso. Una volta risolto, PrimeTestLab fornisce 12+ tester reali che installano la tua build di Play su veri telefoni Android e mantengono attivo il test per tutti i 14 giorni, da $19.99 (più il 5% di commissione di servizio). Se Google non concede l’accesso in produzione dopo il test completo, puoi scegliere tra un nuovo test gratuito o un rimborso completo. Scopri come funziona il test chiuso con 12 tester.
Domande frequenti
Perché Google Sign-In funziona in debug ma non nel test chiuso?
L’APK di debug e l’app scaricata da Google Play possono essere firmati con certificati diversi, quindi registrare l’impronta di debug non configura la build di Play. Parti dallo SHA-1 della firma dell’app di Play, poi controlla il nome del pacchetto finale della build di release e gli ID client che l’app usa davvero.
Dove trovo ora lo SHA-1 di Play App Signing?
Apri la pagina Protected with Play della tua app in Play Console. La guida di Google indica Play Store distribution, poi Go to Play app signing; altri testi attuali di Google li chiamano Play Store protection e Manage Play app signing. Apri la sezione App signing key certificate e copia lo SHA-1, controllando anche le eventuali chiavi aggiuntive mostrate per la tua app.
Per Google Sign-In serve lo SHA-1 o lo SHA-256?
Il client OAuth Android di Google identifica la tua app tramite il nome del pacchetto e l’impronta SHA-1 del certificato di firma, e lo SHA-256 non sostituisce quel campo. Altri servizi hanno esigenze proprie: l’autenticazione tramite telefono di Firebase usa lo SHA-256 per Play Integrity e lo SHA-1 per il fallback reCAPTCHA. Configura ogni servizio per il flusso usato dalla tua app.
Ho già aggiunto lo SHA-1. Cosa devo controllare ora?
Verifica che appartenga all’app installata da Play, non alla tua chiave di caricamento o di debug. Poi confronta l’ID applicazione finale, il progetto Firebase o Cloud e l’ID client Web. Se la tua app ha più certificati di firma, controlla anche quelli. Un errore di battitura nell’ID client accettato dal backend può rompere l’accesso anche quando le impronte sono corrette.
Devo caricare un altro AAB dopo aver aggiunto un’impronta?
Non necessariamente. Alcuni sviluppatori riferiscono che una correzione della sola registrazione in Firebase o Google Cloud ha funzionato con l’app già installata. Un ID client, un file di configurazione, il codice o una dipendenza modificati devono invece arrivare ai tester in una nuova build. Controlla cosa hai cambiato, poi verifica l’installazione effettiva da Play invece di ricreare la build più volte senza una diagnosi.
Quanto tempo ci mette una nuova impronta a funzionare?
Google non pubblica un tempo di propagazione specifico per le impronte, e le discussioni tra sviluppatori che abbiamo esaminato non ne hanno misurato uno. Salva la configurazione corretta e riprova. Se fallisce ancora, verifica il certificato installato e le impostazioni del client invece di aspettare un numero fisso di ore, perché l’attesa non ripara una mancata corrispondenza.
Perché dice canceled se non ho annullato?
Alcune integrazioni di Credential Manager e dei framework segnalano un problema di configurazione o di autorizzazione come annullamento, anche se un annullamento può essere reale. Annota il tipo e il messaggio dell’eccezione, consulta la guida alla risoluzione dei problemi del tuo framework e tieni distinta l’API attuale dallo stato legacy 12501 SIGN_IN_CANCELLED prima di modificare le impostazioni.
L’ID client Android è quello da inserire in serverClientId?
No. Nelle integrazioni native di Google documentate, serverClientId o webClientId è il client OAuth dell’applicazione Web usato per la richiesta di token. Il client Android registra invece il tuo pacchetto e il certificato di firma. Configurali entrambi e verifica che il tuo backend accetti l’audience del token prevista, invece di scambiare gli ID client a caso.
L’errore 10 fa ripartire il mio test chiuso di 14 giorni?
Nessuna regola di Google che abbiamo trovato dice che questo errore azzera il periodo di attivazione, e Google incoraggia i miglioramenti durante il test chiuso, quindi mantieni i tester iscritti e correggi il canale esistente. Questo non significa che l’app sia pronta: un muro di login può impedire un test utile e lasciare un problema di funzionalità che devi risolvere prima di fare la richiesta.
Cosa devo chiedere a un tester di inviarmi?
Chiedi la versione installata, il link di test di Play, il dispositivo e la versione di Android, l’errore esatto e il passaggio in cui l’accesso si blocca. Uno screenshot oscurato o una breve registrazione dello schermo aiutano. Dopo la correzione, chiedi allo stesso tester di usare una funzione che richiede l’accesso, poi di uscire e accedere di nuovo, senza condividere alcuna credenziale.
In conclusione
In sintesi
L’errore 10 di Google Sign-In significa che l’app non è configurata correttamente, e quando fallisce solo la copia di Play, il certificato di firma è la prima cosa da controllare. Copia lo SHA-1 della chiave di firma dell’app da Protected with Play, registralo con il nome del pacchetto finale della build nello stesso progetto Firebase o Google Cloud usato dalla tua app, mantieni l’ID client Web in serverClientId e ripeti il test sulla build installata dai tuoi tester, compreso un secondo accesso. Se fallisce ancora, confronta il certificato dell’APK installato, l’ID applicazione e gli ID client prima di cambiare qualsiasi altra cosa.
Fonti verificate il 16 ottobre 2026
Le etichette dei menu di Play Console e di Firebase sono i dati che cambiano più in fretta in questa pagina. Se un percorso indicato sopra non corrisponde più alla tua console, cerca la firma dell’app di Play in Protected with Play, e le impronte sotto la tua app Android nelle Project settings di Firebase.