رُفض تطبيق TWA على جوجل بلاي؟ انتقل إلى WebView

هذا من أكثر أنواع الرفض إحباطًا لمطوّر مستقل. كان مختبروك نشطين فعلًا. كان لديك 12 أشخاص. مرّت الـ14 يومًا. ثم عادت جوجل بـ"your testers were not engaged enough." إن بنيت تطبيقك كـTrusted Web Activity (TWA) أو PWA wrapper، فالنمط ليس وهمًا: عبر 7,400+ تطبيقًا استقبلناها، تصطدم إصدارات الأغلفة بهذا الرفض تحديدًا أكثر بكثير من الإصدارات الأصلية أو WebView. يشرح هذا الدليل السبب، ويُظهر فرق المعمارية المهم، ويمرّ على الانتقال إلى WebView دون التخلي عن أيام الاختبار التي راكمتها.

لماذا تصطدم تطبيقات TWA برفض الاختبار المغلق؟

يعرض Trusted Web Activity موقعك عبر سطح Custom Tabs في Chrome بدل رسم الشاشات داخل تطبيقك. طريقة سريعة لتحويل موقع أو PWA إلى شيء قابل للتثبيت، وكثير من تطبيقات الإصدار العلني تعمل بها بلا مشكلة. المشكلة تظهر تحديدًا عندما يحتاج حساب مطوّر شخصي إلى اجتياز شرط الاختبار المغلق الإلزامي 14 يومًا قبل طلب الإصدار العلني.

في تجربتنا بمساعدة أكثر من 7,400+ تطبيقًا عبر تلك العملية، تصطدم إصدارات TWA وPWA-wrapper برفض "testers were not engaged" أكثر بكثير من التطبيقات الأصلية القياسية، حتى عندما كان المختبرون نشطين كل يوم. النمط ثابت بما يكفي لندفع المطوّرين بعيدًا عن TWA كلما كان التطبيق ما زال بحاجة لاجتياز اختبار 14 يومًا المغلق.

ما هو TWA فعليًا (وكيف يُبنى)

قبل إصلاح الرفض، يفيد فهم ما رفعته بالضبط. Trusted Web Activity تطبيق أندرويد هو في جوهره موقعك يعمل بملء الشاشة داخل محرك متصفح حقيقي: بلا شريط عنوان، بلا واجهة متصفح، ولا شيء يخبر المستخدم أنه ينظر إلى صفحة ويب. للمستخدم يبدو كتطبيق أصلي. تحت الغطاء، هو موقعك الحي.

تُولَّد TWAs عادة عبر CLI Bubblewrap من جوجل أو PWABuilder، وكلاهما يعتمد على مكتبة androidbrowserhelper. توجّه الأداة إلى URL، تنتج مشروع أندرويد، توقّعه وترفع AAB إلى جوجل بلاي.

لماذا يلجأ المطوّرون إلى TWA

المقايضة التي تسبب الرفض

نفس ما يجعل TWA رخيصًا يجعله هشًا للاختبار المغلق:

• يحتاج الإنترنت. هو نافذة على موقعك، فاتصال ضعيف يعني تطبيقًا ضعيفًا ما لم يكن لـ PWA دعم offline متين.
• مخاطر رفض متجر Play. سياسة Minimum Functionality / المحتوى المعاد تغليفه تستهدف التطبيقات التي «مجرد موقع في غلاف». TWA بلا قدرة أصلية حقيقية قد يُرفض أو يُزال، خاصة في الإرسالات الجديدة. إضافة ميزات أصلية (إشعارات push، وضع offline، كاميرا، أهداف مشاركة) هو ما يبقيك على الجانب الصحيح من ذلك الخط.
• مشكلة إشارة التفاعل أعلاه، ولهذا تستمر الحسابات الشخصية أمام اختبار 14 يومًا المغلق في رؤية رسالة "testers not engaged".

سوء الفهم: TWA ليس WebView

هذا ما تخطئ فيه معظم المقالات، ويستحق الدقة لأنه يغيّر طريقة الإصلاح. TWA لا يستخدم مكوّن WebView في أندرويد أصلًا.

لأن TWA يستخدم المحرك خلف Custom Tabs، تحصل على نفس محرك العرض ومحرك JavaScript وصندوق الأمان مثل Chrome الحقيقي، بالإضافة إلى ملفات تعريف الارتباط والتخزين المشتركة مع Chrome (فيبقى المستخدم المسجّل على الويب مسجّلًا)، وتحديثات المتصفح التلقائية، ودعم كامل لمنصة الويب. هذا قوي فعلًا لتطبيق منشور عادي، لكنه يعني أيضًا أن شاشاتك تعمل خارج العملية، داخل Chrome، لا داخل تطبيقك. هنا جذر تخفيف إشارة التفاعل وانخفاض عدّ المستخدمين النشطين.

