الإجابة المختصرة
الخطأ 10 في Google Sign-In، أي DEVELOPER_ERROR، يعني أن تطبيق Android مُهيّأ بشكل خاطئ. إذا كان تسجيل الدخول يعمل محليًا لكنه يفشل في اختبار مغلق على Play، فتحقّق من أن بصمة SHA-1 لتوقيع التطبيق المثبّت من Play واسم حزمته النهائي مسجّلان في مشروع Firebase أو Google Cloud الصحيح، ومن أن أي serverClientId أو webClientId هو معرّف عميل تطبيق الويب (Web application)، لا معرّف عميل Android. ثم أعد الاختبار بالإصدار المثبّت من Google Play.
اختر إعدادك
أضفت SHA-1 بالفعل؟ انتقل إلى ما الذي تتحقق منه بعد ذلك.
يتناول هذا الدليل عطلًا واحدًا: تسجيل الدخول الأصلي (native) بحساب Google الذي يتعطّل في النسخة التي يوصلها Google Play. يفصله عن أخطاء أخرى تبدو مشابهة، ثم يغطي أطر العمل ومزوّدي تسجيل الدخول الآخرين وما ينبغي أن يبلّغ عنه المختبِرون. تم التحقق من كل صفحة من صفحات Google المذكورة هنا في 16 أكتوبر 2026، وتقارير المجتمع موسومة على أنها كذلك. المصادر مدرجة في النهاية.
في هذه الصفحة
أصلح Google Sign-In في إصدار Play
طابِق التطبيق الذي ثبّته المختبِرون مع اسم الحزمة وبصمة SHA-1 للتوقيع المسجّلين له. نفّذ هذه الخطوات بالترتيب؛ ويليها مسارا Firebase وGoogle Cloud.
تأكّد من النسخة التي تفشل
تحقّق من أن المختبِر ثبّت التطبيق من اختبارك المغلق على Google Play، ودوّن الإصدار الموجود لديه. ثم دوّن معرّف التطبيق النهائي (application ID) لذلك الإصدار. يقول دليل البناء في Android إن معرّف تطبيقك تحدّده الخاصية applicationId، وقد يختلف عن مساحة الاسم (namespace) في الشيفرة المصدرية أو تُضاف إليه لاحقة في نكهة بناء (build flavor). إذا لم يتمكن المختبِر من تثبيت التطبيق أصلًا فتلك مشكلة مختلفة: راجع لماذا لا يكون التطبيق متاحًا للمختبِرين.
افتح توقيع التطبيق في Play
في Play Console، افتح التطبيق وانتقل إلى Protected with Play. نقلت Google توقيع التطبيق إلى هناك في مايو 2026، ويسمّي مركز مساعدتها الخطوة التالية بطريقتين (الجدول أدناه). كلا المسارين ينتهي إلى الصفحة نفسها.
| المسار كما تكتبه Google | أين تستخدمه Google | ما الذي تفتحه هناك |
|---|---|---|
| Protected with Play > Play Store distribution > Go to Play app signing | أين تستخدمه Googleمركز مساعدة Play Console، صفحة Use Play App Signing، قسم تسجيل واجهات API | ما الذي تفتحه هناكApp signing key certificate، ثم قيمة SHA-1 |
| Protected with Play > Play Store protection > Manage Play app signing | أين تستخدمه Googleملاحظات تحديث مايو 2026 من Google Play، وقسم آخر من صفحة المساعدة نفسها | ما الذي تفتحه هناكالصفحة نفسها؛ قد تختلف تسميات القوائم من حساب إلى آخر |
انسخ بصمة SHA-1 لمفتاح توقيع التطبيق
افتح قسم App signing key certificate (شهادة مفتاح توقيع التطبيق)، لا شهادة مفتاح التحميل، وانسخ بصمة SHA-1 منه. إذا عرض Play أكثر من مفتاح توقيع لتطبيقك، فسجّل كل بصمة تنطبق (راجع شهادات التوقيع المتعددة). احتفظ ببصمات التصحيح والبصمات المحلية الحالية وأضف بصمات Play بجانبها. لا تغيّر مفتاح التوقيع (key rotation) لإصلاح تسجيل الدخول.
سجّلها حيث يسجّل تطبيقك الدخول
استخدم مسار Firebase أو مسار Google Cloud، أيهما يستخدمه تطبيقك، واستخدم المشروع نفسه الذي أصدر معرّفات العملاء الموجودة داخل تطبيقك.
أعد اختبار إصدار Play المثبّت
إذا غيّرت تسجيلًا في Firebase أو Google Cloud فقط، فأعد المحاولة بالنسخة المثبّتة من Play مسبقًا قبل أن تبني أي شيء؛ فقد أفاد مطوّرون بأن إصلاحًا اقتصر على التسجيل نجح دون رفع إصدار جديد. أما إذا غيّرت إعدادات مضمّنة في التطبيق أو معرّف عميل أو الشيفرة أو إحدى التبعيات، فارفع إصدارًا جديدًا إلى مسار الاختبار المغلق نفسه واختبره. لا تنشر Google مدة ثابتة لتفعيل البصمة الجديدة، لذا أعد الاختبار بدلًا من انتظار عدد محدد من الساعات.
أضف شهادة Play في Firebase
اختر تطبيق Android المطابق قبل أن تضيف بصمة توقيعه في Play. تتبع الخطوات مساعدة Firebase الخاصة بالبصمات ودليلها لتسجيل الدخول بحساب Google.
- في وحدة تحكم Firebase، افتح المشروع الذي يستخدمه تطبيقك، ثم Project settings > General.
- تحت Your apps، اختر تطبيق Android الذي يطابق اسم حزمته الإصدار الذي يفشل.
- انقر Add fingerprint، والصق بصمة SHA-1 لتوقيع التطبيق في Play واحفظ. أضفها بجانب البصمات الحالية بدلًا من استبدالها.
- تحت Authentication > Sign-in method، تأكّد من أن Google مُفعّل.
- إذا طلب منك Firebase تنزيل ملف
google-services.jsonمحدَّث، فاستبدل الملف في مشروعك. يقول Firebase إن الملف “يحتوي على معلومات عميل OAuth المطلوبة لتسجيل الدخول بحساب Google”، لذا فإن تغيّر الملف يعني إصدارًا جديدًا. تحقّق من أن المشروع والحزمة فيه يطابقان التطبيق الذي يفشل.
أضف بصمة SHA-256 فقط حيث تطلبها خدمة محددة من Firebase. فمصادقة الهاتف مثلًا تستخدم SHA-256 لمسار Play Integrity؛ أما Google Sign-In نفسه فيعتمد على SHA-1.
هيّئ Google Cloud دون Firebase
عميلا OAuth يؤديان مهمتين مختلفتين. عميل Android يسجّل تطبيقك؛ ومعرّف عميل الويب هو الذي يستخدمه طلب الرمز المميز (token).
| نوع العميل | ما الذي يحتويه | أين تستخدمه |
|---|---|---|
| Android | ما الذي يحتويهاسم حزمتك وبصمة SHA-1 لشهادة التوقيع | أين تستخدمهيسجّل هوية التطبيق الأصلي. لا تلصق معرّف هذا العميل في serverClientId. |
| تطبيق ويب (Web application) | ما الذي يحتويهمعرّف عميل الويب | أين تستخدمهقيمة serverClientId أو webClientId في طلب الرمز المميز، والجمهور (audience) الذي يقبله الخادم الخلفي لديك. يصفه مختبر Sign in with Google التعليمي من Google بأنه يعمل “بوصفه العميل الخلفي لخدمة Google Sign-in.” |
- اختر المشروع الذي أصدر معرّفات العملاء الخاصة بك، ثم افتح Google Auth platform > Clients (مساعدة Google Cloud).
- ابحث عن عميل Android موجود بهذا الاسم للحزمة وبصمة SHA-1 هذه قبل أن تنشئ عميلًا آخر.
- إذا لم يكن موجودًا، فاختر Create Client، واضبط Application type على Android، وأدخل اسمًا واسم الحزمة وبصمة SHA-1 لتوقيع التطبيق في Play، ثم Create. يحتوي نموذج Android على حقل لـ SHA-1؛ أما SHA-256 فلا مكان لها هناك.
- سجّل كل زوج من الحزمة والشهادة تحتاج إليه، مثل التصحيح والإصدار المحلي وPlay.
- أبقِ عميل الويب في مكانه لطلب الرمز المميز، ولا تضع أبدًا سرّ العميل (client secret) داخل التطبيق.
أثبت نجاح الإصلاح
تسجيل دخول واحد ناجح لا يثبت أن الإصدار قد أُصلح. قائمة التحقق هذه هي اختبار القبول الذي نوصي به، وليست قاعدة من Google؛ والصف الأخير مهم لأن تسجيل الدخول لدى أحد المطوّرين نجح مرة ثم فشل في المرة التالية، وهي مشكلة جلسة كان فحص واحد سيغفل عنها.
| الفحص | دليل النجاح | إذا فشل |
|---|---|---|
| التطبيق والإصدار الصحيحان | دليل النجاحيؤكد المختبِر التثبيت المقصود من Play والإصدار المقصود | إذا فشلعالِج أولًا مشكلة الإصدار أو وصوله عبر المسار |
| أول تسجيل دخول | دليل النجاحاختيار حساب يعيد المستخدم إلى التطبيق وهو مسجّل الدخول | إذا فشلالتقط الاستثناء الدقيق واستخدم جدول الأخطاء أدناه |
| ميزة محمية | دليل النجاحيستطيع المختبِر استخدام ميزة تتطلب تسجيل الدخول | إذا فشلافحص طريقة تعامل التطبيق والخادم الخلفي مع الرمز المميز |
| تسجيل الخروج ثم الدخول مجددًا | دليل النجاحينجح تسجيل الدخول الثاني دون إعادة التثبيت | إذا فشلافحص التعامل مع الجلسة وتسجيل الخروج من المزوّد |
| جهاز تأثّر سابقًا | دليل النجاحينجح الآن المختبِر نفسه على الجهاز نفسه | إذا فشلقارن الشهادة ونظام التشغيل والحساب والإصدار الفعلي |
| استمرارية الاختبار | دليل النجاحما زال المختبِر مشتركًا في الاختبار وقد وثّقت الإصلاح | إذا فشلعالِج الانضمام إلى الاختبار بمعزل عن تسجيل الدخول |
لماذا يعمل تسجيل الدخول في نسخة التصحيح ويفشل في الاختبار المغلق؟
قد يكون للتطبيق المثبّت عبر Google Play مُوقِّع مختلف عن ملف APK الذي تثبّته محليًا. يشير دليل مصادقة العميل من Google إلى أن “Android Studio يوقّع تطبيقك تلقائيًا بشهادة تصحيح.” أما إصدار الإنتاج الذي تبنيه بنفسك فيستخدم أي مفتاح هُيّئ له ذلك المتغيّر (variant). ومع Play App Signing، يوقّع مفتاح التحميل الخاص بك الحزمة التي ترفعها، وتوقّع Google ملفات APK التي يتلقاها المختبِرون بمفتاح توقيع التطبيق.
لهذه المفاتيح أدوار مختلفة، لكنها ليست دائمًا قيمًا مختلفة: يمكنك تقديم مفتاح التوقيع الخاص بك، وبعض الإعدادات تستخدم مفتاحًا واحدًا لدورين. قارن البصمات الفعلية بدلًا من أسماء المفاتيح.
| النسخة المثبّتة | الشهادة التي تفحصها | الإجراء الأول |
|---|---|---|
| تثبيت من Play عبر الاختبار الداخلي أو المغلق أو المفتوح أو الإصدار العلني مع Play App Signing | الشهادة التي تفحصهاشهادة أو شهادات توقيع التطبيق في Play، الموجودة ضمن Protected with Play | الإجراء الأولسجّل كل بصمة SHA-1 من Play تنطبق على تطبيقك |
| تشغيل نسخة التصحيح من Android Studio | الشهادة التي تفحصهاشهادة التصحيح الخاصة بذلك الجهاز | الإجراء الأولسجّل بصمة SHA-1 تلك لمعرّف التطبيق المطابق |
| ملف APK للإصدار (release) مبني على جهازك | الشهادة التي تفحصهاالشهادة المهيّأة لمتغيّر الإصدار ذاك | الإجراء الأوللا تفترض أن “release” تعني مُوقِّع Google |
| رابط المشاركة الداخلية للتطبيق (Internal app sharing) | الشهادة التي تفحصهاشهادة الاختبار الخاصة بالمشاركة الداخلية للتطبيق | الإجراء الأولسجّلها بشكل منفصل إذا كان المختبِرون يستخدمون هذا المسار |
المشاركة الداخلية للتطبيق ليست الاختبار الداخلي
تقول مساعدة Google الخاصة بالمشاركة الداخلية للتطبيق: “يُعاد توقيع كل ملف APK بشهادة الاختبار هذه.” تجدها ضمن Test and release > Internal testing > Internal app sharing > Uploaders and testers > Internal test certificate. أما مسارا الاختبار الداخلي والاختبار المغلق فيستخدمان مفتاح توقيع التطبيق في Play بدلًا منها.
اقرأ البصمات بنفسك
للإصدارات المبنية على جهازك، يطبع تقرير التوقيع في Gradle بصمتي SHA-1 وSHA-256 لكل متغيّر، ويقرأ keytool مخزن مفاتيح التصحيح مباشرة (أدخل كلمة مرور مخزن المفاتيح عند طلبها):
./gradlew signingReport
keytool -list -v -alias androiddebugkey -keystore ~/.android/debug.keystoreتقرير التوقيع المحلي لا يخبرك بما وقّع نسخة Play. لفحص الإصدار الذي يفشل نفسه، ثبّته من الاختبار المغلق على جهاز، واسحبه باستخدام adb واطبع شهاداته باستخدام apksigner، الذي توثّق Google أنه يعرض “معلومات عن شهادات توقيع ملف APK.” استبدل اسم الحزمة واستخدم المسار الذي يطبعه الأمر الأول:
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 وما زال يفشل
قارن شهادة ملف APK الذي يفشل ومعرّف تطبيقه النهائي ومعرّفات العملاء قبل تغيير مزيد من الإعدادات. انزل في هذا السلّم درجة درجة؛ كل صف يستبعد طبقة واحدة.
| الفحص | ما الذي تقارنه | القرار |
|---|---|---|
| 1. النسخة المثبّتة والمسار | ما الذي تقارنهالتثبيت الفعلي من Play لدى المختبِر مقابل الإصدار الذي قصدت اختباره | القرارتقرير التوقيع المحلي ليس دليلًا على مُوقِّع Play |
| 2. الشهادة | ما الذي تقارنهمخرجات apksigner verify --print-certs على ملف APK الذي يفشل من Play مقابل ما سجّلته |
القرارسجّل كل مُوقِّع تحتاج إليه؛ واحتفظ بالإدخالات الأقدم التي ما زالت تخدم المستخدمين الذين ثبّتوا التطبيق |
| 3. معرّف التطبيق النهائي | ما الذي تقارنهقيمة applicationId للمتغيّر المبني، بما فيها لواحق النكهات، مقابل الحزمة المسجّلة | القرارمساحة الاسم في الشيفرة المصدرية لا تُحتسب |
| 4. المشروع وعميل الويب | ما الذي تقارنهالمشروع ومعرّف عميل الويب اللذان يستخدمهما فعلًا إصدار الإنتاج والخادم الخلفي لديك | القرارخطأ إملائي هنا يعطّل تسجيل الدخول حتى مع بصمات صحيحة |
| 5. وجود المزوّد والعملاء | ما الذي تقارنهتفعيل Google كمزوّد، إضافة إلى عميلي Android والويب المرتبطين به | القرارإذا كان مشروع آخر يملك الزوج، فراجع ملاحظة التعارض أدناه |
| 6. عائلة الخطأ | ما الذي تقارنهالرمز الأصلي 10، أو إلغاء من Credential Manager، أو رفض الخادم الخلفي للرمز المميز، أو عدم تطابق إعادة التوجيه في المتصفح | القرارلكل منها فرع مستقل؛ راجع جدول الأخطاء |
| 7. مشكلة إصدار خاصة بإطار العمل | ما الذي تقارنهتقليص الموارد (resource shrinking)، وإصدار المكتبة المعتمد فعليًا، والتهيئة | القراراعتمد على سجلات التغييرات والإصلاحات المؤكدة، لا على ترقيات أو تخفيضات عشوائية |
الصف 4 ليس نظريًا. في حالة Expo أُبلغ عنها في سبتمبر 2026، لم تغيّر إضافة البصمات شيئًا؛ وكان الإصلاح تصحيح خطأ إملائي في معرّف العميل الذي يقبله الخادم الخلفي.
شهادات توقيع متعددة أو مفاتيح مُرقّاة
قد يحتاج التطبيق الواحد إلى تسجيل أكثر من هوية توقيع. تصف مساعدة Play App Signing الحالية من Google التوقيع الهجين بثلاثة مفاتيح لتوقيع التطبيق وتطلب منك تسجيل بصمات كل منها، كما أن التطبيق الذي رقّى مفتاح توقيعه قد تبقى لديه عمليات تثبيت موقّعة بمفتاح أقدم. سجّل الهويات التي تحملها عمليات التثبيت لديك فعلًا ولا تحذف الإدخالات الأقدم التي ما زالت تعمل. تغيير المفتاح (key rotation) خارج نطاق هذا الدليل، وهو ليس إصلاحًا لتسجيل الدخول.
مشروع آخر يملك بالفعل هذه الحزمة وبصمة SHA-1
تقول مساعدة Firebase الخاصة بالتعارضات إن زوج اسم الحزمة وبصمة SHA-1 “يجب أن يكون فريدًا في جميع مشاريع Firebase وGoogle Cloud.” إذا رفضت وحدة التحكم بصمتك لأن مشروعًا آخر يحملها، فاعرف أي مشروع يملك عميل OAuth ذاك قبل أن تحذف أي شيء. يمكن لدعم Google المساعدة في تحديد موضع التعارض؛ ولا تحذف عملاء أو مشاريع نشطة لتتلمّس طريقك بالتخمين.
هل الخطأ 10 هو نفسه 12500 أو 12501 أو canceled؟
لا. اقرأ الخطأ الدقيق والمكتبة التي أنتجته قبل أن تعامل كل تسجيل دخول فاشل على أنه مشكلة واحدة. يعرّف مرجع رموز الحالة الشائعة من Google القيمة DEVELOPER_ERROR = 10 بأنها “التطبيق مُهيّأ بشكل خاطئ.” أما الرموز الأخرى أدناه فمصدرها حزمة SDK القديمة play-services-auth 21.6.0 من Google.
| ما تراه | معناه | الخطوة التالية |
|---|---|---|
ApiException: 10 أو DEVELOPER_ERROR |
معناهخطأ في تهيئة التطبيق | الخطوة التاليةقارن المُوقِّع والحزمة والمشروع ومعرّفات العملاء |
12500 |
معناهSIGN_IN_FAILED: “حدث فشل في تسجيل الدخول لا يمكن التعافي منه” |
الخطوة التاليةاقرأ السجلات المحيطة؛ ولا تعامله على أنه الخطأ 10 |
12501 |
معناهSIGN_IN_CANCELLED: “تم إلغاء إجراء تسجيل الدخول” |
الخطوة التاليةتحقّق مما إذا كان المستخدم قد ألغى فعلًا، وأي واجهة API أنتجت الرمز |
canceled في Credential Manager أو Flutter |
معناهإلغاء حقيقي أو مشكلة في التهيئة | الخطوة التاليةافحص تفاصيل الاستثناء والإعداد؛ ودع المستخدم يبدأ محاولة جديدة بعد أن تنتهي من التشخيص |
NoCredentialException |
معناهلم تُرجَع أي بيانات اعتماد؛ وهذا ليس تشخيصًا لمشكلة في الشهادة | الخطوة التاليةتحقّق من توفّر الحساب ومن تهيئة الطلب، إضافة إلى التسجيل |
| رمز Google يعمل، والخادم الخلفي يرفضه | معناهمرحلة لاحقة لمرحلة الحصول على بيانات اعتماد Google | الخطوة التاليةتحقّق من الجمهور (audience) ومعرّفات العملاء التي يقبلها الخادم الخلفي |
redirect_uri_mismatch |
معناهإعادة توجيه OAuth في المتصفح لا تطابق أي عنوان URI معتمد | الخطوة التاليةأصلح إعدادات عنوان الاستدعاء (callback) لهذا المسار |
| “Item not found” على رابط Play | معناهمشكلة في التثبيت أو الأهلية، لا في تسجيل الدخول | الخطوة التاليةاتبع فحوص التطبيق غير المتاح |
Google Sign-In القديم وCredential Manager
تذكر ملاحظات إصدار Play services من Google إيقاف واجهات Google Sign-In البرمجية (deprecation) في play-services-base بتاريخ 16 أبريل 2024، وأعلنت Google الانتقال إلى Credential Manager في 11 سبتمبر 2024. ثم أُزيلت هذه الواجهات من play-services-auth 22.0.0 في 26 أغسطس 2026 ومن play-services-base 18.11.0 في 17 سبتمبر 2026، مع الملاحظة “Removed the APIs related to Google Sign-in.” (أُزيلت الواجهات البرمجية المتعلقة بـ Google Sign-in). هذا تغيير في حزمة SDK؛ ولا يحدّد موعدًا لتوقّف التطبيقات المثبّتة بالفعل. ينبغي أن تتبع الشيفرة الجديدة والترقيات دليل الترحيل من Google.
تفشل الواجهتان بطريقتين مختلفتين. لا يوجد الخطأ 10 في Credential Manager؛ ويحذّر دليل استكشاف الأخطاء وإصلاحها الخاص به من أن “العدد الكبير من "الإلغاءات" قد يشير في الواقع إلى خطأ في التهيئة.” لذا قد يكون الإلغاء عطلًا في التهيئة أو إلغاءً حقيقيًا، أما NoCredentialException فإشارة مختلفة أخرى.
فحوص Flutter وReact Native وExpo وUnity
تنطبق فحوص الهوية الأصلية أعلاه على كل إطار عمل، لكن الإعداد والتهيئة وإعدادات البناء تختلف. استخدم المسار الخاص بإطار عملك وإصدار المكتبة الذي يعتمده تطبيقك فعلًا.
| إطار العمل | فحوص محددة | لا تفترض |
|---|---|---|
| Flutter | فحوص محددةانتقل تطبيق Android للمكتبة، google_sign_in_android، إلى Credential Manager في الإصدار 7.0.0. مرّر معرّف عميل الويب بوصفه serverClientId. يذكر سجل التغييرات الخاص بها للإصدار 7.2.16 أنه “يمنع أدوات تقليص الموارد من حذف المورد default_web_client_id”، وهذا مهم للأعطال التي تظهر في إصدار الإنتاج وحده. |
لا تفترضأن كل نتيجة canceled هي مشكلة في SHA، أو أن الرجوع إلى إصدار أقدم إصلاح شامل. |
| React Native | فحوص محددةحدّد أي واجهة API من المكتبة تستخدم، ومرّر معرّف عميل الويب بوصفه webClientId، وتحقّق من applicationId الفعلي ومن ملف APK الذي يفشل. يذكر دليل استكشاف الأخطاء وإصلاحها حالة “تسجيل الدخول لا يعمل عند التنزيل من Play Store” ويقدّم أمرًا لفحص الإعدادات (أدناه). |
لا تفترضأن إغلاق بلاغ على متتبّع المشكلات يثبت حدوث الإصلاح. |
| Expo | فحوص محددةيحتاج تسجيل الدخول الأصلي بحساب Google إلى إصدار تطوير أو إصدار مخصص؛ يقول دليل Expo: “لا يمكن استخدام هذه المكتبات في Expo Go لأنها تتطلب شيفرة أصلية مخصصة.” افصل بين شهادة توقيع EAS أو الشهادة المحلية وبين شهادة توقيع التطبيق في Play. | لا تفترضأن Expo Go يعيد إنتاج مسار إصدار الإنتاج، أو أن إعادة البناء تصلح معرّف عميل خاطئًا في الخادم الخلفي. |
| Unity | فحوص محددةقرّر هل تستخدم Firebase Authentication أم Unity Authentication، واحصل على رمز Google ID عبر تكامل المنصة المدعوم، ثم بادِله مع ذلك الخادم الخلفي (دليل Firebase لـ Unity). أُرشف نموذج تسجيل الدخول القديم من Google لـ Unity في 19 أبريل 2026. | لا تفترضأن تسجيل الدخول إلى Play Games وتسجيل الدخول بحساب Google هما التكامل نفسه. |
بالنسبة إلى React Native، يوفّر القائمون على المكتبة أداة لفحص الإعدادات يمكنك تشغيلها من جذر المشروع:
npx @react-native-google-signin/config-doctorما الذي يتغيّر مع Supabase أو Facebook أو Apple أو Auth0؟
المزوّد ومسار تسجيل الدخول هما ما يحدّد أي شهادة أو معرّف عميل أو عنوان استدعاء يجب أن يتطابق. بصمة SHA-1 من Google هي الحل لتسجيل الدخول الأصلي بحساب Google؛ أما مع المزوّدين الآخرين فقد تكون التجزئة الخاطئة، أو بالتنسيق الخاطئ، أو لا علاقة لها بالأمر.
| المزوّد أو المسار | ما الذي يجب أن يتطابق | أين تضبطه |
|---|---|---|
| Google الأصلي مع Firebase | ما الذي يجب أن يتطابقالحزمة المثبّتة وبصمة SHA-1، وعميل الويب، وتفعيل Google كمزوّد | أين تضبطهبصمات Project settings في Firebase، إضافة إلى Authentication |
| Google الأصلي مع Supabase | ما الذي يجب أن يتطابقهوية Android الأصلية ومعرّف عميل الويب؛ يقول دليل Supabase: “معرّف عميل الويب هو الذي يُستخدم في تطبيق Android الخاص بك.” | أين تضبطهعميلا Android والويب في Google، ثم إعدادات مزوّد Google في Supabase |
| OAuth عبر المتصفح في Supabase | ما الذي يجب أن يتطابقعميل الويب، وعنوان الاستدعاء في Supabase، ورابط العودة إلى تطبيقك | أين تضبطهعناوين URI المعتمدة لإعادة التوجيه في Google وإعدادات إعادة التوجيه في Supabase؛ إصلاح SHA لا ينطبق هنا |
| Facebook على Android | ما الذي يجب أن يتطابقتجزئة مفتاح (key hash) بترميز Base64 مُنشأة من بايتات SHA-1 لشهادة التوقيع، لا من الصيغة الست عشرية المفصولة بنقطتين | أين تضبطهإعدادات تطبيق Facebook، ثم Android key hashes (المسار كما هو موثّق في دليل Expo لـ Facebook) |
| تسجيل الدخول بـ Apple عبر الويب على Android | ما الذي يجب أن يتطابقمعرّف الخدمات (Services ID) والنطاق وعنوان URL للعودة | أين تضبطهإعدادات Sign in with Apple للويب من Apple؛ وليست آلية DEVELOPER_ERROR الخاصة بـ Google |
| Apple عبر Firebase على Android | ما الذي يجب أن يتطابقإعداد Apple إضافة إلى بصمة SHA-1 للتطبيق | أين تضبطهدليل Firebase لـ Apple: “حدّد بصمة SHA-1 لتطبيقك إن لم تكن قد فعلت ذلك بعد.” |
| Auth0 على Android | ما الذي يجب أن يتطابقعناوين URL المسموح بها للاستدعاء ومخطط التطبيق (scheme)؛ وهوية روابط التطبيق (App Links) حيث تُستخدم | أين تضبطهإعدادات التطبيق في Auth0؛ ويستخدم ملف readme لحزمة Android SDK الخاص به تجزئات مفاتيح SHA-256 لإعداد روابط التطبيق |
| مصادقة الهاتف في Firebase | ما الذي يجب أن يتطابقSHA-256 لـ Play Integrity، وSHA-1 لمسار reCAPTCHA البديل | أين تضبطهمصادقة الهاتف في Firebase: مسار منفصل عن تسجيل الدخول بحساب Google |
لا تنقل تسجيل الدخول إلى WebView
توجيه تسجيل الدخول بحساب Google عبر WebView مضمّن ليس حلًا بديلًا. تنص سياسات OAuth 2.0 من Google على أن المطوّرين “يجب ألا يوجّهوا طلب تفويض Google OAuth 2.0 إلى وكيل مستخدم مضمّن.”
ما الذي ينبغي أن يرسله المختبِرون إلى المطوّر؟
التقرير المفيد يحدّد إصدار Play الذي يفشل والنقطة الدقيقة التي يتوقف عندها تسجيل الدخول. لا يستطيع المختبِر إصلاح تسجيل OAuth بإعادة المحاولة، فمهمته تقديم الدليل لا الإلحاح. انسخ هذا القالب وأرسله إلى المختبِرين:
التطبيق ورابط الاختبار في Play:
إصدار التطبيق المثبّت أو رقم البناء:
مصدر التثبيت: الاختبار المغلق على Play / مسار آخر
الجهاز وإصدار Android:
التاريخ والوقت والمنطقة الزمنية:
نص الخطأ الدقيق أو لقطة شاشة مع إخفاء البيانات الحساسة:
أين توقف: قبل نافذة اختيار الحساب / بعد اختيار الحساب / بعد العودة إلى التطبيق
هل فتحت طريقة تسجيل دخول أخرى التطبيق؟
نتيجة إعادة الاختبار والإصدار:اطلب من المختبِرين البقاء مشتركين في الاختبار أثناء إصلاحك للمشكلة. لا تطلب أبدًا كلمات مرور أو رموز OAuth المميزة أو مفاتيح خاصة أو صلاحية الدخول إلى Play Console. بعد التغيير، اطلب من المختبِر نفسه فتح ميزة تتطلب تسجيل الدخول، ثم تسجيل الخروج والدخول مجددًا، وتدوين الإصدار والنتيجة.
هل يؤثر الخطأ 10 في اختباري المغلق أو في إذن الإصدار العلني؟
خطأ تهيئة تسجيل الدخول منفصل عن الانضمام إلى الاختبار. الخطأ 10 ليس رمز رفض بموجب سياسات Play، ولم نجد أي قاعدة من Google تقول إنه يعيد ضبط فترة اشتراك المختبِرين. تشجّعك صفحة متطلبات الاختبار من Google على تحسين التطبيق أثناء الاختبار المغلق، لذا أبقِ المختبِرين مشتركين وانشر الإصلاح على مسار الاختبار المغلق نفسه. هذه قراءة للقواعد المنشورة، وليست وعدًا يشمل كل الحالات.
مع ذلك، تعطّل تسجيل الدخول أمر مهم. تقول سياسة الأداء الوظيفي في Google Play: “لا نسمح بالتطبيقات التي تتعطّل أو تُغلق قسرًا أو تتجمّد أو تعمل بشكل غير طبيعي بأي طريقة أخرى”، كما أن جدار تسجيل الدخول يمنع المختبِرين من الوصول إلى الميزات التي يُفترض أن يختبروها. أصلحه قبل أن تطلب الإصدار العلني، وزوّد المراجعين ببيانات تسجيل دخول صالحة. إذا عادت نتيجة المراجعة بالفعل، فراجع الرفض بسبب Broken Functionality.
للتوضيح: تحتاج حسابات المطوّرين الشخصية التي أُنشئت بعد 13 نوفمبر 2023 إلى 12 مختبِرًا على الأقل مشتركين بلا انقطاع لمدة 14 يومًا متواصلة قبل طلب الإصدار العلني لذلك التطبيق. وبعد تقديم الطلب، تقول Google: “تستغرق هذه العملية عادةً 7 أيام أو أقل، ولكنّها قد تستغرق وقتًا أطول في بعض الأحيان.” إذا كان بعض المختبِرين غير محتسبين في العدد، فتحقّق من طريقة دعوتهم قبل أن تلمس تسجيل الدخول.
هل تحتاج إلى مختبِرين حقيقيين لمدة 14 يومًا؟
لا يستطيع المختبِرون إصلاح تسجيل OAuth، لذا اجعل تسجيل الدخول يعمل أولًا. وبمجرد أن يعمل، توفّر PrimeTestLab (برايم تست لاب) 12+ مختبِرًا حقيقيًا يثبّتون إصدار Play الخاص بك على هواتف Android حقيقية ويبقون مشتركين طوال الأيام الـ 14 كاملة، ابتداءً من $19.99 (مع 5% رسوم خدمة إضافية). إذا لم تمنحك Google إذن الإصدار العلني بعد اكتمال الاختبار، فلك الخيار بين إعادة الاختبار مجانًا أو استرداد كامل المبلغ. تعرّف على طريقة عمل الاختبار المغلق بـ 12 مختبِرًا.
الأسئلة الشائعة
لماذا يعمل Google Sign-In في نسخة التصحيح ولا يعمل في الاختبار المغلق؟
قد يكون ملف APK الخاص بالتصحيح والتطبيق المنزَّل من Google Play موقّعين بشهادتين مختلفتين، لذا فإن تسجيل بصمة التصحيح لا يهيّئ إصدار Play. ابدأ ببصمة SHA-1 لتوقيع التطبيق في Play، ثم تحقّق من اسم الحزمة النهائي لإصدار الإنتاج ومن معرّفات العملاء التي يستخدمها التطبيق فعلًا.
أين أجد الآن بصمة SHA-1 الخاصة بـ Play App Signing؟
افتح صفحة Protected with Play الخاصة بتطبيقك في Play Console. تصف مساعدة Google المسار Play Store distribution ثم Go to Play app signing؛ بينما تسمّيهما نصوص أخرى حالية من Google باسم Play Store protection وManage Play app signing. افتح قسم App signing key certificate وانسخ بصمة SHA-1، مع التحقق من أي مفاتيح إضافية معروضة لتطبيقك.
هل أحتاج إلى SHA-1 أم SHA-256 من أجل Google Sign-In؟
يتعرّف عميل OAuth الخاص بـ Android لدى Google على تطبيقك من خلال اسم حزمته وبصمة SHA-1 لشهادة التوقيع، ولا تحلّ SHA-256 محل هذا الحقل. للخدمات الأخرى متطلباتها الخاصة: فمصادقة الهاتف في Firebase تستخدم SHA-256 لـ Play Integrity وSHA-1 لمسار reCAPTCHA البديل. هيّئ كل خدمة وفق المسار الذي يستخدمه تطبيقك.
أضفت بصمة SHA-1 بالفعل. ما الذي أتحقق منه بعد ذلك؟
تأكّد من أنها تخص التطبيق المثبّت من Play، لا مفتاح التحميل أو مفتاح التصحيح. ثم قارن معرّف التطبيق النهائي، ومشروع Firebase أو Cloud، ومعرّف عميل الويب. إذا كانت لتطبيقك عدة شهادات توقيع، فتحقّق منها أيضًا. خطأ إملائي في معرّف العميل الذي يقبله الخادم الخلفي قد يعطّل تسجيل الدخول حتى عندما تكون البصمات صحيحة.
هل عليّ رفع ملف AAB آخر بعد إضافة بصمة؟
ليس بالضرورة. يفيد مطوّرون بأن إصلاحًا اقتصر على التسجيل في Firebase أو Google Cloud نجح مع التطبيق المثبّت مسبقًا. أما تغيير معرّف العميل أو ملف الإعدادات أو الشيفرة أو إحدى التبعيات فيجب أن يصل إلى المختبِرين في إصدار جديد. تحقّق مما غيّرته، ثم افحص التثبيت الفعلي من Play بدلًا من إعادة البناء مرارًا دون تشخيص.
كم تستغرق البصمة الجديدة حتى تعمل؟
لا تنشر Google مدة انتشار خاصة بالبصمات، ولم تقِس سلاسل النقاش التي راجعناها بين المطوّرين أي مدة. احفظ الإعدادات الصحيحة وأعد المحاولة. إذا استمر الفشل، فافحص الشهادة المثبّتة وإعدادات العميل بدلًا من انتظار عدد ثابت من الساعات، لأن الانتظار لا يصلح عدم التطابق.
لماذا تظهر رسالة canceled مع أنني لم ألغِ شيئًا؟
بعض تكاملات Credential Manager وأطر العمل تبلّغ عن مشكلة في التهيئة أو التفويض على أنها إلغاء، مع أن الإلغاء قد يكون حقيقيًا أيضًا. سجّل نوع الاستثناء ورسالته، وراجع دليل استكشاف الأخطاء الخاص بإطار عملك، وافصل بين الواجهة الحالية والحالة القديمة 12501 SIGN_IN_CANCELLED قبل تغيير الإعدادات.
هل معرّف عميل Android هو الذي أضعه في serverClientId؟
لا. في تكاملات Google الأصلية الموثّقة، تكون قيمة serverClientId أو webClientId هي عميل OAuth من نوع تطبيق الويب (Web application) المستخدم في طلب الرمز المميز. أما عميل Android فيسجّل حزمتك وشهادة التوقيع. هيّئ الاثنين، وتأكّد من أن الخادم الخلفي يقبل جمهور الرمز (audience) المقصود بدلًا من تبديل معرّفات العملاء عشوائيًا.
هل يعيد الخطأ 10 بدء اختباري المغلق لمدة 14 يومًا؟
لم نجد أي قاعدة من Google تقول إن هذا الخطأ يعيد ضبط فترة الاشتراك، وGoogle تشجّع على إجراء التحسينات أثناء الاختبار المغلق، لذا أبقِ المختبِرين منضمّين وأصلح المشكلة على المسار الحالي. لكن هذا ليس علامة على أن التطبيق جاهز: فجدار تسجيل الدخول قد يمنع الاختبار المفيد ويترك مشكلة في الأداء الوظيفي يجب إصلاحها قبل تقديم الطلب.
ما الذي ينبغي أن أطلب من المختبِر إرساله إليّ؟
اطلب الإصدار المثبّت، ورابط الاختبار في Play، والجهاز وإصدار Android، والخطأ الدقيق، والخطوة التي يتوقف عندها تسجيل الدخول. تفيد لقطة شاشة مع إخفاء البيانات الحساسة أو تسجيل قصير. بعد الإصلاح، اطلب من المختبِر نفسه استخدام ميزة تتطلب تسجيل الدخول، ثم تسجيل الخروج والدخول مجددًا، دون مشاركة أي بيانات اعتماد.
الخلاصة
الخلاصة
الخطأ 10 في Google Sign-In يعني أن التطبيق مُهيّأ بشكل خاطئ، وعندما تفشل نسخة Play وحدها، فشهادة التوقيع هي أول ما تفحصه. انسخ بصمة SHA-1 لمفتاح توقيع التطبيق من Protected with Play، وسجّلها مع اسم الحزمة النهائي للإصدار في مشروع Firebase أو Google Cloud نفسه الذي يستخدمه تطبيقك، وأبقِ معرّف عميل الويب في serverClientId، وأعد اختبار الإصدار الذي ثبّته المختبِرون، بما في ذلك تسجيل دخول ثانٍ. إذا استمر الفشل، فقارن شهادة ملف APK المثبّت ومعرّف التطبيق ومعرّفات العملاء قبل تغيير أي شيء آخر.
المصادر التي تم التحقق منها في 16 أكتوبر 2026
تسميات القوائم في Play Console وFirebase هي أسرع الحقائق تغيّرًا في هذه الصفحة. إذا لم يعد أحد المسارات أعلاه يطابق وحدة التحكم لديك، فابحث عن توقيع التطبيق في Play ضمن Protected with Play، وعن البصمات تحت تطبيق Android الخاص بك في Project settings داخل Firebase.