إجابة سريعة
يعني الرفض بسبب Broken Functionality أن مراجع Google وجد أن الإصدار الذي أرسلته تعطّل، أو أُغلق قسرًا، أو تجمّد، أو عمل بشكل غير طبيعي بطريقة أخرى؛ والأمثلة التي تذكرها Google نفسها هي تطبيقات لا تُثبَّت، أو تُثبَّت لكنها لا تُحمَّل، أو تُحمَّل لكنها لا تستجيب. إنه قرار سياسة يخص إصدارًا بعينه، وليس رفضًا لإذن الإصدار العلني، وتقول Google إن الرفض وحده لا يؤثر في وضع حساب المطوّر الخاص بك. أعِد إنتاج المشكلة على الإصدار الذي يوزّعه Play، وتأكد من أن المراجعين يستطيعون تسجيل الدخول عبر تفاصيل تسجيل الدخول (Sign-in details، وكان اسمها سابقًا App access)، وأصلح كل مسار متأثر، ثم أرسل الإصدار المصحَّح للمراجعة. ولا تقدّم طعنًا إلا إذا استطعت إثبات أن النتيجة كانت خاطئة.
محدَّث حتى 16 أكتوبر 2026. رُوجعت كل قاعدة في هذه الصفحة مقابل صفحات سياسات Google Play ومركز مساعدة Play Console في ذلك التاريخ، وكل قاعدة مرفقة برابط مصدرها حيث تُذكر. أما تقارير المطوّرين المقتبسة أدناه فهي دليل على ما رآه المطوّرون في 2026، وليست تشخيص Google لتطبيقاتهم، ولا نقدّم ترتيبًا للأسباب لأنه لا توجد بيانات عامة تدعم أي ترتيب.
يتناول هذا المقال رفض الإصدارات بموجب سياسة Broken Functionality. أما إذا رفضت Google منحك إذن الإصدار العلني بعد الاختبار المغلق (closed testing)، أو أخبرتك بأنه يلزم مزيد من الاختبار، فذلك قرار مختلف له إصلاح مختلف: اقرأ بدلًا من ذلك ماذا تفعل عندما تقول جوجل بلاي إنه يلزم مزيد من الاختبار ولماذا تُرفض طلبات الاختبار المغلق.
محتويات هذا المقال
ماذا يعني Broken Functionality على جوجل بلاي؟
إنه أحد قسمين في سياسة Google بعنوان Functionality, Content, and User Experience (الوظائف والمحتوى وتجربة المستخدم). أما القسم الآخر، Limited Functionality and Content، فيتناول التطبيقات التي غرضها محدود جدًا. ويتناول Broken Functionality التطبيق الذي لا يعمل كما أُرسل.
لا نسمح بالتطبيقات التي تتعطّل أو تُغلق قسرًا أو تتجمّد أو تعمل بشكل غير طبيعي بأي طريقة أخرى.
تذكر Google ثلاثة أمثلة على المخالفات الشائعة تحت تلك الجملة: تطبيقات لا تُثبَّت، وتطبيقات تُثبَّت لكنها لا تُحمَّل، وتطبيقات تُحمَّل لكنها لا تستجيب. اقرأها على أنها ثلاثة أماكن تبحث فيها. فالمراجع الذي لا يستطيع تثبيت الإصدار، أو الذي يرى شاشة فارغة أو شاشة تحميل لا تنتهي، أو الذي ينقر على عنصر تحكم فلا يحدث شيء، قد ينتج عنه الإشعار نفسه في كل الحالات.
قد تصادف اسم Minimum Functionality في روابط المساعدة القديمة وسلاسل المنتديات. أما اسم قسم السياسة الحالي فهو Limited Functionality and Content (الوظائف والمحتوى المحدودة)، ويشمل التطبيقات التي تعرض نصًا ثابتًا أو ملفات PDF فقط، والتطبيقات ذات المحتوى القليل جدًا، والتطبيقات المصمَّمة لكي لا تفعل شيئًا. وقد يستشهد الإشعار بأيٍّ من القسمين، والإصلاحات مختلفة، لذا اقرأ القسم الذي يذكره إشعارك قبل أن تغيّر أي شيء.
أربعة قرارات يُخلط بينها
| القرار | موضوعه | من أين تبدأ |
|---|---|---|
| Broken Functionality | موضوعهتعطّل الإصدار المُرسَل أو تجمّد أو لم يُحمَّل أو لم يستجب لدى المراجع. | من أين تبدأأعِد إنتاج المشكلة على الإصدار الذي يوزّعه Play، وأصلحها في كل مسار متأثر، ثم أعِد الإرسال. |
| Limited Functionality and Content | موضوعهيعمل التطبيق لكنه يقدّم غرضًا أو محتوى خاصًا بالتطبيق قليلًا جدًا. | من أين تبدأأضِف وظائف حقيقية. فإصلاح الأخطاء وحده لن يعالج هذا القرار. |
| تفاصيل تسجيل الدخول مفقودة أو لا تعمل | موضوعهلم يتمكن المراجعون من تجاوز تسجيل دخول أو اشتراك عضوية أو جدار دفع أو رمز لمرة واحدة أو تحقّق من المنطقة. | من أين تبدأحدّث Sign-in details في App content، ثم أرسل التغيير للمراجعة. |
| لم يُمنح إذن الإصدار العلني | موضوعهبعد الاختبار المغلق، قررت Google أن التطبيق يحتاج إلى مزيد من الاختبار أو أنه غير جاهز للإصدار العلني. | من أين تبدأعملية منفصلة بلا إشعار على مستوى الشيفرة. راجع يلزم مزيد من الاختبار. |
أين تُظهر Google ما الذي تعطّل؟
ابدأ برسالة الإجراء التنفيذي عبر البريد الإلكتروني وبصفحة Policy status (حالة السياسة) في Play Console. فهما معًا تذكران السياسة والإصدار المتأثر، وتقول Google إن صفحة Policy status تعرض أيضًا أي معلومات إضافية متاحة. أما لقطات الشاشة وتفاصيل الأجهزة وتتبّعات المكدس (stack traces) فليست مضمونة، لذا لا تنتظرها.
افتح Play Console، واختر التطبيق، وافتح صفحة Policy status الخاصة به. دوّن أربعة أشياء قبل أن تلمس الشيفرة: قسم السياسة المذكور، ورمز الإصدار (version code) والمسار اللذين خضعا للمراجعة، والتاريخ، وأي أدلة مرفقة. وتحقّق أيضًا من البريد الإلكتروني ومن إشعارات Play Console، لأنها المكان الذي تحدّد فيه Google السياسة التي خالفها الإصدار.
كيف تبدو إشعارات 2026 فعلًا
لا توجد رسالة Broken Functionality واحدة يتلقاها الجميع، وأي صفحة تنشر واحدة على أنها القالب الحرفي فهي تخمّن. والمطوّرون الذين نشروا إشعاراتهم علنًا في 2026 يصفون مستويات تفصيل مختلفة جدًا:
- تسمية إشعار نصّها "Broken Functionality: Unresponsive UI elements" (عناصر واجهة لا تستجيب)، نشرها في 2 سبتمبر 2026 مطوّر كان تطبيقه يعرض شاشة إعادة محاولة في وضع عدم الاتصال أثناء أول مزامنة للبيانات (مجتمع مساعدة Play Console).
- مثال من المراجع نصّه "For example, your app does not open or load." (على سبيل المثال، لا يفتح تطبيقك أو لا يُحمَّل)، اقتبسه في يونيو 2026 مطوّر ألعاب كانت شاشة العنوان في لعبته تُحمَّل فعلًا. وأفاد الكاتب لاحقًا بأن اللعبة نُشرت بعد أن غيّر طريقة الخروج منها بزر الرجوع (Back) في Android.
- إشعار وصفه أحد المطوّرين في أغسطس 2026 بأنه كلمتان فقط، "Broken functionality"، دون أي شيء آخر.
هذه مقتطفات نقلها المطوّرون، وليست رسائل Google موثَّقة، وكل منها حالة فردية. وهي تُظهر مدى التفصيل الذي قد تحصل عليه، لا ما سيقوله إشعارك ولا سبب فشل تطبيقك.
إذا كان إشعارك مبهمًا
تعامل مع السياسة المذكورة على أنها عَرَض يجب إعادة إنتاجه، لا على أنها تشخيص. فالفحوص الخمسة في القسم التالي مرتّبة بحيث يستبعد كل منها مكانًا مختلفًا قد يختبئ فيه الخلل.
ما الذي يجب أن تفحصه أولًا بعد الرفض بسبب Broken Functionality؟
أجرِ خمسة فحوص على الإصدار نفسه الذي راجعته Google. وهي مرتّبة من الأسهل استبعادًا إلى الأصعب، لا بحسب مدى تكرار كل سبب، لأنه لا توجد بيانات عامة تبيّن مدى تكرار كل منها.
خمسة فحوص بالترتيب
ثبّت الإصدار الذي يوزّعه Play، لا إصدار تصحيح الأخطاء
ثبّت التطبيق من مسار الاختبار على جهاز نظيف مسجَّل الدخول بحساب Google لم يشغّل التطبيق قط، ثم افتحه كما يفعل المراجع. توقّع Google Play الإصدارات التي توزّعها بمفتاح توقيع تطبيقك (استخدام Play App Signing)، لذا فإن أي خدمة تتحقق من بصمة الشهادة، مثل Google Sign-In أو Maps أو مفتاح API مقيَّد باسم الحزمة وبصمة SHA-1، قد تعمل في إصدار تصحيح الأخطاء (debug) وتفشل في إصدار المتجر. وقد تتبّع أحد المطوّرين في 2025 خللًا لا يظهر إلا في الإصدار النهائي حتى وصل إلى إذن الإنترنت المفقود من ملف البيان (manifest) الخاص بالإصدار العلني.
تأكد من أن المراجع يستطيع الدخول
إذا كان أي جزء من التطبيق خلف تسجيل دخول أو اشتراك عضوية أو قيد موقع أو أي بوابة أخرى، فإن Google تشترط عليك تقديم تفاصيل الوصول. تحقّق من أن Sign-in details (وكان اسمها سابقًا App access) تحتوي على بيانات اعتماد تعمل اليوم، ومن أي بلد، ودون رمز لمرة واحدة. ويشرح القسم التالي ذلك خطوة بخطوة.
اختبر الخادم من خارج شبكتك
تفشل شاشات تسجيل الدخول وشاشات البيانات عندما يتعذّر الوصول إلى الخادم من شبكة المراجع. وقد تتبّع مطوّرون في 2026 حالات فشل حتى وصلوا إلى قاعدة جدار حماية أُضيفت عن طريق الخطأ فحجبت طلب رمز تسجيل الدخول، وأبلغوا عن خطأ في الثقة بالشهادة ظهر على شاشة تسجيل الدخول. اختبر عبر بيانات الجوّال وعبر شبكة أخرى، ومن بلد آخر إذا كان خادمك يفلتر حركة المرور حسب المنطقة.
انقر على كل عنصر تحكم ظاهر وافتح كل شاشة فارغة
يجب أن يستجيب كل زر ورابط بمحتوى مناسب. وتقول قائمة التحقق الخاصة بـ Broken Functionality التي نشرتها Google نفسها في مجتمع مساعدة Play Console: "تأكد من أن تطبيقك لا يحتوي على أي صفحات فارغة أو خالية تفتقر إلى إخلاءات مسؤولية أو رسائل خطأ مناسبة." أزِل الميزات غير المكتملة بدلًا من شحن زر لا يفعل شيئًا، وتحقّق من أن كل ميزة تعِد بها صفحة التطبيق في المتجر تعمل فعلًا في الإصدار. وامنح القائمة الفارغة لسبب مشروع، مثل عدم وجود عناصر محفوظة بعد، جملة تشرح ذلك وإجراءً تاليًا. وإذا كان التنقل في تطبيقك غير معتاد، مثل النقر في أي مكان للمتابعة، فأضِف إشارة مرئية لا يمكن أن يفوّتها مستخدم جديد.
افحص التشغيل وزر الرجوع والتقارير التي يحتفظ بها Play بالفعل
افتح التطبيق من حالة الإيقاف الكامل، وأدِر الشاشة، وأرسله إلى الخلفية ثم أعِده، واضغط زر الرجوع في كل شاشة. ثم اقرأ تقرير ما قبل الإطلاق (pre-launch report) وAndroid vitals للإصدار الذي خضع للمراجعة. فالتعطّل المسجَّل هناك هو أقوى دليل ستحصل عليه، أما التقرير الخالي من المشكلات فله حدود يشرحها القسم الذي يلي القسم التالي.
كيف تقدّم تفاصيل تسجيل الدخول لمراجعي Google؟
في Play Console، انتقل إلى Policy and programs، ثم App content، ثم Sign-in details. كان اسم هذا القسم سابقًا App access، لذا لا تزال المقالات الأقدم وبعض صفحات المساعدة المترجمة تستخدم ذلك الاسم.
إذا كان تطبيقك بالكامل أو أجزاء منه مقيَّدة على أساس بيانات اعتماد تسجيل الدخول أو تفاصيل تسجيل الدخول أو الاشتراكات أو الموقع أو أي أشكال أخرى من المصادقة، فيجب عليك تقديم جميع التفاصيل المطلوبة لإتاحة الوصول إلى تطبيقك.
أضِف التعليمات أو حدّثها
- افتح Play Console وانتقل إلى صفحة App content (Policy and programs > App content).
- ضمن Sign-in details، اختر Start، أو Manage إذا كنت قد أضفت تعليمات من قبل.
- اختر + Add new instructions وأدخل تفاصيل الوصول. واستخدم الحقل Any other instructions لأي شيء غير معتاد، مثل كلمة مرور لمرة واحدة، أو المصادقة متعددة العوامل، أو تسجيل دخول يتطلب أكثر من حقلين.
- احفظ التغييرات. يمكنك إضافة ما يصل إلى خمس مجموعات من التعليمات.
- انتقل إلى Publishing overview، وابحث عن التغيير ضمن Changes ready to send for review، ثم اختر Send for review. فالحفظ وحده لا يُرسل أي شيء.
ما الذي يُعدّ وصولًا صالحًا
تطلب منك متطلبات Play Console لدى Google "تقديم حساب تجريبي نشط ومعلومات تسجيل الدخول وجميع الموارد الأخرى اللازمة لكي تراجع Google Play تطبيقك". وتوضّح متطلبات تفاصيل تسجيل الدخول لدى Google ما يعنيه ذلك:
- حساب نشط وقابل لإعادة الاستخدام، لا دعوة صالحة لمرة واحدة ولا فترة تجريبية تنتهي أثناء المراجعة.
- بيانات اعتماد تتجاوز الرموز لمرة واحدة والتحقق بخطوتين، لأن المراجع لا يستطيع تلقي الرمز الذي ترسله إلى هاتف أو صندوق بريد.
- وصول يعمل من أي موقع إذا كان التطبيق يقيّد حسب المنطقة، ووصول كامل إلى الميزات المدفوعة أو المقيَّدة التي يحتاج المراجع إلى رؤيتها، دون أن يُطلب منه الدفع.
- تفاصيل مكتوبة باللغة الإنجليزية ومحدَّثة دائمًا. إذا غيّرت كلمة المرور أو حذفت الحساب التجريبي، فحدّث Sign-in details في اليوم نفسه.
- إذا كان تسجيل الدخول يتطلب شيئًا ليس نصًا، مثل رمز QR أو رمز شريطي، فأنشئ له عنوان URL ثابتًا وأضِفه إلى Sign-in details. وإذا كان التطبيق يطلب من المستخدمين تعيين رمز PIN خاص بهم أو يستخدم تسجيل الدخول عبر حسابات التواصل الاجتماعي، فاشرح في التعليمات كيف يتجاوز المراجع ذلك.
غياب الوصول ليس كتسجيل دخول معطّل
إذا كان الإشعار يذكر Sign-in details، فلن يفيد أي تغيير في الشيفرة حتى تُصحَّح تفاصيل الوصول وتُرسَل للمراجعة. أما إذا كانت بيانات الاعتماد سليمة وفشل تسجيل الدخول نفسه، فتلك مشكلة Broken Functionality، وفحص الخادم أعلاه هو المكان الذي تبحث فيه.
ماذا لو كان التطبيق يعمل على هاتفك ولم ترسل Google أي لقطة شاشة؟
إذن فهاتفك ليس البيئة التي حدث فيها الفشل. أعِد إنتاج المشكلة على إصدار المتجر، وعلى جهاز نظيف وعبر شبكة أخرى، واقرأ التقريرين اللذين يحتفظ بهما Play Console بالفعل لذلك الإصدار قبل أن تقرر أي شيء.
تقرير ما قبل الإطلاق
تجده ضمن Test and release > Testing > Pre-launch report. تُنشئه Google تلقائيًا عند رفع حزمة تطبيق (app bundle) أو APK، بحسب السعة المتاحة، عبر تشغيل التطبيق على أجهزة اختبار. تحقّق من الشاشات التي وصل إليها الزحف فعلًا: فإذا توقّف عند شاشة تسجيل الدخول، فلم يرَ بقية التطبيق قط. وتضيف Google قيدًا يستحق المعرفة: "لا يمكن إدخال بيانات الاعتماد تلقائيًا إلا في تطبيقات Android التي تستخدم أدوات Android القياسية (standard Android widgets)." (استخدام تقرير ما قبل الإطلاق لتحديد المشكلات). فالتقرير الخالي من المشكلات دليل، وليس اجتيازًا. وتقول Google الشيء نفسه عن فحوص ما قبل المراجعة: "اجتياز جميع فحوص ما قبل المراجعة لا يضمن اجتياز عملية مراجعة التطبيق الرسمية".
Android vitals
تجده ضمن Monitor and improve > Android vitals > Crashes and ANRs. لا تجمع Google هذه البيانات إلا من المستخدمين الذين وافقوا على مشاركة بيانات الاستخدام والتشخيص (مراقبة الجودة التقنية باستخدام Android vitals)، لذا قد لا يُظهر تطبيق جديد في اختبار صغير أي شيء على الإطلاق. وصفحة vitals الفارغة لا تُثبت أن التطبيق لم يتعطّل قط.
أشخاص حقيقيون على أجهزة حقيقية
يوجد الاختبار المغلق تحديدًا لاكتشاف هذا النوع من المشكلات قبل الإصدار العام. فالمختبِرون على هواتف وإصدارات Android وشبكات مختلفة يصلون إلى الشاشات التي يصل إليها المراجع، وتخبرك ملاحظاتهم بمواضع الأعطال. وهذا يساعدك على اكتشاف العيوب وإصلاحها، لكنه لا يغيّر طريقة مراجعة Google للتطبيق. وإذا كنت تحتاج إلى أساسيات مسار الاختبار نفسه، فراجع كيف يعمل الاختبار المغلق على جوجل بلاي.
هل تُصلح وتعيد الإرسال، أم تقدّم طعنًا؟
أصلِح وأعِد الإرسال عندما تستطيع إعادة إنتاج الخلل أو تجد سببًا معقولًا له. وقدّم طعنًا عندما تملك أدلة على أن النتيجة المذكورة خاطئة. ولا تُعِد إرسال الإصدار نفسه دون تغيير أبدًا: إذ تطلب Google من المطوّرين عدم إعادة نشر تطبيق تم رفضه إلا بعد إصلاح المخالفة.
إصلاح أم توضيح أم طعن؟
أجب عن ثلاثة أسئلة حول إشعارك واختبارك الخاص. لا يغادر أي شيء تختاره هذه الصفحة.
أجب عن الأسئلة لترى توصية. وإذا لم تستطع إعادة إنتاج الخلل، فالسؤال الثالث هو الذي يحسم الأمر.
أصلِحه، ثم أعِد الإرسال في كل مسار
أصلِح وأعِد الإرساللديك خلل يمكن إعادة إنتاجه، وهذا أفضل وضع يمكن أن تكون فيه. أصلِحه، واختبر الإصلاح على إصدار المتجر، ثم اتبع خطوات إعادة الإرسال أدناه حتى لا تبقى أي حزمة مخالفة نشطة في أي مسار.
اختبر إصدار المتجر قبل أن تقرر
اختبر أولًاإصدار تصحيح الأخطاء ليس ما شغّله المراجع. ثبّت التطبيق من مسار الاختبار على جهاز نظيف بحساب جديد، وعبر شبكة لا تتحكم فيها، وأجرِ الفحوص الخمسة. ولا تقرر إلا بعد ذلك.
صحّح Sign-in details، ثم أرسلها للمراجعة
إصلاح الوصولحدّث التعليمات ببيانات اعتماد قابلة لإعادة الاستخدام تتجاوز الرموز لمرة واحدة، واحفظها، ثم أرسل التغيير للمراجعة من Publishing overview. وتقول Google إنه يمكنك فعل ذلك دون التواصل مع فريق دعم السياسات أو انتظاره.
أضِف غرضًا، لا مجرد إصلاحات
إعادة عملتتعلق Limited Functionality and Content بمقدار ما يقدّمه التطبيق. أضِف ميزات أو محتوى حقيقيًا خاصًا بالتطبيق قبل أن تعيد الإرسال؛ فإصلاح الاستقرار لا يعالج هذه النتيجة.
اجعل التصميم واضحًا، ثم قرّر
توضيحإذا كانت شاشة عدم الاتصال أو الحالة الفارغة أو الإيماءة غير المعتادة مقصودة، فقد يراها المراجع مع ذلك معطّلة. أضِف إشارة مرئية وشرحًا وإجراءً تاليًا. يمكنك تقديم طعن مدعوم بالأدلة، لكن الشاشة الأوضح تزيل الشك أيضًا لدى المراجع التالي.
قدّم طعنًا مدعومًا بالأدلة
طعناختبرت إصدار المتجر على جهاز نظيف وعبر شبكة أخرى ولم تجد أي خلل. قدّم طعنًا مرة واحدة، مع رمز الإصدار، والجهاز وإصدار Android، والخطوات الدقيقة، وتسجيل شاشة للمسار الذي يذكره الإشعار.
إعادة إرسال إصدار مُصلَح
خطوات إعادة الإرسال لدى Google أكثر من مجرد رفع رمز إصدار جديد:
- اقرأ السياسة المذكورة في البريد الإلكتروني وفي إشعاراتك، وافحص التطبيق مقابل السياسات الأخرى أيضًا؛ إذ تحذّر Google من أن المخالفات الإضافية قد تؤدي إلى إجراءات تنفيذية إضافية.
- حدّث كل نوع إصدار يحمل الإصدار المتأثر، لا الإصدار العلني فقط: بما في ذلك مسارات الاختبار المفتوح والمغلق والداخلي.
- ارفع حزمة التطبيق المصحَّحة وألغِ تفعيل الحزم المخالفة. وتحذّر Google من أنك إن لم تلغِ تفعيلها، فستفشل إعادة الإرسال وقد تُزال الإصدارات المنشورة.
- في كل مسار متأثر، اختر Manage track ثم Create new release، وأضِف الحزمة المصحَّحة (أو تجاهل المسودة التي تحتوي على الحزمة المخالفة)، وتأكد من أن الإصدار المخالف مُدرَج ضمن Not included.
- احفظ، واختر Review release، ثم ابدأ طرحه.
بعد ذلك، ينتظر التغيير المعالجة. تقول Google: "قد تستغرق المعالجة بضع ساعات أو ما يصل إلى سبعة أيام (أو مدة أطول في حالات استثنائية)" (التحكم في توقيت مراجعة تغييرات التطبيق ونشرها).
تم الإصلاح، لكن التحذير لا يزال ظاهرًا
إذا كان إصدار مصحَّح منشورًا ولا تزال صفحة Policy status تُظهر المشكلة، فقارن رموز الإصدارات والمسارات التي يذكرها التحذير بما هو نشط الآن: فالحزمة المخالفة المتروكة في مسار اختبار هي أول ما يجب استبعاده. ولا يؤدي الإصدار الأحدث تلقائيًا إلى إزالة كل إدخال تنفيذي. وإذا كان كل شيء متطابقًا، فتواصل مع دعم Play Console وأرفق رموز الإصدارات والمسارات المتأثرة وأي مرجع لحالة سابقة.
الطعن في القرار
تعيد Google التطبيقات عندما تكون قد ارتكبت خطأً وتجد أن التطبيق لا يخالف سياساتها. لتقديم طعن، اتبع التعليمات الواردة في رسالة الإجراء التنفيذي أو استخدم نموذج الطعن لدى Google. يمكنك تقديم طعن واحد لكل إجراء تنفيذي (إدارة مخالفات السياسة والطعون)، وتردّ Google على الطعون باللغات الصينية والإنجليزية واليابانية والكورية. ولا تنشر Google أي مدة للرد على الطعون، وتقارير المطوّرين تخلط بين الردود على الطعون والمراجعات اللاحقة للإصدارات، لذا خطّط دون موعد محدد.
اكتب الطعن بلغة الأدلة لا بلغة الإحباط: رمز الإصدار الذي خضع للمراجعة، والجهاز وإصدار Android اللذين اختبرت عليهما، والخطوات الدقيقة، وتسجيل شاشة للمسار الذي يذكره الإشعار، وما الذي غيّرته، إن كنت قد غيّرت شيئًا.
هل يضرّ الرفض بسبب Broken Functionality بحسابك أو باختبارك المغلق؟
الرفض وحده لا يؤثر في وضع حساب المطوّر الخاص بك. لكن تكرار الرفض قد يؤدي إلى التعليق، وحالات التعليق تُحتسب مخالفات على الحساب (strikes)، لذا أصلِح قبل أن تعيد الإرسال. أما تأثير الرفض في اختبار مغلق جارٍ فغير موثَّق.
توضّح صفحة Enforcement Process (عملية التنفيذ) لدى Google الفرق:
- "حالات الرفض لا تؤثر في وضع حساب المطوّر الخاص بك على Google Play."
- "إذا رُفض تحديث لتطبيق موجود، فسيظل إصدار التطبيق المنشور قبل التحديث متاحًا على Google Play."
- "قد يحدث التعليق نتيجةً لمخالفات جسيمة أو متعددة للسياسات، وكذلك نتيجةً لتكرار رفض التطبيقات أو إزالتها."
لا تنشر Google أي عدد آمن من حالات الرفض. وإعادة إرسال الخلل نفسه هي بالضبط النمط الذي يصفه السطر الثالث.
وماذا عن الاختبار المغلق لمدة 14 يومًا؟
يطلب شرط الاختبار لدى Google من الحسابات الشخصية التي أُنشئت بعد 13 نوفمبر 2023 وجود 12 مختبِرًا على الأقل وافقوا على المشاركة بشكل متواصل لمدة 14 يومًا على الأقل قبل طلب الإصدار العلني. ولا يذكر ما إذا كان رفض إصدار في مسار مغلق بسبب السياسة يعيد تلك المدة من البداية أو يوقفها مؤقتًا أو يحافظ عليها، وما يُقال في المنتديات في أيٍّ من الاتجاهين مجرد تخمين. ما يمكنك التحقق منه: هل لا يزال لدى مختبِريك إصدار معتمد في المسار، وماذا تُظهر لوحة البيانات (Dashboard) بشأن إذن الإصدار العلني. أبقِ المختبِرين مشتركين في الاختبار أثناء الإصلاح، واسأل دعم Play Console عن حالتك إذا تغيّرت لوحة البيانات. والقاعدة نفسها مشروحة في معنى 14 يومًا متواصلة.
هل سترفض Google تطبيق WebView أو TWA على أنه معطّل؟
ليس بسبب التقنية. فـ Google توثّق كلًا من Trusted Web Activities وWebView لتطبيقات Android، ولا توجد سياسة تحظر هذه البنية. أما الأسئلة الحقيقية فهي: هل يعمل التطبيق، وهل له غرض كافٍ، وهل لديك الحق في تغليف الموقع الإلكتروني.
لا نسمح بالتطبيقات التي يكون غرضها الأساسي توجيه زيارات تسويق بالعمولة إلى موقع إلكتروني، أو تقديم عرض ويب (webview) لموقع إلكتروني دون إذن من مالك الموقع أو مسؤوله.
بالنسبة إلى التطبيق المبني على الويب، فإن فحوص Broken Functionality هي نفسها كما في أي تطبيق آخر: يجب أن يُحمَّل الموقع داخل التطبيق بعد تثبيت نظيف، ويجب أن تشرح حالات عدم الاتصال والأخطاء نفسها، ويجب أن يؤدي كل رابط إلى وجهة ما. وإذا كان التطبيق في الغالب مجرد عرض رقيق لموقع إلكتروني، فإن قسم Limited Functionality and Content هو الخطر الأكبر. ولم يثبت أن التحويل من TWA إلى WebView، أو العكس، يصلح الرفض بحد ذاته.
كيف تساعدك PrimeTestLab قبل المراجعة التالية؟
لا يمكننا إصلاح شيفرتك ولا تغيير قرار Google. ما نقدّمه هو جانب الاختبار: أشخاص حقيقيون على أجهزة حقيقية يستخدمون تطبيقك عبر اختبارك المغلق، لكي تظهر مشكلات مثل التي سبق ذكرها في ملاحظاتهم قبل أن يكتشفها المراجع.
توفّر PrimeTestLab (برايم تست لاب) 12 مختبِرًا حقيقيًا أو أكثر على أجهزة حقيقية تغطي Android 7 إلى 17، مشتركين في الاختبار طوال الأيام الـ 14 كاملة، ويبدأ الاختبار خلال 4-6 ساعات. وقد أجرينا اختبارات مُدارة لـ 12,100+ تطبيق بمختبِرين في 120+ دولة.
الاختبار بنفسك أم الاختبار المُدار
| المهمة | بنفسك | مع PrimeTestLab |
|---|---|---|
| العثور على المختبِرين | بنفسكأصدقاء ومجموعات ومنتديات، وغالبًا على هواتف متشابهة | مع PrimeTestLabمختبِرون حقيقيون على أجهزة حقيقية، مخصَّصون لتطبيقك |
| تنوّع الأجهزة وإصدارات Android | بنفسكما يملكه متطوّعوك من أجهزة | مع PrimeTestLabأجهزة تغطي Android 7 إلى 17 |
| الاستخدام اليومي والملاحظات | بنفسكيعتمد على حسن النية | مع PrimeTestLabيستخدم المختبِرون التطبيق ويبلّغون عمّا يتعطّل |
| إبقاء 12 مختبِرًا مشتركين لمدة 14 يومًا | بنفسكتلاحق المنسحبين بنفسك | مع PrimeTestLabيُستبدَل المنسحبون ليبقى العدد ثابتًا |
| إصلاح الشيفرة والإشعار | بنفسكأنت | مع PrimeTestLabيبقى عليك؛ ونحن نبلّغك بما وجده المختبِرون |
| قرار Google | بنفسكGoogle | مع PrimeTestLabيبقى لـ Google؛ ولا أحد يستطيع أن يعِد بالموافقة |
إذا لم تمنحك Google إذن الإصدار العلني بعد اكتمال اختبارك مع PrimeTestLab، فلك الخيار بين إعادة الاختبار مجانًا أو استرداد كامل المبلغ؛ راجع سياسة الاسترداد وإعادة الاختبار مجانًا. ويغطي ذلك شرط الاختبار، لا رفض شيفرتك بسبب السياسة. تبدأ الخطط من $19.99 مع 5% رسوم خدمة إضافية عند الدفع (بحد أدنى $1.50)، أما رسوم تسجيل Google لمرة واحدة بقيمة 25 دولار أمريكي فمنفصلة. قارن الخطط في صفحة الأسعار.
الأسئلة الشائعة
ما سياسة Broken Functionality على جوجل بلاي؟
إنها قسم من سياسة Google Play بعنوان Functionality, Content, and User Experience (الوظائف والمحتوى وتجربة المستخدم). لا تسمح Google بالتطبيقات التي تتعطّل أو تُغلق قسرًا أو تتجمّد أو تعمل بشكل غير طبيعي بأي طريقة أخرى، وتذكر من المخالفات الشائعة التطبيقات التي لا تُثبَّت، والتطبيقات التي تُثبَّت لكنها لا تُحمَّل، والتطبيقات التي تُحمَّل لكنها لا تستجيب.
هل Broken Functionality هي نفسها Minimum Functionality؟
لا. Minimum Functionality هو الاسم القديم لما تسمّيه Google الآن Limited Functionality and Content، ويشمل التطبيقات ذات الغرض أو المحتوى القليل جدًا. أما Broken Functionality فيشمل التطبيقات التي لا تعمل كما أُرسلت. وكلاهما ضمن السياسة نفسها، لكنهما يحتاجان إلى إصلاحات مختلفة.
أين أضيف بيانات الحساب التجريبي لمراجعة جوجل بلاي؟
في Play Console، انتقل إلى Policy and programs، ثم App content، ثم Sign-in details (وكان اسمها سابقًا App access). اختر Start أو Manage، وأضِف التعليمات واحفظها، ثم أرسل التغيير للمراجعة من صفحة Publishing overview. ويجب أن تكون بيانات الاعتماد قابلة لإعادة الاستخدام، وألا تعتمد على رمز لمرة واحدة يُرسَل إلى هاتفك.
هل يُحتسب الرفض مخالفة على حساب المطوّر الخاص بي؟
تقول Google إن حالات الرفض لا تؤثر في وضع حساب المطوّر الخاص بك. أما حالات التعليق فتُحتسب مخالفات على الحساب، وتذكر Google تكرار رفض التطبيقات أو إزالتها ضمن أسباب التعليق، لذا أصلِح المشكلة المذكورة قبل أن تعيد الإرسال.
كم تستغرق المراجعة بعد إعادة إرسال تطبيق مُصلَح؟
تقول Google إن معالجة تغييرات التطبيق قد تستغرق بضع ساعات أو ما يصل إلى سبعة أيام، أو مدة أطول في حالات استثنائية. وهذه هي مراجعة الإصدار المصحَّح. ولا تنشر Google أي مدة للرد على الطعون.
هل يمكنني الطعن في الرفض بسبب Broken Functionality؟
نعم، إذا كنت تعتقد أن النتيجة خاطئة. اتبع التعليمات الواردة في رسالة الإجراء التنفيذي أو استخدم نموذج الطعن لدى Google. يمكنك تقديم طعن واحد لكل إجراء تنفيذي، لذا أرفق رمز الإصدار الذي خضع للمراجعة، والجهاز والخطوات التي اختبرتها، وتسجيلًا للمسار الذي يذكره الإشعار.
هل يعيد الرفض بسبب Broken Functionality اختباري المغلق لمدة 14 يومًا من البداية؟
لا توثّق Google ذلك. وشرطها هو وجود 12 مختبِرًا على الأقل وافقوا على المشاركة بشكل متواصل لمدة 14 يومًا على الأقل قبل أن تطلب الإصدار العلني. أبقِ المختبِرين مشتركين أثناء إصلاح الإصدار، وراقب لوحة البيانات، واسأل دعم Play Console إذا تغيّرت أهليتك.
لماذا رُفض تطبيقي مع أنه يعمل على هاتفي؟
هاتفك يغطي إصدارًا واحدًا وحسابًا واحدًا ومجموعة بيانات واحدة وشبكة واحدة. ثبّت الإصدار الذي يوزّعه Play على جهاز نظيف بحساب جديد، ثم اختبر حالات المحتوى الفارغ وطلبات الشبكة الفاشلة. فإصدار المتجر الموقَّع بمفتاح توقيع التطبيق قد يفشل حيث يعمل إصدار تصحيح الأخطاء، لذا اختبر الإصدار الذي ثبّته المراجع.
يستخدم تطبيقي Google Sign-In أو رمزًا لمرة واحدة. ماذا أقدّم للمراجعين؟
تشترط Google تفاصيل تسجيل دخول قابلة لإعادة الاستخدام، وتعمل من أي موقع، وتتجاوز كلمات المرور لمرة واحدة أو التحقق بخطوتين. امنح المراجعين حسابًا تجريبيًا وتعليمات تصل إلى كل ميزة مقيَّدة، بما فيها الميزات المدفوعة. ثم اختبر بنفسك التفاصيل نفسها التي قدّمتها؛ فشرح الطريقة التي يتلقى بها المستخدم العادي الرمز لا يُعدّ وصولًا صالحًا.
لم ترسل Google أي لقطة شاشة أو سجل أعطال. ماذا الآن؟
افحص صفحة Policy status ورسالة الإجراء التنفيذي بحثًا عن الإصدار المتأثر وأي تفاصيل أضافتها Google. ثم أعِد إنتاج رحلة الاستخدام الرئيسية على الإصدار المُرسَل وسجّل الفيديو والسجلات بنفسك. فصفحة Android vitals الخالية من المشكلات أو تقرير ما قبل الإطلاق النظيف لا يثبتان أن كل شاشة وكل طلب إلى الخادم عملا لدى المراجع.
هل تُرفض تطبيقات TWA وWebView تلقائيًا؟
لا. توثّق Google كلتا التقنيتين ولا توجد سياسة تحظرهما. لكن Google تقيّد التطبيقات التي تغلّف موقعًا إلكترونيًا دون إذن مالكه، والتطبيقات ذات الوظائف أو المحتوى القليل جدًا. شخّص الخلل الفعلي، مثل أخطاء تسجيل الدخول أو التنقل أو الشبكة؛ فالتحويل من أسلوب تغليف إلى آخر ليس إصلاحًا موثَّقًا.
الخلاصة
الخلاصة
يقول الرفض بسبب Broken Functionality إن الإصدار الذي راجعته Google لم يعمل: فقد تعطّل أو تجمّد أو لم يُحمَّل أو لم يستجب. اقرأ السياسة التي يذكرها الإشعار، وأعِد إنتاج المشكلة على الإصدار الذي يوزّعه Play، وتأكد من أن المراجعين يستطيعون تسجيل الدخول عبر Sign-in details، واختبر الخادم من خارج شبكتك، واجعل كل عنصر تحكم وكل شاشة فارغة تشرح نفسها. أصلِح كل مسار متأثر وأرسل الإصدار المصحَّح للمراجعة. ولا تقدّم طعنًا إلا بأدلة على أن النتيجة كانت خاطئة. فالرفض وحده ليس مخالفة على الحساب، لكن تكرار إعادة الإرسال دون إصلاح قد يؤدي إلى واحدة.
إذا كنت تريد أشخاصًا حقيقيين على أجهزة حقيقية يكتشفون الشاشة المعطّلة قبل أن يكتشفها المراجع التالي، فإن PrimeTestLab تتولّى جانب الاختبار المغلق بينما تُصلح أنت التطبيق.
وثائق Google الرسمية
ما الذي قد يتغيّر في هذه الصفحة
- تتغيّر تسميات Play Console. فقد كان اسم Sign-in details هو App access حتى وقت قريب، ولا تزال بعض صفحات المساعدة المترجمة تستخدم الاسم القديم.
- صياغة الإشعارات لا تُنشر كقالب وتختلف من حالة إلى أخرى؛ لذا ثق ببريدك الإلكتروني وبصفحة Policy status الخاصة بك أكثر من أي مثال هنا.
- لا توثّق Google ما يفعله الرفض بسبب السياسة باختبار مغلق جارٍ. وإذا نشرت قاعدة بهذا الشأن، فستتبعها هذه الصفحة.
رُوجعت المصادر في 16 أكتوبر 2026.