أين اختفى system.img؟ شرح Dynamic Partitions و Super Partition في أندرويد

جدول المحتويات

ما تحتاجه لفهم هذا المقال

• خبرة عملية بتفليش رومات عبر fastboot
• معرفة بهيكل الأقسام: system ، vendor ، boot
• إلمام عام بمفهوم OTA Updates
• جهاز أو روم حديث (Android 10+)

1

شكل النظام القديم: Static Partitions

تقسيم الذاكرة كان ثابتاً. كل قسم يحجز حجمه مسبقاً:

boot system vendor recovery userdata

كنت تفتح روم وتلاقي ملفات واضحة: system.img ، vendor.img ، boot.img — تفليش مباشر، نتيجة مباشرة.

مشاكل النظام القديم

• لو system كبر → لازم إعادة تقسيم كامل
• مساحات بتضيع بدون استخدام
• تحديثات OTA معقدة
• مرونة شبه صفر

2

لماذا ظهرت Dynamic Partitions

Google غيّرت الفكرة لأن الأجهزة الحديثة بقت تحتاج مرونة أعلى:

• استغلال أفضل لمساحة الذاكرة
• تحديثات OTA أسهل وأكثر أماناً
• تغيير حجم system/vendor بدون repartition كامل

3

ما هو Super Partition

"حاوية كبيرة" واحدة اسمها super، وبداخلها كل الأقسام المنطقية:

super ├── system ├── vendor ├── product ├── odm └── system_ext

ℹ️

الأقسام داخل super ليست partitions حقيقية — هي Logical Partitions تظهر للنظام كأنها منفصلة لكنها تعيش داخل حاوية واحدة.

الفرق الحقيقي: Physical مقابل Logical

Physical (حقيقية)

• boot
• super
• userdata
• vbmeta

موجودة فعلياً على الفلاش — تتعامل معها من fastboot مباشرة

Logical (منطقية)

• system
• vendor
• product
• odm

تعيش داخل super — مش ليها مكان مستقل على الفلاش

4

أين اختفى system.img بالضبط

System ما اختفاش… لكنه اتغير مكانه. عندك 3 سيناريوهات:

4.1

system داخل super.img

مش هتلاقي system.img منفصل — القسم مضغوط داخل super.img.

4.2

system داخل payload.bin

ملف OTA يحتوي كل الأقسام مضغوطة. لازم تستخرجها بأدوات مخصصة.

4.3

system.img موجود لكن للـ fastboot فقط

بعض الشركات لسه بتصدره منفصل، لكن ده استثناء مش قاعدة.

⚠️

وجود payload.bin مش معناه تلقائياً أن الجهاز Dynamic Partitions — هو مجرد طريقة OTA packaging.

5

العلاقة مع نظام A/B Slots

معظم الأجهزة الحديثة بتستخدم A/B Slots مع Dynamic Partitions:

Slot A ├── system_a └── boot_a Slot B ├── system_b └── boot_b

• تحديث بدون ما توقف الجهاز (Seamless Update)
• Rollback تلقائي لو التحديث فشل
• الجهاز بيشتغل من slot والتحديث بيتم على التاني

6

لماذا اختفى recovery.img

الريكفري بقى جزء من boot image — مفهوم Recovery-as-Boot:

• مفيش recovery.img منفصل
• الريكفري مدمج داخل boot.img
• عند الدخول للريكفري، النظام بيستدعي boot في وضع مختلف

أدوات الفني الجديدة

الشغل الحديث بقى مختلف. الأدوات القديمة مش كافية:

payload-dumper-go استخراج الأقسام من payload.bin

payload_dumper.py بديل Python لاستخراج payload

lpunpack فك super.img لأقسام منفصلة

imjtool تحليل وفك صور super

lpmake إعادة بناء super.img

fastbootd وضع fastboot للأقسام المنطقية

Pro Tip

للتفليش المباشر لـ super على أجهزة Dynamic Partitions، لازم تدخل وضع fastbootd. شغّل fastboot reboot fastboot للانتقال إليه.

