Kapalı Testte Google Sign-In Hata 10 Nasıl Çözülür

Bu yazının kapsamı tek bir hatadır: Google Play’in teslim ettiği kopyada bozulan yerel (native) Google girişi. Yazı bu hatayı benzer görünen diğer hatalardan ayırır, ardından framework’leri, diğer giriş sağlayıcılarını ve test kullanıcılarının neyi bildirmesi gerektiğini ele alır. Burada atıfta bulunulan her Google sayfası 16 Ekim 2026 tarihinde kontrol edildi ve topluluk bildirimleri ayrıca belirtildi. Kaynaklar sonda listelenmiştir.

Play derlemesinde Google Sign-In’i düzeltin

Test kullanıcılarınızın kurduğu uygulamayı, onun için kayıtlı paket adı ve imzalama SHA-1’i ile eşleştirin. Bu adımları sırayla uygulayın; Firebase ve Google Cloud yolları ardından gelir.

Play sertifikasını Firebase’e ekleyin

Play imzalama parmak izini eklemeden önce eşleşen Android uygulamasını seçin. Adımlar Firebase’in parmak izi yardımını ve Google ile giriş rehberini izler.

1. Firebase konsolunda uygulamanızın kullandığı projeyi açın, ardından Project settings > General bölümüne gidin.
2. Your apps altında, paket adı başarısız derlemeyle eşleşen Android uygulamasını seçin.
3. Add fingerprint seçeneğine tıklayın, Play uygulama imzalama SHA-1’ini yapıştırın ve kaydedin. Mevcut parmak izlerinin yerine koymak yerine onların yanına ekleyin.
4. Authentication > Sign-in method altında Google’ın etkin olduğunu doğrulayın.
5. Firebase sizden güncellenmiş bir google-services.json indirmenizi isterse projenizdeki dosyayı değiştirin. Firebase’e göre bu dosya “contains the OAuth client information required for Google sign-in” (Google ile giriş için gereken OAuth istemci bilgilerini içerir); dolayısıyla değişen bir dosya yeni bir derleme demektir. Dosyanın projesinin ve paketinin başarısız uygulamayla eşleştiğini kontrol edin.

SHA-256’yı yalnızca belirli bir Firebase hizmeti istediğinde ekleyin. Örneğin telefonla kimlik doğrulama, Play Integrity yolu için SHA-256 kullanır; Google Sign-In ise SHA-1’e dayanır.

Google Cloud’u Firebase olmadan yapılandırın

İki OAuth istemcisi iki farklı iş görür. Android istemcisi uygulamanızı kaydeder; Web istemci kimliği ise token isteğinizin kullandığı kimliktir.

1. İstemci kimliklerinizi oluşturan projeyi seçin, ardından Google Auth platform > Clients bölümünü açın (Google Cloud yardımı).
2. Yeni bir istemci oluşturmadan önce bu paket adı ve SHA-1 ile mevcut bir Android istemcisi olup olmadığına bakın.
3. Yoksa Create Client seçeneğini seçin, Application type değerini Android yapın, bir ad, paket adı ve Play uygulama imzalama SHA-1’ini girin, ardından Create deyin. Android formunda bir SHA-1 alanı vardır; SHA-256 oraya girilmez.
4. İhtiyacınız olan her paket ve sertifika çiftini kaydedin; örneğin debug, yerel release ve Play.
5. Token isteği için Web istemcisini yerinde bırakın ve uygulamanın içine asla bir istemci gizli anahtarı (client secret) koymayın.

Onarımı kanıtlayın

Tek bir başarılı giriş, sürümün düzeldiğini kanıtlamaz. Bu kontrol listesi bir Google kuralı değil, önerdiğimiz kabul testidir; son satır önemlidir, çünkü bir geliştiricinin girişi bir kez başarılı olmuş ama bir sonraki girişte yine başarısız olmuştu: tek bir kontrolün kaçıracağı bir oturum sorunu.

Giriş neden debug’da çalışıp kapalı testte başarısız oluyor?

Google Play üzerinden kurulan uygulamanın imzalayıcısı, yerelde kurduğunuz APK’nınkinden farklı olabilir. Google’ın istemci kimlik doğrulama rehberi şunu belirtir: “Android Studio automatically signs your app with a debug certificate.” (Android Studio uygulamanızı otomatik olarak bir debug sertifikasıyla imzalar.) Kendi derlediğiniz bir release, o varyant için hangi anahtar yapılandırıldıysa onu kullanır. Play App Signing ile yükleme anahtarınız yüklediğiniz paketi imzalar, Google ise test kullanıcılarınıza ulaşan APK’ları uygulama imzalama anahtarıyla imzalar.

