إجابة سريعة
إذا كان تطبيق TWA يعمل بملء الشاشة عندما تثبّت نسختك بنفسك لكنه يُظهر شريط المتصفح عند تثبيته من جوجل بلاي، فتحقّق أولًا مما إذا كان موقعك يذكر شهادة التوقيع الخاصة بجوجل بلاي. في Play Console، افتح Play app signing ضمن Protected with Play وانسخ بصمة SHA-256 لشهادة مفتاح توقيع التطبيق. أضفها إلى المصفوفة sha256_cert_fingerprints في https://your-domain/.well-known/assetlinks.json، وقدّم هذا الملف عبر HTTPS باستجابة HTTP 200 مباشرة، دون إعادة توجيه، وبنوع application/json، ثم اختبر مجددًا بنسخة مثبّتة من أحد مسارات الاختبار في جوجل بلاي. وإذا كانت البصمة مطابقة أصلًا، فافحص الانتقال خارج المصدر الذي تم التحقّق منه، وعمليات إعادة التوجيه، والمتصفح المستخدَم.
أصلحه بهذا الترتيب
ثم اختبر النسخة المثبّتة من جوجل بلاي، لا نسخة ثبّتها بنفسك.
يتناول هذا الدليل إصلاحًا واحدًا: الربط بين موقعك والنسخة التي يسلّمها جوجل بلاي. ولا يتناول بناء تطبيق TWA نفسه ولا مراجعة جوجل بلاي للتطبيق، فلكلٍّ منهما دليله المرتبط أدناه. تمت مراجعة كل صفحة من صفحات جوجل المذكورة هنا في 16 أكتوبر 2026، والمصادر مدرجة في النهاية.
في هذا الدليل
لماذا يظهر شريط المتصفح في نسخة جوجل بلاي فقط
يتحقّق Chrome من تطبيق TWA بمقارنة الشهادة التي وُقّع بها التطبيق المثبّت مع البصمات التي ينشرها موقعك. وعندما يفشل هذا التحقّق، يذكر دليل البدء السريع لـ TWA من Chrome أن المتصفح يعود إلى عرض موقعك على شكل Custom Tab. وهذا البديل هو شريط العنوان الذي تراه.
مع Play App Signing توجد عادةً شهادتان. أنت توقّع الحزمة التي ترفعها بمفتاح الرفع (upload key)، وجوجل توقّع ملفات APK التي تسلّمها بمفتاح توقيع التطبيق. وتذكر صفحة مفاهيم Android لمطوّري الويب من Chrome أن بصمة مفتاح توقيع التطبيق هي التي تطابق تطبيقك عند تنزيله من متجر Play. لذلك فإن الملف الذي لا يذكر سوى شهادتك المحلية ينجح على جهازك ويفشل على كل هاتف ثبّت التطبيق من جوجل بلاي.
المفتاحان ليسا مختلفين دائمًا. تصف وثائق توقيع التطبيقات في Android إعدادات يكون فيها المفتاح نفسه هو مفتاح توقيع التطبيق ومفتاح الرفع معًا. لذا فالإصلاح هو مقارنة الشهادات الفعلية، لا افتراض أيّها لديك.
| مصدر النسخة | موقّعة بـ | ما يحتاجه assetlinks.json |
|---|---|---|
| مثبّتة من مسار اختبار في جوجل بلاي أو من الإصدار العلني | موقّعة بـمفتاح توقيع التطبيق الخاص بجوجل بلاي | ما يحتاجه assetlinks.jsonبصمة SHA-256 لشهادة مفتاح توقيع التطبيق. هذه هي التي تُصلح نسخة جوجل بلاي. |
| ملف APK للإصدار من إنشائك، مثبّت يدويًا | موقّعة بـمفتاح الرفع أو مفتاح الإصدار الخاص بك | ما يحتاجه assetlinks.jsonبصمة SHA-256 لهذا المفتاح، فقط إذا أردت أن يتم التحقّق من هذه النسخ أيضًا |
| تشغيل debug من Android Studio | موقّعة بـمفتاح debug المحلي لديك | ما يحتاجه assetlinks.jsonبصمة SHA-256 لمفتاح debug، فقط إذا أردت أن يتم التحقّق من نسخ debug. ومعرّف التطبيق المختلف يحتاج إلى عبارة خاصة به. |
| رابط المشاركة الداخلية للتطبيقات | موقّعة بـمفتاح منفصل للمشاركة الداخلية للتطبيقات | ما يحتاجه assetlinks.jsonتقوم جوجل بإعادة توقيع هذه الملفات المرفوعة بمفتاح Internal App Sharing، لذا اختبر الإصلاح على مسار اختبار بدلًا من ذلك |
| نسخة صدرت بعد ترقية مفتاح التوقيع | موقّعة بـالشهادة التي يستخدمها جوجل بلاي الآن لتلك النسخة | ما يحتاجه assetlinks.jsonكل شهادة للنسخ التي لا تزال تدعمها. لا تحذف شهادة أقدم لمجرد ظهور شهادة أحدث. |
المختبِرون في الاختبار المغلق يرونه أيضًا
يثبّت المختبِرون في الاختبار المغلق (closed testing) النسخة الموقّعة من جوجل بلاي، لذا كثيرًا ما يكون هذا أول مكان يظهر فيه الشريط. وهذا ليس عيبًا في الاختبار المغلق: العامل المتغيّر هو الشهادة الموجودة على ملف APK المثبّت. وإذا كنت لا تختبر إلا ملف APK مثبّتًا يدويًا، فقد تفوتك المشكلة تمامًا.
اعثر على SHA-256 لتوقيع التطبيق في Play Console
تذكر وثائق جوجل نفسها حاليًا تسميتين للمكان نفسه. وكلتاهما تبدأ من Protected with Play في القائمة اليسرى لتطبيقك.
| صفحة جوجل | المسار | انسخ من |
|---|---|---|
| مساعدة Play Console: استخدام Play App Signing | المسارProtected with Play > Play Store distribution > Go to Play app signing | انسخ منقسم مفتاح توقيع التطبيق (App signing key) |
| وثائق Android App Links | المسارProtected with Play > Play Store protection > Manage Play app signing | انسخ منApp signing key certificate > SHA-256 certificate fingerprint |
لا تزال أدلة أقدم، ومنها بعض صفحات جوجل، تذكر Release > Setup > App signing أو Setup > App integrity. إذا لم تجد سوى هذه التسميات، فأنت تبحث عن الصفحة نفسها تحت اسم أقدم.
افتح التطبيق في Play Console
اختر التطبيق الذي يستخدم تطبيق TWA اسم حزمته. لكل تطبيق مفتاح توقيع خاص به.
انتقل إلى Play app signing
استخدم أيًّا من المسارين في الجدول أعلاه. كلاهما يقود إلى الصفحة التي تعرض مفتاح توقيع التطبيق ومفتاح الرفع.
انسخ بصمة SHA-256 لمفتاح توقيع التطبيق
انسخ بصمة شهادة SHA-256 من قسم مفتاح توقيع التطبيق، لا من قسم مفتاح الرفع ولا من سطر SHA-1. وهي 32 زوجًا من الأحرف الست عشرية تفصل بينها نقطتان رأسيتان. الصقها كاملة؛ فالمثال المختصر المأخوذ من مقال في مدونة لن ينجح في التحقّق.
احتفظ بكل شهادة توقيع تطبيق تنطبق عليك
تصف صفحة المساعدة الحالية من جوجل التوقيع الهجين الجاهز للحوسبة الكمّية، حيث تنسخ البصمات لثلاثة مفاتيح: مفتاحان جديدان، تقليدي وما بعد كمّي، يُستخدمان على الأجهزة الأحدث، والمفتاح التقليدي المستخدَم على الأجهزة الأقدم. إذا عرضت صفحتك أكثر من شهادة توقيع تطبيق واحدة، فأدرج كل شهادة يمكن أن تتلقاها الأجهزة التي تدعمها. ولا ينطبق هذا إلا على التطبيقات التي تستخدم هذا الإعداد؛ فمعظم التطبيقات تعرض شهادة توقيع تطبيق واحدة.
اقرأ بصمة مفتاح تحتفظ به بنفسك
بالنسبة إلى مفتاح الرفع أو مفتاح debug، تطبع أداة keytool من Java الصيغة نفسها. استبدل ملف keystore والاسم المستعار (alias) بما لديك، ثم انسخ السطر المعنون SHA256:
keytool -list -v -keystore my-upload-key.jks -alias uploadإذا كنت تدير تطبيقات كثيرة، فيمكن لواجهة Google Play Developer API أيضًا أن تُرجع تجزئة شهادة ملفات APK التي أنشأها جوجل بلاي (الحقل certificateSha256Hash في قائمة ملفات APK المُنشأة). أما لإصلاح واحد، فالنسخ من Play Console أبسط.
اكتب ملف assetlinks.json صحيحًا وقدّمه
الملف عبارة عن مصفوفة JSON من العبارات (statements). بالنسبة إلى TWA تكون العلاقة delegate_permission/common.handle_all_urls، والهدف هو تطبيق Android الخاص بك: مساحة الاسم android_app، ومعرّف تطبيقك الدقيق، ومصفوفة من بصمات SHA-256. يبدو الملف في أبسط صوره هكذا:
[
{
"relation": ["delegate_permission/common.handle_all_urls"],
"target": {
"namespace": "android_app",
"package_name": "com.example.twa",
"sha256_cert_fingerprints": [
"PLAY_APP_SIGNING_KEY_SHA256",
"UPLOAD_KEY_SHA256"
]
}
}
]استبدل com.example.twa بمعرّف تطبيقك، وكل عنصر نائب ببصمة SHA-256 كاملة مفصولة بنقطتين رأسيتين. احذف الإدخال الثاني إذا كنت تحتاج فقط إلى التحقّق من نسخ جوجل بلاي. صيغة JSON صارمة فقط: لا تعليقات، ولا فواصل زائدة في النهاية، ولا قيم SHA-1.
كيف تشترط جوجل تقديم الملف
- الموقع الدقيق.
https://your-domain/.well-known/assetlinks.json، مع النقطة في.well-known. النطاقانexample.comوwww.example.comمصدران مختلفان؛ انشر الملف على كل مصدر يفتحه تطبيقك. ولا تُحتسب نسخة في مجلد فرعي مثل/app/.well-known/. - استجابة HTTP 200 مباشرة. تقول وثائق Digital Asset Links من جوجل: “أي استجابة من الخادم غير HTTP 200 تُعامَل كخطأ، وستؤدي إلى قائمة عبارات فارغة.”
- دون إعادة توجيه. لا تتم متابعة الاستجابات 301 و302. ويشمل ذلك الانتقال من http إلى https، والانتقال من النطاق المجرّد إلى www.
- HTTPS بسلسلة شهادات صالحة، والترويسة
Content-Type: application/json. صفحة تسجيل الدخول أو صفحة خطأ HTML التي تستجيب بالرمز 200 ليست ملفًا صالحًا.
افحص الاستجابة المباشرة من أي طرفية. يجب أن يكون سطر الحالة الأول 200 وأن يكون نوع المحتوى JSON، دون أي استجابة 3xx قبله:
curl -sI https://example.com/.well-known/assetlinks.jsonأكثر من بصمة، وأكثر من تطبيق
يقول دليل ربط المواقع في Android عن مصفوفة البصمات: “يدعم هذا الحقل بصمات متعددة، ويمكن استخدامها لدعم إصدارات مختلفة من تطبيقك، مثل نسخ debug ونسخ الإصدار العلني.” لا تضف بصمة مفتاح الرفع أو مفتاح debug إلا للنسخ التي تريد فعلًا أن يثق بها هذا الموقع. والنسخة ذات معرّف التطبيق المختلف، مثل حزمة debug منفصلة، تحتاج إلى عبارة خاصة بها في المصفوفة.
إذا أنشأت تطبيق TWA باستخدام Bubblewrap أو PWABuilder
في مشروع Bubblewrap قائم، أضف بصمة جوجل بلاي وأعد إنشاء الملف:
bubblewrap fingerprint add "PLAY_APP_SIGNING_KEY_SHA256" --name="Play app signing"
bubblewrap fingerprint list
bubblewrap fingerprint generateAssetLinksإنشاء الملف لا يعني نشره: ارفع ملف assetlinks.json الجديد إلى موقعك وافحصه باستخدام curl. يفحص الأمر bubblewrap validate تطبيق PWA الخاص بك وفق معايير الجودة؛ ولا يفحص ربط التوقيع، لذا فإن النجاح فيه لا يثبت شيئًا عن البصمة. وتؤكد تعليمات PWABuilder الحالية النقطة نفسها بشأن التوقيع: “بمجرد رفع ملف .aab، يعيد جوجل بلاي توقيع تطبيقك”، وتطلب منك إضافة بصمة جوجل بلاي إلى الملف المُنشأ. وتصحيح البصمة تغيير في موقعك، لا في ملف التطبيق الثنائي.
تحقّق من الربط، ثم اختبر نسخة جوجل بلاي
هناك أربع طبقات معنية: الملف على موقعك، وواجهة Digital Asset Links API من جوجل، وتحقّق Android نفسه من الروابط، والمتصفح الذي يشغّل تطبيق TWA. واجتياز طبقة لا يثبت اجتياز التالية، لذا افحصها بالترتيب واختم بالجهاز.
الملف على الموقع
شغّل فحص curl المذكور أعلاه. أصلح أي إعادة توجيه، أو نوع محتوى خاطئ، أو حالة غير 200 قبل أن تبحث في أي مكان آخر.
أداة Statement List Generator and Tester من جوجل
تأخذ أداة Statement List Generator and Tester من جوجل نطاقك واسم الحزمة وبصمة SHA-256، وتختبر ما إذا كانت العبارة موجودة. وهي أسرع فحص مرئي.
الفحص الدقيق عبر الواجهة البرمجية
تجيب طريقة assetlinks.check عن سؤال واحد دقيق: هل هذه الحزمة بهذه الشهادة مرتبطة بهذا الموقع؟ استبدل المصدر والحزمة والبصمة والمفتاح، ورمّز القيم بترميز URL، وابحث عن "linked": true:
https://digitalassetlinks.googleapis.com/v1/assetlinks:check?source.web.site=https%3A%2F%2Fexample.com&relation=delegate_permission%2Fcommon.handle_all_urls&target.android_app.package_name=com.example.twa&target.android_app.certificate.sha256_fingerprint=URL_ENCODED_SHA256&key=YOUR_API_KEYالمصدر هو الأصل (origin)، وليس عنوان URL للملف. أما طريقة statements.list فتعرض فقط ما ينشره الموقع، لذا فإن القائمة غير الفارغة لا تثبت أن حزمتك وشهادتك موجودتان فيها. ويطلب دليل جوجل مفتاح API؛ وخطأ التفويض أو الحصة مشكلة في الوصول إلى الواجهة البرمجية، وليس فشلًا في الربط.
لرؤية كل ما ينشره الموقع، يأخذ طلب القائمة المصدر والعلاقة فقط. اقرأ الأهداف المُرجَعة وابحث عن حزمتك وشهادتك بدقة:
https://digitalassetlinks.googleapis.com/v1/statements:list?source.web.site=https%3A%2F%2Fexample.com&relation=delegate_permission%2Fcommon.handle_all_urlsالتطبيق الذي يثبّته المختبِر
ثبّت التطبيق من مسار الاختبار في جوجل بلاي، لا من ملف APK مثبّت يدويًا ولا من رابط مشاركة داخلية للتطبيقات، ثم افتحه. إذا بقي الشريط ظاهرًا، فاقرأ سجل التحقّق في Chrome عبر adb. تقول وثائق Chrome إنك إذا رأيت Statement failure matching fingerprint. فإن توقيع التطبيق لا يطابق ملف assetlinks.json لديك:
adb logcat -v brief | grep -e OriginVerifier -e digital_asset_linksيفحص App Links Assistant في Android Studio (Tools > App Links Assistant) ربط Android App Links وملف البيان (manifest) لديك. وهو مفيد لهذين الأمرين، لكنه لا يخبرك ما إذا كان تطبيق TWA يفتح بملء الشاشة؛ فاختبار الجهاز وحده يخبرك بذلك.
متقدّم: حالة التحقّق الخاصة بـ Android نفسه
على Android 12 والإصدارات الأحدث، يوثّق دليل التحقّق في Android هذه الأوامر لـ App Links. استبدل الحزمة، وشغّل الأمرين الأولين، وانتظر بضع دقائق، ثم اقرأ الحالة:
adb shell pm set-app-links --package YOUR_PACKAGE 0 all
adb shell pm verify-app-links --re-verify YOUR_PACKAGE
adb shell pm get-app-links YOUR_PACKAGEتصف verified تحقّق Android من النطاق، لا ما إذا كان تطبيق TWA يفتح دون واجهة المتصفح. والرموز 1024 فما فوق أخطاء خاصة بأداة التحقّق، وليست تشخيصًا لبصمة SHA-256 خاطئة. أما لتطبيق TWA نفسه، فاستخدم سجل Chrome المذكور أعلاه.
البصمة مطابقة لكن الشريط باقٍ
ظهور الشريط لا يثبت أن بصمة SHA-256 خاطئة. عندما يُرجع الفحص أعلاه linked: true ويبقى الشريط ظاهرًا، فراجع هذه الأسباب واحدًا تلو الآخر.
| ما تراه | السبب المرجّح | ما الذي تفعله |
|---|---|---|
| يظهر الشريط بعد رابط أو تسجيل دخول أو إعادة توجيه | السبب المرجّحغادرت المصدر الذي تم التحقّق منه | ما الذي تفعلهيقول دليل المصادر المتعددة من Chrome: “عندما ينتقل المستخدم خارج المصدر الذي تم التحقّق منه، تظهر واجهة Custom Tab.” صرّح بكل مصدر تتحكم فيه داخل التطبيق وانشر assetlinks.json على كلٍّ منها. أما صفحة تسجيل الدخول على نطاق شركة أخرى، مثل مزوّد هوية، فهي خارج نطاق الربط الخاص بك: لا يمكنك نشر ملفها، لذا فظهور واجهة المتصفح هناك أمر متوقع. |
| الشريط ظاهر منذ الشاشة الأولى، ونطاقك يعيد التوجيه | السبب المرجّحعنوان URL للبدء والمصدر المصرّح به مضيفان مختلفان | ما الذي تفعلهاجعل عنوان URL للتشغيل والمصدر المصرّح به ومضيف الملف متطابقة، مثلًا كلها على www. وقد أُصلحت حالة مُبلَّغ عنها في Bubblewrap كانت بصمتها مطابقة بهذه الطريقة تحديدًا. |
| ملء الشاشة مع Chrome، وشريط مع متصفح افتراضي آخر | السبب المرجّحاختيار مزوّد المتصفح | ما الذي تفعلهوفق دليل البدء السريع من Chrome: يُستخدم المتصفح الافتراضي إذا كان يدعم TWA، وإلا فمتصفح مثبّت آخر يدعمه، وإلا فـ Custom Tab. شغّل adb logcat -v brief | grep -e TWAProviderPicker لترى أي متصفح تم اختياره. |
| تثبيت جديد على شبكة ضعيفة أو دون شبكة | السبب المرجّحتعذّر إجراء التحقّق | ما الذي تفعلهأعد الاتصال وافتح التطبيق مجددًا. هذا نمط أبلغ عنه المجتمع، وليس سلوكًا موثّقًا. |
يُبلغ Android بالحالة verified، لكن تطبيق TWA يُظهر واجهة المتصفح |
السبب المرجّحفحص Android وفحص المتصفح منفصلان | ما الذي تفعلهالتقط رسالة تحقّق المتصفح من المصدر باستخدام أمر logcat المذكور أعلاه؛ فهي تفسّر نتيجة TWA، لا حالة Android. |
| رسالة قصيرة تفيد بأن التطبيق يعمل في متصفحك، ثم ملء الشاشة | السبب المرجّحربما إشعار من المتصفح، وليس شريطًا دائمًا | ما الذي تفعلهسجّل النص الدقيق ومدة بقائه قبل أن تعتبره فشلًا في الربط. هذا العَرَض أبلغ عنه المجتمع ولم توثّقه جوجل. |
كم يستغرق الملف المُصلَح حتى يسري مفعوله
لا تنشر جوجل مدة انتظار واحدة لتطبيقات TWA، لأن عدة طبقات من ذاكرة التخزين المؤقت معنية، ولكلٍّ منها قواعدها:
- خادمك أو شبكة CDN قد يظلان يقدّمان الملف القديم. امسح ذاكرة التخزين المؤقت وتأكد من الاستجابة المباشرة باستخدام curl.
- واجهة Digital Asset Links API تذكر مدة صلاحية كل استجابة في الحقل
maxAge. - Android App Links له توقيت منفصل. يقول دليل التحقّق في Android إن التغييرات على Android 15 والإصدارات الأحدث قد تستغرق ما يصل إلى سبعة أيام لتصل إلى جميع الأجهزة، وإن الملف على Android 14 والإصدارات الأقدم يُلتقط عادةً عند تثبيت التطبيق أو تحديثه.
- المتصفح قد يحتفظ بحالته الخاصة. أبلغ أحد المطوّرين عن نجاح الأمر بعد مسح بيانات Chrome.
لذا امسح ذاكرة التخزين المؤقت، وتأكد من الملف المباشر، وأعد التثبيت من جوجل بلاي. على جهاز الاختبار، يمكن للتثبيت الجديد أو مسح بيانات المتصفح أن يستبعد الحالة المخزّنة مؤقتًا؛ وهذه خطوة تشخيصية، وليست شيئًا تطلبه من كل مستخدم. لا تبنِ خطتك على عدد ثابت من الساعات.
الرفض والمراجعة والاختبار المغلق
غياب ملف assetlinks.json أو خطؤه غير موثّق كسبب للرفض بحد ذاته. ما تصفه الوثائق هو العودة إلى Custom Tab بواجهة المتصفح. أما المراجعة فمسألة منفصلة: تقول سياسة الوظائف في جوجل بلاي “لا نسمح بالتطبيقات التي تتعطل أو تُغلَق قسرًا أو تتجمّد أو تعمل بشكل غير طبيعي بأي طريقة أخرى”، وهذا ينطبق أيًّا كانت حالة الربط لديك. البصمة الصحيحة تُصلح الشريط؛ لكنها لا تحسم المراجعة. وإذا تلقيت رفضًا، فابدأ من السياسة المذكورة في البريد الإلكتروني.
تقول بعض المقالات القديمة إن Chrome سيُعطّل تطبيق TWA الذي يفشل في فحوص الجودة. وقد أزال Chromium شيفرة QualityEnforcer هذه في 4 مايو 2023، لذا تعامل مع هذه النصيحة على أنها تاريخية لا على أنها وصف لمتصفحات اليوم.
إذا تلقيت رفضًا، فانطلق من السبب المذكور في الإشعار: يشرح دليل رفض Broken Functionality أكثر إشعارات الوظائف شيوعًا خطوة بخطوة. لا تُعِد بناء تطبيق TWA على شكل WebView لمجرد ظهور شريط المتصفح. وإذا كان تطبيقك ناتجًا عن أداة بناء بالذكاء الاصطناعي، فإن دليل نشر تطبيق Vibe Coding على جوجل بلاي يغطي المسار الكامل من المشروع إلى جوجل بلاي.
اختبار تطبيق TWA بحساب شخصي جديد
لا تزال حسابات المطوّرين الشخصية التي أُنشئت بعد 13 نوفمبر 2023 تحتاج إلى اختبار مغلق يضم 12 مختبِرًا على الأقل ممّن وافقوا على المشاركة لمدة 14 يومًا متواصلة قبل طلب الإصدار العلني. وهؤلاء المختبِرون يثبّتون النسخة الموقّعة من جوجل بلاي، وهي بالضبط حيث يظهر هذا الخطأ. توفّر PrimeTestLab (برايم تست لاب) أكثر من 12 مختبِرًا حقيقيًا ابتداءً من $19.99 (مع 5% رسوم خدمة إضافية)، وإذا لم تمنحك جوجل إذن الإصدار العلني بعد الاختبار الكامل، فلك الخيار: إعادة الاختبار مجانًا أو استرداد كامل المبلغ. اطّلع على طريقة عمل خدمة 12 مختبِرًا.
الأسئلة الشائعة
أي بصمة SHA-256 أضعها في assetlinks.json عند استخدام Play App Signing؟
بصمة SHA-256 لشهادة مفتاح توقيع التطبيق المعروضة في صفحة Play app signing داخل Play Console. فهذه الشهادة توقّع النسخ التي يثبّتها الناس من جوجل بلاي. ولا تضف بصمة مفتاح الرفع أو مفتاح debug أيضًا إلا إذا أردت أن يتم التحقّق كذلك من النسخ التي تثبّتها بنفسك.
لماذا يعمل تطبيق TWA من Android Studio لكنه يُظهر شريط العنوان عند تثبيته من جوجل بلاي؟
النسخ التي تثبّتها بنفسك موقّعة بمفتاح debug أو مفتاح الرفع الخاص بك، بينما يسلّم جوجل بلاي تطبيقك موقّعًا بمفتاح توقيع التطبيق. فإذا كان موقعك لا يذكر سوى شهادتك المحلية، يفشل التحقّق في نسخة جوجل بلاي ويعود Chrome إلى Custom Tab مع شريط المتصفح.
أين أجد مفتاح توقيع التطبيق في Play Console الحالي؟
ضمن Protected with Play. توثّق جوجل حاليًا مسارين: Play Store distribution ثم Go to Play app signing، وPlay Store protection ثم Manage Play app signing. انسخ بصمة شهادة SHA-256 من قسم شهادة مفتاح توقيع التطبيق.
هل يمكن أن يذكر assetlinks.json أكثر من بصمة SHA-256؟
نعم. الحقل sha256_cert_fingerprints مصفوفة ويدعم بصمات متعددة للحزمة نفسها، مثل نسخة debug والنسخة الموقّعة من جوجل بلاي. أما معرّف التطبيق المختلف فيحتاج إلى عبارة خاصة به.
كم من الوقت بعد إصلاح assetlinks.json يختفي شريط المتصفح؟
لا تنشر جوجل مدة انتظار واحدة لتطبيقات TWA. امسح أي ذاكرة تخزين مؤقت في CDN، وتأكد من أن الملف المباشر يُرجع HTTP 200 بصيغة JSON دون إعادة توجيه، وأعد تثبيت التطبيق من جوجل بلاي؛ وعلى جهاز الاختبار، يمكن لمسح بيانات المتصفح أن يستبعد الحالة المخزّنة مؤقتًا. أما التحقّق من Android App Links فله توقيته الخاص، وقد يستغرق ما يصل إلى سبعة أيام على Android 15 والإصدارات الأحدث.
هل يؤدي ملف assetlinks.json الخاطئ إلى رفض تطبيق TWA على جوجل بلاي؟
تصف الوثائق الحالية العودة إلى Custom Tab بواجهة المتصفح، لا رفضًا تلقائيًا. وتحكم مراجعة جوجل بلاي على ما إذا كان التطبيق يعمل ويقدّم تجربة حقيقية، لذا فإن الملف الصحيح يُصلح الشريط لكنه لا يحسم المراجعة وحده.
هل يرى المختبِرون في الاختبار المغلق شريط المتصفح أيضًا؟
نعم، إذا كان الموقع يفتقر إلى شهادة توقيع التطبيق، لأن المختبِرين في الاختبار المغلق يثبّتون النسخة الموقّعة من جوجل بلاي. اختبر الإصلاح بهذا التثبيت بدلًا من ملف APK مثبّت يدويًا، وتذكّر أن روابط المشاركة الداخلية للتطبيقات موقّعة بمفتاح مختلف.
فحص Digital Asset Links ينجح. فلماذا لا يزال الشريط ظاهرًا؟
تحقّق مما نجح بالضبط. قد تحتوي قائمة العبارات على ربط لحزمة أو شهادة مختلفة، وحتى الفحص الدقيق لا يختبر إلا القيم التي أدخلتها. تأكد من أن النسخة المثبّتة تستخدم تلك الهوية، وتتبّع المصدر الذي يصل إليه التطبيق فعلًا، واقرأ سجل التحقّق في المتصفح. أما حالة App Links في Android فمؤشر منفصل.
هل يمكن لإعادة التوجيه إلى www أو لصفحة تسجيل الدخول أن تعيد الشريط؟
نعم. ينطبق تحقّق TWA على المصادر، والانتقال خارج مصدر تم التحقّق منه يُظهر واجهة المتصفح. افحص أين يصل التطبيق بعد عمليات إعادة التوجيه، واضبط كل مصدر تتحكم فيه في التطبيق وفي ملف assetlinks.json الخاص به. أما صفحة تسجيل الدخول على نطاق شركة أخرى فلا يشملها ملفك، ولا يمكنك نشر ربطها.
هل يفحص الأمر bubblewrap validate بصمة توقيع جوجل بلاي لديّ؟
لا. توثّق Bubblewrap الأمر validate على أنه فحص لتطبيق PWA وفق معايير الجودة، لذا فإن النجاح فيه لا يقول شيئًا عن تطابق التطبيق المثبّت من جوجل بلاي مع قائمة شهاداتك. استخدم أوامر fingerprint لإعداد assetlinks.json، ثم انشره، وافحص النطاق والحزمة والشهادة بدقة، ثم اختبر التثبيت من جوجل بلاي.
هل أحتاج إلى تحويل تطبيق TWA إلى WebView لإزالة الشريط؟
ليس كخطوة أولى. صحّح هوية التوقيع للتطبيق المثبّت، وطريقة تقديم الموقع للملف، والمصادر التي يفتحها التطبيق، ثم أعد الاختبار. وإذا كانت المشكلة الحقيقية سلوكًا غير مدعوم في المتصفح، أو المصادقة، أو إشعارًا محددًا بشأن سياسة، فافحص ذلك على حدة قبل أن تقرر ما إذا كان غلاف مختلف يناسب تطبيقك.
الخلاصة
الخلاصة
يبدأ حل شريط المتصفح في تطبيق TWA مثبّت من جوجل بلاي بمقارنة واحدة: الشهادة التي وقّعت النسخة المثبّتة مقابل البصمات الموجودة في ملف assetlinks.json على موقعك. انسخ بصمة SHA-256 لمفتاح توقيع التطبيق من Play app signing، وانشر JSON صارمًا على المصدر الدقيق باستجابة HTTP 200 مباشرة، وافحص الحزمة والشهادة بدقة، ثم اختبر النسخة التي سيثبّتها المختبِر. وإذا كانت البصمة مطابقة أصلًا، فافحص المصادر وعمليات إعادة التوجيه والمتصفح وذاكرة التخزين المؤقت قبل أن تعيد بناء أي شيء.
المصادر التي تمت مراجعتها في 16 أكتوبر 2026
تسميات قوائم Play Console هي أسرع المعلومات تغيّرًا في هذه الصفحة. إذا لم تعد المسارات أعلاه تطابق ما تراه في Console، فابحث عن Play app signing ضمن Protected with Play، أو ابحث في Console عن app signing.