إجابة سريعة
يشترط جوجل بلاي على التطبيقات التي تستهدف Android 15 (مستوى API 35) أو أعلى دعم أحجام صفحات الذاكرة 16 KB على أجهزة 64 بت، ومن 1 فبراير 2027 لن تتمكّن من إصدار تحديثات لا تدعمها. التطبيق المكتوب بلغة Java أو Kotlin وحدها، بما في ذلك كل مكتباته وحِزَم SDK فيه، متوافق أصلًا. أما التطبيق الذي يحزم مكتبات .so أصلية فيفشل حتى تُعاد بناء كل واحدة منها أو تُستبدل، ويُفضَّل ذلك بـ Android Gradle Plugin 8.5.1+ وNDK r28+، وحتى يجتاز البناء فحصين منفصلين: أن يكون كل مقطع LOAD في ELF محاذًى عند 2**14 على الأقل، وأن تُبلّغ حزمة التطبيق عن PAGE_ALIGNMENT_16K. ترقية إطار العمل ليست دليلًا؛ الدليل هو الناتج نفسه. وإذا أوقف حلُّ هذا التحذير اختبارًا مغلقًا (closed testing) كنت في منتصفه، فإن PrimeTestLab (برايم تست لاب) تُبقي جانب المختبِرين يعمل بينما تعيد أنت البناء.
التحذير قصير، ويذكر اسم ملف واحد في أحسن الأحوال، ويصل بعد أن تكون قد ظننت البناء منتهيًا. لهذا تتكرّر المنعطفات الخاطئة الثلاثة نفسها: أن تثق بموعد تغيّر، أو أن ترقّي إطار عمل وتفترض أن المهمة انتهت، أو أن تفحص ملف APK محليًا واحدًا ولا تنظر أبدًا إلى الحزمة التي يبني منها جوجل فعلًا. رتّبنا هذا المقال بالترتيب الذي تُحلّ به المشكلة حقًا: التحديد، ثم نسب المسؤولية، ثم الإصلاح، ثم الإثبات. وكل ما فيه محدَّث حتى 5 أغسطس 2026، وقُوبل بدليل جوجل لأحجام الصفحات في اليوم نفسه الذي جرى فيه آخر تحديث لتلك الصفحة. وحيثما كان الدليل تتبّعَ مشكلات لدى مشرف مشروع لا ملاحظةَ إصدار رسمية، تقول البطاقة ذلك بدل ترقيته إلى حقيقة.
مختبر المحاذاة
اثنتا عشرة أداة بُنيت لهذا الخطأ وحده. لا شيء هنا يحتاج حسابًا ولا رفعًا ولا طلبًا عبر الشبكة، فكل أداة تعمل داخل متصفحك على القيم التي تكتبها بنفسك.
المحتويات
الحل في ثلاث خطوات
كل حلّ حقيقي لهذا الخطأ هو الحركات الثلاث نفسها بالترتيب نفسه: حدِّد المكتبة الأصلية غير المحاذاة، ثم حدِّث الاعتمادية التي تملكها، ثم تحقّق من الناتج الذي توشك على رفعه. والقفز مباشرةً إلى الخطوة الثانية هو سبب أن كثيرًا من المطوّرين يرقّون إطار عمل ويعيدون البناء ثم يرون التحذير يعود كما هو.
الشرط نفسه ضيّق النطاق. يقول دليل جوجل لأحجام الصفحات إن التطبيقات التي تستهدف Android 15 (مستوى API 35) أو أعلى يجب أن تدعم أحجام صفحات الذاكرة 16 KB على أجهزة 64 بت، وإنك اعتبارًا من 1 فبراير 2027 لن تتمكّن من إصدار تحديثات لا تفعل ذلك. وهو ينطبق على الشيفرة الأصلية وحدها. فإذا كان تطبيقك وكل مكتبة وحزمة SDK داخله بلغة Java أو Kotlin خالصة، فإن جوجل ينصّ على أن تطبيقك يدعم أجهزة 16 KB أصلًا. المشكلة أن معظم من يرى هذا التحذير يظنّ نفسه في تلك الفئة وهو ليس فيها.
حدِّد ملف .so المسبِّب
افتح ملف APK الخاص بالإصدار في Android Studio عبر Build > Analyze APK...، ووسّع lib/arm64-v8a وlib/x86_64، واقرأ عمود Alignment. دوّن كل اسم ملف يُشار إليه، فهذه الأسماء هي مفاتيح البحث الوحيدة الموثوقة لديك.
حدِّث الجهة التي تملكه
الملف الثنائي الذي جمّعته بنفسك تصلحه سلسلة أدواتك: AGP 8.5.1 فأحدث مع NDK r28 فأحدث. أما الملف الذي وصل داخل إضافة أو حزمة SDK أو محرّك أو AAR فلا يصلحه إلا من بناه، ولذلك يكون التصرّف هو ترقية تلك الحزمة أو استبدالها أو طلب ناتج مُعاد بناؤه منها.
اعرف أقصر مسار لإطار عملكتحقّق من الناتج لا من الترقية
يجب أن يجتاز فحصان مستقلّان معًا. أن يكون كل مقطع LOAD في ELF محاذًى عند 2**14 أو أكثر، وأن يُبلّغ bundletool عن PAGE_ALIGNMENT_16K لحزمة الإصدار. واجتياز أحدهما لا يثبت شيئًا عن الآخر.
القرار كلّه في شاشة واحدة
قبل أن تغيّر إصدار اعتمادية واحدة، اسلك هذا المسار. يستغرق دقيقتين تقريبًا، وهو الفارق بين إصلاح الشيء الصحيح وترقية إحدى عشرة حزمة لم تكن يومًا سبب المشكلة.
هل يحتوي ملف APK الخاص بالإصدار على مجلد lib فيه ملفات .so؟
متوافق أصلًا
لا شيفرة أصلية في ملف APK. ينصّ جوجل على أن التطبيق المكتوب بلغة Java أو Kotlin وحدها، بما في ذلك مكتباته وحِزَم SDK فيه، يدعم أجهزة 16 KB أصلًا. ومع ذلك تستحق تجربة اختبار واحدة، ويستحق التأكّد من أنك فحصت البناء نفسه الذي رفعته.
هل يذكر APK Analyzer أو check_elf_alignment.sh مكتبة غير محاذاة؟
انسب المسؤولية ثم رقِّ
اعرف أي إطار عمل أو إضافة أو حزمة SDK أو محرّك يوفّر اسم الملف بعينه، وحدِّث تلك الحزمة. فـ NDK لديك لا يستطيع إعادة كتابة ملف ثنائي بناه غيرك.
بماذا يُبلّغ bundletool dump config عن حزمة الإصدار؟
PAGE_ALIGNMENT_4K
المكتبات سليمة والخلل في طريقة الحزم. انتقل إلى AGP 8.5.1 فأحدث وأعد البناء، أو طبّق حلّ الحزم القديم إن تعذّرت الترقية.
PAGE_ALIGNMENT_16K
طريقة الحزم صحيحة. اختبر الآن ملفات APK التي يولّدها Play على بيئة 16 KB حقيقية، وراجع أي شيفرة تعمل وقت التشغيل وتفترض حجم صفحة ثابتًا.
الفخّ في سطر واحد
ملف APK محلي يجتاز كل فحوص المحاذاة لا يثبت أن الحزمة التي رفعتها صحيحة. يحذّر جوجل تحديدًا من أن Android Gradle Plugin من 8.3 إلى 8.5 قد يُنتج حزمة تكون ملفات APK التي يبنيها Play منها غير محاذاة في ZIP، حتى لو بدا ملف APK على جهازك مثاليًا. وهذا التفاوت هو السبب الأكثر شيوعًا لبقاء التحذير بعد إصلاح «ناجح».
ما الذي يعنيه تحذير Play Console فعلًا
النتيجة التي وثّقها جوجل دقيقة: اعتبارًا من 1 فبراير 2027 لن تتمكّن من إصدار تحديثات تستهدف Android 15 (مستوى API 35) أو أعلى من دون دعم 16 KB. إنه حظر على إصدار التحديثات لا قول بأن تطبيقًا منشورًا سيُزال من المتجر في ذلك اليوم. وحتى ذلك الحين يرى معظم المطوّرين تحذير توافق لا رفضًا عند الرفع.
الصياغة مهمّة لأن النسخة المذعورة من هذه القصة تنتشر أسرع من النسخة الدقيقة. اقرأ النصوص التي يعرضها جوجل فعلًا، يصبح النطاق ضيّقًا وقابلًا للإدارة.
App must support 16 KB memory page sizes
أُعيد بناؤها عن لقطة Play Console التي نشرها جوجل في دليل أحجام الصفحات. النصوص باقية بالإنجليزية كما في تلك اللقطة: قد تعرضها لوحتك بالعربية، وقد يختلف التخطيط والأزرار المتاحة بحسب الحساب.
هناك قراءتان خاطئتان شائعتان لهذه البطاقة. الأولى أن عبارة "Action by Feb 1, 2027" ليست عدًّا تنازليًا نحو الحذف؛ فنصّ جوجل نفسه في الصفحة ذاتها يصف النتيجة بأنها تعذّر إصدار تلك التحديثات. والثانية أن عبارة Extension granted تظهر في لقطة جوجل، لكن ذلك لا يثبت أن إجراء طلب تمديد مفتوح أمامك الآن. فاعتبر التمديد قائمًا فقط إذا رأيت الخيار داخل Play Console الخاص بك.
أي موعد قرأت بالضبط؟
ثلاثة تواريخ متداولة وواحد فقط ساري المفعول. اختر ما رأيته لتعرف حالته مقارنةً بصفحة جوجل الحالية التي جرى آخر تحديث لها في 5 أغسطس 2026.
الأداة 01
محدِّد المواعيد
حرّك جوجل هذا الموعد أكثر من مرة. وقبل أن تبني خطة إصدار حول 1 فبراير 2027، افتح دليل أحجام الصفحات بنفسك وتحقّق من ختم "Last updated" في أسفله. هذه العادة وحدها تساوي أكثر من أي تاريخ مطبوع في مقال، بما في ذلك هذا المقال.
هل يخصّ شرط 16 KB تطبيقي؟
ليس إطار عملك هو ما يحسم ذلك، بل محتوى ملف APK الذي تولّده. فإن وُجدت ملفات .so تحت lib فأنت داخل النطاق سواء فتحت ملف C++ يومًا أم لا، وإن لم يوجد أي منها فإن إرشادات جوجل نفسها تقول إنك تدعم أجهزة 16 KB أصلًا.
التطبيقات المكتوبة بلغة Java أو Kotlin وحدها
جوجل واضح هنا: إذا كان تطبيقك وكل مكتباته وحِزَم SDK فيه يستخدم Java أو Kotlin فقط، فإن تطبيقك يدعم أجهزة 16 KB أصلًا. ومع ذلك يوصي جوجل بالاختبار في بيئة 16 KB لالتقاط أي تراجع غير متوقّع، وهو ما يكلّفك تشغيل محاكٍ واحدًا.
والمأزق في عبارة «وكل مكتباته وحِزَم SDK فيه». فاعتمادية واحدة لقاعدة بيانات أو تحليلات أو تقارير أعطال أو وسائط أو خرائط أو تعلّم آلي أو أمان قد تضيف ملفات ثنائية أصلية إلى مشروع لا يحتوي مصدره إلا على Kotlin. عبارة «لم أكتب C++» ليست دليلًا؛ الدليل هو مجلد lib.
Flutter وReact Native وUnity وKivy وأدوات البناء بلا شيفرة
هذه البيئات تحمل بحكم تصميمها أنظمة تشغيل أصلية وملفات محرّكات ومكتبات إضافات، فهي داخل النطاق في الغالب دائمًا. ويسمّي جوجل صراحةً أدوات بناء التطبيقات من أطراف أخرى التي تستخدم مكتبات أصلية بوصفها طريقًا لتأثّر تطبيق لم يكتب صاحبه C أو C++ قط. وما يختلف ليس وجود شيفرة أصلية عندك بل أي حزمة أدخلت الجزء المسبِّب، ولهذا يأتي نسب اسم الملف إلى مصدره قبل أي ترقية.
كيف تفحص بدقّة
افتح ملف APK الخاص بالإصدار، ووسّع lib، وانظر إلى مجلدات ABI داخله، وهي عادةً arm64-v8a وx86_64. ووجود أي ملفات كائن مشترك يعني أن تطبيقك يستخدم شيفرة أصلية. أما غياب ملفات .so ومجلد lib معًا فيعني أن ملف APK هذا لا يستخدم شيفرة أصلية إطلاقًا. ويعرض عمود Alignment في المحلّل رسائل تحذير للملفات ذات مشكلات المحاذاة، وهو أسرع طريق من «هناك خلل ما» إلى اسم ملف محدّد.
الأداة 02
تشخيص النطاق
01 ما الذي يستهدفه تطبيقك حاليًا؟
02 افتح ملف APK الخاص بالإصدار في APK Analyzer. هل يوجد مجلد lib؟
03 أي وصف ينطبق على التطبيق أكثر؟
04 هل شغّلت bundletool dump config على حزمة الإصدار؟
لماذا يفشل ملف ثنائي بحجم 4 KB على جهاز 16 KB
صفحة الذاكرة هي أصغر كتلة تعيّنها النواة دفعةً واحدة. وقد استخدم أندرويد تاريخيًا صفحات بحجم 4 KB، ثم أضاف Android 15 دعم الأجهزة المهيّأة بصفحات 16 KB. والمكتبة الأصلية تسجّل المحاذاة التي رُبطت مقاطعها عليها، فإذا كانت تلك القيمة أصغر من حجم صفحة الجهاز تعذّر على المحمِّل وضع المقطع عند حدّ صفحة.
هذه هي الآلية كلها، وهي تفسّر الرقم الذي ستراه مرارًا. تُكتب المحاذاة كقوة للعدد 2: فـ 2**12 يساوي 4096 بايت، و2**14 يساوي 16384 بايت. وقاعدة جوجل أن كل مقطع LOAD في المكتبة الأصلية يجب أن يكون محاذًى عند 2**14 أو أكثر. والمكتبة المبنية عند 2**14 تعمل على أجهزة 4 KB و16 KB معًا، لأن 16384 مضاعف تامّ للعدد 4096. أما المبنية عند 2**12 فتعمل مع حجم الصفحة الأصغر وحده. وبسبب هذا التفاوت يكون الحل دائمًا «ارفع المحاذاة» لا «تحقّق من نوع الجهاز».
الأداة 03
عارض الصفحات
اختر قيمة المحاذاة التي تُبلّغ عنها مكتبتك لترى أين يمكن أن تبدأ مقاطعها على جهاز يستخدم صفحات 16 KB.
ناجح
وهناك قيد ثانٍ منفصل تمامًا يقع خارج المكتبة. فالمكتبات الأصلية المخزَّنة غير مضغوطة داخل ملف APK يجب أن تقع هي أيضًا عند حدّ 16 KB داخل أرشيف ZIP نفسه. هذه خاصية حزم، تُفحص بأداة zipalign ويضبطها إضافة البناء لديك، وقد تكون خاطئة بينما كل مكتبة في الداخل محاذاة تمامًا. والفصل بين هاتين الفكرتين هو أنفع ما تخرج به من هذا القسم.
كيف تقرأ الأرقام
حين ترى 2**14 في مخرجات llvm-objdump فهذا نجاح. أما 2**13 أو 2**12 فهو فشل. لا درجات جزئية ولا «قريب بما يكفي»: يكفي مقطع LOAD واحد غير محاذًى في مكتبة واحدة في بنية ABI واحدة ليبقى التحذير على حسابك.
أقصر حل لكل إطار عمل
جاهزية إطار العمل وتوافق التطبيق أمران مختلفان. فـ React Native 0.77 وإصدارات Unity المدعومة مراجع حقيقية وموثّقة، أما Flutter فلا حدّ أدنى عامًّا قابلًا للتحقّق له. وفي كل الحالات تصلح الترقية ملفات إطار العمل نفسه وتترك كل إضافة من طرف آخر غير متوافقة كما كانت.
الأداة 04
باحث أطر العمل
ما الذي قد يفشل بعد ذلك
كل المراجع في جدول واحد
| إطار العمل | المرجع الموثّق | أقصر إجراء | الثقة |
|---|---|---|---|
| Flutter | لا حدّ أدنى عامّ مؤكّد؛ و3.38 هي محطة التهيئة الموثّقة (NDK r28 افتراضيًا) | إصدار Flutter المستقر الحالي، وتحديث الإضافات الأصلية، والتنظيف، وإعادة البناء، وفحص كل مكتبة | جزئي |
| React Native | 0.77 | مسار الترقية المدعوم، ثم تحديث الوحدات الأصلية وحِزَم SDK من المورّدين | مؤكّد |
| خط Unity 6.1 | 6000.1 فأحدث | ترقية المحرّر وتحديث الحزم والإضافات وإعادة البناء | مؤكّد |
| Unity 6 LTS | 6000.0.38f1 فأحدث | كما سبق | مؤكّد |
| Unity 2022 LTS | 2022.3.56f1 فأحدث | كما سبق | مؤكّد |
| Unity 2021 | 2021.3.48f1 فأحدث، مع أهلية الدعم الممتد | رقِّ إن كنت مؤهّلًا، وإلا فانتقل إلى محرّر مدعوم | مؤكّد |
| Unity Burst | 1.8.21 فأحدث | رقِّ Burst عند ذكر lib_burst_generated.so |
مؤكّد |
| أندرويد الأصلي | NDK r28+ مع AGP 8.5.1+ | أعد تجميع شيفرتك، وحدّث كل اعتمادية مبنية مسبقًا | مؤكّد |
| مقيَّد بـ NDK قديم | r27 أو أقدم مع خياري الرابط معًا | أضف max-page-size وcommon-page-size وأعد بناء كل المكتبات |
يعمل لكنه غير مفضّل |
| Kivy أو أداة بناء Python | لا نسخة عامّة مؤكّدة | حدّث أداة البناء والوصفات، وأبلغ المنبع باسم الملف الدقيق | يعتمد على المورّد |
| أداة بناء بلا شيفرة | لا نسخة عامّة مؤكّدة | أعد التوليد على سلسلة بناء متوافقة لدى المورّد وأرسل إليه اسم الملف | يعتمد على المورّد |
تحمل أوسمة الثقة المعنى نفسه في كل هذه الصفحة. مؤكّد يعني أن مصدرًا أوّليًا حاليًا ينصّ على ذلك مباشرةً. وجزئي يعني أن مصدرًا موثوقًا يسند الادّعاء الأساسي لا كل تفصيل تنفيذي. ومُبلَّغ عنه يعني أن الدليل تتبّع مشكلات لدى مشرف أو بلاغات مطوّرين لا ملاحظة إصدار رسمية.
حدِّد المكتبة المسبِّبة للخطأ بالضبط
اسم الملف هو التحقيق كلّه. فما إن تعرف أن libfoo.so هو الملف الثنائي المسبِّب، حتى يتحوّل السؤال من «كيف أصلح دعم 16 KB» إلى «أي حزمة توزّع libfoo.so وهل توجد نسخة أحدث». والسؤال الثاني له جواب، والأول لا.
ابدأ من APK Analyzer
افتح Build > Analyze APK...، وحمّل ملف APK الخاص بالإصدار، ووسّع lib. ستجد بداخله مجلدًا لكل بنية ABI، عادةً arm64-v8a وx86_64. ويعرض عمود Alignment رسائل تحذير للملفات ذات مشكلات المحاذاة. كما تُبرز تحذيرات Android Studio وأداة Lint المكتبات الأصلية غير المتوافقة، فقد ترى النتيجة نفسها في أكثر من موضع.
سجّل كل اسم ملف مُشار إليه قبل أن تمسّ رقم إصدار واحد. وافحص مجلدَي ABI كلًّا على حدة: من الطبيعي تمامًا أن ينجح arm64-v8a ويفشل x86_64 أو العكس، لأنهما ملفان مختلفان ربما بُنيا عبر مسارات بناء مختلفة.
اقرأ مخرجات سطر الأوامر
إن كنت تفضّل العمل في الطرفية، فجوجل يوفّر check_elf_alignment.sh الذي يُبلّغ بـ ALIGNED أو UNALIGNED لملف APK، ويمكنك فحص مكتبة واحدة مباشرةً بأداة llvm-objdump. وكلاهما يحتاج Android SDK Build-Tools 35.0.0 فأحدث. الصق ما تطبعه أيٌّ منهما أدناه وسنقرأه لك.
الأداة 05
قارئ ELF
الصق مخرجات llvm-objdump -p file.so | grep LOAD أو check_elf_alignment.sh أو zipalign -c -P 16. كل شيء يُحلَّل داخل متصفحك ولا يُرفع إلى أي جهة.
اعرف أي اعتمادية تملكها
يعطيك Play Console وAPK Analyzer اسم ملف بلا مالك. اكتبه أدناه لنخبرك بما هو معروف عن ذلك الملف الثنائي مع بيان جودة الدليل، ونعطيك أوامر البحث واسم ملفك مُدرَج فيها سلفًا.
الأداة 06
البحث عن مالك المكتبة
يعرض ./gradlew app:dependencies شجرة الاعتماديات المحلولة، وبها تجد الحزمة غير المباشرة التي جلبت مكتبة لم تضفها أنت قط. لكنه لن يخبرك مباشرةً أي ناتج يحتوي على ملف .so بعينه، فاقرنه بفكّ ضغط ملف AAR المشتبه به. وهذه أساليب تشخيص عملية لا خطوات يفرضها جوجل.
افحص حزمة التطبيق لا ملف APK المحلي وحده
ملف APK لديك وملفات APK التي يولّدها جوجل بلاي من حزمتك نواتج مختلفة. فمحاذاة ELF تقع داخل كل مكتبة، ومحاذاة ZIP خاصية بطريقة رصّ الأرشيف، والحزمة تحمل إعدادًا يخبر Play أيهما يستخدم. وقد تتعارض الثلاثة، والأخير وحده هو ما يحدّد ما يثبّته المستخدمون.
هذه هي آلية أكثر صور المشكلة إحباطًا: يرقّي المطوّر كل شيء، ويفحص ملف APK المحلي، ويرى مخرجات نظيفة، ويرفع، ويبقى التحذير. لا شيء مما فحصه كان خاطئًا، لكنه ببساطة لم يفحص قط ما يقوّمه Play.
ما فحصته أنت
app-release.apk على جهازكبناه Gradle مباشرةً على عتادك بسلوك الحزم لديك. واجتيازه zipalign هنا يثبت أن هذا الملف مرصوص بطريقة صحيحة.
ما يقوّمه Play
ملفات APK المولَّدة من app-release.aabيبنيها جوجل من حزمتك بالمحاذاة التي تطلبها الحزمة. فإذا قالت الحزمة 4 KB، فهذه الملفات خاطئة مهما كان ملف APK المحلي نظيفًا.
لذلك شغّل هذا الأمر على الحزمة التي توشك على رفعها، في كل مرة:
bundletool dump config --bundle=app-release.aab | grep alignment
النتيجة المطلوبة هي PAGE_ALIGNMENT_16K. أما PAGE_ALIGNMENT_4K فتعني أن الحزمة تطلب من bundletool رصّ المكتبات الأصلية عند حدود 4 KB، وعندها يكون كل ملف APK يبنيه Play منها خاطئًا. ويحذّر جوجل تحديدًا من أن Android Gradle Plugin من 8.3 إلى 8.5 قد يُنتج هذا التفاوت بعينه: البناء المحلي يبدو محاذًى، والتطبيق الذي يبنيه Play من الحزمة لا يُثبَّت بشكل صحيح على جهاز 16 KB. والحل المفضّل هو الانتقال إلى Android Gradle Plugin 8.5.1 فأحدث.
كل أمر وفيه أسماء ملفاتك أنت
اكتب أسماء ملفاتك مرة واحدة. ستُعاد كتابة كل أمر أدناه، ويعرض كل تبويب الناتج الدقيق الذي يُعدّ نجاحًا، فلا تحتاج إلى تخمين ما إذا كانت النتيجة جيدة.
الأداة 07
مختبر الأوامر
لا تتوقّف عند «APK Analyzer يقول محاذًى»
اجتياز فحص ملف APK واحد من أربعة فحوص لا خطّ النهاية. تحقّق من محاذاة LOAD في ELF، ومن محاذاة ZIP في ملف APK، ومن إعداد الحزمة، ومن سلوك الناتج الذي يولّده Play فعلًا وقت التشغيل. وفشل واحد منها كافٍ لإبقاء التحذير على حسابك بعد بناء ظننته مُصلَحًا.
AGP وNDK وفخّ الحزم
إصداران يحملان معظم العبء. فـ NDK r28 فأحدث يجمّع الشيفرة الأصلية بمحاذاة 16 KB افتراضيًا، وAndroid Gradle Plugin 8.5.1 فأحدث يرصّ المكتبات الأصلية غير المضغوطة عند حدود ZIP بحجم 16 KB بشكل صحيح. ولا يستطيع أيٌّ منهما إصلاح ملف ثنائي مجمّع مسبقًا وصل داخل اعتمادية.
والمنطقة الرمادية الخطرة هي Android Gradle Plugin من 8.3 إلى 8.5. ففي هذا المدى قد يبدو البناء المحلي سليمًا تمامًا بينما لا يحاذي bundletool في ZIP ملفات APK التي ينتجها من حزمتك لأجل Play، وعبارة جوجل عن النتيجة صريحة: التطبيق المبني من تلك الحزمة لن يُثبَّت بشكل صحيح. فإن كنت على 8.5.0 وملف APK المحلي يجتاز كل فحص يخطر ببالك، فهذا أول ما ينبغي استبعاده.
الأداة 08
فاحص سلسلة الأدوات
مرجع إعدادات البناء
| الحالة | الإعداد | ملاحظات |
|---|---|---|
| NDK المفضّل | r28 فأحدث |
ينتج مخرجات أصلية محاذاة عند 16 KB افتراضيًا |
| AGP المفضّل | 8.5.1 فأحدث |
يتعامل مع المكتبات الأصلية غير المضغوطة عند حدود ZIP بحجم 16 KB |
| NDK r27 أو أقدم | -Wl,-z,max-page-size=16384 |
خيار رابط مطلوب في كل هدف أصلي |
| NDK r27 أو أقدم | -Wl,-z,common-page-size=16384 |
يُستخدم مع خيار حجم الصفحة الأقصى معًا |
ndk-build |
LOCAL_LDFLAGS += ... |
طبّق الخيارين على كل هدف أصلي |
| CMake | target_link_options(...) |
طبّق الخيارين على كل هدف معنيّ |
| تعذّر ترقية AGP | jniLibs.useLegacyPackaging = true |
يضغط المكتبات الأصلية، ويزيد المساحة المستهلكة بعد التثبيت |
| AGP 8.0 أو أقدم | android.bundle.enableUncompressedNativeLibs=false |
خاصية قديمة إضافية تُستعمل مع الخيار أعلاه |
| شيفرة وقت التشغيل | getpagesize() أو sysconf(_SC_PAGESIZE) |
تحلّ محلّ القيمة الثابتة 4096 وافتراض ثبات PAGE_SIZE |
الجزء الذي لا يصلحه الحزم
إن كانت شيفرة C أو C++ لديك تفترض حجم صفحة معيّنًا، فلا خيار بناء ينقذك. احذف القيم الثابتة 4096 وأي اعتماد على ثابت PAGE_SIZE، واقرأ القيمة الحقيقية وقت التشغيل بـ getpagesize() أو sysconf(_SC_PAGESIZE)، وراجع كل استدعاء لـ mmap() مع أي وسيط تحاذيه يدويًا. هذا هو صنف الأعطال الذي يُثبَّت فيه التطبيق بسلاسة على جهاز 16 KB، ويجتاز فحوص الحزمة، ثم ينهار عند أول تعامل مع تعيين الذاكرة.
ترتيب الخطوات
أصلح جانب المصرِّف قبل جانب الحزم. فإذا طبّقت حلّ الحزم القديم أولًا، سيبدأ ملف APK باجتياز zipalign بينما المكتبات بداخله ما زالت مبنية لصفحات 4 KB، وتكون قد أخفيت المشكلة الحقيقية خلف نتيجة خضراء.
اختبر على بيئة 16 KB حقيقية
أمر واحد يقرّر إن كان لاختبارك معنى: يجب أن يعيد adb shell getconf PAGE_SIZE القيمة 16384. شغّله قبل كل جلسة. فمحاكٍ أقلع بهدوء في وضع 4 KB سيمرّر لك بناءً معطوبًا مهما ألقيت عليه.
أمامك ثلاثة طرق عملية واثنان متخصّصان. اختر ما تستطيع الوصول إليه اليوم فعلًا؛ فلا فرق في الجودة بينها لغرض التقاط أعطال حجم الصفحة.
الأداة 09
اختيار بيئة الاختبار
الحد
ثم، في كل مرة وقبل أي اختبار
adb shell getconf PAGE_SIZE
لا تتابع ما لم يكن الناتج 16384.
ما الذي تجرّبه فعلًا
بعد التأكّد من البيئة، لا تكون الجولة المفيدة هي «هل يفتح التطبيق». فالأعطال الأصلية تتجمّع في الميزات التي تمسّ الشيفرة الأصلية، فجرّبها عن قصد: الإقلاع البارد، والتنقّل داخل التطبيق، والكاميرا، والقراءة والكتابة في قاعدة البيانات، وتشغيل الوسائط وتسجيلها، والمصادقة، والعمل في الخلفية، وأي ميزة تعلّم آلي أو واقع معزّز، وكل واجهة تعتمد على إضافة أصلية، وأي جزء من شيفرتك يستخدم تعيين الذاكرة. وإذا كانت ميزة ما تعمل بإحدى المكتبات التي رقّيتها للتوّ، فتلك الميزة هي الاختبار.
وضع التوافق ليس نجاحًا
يستطيع أندرويد تشغيل بعض التطبيقات المحاذاة عند 4 KB على جهاز 16 KB عبر مسار توافق، وقد ترى تحذيرًا عند أول تشغيل حين يحدث ذلك. ومع ذلك يوصي جوجل بالمحاذاة الصحيحة عند 16 KB لأفضل موثوقية واستقرار. فالتطبيق الذي يعمل فقط لأن وضع التوافق تدخّل ليس تطبيقًا مُصلَحًا، والنشر على هذا الأساس يعني أن العطل الحقيقي ما زال أمامك.
لماذا يبقى التحذير بعد التحديث
كل حالة «لكنني أصلحت هذا فعلًا» تقريبًا هي واحدة من ثلاث عشرة حالة محدّدة، وإحدى عشرة منها يمكن إثباتها من الناتج الذي أمامك. اختر العرَض المطابق وستعرف السبب عادةً قبل أن تُنهي القراءة.
الأداة 10
تشخيص التحذير الباقي
حالتان من هذه تستحقّان تحفّظًا لا إجابة واثقة. فلا مصدر أوّلي يحدّد كم يستغرق جوجل بلاي لإعادة تقويم حزمة مرفوعة، ولذلك إن بقي تحذيرك مباشرةً بعد الرفع فالتصرّف الأمين هو التأكّد من ظهور رقم الإصدار الجديد في أحدث إصداراتك وحزم التطبيق ثم المراجعة لاحقًا، بدل الوثوق برقم بعينه قرأته عن أزمنة المعالجة. والتطبيق الذي يعمل فقط لأن وضع التوافق تدخّل لم يُصلَح بل جرى التغاضي عنه.
مكتبات خارجية يتكرّر ذكرها
هذه أمثلة جرى الإبلاغ عنها، لا ترتيب لمدى شيوع كل منها، ولا وعد بأن نسخة بعينها ستصلح بناءك. فأي حزمة قد تضيف نواتج أصلية أو تزيلها أو تستبدلها في أي إصدار. والمرجع النهائي دائمًا هو الملف الثنائي الموجود داخل حزمة إصدارك أنت.
استعمل القائمة نقطة بداية حين يبدو اسم ملف مألوفًا، ثم تحقّق من الإصدارات الحالية والمشكلات المفتوحة لذلك المشروع. وحيثما كان الدليل تتبّع مشكلات لدى مشرف لا ملاحظة إصدار، تقول البطاقة ذلك.
الأداة 11
قائمة المكتبات المُبلَّغ عنها
libobjectbox-jni.so
فشلت مكتبات أندرويد الأصلية القديمة في بيئة 16 KB. ولم تتأكّد نسخة مُصلَحة بعينها بما يكفي لنشرها هنا. راجع ملاحظات الإصدار الحالية لـ ObjectBox لمعرفة النسخة التي أضافت دعم 16 KB، ثم تحقّق من الملف الثنائي داخل ملف APK الذي بنيته بدل الاكتفاء برقم النسخة.
مكتبة أندرويد المضمّنة
تحزم حزمة Dart من ObjectBox مكتبة أندرويد خاصة بها. ولم تتأكّد نسخة مُصلَحة بعينها بما يكفي لنشرها هنا. راجع ملاحظات الإصدار الحالية لـ ObjectBox، ثم تحقّق من الناتج الذي يحلّه بناؤك فعليًا.
libsqlite3.so
ظهرت اعتمادية قديمة بالنسخة 3.43.0 في حزم Flutter وAWS Amplify المتأثّرة. وتشير أدلة المشكلات إلى النسخة 3.46.1+1 بوصفها التي أضافت دعم 16 KiB. تحقّق من نسخة الاعتمادية المحلولة لا من التي أعلنتها أنت، فقد تثبّت حزمة إطار عمل نسخة أقدم.
sqlcipher-android
حزمة android-database-sqlcipher القديمة موقوفة في المنبع لصالح حزمة sqlcipher-android المدعومة. ولم تتأكّد نسخة بعينها بما يكفي لنشرها كحدّ أدنى مُصلَح، فانتقل إلى الحزمة المدعومة حاليًا وتحقّق من كل بنية ABI في التطبيق المبني بدل الاعتماد على رقم نسخة.
ملفات معالجة الوسائط
أُوقف مستودع FFmpegKit الأصلي، ولم يثبت وجود إصدار متوافق آمن للجميع. وتتفاوت جودة النسخ المتفرّعة. حدِّد بدقّة أي نسخة متفرّعة يحلّها بناؤك، وافحص نواتجها لكل بنية ABI مباشرةً، ووازن بين حالة الصيانة والمصدر قبل اعتماد إحداها حلًّا.
ملفات Realm وJNI
البلاغات متضاربة. أُشير إلى النسخة 20.1.0، ثم قال بلاغ لاحق إن النسخة 20.2.0 أصلحت أحد ملفات Realm بينما بقي ملف JNI آخر مشكلًا. ولا يمكن تسمية نسخة آمنة واحدة بمسؤولية، فرقِّ ثم افحص كل مكتبة يسهم بها Realm على حدة.
libmediapipe_tasks_vision_jni.so
جرى الإبلاغ عنه بمحاذاة 2**12. ولم يثبت إصدار مُصلِح في المشكلة التي رُوجعت، فتعامل مع التوافق باعتباره خاصًّا بالنسخة: راجع ملاحظات الإصدار الحالية، ورقِّ، وتحقّق من الملف الثنائي في بنائك أنت.
ناتج OpenCV لأندرويد
جرى الإبلاغ عن مشكلة محاذاة في ناتج OpenCV 5.0.0 لأندرويد. وتشير مشكلة المستودع إلى إصلاح في التكامل المستمر، لكن لم يثبت ناتج مُصدَر بعينه على نحو آمن. نزّل ملف AAR الذي تعتمد عليه بالضبط، وفكّ ضغطه، وافحص المكتبات بنفسك.
lib_burst_generated.so
إرشاد Unity نفسه هو تحديث حزمة Burst إلى 1.8.21 فأحدث عند الإشارة إلى هذا الملف. وهو المدخل الوحيد في القائمة الذي تسنده وثائق رسمية من المورّد لا بلاغات مشكلات.
libUnityARCore.so وlibquack.so وغيرهما
تذكر بلاغات المجتمع هذه الملفات ضمن ما يبقى بعد ترقية المحرّر. ولا توجد نسخة عامّة يمكن ذكرها لأن كل ملف يتبع حزمة مختلفة. استعمل اسم الملف الدقيق لتقرّر أي حزمة تتبع أثرها.
لا يوجد مدخل يطابق هذه التصفية. وهذا طبيعي: تغطّي القائمة أمثلة مُبلَّغًا عنها لا كل مكتبة في المنظومة. استعمل البحث عن مالك المكتبة وتتبّع الملف داخل مشروعك أنت.
لماذا هذه القائمة قصيرة: عدد المشكلات يُظهر المشاريع التي لها مستخدمون كثيرو الحديث، لا المكتبات الأكثر تثبيتًا. ونشر ترتيب لـ «أكثر المتسبّبين شيوعًا» يعني اختلاق إحصاءة. أما ما يصلح للتعميم فهو الطريقة نفسها: خذ اسم الملف، وابحث عن الحزمة، وراجع إصداراتها الحالية، وتحقّق من الملف الثنائي في بنائك.
علاقة ذلك بموعد API 36 في 31 أغسطس 2026
هذان شرطان مستقلان من جوجل بلاي يلتقيان عند نقطة واحدة فقط. رفع مستوى API المستهدف قد يُظهر تحذير 16 KB، لأن الشرط ينطبق على التطبيقات التي تستهدف Android 15 (مستوى API 35) أو أعلى. وهو لا يُنشئ اختلال المحاذاة ولا يستطيع إصلاحه.
يشترط جوجل بلاي أن تستهدف التطبيقات الجديدة وتحديثاتها Android 16 (مستوى API 36) اعتبارًا من 31 أغسطس 2026، مع إمكانية طلب تمديد حتى 1 نوفمبر 2026. هذا تغيير في ملف البيان وفي السلوك. أما قاعدة 16 KB فهي تغيير في التوافق الثنائي. من يرفع targetSdk يوم الاثنين ويرى تحذير 16 KB يوم الثلاثاء لم يُعطِب شيئًا: المكتبات الأصلية كانت مبنية أصلًا لصفحات 4 KB، ومستوى الاستهداف الأعلى أدخل التطبيق فحسب في نطاق فحص كان سينطبق على أي حال.
الشرط أ
استهداف API 36- الموعد 31 أغسطس 2026، وتمديد حتى 1 نوفمبر 2026
- النطاق التطبيقات الجديدة والتحديثات
- مكانه ملف البيان وإعدادات البناء
- طريقة الحل رفع مستوى الاستهداف ومعالجة تغييرات سلوك Android 16
الشرط ب
دعم صفحات 16 KB- الموعد 1 فبراير 2027
- النطاق التطبيقات التي تستهدف API 35+ على أجهزة 64 بت
- مكانه الملفات الثنائية الأصلية داخل حزمتك
- طريقة الحل إعادة بناء كل مكتبة غير محاذاة أو استبدالها
عمليًا، تعامل مع الأمرين بوصفهما انتقالًا واحدًا بدليلين. أنت سترفع مستوى الاستهداف على أي حال، فاجعل تدقيق المكتبات الأصلية ضمن الإصدار نفسه بدل اكتشافه وسط زحمة API 36. وللاطلاع على كامل المستويات بحسب شكل الجهاز والاستثناءات وآلية التمديد، راجع مقالنا عن موعد API 36 في جوجل بلاي، وللتسلسل الكامل من الحساب حتى الإصدار العلني راجع مقالنا عن شروط النشر 2026.
بوابة ما قبل الرفع
إحدى عشرة نقطة فحص، لكلٍّ منها دليل اجتياز محدّد. أنجزها قبل الرفع لا بعد أن يخبرك Play بوجود خلل، فتحوّل جلسة تنقيح بلا نهاية إلى قائمة محدودة.
الأداة 12
بوابة الإصدار
أُنجز 0 من 11
لم يثبت شيء بعد. ابدأ بالبناء الذي تنوي رفعه فعلًا، لا بآخر بناء صادف أن كان مفتوحًا لديك.
يُحفظ تقدّمك في هذا المتصفح وحده. لا يُرسل إلى أي جهة، ويزول بمسح بيانات المتصفح.
إنجاز النقاط الإحدى عشرة كلها يثبت المحاذاة التقنية وفق الفحوص المذكورة في هذه الصفحة. وهو ليس وعدًا بالقبول. فقد يثير جوجل بلاي مسائل سياسة أو محتوى أو جودة لا علاقة لها بالموضوع على الرفع نفسه، ولا تستطيع أي قائمة تحقّق أن تتحدّث نيابةً عن تلك المسائل.
أين تصطدم هذه المشكلة بالاختبار المغلق
لا شيء في هذه الصفحة يغيّر شرط المختبِرين لديك، ولا شيء في شأن المختبِرين يغيّر بناءك. المشكلتان تصطدمان على محور واحد فقط: الوقت. الاختبار المغلق لمدة 14 يومًا يجري على ساعة لا يمكنك إيقافها، والتحقيق في مكتبة أصلية يجري على ساعة لا يستطيع أحد التنبؤ بها.
التسلسل المؤلم يسير هكذا: حساب مطوّر شخصي يبدأ اختبارًا مغلقًا، فتنطلق نافذة الأربعة عشر يومًا المتواصلة للموافقة على المشاركة، وفي منتصفها يكشف رفعُ مستوى الاستهداف تحذيرَ 16 KB. الآن يعيد المطوّر بناء اعتماديات أصلية بينما يجب أن تبقى مجموعة المختبِرين سليمة حوله. رفع إصدار جديد إلى المسار أمر لا مشكلة فيه، وجوجل نفسه يشجّع على مواصلة التحديث أثناء الاختبار. ما يُفسد المسار هو أن يهدأ جانب المختبِرين.
هذا تحديدًا ما تُبقيه PrimeTestLab ثابتًا. نوفّر 12 مختبِرًا حقيقيًا على أجهزة حقيقية تمتد من Android 7 إلى 17، موافقين على المشاركة ومحافظين عليها طوال الأيام الأربعة عشر، فتجري إعادة بنائك في مواجهة اختبار مستقر لا اختبار ينهار. يبدأ الاختبار خلال 4-6 ساعات، وقد أجرينا ذلك على 7,400+ تطبيق في 120+ دولة بنسبة نجاح 99.9%.
أن تجمع المختبِرين بنفسك مقابل تشغيل مُدار
| شرط جوجل | أن تجمعهم بنفسك | تشغيل مُدار |
|---|---|---|
| 12 مختبِرًا على الأقل وافقوا على المشاركة | تبحث عن أشخاص حقيقيين وتشرح لهم وتلاحقهم، ثم تأمل ألّا ينسحب أحد | 12 مختبِرًا نوفّرهم ونحافظ عليهم طوال المدة |
| 14 يومًا متواصلة | انسحاب مختبِر واحد في المنتصف يكسر تواصل المدة | نتابع المجموعة حتى تبقى المدة متصلة |
| أجهزة حقيقية وأشخاص حقيقيون | المحاكيات والحسابات الخاملة هي الاختصار المعتاد، وهي السبب المعتاد للفشل | أجهزة حقيقية من Android 7 إلى 17 |
| الوقت حتى أول موافقة | أيام، بحسب من يردّ عليك | يبدأ الاختبار خلال 4-6 ساعات |
| التكلفة | وقتك أنت، في الأسبوع نفسه الذي تعيد فيه بناء المكتبات | ابتداءً من $19.99 مع 5% رسوم خدمة إضافية |
| إعادة البناء أثناء الاختبار | كل رفع جديد يعني جولة أخرى من مطالبة الناس بالتحديث | ارفع إصدارات جديدة بحرّية، وتبقى المجموعة على موافقتها |
ولنكن صريحين بشأن الحدود: نحن لا نعيد بناء مكتباتك الأصلية، وهذا المقال ليس عرضًا تسويقيًا لذلك. عمل 16 KB عملك أنت، وكل ما فوق هذا القسم مكتوب ليجعله أقصر ما يمكن. ما نرفعه عن كاهلك هو شرط المختبِرين الجاري بالتوازي، حتى تتوقف المشكلتان عن التنازع على الأسبوعين نفسيهما.
نصيحة في الترتيب
إن لم تكن قد بدأت الاختبار المغلق بعد وتعلم أن لديك مكتبات أصلية، شغّل نافذة المختبِرين أولًا وأنجز عمل المحاذاة داخلها. فترة التأهيل عند جوجل تُقاس باستمرار موافقة المختبِرين على المشاركة لا بإصدار واحد مجمّد، وجوجل يشجّع على مواصلة التحديث أثناء الاختبار، ولذلك يمكن للجدولين أن يتداخلا بدل أن يتراكما. وأبقِ المسار ومجموعة المختبِرين كما هما أثناء ذلك. هذا وحده يوفّر أسبوعًا كاملًا في الغالب.
الأسئلة الشائعة
هل يرفض جوجل بلاي الآن التطبيقات غير المتوافقة مع 16 KB؟
تقول وثائق جوجل الحالية إنه اعتبارًا من 1 فبراير 2027 لن تتمكّن من إصدار تحديثات تستهدف Android 15 (مستوى API 35) أو أعلى من دون دعم 16 KB على أجهزة 64 بت. وقبل ذلك التاريخ يرى معظم المطوّرين تحذير توافق في Play Console لا حظرًا كاملًا. والنتيجة الموثّقة في صفحة جوجل المذكورة هي عدم القدرة على إصدار تحديثات غير متوافقة، لا الإزالة التلقائية لتطبيق منشور بالفعل.
لماذا يقول جوجل 1 فبراير 2027 بينما تقول مقالات أخرى 1 نوفمبر 2025؟
كان 1 نوفمبر 2025 هو الموعد الذي أعلنه جوجل أصلًا، وكان 31 مايو 2026 تاريخ تمديد لاحق صار تاريخيًا. وفي 5 أغسطس 2026 كانت صفحة Android Developers الحالية ولقطة تحذير Play Console الحالية تعرضان معًا 1 فبراير 2027، فالمصدر الأوّلي الأحدث هو المرجع. وما زالت مقالات كثيرة وإجابات ذكاء اصطناعي تنقل التواريخ القديمة لأنها كُتبت قبل التغيير.
لم أكتب C++ يومًا. لماذا يتأثّر تطبيقي؟
قد يضيف إطار عمل أو حزمة SDK أو إضافة أو محرّك ألعاب أو قاعدة بيانات أو مكوّن وسائط أو أداة بناء تطبيقات ملفات .so أصلية حتى لو كانت شيفرتك أنت بلغة Dart أو JavaScript أو Python أو Java أو Kotlin. وإرشادات جوجل تشمل صراحةً التطبيقات التي تستخدم مكتبات NDK بطريقة غير مباشرة عبر اعتمادية. افتح ملف APK في Android Studio عبر Build ثم Analyze APK؛ ووجود أي ملف .so تحت lib يعني أن التطبيق المحزوم يستخدم شيفرة أصلية.
هل يحتاج تطبيق مكتوب بلغة Kotlin وحدها إلى أي تغيير؟
بحسب جوجل، التطبيق الذي يستخدم Java أو Kotlin فقط، بما في ذلك كل مكتباته وحِزَم SDK فيه، يدعم أجهزة 16 KB أصلًا. ومع ذلك يوصي جوجل بإجراء اختبار في بيئة 16 KB لالتقاط أي تراجع غير متوقّع. وتحقّق من أن ملف APK الفعلي للإصدار لا يحتوي على مجلد lib قبل أن تصف تطبيقك بأنه Kotlin خالص، فاعتمادية واحدة للتحليلات أو لقواعد البيانات كافية لإضافته.
أي إصدار من Flutter يحلّ تحذير حجم صفحة 16 KB؟
لا يوجد مصدر رسمي يحدّد إصدارًا واحدًا من Flutter يضمن توافق كل تطبيق وكل إضافة. وملاحظات إصدار Flutter 3.27 أضيق مما تبدو، فهي تغطي دعم 16 KB لقوالب plugin_ffi تحديدًا لا المحرّك كلّه. وأقوى محطة موثّقة هي Flutter 3.38، إذ قدّم Flutter الترقية إليها صراحةً بوصفها تهيئة لشرط 16 KB في Play وحوّل NDK الافتراضي إلى r28. وأسلم تصرّف هو الانتقال إلى إصدار Flutter المستقر الحالي، وتحديث كل إضافة أصلية، وإعادة بناء حزمة الإصدار، وفحص كل ملف .so يخرج منها.
أي إصدار من React Native يدعم صفحات 16 KB؟
إصدار React Native 0.77 هو المرجع الرسمي الواضح. ويذكر إعلان إصداره أن React Native جاهز لدعم أحجام صفحات الذاكرة 16 KB دعمًا كاملًا. ومع ذلك قد تظلّ وحدات المجتمع الأصلية وشيفرة C++ المحلية وحِزَم SDK من أطراف أخرى تحمل ملفات ثنائية غير متوافقة، فرقِّ عبر مسار الترقية المدعوم في React Native أو Expo ثم افحص ملف APK الناتج.
أي إصدار من Unity أحتاج لدعم صفحات 16 KB؟
تذكر Unity الإصدارات 6000.1 فأحدث، و6000.0.38f1 فأحدث، و2022.3.56f1 فأحدث، و2021.3.48f1 فأحدث ضمن الدعم الممتد للعملاء المؤهّلين من فئتي Enterprise وIndustry. وحدِّث إضافاتك الأصلية أيضًا، وارفع Burst إلى 1.8.21 فأحدث إذا ذكر Play Console الملف lib_burst_generated.so. فإصدار المحرّر المدعوم شرط لازم لكنه غير كافٍ، لأن إضافات الأطراف الأخرى تحمل ملفاتها الثنائية.
كيف أحدّد ملف .so المسبِّب بالضبط؟
افتح ملف APK عبر Build ثم Analyze APK في Android Studio، ووسّع lib/arm64-v8a وlib/x86_64، واقرأ عمود Alignment الذي يعرض تحذيرات للملفات ذات مشكلات المحاذاة. وللتأكيد من سطر الأوامر شغّل سكربت check_elf_alignment.sh من جوجل على ملف APK، أو افحص مكتبة واحدة بأمر llvm-objdump -p file.so مع تمريره إلى grep LOAD. وأي محاذاة LOAD أقل من 2**14 تحتاج معالجة.
لماذا يجتاز ملف APK الفحص بينما تفشل حزمة التطبيق؟
محاذاة ELF داخل المكتبة ومحاذاة ZIP داخل الناتج المحزوم فحصان منفصلان. شغّل bundletool dump config --bundle=app.aab ومرِّره إلى grep alignment: قيمة PAGE_ALIGNMENT_16K تعني النجاح، أما PAGE_ALIGNMENT_4K فتعني أن ملفات APK المولَّدة ما زالت تُطلب بمحاذاة 4 KB. ويحذّر جوجل تحديدًا من أن Android Gradle Plugin من 8.3 إلى 8.5 قد يبدو سليمًا محليًا بينما ملفات APK التي يبنيها Play من حزمتك غير محاذاة في ZIP كما ينبغي، فانتقل إلى 8.5.1 فأحدث.
هل تكفي الترقية إلى NDK r28 لحلّ المشكلة؟
لا. يجمّع NDK r28 فأحدث بمحاذاة 16 KB افتراضيًا، لكن ذلك يشمل الشيفرة الأصلية التي تُجمَّع أثناء بنائك أنت فقط. ولا يستطيع إعادة كتابة ملف .so مجمّع مسبقًا يصل داخل حزمة AAR أو إضافة أو حزمة محرّك ألعاب من طرف آخر. فكل اعتمادية أصلية مبنية مسبقًا يجب تحديثها أو استبدالها أو إعادة بنائها واستيرادها من جديد.
كيف أختبر دعم 16 KB من دون امتلاك هاتف مدعوم؟
ثبّت إحدى صور نظام محاكي أندرويد بحجم صفحة 16 KB من جوجل عبر SDK Manager، أو احجز جهازًا مدعومًا عبر Samsung Remote Test Lab. ومهما استخدمت، تحقّق من البيئة أولًا بأمر adb shell getconf PAGE_SIZE؛ ويجب أن يكون الناتج 16384 قبل أن يكون للاختبار أي معنى. ونجاح المحاكي يثبت السلوك أثناء التشغيل لا طريقة الحزم، فواصل فحص حزمة الإصدار أيضًا.
هل يعيد إصلاح دعم 16 KB اختباري المغلق من البداية أو يؤثّر فيه؟
يقيس جوجل فترة التأهيل ببقاء 12 مختبِرًا على الأقل موافقين على المشاركة 14 يومًا متواصلة، لا بإصدار واحد مجمّد، ويشجّع على مواصلة تحديث الإصدار أثناء الاختبار. ولا ينشر جوجل ضمانًا صريحًا يغطّي كل سيناريوهات استبدال الإصدار، فأسلم نهج هو إبقاء مجموعة المختبِرين مستقرة بينما ترفع في منتصف الاختبار حزمة أُعيد بناؤها ومتوافقة مع 16 KB. وتوفّر PrimeTestLab 12 مختبِرًا حقيقيًا على أجهزة حقيقية ابتداءً من $19.99 مع 5% رسوم خدمة إضافية، وتحافظ على المجموعة طوال الأيام الأربعة عشر.
الخلاصة
الخلاصة
يشترط جوجل بلاي على التطبيقات التي تستهدف Android 15 (مستوى API 35) أو أعلى دعم أحجام صفحات الذاكرة 16 KB على أجهزة 64 بت، ومن 1 فبراير 2027 لن يمكن إصدار التحديثات غير المتوافقة. أما 1 نوفمبر 2025 و31 مايو 2026 فتاريخان ميتان ما زالا يتصدّران نتائج البحث. التطبيقات المكتوبة بلغة Java أو Kotlin وحدها متوافقة أصلًا. وما عداها يسلك الخطوات الثلاث نفسها: حدِّد ملف .so المسبِّب، وحدِّث الحزمة التي تملكه، وأثبت سلامة الناتج بفحصين مستقلّين، أي أن يكون كل مقطع LOAD في ELF عند 2**14 أو أكثر، وأن تُبلّغ الحزمة عن PAGE_ALIGNMENT_16K. وAGP 8.5.1+ مع NDK r28+ هي سلسلة الأدوات الافتراضية الأكثر أمانًا، ولا يستطيع أيٌّ منهما إصلاح ملف ثنائي جمّعه شخص آخر. وإذا وقع هذا في منتصف اختبار مغلق، فجانب المختبِرين هو الجزء الذي يمكنك تسليمه لنا. اطّلع على الخطط ←
المصادر الأولية
ما الذي سيتقادم أولًا في هذه الصفحة
- تاريخ 1 فبراير 2027. حرّك جوجل هذا الجدول أكثر من مرة. قبل أن تبني خطة إصدار حوله، تحقّق من ختم "Last updated" أسفل دليل أحجام الصفحات.
- نصوص Play Console. تتغيّر نصوص الواجهة ومسارات التنقّل بمعزل عن صفحات السياسة، وقد تختلف العناوين التي تراها عمّا أُعيد إنتاجه هنا.
- إصدارات أطر العمل المرجعية. يصدر Flutter نسخًا مستقرة بوتيرة عالية، وتتغيّر سياسة دعم React Native، وتتبدّل أهلية Unity LTS. تحقّق من ملاحظات الإصدار الحالية لا من رقم مطبوع في مقال.
- قائمة المكتبات المُبلَّغ عنها. أي حزمة قد تضيف ملفًا ثنائيًا أصليًا أو تستبدله أو تتراجع عنه في أي إصدار. تحقّق دائمًا من الناتج داخل حزمتك أنت.
- أسماء صور المحاكي. الصور الموسومة بأنها تجريبية قد يُعاد تسميتها أو تُرقّى، وقد لا يطابق النص الظاهر في SDK Manager ما هو مذكور هنا.
جرى التحقّق من وثائق جوجل في 9 أغسطس 2026. تُراجَع الصفحة شهريًا حتى شهر واحد على الأقل بعد بدء التنفيذ.