لماذا تختلف قيم SHA-1 الخاصة بـ debug وrelease لدي؟

لأنهما يأتيان من keystores مختلفين. يُنشأ keystore الخاص بـ debug تلقائيًا ومرتبط بالجهاز، بينما keystore الخاص بـ release/upload هو المفتاح الدائم الذي أنشأته بنفسك. من الطبيعي أن تختلف بصمتاهما؛ عليك إضافة كليهما بشكل منفصل إلى Firebase.

هل يجب أن أستخدم SHA-1 أم SHA-256؟

استخدم أيًا كانت الميزة التي تدمجها تطلبه؛ إذا لم تكن متأكدًا، أضف كليهما. يطبع أمر keytool -list -v كليهما بالفعل في نفس المخرجات، لذا لا تحتاج إلى تشغيل أمر منفصل لكل واحد.

أحصل على "command not found" عند تشغيل keytool — ماذا يجب أن أفعل؟

يأتي keytool مرفقًا مع JDK ولا يمكن العثور عليه مباشرة إذا لم يكن ضمن PATH لديك. على macOS/Linux يكون JDK عادةً موجودًا بالفعل في PATH؛ وإن لم يكن كذلك، أشر إلى دليل bin الخاص بـ JDK الذي ثبّته Android Studio. على Windows، الطريقة الأكثر موثوقية هي تشغيل flutter doctor -v والبحث عن سطر "Java binary at:" في مخرجاته لتحديد دليل bin الخاص بذلك JDK؛ فافتراض المسار "%JAVA_HOME%\bin\keytool" قد يكون مضللًا إذا لم يكن المتغير معرَّفًا أو كان لديك أكثر من JDK مثبّت.

كم من الوقت يستغرق حتى تصبح البصمة التي أضفتها إلى Firebase نشطة؟

عادةً ما تصبح نشطة خلال دقائق قليلة. بالنسبة لبعض الميزات مثل Google Sign-In أو App Check، قد تحتاج إلى إعادة تنزيل ملف google-services.json المحدَّث ووضعه مجددًا في مشروعك بعد إضافتها؛ وإلا فلن يتعرف الملف القديم على البصمة الجديدة.

← كل المقالات

المدونة

كيفية الحصول على بصمة SHA-1 وSHA-256 (keytool، Firebase)

تاريخ النشر: 19 يوليو 2026آخر تحديث: 25 يوليو 2026قراءة 7 دقائق

ما هي بصمة SHA-1/SHA-256، وأين تُطلب؟

البصمة هي قيمة تجزئة (hash) مشتقة من الشهادة التي توقّع تطبيقك؛ وهي تثبت أي شهادة أنتجت حزمة معينة. ينتج كل زوج keystore/alias لتطبيق Android بصمته الخاصة — فنفس التطبيق الموقّع بـ keystore مختلف يعطي SHA-1 مختلفًا.

تُطلب هذه القيمة غالبًا في ثلاثة أماكن: عند إضافة تطبيق Android في وحدة تحكم Firebase (لميزات مثل Google Sign-In وPhone Authentication وApp Check)، عند تقييد مفتاح API لـ Maps SDK for Android بواسطة اسم الحزمة + SHA-1 في Google Cloud Console، وفي ملف assetlinks.json الذي تستضيفه على خادمك للتحقق التلقائي من Android App Links.

طُلب SHA-1 منذ فترة طويلة في سيناريوهات كلاسيكية مثل Google Sign-In وتقييد مفتاح API الخاص بـ Maps؛ أما SHA-256 فمطلوب للتحقق من App Links (assetlinks.json) وبعض ميزات Firebase الأحدث. يطبع أمر keytool -list -v كليهما في نفس المخرجات، لذا يغطي أمر واحد أيهما طُلب منك.

الحصول على SHA من keystore الخاص بـ debug

ينشئ Android Studio وFlutter تلقائيًا keystore من نوع debug للتطوير المحلي، ويأتي بمعلومات ثابتة: يوجد في ~/.android/debug.keystore على macOS/Linux، وفي C:\Users\<اسم_المستخدم>\.android\debug.keystore على Windows؛ الـ alias هو دائمًا androiddebugkey، وكلمتا مرور المخزن والمفتاح هما android.

