Jawaban Singkat
Error 10 Google Sign-In, DEVELOPER_ERROR, berarti aplikasi Android salah dikonfigurasi. Jika login berhasil secara lokal tetapi gagal di pengujian tertutup Play, pastikan SHA-1 penandatanganan aplikasi yang diinstal dari Play dan nama paket finalnya terdaftar di project Firebase atau Google Cloud yang benar, dan bahwa serverClientId atau webClientId yang dipakai adalah client ID aplikasi Web, bukan client ID Android. Lalu uji ulang dengan build yang diinstal dari Google Play.
Pilih penyiapan Anda
Sudah menambahkan SHA-1? Lihat apa yang perlu diperiksa berikutnya.
Cakupan artikel ini adalah satu kegagalan: login Google native yang rusak di salinan yang dikirim oleh Google Play. Artikel ini memisahkannya dari error lain yang tampak serupa, lalu membahas framework, penyedia login lain, dan apa yang harus dilaporkan penguji. Setiap halaman Google yang dikutip di sini diperiksa pada 16 Oktober 2026, dan laporan komunitas diberi label sebagai laporan komunitas. Daftar sumber ada di bagian akhir.
Di halaman ini
Perbaiki Google Sign-In di build Play
Cocokkan aplikasi yang diinstal penguji Anda dengan nama paket dan SHA-1 penandatanganan yang terdaftar untuknya. Kerjakan langkah-langkah ini secara berurutan; rute Firebase dan Google Cloud ada setelahnya.
Pastikan salinan mana yang gagal
Pastikan penguji menginstal aplikasi dari pengujian tertutup Anda di Google Play, dan catat versi yang mereka miliki. Lalu catat application ID final dari build tersebut. Panduan build Android menyebutkan bahwa application ID Anda ditentukan oleh properti applicationId, yang bisa berbeda dari namespace kode sumber Anda atau mendapat akhiran di build flavor. Jika penguji sama sekali tidak bisa menginstal aplikasi, itu masalah yang berbeda: lihat mengapa aplikasi tidak tersedia untuk penguji.
Buka Play app signing
Di Play Console, buka aplikasi lalu masuk ke Protected with Play. Google memindahkan penandatanganan aplikasi ke sana pada Mei 2026, dan bantuan resminya menyebut langkah berikutnya dengan dua cara (lihat tabel di bawah). Kedua rute berakhir di halaman yang sama.
| Rute sesuai tulisan Google | Tempat Google menggunakannya | Apa yang dibuka di sana |
|---|---|---|
| Protected with Play > Play Store distribution > Go to Play app signing | Tempat Google menggunakannyaBantuan Play Console, Use Play App Signing, bagian pendaftaran API | Apa yang dibuka di sanaApp signing key certificate, lalu nilai SHA-1 |
| Protected with Play > Play Store protection > Manage Play app signing | Tempat Google menggunakannyaCatatan pembaruan Mei 2026 Google Play dan bagian lain di halaman bantuan yang sama | Apa yang dibuka di sanaHalaman yang sama; label menu bisa berbeda antar akun |
Salin SHA-1 kunci penandatanganan aplikasi
Buka bagian App signing key certificate (sertifikat kunci penandatanganan aplikasi), bukan sertifikat kunci upload, lalu salin SHA-1-nya. Jika Play mencantumkan lebih dari satu kunci penandatanganan untuk aplikasi Anda, daftarkan setiap sidik jari yang relevan (lihat beberapa sertifikat penandatanganan). Pertahankan sidik jari debug dan lokal yang sudah ada, lalu tambahkan sidik jari Play di sampingnya. Jangan merotasi kunci penandatanganan Anda untuk memperbaiki login.
Daftarkan di tempat aplikasi Anda melakukan login
Gunakan rute Firebase atau rute Google Cloud, sesuai yang dipakai aplikasi Anda, dan gunakan project yang sama dengan yang menerbitkan client ID di dalam aplikasi Anda.
Uji ulang build Play yang terinstal
Jika Anda hanya mengubah pendaftaran di Firebase atau Google Cloud, coba lagi dengan salinan yang sudah terinstal dari Play sebelum Anda membuat build apa pun; para developer melaporkan bahwa perbaikan yang hanya menyangkut pendaftaran berhasil tanpa upload baru. Jika Anda mengubah konfigurasi yang dibundel, client ID, kode, atau dependensi, upload build baru ke jalur tertutup yang sama dan uji build tersebut. Google tidak memublikasikan waktu pasti bagi sidik jari baru untuk mulai berlaku, jadi uji ulang alih-alih menunggu sejumlah jam tertentu.
Tambahkan sertifikat Play di Firebase
Pilih aplikasi Android yang sesuai sebelum Anda menambahkan sidik jari penandatanganan Play-nya. Langkah-langkah ini mengikuti bantuan sidik jari Firebase dan panduan login Google dari Firebase.
- Di Firebase console, buka project yang digunakan aplikasi Anda, lalu Project settings > General.
- Di bawah Your apps, pilih aplikasi Android yang nama paketnya cocok dengan build yang gagal.
- Klik Add fingerprint, tempel SHA-1 Play app signing, lalu simpan. Tambahkan di samping sidik jari yang sudah ada, jangan menggantinya.
- Di bawah Authentication > Sign-in method, pastikan Google sudah diaktifkan.
- Jika Firebase meminta Anda mengunduh
google-services.jsonyang diperbarui, ganti file tersebut di project Anda. Firebase menyatakan bahwa file ini “contains the OAuth client information required for Google sign-in” (berisi informasi client OAuth yang diperlukan untuk login Google), jadi file yang berubah berarti build baru. Pastikan project dan paket di dalamnya cocok dengan aplikasi yang gagal.
Tambahkan SHA-256 hanya jika layanan Firebase tertentu memintanya. Phone authentication, misalnya, menggunakan SHA-256 untuk jalur Play Integrity-nya; Google Sign-In sendiri mengandalkan SHA-1.
Konfigurasikan Google Cloud tanpa Firebase
Dua client OAuth menjalankan dua tugas yang berbeda. Client Android mendaftarkan aplikasi Anda; client ID Web adalah yang dipakai oleh permintaan token Anda.
| Jenis client | Isinya | Tempat Anda menggunakannya |
|---|---|---|
| Android | IsinyaNama paket Anda dan SHA-1 dari sertifikat penandatanganan | Tempat Anda menggunakannyaMendaftarkan identitas aplikasi native. Anda tidak menempelkan client ID ini ke serverClientId. |
| Aplikasi web | IsinyaClient ID Web | Tempat Anda menggunakannyaserverClientId atau webClientId dalam permintaan token Anda, serta audience yang diterima backend Anda. Codelab Sign in with Google dari Google menyebutnya berfungsi “as the backend client for the Google Sign-in service” (sebagai client backend untuk layanan Google Sign-in). |
- Pilih project yang menerbitkan client ID Anda, lalu buka Google Auth platform > Clients (bantuan Google Cloud).
- Cari client Android yang sudah ada dengan nama paket dan SHA-1 ini sebelum Anda membuat yang lain.
- Jika belum ada, pilih Create Client, atur Application type ke Android, masukkan nama, nama paket, dan SHA-1 Play app signing, lalu Create. Formulir Android memiliki kolom SHA-1; SHA-256 tidak dimasukkan ke sana.
- Daftarkan setiap pasangan paket dan sertifikat yang Anda perlukan, misalnya debug, rilis lokal, dan Play.
- Biarkan client Web tetap ada untuk permintaan token, dan jangan pernah menaruh client secret di dalam aplikasi.
Buktikan perbaikannya
Satu login yang berhasil tidak membuktikan bahwa rilis sudah diperbaiki. Checklist ini adalah uji penerimaan yang kami rekomendasikan, bukan aturan Google; baris terakhir penting karena login seorang developer pernah lolos sekali lalu tetap gagal pada login berikutnya, masalah sesi yang akan terlewat jika hanya diperiksa sekali.
| Pemeriksaan | Bukti lolos | Jika gagal |
|---|---|---|
| Aplikasi dan versi yang benar | Bukti lolosPenguji mengonfirmasi instalasi Play dan build yang dimaksud | Jika gagalSelesaikan dulu masalah rilis atau pengiriman jalur |
| Login pertama | Bukti lolosMemilih akun mengembalikan pengguna ke aplikasi dalam keadaan sudah login | Jika gagalCatat exception persisnya dan gunakan tabel error di bawah |
| Fitur yang dilindungi | Bukti lolosPenguji dapat memakai fitur yang memerlukan login | Jika gagalPeriksa penanganan token di aplikasi dan backend |
| Logout lalu login kembali | Bukti lolosLogin kedua berhasil tanpa menginstal ulang | Jika gagalSelidiki penanganan sesi dan logout penyedia |
| Perangkat yang sebelumnya terdampak | Bukti lolosPenguji dan perangkat yang sama kini berhasil | Jika gagalBandingkan sertifikat, OS, akun, dan build yang sebenarnya |
| Kesinambungan pengujian | Bukti lolosPenguji masih ikut serta dan Anda sudah mencatat perbaikannya | Jika gagalPerbaiki keikutsertaan secara terpisah dari login |
Mengapa login berhasil di debug tetapi gagal di pengujian tertutup?
Aplikasi yang diinstal melalui Google Play bisa memiliki penanda tangan yang berbeda dari APK yang Anda instal secara lokal. Panduan autentikasi client dari Google mencatat bahwa “Android Studio automatically signs your app with a debug certificate” (Android Studio otomatis menandatangani aplikasi Anda dengan sertifikat debug). Rilis yang Anda build sendiri menggunakan kunci apa pun yang dikonfigurasi untuk varian tersebut. Dengan Play App Signing, kunci upload Anda menandatangani bundle yang Anda upload, dan Google menandatangani APK yang diterima penguji Anda dengan kunci penandatanganan aplikasi.
Kunci-kunci tersebut memiliki peran berbeda, tetapi nilainya tidak selalu berbeda: Anda dapat menyediakan kunci penandatanganan sendiri, dan beberapa penyiapan memakai satu kunci untuk dua peran. Bandingkan sidik jari yang sebenarnya, bukan label kuncinya.
| Salinan yang terinstal | Sertifikat yang diperiksa | Tindakan pertama |
|---|---|---|
| Instalasi Play dari jalur internal, tertutup, terbuka, atau produksi dengan Play App Signing | Sertifikat yang diperiksaSatu atau beberapa sertifikat Play app signing, yang ada di bawah Protected with Play | Tindakan pertamaDaftarkan setiap SHA-1 Play yang relevan |
| Menjalankan debug dari Android Studio | Sertifikat yang diperiksaSertifikat debug di komputer tersebut | Tindakan pertamaDaftarkan SHA-1 tersebut untuk application ID yang sesuai |
| APK rilis yang di-build di komputer Anda | Sertifikat yang diperiksaSertifikat yang dikonfigurasi untuk varian rilis tersebut | Tindakan pertamaJangan berasumsi bahwa “rilis” berarti penanda tangan Google |
| Link berbagi aplikasi internal | Sertifikat yang diperiksaSertifikat uji milik berbagi aplikasi internal | Tindakan pertamaDaftarkan secara terpisah jika penguji memakai rute tersebut |
Berbagi aplikasi internal bukan pengujian internal
Bantuan berbagi aplikasi internal dari Google menyatakan “Every APK is resigned with this test certificate” (setiap APK ditandatangani ulang dengan sertifikat uji ini). Temukan di Test and release > Internal testing > Internal app sharing > Uploaders and testers > Internal test certificate. Jalur pengujian internal dan pengujian tertutup memakai kunci Play app signing Anda.
Baca sendiri sidik jarinya
Untuk build di komputer Anda, signing report Gradle mencetak SHA-1 dan SHA-256 dari setiap varian, dan keytool membaca keystore debug secara langsung (masukkan kata sandi keystore saat diminta):
./gradlew signingReport
keytool -list -v -alias androiddebugkey -keystore ~/.android/debug.keystoreSigning report lokal tidak memberi tahu Anda apa yang menandatangani salinan dari Play. Untuk memeriksa build yang gagal itu sendiri, instal dari pengujian tertutup di sebuah perangkat, tarik dengan adb, lalu cetak sertifikatnya dengan apksigner, yang didokumentasikan Google sebagai alat untuk menampilkan “information about the APK's signing certificates” (informasi tentang sertifikat penandatanganan APK). Ganti nama paketnya dan gunakan path yang dicetak oleh perintah pertama:
adb shell pm path com.example.app
adb pull /data/app/.../base.apk failing-play.apk
apksigner verify --print-certs failing-play.apkSaya sudah menambahkan SHA-1 dan masih gagal
Bandingkan sertifikat APK yang gagal, application ID finalnya, dan client ID sebelum mengubah pengaturan lain. Telusuri tangga diagnosis ini dari atas ke bawah; setiap baris menyingkirkan satu lapisan.
| Pemeriksaan | Apa yang dibandingkan | Keputusan |
|---|---|---|
| 1. Salinan terinstal dan jalur | Apa yang dibandingkanInstalasi Play penguji yang sebenarnya dibandingkan dengan versi yang ingin Anda uji | KeputusanSigning report lokal bukan bukti penanda tangan Play |
| 2. Sertifikat | Apa yang dibandingkanOutput apksigner verify --print-certs pada APK Play yang gagal dibandingkan dengan yang Anda daftarkan |
KeputusanDaftarkan setiap penanda tangan yang diperlukan; pertahankan entri lama yang masih melayani pengguna yang sudah menginstal |
| 3. Application ID final | Apa yang dibandingkanapplicationId dari varian yang di-build, termasuk akhiran flavor, dibandingkan dengan paket yang terdaftar | KeputusanNamespace kode sumber tidak dihitung |
| 4. Project dan client Web | Apa yang dibandingkanProject dan client ID Web yang benar-benar dipakai build rilis dan backend Anda | KeputusanSalah ketik di sini merusak login meskipun sidik jarinya benar |
| 5. Penyedia dan client tersedia | Apa yang dibandingkanGoogle aktif sebagai penyedia, beserta client Android dan Web di belakangnya | KeputusanJika project lain mengklaim pasangan tersebut, lihat catatan konflik di bawah |
| 6. Kelompok error | Apa yang dibandingkanKode native 10, pembatalan Credential Manager, penolakan token oleh backend, atau ketidakcocokan redirect browser | KeputusanMasing-masing adalah cabang terpisah; lihat tabel error |
| 7. Masalah rilis framework | Apa yang dibandingkanResource shrinking, versi library yang ter-resolve, dan inisialisasi | KeputusanGunakan changelog dan perbaikan yang sudah terkonfirmasi, bukan upgrade atau downgrade acak |
Baris 4 bukan sekadar teori. Dalam sebuah kasus Expo yang dilaporkan pada September 2026, menambahkan sidik jari tidak mengubah apa pun; perbaikannya adalah salah ketik pada client ID yang diterima backend.
Beberapa sertifikat penandatanganan atau kunci yang di-upgrade
Satu aplikasi mungkin perlu mendaftarkan lebih dari satu identitas penandatanganan. Bantuan Play App Signing Google saat ini menjelaskan hybrid signing dengan tiga kunci penandatanganan aplikasi dan meminta Anda mendaftarkan sidik jari masing-masing, dan aplikasi yang meng-upgrade kunci penandatanganannya masih bisa memiliki instalasi yang ditandatangani oleh kunci lama. Daftarkan identitas yang benar-benar dibawa oleh instalasi Anda dan jangan hapus entri lama yang masih berfungsi. Rotasi kunci berada di luar cakupan artikel ini, dan bukan perbaikan untuk login.
Project lain sudah memiliki paket dan SHA-1 ini
Bantuan konflik Firebase menyatakan bahwa pasangan nama paket dan SHA-1 “must be unique across all Firebase and Google Cloud projects” (harus unik di seluruh project Firebase dan Google Cloud). Jika console menolak sidik jari Anda karena project lain memilikinya, cari tahu project mana yang memiliki client OAuth tersebut sebelum Anda menghapus apa pun. Dukungan Google dapat membantu menemukan konfliknya; jangan menghapus client atau project yang aktif hanya untuk menebak-nebak jalan keluarnya.
Apakah error 10 sama dengan 12500, 12501, atau canceled?
Tidak. Baca error persisnya dan library yang menghasilkannya sebelum memperlakukan setiap login yang gagal sebagai satu masalah yang sama. Referensi kode status umum Google mendefinisikan DEVELOPER_ERROR = 10 sebagai “The application is misconfigured” (aplikasi salah dikonfigurasi). Kode-kode lain di bawah berasal dari SDK play-services-auth 21.6.0 historis milik Google.
| Yang Anda lihat | Artinya | Langkah berikutnya |
|---|---|---|
ApiException: 10 atau DEVELOPER_ERROR |
ArtinyaError konfigurasi aplikasi | Langkah berikutnyaBandingkan penanda tangan, paket, project, dan client ID |
12500 |
ArtinyaSIGN_IN_FAILED: “A non-recoverable sign in failure occurred” (terjadi kegagalan login yang tidak dapat dipulihkan) |
Langkah berikutnyaBaca log di sekitarnya; jangan perlakukan sebagai error 10 |
12501 |
ArtinyaSIGN_IN_CANCELLED: “Sign in action cancelled” (tindakan login dibatalkan) |
Langkah berikutnyaCari tahu apakah pengguna membatalkannya dan API mana yang menghasilkannya |
canceled dari Credential Manager atau Flutter |
ArtinyaPembatalan sungguhan atau masalah konfigurasi | Langkah berikutnyaPeriksa detail exception dan penyiapannya; biarkan pengguna memulai percobaan baru setelah Anda mendiagnosisnya |
NoCredentialException |
ArtinyaTidak ada kredensial yang dikembalikan; bukan diagnosis sertifikat | Langkah berikutnyaPeriksa ketersediaan akun dan konfigurasi permintaan, selain pendaftarannya |
| Token Google berhasil, backend menolaknya | ArtinyaTahap yang lebih lanjut daripada mendapatkan kredensial Google | Langkah berikutnyaPeriksa audience dan client ID yang diterima backend Anda |
redirect_uri_mismatch |
ArtinyaRedirect OAuth browser tidak cocok dengan URI yang diotorisasi | Langkah berikutnyaPerbaiki konfigurasi callback untuk alur tersebut |
| “Item not found” (item tidak ditemukan) pada link Play | ArtinyaMasalah instalasi atau kelayakan, bukan login | Langkah berikutnyaIkuti pemeriksaan aplikasi tidak tersedia |
Google Sign-In lama dan Credential Manager
Catatan rilis Play services dari Google mencantumkan penghentian (deprecation) API Google Sign-In di play-services-base pada 16 April 2024, dan Google mengumumkan peralihan ke Credential Manager pada 11 September 2024. API tersebut kemudian dihapus dari play-services-auth 22.0.0 pada 26 Agustus 2026 dan dari play-services-base 18.11.0 pada 17 September 2026, dengan catatan “Removed the APIs related to Google Sign-in” (menghapus API yang terkait dengan Google Sign-in). Itu adalah perubahan SDK; hal ini tidak menetapkan tanggal penghentian layanan bagi aplikasi yang sudah terinstal. Kode baru dan upgrade sebaiknya mengikuti panduan migrasi Google.
Kedua API gagal dengan cara yang berbeda. Credential Manager tidak memiliki error 10; panduan pemecahan masalahnya memperingatkan bahwa “A high volume of "cancellations" may actually indicate a misconfiguration” (banyaknya "pembatalan" sebenarnya bisa menandakan kesalahan konfigurasi). Jadi pembatalan bisa berupa kesalahan konfigurasi atau pembatalan sungguhan, dan NoCredentialException adalah sinyal yang berbeda lagi.
Pemeriksaan untuk Flutter, React Native, Expo, dan Unity
Pemeriksaan identitas native di atas berlaku untuk setiap framework, tetapi penyiapan, inisialisasi, dan konfigurasi build-nya berbeda. Gunakan rute untuk framework Anda dan versi library yang benar-benar di-resolve oleh aplikasi Anda.
| Framework | Pemeriksaan khusus | Jangan berasumsi |
|---|---|---|
| Flutter | Pemeriksaan khususImplementasi Android, google_sign_in_android, beralih ke Credential Manager di versi 7.0.0. Teruskan client ID Web sebagai serverClientId. Changelog-nya untuk versi 7.2.16 menyebutkan “Keeps default_web_client_id resource from being stripped by resource shrinkers” (mencegah resource default_web_client_id dihapus oleh resource shrinker), yang penting untuk kegagalan yang hanya terjadi di rilis. |
Jangan berasumsiBahwa setiap hasil canceled adalah masalah SHA, atau bahwa downgrade adalah perbaikan universal. |
| React Native | Pemeriksaan khususKenali API library mana yang Anda gunakan, teruskan client ID Web sebagai webClientId, lalu periksa applicationId yang sebenarnya dan APK yang gagal. Panduan pemecahan masalah-nya mencantumkan “Login does not work when downloading from the Play Store” (login tidak berfungsi saat diunduh dari Play Store) dan menyediakan perintah pemeriksaan konfigurasi (di bawah). |
Jangan berasumsiBahwa issue yang ditutup di tracker membuktikan adanya perbaikan. |
| Expo | Pemeriksaan khususLogin Google native memerlukan development build atau custom build; panduan Expo menyatakan “These libraries can't be used in Expo Go because they require custom native code” (library ini tidak dapat digunakan di Expo Go karena memerlukan kode native kustom). Pisahkan sertifikat penandatanganan EAS atau lokal dari sertifikat Play app signing. | Jangan berasumsiBahwa Expo Go mereproduksi alur rilis, atau bahwa build ulang memperbaiki client ID backend yang salah. |
| Unity | Pemeriksaan khususTentukan apakah Anda memakai Firebase Authentication atau Unity Authentication, dapatkan Google ID token melalui integrasi platform yang didukung, lalu tukarkan dengan backend tersebut (panduan Unity dari Firebase). Sampel login Unity lama milik Google diarsipkan pada 19 April 2026. | Jangan berasumsiBahwa login Play Games dan login akun Google adalah integrasi yang sama. |
Untuk React Native, pengelola library menyediakan pemeriksaan konfigurasi yang dapat Anda jalankan dari root project:
npx @react-native-google-signin/config-doctorApa yang berbeda untuk Supabase, Facebook, Apple, atau Auth0?
Penyedia dan alur login menentukan sertifikat, client ID, atau callback mana yang harus cocok. SHA-1 Google adalah jawabannya untuk login Google native; untuk penyedia lain, SHA-1 bisa jadi hash yang salah, format yang salah, atau tidak relevan.
| Penyedia atau alur | Apa yang harus cocok | Tempat mengaturnya |
|---|---|---|
| Google native dengan Firebase | Apa yang harus cocokPaket terinstal dan SHA-1, client Web, Google aktif sebagai penyedia | Tempat mengaturnyaSidik jari di Project settings Firebase, ditambah Authentication |
| Google native dengan Supabase | Apa yang harus cocokIdentitas Android native dan client ID Web; panduan Supabase menyatakan “The Web client ID is the one used in your Android app” (client ID Web adalah yang digunakan di aplikasi Android Anda). | Tempat mengaturnyaClient Android dan Web Google, lalu pengaturan penyedia Google di Supabase |
| OAuth browser Supabase | Apa yang harus cocokClient Web, callback Supabase, dan link kembali aplikasi Anda | Tempat mengaturnyaAuthorized redirect URIs di Google dan pengaturan redirect Supabase; perbaikan SHA tidak berlaku |
| Facebook di Android | Apa yang harus cocokKey hash Base64 yang dibuat dari byte SHA-1 sertifikat penandatanganan, bukan hex yang dipisahkan titik dua | Tempat mengaturnyaPengaturan aplikasi Facebook, Android key hashes (rute sesuai dokumentasi di panduan Facebook dari Expo) |
| Login web Apple di Android | Apa yang harus cocokServices ID, domain, dan URL kembali | Tempat mengaturnyaKonfigurasi web Sign in with Apple dari Apple; bukan mekanisme DEVELOPER_ERROR milik Google |
| Apple melalui Firebase di Android | Apa yang harus cocokPenyiapan Apple ditambah SHA-1 aplikasi | Tempat mengaturnyaPanduan Apple dari Firebase: “Specify your app's SHA-1 fingerprint if you haven't already” (tentukan sidik jari SHA-1 aplikasi Anda jika belum). |
| Auth0 di Android | Apa yang harus cocokAllowed callback URLs dan skema aplikasi; identitas app link jika digunakan | Tempat mengaturnyaPengaturan aplikasi Auth0; readme Android SDK-nya menggunakan key hash SHA-256 untuk penyiapan app link |
| Firebase phone authentication | Apa yang harus cocokSHA-256 untuk Play Integrity, SHA-1 untuk fallback reCAPTCHA | Tempat mengaturnyaFirebase phone auth: alur yang terpisah dari login Google |
Jangan pindahkan login ke WebView
Mengarahkan login Google melalui WebView tertanam bukanlah solusi. Kebijakan OAuth 2.0 Google menyatakan bahwa developer “must not direct a Google OAuth 2.0 authorization request to an embedded user-agent” (tidak boleh mengarahkan permintaan otorisasi Google OAuth 2.0 ke user-agent tertanam).
Apa yang harus dikirim penguji kepada developer?
Laporan yang berguna mengidentifikasi build Play yang gagal dan titik persis tempat login berhenti. Penguji tidak bisa memperbaiki pendaftaran OAuth dengan mencoba berulang kali, jadi tugasnya adalah memberikan bukti, bukan terus mencoba. Salin template ini dan kirimkan ke penguji Anda:
Aplikasi dan link pengujian Play:
Versi atau build aplikasi yang terinstal:
Diinstal dari: pengujian tertutup Play / rute lain
Perangkat dan versi Android:
Tanggal, waktu, dan zona waktu:
Teks error persisnya atau screenshot yang disensor:
Tempat berhenti: sebelum pemilih akun / setelah memilih akun / setelah kembali ke aplikasi
Apakah metode login lain bisa membuka aplikasi?
Hasil uji ulang dan versinya:Minta penguji untuk tetap ikut serta dalam pengujian selama Anda memperbaikinya. Jangan pernah meminta kata sandi, token OAuth, kunci privat, atau akses Play Console. Setelah perubahan Anda, minta penguji yang sama membuka fitur yang memerlukan login, lalu logout dan login kembali, serta mencatat versi dan hasilnya.
Apakah error 10 memengaruhi pengujian tertutup atau akses produksi saya?
Error konfigurasi login terpisah dari keikutsertaan. Error 10 bukan kode penolakan kebijakan Play, dan tidak ada aturan Google yang kami temukan yang menyatakan bahwa error ini mereset periode keikutsertaan penguji Anda. Halaman persyaratan pengujian Google mendorong Anda untuk menyempurnakan aplikasi selama pengujian tertutup, jadi pertahankan keikutsertaan penguji dan kirim perbaikannya ke jalur tertutup yang sama. Itu adalah pembacaan atas aturan yang dipublikasikan, bukan janji yang berlaku untuk setiap kasus.
Login yang rusak tetap penting. Kebijakan fungsionalitas Google Play menyatakan “We don’t allow apps that crash, force close, freeze, or otherwise function abnormally” (kami tidak mengizinkan aplikasi yang error, tertutup paksa, macet, atau berfungsi tidak normal), dan dinding login menghalangi penguji menjangkau fitur yang seharusnya mereka uji. Perbaiki sebelum Anda mengajukan permohonan akses produksi, dan berikan detail login yang berfungsi kepada peninjau. Jika hasil peninjauan sudah keluar, lihat penolakan Broken Functionality.
Sebagai konteks: akun developer pribadi yang dibuat setelah 13 November 2023 memerlukan minimal 12 penguji yang terus-menerus ikut serta selama 14 hari sebelum mengajukan permohonan akses produksi untuk aplikasi tersebut. Setelah Anda mengajukan permohonan, Google menyatakan “Proses ini biasanya memerlukan waktu 7 hari atau kurang, tetapi terkadang bisa lebih lama.” Jika ada penguji yang tidak terhitung, periksa cara mereka diundang sebelum Anda mengutak-atik login.
Butuh penguji asli untuk 14 hari?
Penguji tidak bisa memperbaiki pendaftaran OAuth, jadi pastikan login berfungsi terlebih dahulu. Setelah berfungsi, PrimeTestLab menyediakan 12+ penguji asli yang menginstal build Play Anda di ponsel Android asli dan tetap ikut serta selama 14 hari penuh, mulai $19.99 (ditambah biaya layanan 5%). Jika Google tidak memberikan akses produksi setelah pengujian penuh, Anda bisa memilih tes ulang gratis atau pengembalian dana penuh. Lihat cara kerja pengujian tertutup dengan 12 tester.
Pertanyaan yang Sering Diajukan
Mengapa Google Sign-In berfungsi di debug tetapi tidak di pengujian tertutup?
APK debug Anda dan aplikasi yang diunduh dari Google Play bisa ditandatangani dengan sertifikat yang berbeda, sehingga mendaftarkan sidik jari debug tidak mengonfigurasi build Play. Mulailah dengan SHA-1 Play app signing, lalu periksa nama paket final build rilis dan client ID yang benar-benar dipakai aplikasi.
Di mana saya menemukan SHA-1 Play App Signing sekarang?
Buka halaman Protected with Play aplikasi Anda di Play Console (Konsol Play). Bantuan Google menyebut Play Store distribution, lalu Go to Play app signing; teks Google lain yang berlaku saat ini menyebutnya Play Store protection dan Manage Play app signing. Buka bagian App signing key certificate dan salin SHA-1, sambil memeriksa kunci tambahan apa pun yang ditampilkan untuk aplikasi Anda.
Apakah Google Sign-In memerlukan SHA-1 atau SHA-256?
Client OAuth Android dari Google mengidentifikasi aplikasi Anda berdasarkan nama paket dan sidik jari sertifikat penandatanganan SHA-1, dan SHA-256 tidak menggantikan kolom tersebut. Layanan lain memiliki kebutuhannya sendiri: Firebase phone authentication menggunakan SHA-256 untuk Play Integrity dan SHA-1 untuk fallback reCAPTCHA-nya. Konfigurasikan setiap layanan sesuai alur yang dipakai aplikasi Anda.
Saya sudah menambahkan SHA-1. Apa yang harus saya periksa berikutnya?
Pastikan SHA-1 itu milik aplikasi yang diinstal dari Play, bukan kunci upload atau debug Anda. Lalu bandingkan application ID final, project Firebase atau Cloud, dan client ID Web. Jika aplikasi Anda memiliki beberapa sertifikat penandatanganan, periksa juga semuanya. Salah ketik pada client ID yang diterima backend dapat merusak login meskipun sidik jarinya benar.
Apakah saya harus mengupload AAB lain setelah menambahkan sidik jari?
Belum tentu. Para developer melaporkan bahwa perbaikan yang hanya menyangkut pendaftaran di Firebase atau Google Cloud berhasil dengan aplikasi yang sudah terinstal. Perubahan client ID, file konfigurasi, kode, atau dependensi harus sampai ke penguji melalui build baru. Periksa apa yang Anda ubah, lalu verifikasi instalasi Play yang sebenarnya alih-alih membuat build berulang kali tanpa diagnosis.
Berapa lama sidik jari baru mulai berfungsi?
Google tidak memublikasikan waktu propagasi khusus untuk sidik jari, dan thread developer yang kami tinjau tidak mengukurnya. Simpan konfigurasi yang benar lalu coba lagi. Jika masih gagal, verifikasi sertifikat yang terinstal dan pengaturan client alih-alih menunggu sejumlah jam tertentu, karena menunggu tidak memperbaiki ketidakcocokan.
Mengapa muncul canceled padahal saya tidak membatalkan?
Beberapa integrasi Credential Manager dan framework melaporkan masalah konfigurasi atau otorisasi sebagai pembatalan, meskipun pembatalan juga bisa sungguhan. Catat jenis dan pesan exception-nya, periksa panduan pemecahan masalah framework Anda, dan bedakan API saat ini dari status lama 12501 SIGN_IN_CANCELLED sebelum mengubah pengaturan.
Apakah client ID Android yang saya masukkan ke serverClientId?
Bukan. Dalam integrasi Google native yang terdokumentasi, serverClientId atau webClientId adalah client OAuth aplikasi Web yang dipakai untuk permintaan token. Client Android justru mendaftarkan paket dan sertifikat penandatanganan Anda. Konfigurasikan keduanya, dan pastikan backend Anda menerima audience token yang dimaksud alih-alih menukar-nukar client ID secara acak.
Apakah error 10 memulai ulang pengujian tertutup 14 hari saya?
Tidak ada aturan Google yang kami temukan yang menyatakan error ini mereset periode keikutsertaan, dan Google mendorong penyempurnaan selama pengujian tertutup, jadi pertahankan keikutsertaan penguji dan perbaiki jalur yang sudah ada. Itu bukan tanda bahwa aplikasi sudah siap: dinding login dapat menghalangi pengujian yang bermanfaat dan meninggalkan masalah fungsionalitas yang harus Anda perbaiki sebelum mengajukan permohonan.
Apa yang harus saya minta untuk dikirim oleh penguji?
Minta versi yang terinstal, link pengujian Play, perangkat dan versi Android, error persisnya, serta langkah tempat login berhenti. Screenshot yang disensor atau rekaman singkat akan membantu. Setelah perbaikan Anda, minta penguji yang sama memakai fitur yang memerlukan login, lalu logout dan login kembali, tanpa membagikan kredensial apa pun.
Kesimpulan
Kesimpulan
Error 10 Google Sign-In berarti aplikasi salah dikonfigurasi, dan jika hanya salinan dari Play yang gagal, sertifikat penandatanganan adalah hal pertama yang perlu diperiksa. Salin SHA-1 kunci penandatanganan aplikasi dari Protected with Play, daftarkan dengan nama paket final build di project Firebase atau Google Cloud yang sama dengan yang dipakai aplikasi Anda, tetap gunakan client ID Web di serverClientId, lalu uji ulang build yang diinstal penguji Anda, termasuk login kedua. Jika masih gagal, bandingkan sertifikat APK yang terinstal, application ID, dan client ID sebelum mengubah hal lain.
Sumber diperiksa 16 Oktober 2026
Label menu Play Console dan Firebase adalah fakta yang paling cepat berubah di halaman ini. Jika rute di atas tidak lagi cocok dengan console Anda, cari Play app signing di bawah Protected with Play, dan cari sidik jari di bawah aplikasi Android Anda di Project settings Firebase.