أوامر Fastboot مهمة للفني

أول شيء تشغّله قبل أي تفليش لمعرفة بنية الجهاز:

Terminal # التحقق هل system قسم منطقي fastboot getvar is-logical:system # عرض كل متغيرات الجهاز fastboot getvar all # معرفة السلوت النشط fastboot getvar current-slot # الانتقال لوضع fastbootd fastboot reboot fastboot

ℹ️

لو نتيجة is-logical:system هي yes — فأنت تتعامل مع Dynamic Partitions ولازم تستخدم fastbootd.

📱 سيناريو عملي من الورشة

جهاز جالك Bootloop بعد تفليش روم

التشخيص:

• system متوافق لكن vendor مختلف
• vbmeta مكسور أو غير مطابق
• super فيها mismatch

خطوات الحل:

1. استخراج الأقسام من payload.bin بـ payload-dumper-go
2. إعادة تفليش system + vendor متوافقين من نفس الروم
3. إعادة بناء super.img بـ lpmake (لو تم التعديل)
4. تفليش vbmeta الصحيح مع تعطيل التحقق

Terminal — الحل # تفليش vbmeta مع تعطيل التحقق fastboot flash vbmeta --disable-verity --disable-verification vbmeta.img # دخول fastbootd ثم تفليش super fastboot reboot fastboot fastboot flash super super.img

حلول المشاكل الشائعة

المشكلة	السبب	الحل
Bootloop بعد تفليش super	mismatch بين الأقسام	أعد بناء super.img من أقسام متوافقة
فشل إقلاع بسبب vbmeta	vbmeta غير مطابق	fastboot flash vbmeta --disable-verification
تلف super partition	قطع الكهرباء أو ملف تالف	إعادة تفليش super كامل عبر fastbootd
OTA update fail	اختلاف A/B slots	تأكد من تطابق Slot النشط
فشل تفليش system لوحده	قسم منطقي لا يقبل تفليش منفصل	فك super ← تعديل ← lpmake ← تفليش الكل
fastboot flash system لا يعمل	يحتاج fastbootd	fastboot reboot fastboot ثم أعد المحاولة

تحذيرات حرجة

⚠️

تفليش super من روم إصدار مختلف = احتمال Hard Brick

⚠️

أي mismatch بين system و vendor = Bootloop مباشر

🚫

لا تفليش system لوحده في أجهزة Dynamic Partitions — لازم تفلش super كامل أو تستخدم fastbootd

💾

لازم Backup كامل قبل أي تعديل على super أو partitions

🔄

احتفظ بالروم الأصلية دائماً قبل أي تعديل — ارجع لها وقت الأزمات

الخلاصة العملية

اختفاء system.img مش مجرد تغيير ملفات — ده تغيير كامل في فلسفة إدارة النظام.

الفني اللي فاهم النظام القديم بس، هيواجه مشاكل حقيقية. لكن اللي فاهم:

• Dynamic Partitions وكيف تعمل
• Super Partition وبنيتها
• payload.bin وكيفية استخراج محتوياته
• A/B Slots وتأثيرها على التفليش

هو اللي يقدر يتعامل مع الجيل الجديد بدون خوف.

القاعدة الذهبية للفني

مش مهم تعرف system فين… المهم تعرف هتوصله إزاي لما الجهاز يقع.

روابط تحميل الأدوات

📦 payload-dumper-go — مستودع GitHub ← 💿 payload-dumper-go — نسخ جاهزة (Releases) ← 📄 توثيق Google — Dynamic Partitions ← 🔧 liblp — مكتبة Logical Partitions ←

نصيحة ختامية: قبل ما تتعامل مع أي جهاز حديث، شغّل fastboot getvar all واحفظ المخرجات في ملف نصي. ده مرجعك الأول لمعرفة هل الجهاز يستخدم Dynamic Partitions أو لا — وده بيوفر عليك نصف وقت التشخيص.