Bu anahtarların rolleri farklıdır, ancak değerleri her zaman farklı değildir: kendi imzalama anahtarınızı sağlayabilirsiniz ve bazı kurulumlar iki rol için tek bir anahtar kullanır. Anahtar etiketlerini değil, gerçek parmak izlerini karşılaştırın.

Parmak izlerini kendiniz okuyun

Kendi makinenizdeki derlemeler için Gradle imzalama raporu her varyantın SHA-1 ve SHA-256 değerlerini yazdırır; keytool ise debug keystore’u doğrudan okur (istendiğinde keystore şifresini girin):

./gradlew signingReport

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

Yerel bir imzalama raporu, Play kopyasını neyin imzaladığını söylemez. Başarısız derlemenin kendisini kontrol etmek için onu kapalı testten bir cihaza kurun, adb ile çekin ve sertifikalarını apksigner ile yazdırın; Google bu aracı “information about the APK's signing certificates” (APK’nın imzalama sertifikalarına ilişkin bilgileri) gösteren araç olarak belgeler. Paket adını değiştirin ve ilk komutun yazdırdığı yolu kullanın:

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’i ekledim ama hâlâ başarısız oluyor

Başka ayarları değiştirmeden önce başarısız APK’nın sertifikasını, nihai uygulama kimliğini ve istemci kimliklerini karşılaştırın. Bu basamakları yukarıdan aşağıya izleyin; her satır bir katmanı eler.

4. satır teorik değil. Eylül 2026’da bildirilen bir Expo vakasında parmak izi eklemek hiçbir şeyi değiştirmedi; çözüm, backend’in kabul ettiği istemci kimliğindeki bir yazım hatasını düzeltmekti.

Birden fazla imzalama sertifikası veya yükseltilmiş anahtarlar

Tek bir uygulamanın birden fazla imzalama kimliğini kaydetmesi gerekebilir. Google’ın güncel Play App Signing yardım sayfası, üç uygulama imzalama anahtarıyla hibrit imzalamayı anlatır ve her birinin parmak izlerini kaydetmenizi ister; imzalama anahtarını yükseltmiş bir uygulamanın da hâlâ eski bir anahtarla imzalanmış kurulumları olabilir. Kurulumlarınızın gerçekte taşıdığı kimlikleri kaydedin ve hâlâ çalışan eski kayıtları silmeyin. Anahtar rotasyonu bu yazının kapsamı dışındadır ve bir giriş düzeltmesi değildir.

Bu paket ve SHA-1 zaten başka bir projeye ait

Firebase’in çakışma yardım sayfası, bir paket adı ve SHA-1 çiftinin “must be unique across all Firebase and Google Cloud projects” (tüm Firebase ve Google Cloud projelerinde benzersiz olması gerektiğini) belirtir. Konsol, parmak izini başka bir proje tuttuğu için reddediyorsa, herhangi bir şeyi silmeden önce o OAuth istemcisinin hangi projeye ait olduğunu bulun. Google desteği çakışmanın yerini bulmanıza yardımcı olabilir; tahminle ilerlemek için etkin istemcileri veya projeleri kaldırmayın.

Hata 10, 12500, 12501 veya canceled ile aynı mı?

Hayır. Her başarısız girişi tek bir sorun gibi ele almadan önce tam hatayı ve onu üreten kütüphaneyi okuyun. Google’ın ortak durum kodları referansı DEVELOPER_ERROR = 10 değerini “The application is misconfigured.” (Uygulama yanlış yapılandırılmış.) olarak tanımlar. Aşağıdaki diğer kodlar Google’ın eski play-services-auth 21.6.0 SDK’sından gelir.

Eski Google Sign-In ve Credential Manager

Google’ın Play services sürüm notları, Google Sign-In API’lerinin play-services-base içinde 16 Nisan 2024’te kullanımdan kaldırıldığını (deprecated) listeler; Google, Credential Manager’a geçişi 11 Eylül 2024’te duyurdu. API’ler daha sonra 26 Ağustos 2026’da play-services-auth 22.0.0’dan ve 17 Eylül 2026’da play-services-base 18.11.0’dan “Removed the APIs related to Google Sign-in.” (Google Sign-in ile ilgili API’ler kaldırıldı.) notuyla çıkarıldı. Bu bir SDK değişikliğidir; zaten kurulu uygulamalar için bir kapanış tarihi belirlemez. Yeni kod ve yükseltmeler Google’ın geçiş rehberini izlemelidir.

İki API farklı şekillerde başarısız olur. Credential Manager’da hata 10 yoktur; sorun giderme rehberi şu uyarıyı yapar: “A high volume of "cancellations" may actually indicate a misconfiguration.” (Çok sayıda "iptal" aslında bir yanlış yapılandırmaya işaret edebilir.) Yani bir iptal, bir yapılandırma hatası da olabilir gerçek bir iptal de; NoCredentialException ise yine farklı bir sinyaldir.

