Jak naprawić błąd 10 Google Sign-In w testach zamkniętych

Ten tekst dotyczy jednej awarii: natywnego logowania przez Google, które przestaje działać w kopii dostarczanej przez Google Play. Oddziela ją od innych, podobnie wyglądających błędów, a potem omawia frameworki, innych dostawców logowania i to, co powinni zgłaszać testerzy. Każdą cytowaną tu stronę Google sprawdziliśmy 16 października 2026 r., a zgłoszenia społeczności są wyraźnie oznaczone. Źródła znajdziesz na końcu.

Napraw Google Sign-In w wersji z Play

Dopasuj aplikację zainstalowaną przez testerów do zarejestrowanej dla niej nazwy pakietu i SHA-1 certyfikatu podpisywania. Wykonaj te kroki po kolei; ścieżki dla Firebase i Google Cloud znajdziesz poniżej.

Dodaj certyfikat z Play w Firebase

Zanim dodasz odcisk cyfrowy klucza podpisywania z Play, wybierz właściwą aplikację na Androida. Kroki opierają się na pomocy Firebase dotyczącej odcisków cyfrowych i jego przewodniku po logowaniu przez Google.

1. W konsoli Firebase otwórz projekt, którego używa Twoja aplikacja, a potem Project settings > General.
2. W sekcji Your apps wybierz aplikację na Androida, której nazwa pakietu zgadza się z wersją, która zawodzi.
3. Kliknij Add fingerprint, wklej SHA-1 klucza podpisywania aplikacji z Play i zapisz. Dodaj go obok istniejących odcisków, zamiast je zastępować.
4. W sekcji Authentication > Sign-in method upewnij się, że Google jest włączony.
5. Jeśli Firebase poprosi Cię o pobranie zaktualizowanego pliku google-services.json, podmień plik w projekcie. Według Firebase plik ten „zawiera informacje o kliencie OAuth wymagane do logowania przez Google”, więc zmieniony plik oznacza nową wersję. Sprawdź, czy projekt i pakiet w pliku zgadzają się z aplikacją, która zawodzi.

SHA-256 dodawaj tylko tam, gdzie prosi o niego konkretna usługa Firebase. Na przykład uwierzytelnianie przez telefon używa SHA-256 na ścieżce Play Integrity; samo Google Sign-In opiera się na SHA-1.

Konfiguracja w Google Cloud bez Firebase

Dwa klienty OAuth mają dwa różne zadania. Klient Androida rejestruje Twoją aplikację; identyfikator klienta internetowego to ten, którego używa Twoje żądanie tokena.

1. Wybierz projekt, który wydał Twoje identyfikatory klienta, a potem otwórz Google Auth platform > Clients (pomoc Google Cloud).
2. Zanim utworzysz kolejnego klienta Androida, poszukaj istniejącego z tą nazwą pakietu i tym SHA-1.
3. Jeśli go brakuje, wybierz Create Client, ustaw Application type na Android, wpisz nazwę, nazwę pakietu i SHA-1 klucza podpisywania aplikacji z Play, a potem kliknij Create. Formularz Androida ma pole na SHA-1; SHA-256 tam nie trafia.
4. Zarejestruj każdą potrzebną parę pakietu i certyfikatu, na przykład debug, lokalną wersję release i Play.
5. Klienta internetowego zostaw na miejscu dla żądania tokena i nigdy nie umieszczaj tajnego klucza klienta (client secret) w aplikacji.

Udowodnij, że naprawa działa

Jedno udane logowanie nie dowodzi, że wersja jest naprawiona. Ta lista kontrolna to nasz zalecany test akceptacyjny, a nie reguła Google; ostatni wiersz jest ważny, bo u jednego dewelopera logowanie raz przeszło, a przy kolejnym i tak zawiodło. To problem z sesją, którego pojedyncze sprawdzenie by nie wychwyciło.

Dlaczego logowanie działa w wersji debug, a zawodzi w teście zamkniętym?

Aplikacja zainstalowana przez Google Play może mieć innego sygnatariusza niż plik APK instalowany lokalnie. Przewodnik Google po uwierzytelnianiu klienta zauważa, że „Android Studio automatycznie podpisuje aplikację certyfikatem debugowania”. Wersja release, którą kompilujesz samodzielnie, używa klucza skonfigurowanego dla tego wariantu. Przy Play App Signing Twój klucz przesyłania podpisuje pakiet, który przesyłasz, a Google podpisuje pliki APK trafiające do testerów kluczem podpisywania aplikacji.

Te klucze pełnią różne role, ale nie zawsze mają różne wartości: możesz dostarczyć własny klucz podpisywania, a niektóre konfiguracje używają jednego klucza w dwóch rolach. Porównuj faktyczne odciski cyfrowe, a nie nazwy kluczy.