باستخدام هذه المعلومات، يكون الأمر: keytool -list -v -keystore ~/.android/debug.keystore -alias androiddebugkey -storepass android -keypass android. تُظهر المخرجات سطري "SHA1:" و"SHA256:"، وكلاهما بتنسيق أزواج سداسية عشرية مفصولة بنقطتين رأسيتين.

تعمل هذه البصمة فقط لبنيات debug؛ كما أن keystore الخاص بـ debug مرتبط بالجهاز — فملف debug.keystore الخاص بكل مطوّر وكل جهاز CI ينتج SHA-1 مختلفًا. إذا كنت تعمل ضمن فريق، يحتاج كل عضو (وكذلك CI) إلى إضافة SHA-1 الخاص بـ debug لديه بشكل منفصل إلى Firebase؛ وهذا هو السبب الأكثر شيوعًا لمشكلة "Google Sign-In يعمل عندي لكن لا يعمل عند زميلي".

الحصول على SHA من keystore الخاص بـ release/upload

إذا كان لديك بالفعل keystore من نوع release أو upload (نشرح كيفية إنشائه بـ keytool في دليلنا الآخر)، فإن الأمر يأخذ نفس الشكل — ما عليك سوى توجيهه إلى ملفك وalias الخاص بك: keytool -list -v -keystore /path/to/your/upload-keystore.jks -alias upload. سيطلب منك كلمة مرور المخزن التي حددتها عند إنشاء الـ keystore.

يمكنك قراءة هذه التفاصيل من ملف android/key.properties الخاص بك (storeFile، keyAlias)؛ إدخال كلمة المرور تفاعليًا عند طلبها بدلًا من تمريرها في سطر الأوامر يتجنب تركها كنص عادي في سجل الأوامر الخاص بك.

ينتمي SHA-1/SHA-256 الناتج هنا إلى "upload key" الخاص بك. إذا كان تطبيقك مسجّلًا في Play App Signing (إلزامي للتطبيقات الجديدة منذ 2021)، فقد لا تتطابق هذه القيمة مع التوقيع الفعلي للحزمة الموزَّعة على المستخدمين — يتناول القسم التالي ذلك.

ضمن Play App Signing: debug مقابل upload مقابل app signing key (الخطأ الأول)

مع تفعيل Play App Signing، توقّع ملف AAB بمفتاح upload key الخاص بك، لكن Google Play يعيد توقيع الحزمة بمفتاح "app signing key" الخاص به قبل توزيعها على المستخدمين. النتيجة: شهادة التطبيق الفعلي الذي يحمّله المستخدمون من المتجر لا تتطابق مع SHA-1 الذي تستخرجه من keystore الخاص بـ upload المحلي لديك.

هذا بالضبط هو الخطأ الأكثر شيوعًا: يضيف المطوّر SHA-1 من keystore الخاص بـ upload المحلي إلى Firebase، ويعمل كل شيء على جهازه الخاص وفي بنيات الاختبار الداخلية، لكن بالنسبة للمستخدمين الحقيقيين الذين يحمّلون من Play Store، يفشل Google Sign-In أو Maps API بصمت — لأن حزمة المتجر تحمل شهادة مختلفة.

احصل على القيم الصحيحة من شاشة Protected with Play > Play Store protection > Manage Play app signing في Play Console، حيث تُدرَج شهادتان منفصلتان: "App signing key certificate" (التوقيع الفعلي الذي يستلمه المستخدمون) و"Upload key certificate". تُدرِج كل منهما قيم SHA-1 وSHA-256 وMD5 الخاصة بها في هذه الشاشة.

الحل العملي: يتيح لك Firebase تسجيل أكثر من بصمة واحدة لكل تطبيق Android. أضف SHA-1 الخاص بـ keystore الـ debug، وSHA-1 الخاص بـ upload key، وSHA-1 الخاص بـ app signing key في آنٍ واحد؛ وبهذا يتم التحقق بشكل صحيح من التطوير المحلي، وبنيات الاختبار الداخلية الموزَّعة مباشرة كملف APK، وعمليات التثبيت الحقيقية من Play Store.

إضافة بصمة SHA إلى Firebase

