Trả lời nhanh
Lỗi Google Sign-In 10, tức DEVELOPER_ERROR, nghĩa là ứng dụng Android bị cấu hình sai. Nếu đăng nhập chạy được trên máy bạn nhưng lỗi trong thử nghiệm khép kín trên Play, hãy kiểm tra xem SHA-1 ký của ứng dụng được cài từ Play và tên gói cuối cùng của nó đã được đăng ký trong đúng dự án Firebase hoặc Google Cloud chưa, và mọi serverClientId hoặc webClientId có phải là client ID loại Web application, chứ không phải client ID Android, hay không. Sau đó thử lại với bản được cài từ Google Play.
Chọn cách thiết lập của bạn
Đã thêm SHA-1 rồi? Hãy chuyển đến những gì cần kiểm tra tiếp.
Bài này chỉ bàn về một lỗi: đăng nhập Google gốc (native) bị hỏng trong bản do Google Play phân phối. Bài tách lỗi đó khỏi các lỗi khác trông tương tự, rồi đề cập đến các framework, các nhà cung cấp đăng nhập khác và những gì người thử nghiệm nên báo cáo. Mọi trang của Google được trích dẫn ở đây đều đã được kiểm tra vào ngày 16 tháng 10 năm 2026, và các báo cáo từ cộng đồng đều được ghi rõ là như vậy. Danh sách nguồn nằm ở cuối bài.
Trên trang này
Sửa Google Sign-In trong bản Play
Hãy khớp ứng dụng mà người thử nghiệm đã cài với tên gói và SHA-1 ký đã đăng ký cho nó. Làm lần lượt các bước sau; cách làm qua Firebase và qua Google Cloud nằm ở phía dưới.
Xác nhận bản nào đang bị lỗi
Kiểm tra xem người thử nghiệm có cài ứng dụng từ đợt thử nghiệm khép kín của bạn trên Google Play không, và ghi lại phiên bản họ đang dùng. Sau đó ghi lại application ID cuối cùng của bản đó. Hướng dẫn build của Android cho biết application ID của bạn được xác định bởi thuộc tính applicationId, giá trị này có thể khác namespace trong mã nguồn hoặc được thêm hậu tố trong một build flavor. Nếu người thử nghiệm hoàn toàn không cài được ứng dụng thì đó là vấn đề khác: xem vì sao ứng dụng không có sẵn cho người thử nghiệm.
Mở mục Play app signing
Trong Play Console, mở ứng dụng và vào Protected with Play. Google đã chuyển phần ký ứng dụng về đây vào tháng 5 năm 2026, và chính trang trợ giúp của Google gọi bước tiếp theo theo hai cách (xem bảng bên dưới). Cả hai đường đều dẫn đến cùng một trang.
| Đường dẫn theo cách Google viết | Nơi Google dùng nó | Mở gì ở đó |
|---|---|---|
| Protected with Play > Play Store distribution > Go to Play app signing | Nơi Google dùng nóTrợ giúp Play Console, Use Play App Signing, phần đăng ký API | Mở gì ở đóApp signing key certificate, rồi đến giá trị SHA-1 |
| Protected with Play > Play Store protection > Manage Play app signing | Nơi Google dùng nóGhi chú cập nhật tháng 5 năm 2026 của Google Play và một phần khác trên cùng trang trợ giúp | Mở gì ở đóCùng một trang; nhãn menu có thể khác nhau giữa các tài khoản |
Sao chép SHA-1 của khóa ký ứng dụng
Mở phần App signing key certificate (chứng chỉ khóa ký ứng dụng), không phải upload key certificate (chứng chỉ khóa tải lên), rồi sao chép SHA-1 của nó. Nếu Play liệt kê nhiều hơn một khóa ký cho ứng dụng, hãy đăng ký từng vân tay phù hợp (xem nhiều chứng chỉ ký). Giữ nguyên các vân tay debug và vân tay trên máy hiện có, rồi thêm các vân tay của Play bên cạnh. Đừng xoay vòng (rotate) khóa ký chỉ để sửa lỗi đăng nhập.
Đăng ký ở nơi ứng dụng dùng để đăng nhập
Dùng cách làm qua Firebase hoặc cách làm qua Google Cloud, tùy ứng dụng của bạn dùng cái nào, và dùng đúng dự án đã cấp các client ID nằm trong ứng dụng.
Thử lại bản đã cài từ Play
Nếu bạn chỉ thay đổi phần đăng ký trong Firebase hoặc Google Cloud, hãy thử lại với bản đã cài sẵn từ Play trước khi build bất cứ thứ gì; các nhà phát triển cho biết có lần chỉ sửa phần đăng ký là đã chạy được mà không cần tải bản mới lên. Nếu bạn thay đổi cấu hình đóng gói trong ứng dụng, một client ID, mã nguồn hoặc một thư viện phụ thuộc, hãy tải bản build mới lên cùng kênh thử nghiệm khép kín và thử với bản đó. Google không công bố thời gian cố định để một vân tay mới có hiệu lực, vì vậy hãy thử lại thay vì chờ một số giờ nhất định.
Thêm chứng chỉ của Play vào Firebase
Chọn đúng ứng dụng Android tương ứng trước khi thêm vân tay ký của Play. Các bước dưới đây theo trang trợ giúp về vân tay của Firebase và hướng dẫn đăng nhập Google của Firebase.
- Trong Firebase console, mở dự án mà ứng dụng của bạn dùng, rồi vào Project settings > General.
- Trong Your apps, chọn ứng dụng Android có tên gói trùng với bản build bị lỗi.
- Nhấn Add fingerprint, dán SHA-1 ký ứng dụng của Play rồi lưu. Thêm nó bên cạnh các vân tay hiện có thay vì thay thế chúng.
- Trong Authentication > Sign-in method, xác nhận Google đã được bật.
- Nếu Firebase nhắc bạn tải tệp
google-services.jsonđã cập nhật, hãy thay tệp đó trong dự án. Firebase cho biết tệp này “contains the OAuth client information required for Google sign-in” (chứa thông tin OAuth client cần cho đăng nhập Google), nên tệp thay đổi đồng nghĩa với một bản build mới. Kiểm tra xem dự án và tên gói trong tệp có khớp với ứng dụng bị lỗi không.
Chỉ thêm SHA-256 khi một dịch vụ Firebase cụ thể yêu cầu. Ví dụ, xác thực bằng số điện thoại dùng SHA-256 cho luồng Play Integrity; bản thân Google Sign-In dựa vào SHA-1.
Cấu hình Google Cloud khi không dùng Firebase
Hai OAuth client làm hai việc khác nhau. Client Android đăng ký ứng dụng của bạn; Web client ID là ID mà yêu cầu token của bạn sử dụng.
| Loại client | Nội dung chứa | Dùng ở đâu |
|---|---|---|
| Android | Nội dung chứaTên gói của bạn và SHA-1 của chứng chỉ ký | Dùng ở đâuĐăng ký danh tính của ứng dụng gốc. Bạn không dán client ID này vào serverClientId. |
| Web application | Nội dung chứaWeb client ID | Dùng ở đâuserverClientId hoặc webClientId trong yêu cầu token, và audience mà backend của bạn chấp nhận. Codelab Sign in with Google của Google mô tả nó đóng vai trò “as the backend client for the Google Sign-in service” (client phía backend cho dịch vụ Google Sign-in). |
- Chọn dự án đã cấp các client ID của bạn, rồi mở Google Auth platform > Clients (trợ giúp Google Cloud).
- Tìm xem đã có client Android với tên gói và SHA-1 này chưa trước khi tạo thêm một cái khác.
- Nếu chưa có, chọn Create Client, đặt Application type là Android, nhập tên, tên gói và SHA-1 ký ứng dụng của Play, rồi nhấn Create. Biểu mẫu Android có một trường SHA-1; SHA-256 không điền vào đó.
- Đăng ký từng cặp tên gói và chứng chỉ mà bạn cần, ví dụ debug, bản release build trên máy và bản Play.
- Giữ nguyên Web client cho yêu cầu token, và không bao giờ đặt client secret bên trong ứng dụng.
Chứng minh đã sửa xong
Một lần đăng nhập thành công chưa chứng minh bản phát hành đã được sửa. Danh sách kiểm tra này là bài kiểm tra nghiệm thu chúng tôi khuyến nghị, không phải quy định của Google; dòng cuối quan trọng vì có một nhà phát triển đăng nhập được một lần nhưng vẫn lỗi ở lần đăng nhập sau, một lỗi phiên (session) mà kiểm tra một lần sẽ bỏ sót.
| Kiểm tra | Bằng chứng đạt | Nếu không đạt |
|---|---|---|
| Đúng ứng dụng và phiên bản | Bằng chứng đạtNgười thử nghiệm xác nhận đúng bản cài từ Play và đúng bản build dự định | Nếu không đạtGiải quyết việc phân phối bản phát hành hoặc kênh trước |
| Lần đăng nhập đầu tiên | Bằng chứng đạtChọn tài khoản xong thì quay lại ứng dụng ở trạng thái đã đăng nhập | Nếu không đạtGhi lại chính xác exception và dùng bảng mã lỗi bên dưới |
| Tính năng cần đăng nhập | Bằng chứng đạtNgười thử nghiệm dùng được một tính năng cần đăng nhập | Nếu không đạtKiểm tra cách ứng dụng và backend xử lý token |
| Đăng xuất rồi đăng nhập lại | Bằng chứng đạtLần đăng nhập thứ hai chạy được mà không cần cài lại | Nếu không đạtĐiều tra cách xử lý phiên và đăng xuất khỏi nhà cung cấp |
| Thiết bị từng bị lỗi | Bằng chứng đạtCùng người thử nghiệm và cùng thiết bị đó giờ đã thành công | Nếu không đạtSo sánh chứng chỉ, hệ điều hành, tài khoản và bản build thực tế |
| Tính liên tục của thử nghiệm | Bằng chứng đạtNgười thử nghiệm vẫn đang chọn tham gia và bạn đã ghi lại bản sửa | Nếu không đạtXử lý việc tham gia tách biệt với việc đăng nhập |
Vì sao đăng nhập chạy được ở bản debug nhưng lỗi khi thử nghiệm khép kín?
Ứng dụng cài qua Google Play có thể được ký bởi một khóa khác với APK bạn cài trên máy. Hướng dẫn xác thực client của Google lưu ý rằng “Android Studio automatically signs your app with a debug certificate.” (Android Studio tự động ký ứng dụng của bạn bằng chứng chỉ debug). Bản release bạn tự build sẽ dùng khóa nào được cấu hình cho variant đó. Với Play App Signing, khóa tải lên (upload key) của bạn ký bundle mà bạn tải lên, còn Google ký các APK mà người thử nghiệm nhận được bằng khóa ký ứng dụng (app signing key).
Các khóa đó có vai trò khác nhau, nhưng không phải lúc nào cũng có giá trị khác nhau: bạn có thể tự cung cấp khóa ký của mình, và một số cách thiết lập dùng một khóa cho cả hai vai trò. Hãy so sánh các vân tay thực tế thay vì dựa vào tên gọi của khóa.
| Bản đã cài | Chứng chỉ cần kiểm tra | Việc cần làm trước |
|---|---|---|
| Bản cài từ kênh thử nghiệm nội bộ, khép kín, công khai hoặc kênh phát hành công khai trên Play có dùng Play App Signing | Chứng chỉ cần kiểm traMột hoặc nhiều chứng chỉ ký ứng dụng của Play, nằm trong Protected with Play | Việc cần làm trướcĐăng ký từng SHA-1 phù hợp của Play |
| Chạy debug từ Android Studio | Chứng chỉ cần kiểm traChứng chỉ debug của chính máy đó | Việc cần làm trướcĐăng ký SHA-1 đó cho application ID tương ứng |
| APK release build trên máy của bạn | Chứng chỉ cần kiểm traChứng chỉ được cấu hình cho release variant đó | Việc cần làm trướcĐừng mặc định “release” nghĩa là khóa ký của Google |
| Đường liên kết chia sẻ ứng dụng nội bộ | Chứng chỉ cần kiểm traChứng chỉ thử nghiệm riêng của tính năng chia sẻ ứng dụng nội bộ | Việc cần làm trướcĐăng ký riêng nếu người thử nghiệm dùng con đường đó |
Chia sẻ ứng dụng nội bộ không phải là thử nghiệm nội bộ
Trang trợ giúp về chia sẻ ứng dụng nội bộ của Google viết “Every APK is resigned with this test certificate.” (Mọi APK đều được ký lại bằng chứng chỉ thử nghiệm này). Bạn tìm nó tại Test and release > Internal testing > Internal app sharing > Uploaders and testers > Internal test certificate. Còn kênh thử nghiệm nội bộ và kênh thử nghiệm khép kín thì dùng khóa ký ứng dụng Play của bạn.
Tự đọc các vân tay
Với các bản build trên máy của bạn, báo cáo ký của Gradle in ra SHA-1 và SHA-256 của mọi variant, còn keytool đọc trực tiếp keystore debug (nhập mật khẩu keystore khi được hỏi):
./gradlew signingReport
keytool -list -v -alias androiddebugkey -keystore ~/.android/debug.keystoreBáo cáo ký trên máy không cho bạn biết cái gì đã ký bản trên Play. Để kiểm tra chính bản build đang lỗi, hãy cài nó từ đợt thử nghiệm khép kín lên một thiết bị, kéo nó về bằng adb và in các chứng chỉ của nó bằng apksigner, công cụ mà Google mô tả là hiển thị “information about the APK's signing certificates.” (thông tin về các chứng chỉ ký của APK). Thay tên gói và dùng đường dẫn mà lệnh đầu tiên in ra:
adb shell pm path com.example.app
adb pull /data/app/.../base.apk failing-play.apk
apksigner verify --print-certs failing-play.apkTôi đã thêm SHA-1 mà vẫn lỗi
Hãy so sánh chứng chỉ của APK đang lỗi, application ID cuối cùng của nó và các client ID trước khi thay đổi thêm cài đặt nào. Đi lần lượt xuống thang kiểm tra này; mỗi dòng loại trừ một lớp.
| Kiểm tra | Cần so sánh gì | Kết luận |
|---|---|---|
| 1. Bản đã cài và kênh | Cần so sánh gìBản người thử nghiệm thực sự cài từ Play so với phiên bản bạn định thử nghiệm | Kết luậnBáo cáo ký trên máy không chứng minh được khóa ký của Play |
| 2. Chứng chỉ | Cần so sánh gìKết quả của apksigner verify --print-certs trên APK Play đang lỗi so với những gì bạn đã đăng ký |
Kết luậnĐăng ký mọi khóa ký cần thiết; giữ các mục cũ vẫn đang phục vụ người dùng đã cài |
| 3. Application ID cuối cùng | Cần so sánh gìapplicationId của variant đã build, kể cả hậu tố flavor, so với tên gói đã đăng ký | Kết luậnNamespace trong mã nguồn không được tính |
| 4. Dự án và Web client | Cần so sánh gìDự án và Web client ID mà bản release và backend của bạn thực sự dùng | Kết luậnMột lỗi đánh máy ở đây làm hỏng đăng nhập ngay cả khi vân tay đúng |
| 5. Nhà cung cấp và các client tồn tại | Cần so sánh gìGoogle đã được bật làm nhà cung cấp, cùng với client Android và Web client đứng sau | Kết luậnNếu một dự án khác đang giữ cặp này, xem ghi chú về xung đột bên dưới |
| 6. Nhóm lỗi | Cần so sánh gìMã gốc 10, một lần hủy của Credential Manager, backend từ chối token hoặc chuyển hướng trình duyệt không khớp | Kết luậnMỗi loại là một nhánh riêng; xem bảng mã lỗi |
| 7. Vấn đề của framework ở bản release | Cần so sánh gìViệc thu gọn tài nguyên (resource shrinking), phiên bản thư viện thực tế được dùng và quá trình khởi tạo | Kết luậnDựa vào changelog và các bản sửa đã được xác nhận, không nâng cấp hay hạ cấp ngẫu nhiên |
Dòng 4 không phải là lý thuyết. Trong một trường hợp dùng Expo được báo cáo vào tháng 9 năm 2026, thêm vân tay không thay đổi gì; cách sửa là chữa một lỗi đánh máy trong client ID mà backend chấp nhận.
Nhiều chứng chỉ ký hoặc khóa đã nâng cấp
Một ứng dụng có thể cần đăng ký nhiều hơn một danh tính ký. Trang trợ giúp Play App Signing hiện tại của Google mô tả cơ chế ký kết hợp (hybrid signing) với ba khóa ký ứng dụng và yêu cầu bạn đăng ký vân tay của từng khóa, và một ứng dụng đã nâng cấp khóa ký vẫn có thể có những bản cài được ký bằng khóa cũ. Hãy đăng ký các danh tính mà các bản cài của bạn thực sự mang và đừng xóa các mục cũ vẫn còn hoạt động. Việc xoay vòng khóa nằm ngoài phạm vi bài này, và đó không phải là cách sửa lỗi đăng nhập.
Một dự án khác đã sở hữu tên gói và SHA-1 này
Trang trợ giúp về xung đột của Firebase cho biết một cặp tên gói và SHA-1 “must be unique across all Firebase and Google Cloud projects.” (phải là duy nhất trên mọi dự án Firebase và Google Cloud). Nếu console từ chối vân tay của bạn vì một dự án khác đang giữ nó, hãy tìm xem dự án nào sở hữu OAuth client đó trước khi xóa bất cứ thứ gì. Bộ phận hỗ trợ của Google có thể giúp xác định chỗ xung đột; đừng xóa các client hoặc dự án đang hoạt động để mò đường.
Lỗi 10 có giống 12500, 12501 hay canceled không?
Không. Hãy đọc chính xác lỗi và thư viện đã tạo ra nó trước khi coi mọi lần đăng nhập thất bại là cùng một vấn đề. Tài liệu tham khảo mã trạng thái chung của Google định nghĩa DEVELOPER_ERROR = 10 là “The application is misconfigured.” (ứng dụng bị cấu hình sai). Các mã khác bên dưới đến từ SDK play-services-auth 21.6.0 cũ của Google.
| Bạn thấy gì | Ý nghĩa | Bước tiếp theo |
|---|---|---|
ApiException: 10 hoặc DEVELOPER_ERROR |
Ý nghĩaLỗi cấu hình ứng dụng | Bước tiếp theoSo sánh khóa ký, tên gói, dự án và các client ID |
12500 |
Ý nghĩaSIGN_IN_FAILED: “A non-recoverable sign in failure occurred” (đã xảy ra lỗi đăng nhập không thể khôi phục) |
Bước tiếp theoĐọc các log xung quanh; đừng coi nó là lỗi 10 |
12501 |
Ý nghĩaSIGN_IN_CANCELLED: “Sign in action cancelled” (thao tác đăng nhập đã bị hủy) |
Bước tiếp theoTìm hiểu xem người dùng có hủy không và API nào đã tạo ra nó |
canceled của Credential Manager hoặc Flutter |
Ý nghĩaMột lần hủy thật hoặc một lỗi cấu hình | Bước tiếp theoKiểm tra chi tiết exception và phần thiết lập; để người dùng thử lại sau khi bạn đã chẩn đoán |
NoCredentialException |
Ý nghĩaKhông có thông tin xác thực nào được trả về; không phải là chẩn đoán về chứng chỉ | Bước tiếp theoKiểm tra tài khoản có sẵn hay không và cấu hình yêu cầu, bên cạnh phần đăng ký |
| Token Google hoạt động, backend từ chối | Ý nghĩaMột giai đoạn sau bước lấy thông tin xác thực Google | Bước tiếp theoKiểm tra audience và các client ID mà backend của bạn chấp nhận |
redirect_uri_mismatch |
Ý nghĩaChuyển hướng OAuth trên trình duyệt không khớp với URI đã được cho phép | Bước tiếp theoSửa cấu hình callback cho luồng đó |
| “Item not found” trên đường liên kết Play | Ý nghĩaVấn đề về cài đặt hoặc điều kiện tham gia, không phải đăng nhập | Bước tiếp theoLàm theo các bước kiểm tra khi ứng dụng không có sẵn |
Google Sign-In cũ và Credential Manager
Ghi chú phát hành của Play services ghi nhận việc ngừng khuyến nghị (deprecation) các API Google Sign-In trong play-services-base vào ngày 16 tháng 4 năm 2024, và Google đã thông báo chuyển sang Credential Manager vào ngày 11 tháng 9 năm 2024. Sau đó các API này bị gỡ khỏi play-services-auth 22.0.0 vào ngày 26 tháng 8 năm 2026 và khỏi play-services-base 18.11.0 vào ngày 17 tháng 9 năm 2026, kèm ghi chú “Removed the APIs related to Google Sign-in.” (đã gỡ các API liên quan đến Google Sign-in). Đó là một thay đổi về SDK; nó không xác lập ngày ngừng hoạt động cho các ứng dụng đã được cài. Mã mới và các lần nâng cấp nên làm theo hướng dẫn chuyển đổi của Google.
Hai API này lỗi theo cách khác nhau. Credential Manager không có lỗi 10; hướng dẫn khắc phục sự cố của nó cảnh báo rằng “A high volume of "cancellations" may actually indicate a misconfiguration.” (số lượng lớn "lần hủy" thực ra có thể là dấu hiệu cấu hình sai). Vì vậy một lần hủy có thể là lỗi cấu hình hoặc là một lần hủy thật, còn NoCredentialException lại là một tín hiệu khác nữa.
Kiểm tra cho Flutter, React Native, Expo và Unity
Các bước kiểm tra danh tính ứng dụng gốc ở trên áp dụng cho mọi framework, nhưng cách thiết lập, khởi tạo và cấu hình build thì khác nhau. Hãy dùng cách làm dành cho framework của bạn và phiên bản thư viện mà ứng dụng thực sự sử dụng.
| Framework | Kiểm tra cụ thể | Đừng mặc định |
|---|---|---|
| Flutter | Kiểm tra cụ thểPhần triển khai Android, google_sign_in_android, đã chuyển sang Credential Manager từ bản 7.0.0. Truyền Web client ID vào serverClientId. Changelog của bản 7.2.16 ghi “Keeps default_web_client_id resource from being stripped by resource shrinkers,” (giữ tài nguyên default_web_client_id không bị công cụ thu gọn tài nguyên loại bỏ), điều quan trọng với những lỗi chỉ xảy ra ở bản release. |
Đừng mặc địnhRằng mọi kết quả canceled đều là lỗi SHA, hoặc hạ cấp là cách sửa cho mọi trường hợp. |
| React Native | Kiểm tra cụ thểXác định bạn đang dùng API nào của thư viện, truyền Web client ID vào webClientId, và kiểm tra applicationId thực tế cùng APK đang lỗi. Hướng dẫn khắc phục sự cố có mục “Login does not work when downloading from the Play Store” (đăng nhập không hoạt động khi tải từ Play Store) và cung cấp một lệnh kiểm tra cấu hình (bên dưới). |
Đừng mặc địnhRằng một issue đã đóng trên tracker chứng minh lỗi đã được sửa. |
| Expo | Kiểm tra cụ thểĐăng nhập Google gốc cần một bản development build hoặc custom build; hướng dẫn của Expo viết “These libraries can't be used in Expo Go because they require custom native code.” (các thư viện này không dùng được trong Expo Go vì chúng cần mã native tùy chỉnh). Hãy tách bạch chứng chỉ ký của EAS hoặc trên máy với chứng chỉ ký ứng dụng của Play. | Đừng mặc địnhRằng Expo Go tái hiện được luồng của bản release, hoặc build lại sẽ sửa được một client ID backend sai. |
| Unity | Kiểm tra cụ thểQuyết định bạn dùng Firebase Authentication hay Unity Authentication, lấy Google ID token qua tích hợp nền tảng được hỗ trợ, rồi trao đổi nó với backend đó (hướng dẫn Unity của Firebase). Mẫu đăng nhập Unity cũ của Google đã được lưu trữ (archived) vào ngày 19 tháng 4 năm 2026. | Đừng mặc địnhRằng đăng nhập Play Games và đăng nhập tài khoản Google là cùng một tích hợp. |
Với React Native, những người duy trì thư viện cung cấp một lệnh kiểm tra cấu hình mà bạn có thể chạy từ thư mục gốc của dự án:
npx @react-native-google-signin/config-doctorĐiều gì thay đổi với Supabase, Facebook, Apple hoặc Auth0?
Nhà cung cấp và luồng đăng nhập quyết định chứng chỉ, client ID hay callback nào phải khớp. SHA-1 của Google là câu trả lời cho đăng nhập Google gốc; với các nhà cung cấp khác, nó có thể là sai loại hash, sai định dạng hoặc không liên quan.
| Nhà cung cấp hoặc luồng | Những gì phải khớp | Thiết lập ở đâu |
|---|---|---|
| Đăng nhập Google gốc qua Firebase | Những gì phải khớpTên gói và SHA-1 của bản đã cài, Web client, Google được bật làm nhà cung cấp | Thiết lập ở đâuCác vân tay trong Project settings của Firebase, cùng với Authentication |
| Đăng nhập Google gốc qua Supabase | Những gì phải khớpDanh tính Android gốc và Web client ID; hướng dẫn của Supabase viết “The Web client ID is the one used in your Android app.” (Web client ID là ID được dùng trong ứng dụng Android của bạn). | Thiết lập ở đâuClient Android và Web client của Google, rồi đến cài đặt nhà cung cấp Google trong Supabase |
| OAuth trên trình duyệt của Supabase | Những gì phải khớpWeb client, callback của Supabase và đường liên kết quay lại ứng dụng của bạn | Thiết lập ở đâuCác URI chuyển hướng được cho phép trong Google và cài đặt chuyển hướng của Supabase; cách sửa bằng SHA không áp dụng |
| Facebook trên Android | Những gì phải khớpMột key hash Base64 tạo từ các byte SHA-1 của chứng chỉ ký, không phải chuỗi hex phân cách bằng dấu hai chấm | Thiết lập ở đâuCài đặt ứng dụng Facebook, mục Android key hashes (đường dẫn theo tài liệu trong hướng dẫn Facebook của Expo) |
| Đăng nhập Apple qua web trên Android | Những gì phải khớpServices ID, tên miền và URL quay lại | Thiết lập ở đâuCấu hình web Sign in with Apple của Apple; không phải cơ chế DEVELOPER_ERROR của Google |
| Apple qua Firebase trên Android | Những gì phải khớpPhần thiết lập Apple cùng với SHA-1 của ứng dụng | Thiết lập ở đâuHướng dẫn Apple của Firebase: “Specify your app's SHA-1 fingerprint if you haven't already.” (khai báo vân tay SHA-1 của ứng dụng nếu bạn chưa làm) |
| Auth0 trên Android | Những gì phải khớpCác callback URL được cho phép và scheme của ứng dụng; danh tính app link nếu có dùng | Thiết lập ở đâuCài đặt ứng dụng Auth0; readme của Android SDK dùng key hash SHA-256 cho phần thiết lập app link |
| Xác thực bằng số điện thoại của Firebase | Những gì phải khớpSHA-256 cho Play Integrity, SHA-1 cho phương án dự phòng reCAPTCHA | Thiết lập ở đâuXác thực số điện thoại của Firebase: một luồng tách biệt với đăng nhập Google |
Đừng chuyển đăng nhập vào WebView
Đưa đăng nhập Google qua một WebView nhúng không phải là cách lách. Chính sách OAuth 2.0 của Google quy định nhà phát triển “must not direct a Google OAuth 2.0 authorization request to an embedded user-agent.” (không được chuyển yêu cầu ủy quyền Google OAuth 2.0 đến một user-agent nhúng).
Người thử nghiệm nên gửi gì cho nhà phát triển?
Một báo cáo hữu ích xác định được bản build Play đang lỗi và đúng thời điểm đăng nhập bị dừng. Người thử nghiệm không thể sửa phần đăng ký OAuth bằng cách thử lại, nên việc của họ là cung cấp bằng chứng, không phải kiên trì thử mãi. Hãy sao chép mẫu này và gửi cho người thử nghiệm của bạn:
Ứng dụng và đường liên kết thử nghiệm trên Play:
Phiên bản hoặc bản build đã cài:
Cài từ: thử nghiệm khép kín trên Play / cách khác
Thiết bị và phiên bản Android:
Ngày, giờ và múi giờ:
Nguyên văn thông báo lỗi hoặc ảnh chụp màn hình đã che thông tin nhạy cảm:
Dừng ở đâu: trước khi hiện bảng chọn tài khoản / sau khi chọn tài khoản / sau khi quay lại ứng dụng
Có cách đăng nhập nào khác mở được ứng dụng không?
Kết quả thử lại và phiên bản:Hãy đề nghị người thử nghiệm tiếp tục chọn tham gia thử nghiệm trong lúc bạn sửa lỗi. Không bao giờ hỏi mật khẩu, OAuth token, khóa riêng tư hay quyền truy cập Play Console. Sau khi bạn thay đổi, hãy nhờ chính người thử nghiệm đó mở một tính năng cần đăng nhập, rồi đăng xuất và đăng nhập lại, và ghi lại phiên bản cùng kết quả.
Lỗi 10 có ảnh hưởng đến thử nghiệm khép kín hoặc quyền truy cập vào kênh phát hành công khai không?
Lỗi cấu hình đăng nhập là chuyện tách biệt với việc tham gia thử nghiệm. Lỗi 10 không phải là mã từ chối theo chính sách của Play, và chúng tôi không tìm thấy quy định nào của Google nói rằng nó đặt lại thời gian chọn tham gia của người thử nghiệm. Trang yêu cầu về thử nghiệm của Google khuyến khích bạn cải thiện ứng dụng trong quá trình thử nghiệm khép kín, vì vậy hãy giữ người thử nghiệm tiếp tục tham gia và phát hành bản sửa lên cùng kênh thử nghiệm khép kín. Đây là cách hiểu các quy định đã công bố, không phải lời hứa áp dụng cho mọi trường hợp.
Đăng nhập bị hỏng vẫn là vấn đề quan trọng. Chính sách về chức năng của Google Play nêu “We don’t allow apps that crash, force close, freeze, or otherwise function abnormally,” (Google không cho phép ứng dụng bị treo, buộc đóng, đơ hoặc hoạt động bất thường theo cách khác), và một màn hình đăng nhập chặn đường sẽ khiến người thử nghiệm không tới được các tính năng họ cần thử. Hãy sửa nó trước khi đăng ký quyền truy cập vào kênh phát hành công khai, và cung cấp cho người xem xét thông tin đăng nhập hoạt động được. Nếu đã có kết quả xem xét, hãy xem lỗi từ chối Broken Functionality.
Để nắm bối cảnh: tài khoản nhà phát triển cá nhân tạo sau ngày 13 tháng 11 năm 2023 cần ít nhất 12 người thử nghiệm chọn tham gia liên tục trong 14 ngày trước khi đăng ký quyền truy cập vào kênh phát hành công khai cho ứng dụng đó. Sau khi bạn đăng ký, Google cho biết “Review usually takes seven days or less, but can occasionally take longer.” (quá trình xem xét thường mất 7 ngày hoặc ít hơn, nhưng đôi khi có thể lâu hơn). Nếu số người thử nghiệm được tính bị thiếu, hãy kiểm tra cách họ được mời trước khi động đến phần đăng nhập.
Cần tester thật cho 14 ngày?
Người thử nghiệm không thể sửa phần đăng ký OAuth, vì vậy hãy làm cho đăng nhập hoạt động trước. Khi đã chạy được, PrimeTestLab cung cấp 12+ tester thật cài bản Play của bạn trên điện thoại Android thật và duy trì chọn tham gia trọn 14 ngày, giá từ $19.99 (cộng 5% phí dịch vụ). Nếu Google không cấp quyền truy cập vào kênh phát hành công khai sau khi thử nghiệm đủ thời gian, bạn chọn thử nghiệm lại miễn phí hoặc hoàn tiền toàn bộ. Xem cách thử nghiệm khép kín với 12 tester hoạt động.
Câu hỏi thường gặp
Vì sao Google Sign-In chạy được ở bản debug nhưng không chạy khi thử nghiệm khép kín?
APK debug của bạn và ứng dụng tải từ Google Play có thể được ký bằng các chứng chỉ khác nhau, nên đăng ký vân tay debug không cấu hình được cho bản Play. Hãy bắt đầu với SHA-1 ký ứng dụng của Play, sau đó kiểm tra tên gói cuối cùng của bản release và các client ID mà ứng dụng thực sự dùng.
Giờ tìm SHA-1 của Play App Signing ở đâu?
Mở trang Protected with Play của ứng dụng trong Play Console. Trang trợ giúp của Google mô tả đường đi là Play Store distribution, rồi Go to Play app signing; một số văn bản hiện hành khác của Google gọi các mục này là Play Store protection và Manage Play app signing. Mở phần App signing key certificate và sao chép SHA-1, đồng thời kiểm tra mọi khóa bổ sung hiển thị cho ứng dụng của bạn.
Google Sign-In cần SHA-1 hay SHA-256?
OAuth client Android của Google nhận diện ứng dụng bằng tên gói và vân tay chứng chỉ ký SHA-1, và SHA-256 không thay thế được trường đó. Các dịch vụ khác có yêu cầu riêng: xác thực bằng số điện thoại của Firebase dùng SHA-256 cho Play Integrity và SHA-1 cho phương án dự phòng reCAPTCHA. Hãy cấu hình từng dịch vụ theo luồng mà ứng dụng của bạn sử dụng.
Tôi đã thêm SHA-1 rồi. Nên kiểm tra gì tiếp theo?
Xác nhận nó thuộc về ứng dụng được cài từ Play, không phải khóa tải lên hay khóa debug của bạn. Sau đó so sánh application ID cuối cùng, dự án Firebase hoặc Cloud và Web client ID. Nếu ứng dụng có nhiều chứng chỉ ký, hãy kiểm tra cả chúng. Một lỗi đánh máy trong client ID mà backend chấp nhận có thể làm hỏng đăng nhập ngay cả khi vân tay đã đúng.
Có phải tải lên AAB khác sau khi thêm vân tay không?
Không nhất thiết. Các nhà phát triển cho biết chỉ sửa phần đăng ký trong Firebase hoặc Google Cloud là đã chạy được với ứng dụng đã cài sẵn. Còn client ID, tệp cấu hình, mã nguồn hoặc thư viện phụ thuộc đã thay đổi thì phải đến tay người thử nghiệm qua một bản build mới. Hãy xem bạn đã thay đổi gì, rồi xác minh bản cài thực tế từ Play thay vì build lại nhiều lần mà không chẩn đoán.
Vân tay mới mất bao lâu để có hiệu lực?
Google không công bố thời gian lan truyền riêng cho vân tay, và các thảo luận của nhà phát triển mà chúng tôi đã xem cũng không đo được con số nào. Hãy lưu đúng cấu hình rồi thử lại. Nếu vẫn lỗi, hãy xác minh chứng chỉ của bản đã cài và cài đặt client thay vì chờ một số giờ cố định, vì chờ đợi không sửa được sự không khớp.
Vì sao báo canceled khi tôi không hề hủy?
Một số tích hợp Credential Manager và framework báo một lỗi cấu hình hoặc ủy quyền dưới dạng lần hủy, dù lần hủy cũng có thể là thật. Hãy ghi lại loại exception và thông báo, xem hướng dẫn khắc phục sự cố của framework, và phân biệt API hiện tại với trạng thái 12501 SIGN_IN_CANCELLED cũ trước khi thay đổi cài đặt.
Client ID Android có phải là ID tôi điền vào serverClientId không?
Không. Trong các tích hợp Google gốc có tài liệu, serverClientId hoặc webClientId là OAuth client loại Web application dùng cho yêu cầu token. Còn client Android thì đăng ký tên gói và chứng chỉ ký của bạn. Hãy cấu hình cả hai, và xác nhận backend của bạn chấp nhận đúng audience của token như dự định thay vì hoán đổi các client ID một cách ngẫu nhiên.
Lỗi 10 có làm thử nghiệm khép kín 14 ngày của tôi bắt đầu lại không?
Chúng tôi không tìm thấy quy định nào của Google nói lỗi này đặt lại thời gian chọn tham gia, và Google khuyến khích cải thiện ứng dụng trong quá trình thử nghiệm khép kín, vì vậy hãy giữ người thử nghiệm tiếp tục tham gia và sửa trên kênh hiện có. Điều đó không có nghĩa ứng dụng đã sẵn sàng: một màn hình đăng nhập chặn đường có thể khiến việc thử nghiệm mất tác dụng và để lại một vấn đề về chức năng mà bạn phải sửa trước khi đăng ký.
Tôi nên nhờ người thử nghiệm gửi cho tôi những gì?
Hãy hỏi phiên bản đã cài, đường liên kết thử nghiệm trên Play, thiết bị và phiên bản Android, nguyên văn lỗi và bước mà đăng nhập bị dừng. Một ảnh chụp màn hình đã che thông tin nhạy cảm hoặc một đoạn quay ngắn sẽ có ích. Sau khi sửa, hãy nhờ chính người thử nghiệm đó dùng một tính năng cần đăng nhập, rồi đăng xuất và đăng nhập lại, mà không chia sẻ bất kỳ thông tin đăng nhập nào.
Kết luận
Kết luận
Lỗi Google Sign-In 10 nghĩa là ứng dụng bị cấu hình sai, và khi chỉ bản tải từ Play bị lỗi thì chứng chỉ ký là thứ cần kiểm tra đầu tiên. Hãy sao chép SHA-1 của khóa ký ứng dụng trong Protected with Play, đăng ký nó cùng tên gói cuối cùng của bản build trong chính dự án Firebase hoặc Google Cloud mà ứng dụng của bạn dùng, giữ Web client ID trong serverClientId, và thử lại bản mà người thử nghiệm đã cài, bao gồm cả lần đăng nhập thứ hai. Nếu vẫn lỗi, hãy so sánh chứng chỉ của APK đã cài, application ID và các client ID trước khi thay đổi bất cứ điều gì khác.
Nguồn đã kiểm tra ngày 16 tháng 10 năm 2026
Nhãn menu của Play Console và Firebase là những thông tin thay đổi nhanh nhất trên trang này. Nếu một đường dẫn ở trên không còn khớp với console của bạn, hãy tìm Play app signing trong Protected with Play, và tìm các vân tay trong ứng dụng Android của bạn ở Project settings của Firebase.