Odczytaj odciski cyfrowe samodzielnie

W przypadku wersji kompilowanych na Twoim komputerze raport podpisywania Gradle wypisuje SHA-1 i SHA-256 każdego wariantu, a keytool odczytuje bezpośrednio magazyn kluczy debug (gdy pojawi się prośba, wpisz hasło magazynu kluczy):

./gradlew signingReport

keytool -list -v -alias androiddebugkey -keystore ~/.android/debug.keystore

Lokalny raport podpisywania nie mówi, czym podpisano kopię z Play. Aby sprawdzić samą wersję, która zawodzi, zainstaluj ją z testu zamkniętego na urządzeniu, pobierz ją przez adb i wypisz jej certyfikaty za pomocą apksigner, który według dokumentacji Google pokazuje „informacje o certyfikatach podpisywania pliku APK”. Podmień nazwę pakietu i użyj ścieżki, którą wypisze pierwsze polecenie:

adb shell pm path com.example.app
adb pull /data/app/.../base.apk failing-play.apk
apksigner verify --print-certs failing-play.apk

SHA-1 jest dodany, a logowanie nadal nie działa

Zanim zmienisz kolejne ustawienia, porównaj certyfikat APK, który zawodzi, jego ostateczny identyfikator aplikacji i identyfikatory klienta. Przejdź tę drabinę od góry; każdy wiersz wyklucza jedną warstwę.

Wiersz 4 to nie teoria. W przypadku z Expo zgłoszonym we wrześniu 2026 r. dodanie odcisków cyfrowych niczego nie zmieniło; rozwiązaniem była poprawka literówki w identyfikatorze klienta akceptowanym przez backend.

Kilka certyfikatów podpisywania lub zmienione klucze

Jedna aplikacja może wymagać zarejestrowania więcej niż jednej tożsamości podpisywania. Aktualna pomoc dotycząca Play App Signing opisuje podpisywanie hybrydowe z trzema kluczami podpisywania aplikacji i prosi o zarejestrowanie odcisków cyfrowych każdego z nich, a aplikacja, która przeszła na nowy klucz podpisywania, nadal może mieć instalacje podpisane starszym. Zarejestruj tożsamości, które faktycznie mają Twoje instalacje, i nie usuwaj starszych wpisów, które nadal działają. Rotacja klucza wykracza poza zakres tego tekstu i nie jest sposobem na naprawę logowania.

Inny projekt ma już ten pakiet i SHA-1

Pomoc Firebase dotycząca konfliktów mówi, że para nazwy pakietu i SHA-1 „musi być unikalna we wszystkich projektach Firebase i Google Cloud”. Jeśli konsola odrzuca Twój odcisk cyfrowy, bo ma go inny projekt, zanim cokolwiek usuniesz, ustal, który projekt jest właścicielem tego klienta OAuth. Pomoc Google może pomóc zlokalizować konflikt; nie usuwaj aktywnych klientów ani projektów na chybił trafił.

Czy błąd 10 to to samo co 12500, 12501 lub canceled?

Nie. Zanim potraktujesz każde nieudane logowanie jako jeden problem, przeczytaj dokładny błąd i sprawdź, która biblioteka go zgłosiła. Dokumentacja wspólnych kodów stanu Google definiuje DEVELOPER_ERROR = 10 jako „Aplikacja jest nieprawidłowo skonfigurowana”. Pozostałe kody poniżej pochodzą z historycznego SDK play-services-auth 21.6.0 od Google.

Starsze Google Sign-In i Credential Manager

Informacje o wersjach usług Google Play podają wycofanie interfejsów API Google Sign-In w play-services-base 16 kwietnia 2024 r., a 11 września 2024 r. Google ogłosił przejście na Credential Manager. Następnie interfejsy te usunięto z play-services-auth 22.0.0 26 sierpnia 2026 r. i z play-services-base 18.11.0 17 września 2026 r., z adnotacją „Usunięto interfejsy API związane z Google Sign-in”. To zmiana w SDK; nie wyznacza ona daty wyłączenia dla aplikacji, które są już zainstalowane. Nowy kod i aktualizacje powinny opierać się na przewodniku po migracji od Google.

Oba interfejsy API zawodzą w różny sposób. Credential Manager nie ma błędu 10; jego przewodnik rozwiązywania problemów ostrzega, że „duża liczba ‚anulowań’ może w rzeczywistości wskazywać na błędną konfigurację”. Anulowanie może więc być błędem konfiguracji albo prawdziwym anulowaniem, a NoCredentialException to jeszcze inny sygnał.