Flutter, React Native, Expo ve Unity kontrolleri

Yukarıdaki yerel kimlik kontrolleri her framework için geçerlidir, ancak kurulum, başlatma ve derleme yapılandırması farklılık gösterir. Framework’ünüze ait yolu ve uygulamanızın gerçekte çözümlediği kütüphane sürümünü kullanın.

React Native için kütüphane geliştiricileri, proje kök dizininden çalıştırabileceğiniz bir yapılandırma kontrolü sunar:

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

Supabase, Facebook, Apple veya Auth0 için ne değişir?

Hangi sertifikanın, istemci kimliğinin veya geri çağırmanın eşleşmesi gerektiğini sağlayıcı ve giriş akışı belirler. Yerel Google girişi için cevap bir Google SHA-1’idir; diğer sağlayıcılar için bu yanlış hash, yanlış biçim veya tamamen ilgisiz olabilir.

Test kullanıcıları geliştiriciye ne göndermeli?

Faydalı bir rapor, başarısız Play derlemesini ve girişin tam olarak durduğu noktayı belirtir. Bir test kullanıcısı tekrar deneyerek bir OAuth kaydını onaramaz; bu yüzden görev ısrar değil, kanıt toplamaktır. Bu şablonu kopyalayın ve test kullanıcılarınıza gönderin:

Uygulama ve Play test bağlantısı:
Kurulu uygulama sürümü veya derlemesi:
Kurulduğu yer: Play kapalı testi / başka bir yol
Cihaz ve Android sürümü:
Tarih, saat ve saat dilimi:
Tam hata metni veya hassas bilgileri gizlenmiş bir ekran görüntüsü:
Nerede durdu: hesap seçiciden önce / bir hesap seçtikten sonra / uygulamaya döndükten sonra
Başka bir giriş yöntemiyle uygulama açılabildi mi?
Yeniden test sonucu ve sürüm:

Siz sorunu düzeltirken test kullanıcılarından teste kayıtlı kalmalarını isteyin. Asla şifre, OAuth token’ı, özel anahtar veya Play Console erişimi istemeyin. Değişikliğinizden sonra aynı test kullanıcısından giriş gerektiren bir özelliği açmasını, ardından çıkış yapıp yeniden giriş yapmasını ve sürümü ve sonucu kaydetmesini isteyin.

Hata 10, kapalı testimi veya üretim erişimimi etkiler mi?

Bir giriş yapılandırma hatası, test kaydından ayrı bir konudur. Hata 10 bir Play politikası reddetme kodu değildir ve bulduğumuz hiçbir Google kuralı, bu hatanın test kullanıcılarınızın kayıt süresini sıfırladığını söylemiyor. Google’ın test şartları sayfası, kapalı test sırasında uygulamanızı iyileştirmenizi teşvik eder; bu yüzden test kullanıcılarını kayıtlı tutun ve düzeltmeyi aynı kapalı test kanalına gönderin. Bu, yayınlanmış kuralların bir yorumudur, her durumu kapsayan bir vaat değildir.

Bozuk giriş yine de önemlidir. Google Play’in işlevsellik politikası “We don’t allow apps that crash, force close, freeze, or otherwise function abnormally” (çöken, zorla kapanan, donan veya başka şekilde anormal çalışan uygulamalara izin vermiyoruz) der ve bir giriş duvarı, test kullanıcılarının test etmeleri gereken özelliklere ulaşmasını engeller. Üretim erişimi için başvurmadan önce sorunu düzeltin ve inceleme ekibine çalışan giriş bilgileri verin. Bir inceleme sonucu zaten geldiyse Broken Functionality reddine bakın.

Bağlam için: 13 Kasım 2023’ten sonra oluşturulan kişisel geliştirici hesaplarının, o uygulama için üretim erişimine başvurmadan önce aralıksız 14 gün boyunca teste kayıtlı en az 12 test kullanıcısına ihtiyacı vardır. Başvurduktan sonra Google’a göre “Review usually takes seven days or less, but can occasionally take longer.” (İnceleme genellikle 7 gün veya daha kısa sürer ancak bazen daha uzun sürebilir.) Test kullanıcıları sayımda eksik görünüyorsa, girişe dokunmadan önce nasıl davet edildiklerini kontrol edin.

Sıkça Sorulan Sorular

Sonuç

Play Console ve Firebase menü etiketleri bu sayfadaki en hızlı değişen bilgilerdir. Yukarıdaki bir yol artık konsolunuzla eşleşmiyorsa Play uygulama imzalamayı Protected with Play altında, parmak izlerini ise Firebase Project settings içinde Android uygulamanızın altında arayın.