تدفق الإطلاق خطوة بخطوة

فحص الثقة: Digital Asset Links

لا يزيل Chrome شريط العنوان إلا إذا أثبت التطبيق ملكية الموقع عبر Digital Asset Links. يصرّح التطبيق بالموقع الذي يمثله، ويجب أن يخدم الموقع ملفًا عند /.well-known/assetlinks.json يسمّي حزمة التطبيق وبصمة شهادة التوقيع (SHA-256).

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.yourapp.name",
    "sha256_cert_fingerprints": [
      "AB:CD:EF:...:99"  // your signing cert SHA-256
    ]
  }
}]

مسار إشارة التفاعل: TWA مقابل WebView

أبسط طريقة لفهم الرفض هي تتبّع أين يذهب نشاط المختبر فعليًا. في TWA، تعيش شاشاتك طبقة واحدة أبعد عن تطبيقك، داخل سطح Custom Tabs في Chrome. في تطبيق WebView، تعمل الشاشات نفسها داخل عملية تطبيقك، وتُنسب مباشرة إلى حزمتك. ذلك الفرق الواحد يغيّر قوة تسجيل النشاط.

كيف تتعرّف على TWA (من الخارج والداخل)

لست متأكدًا إن كان التطبيق الذي (أو المقاول) رفعته TWA فعلًا؟ إليك كيف تتأكد: بالعين أولًا، ثم بشكل قاطع من APK أو جهاز متصل.

علامات بصرية سريعة (كمستخدم)

• يتصرف تمامًا كالموقع، لأنه هو الموقع.
• إن أخطأ المطوّر في الإعداد، سترى شريط عنوان متصفح في الأعلى: دليل قاطع (انظر خطأ assetlinks أعلاه).
• يتحدّث المحتوى دون تحديث تطبيق يظهر في متجر Play.

علامات تقنية قاطعة (فحص APK / الجهاز)

أكّدها بـ adb

على جهاز متصل (أو محاكي)، أمران يحسمان الأمر:

# Is it a TWA? Look for the delegation service:
adb shell dumpsys package <package.name> | grep -i DelegationService

# Which site does it wrap, and is the trust check passing?
adb shell pm get-app-links <package.name>
#   -> "verified"  = Digital Asset Links pass (fullscreen)
#   -> "1024"      = verification failed (address bar shows)

TWA مقابل WebView للاختبار المغلق: جنبًا إلى جنب

كلتا المعماريّتين تغلف محتوى ويب. الفرق المهم لاجتياز اختبار 14 يومًا المغلق هو أين يعمل ذلك المحتوى وكيف يُنسب نشاطه. إليك المقارنة على المقاييس التي تقرّر وصولك إلى الإصدار العلني في دورة واحدة.

الإصلاح: ابنِ تطبيق WebView قياسيًا بدلًا منه

بدل ترقيع TWA أو محاولة انتزاع إشارات أفضل منه، المسار الأنظف هو إعادة بناء التطبيق حول مكوّن WebView ونشر ذلك الإصدار. لديك ثلاث طرق شائعة، كلها تحمّل موقعك داخل تطبيقك:

الحد الأدنى لإعداد WebView (جاهز للنسخ)

الأساس صغير: WebView يحمّل URL مع تفعيل JavaScript والتخزين، يبقي التنقل داخل التطبيق بدل القفز إلى Chrome، ويربط معالج زر الرجوع الذي تتوقعه مراجعة جوجل. بدّل التبويب للغتك وانسخ الأساس:

val webView = findViewById<WebView>(R.id.webview)
webView.settings.apply {
    javaScriptEnabled = true          // most sites need this
    domStorageEnabled = true          // localStorage / sessionStorage
    cacheMode = WebSettings.LOAD_DEFAULT
}

// Keep links INSIDE the app (this is the key difference vs a TWA)
webView.webViewClient = WebViewClient()
webView.loadUrl("https://yourwebsite.com")

// The exact back-button handler Google looks for
onBackPressedDispatcher.addCallback(this, object : OnBackPressedCallback(true) {
    override fun handleOnBackPressed() {
        if (webView.canGoBack()) {
            webView.goBack()
        } else {
            finish()
        }
    }
})