Kontrole dla Fluttera, React Native, Expo i Unity

Opisane wyżej kontrole tożsamości natywnej aplikacji dotyczą każdego frameworka, ale konfiguracja, inicjalizacja i ustawienia kompilacji się różnią. Korzystaj ze ścieżki dla swojego frameworka i z wersji biblioteki, której Twoja aplikacja faktycznie używa.

W React Native opiekunowie biblioteki udostępniają narzędzie do sprawdzania konfiguracji, które uruchomisz z katalogu głównego projektu:

npx @react-native-google-signin/config-doctor

Co się zmienia w przypadku Supabase, Facebooka, Apple lub Auth0?

To dostawca i przepływ logowania decydują, który certyfikat, identyfikator klienta lub wywołanie zwrotne musi się zgadzać. SHA-1 Google to odpowiedź dla natywnego logowania przez Google; u innych dostawców może to być niewłaściwy skrót, niewłaściwy format albo coś bez znaczenia.

Co testerzy powinni przesłać deweloperowi?

Przydatne zgłoszenie wskazuje wersję z Play, która zawodzi, i dokładny moment, w którym logowanie się zatrzymuje. Tester nie naprawi rejestracji OAuth ponownymi próbami, więc jego zadaniem są dowody, a nie wytrwałość. Skopiuj ten szablon i wyślij go swoim testerom:

Aplikacja i link do testów w Play:
Zainstalowana wersja lub kompilacja aplikacji:
Źródło instalacji: test zamknięty w Play / inna droga
Urządzenie i wersja Androida:
Data, godzina i strefa czasowa:
Dokładna treść błędu lub zrzut ekranu z zamazanymi danymi:
Gdzie się zatrzymało: przed wyborem konta / po wybraniu konta / po powrocie do aplikacji
Czy inną metodą logowania dało się otworzyć aplikację?
Wynik ponownego testu i wersja:

Poproś testerów, żeby na czas naprawy nadal uczestniczyli w teście. Nigdy nie proś o hasła, tokeny OAuth, klucze prywatne ani dostęp do Play Console. Po wprowadzeniu zmiany poproś tego samego testera, żeby otworzył funkcję wymagającą zalogowania, potem wylogował się i zalogował ponownie, a także zapisał wersję i wynik.

Czy błąd 10 wpływa na mój test zamknięty lub dostęp do wersji produkcyjnej?

Błąd konfiguracji logowania to coś innego niż udział testerów w teście. Błąd 10 nie jest kodem odrzucenia za naruszenie zasad Play i nie znaleźliśmy żadnej reguły Google, według której zerowałby okres uczestnictwa Twoich testerów. Strona z wymaganiami dotyczącymi testowania zachęca do ulepszania aplikacji w trakcie testów zamkniętych, więc niech testerzy nadal uczestniczą w teście, a poprawkę opublikuj na tej samej ścieżce zamkniętej. To nasza interpretacja opublikowanych zasad, a nie obietnica obejmująca każdy przypadek.

Niedziałające logowanie nadal ma znaczenie. Zasady Google Play dotyczące funkcjonalności mówią: „Nie zezwalamy na aplikacje, które ulegają awarii, wymuszają zamknięcie, zawieszają się lub w inny sposób działają nieprawidłowo”, a ekran logowania, przez który nie da się przejść, nie pozwala testerom dotrzeć do funkcji, które mają testować. Napraw to, zanim poprosisz o dostęp do wersji produkcyjnej, i przekaż weryfikatorom działające dane logowania. Jeśli wynik weryfikacji już przyszedł, zobacz odrzucenie z powodu niedziałającej funkcjonalności (Broken Functionality).

Dla kontekstu: osobiste konta dewelopera utworzone po 13 listopada 2023 r. potrzebują co najmniej 12 testerów, którzy nieprzerwanie uczestniczą w teście przez 14 dni, zanim poproszą o dostęp do wersji produkcyjnej dla danej aplikacji. Po złożeniu prośby, jak podaje Google, „Zwykle zajmuje to 7 dni lub mniej, ale w niektórych przypadkach może potrwać dłużej”. Jeśli brakuje testerów w liczniku, zanim zaczniesz zmieniać logowanie, sprawdź, jak zostali zaproszeni.

Najczęściej zadawane pytania

Podsumowanie

Etykiety menu w Play Console i Firebase to najszybciej zmieniające się informacje na tej stronie. Jeśli opisana wyżej ścieżka nie zgadza się już z Twoją konsolą, szukaj podpisywania aplikacji w Play w sekcji Protected with Play, a odcisków cyfrowych przy swojej aplikacji na Androida w Project settings w Firebase.