Kort antwoord
Google Sign-In fout 10, DEVELOPER_ERROR, betekent dat de Android-app verkeerd is geconfigureerd. Werkt inloggen lokaal wel maar faalt het in een gesloten test op Play, controleer dan of de ondertekenings-SHA-1 van de via Play geïnstalleerde app en de uiteindelijke pakketnaam zijn geregistreerd in het juiste Firebase- of Google Cloud-project, en of een eventuele serverClientId of webClientId het client-ID van de webapplicatie is, niet dat van de Android-client. Test daarna opnieuw met de build die via Google Play is geïnstalleerd.
Kies je opzet
SHA-1 al toegevoegd? Ga naar wat je daarna controleert.
Dit artikel gaat over één fout: native inloggen met Google dat niet werkt in de versie die Google Play levert. Het onderscheidt die fout van andere fouten die erop lijken en behandelt daarna frameworks, andere inlogproviders en wat testers moeten melden. Elke Google-pagina die hier wordt aangehaald, is gecontroleerd op 16 oktober 2026, en meldingen uit de community zijn als zodanig aangeduid. De bronnen staan onderaan.
Op deze pagina
Google Sign-In herstellen in de Play-build
Laat de app die je testers hebben geïnstalleerd overeenkomen met de pakketnaam en de ondertekenings-SHA-1 die ervoor zijn geregistreerd. Doorloop deze stappen op volgorde; de routes voor Firebase en Google Cloud volgen daarna.
Stel vast welke versie faalt
Controleer of de tester de app vanuit je gesloten test op Google Play heeft geïnstalleerd en noteer welke versie hij heeft. Noteer daarna het uiteindelijke applicatie-ID van die build. De buildgids van Android zegt dat je applicatie-ID wordt bepaald door de eigenschap applicationId, die kan afwijken van je bron-namespace of in een buildflavor een achtervoegsel kan krijgen. Kan de tester de app helemaal niet installeren, dan is dat een ander probleem: zie waarom een app niet beschikbaar is voor testers.
Open Play App Signing
Open in Play Console de app en ga naar Protected with Play. Google heeft app-ondertekening daar in mei 2026 ondergebracht, en de eigen helppagina's van Google noemen de volgende stap op twee manieren (zie de tabel hieronder). Beide routes komen uit op dezelfde pagina.
| Route zoals Google die schrijft | Waar Google die gebruikt | Wat je daar opent |
|---|---|---|
| Protected with Play > Play Store distribution > Go to Play app signing | Waar Google die gebruiktPlay Console Help, Use Play App Signing, onderdeel over API-registratie | Wat je daar opentApp signing key certificate, daarna de SHA-1-waarde |
| Protected with Play > Play Store protection > Manage Play app signing | Waar Google die gebruiktDe updatenotities van mei 2026 van Google Play en een ander onderdeel van dezelfde helppagina | Wat je daar opentDezelfde pagina; menulabels kunnen per account verschillen |
Kopieer de SHA-1 van de app-ondertekeningssleutel
Open het onderdeel App signing key certificate, niet het certificaat van de uploadsleutel, en kopieer de SHA-1 daarvan. Toont Play meer dan één ondertekeningssleutel voor je app, registreer dan elke relevante vingerafdruk (zie meerdere ondertekeningscertificaten). Laat je bestaande debug- en lokale vingerafdrukken staan en voeg de Play-vingerafdrukken ernaast toe. Roteer je ondertekeningssleutel niet om het inloggen te herstellen.
Registreer hem waar je app inlogt
Gebruik de route via Firebase of de route via Google Cloud, afhankelijk van wat je app gebruikt, en kies hetzelfde project dat de client-ID's in je app heeft uitgegeven.
Test de geïnstalleerde Play-build opnieuw
Heb je alleen een registratie in Firebase of Google Cloud aangepast, probeer het dan opnieuw met de versie die al via Play is geïnstalleerd voordat je iets bouwt; ontwikkelaars melden dat een oplossing die alleen uit registratie bestond werkte zonder nieuwe upload. Heb je meegebundelde configuratie, een client-ID, code of een dependency gewijzigd, upload dan een nieuwe build naar dezelfde gesloten testtrack en test die. Google noemt geen vaste termijn waarbinnen een nieuwe vingerafdruk actief wordt, dus test opnieuw in plaats van een vast aantal uren te wachten.
Voeg het Play-certificaat toe in Firebase
Selecteer de juiste Android-app voordat je de vingerafdruk van de Play-ondertekening toevoegt. De stappen volgen de help van Firebase over vingerafdrukken en de gids voor inloggen met Google.
- Open in de Firebase-console het project dat je app gebruikt en ga naar Project settings > General.
- Selecteer onder Your apps de Android-app waarvan de pakketnaam overeenkomt met de falende build.
- Klik op Add fingerprint, plak de SHA-1 van Play App Signing en sla op. Voeg hem toe naast de bestaande vingerafdrukken in plaats van ze te vervangen.
- Controleer onder Authentication > Sign-in method of Google is ingeschakeld.
- Vraagt Firebase je om een bijgewerkt
google-services.jsonte downloaden, vervang het bestand dan in je project. Volgens Firebase “bevat het bestand de OAuth-clientgegevens die nodig zijn voor inloggen met Google”, dus een gewijzigd bestand betekent een nieuwe build. Controleer of het project en het pakket erin overeenkomen met de falende app.
Voeg alleen een SHA-256 toe als een specifieke Firebase-dienst daarom vraagt. Telefoonauthenticatie gebruikt bijvoorbeeld SHA-256 voor de route via Play Integrity; Google Sign-In zelf steunt op de SHA-1.
Google Cloud configureren zonder Firebase
Twee OAuth-clients doen twee verschillende dingen. De Android-client registreert je app; het webclient-ID is het ID dat je tokenaanvraag gebruikt.
| Clienttype | Wat erin staat | Waar je hem gebruikt |
|---|---|---|
| Android | Wat erin staatJe pakketnaam en de SHA-1 van het ondertekeningscertificaat | Waar je hem gebruiktRegistreert de identiteit van de native app. Dit client-ID plak je niet in serverClientId. |
| Webapplicatie | Wat erin staatHet webclient-ID | Waar je hem gebruiktDe serverClientId of webClientId in je tokenaanvraag, en de audience die je backend accepteert. De codelab Sign in with Google van Google beschrijft hem als de client die “optreedt als backendclient voor de Google Sign-in-service”. |
- Selecteer het project dat je client-ID's heeft uitgegeven en open daarna Google Auth platform > Clients (help van Google Cloud).
- Kijk of er al een Android-client met deze pakketnaam en SHA-1 bestaat voordat je een nieuwe maakt.
- Ontbreekt hij, kies dan Create Client, zet Application type op Android, vul een naam, de pakketnaam en de SHA-1 van Play App Signing in en klik op Create. Het Android-formulier heeft een SHA-1-veld; een SHA-256 hoort daar niet.
- Registreer elk paar van pakket en certificaat dat je nodig hebt, bijvoorbeeld debug, lokale release en Play.
- Laat de webclient staan voor de tokenaanvraag en zet nooit een clientgeheim in de app.
Bewijs dat het herstel werkt
Eén geslaagde inlogpoging bewijst niet dat de release in orde is. Deze checklist is onze aanbevolen acceptatietest, geen regel van Google; de laatste rij telt omdat de login van een ontwikkelaar één keer slaagde en bij de volgende inlogpoging toch faalde, een sessieprobleem dat een enkele controle zou missen.
| Controle | Bewijs dat het slaagt | Als het faalt |
|---|---|---|
| Juiste app en versie | Bewijs dat het slaagtDe tester bevestigt de bedoelde Play-installatie en build | Als het faaltLos eerst de levering van de release of de track op |
| Eerste inlogpoging | Bewijs dat het slaagtNa het kiezen van een account keert de tester ingelogd terug in de app | Als het faaltLeg de exacte exception vast en gebruik de fouttabel hieronder |
| Beveiligde functie | Bewijs dat het slaagtDe tester kan een functie gebruiken waarvoor inloggen nodig is | Als het faaltControleer hoe de app en de backend met tokens omgaan |
| Uitloggen en opnieuw inloggen | Bewijs dat het slaagtEen tweede inlogpoging werkt zonder opnieuw te installeren | Als het faaltOnderzoek de afhandeling van sessies en van uitloggen bij de provider |
| Apparaat dat eerder getroffen was | Bewijs dat het slaagtDezelfde tester en hetzelfde apparaat slagen nu | Als het faaltVergelijk certificaat, besturingssysteem, account en de daadwerkelijke build |
| Doorlopende test | Bewijs dat het slaagtDe tester is nog steeds aangemeld en je hebt de oplossing vastgelegd | Als het faaltLos de aanmelding los van het inloggen op |
Waarom werkt inloggen in debug, maar faalt het in de gesloten test?
De app die via Google Play is geïnstalleerd, kan een andere ondertekenaar hebben dan de APK die je lokaal installeert. De gids over clientauthenticatie van Google merkt op dat “Android Studio je app automatisch ondertekent met een debugcertificaat”. Een release die je zelf bouwt, gebruikt de sleutel die voor die variant is ingesteld. Met Play App Signing ondertekent je uploadsleutel de bundel die je uploadt, en ondertekent Google de APK's die je testers ontvangen met de app-ondertekeningssleutel.
Die sleutels hebben verschillende rollen, maar het zijn niet altijd verschillende waarden: je kunt je eigen ondertekeningssleutel aanleveren, en sommige opzetten gebruiken één sleutel voor twee rollen. Vergelijk de echte vingerafdrukken in plaats van de namen van de sleutels.
| Geïnstalleerde versie | Te controleren certificaat | Eerste actie |
|---|---|---|
| Installatie via Play uit een interne, gesloten of open test of uit productie, met Play App Signing | Te controleren certificaatHet certificaat of de certificaten van Play App Signing, te vinden onder Protected with Play | Eerste actieRegistreer elke relevante Play-SHA-1 |
| Debugrun vanuit Android Studio | Te controleren certificaatHet debugcertificaat van die computer | Eerste actieRegistreer die SHA-1 voor het bijbehorende applicatie-ID |
| Release-APK die je op je eigen computer bouwt | Te controleren certificaatHet certificaat dat voor die releasevariant is ingesteld | Eerste actieGa er niet van uit dat “release” de ondertekening van Google betekent |
| Link voor intern delen van apps | Te controleren certificaatHet eigen testcertificaat van intern delen van apps | Eerste actieRegistreer het apart als testers die route gebruiken |
Intern delen van apps is geen interne test
De help van Google over intern delen van apps zegt: “Elke APK wordt opnieuw ondertekend met dit testcertificaat.” Je vindt het onder Test and release > Internal testing > Internal app sharing > Uploaders and testers > Internal test certificate. De tracks voor de interne test en de gesloten test gebruiken in plaats daarvan je app-ondertekeningssleutel van Play.
Lees de vingerafdrukken zelf uit
Voor builds op je eigen computer toont het signing report van Gradle de SHA-1 en SHA-256 van elke variant, en keytool leest de debug-keystore rechtstreeks uit (vul het keystorewachtwoord in als daarom wordt gevraagd):
./gradlew signingReport
keytool -list -v -alias androiddebugkey -keystore ~/.android/debug.keystoreEen lokaal signing report vertelt je niet waarmee de Play-versie is ondertekend. Wil je de falende build zelf controleren, installeer hem dan vanuit de gesloten test op een apparaat, haal hem op met adb en toon de certificaten met apksigner, dat volgens de documentatie van Google “informatie over de ondertekeningscertificaten van de APK” toont. Vervang de pakketnaam en gebruik het pad dat het eerste commando toont:
adb shell pm path com.example.app
adb pull /data/app/.../base.apk failing-play.apk
apksigner verify --print-certs failing-play.apkIk heb de SHA-1 toegevoegd en het faalt nog steeds
Vergelijk het certificaat van de falende APK, het uiteindelijke applicatie-ID en de client-ID's voordat je meer instellingen wijzigt. Werk deze ladder van boven naar beneden af; elke rij sluit één laag uit.
| Controle | Wat je vergelijkt | Beslissing |
|---|---|---|
| 1. Geïnstalleerde versie en track | Wat je vergelijktDe echte Play-installatie van de tester tegenover de versie die je wilde testen | BeslissingEen lokaal signing report bewijst niet wie de Play-versie heeft ondertekend |
| 2. Certificaat | Wat je vergelijktDe uitvoer van apksigner verify --print-certs op de falende Play-APK tegenover wat je hebt geregistreerd |
BeslissingRegistreer elke benodigde ondertekenaar; laat oudere vermeldingen staan die nog geïnstalleerde gebruikers bedienen |
| 3. Uiteindelijk applicatie-ID | Wat je vergelijktDe applicationId van de gebouwde variant, inclusief achtervoegsels van flavors, tegenover het geregistreerde pakket | BeslissingDe namespace in je broncode telt niet |
| 4. Project en webclient | Wat je vergelijktHet project en het webclient-ID die je releasebuild en je backend echt gebruiken | BeslissingEen typfout hier breekt het inloggen, zelfs met correcte vingerafdrukken |
| 5. Provider en clients bestaan | Wat je vergelijktGoogle ingeschakeld als provider, plus de Android- en webclients die erachter zitten | BeslissingClaimt een ander project het paar, zie dan de opmerking over conflicten hieronder |
| 6. Soort fout | Wat je vergelijktNative code 10, een annulering door Credential Manager, een tokenafwijzing door de backend of een niet-overeenkomende browserredirect | BeslissingElk is een aparte tak; zie de fouttabel |
| 7. Releaseprobleem in het framework | Wat je vergelijktResource shrinking, de opgeloste bibliotheekversie en de initialisatie | BeslissingGebruik changelogs en bevestigde oplossingen, geen willekeurige upgrades of downgrades |
Rij 4 is geen theorie. In een Expo-geval dat in september 2026 werd gemeld, veranderde het toevoegen van vingerafdrukken niets; de oplossing was een typfout in het client-ID dat de backend accepteerde.
Meerdere ondertekeningscertificaten of geüpgradede sleutels
Eén app kan meer dan één geregistreerde ondertekeningsidentiteit nodig hebben. De huidige help van Google over Play App Signing beschrijft hybride ondertekening met drie app-ondertekeningssleutels en vraagt je de vingerafdrukken van elk ervan te registreren, en een app die zijn ondertekeningssleutel heeft geüpgraded, kan nog installaties hebben die met een oudere sleutel zijn ondertekend. Registreer de identiteiten die je installaties echt dragen en verwijder geen oudere vermeldingen die nog werken. Sleutelrotatie valt buiten dit artikel, en het is geen oplossing voor inlogproblemen.
Een ander project heeft dit pakket en deze SHA-1 al
De help van Firebase over conflicten zegt dat een paar van pakketnaam en SHA-1 “uniek moet zijn binnen alle Firebase- en Google Cloud-projecten”. Weigert de console je vingerafdruk omdat een ander project hem heeft, zoek dan uit welk project eigenaar is van die OAuth-client voordat je iets verwijdert. De support van Google kan helpen het conflict te vinden; verwijder geen actieve clients of projecten om op de gok een oplossing te vinden.
Is fout 10 hetzelfde als 12500, 12501 of canceled?
Nee. Lees de exacte fout en de bibliotheek die hem gaf voordat je elke mislukte inlogpoging als één probleem behandelt. De referentie van Google voor algemene statuscodes definieert DEVELOPER_ERROR = 10 als “The application is misconfigured.” De andere codes hieronder komen uit de historische play-services-auth 21.6.0 SDK van Google.
| Wat je ziet | Wat het betekent | Volgende stap |
|---|---|---|
ApiException: 10 of DEVELOPER_ERROR |
Wat het betekentConfiguratiefout in de app | Volgende stapVergelijk ondertekenaar, pakket, project en client-ID's |
12500 |
Wat het betekentSIGN_IN_FAILED: “A non-recoverable sign in failure occurred” (een onherstelbare inlogfout) |
Volgende stapLees de omliggende logs; behandel het niet als fout 10 |
12501 |
Wat het betekentSIGN_IN_CANCELLED: “Sign in action cancelled” (inlogactie geannuleerd) |
Volgende stapZoek uit of de gebruiker heeft geannuleerd en welke API de melding gaf |
Credential Manager of Flutter canceled |
Wat het betekentEen echte annulering of een configuratieprobleem | Volgende stapBekijk de details van de exception en de opzet; laat de gebruiker pas na je diagnose een nieuwe poging doen |
NoCredentialException |
Wat het betekentEr is geen credential teruggegeven; geen diagnose van het certificaat | Volgende stapControleer naast de registratie ook of er een account beschikbaar is en hoe de aanvraag is geconfigureerd |
| Google-token werkt, backend weigert het | Wat het betekentEen latere fase dan het ophalen van de Google-credential | Volgende stapControleer de audience en de client-ID's die je backend accepteert |
redirect_uri_mismatch |
Wat het betekentEen OAuth-redirect in de browser komt niet overeen met een geautoriseerde URI | Volgende stapHerstel de callbackconfiguratie voor die flow |
| “Item not found” bij de Play-link | Wat het betekentEen probleem met installatie of geschiktheid, niet met inloggen | Volgende stapVolg de controles voor een app die niet beschikbaar is |
Legacy Google Sign-In en Credential Manager
De release notes van Play services van Google vermelden dat de Google Sign-In-API's in play-services-base op 16 april 2024 als verouderd zijn gemarkeerd, en Google kondigde op 11 september 2024 de overstap naar Credential Manager aan. Daarna zijn de API's verwijderd uit play-services-auth 22.0.0 op 26 augustus 2026 en uit play-services-base 18.11.0 op 17 september 2026, met de opmerking “Removed the APIs related to Google Sign-in.” Dat is een wijziging in de SDK; het legt geen datum vast waarop al geïnstalleerde apps stoppen met werken. Nieuwe code en upgrades volgen het best de migratiegids van Google.
De twee API's falen op verschillende manieren. Credential Manager kent geen fout 10; de gids voor probleemoplossing waarschuwt dat “een groot aantal "annuleringen" eigenlijk op een verkeerde configuratie kan wijzen”. Een annulering kan dus een configuratiefout zijn of een echte annulering, en NoCredentialException is weer een ander signaal.
Controles voor Flutter, React Native, Expo en Unity
De native identiteitscontroles hierboven gelden voor elk framework, maar de opzet, de initialisatie en de buildconfiguratie verschillen. Volg de route voor jouw framework en de bibliotheekversie die je app echt gebruikt.
| Framework | Specifieke controles | Ga er niet van uit |
|---|---|---|
| Flutter | Specifieke controlesDe Android-implementatie, google_sign_in_android, is in 7.0.0 overgestapt op Credential Manager. Geef het webclient-ID door als serverClientId. De changelog voor 7.2.16 zegt “Keeps default_web_client_id resource from being stripped by resource shrinkers” (de resource default_web_client_id wordt niet meer door resource shrinkers verwijderd), wat telt bij fouten die alleen in de release optreden. |
Ga er niet van uitDat elk canceled-resultaat een SHA-probleem is, of dat een downgrade altijd helpt. |
| React Native | Specifieke controlesStel vast welke API van de bibliotheek je gebruikt, geef het webclient-ID door als webClientId en controleer de echte applicationId en de falende APK. De gids voor probleemoplossing noemt “Login does not work when downloading from the Play Store” en biedt een commando om de configuratie te controleren (hieronder). |
Ga er niet van uitDat een gesloten issue in de tracker bewijst dat iets is opgelost. |
| Expo | Specifieke controlesNative inloggen met Google vereist een development build of custom build; de Expo-gids zegt: “Deze bibliotheken kunnen niet in Expo Go worden gebruikt, omdat ze aangepaste native code vereisen.” Houd het ondertekeningscertificaat van EAS of je lokale certificaat gescheiden van het certificaat van Play App Signing. | Ga er niet van uitDat Expo Go de releaseflow nabootst, of dat opnieuw bouwen een verkeerd backendclient-ID oplost. |
| Unity | Specifieke controlesBepaal of je Firebase Authentication of Unity Authentication gebruikt, haal het Google-ID-token op via de ondersteunde platformintegratie en wissel het daarna in bij die backend (Unity-gids van Firebase). Het oude Unity-voorbeeld van Google voor inloggen is op 19 april 2026 gearchiveerd. | Ga er niet van uitDat inloggen via Play Games en inloggen met een Google-account dezelfde integratie zijn. |
Voor React Native bieden de beheerders van de bibliotheek een configuratiecontrole die je vanuit de hoofdmap van het project kunt uitvoeren:
npx @react-native-google-signin/config-doctorWat verandert er bij Supabase, Facebook, Apple of Auth0?
De provider en de inlogflow bepalen welk certificaat, welk client-ID of welke callback moet overeenkomen. Een Google-SHA-1 is het antwoord voor native inloggen met Google; voor andere providers kan het de verkeerde hash zijn, het verkeerde formaat of niet relevant.
| Provider of flow | Wat moet overeenkomen | Waar je het instelt |
|---|---|---|
| Native Google met Firebase | Wat moet overeenkomenGeïnstalleerd pakket en SHA-1, de webclient, Google ingeschakeld als provider | Waar je het insteltVingerafdrukken in de Project settings van Firebase, plus Authentication |
| Native Google met Supabase | Wat moet overeenkomenDe native Android-identiteit en het webclient-ID; de gids van Supabase zegt: “Het webclient-ID is het ID dat in je Android-app wordt gebruikt.” | Waar je het insteltAndroid- en webclients bij Google, daarna de instellingen van de Google-provider in Supabase |
| Browser-OAuth van Supabase | Wat moet overeenkomenDe webclient, de callback van Supabase en de terugkeerlink van je app | Waar je het insteltGeautoriseerde redirect-URI's bij Google en de redirectinstellingen van Supabase; een SHA-oplossing is hier niet van toepassing |
| Facebook op Android | Wat moet overeenkomenEen Base64-key-hash gemaakt van de SHA-1-bytes van het ondertekeningscertificaat, niet de hexwaarde met dubbele punten | Waar je het insteltApp-instellingen van Facebook, Android-key-hashes (route zoals beschreven in de Facebook-gids van Expo) |
| Webinlog van Apple op Android | Wat moet overeenkomenDe Services ID, het domein en de return-URL | Waar je het insteltWebconfiguratie van Sign in with Apple; niet het DEVELOPER_ERROR-mechanisme van Google |
| Apple via Firebase op Android | Wat moet overeenkomenDe Apple-opzet plus de SHA-1 van de app | Waar je het insteltApple-gids van Firebase: “Geef de SHA-1-vingerafdruk van je app op als je dat nog niet hebt gedaan.” |
| Auth0 op Android | Wat moet overeenkomenToegestane callback-URL's en het app-scheme; de identiteit voor app links waar die wordt gebruikt | Waar je het insteltApplicatie-instellingen van Auth0; de readme van de Android-SDK gebruikt SHA-256-key-hashes voor de opzet van app links |
| Telefoonauthenticatie van Firebase | Wat moet overeenkomenSHA-256 voor Play Integrity, SHA-1 voor de reCAPTCHA-fallback | Waar je het insteltTelefoonauthenticatie van Firebase: een andere flow dan inloggen met Google |
Verplaats het inloggen niet naar een WebView
Inloggen met Google via een ingesloten WebView laten lopen is geen workaround. Het OAuth 2.0-beleid van Google zegt dat ontwikkelaars “een Google OAuth 2.0-autorisatieverzoek niet naar een ingesloten user-agent mogen sturen”.
Wat moeten testers naar de ontwikkelaar sturen?
Een bruikbare melding noemt de falende Play-build en het exacte punt waarop het inloggen stopt. Een tester kan een OAuth-registratie niet herstellen door het opnieuw te proberen, dus zijn taak is bewijs leveren, niet volhouden. Kopieer dit sjabloon en stuur het naar je testers:
App en Play-testlink:
Geïnstalleerde appversie of build:
Geïnstalleerd via: gesloten test op Play / andere route
Apparaat en Android-versie:
Datum, tijd en tijdzone:
Exacte fouttekst of een geanonimiseerde screenshot:
Waar het stopte: vóór de accountkiezer / na het kiezen van een account / na terugkeer in de app
Kon de app met een andere inlogmethode wel worden geopend?
Resultaat en versie van de hertest:Vraag testers aangemeld te blijven voor de test terwijl je het oplost. Vraag nooit om wachtwoorden, OAuth-tokens, privésleutels of toegang tot Play Console. Vraag na je wijziging dezelfde tester een functie te openen waarvoor inloggen nodig is, daarna uit te loggen en opnieuw in te loggen, en de versie en het resultaat te noteren.
Heeft fout 10 invloed op mijn gesloten test of op productietoegang?
Een configuratiefout bij het inloggen staat los van de aanmelding. Fout 10 is geen afwijzingscode van het Play-beleid, en geen enkele regel van Google die we hebben gevonden zegt dat de aanmeldingsperiode van je testers erdoor opnieuw begint. De pagina met testvereisten van Google moedigt je aan de app tijdens de gesloten test te verbeteren, dus houd testers aangemeld en lever de oplossing via dezelfde gesloten testtrack. Dat is onze lezing van de gepubliceerde regels, geen belofte die elk geval dekt.
Kapot inloggen telt toch mee. Het functionaliteitsbeleid van Google Play zegt: “We staan geen apps toe die crashen, geforceerd sluiten, vastlopen of op een andere manier abnormaal functioneren”, en een inlogmuur houdt testers weg van de functies die ze juist moeten testen. Los het op voordat je productietoegang aanvraagt, en geef beoordelaars werkende inloggegevens. Is er al een beoordeling teruggekomen, zie dan de afwijzing wegens Broken Functionality.
Ter context: persoonlijke ontwikkelaarsaccounts die na 13 november 2023 zijn gemaakt, hebben minimaal 12 testers nodig die 14 dagen doorlopend aangemeld zijn voordat ze productietoegang voor die app aanvragen. Na je aanvraag zegt Google: “Meestal gebeurt dit binnen 7 dagen, maar het kan soms langer duren.” Ontbreken er testers in de telling, controleer dan hoe ze zijn uitgenodigd voordat je aan het inloggen sleutelt.
Echte testers nodig voor de 14 dagen?
Testers kunnen een OAuth-registratie niet herstellen, dus zorg eerst dat het inloggen werkt. Zodra dat zo is, levert PrimeTestLab 12+ echte testers die je Play-build op echte Android-telefoons installeren en de volle 14 dagen aangemeld blijven, vanaf $19.99 (plus 5% servicekosten). Krijg je na de volledige test geen productietoegang van Google, dan kies je een gratis hertest of een volledige terugbetaling. Bekijk hoe de gesloten test met 12 testers werkt.
Veelgestelde vragen
Waarom werkt Google Sign-In in debug, maar niet in de gesloten test?
Je debug-APK en de app die via Google Play is gedownload, kunnen met verschillende certificaten zijn ondertekend, dus door de debugvingerafdruk te registreren configureer je de Play-build niet. Begin met de SHA-1 van Play App Signing en controleer daarna de uiteindelijke pakketnaam van de releasebuild en de client-ID's die de app echt gebruikt.
Waar vind ik de SHA-1 van Play App Signing nu?
Open in Play Console de pagina Protected with Play van je app. De help van Google beschrijft Play Store distribution en daarna Go to Play app signing; andere actuele teksten van Google noemen dit Play Store protection en Manage Play app signing. Open het onderdeel App signing key certificate en kopieer de SHA-1, en controleer ook eventuele extra sleutels die voor je app worden getoond.
Heb ik SHA-1 of SHA-256 nodig voor Google Sign-In?
De Android-OAuth-client van Google herkent je app aan de pakketnaam en de SHA-1-vingerafdruk van het ondertekeningscertificaat, en SHA-256 vervangt dat veld niet. Andere diensten hebben eigen eisen: telefoonauthenticatie van Firebase gebruikt SHA-256 voor Play Integrity en SHA-1 voor de reCAPTCHA-fallback. Configureer elke dienst voor de flow die je app gebruikt.
Ik heb de SHA-1 al toegevoegd. Wat controleer ik daarna?
Ga na of hij hoort bij de app die via Play is geïnstalleerd, niet bij je upload- of debugsleutel. Vergelijk daarna het uiteindelijke applicatie-ID, het Firebase- of Cloud-project en het webclient-ID. Heeft je app meerdere ondertekeningscertificaten, controleer die dan ook. Een typfout in het client-ID dat de backend accepteert, kan het inloggen breken, zelfs als de vingerafdrukken kloppen.
Moet ik een nieuwe AAB uploaden nadat ik een vingerafdruk heb toegevoegd?
Niet per se. Ontwikkelaars melden dat een oplossing die alleen uit registratie in Firebase of Google Cloud bestond, werkte met de app die al was geïnstalleerd. Een gewijzigd client-ID, configuratiebestand, gewijzigde code of dependency moet testers via een nieuwe build bereiken. Ga na wat je hebt gewijzigd en controleer daarna de echte Play-installatie, in plaats van zonder diagnose steeds opnieuw te bouwen.
Hoe lang duurt het voordat een nieuwe vingerafdruk werkt?
Google noemt geen verwerkingstijd specifiek voor vingerafdrukken, en de threads van ontwikkelaars die we hebben bekeken, hebben er geen gemeten. Sla de juiste configuratie op en probeer het opnieuw. Faalt het nog steeds, controleer dan het geïnstalleerde certificaat en de clientinstellingen in plaats van een vast aantal uren te wachten, want wachten herstelt geen mismatch.
Waarom staat er canceled terwijl ik niet heb geannuleerd?
Sommige integraties van Credential Manager en van frameworks melden een configuratie- of autorisatieprobleem als annulering, al kan een annulering ook echt zijn. Noteer het type en de melding van de exception, bekijk de gids voor probleemoplossing van je framework en houd de huidige API gescheiden van de legacy status 12501 SIGN_IN_CANCELLED voordat je instellingen wijzigt.
Is het Android-client-ID het ID dat ik in serverClientId zet?
Nee. In de gedocumenteerde native Google-integraties is serverClientId of webClientId de OAuth-client van de webapplicatie die voor de tokenaanvraag wordt gebruikt. De Android-client registreert in plaats daarvan je pakket en je ondertekeningscertificaat. Configureer ze allebei en ga na of je backend de bedoelde audience van het token accepteert, in plaats van op de gok client-ID's te verwisselen.
Begint mijn gesloten test van 14 dagen opnieuw door fout 10?
Geen enkele regel van Google die we hebben gevonden zegt dat deze fout de aanmeldingsperiode opnieuw laat beginnen, en Google moedigt verbeteringen tijdens de gesloten test aan, dus houd testers aangemeld en herstel het via de bestaande track. Dat betekent niet dat de app klaar is: een inlogmuur kan nuttig testen blokkeren en een functionaliteitsprobleem achterlaten dat je moet oplossen voordat je je aanvraag indient.
Wat moet ik een tester vragen om te sturen?
Vraag om de geïnstalleerde versie, de Play-testlink, het apparaat en de Android-versie, de exacte fout en de stap waarop het inloggen stopt. Een geanonimiseerde screenshot of een korte opname helpt. Vraag na je oplossing dezelfde tester een functie te gebruiken waarvoor inloggen nodig is en daarna uit te loggen en opnieuw in te loggen, zonder inloggegevens te delen.
Samengevat
Samengevat
Google Sign-In fout 10 betekent dat de app verkeerd is geconfigureerd, en als alleen de Play-versie faalt, is het ondertekeningscertificaat het eerste wat je controleert. Kopieer de SHA-1 van de app-ondertekeningssleutel uit Protected with Play, registreer die met de uiteindelijke pakketnaam van de build in hetzelfde Firebase- of Google Cloud-project dat je app gebruikt, houd het webclient-ID in serverClientId en test de build die je testers hebben geïnstalleerd opnieuw, inclusief een tweede inlogpoging. Faalt het nog steeds, vergelijk dan het certificaat van de geïnstalleerde APK, het applicatie-ID en de client-ID's voordat je iets anders wijzigt.
Bronnen gecontroleerd op 16 oktober 2026
Menulabels in Play Console en Firebase zijn de feiten op deze pagina die het snelst veranderen. Komt een route hierboven niet meer overeen met je console, zoek Play App Signing dan onder Protected with Play, en de vingerafdrukken onder je Android-app in de Project settings van Firebase.