WebView webView = findViewById(R.id.webview);
WebSettings settings = webView.getSettings();
settings.setJavaScriptEnabled(true);      // most sites need this
settings.setDomStorageEnabled(true);      // localStorage / sessionStorage
settings.setCacheMode(WebSettings.LOAD_DEFAULT);

// Keep links INSIDE the app (this is the key difference vs a TWA)
webView.setWebViewClient(new WebViewClient());
webView.loadUrl("https://yourwebsite.com");

// The exact back-button handler Google looks for
getOnBackPressedDispatcher().addCallback(this, new OnBackPressedCallback(true) {
    @Override
    public void handleOnBackPressed() {
        if (webView.canGoBack()) {
            webView.goBack();
        } else {
            finish();
        }
    }
});

# Wrap an existing web/PWA project in a native WebView shell
npm install @capacitor/core @capacitor/cli
npx cap init "YourApp" "com.yourapp.name"

# Point Capacitor at your live site (capacitor.config.ts)
#   server: { url: "https://yourwebsite.com", cleartext: false }

npm install @capacitor/android
npx cap add android
npx cap sync

# Capacitor handles back-button + DOM storage natively.
# Open in Android Studio to build a signed AAB:
npx cap open android

ثلاثة أشياء يجب إضافتها لاجتياز المراجعة

WebView عارٍ يستدعي فقط loadUrl() ما زال غلافًا رقيقًا. هذه الإضافات الثلاث تجعله تطبيقًا حقيقيًا وتبعد المختبرين عن الشاشات الفارغة:

كيف تنتقل دون إعادة عدّاد 14 يومًا

إن كنت في منتصف الاختبار، لا يجب أن تبدأ من الصفر. ينجو عدّاد 14 يومًا من تحديث التطبيق ما دمت على نفس المسار بنفس اسم الحزمة. هذا الانتقال الآمن:

هل يُعد تطبيق WebView ما زال «غلافًا رقيقًا»؟

هذا الفخ يمسك المطوّرين الذين يظنون WebView رصاصة سحرية. الانتقال من TWA إلى WebView يعالج مشكلة إشارة التفاعل، لكنه لا يعفيك من سياسة جوجل Spam and Minimum Functionality. WebView ليس سوى صفحتك الرئيسية في إطار قد يُرفض كغلاف رقيق، بنفس طريقة TWA العاري.

يفيد أن ترى هذين كـبوابتين منفصلتين. خدمة اختبار أو إعادة بناء WebView قد تساعدك على اجتياز إحداهما، لا الأخرى.

إذن الهدف ليس فقط «WebView بدل TWA»، بل تطبيق WebView بقيمة أصلية وسلوك كافٍ ليصمد وحده. عمليًا يعني ذلك:

تريد قائمة أعمق لما يثير رفض الجودة؟ دليلنا عن لماذا يُرفض الاختبار المغلق يفصّل أشهر إخفاقات السياسة والمراجعة خارج التفاعل.

لست متأكدًا إن كان تطبيقك TWA؟ نتحقق لحظة طلبك

لا يجب أن تشغّل أوامر adb أو تحفر في APK بنفسك. نعم: تستطيع PrimeTestLab تأكيد ما إذا كان تطبيقك TWA نيابة عنك. لحظة طلب خدمة الاختبار، يفحص فريقنا إصدارك، يحدّد إن كان TWA أو PWA wrapper، وإن كان كذلك نخبرك بالضبط بما تصلح قبل إهدار عدّاد 14 يومًا على معمارية ستُعلَّم بسبب التفاعل.

ماذا يحدث لحظة الطلب

كيف تساعد PrimeTestLab (النصف الآخر من المشكلة)

المعمارية نصف المشكلة. النصف الآخر، الذي يوقف معظم المطوّرين المنفردين، هو إيجاد 12 مختبِرًا يوافقون على المشاركة ويبقون موافقين 14 يومًا بلا انقطاع. هذا ما تتولاه PrimeTestLab.

نوفّر مختبرين موثّقين وافقوا على المشاركة على أجهزة أندرويد حقيقية يبقون اختبارك المغلق نشطًا طوال الشرط، حتى لا يكسر انسحاب مختبر واحد سلسلة 14 يومًا. تشارك رابط الانضمام للاختبار المغلق؛ نتولى الدعوة، التحقق من الموافقة، مراقبة التفاعل اليومي، والاحتفاظ 14 يومًا. 7,400+ تطبيقًا وأكثر، بنسبة نجاح 99.9% من المحاولة الأولى.

الباقات الحالية

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

الخلاصة