اذهب إلى Firebase Console > Project settings (أيقونة الترس) > "Your apps"، وابحث عن بطاقة تطبيق Android الخاص بك، وانتقل إلى حقل "SHA certificate fingerprints"، وأضف قيمة SHA-1 أو SHA-256 من مخرجات keytool، ثم احفظ. يمكنك إضافة أي عدد من البصمات تحتاجه إلى نفس بطاقة التطبيق.

عند اللصق، انسخ مخرجات keytool تمامًا كما طُبعت (أزواج سداسية عشرية مفصولة بنقطتين رأسيتين)؛ يقبل Firebase القيمة بفواصل أو بدونها، لكن إعادة كتابتها يدويًا تترك مجالًا لأخطاء النسخ. بالنسبة لبعض الميزات المعتمدة على SHA مثل Google Sign-In أو App Check، يُنصح بإعادة تنزيل ملف google-services.json المحدَّث ووضعه مجددًا في مشروعك بعد إضافة بصمة.

لأن خزنة Keystore من Vibeloy تخزّن ملف الـ keystore وكلمات المرور الخاصة بك بتشفير من طرف إلى طرف، فإنها تتيح لك عرض ونسخ قيم SHA-1/SHA-256 بنقرة واحدة من الخزنة، دون البحث عن مسار الملف وكلمة المرور في كل مرة تحتاج فيها إلى keytool. هذه ميزة premium في Vibeloy.

الأسئلة الشائعة

لماذا تختلف قيم SHA-1 الخاصة بـ debug وrelease لدي؟: لأنهما يأتيان من keystores مختلفين. يُنشأ keystore الخاص بـ debug تلقائيًا ومرتبط بالجهاز، بينما keystore الخاص بـ release/upload هو المفتاح الدائم الذي أنشأته بنفسك. من الطبيعي أن تختلف بصمتاهما؛ عليك إضافة كليهما بشكل منفصل إلى Firebase.
هل يجب أن أستخدم SHA-1 أم SHA-256؟: استخدم أيًا كانت الميزة التي تدمجها تطلبه؛ إذا لم تكن متأكدًا، أضف كليهما. يطبع أمر keytool -list -v كليهما بالفعل في نفس المخرجات، لذا لا تحتاج إلى تشغيل أمر منفصل لكل واحد.
ضمن Play App Signing، أي SHA يجب أن أضيفه إلى Firebase؟: أضف كلًا من SHA الخاص بـ upload key وSHA الخاص بـ app signing key — يمكنك الحصول على كليهما من شاشة Protected with Play > Play Store protection > Manage Play app signing في Play Console. إضافة القيمة من keystore الخاص بـ upload المحلي لديك فقط ستجعل الميزة تفشل مع المستخدمين الحقيقيين الذين يحمّلون من Play Store.
أحصل على "command not found" عند تشغيل keytool — ماذا يجب أن أفعل؟: يأتي keytool مرفقًا مع JDK ولا يمكن العثور عليه مباشرة إذا لم يكن ضمن PATH لديك. على macOS/Linux يكون JDK عادةً موجودًا بالفعل في PATH؛ وإن لم يكن كذلك، أشر إلى دليل bin الخاص بـ JDK الذي ثبّته Android Studio. على Windows، الطريقة الأكثر موثوقية هي تشغيل flutter doctor -v والبحث عن سطر "Java binary at:" في مخرجاته لتحديد دليل bin الخاص بذلك JDK؛ فافتراض المسار "%JAVA_HOME%\bin\keytool" قد يكون مضللًا إذا لم يكن المتغير معرَّفًا أو كان لديك أكثر من JDK مثبّت.
كم من الوقت يستغرق حتى تصبح البصمة التي أضفتها إلى Firebase نشطة؟: عادةً ما تصبح نشطة خلال دقائق قليلة. بالنسبة لبعض الميزات مثل Google Sign-In أو App Check، قد تحتاج إلى إعادة تنزيل ملف google-services.json المحدَّث ووضعه مجددًا في مشروعك بعد إضافتها؛ وإلا فلن يتعرف الملف القديم على البصمة الجديدة.

الأداة ذات الصلة

افتح خزنة Keystore من Vibeloy

← كل المقالات العودة إلى الرئيسية