لا: لا يُعاد أبدًا
التحديث العادي يُبقي مدة موافقة مختبِريك على المشاركة مستمرةلا تنشر Google أي قاعدة تقول إن إنشاء إصدار جديد يعيد بدء الاختبار المغلق (closed testing). يتعلّق الشرط ببقاء كل مختبِر موافقًا على المشاركة لمدة 14 يومًا متواصلة، مع وجود 12 مختبِرًا على الأقل من هذا النوع عند تقديم الطلب. رمز الإصدار (version code) وعدد الإصدارات التي ترفعها ليسا جزءًا منه.
مختبِرون يغادرون الاختبار، فيصبح من لديهم 14 يومًا دون انقطاع أقل من 12.
المختبِر الذي ينسحب ثم يعود يبدأ أيامه الـ14 من جديد، والمختبِر البديل يبدأ من اليوم الأول. إذا ترك ذلك أقل من 12 مختبِرًا لديهم 14 يومًا دون انقطاع، فسينتظر طلبك. التحديث ليس هو السبب.
جواب سريع
لا. تحديث نفس التطبيق على مسار اختباره المغلق الجاري لا يعيد بحد ذاته بدء مدة موافقة مختبِريك على المشاركة. لحسابات المطوّر الشخصية المنشأة بعد 13 نوفمبر 2023، يحتاج التطبيق إلى 12 مختبِرًا على الأقل بقي كلٌّ منهم موافقًا على المشاركة لآخر 14 يومًا متتالية عند طلب الإصدار العلني. المختبِر الذي ينسحب يبدأ أيامه الـ14 من جديد. Google توصي بالتصرف بناءً على الملاحظات لكنها لا تنشر عددًا مطلوبًا من الإصدارات. إذا لم يرَ المختبِرون إصدارًا جديدًا، فتحقّق من النشر، والأهلية للطرح، وتحديث الجهاز.
هذا من أكثر مخاوف الاختبار المغلق شيوعًا: أنت في منتصف نافذة الـ14 يومًا، تكتشف خطأً، فتتجمّد خوفًا من أن رفع إصلاح سيمحو تقدّمك ويجبرك على بدء الأسبوعين من جديد. لن يحدث ذلك. شرط الـ14 يومًا يراقب مختبِريك، لا إصداراتك. يفصل هذا الدليل ما يقطع نافذة الاختبار المغلق عمّا لا يقطعها، ويمنحك أداتين تفاعليتين لاختبار أي إجراء بنفسك، ويشرح ما الذي تتحقق منه عندما لا يرى المختبِرون إصدارًا جديدًا. آخر مراجعة له مقابل صفحات مساعدة Google كانت في 16 أكتوبر 2026.
في هذا الدليل
هل يعيد تحديث تطبيقي ضبط عدّاد 14 يومًا للاختبار المغلق؟
لا. هذا أكثر مخاوف المطوّرين شيوعًا أثناء نافذة الاختبار، والجواب مطمئن: رفع حزمة تطبيق جديدة إلى مسار الاختبار المغلق الحالي لا يعيد بحد ذاته بدء مدة موافقة مختبِريك على المشاركة.
شرط الـ14 يومًا مرتبط بـمختبِريك، لا بـإصدارك. تقيسه Google لكل مختبِر على حدة: عندما تطلب الإصدار العلني، يجب أن يكون 12 مختبِرًا على الأقل قد وافق كلٌّ منهم على المشاركة لآخر 14 يومًا متواصلة. رقم إصدار تطبيقك، وعدد مرات رفعك لملف AAB جديد، وما تغيّره في ملاحظات الإصدار ليست جزءًا من هذا الشرط.
يتكرّر هذا السؤال بعينه مرارًا في مجتمع مطوّري Google Play. تعرّف صفحات Play Console Help لدى Google الشرط فقط من حيث المختبِرين الموافقين على المشاركة والوقت، ولا تذكر رفع الإصدارات أبدًا. وقد قدّم أحد خبراء منتجات Google الجواب العملي مباشرةً في ردّ مقبول في المجتمع في يناير 2024: التحديث أثناء الاختبار قد يحتاج إلى مراجعة، لكنه لا يعيد ضبط الـ14 يومًا. هذه قراءة خبير للسياسة، وليست جملة من السياسة نفسها.
لست متأكدًا من إجراء معيّن؟ استخدم الفاحص أدناه: اختر ما أنت على وشك فعله، وسيخبرك ما إذا كان يمس أيام مختبِريك الـ14.
أي إجراء يقلقك؟
مبني على شرط Play Console المنشور لدى Google (مختبِرون وافقوا × أيام متواصلة) وتجربة مطوّرين شائعة. الخطران المُبلَّغان من المجتمع مُعلَّمان كذلك.
ما الذي يعيد ضبط مؤقت 14 يومًا فعليًا؟
أفضل فهم لنافذة 14 يومًا المتواصلة أنها فحص اتساق، لا عدّاد تقويم سلبي. تريد Google أن ترى أنك حافظت على 12 مختبِرًا على الأقل وافقوا على المشاركة بلا انقطاع. هناك فقط محفّزان مؤكدان يكسران تلك الاستمرارية:
عدد من وافقوا ينخفض دون 12
إذا غادر مختبِر واحد وانخفض عدد المختبِرين المؤهَّلين لديك إلى 11، فلا يمكنك تقديم الطلب حتى يكمل مختبِر ثانٍ عشر 14 يومًا دون انقطاع، والبديل يبدأ من اليوم الأول. ولهذا فالعمل بـ12 مختبِرًا بالضبط محفوف بالمخاطر.
خروج المختبِرين رسميًا من الاختبار
ينسحب المختبِر بفتح رابط الاختبار على الويب واختيار المغادرة. هذا مختلف عن إزالة التثبيت. تتوقف الأيام الـ14 الخاصة بذلك المختبِر، وعودته تبدأها من جديد. ولا يؤخر ذلك طلبك إلا إذا ترك أقل من 12 مختبِرًا مؤهَّلًا.
رفع إصدار جديد ليس في تلك القائمة. ولا إصلاح خطأ مطبعي في قائمة المتجر، ولا إرسال مختبِر لملاحظات، ولا تعطل تطبيقك على جهازه: الأخيرة هي جوهر الاختبار. المحاكي أدناه يجعل الفرق واضحًا: اضغط زر التحديث مرارًا ولا يتحرك شيء، لكن اخسر مختبِرين دون 12 فتنهار السلسلة.
ما لا يعيد ضبط العدّاد
رفع AAB جديد على نفس المسار
تعديل ملاحظات الإصدار أو قائمة المتجر
مختبِر يرسل ملاحظات
تعطل التطبيق على جهاز مختبِر
رفع version code أو اسم الإصدار
مختبِر يزيل التثبيت دون الخروج
كيف أرفع تحديثًا إلى اختبار مغلق؟
رفع تحديث هو نفس تدفق إصدارك الأول، مع فرق مهم: تنشئ الإصدار الجديد على نفس مسار الاختبار المغلق الذي وافق عليه المختبِرون. لا تبدأ اختبارًا جديدًا: تضيف buildًا إلى اختبار يعمل، ولهذا بالضبط يستمر عدّاد 14 يومًا. هاتان الخطوتان في Play Console.
أنشئ إصدارًا جديدًا على مسارك المغلق Test and release > Testing > Closed testing > Manage track
افتح مسار الاختبار المغلق الذي تشغّله، وانقر Create new release، وارفع حزمة التطبيق المحدّثة (AAB). حافظ على نفس اسم الحزمة وإعدادات التوقيع، وامنح الإصدار versionCode أعلى: تغيير versionName وحده لا يُعدّ ترقية. أضف ملاحظات إصدار قصيرة تصف ما تغيّر، ثم احفظ. أبقِه على نفس المسار؛ فهذا ما يُبقي أيام مختبِريك الـ14 مستمرة.
راجع الإصدار وابدأ الطرح Review release > Start roll-out
تابع عبر Next وReview release، ثم ابدأ الطرح على مسارك المغلق. بعد ذلك افتح Publishing overview: إذا كانت هناك تغييرات في الانتظار، فاختر Send changes for review، وإذا كان النشر المُدار مفعّلًا، فانشر التغييرات المعتمدة بنفسك. قد يظهر التحديث المُرسَل بحالة In review قبل أن يتلقّاه المختبِرون، وتذكر Google أن التغيير المنشور قد يستغرق عدة ساعات ليصل إليهم. يتلقّى المختبِرون الحاليون التحديث عادةً في مكانه، بلا إعادة تثبيت وبلا موافقة ثانية على المشاركة.
هذا لا يعيد بدء مدة موافقة مختبِريك على المشاركة. لأنك تطرح الإصدار على نفس المسار المغلق الذي وافق مختبِروك على المشاركة فيه، تستمر أيامهم الـ14 تحت الإصدار الجديد. أنت تضيف إصدارًا، لا تبدأ اختبارًا جديدًا. إذا ظل المختبِرون لا يرون الإصدار الجديد، فاتبع الفحوصات في القسم التالي.
لماذا لا يتلقّى المختبِرون الإصدار الجديد؟
تحقّق أولًا مما إذا كان الإصدار المقصود منشورًا في مسار الاختبار الخاص بالمختبِر، ثم تحقّق من حساب المختبِر والإصدار المثبّت، وبعد ذلك فقط من الهاتف. هذا ترتيب للفحوصات، وليس ترتيبًا للأسباب الأكثر شيوعًا. تنتهي المهمة عندما يثبّت مختبِر مؤهَّل الإصدار المقصود ويعيد اختبار التغيير؛ فظهور تاريخ جديد في صفحة المتجر لا يكفي.
تحديثي لا يزال قيد المراجعة
قد يحتاج التحديث المُرسَل إلى مراجعة قبل أن يصل ذلك الإصدار إلى المختبِرين. افتح Publishing overview في Play Console وتصرّف وفق ما يظهر لك:
- Changes not yet sent: راجع القائمة واختر Send changes for review.
- In review: تأكّد من أنه التطبيق والمسار والإصدار الصحيح، واتبع أي رسالة تظهر في Console. لا ترفع إصدارًا آخر لمجرد تحديث الحالة؛ فـGoogle تحتسب مدة المراجعة من آخر تغيير تم إرساله.
- Changes ready to publish: ميزة النشر المُدار مفعّلة، لذا انشر التغييرات المعتمدة بنفسك.
انتظار إصدار للمراجعة وبقاء مختبِريك موافقين على المشاركة حالتان منفصلتان. لا توثّق Google أن مراجعة تحديث عادي توقف مدة موافقة مختبِريك على المشاركة مؤقتًا أو تعيد ضبطها.
بعض المختبِرين فقط يستطيعون التحديث
لا يصل التحديث المنشور إلا إلى المختبِرين الذين طُرح لهم وأصبحوا مؤهَّلين له. تحقّق من هذه النقاط بالترتيب:
- الطرح المرحلي: يمكن أن تستخدم التحديثات في مسارات الاختبار، بما فيها الاختبار المغلق، نسبة طرح، وهذه النسبة لا ترتفع من تلقاء نفسها. في Closed testing > Releases، افتح Manage rollout لترى النسبة وما إذا كان الطرح متوقفًا.
- الحساب: يجب أن يكون العنوان الموجود في قائمتك أو في مجموعة Google، والحساب الذي وافق على المشاركة، والحساب المسجَّل الدخول به في بلاي ستور هو نفسه.
- الاختبار الداخلي: المختبِر الذي لا يزال مشاركًا في اختبارك الداخلي غير مؤهَّل لإصدارات الاختبار المغلق حتى يغادر الاختبار الداخلي وينضم إلى المغلق. هذا إصلاح للتسجيل، وليس خطوة روتينية في التحديث.
- رمز الإصدار: يثبّت Google Play أعلى versionCode متوافق يكون المختبِر مؤهَّلًا له. تغيير versionName وحده لا يُعدّ ترقية.
- الجهاز: يجب أن يدعم الإصدار جهاز المختبِر، وأن تشمله إعدادات التوزيع لديك.
الإصدار متاح، لكن الهاتف لا يزال على الإصدار القديم
استخدم مسار التحديث الخاص ببلاي ستور قبل أن تلمس تسجيل المختبِر:
- افتح صفحة التطبيق على Google Play عبر رابط الاختبار واضغط Update إن ظهر، أو انتقل إلى ملفك الشخصي > Manage apps & device > Updates available.
- تحقّق من التحديث التلقائي: قد يكون متوقفًا، أو مقتصرًا على Wi-Fi، أو متوقفًا لهذا التطبيق وحده.
- تحقّق من الاتصال والمساحة التخزينية الفارغة، ثم أغلق بلاي ستور وأعد فتحه.
- بعد ذلك فقط امسح ذاكرة التخزين المؤقت لبلاي ستور (معلومات التطبيق > Storage & cache > Clear cache). مسح ذاكرة التخزين المؤقت لا يمكنه نشر إصدار لا يزال قيد المراجعة.
لا تطلب من المختبِرين مغادرة الاختبار ثم الانضمام مجددًا للحصول على تحديث. المغادرة تقطع أيام ذلك المختبِر الـ14 المتواصلة. وإزالة تثبيت التطبيق، أو مسح بيانات خدمات Google Play، أو إعادة ضبط الهاتف ليست جزءًا من التحديث العادي أيضًا.
ما الفرق بين المختبِرين المدعوّين ومن وافقوا على المشاركة؟
هذا التمييز يعثّر ناشرين أكثر من أي شيء آخر، وهو مفتاح فهم لماذا لا تهم الإصدارات للعدّاد. نظام Google يمرّر المختبِرين في قمع، والمراحل اللاحقة وحدها تحمل الوزن.
مدعو
أضفت بريدًا إلى قائمة المختبِرين أو Google Group. لم يحدث شيء أكثر بعد.
وافق على المشاركة
ضغط رابط الانضمام، سجّل بحساب Google، واختار Become a tester. هذه الحالة التي يقيسها عدّاد 14 يومًا.
ثبّت ونشط
نزّل التطبيق ويواصل استخدامه. لا يغيّر العدّ الخام، لكنه ما تزنه Google للتفاعل عند طلب الإصدار العلني.
كما توضّح وثائق Google، إضافة بريد إلكتروني لا تكفي. يجب أن يفتح كل مختبِر رابط الانضمام، ويسجّل الدخول، ويصبح مختبِرًا بشكل صريح قبل أن يُحتسب. ولهذا أيضًا لا يعيد التحديث العادي للتطبيق تقدّمك إلى البداية: يبقى مختبِروك موافقين على المشاركة، فتستمر أيامهم في الاحتساب عبر الإصدارات الجديدة. لشرح كامل، راجع دليلنا عن كيفية دعوة المختبِرين بشكل صحيح.
نصيحة من إدارة آلاف الاختبارات: أدِر مختبِريك عبر مجموعة Google بدلًا من قائمة بريد إلكتروني ثابتة. توثّق Google أن رفع ملف CSV يستبدل قائمة المختبِرين السابقة، لذا تجنّبك المجموعة مسح مختبِرين نشطين بالخطأ أثناء تعديلها. لكن المجموعة ليست ضمانًا: فالعضوية لا تزال تتحكم في الوصول، لذا فإن إزالة شخص من المجموعة أو ربط مجموعة مختلفة يغيّر من هو مؤهَّل.
ما نص شرط Google الرسمي بالضبط؟
صفحة مساعدة Play Console الرسمية «متطلبات اختبار التطبيقات لحسابات المطوّر الشخصية الجديدة» تنصّ بدقة:
«إذا كان لديك حساب مطوّر شخصي جديد، يجب إجراء اختبار مغلق لتطبيقك يضم 12 مختبِرًا على الأقل ممّن وافقوا على المشاركة لآخر 14 يومًا متواصلة.»
Google Play Console Help · answer 14151465وبشكل منفصل، عند لحظة طلب الإصدار العلني:
«يجب أن يكون 12 مختبِرًا على الأقل قد وافقوا على المشاركة في اختبارك المغلق عند تقديم طلب الإصدار العلني. ويجب أن يكونوا قد وافقوا على المشاركة لآخر 14 يومًا متواصلة.»
Google Play Console Help · answer 14151465توضّح Google أيضًا بكلماتها أن الأيام يجب أن تكون متتالية: لن تُحتسب مختبِرين وافقوا، اختبروا أقل من 14 يومًا، ثم خرجوا، وحتى إن عادوا، يجب أن تكون الـ14 يومًا متتالية لتُحتسب. ذلك البند وحده يقتل أسطورة «14 يومًا تراكمية»، والأهم: لا يقول شيئًا عن إصداراتك.
ثلاث حقائق لتثبيتها
هل رفع التحديثات أثناء الاختبار جيد أم سيء؟
هنا ينقلب قلق المطوّر إلى فرصة. رفع التحديثات أثناء الاختبار المغلق يُنظر إليه على نطاق واسع كإشارة تفاعل إيجابية. يجدر فصل ما تقوله Google رسميًا عمّا خلص إليه مجتمع المطوّرين، لأنهما يتداخلان دون أن يكونا متطابقين:
واصل التكرار والإصلاح
تشجّع مساعدة Play Console على التكرار المستمر: واصل استخدام الاختبار المغلق أثناء إصلاح المشاكل والأخطاء التي يبلّغ عنها المستخدمون، وتحديث تطبيقك في الاختبار المغلق قبل الإصدار العلني «طريقة رائعة لتقليل التقييمات والمراجعات منخفضة الجودة».
عند طلب الإصدار العلني، تطلب منك الأسئلة وصف التفاعل الذي تلقيته وما فعلت بملاحظات المختبِرين.
النشط يتفوّق على المتجمّد
يذهب الممارسون أبعد من ذلك: التطبيق المتجمّد عند الإصدار 1.0 لمدة 14 يومًا بلا أي نشاط يبدو اختبارًا لاستيفاء الشكل فقط، بينما التطبيق الذي ينشر إصلاحات استجابةً للملاحظات يبدو تطويرًا حقيقيًا. ينشر بعض المطوّرين تحديثين أو ثلاثة تحديثات صغيرة لإظهار الاستجابة، لكن Google لا تنشر أي حصة من هذا النوع (راجع قسم عدد الإصدارات أدناه).
هذا رأي متداول في المجتمع واستنتاج معقول، وليس قاعدة منشورة من Google. لم تحدّد Google أي شرط رقمي من نوع "انشر X تحديثات".
الخلاصة: التحديث آمن ومشجَّع، وقصة التفاعل التي تبنيها به قد تساعدك في الإجابة عن أسئلة طلب الإصدار العلني. الخطر الحقيقي الوحيد يأتي مما تنشره، لا من فعل النشر: وهذا يقود إلى التحفّظ الوحيد الجوهري.
هل أحتاج إلى إصدارين أو ثلاثة أثناء الاختبار المغلق؟
لا تحدّد إرشادات Google المنشورة للاختبار المغلق حدًا أدنى لعدد الإصدارات. فهي توصي بالتصرف بناءً على ملاحظات المختبِرين وإصلاح المشكلات التي يكشفها الاختبار، ويطلب منك طلب الإصدار العلني وصف أي تغييرات أجريتها. عدد مرات الرفع ليس جزءًا من الشرط.
- أبقِ 12 مختبِرًا على الأقل موافقين على المشاركة لمدة 14 يومًا دون انقطاع (شرط منشور)
احمِ استمرار موافقة كل مختبِر على المشاركة منذ اليوم الأول. - تصرّف بناءً على الملاحظات وأصلِح المشكلات التي يكشفها الاختبار (إرشادات Google)
احتفظ بسجل موجز للملاحظات والإصلاح وإعادة الاختبار. - انشر إصدارين أو ثلاثة مهما حدث (موروث متداول في المجتمع، لا حصة منشورة)
لا تختلق تغييرات، ولا تتوقع أن يكسب لك عدد الإصدارات الموافقة.
من أين جاءت هذه النصيحة: أقدم صيغة صريحة عثرنا عليها هي تخمين من أحد المطوّرين، في نقاش يعود إلى أكتوبر 2024، بأن تحديثين أو ثلاثة قد تُظهر لـGoogle عملًا قائمًا على الملاحظات. تكرّرت في نقاشات المجتمع خلال أسابيع، ثم ظهرت لاحقًا في أدلة وكأنها توصية من Google. المصدر الأصلي غير معروف، ويفيد المطوّرون بحالات رفض مع عدة تحديثات وبدونها، لذا فعدد الإصدارات وحده لا يثبت شيئًا.
إذا كشف الاختبار مشكلة حقيقية، فأصلِحها وانشر الإصدار واطلب من المختبِرين إعادة الاختبار. وإن لم يكشف شيئًا، فقل ذلك بصدق عندما تجيب عن أسئلة طلب الإصدار العلني. كما أن رفع إصدارات شكلية بينما يكون تحديث قيد المراجعة قد يعيد تطبيقك إلى الخلف في قائمة انتظار المراجعة، لأن Google تحتسب مدة المراجعة من آخر تغيير تم إرساله.
هل يمكن أن يعيد تحديث سيء ضبط العدّاد بشكل غير مباشر؟
نعم: وهذا التحفّظ الوحيد المهم. بينما فعل التحديث لا يعيد المؤقت مباشرة، قد تفعل عواقب تحديث مكسور ذلك. اتبع السلسلة:
إذن القاعدة بسيطة: حدّث بحرية، لكن افحص كل إصدار لاستقرار أساسي قبل رفعه إلى مسارك المغلق. ولا تشغّل عند 12 مختبِرًا بالضبط، لأن خروجًا واحدًا من إصدار سيء قد يسقطك. هامش مختبِرين فوق 12 يمتص ذلك الخطر.
اقرأ السلسلة بعناية: التحديث لا يعيد بدء مدة موافقة أي مختبِر. التأخير يأتي من فقدان مختبِرين مؤهَّلين؛ والإصدار المعطّل ليس إلا ما أطلق حالات الانسحاب. أبقِ إصداراتك مستقرة واحتفظ بهامش أمان، فيصبح الخطر غير المباشر أصغر بكثير.
هل يحتاج المختبِرون إعادة تثبيت أو موافقة بعد التحديث؟
لا. المختبِرون الحاليون الذين وافقوا على المشاركة وثبّتوا تطبيقك يتلقّون التحديثات عادةً عبر Google Play في مكانها. لا يحتاجون إلى الموافقة على المشاركة مجددًا، ولا تحتاج أنت إلى إعادة إرسال الرابط.
التحديثات تُثبَّت عادةً في مكانها
تنص مساعدة Play Console، في Set up an open, closed, or internal test (answer 9845334)، بوضوح: «بمجرد أن يثبّت المختبِرون تطبيقك، يُحدَّثون تلقائيًا لاستخدام إصدار الاختبار خلال دقائق.» يبقون موافقين عبر كل إصدار: بلا إعادة تثبيت، بلا ضغطة موافقة ثانية.
تحفّظ توقيت من الصفحة نفسها: عند نشر تغييرات إضافية، «قد لا تكون متاحة للمختبِرين لعدة ساعات» قبل أن يبدأ التحديث التلقائي على الجهاز. لكن حالة الموافقة، وهي ما يقيسه عدّاد 14 يومًا، تنتقل عبر كل AAB جديد. ولهذا لا يعيد تحديث الإصدار العدّاد: المختبِرون لم يغادروا.
استثناء مهم الأذونات الجديدة قد تقطع التحديث الصامت
نوع واحد من الإصدارات لا يُطرح دائمًا بصمت: تحديث يضيف إذنًا خطيرًا (حسّاسًا) جديدًا مثل ACCESS_FINE_LOCATION أو الكاميرا أو الميكروفون. حسب الإذن ومستوى API المستهدف، قد يعرض Google Play زر Update يجب أن يضغطه المختبِر ويوافق عليه يدويًا بدل التثبيت في الخلفية، ومن يتجاهله يبقى على الإصدار القديم. وحتى عند التثبيت الصامت، يُمنح الإذن الجديد وقت التشغيل فقط، فقد تبدو ميزة مشروطة بالإذن مكسورة حتى يسمح المختبِر.
في الاختبار المغلق هذا فخ صامت: انشر تحديثًا يطلب أذونات كثيرة في منتصف الاختبار، وقد يبقى بعض المختبِرين على الإصدار القديم أو يجدون ميزة محظورة حتى يمنحوا الإذن. وقد يحتاج إذن جديد عالي الخطورة أيضًا إلى Permissions declaration (تصريح الأذونات) في Play Console قبل أن يمكن نشر الإصدار أصلًا. الموافقة أثناء التشغيل على الهاتف والتصريح في Console فحصان منفصلان.
قبل الطرح في منتصف الاختبار: قارن أذونات الـ manifest الجديد مع الإصدار الحي. إن تغيّرت مجموعة الأذونات، راسل مختبِريك ليفتحوا متجر Play ويحدّثوا يدويًا (ويوافقوا على المطالبة الجديدة)، واحسب وقتًا لمراجعة تصريح محتملة.
أساطير شائعة عن الاختبار المغلق، مفكّكة
معظم الذعر حول التحديث يعود إلى حفنة أساطير. هذه الخمس التي تكلّف المطوّرين أكثر نوم، مع ما هو صحيح فعليًا:
أسطورة 1«إنشاء إصدار جديد يعيد ضبط العدّاد.»
أسطورة 2«إزالة التثبيت تساوي الخروج من الاختبار.»
أسطورة 3«الـ14 يومًا تراكمية.»
أسطورة 4«12 مختبِرًا بالضبط يكفي.»
أسطورة 5«يجب أن يستخدم المختبِرون التطبيق كل يوم.»
ما يعيد ضبط العدّاد وما لا يعيده
السؤال كله على شاشة واحدة. احفظها، التقطها، أو أرسلها لمن في فريقك يسأل مرارًا. كل ما يتعلق بإصدارك آمن؛ فقط ما يتعلق بعدد المختبِرين ليس كذلك.
| الإجراء | يعيد عدّاد 14 يومًا؟ |
|---|---|
| رفع AAB جديد على نفس المسار المغلق | لا |
| تعديل ملاحظات الإصدار أو بيانات قائمة المتجر | لا |
| مختبِر يرسل ملاحظات | لا |
| تعطل التطبيق على جهاز مختبِر | لا |
| مختبِر يزيل التثبيت (دون الخروج) | لا* |
| انخفاض عدد من وافقوا دون 12 | نعم |
| خروج رسمي عبر رابط الاختبار الويب | نعم** |
| رفع إصدار مكسور يدفع الخروج دون 12 | بشكل غير مباشر |
| إيقاف مسار الاختبار المغلق | خطر مُبلَّغ |
| استبدال قائمة المختبِرين وحذف النشطين | خطر مُبلَّغ |
* ليس انسحابًا، لكن المختبِر الذي لا يثبّت التطبيق لا يختبره. ** فقط إذا ترك أقل من 12 مختبِرًا مؤهَّلًا. "نعم" هنا تعني أن أقرب موعد لتقديم طلبك يتأخر: المختبِرون الذين بقوا يحتفظون بأيامهم، لكن البديل يبدأ من اليوم الأول. توثّق Google أن رفع ملف CSV يستبدل القائمة السابقة وأن إيقاف الاختبار مؤقتًا يوقف التحديثات إليه؛ أما كيف تُحتسب الأيام بعد ذلك فغير موثّق، لذا تعامل مع الصفّين الأخيرين على أنهما "لا تخاطر".
كيف تغيّر الشرط عبر الزمن
إن كنت تقرأ دروسًا أقدم، فهذا سبب اختلاف الأرقام. المدة كانت دائمًا 14 يومًا متواصلة؛ فقط عدد المختبِرين تحرّك.
قبل نوفمبر 2023 لم يكن هناك اختبار مغلق مطلوب للوصول إلى الإصدار العلني. كان يمكن النشر دون جمع مختبِرين.
أعلنت Google عن هذا الشرط في 9 نوفمبر 2023. كان على الحسابات الشخصية المنشأة بعد 13 نوفمبر 2023 إجراء اختبار مغلق يضم 20 مختبِرًا وافقوا على المشاركة لمدة 14 يومًا متواصلة. وكانت حسابات المؤسسات معفاة.
في 11 ديسمبر 2024 انخفض الحد من 20 إلى 12، مع بقاء مدة 14 يومًا. حسابات المؤسسات ما زالت معفاة.
أي دليل ما زال يطلب 20 مختبِرًا قديم. نفصّل التحويل في ما تغيّر من 20 إلى 12 مختبِرًا.
تغييرات سياسة 2026 يجب أن تعرفها
الاختبار المغلق لا يعيش في فراغ. مواعيد 2026 قد تتقاطع مع جدول إطلاقك: لا يغيّر أي منها عمل عدّاد 14 يومًا، لكنها قد تصطدم بنافذتك إن لم تراقب التقويم:
مواعيد 2026 التي تتقاطع مع جدولك
التواريخ حسب مساعدة Play Console (مستوى API المستهدف) ومدونة Android Developers (التحقق من المطوّر). توقيت التحقق مرحلي وقد يتوسع عبر 2026-2027، فأكّد من الصفحات الرسمية قبل التخطيط. دليلنا عن متطلبات النشر 2026 يتتبع القائمة الكاملة.
كيف تبقي PrimeTestLab عدّادك يعمل
أصعب جزء في الاختبار المغلق ليس فهم القواعد؛ بل إبقاء 12 إنسانًا حقيقيًا أو أكثر موافقين ومتفاعلين 14 يومًا بلا انقطاع وأنت تكرّر. هذا بالضبط ما بُنيت PrimeTestLab لأجله. نوفّر مختبِرين على أجهزة حقيقية وافقوا على المشاركة ونرشد إعداد Play Console حتى يبدأ العدّاد نظيفًا ويبقى يعمل وأنت تنشر الإصلاحات. اطّلع على خدمة الاختبار المغلق لجوجل بلاي لمعرفة ما يشمله العرض. نحافظ على نسبة نجاح 99.9% عبر 12,100+ تطبيقًا، ويبدأ الاختبار خلال 4-6 ساعات.
تضيف مختبِرينا في Play Console، وتشارك رابط الاختبار، فتبدأ الأيام الـ14. بعدها يمكنك نشر التحديثات عندما تحتاج إليها؛ ويبقى المختبِرون موافقين على المشاركة بينما تطوّر تطبيقك.
تمنحك الخطة التي تتجاوز الحد الأدنى البالغ 12 مختبِرًا مختبِرين إضافيين يبدؤون في اليوم نفسه، فلا يتركك انسحاب واحد، بما فيه انسحاب بسبب إصدار سيئ، بأقل من 12. الهامش لا يفيد إلا إذا وافق هؤلاء المختبِرون على المشاركة مبكرًا: فالبديل المتأخر يبدأ 14 يومًا خاصة به. الأسعار لكل تطبيق، مع 5% رسوم خدمة إضافية (بحد أدنى $1.50) عند الدفع.
الأسئلة الشائعة
هل يمكنني تحديث تطبيقي أثناء الاختبار المغلق دون إعادة 14 يومًا؟
نعم. التحديث العادي لنفس التطبيق على مسار اختباره المغلق الجاري لا يعيد بحد ذاته بدء مدة موافقة المختبِرين على المشاركة. حافظ على أهلية مختبِريك الحاليين وموافقتهم على المشاركة. قد يحتاج الإصدار الجديد مع ذلك إلى مراجعة ونشر قبل أن يتمكن المختبِرون من تثبيته، لذا تحقّق من وصوله بشكل منفصل عن شرط الاختبار.
ما الشيء الوحيد الذي يعيد ضبط عدّاد الاختبار المغلق؟
لا تنشر Google قائمة لإعادة الضبط تغطي كل إجراء في Console. يتعلّق الشرط باستمرار موافقة كل مختبِر على المشاركة. المختبِر الذي يغادر ثم يعود يبدأ أيامه الـ14 من جديد، وفقدان عدد كافٍ من المختبِرين المؤهَّلين قد يؤخر طلبك. والمختبِر البديل الجديد يبدأ من اليوم الأول. أما تحديث الإصدار العادي فحدث مختلف.
ما الفرق بين المدعوّين ومن وافقوا على المشاركة؟
مدعو يعني أن الحساب موجود في قائمة المختبِرين لديك أو في مجموعة Google. وافق على المشاركة يعني أن المختبِر فتح رابط الاختبار بذلك الحساب وانضم إلى الاختبار. إدراج العنوان وحده لا يُكمل التسجيل. اطلب من المختبِرين تأكيد الحساب، ثم تثبيت التطبيق واستخدامه وإرسال ملاحظات مفيدة.
هل يجب أن يعيد المختبِرون الموافقة بعد رفع تحديث؟
في العادة، لا. يتلقّى المختبِرون المؤهَّلون الحاليون التحديث العادي عبر Google Play دون الانضمام إلى الاختبار نفسه مجددًا. حافظ على تسجيلهم سليمًا، ثم اطلب منهم التحقق من صفحة التطبيق والإصدار المثبّت. يعتمد التثبيت التلقائي على توفّر الإصدار وعلى إعدادات الجهاز، لذا لا تعد كل مختبِر بوصول التحديث خلال دقائق.
هل إزالة التثبيت مثل الخروج من الاختبار؟
لا. إزالة التثبيت تحذف التطبيق من الهاتف؛ أما الانسحاب فيغيّر المشاركة في الاختبار. لا عدد عمليات التثبيت اليوم ولا قائمة الدعوات اليوم يثبتان استمرار التسجيل. والمختبِر الذي أزال التثبيت لا يستطيع اختبار ذلك التثبيت أيضًا، لذا تأكّد من أنه لا يزال في الاختبار واطلب منه إعادة التثبيت ومواصلة الاختبار.
هل تريد Google أن أرفع تحديثات أثناء الاختبار؟
توصي Google بالتصرف بناءً على ملاحظات المختبِرين وإصلاح المشكلات، ويسأل طلب الإصدار العلني عمّا غيّرته بعد الاختبار. لكنها لا تنشر عددًا مطلوبًا من الإصدارات. انشر إصلاحات مفيدة عندما تحتاج إليها، وسجّل ما تغيّر وأعد اختباره. لا تنشر إصدارات شكلية لمجرد استيفاء قاعدة مزعومة بتحديثين أو ثلاثة.
كم مختبِرًا أحتاج فعليًا للاختبار المغلق؟
للحسابات الشخصية المنشأة بعد 13 نوفمبر 2023، الحد الأدنى هو 12 مختبِرًا بقي كلٌّ منهم موافقًا على المشاركة لآخر 14 يومًا متتالية عند تقديمك الطلب. استقطاب مختبِرين إضافيين مبكرًا يمنحك هامش أمان. البدلاء الذين يُضافون متأخرين لا يرثون أيام المختبِرين الذين غادروا، ولا يوجد عدد مختبِرين يضمن منح إذن الإصدار العلني.
هل يجب أن أنشر تحديثين أو ثلاثة لاجتياز الاختبار؟
لا تحدّد إرشادات Google المنشورة هذه الحصة. فهي تسأل عن الاختبار والملاحظات والتغييرات ومدى الجاهزية. إذا كشف الاختبار مشكلة حقيقية، فأصلِحها وسجّل إعادة الاختبار. وإن لم يكشف شيئًا، فصِف الاختبار بصدق. عدد الإصدارات وحده لا يثبت أن الاختبار كان مفيدًا، ولا يضمن منح إذن الإصدار العلني.
إصداري متاح، فلماذا لا يزال المختبِر على الإصدار القديم؟
تحقّق من حساب Google الخاص بالمختبِر، وتسجيله في المسار، ونسبة الطرح، وversionCode. ثم اطلب منه فتح صفحة التطبيق على Google Play والتحقق من وجود Update. قد يكون التحديث التلقائي متوقفًا أو مؤجَّلًا بسبب ظروف الجهاز. تأكّد من أن الإصدار ثُبّت فعلًا؛ فتاريخ التحديث في صفحة المتجر لا يكفي.
هل توقف حالة "In review" اختبار الـ14 يومًا مؤقتًا؟
التحديث قيد المراجعة ينتظر أن تعالج Google ذلك الإصدار. لا توثّق Google أن مراجعة تحديث عادي توقف مدة الموافقة على المشاركة الحالية لمختبِريك. تحقّق من أن الاختبار الجاري لا يزال متاحًا وأن التسجيل سليم. قد يؤخر إرسال آخر مراجعة الإصدار، وهي أمر منفصل عن شرط الاختبار المتواصل.
هل يجب أن يغادر المختبِرون الاختبار ثم ينضموا مجددًا للحصول على التحديث؟
لا. مغادرة الاختبار المغلق ثم الانضمام إليه مجددًا ليست حلًا لمشكلة التحديث، وهي تقطع أيام موافقة ذلك المختبِر المتتالية. تحقّق أولًا من النشر، وحساب المختبِر، والطرح، وversionCode، ثم جرّب مسار التحديث العادي في بلاي ستور. أصلِح التسجيل الخاطئ فعلًا بشكل منفصل، مع إدراك ما يفعله ذلك بأيام هذا المختبِر الـ14.
الخلاصة
ملخص
تحديث تطبيقك أثناء الاختبار المغلق لمدة 14 يومًا آمن وطبيعي ومشجَّع. تقيس Google استمرار موافقة كل مختبِر على المشاركة دون انقطاع، لذا فإن التحديث العادي لنفس المسار المغلق لا يعيد بدء أيام مختبِريك الـ14. المخاطر الحقيقية هي فقدان مختبِرين مؤهَّلين، أو انسحاب المختبِرين رسميًا، أو نشر إصدار معطّل لدرجة أن يتركه المختبِرون. انشر إصلاحات حقيقية، وتصرّف بناءً على الملاحظات، واحمِ عدد مختبِريك بهامش تستقطبه مبكرًا. إن أردت مساعدة في إبقاء 12 مختبِرًا أو أكثر موافقين على المشاركة، توفّر PrimeTestLab من 12 إلى 25 مختبِرًا حقيقيًا ابتداءً من $19.99 مع 5% رسوم خدمة إضافية (بحد أدنى $1.50)، ويبدأ الاختبار خلال 4-6 ساعات. وإن لم يُمنح إذن الإصدار العلني بعد الاختبار الكامل، فلك الخيار بين إعادة الاختبار مجانًا أو استرداد كامل المبلغ. اطّلع على خطط الأسعار ←