AVD Android: ما هو، Android Virtual Device وكيفية إعداد المحاكي

ما هو AVD

AVD (Android Virtual Device) هو تكوين برمجي يصف جهاز Android افتراضياً. على عكس الهاتف الفعلي، لا يتطلب AVD أجهزة مادية — فهو يعمل على الكمبيوتر عبر محاكي Android المبني على QEMU. ينشئ المطور عدداً من AVD حسب الحاجة للاختبار: لإصدارات Android المختلفة، أحجام الشاشات، سعات الذاكرة وكثافات البكسل.

كل AVD مرتبط بـ SDK Platform محددة. هذا يعني أنه لإنشاء AVD مع Android 14 (API Level 34)، يجب أولاً تثبيت System Image لهذا الإصدار عبر SDK Manager. System Image هي صورة نظام تشغيل تتضمن جميع تطبيقات النظام وخدمات Google (إذا تم تحديد صورة Google APIs) ومكونات وقت التشغيل. توصي Google باستخدام صور Google APIs مع خدمات Google Play لتحقيق أقصى توافق مع الأجهزة الحقيقية.

AVD لا غنى عنه في التطوير لعدة أسباب. أولاً، يسمح باختبار التطبيق على إصدارات Android المختلفة دون شراء عشرات الأجهزة. ثانياً، يدعم AVD اللقطات (Snapshots) — حفظ حالة النظام مما يسرع بدء التشغيل. ثالثاً، المحاكي متكامل مع Android Studio: تثبيت APK وتصحيح الأخطاء والتسجيل تعمل تماماً كما على الجهاز الفعلي.

أنواع الأجهزة الافتراضية

يدعم AVD أنواعاً مختلفة من الأجهزة: الهواتف، الأجهزة اللوحية، ساعات Wear OS، Android TV وAndroid Automotive. لكل نوع، يوفر AVD Manager ملفات تعريف جاهزة من Google: Pixel 8، Pixel 9 Pro، Nexus 7، Samsung Galaxy Tab وغيرها. يحدد ملف تعريف الجهاز حجم الشاشة والدقة وكثافة البكسل (dpi) والتنقل (الإيماءات أو الأزرار).

مما يتكون AVD

كل AVD عبارة عن مجموعة من ملفات التكوين والصور. ملف التكوين الرئيسي هو config.ini، الذي يخزن معلمات الجهاز الافتراضي: الاسم، النوع، مستوى API، حجم الشاشة، حجم RAM و VM heap. يوجد الملف في المسار $HOME/.android/avd/اسمAVD.avd/ ويمكن تعديله يدوياً، على الرغم من أنه يُعدَّل عادةً عبر AVD Manager.

بالإضافة إلى config.ini، يخزن دليل AVD: userdata.img (صورة بيانات المستخدم — التطبيقات، الإعدادات، الملفات)، system.img (رابط إلى System Image لمنصة SDK المثبتة)، cache.img (ذاكرة التخزين المؤقت) و sdcard.img (صورة بطاقة SD). عند تنفيذ Wipe Data، يتم حذف userdata.img وإنشاء صورة فارغة جديدة. يتم حفظ اللقطات (Snapshots) في مجلد منفصل snapshots/ داخل دليل AVD.

يتم تنزيل System Image بشكل منفصل عن AVD — يمكن استخدام صورة واحدة بواسطة أجهزة افتراضية متعددة. يتم تخزين صور النظام في دليل Android SDK: $ANDROID_SDK/system-images/android-{API}/{type}/{arch}/. أنواع الصور: google_apis (مع خدمات Google)، google_apis_playstore (مع Google Play Store) و default (AOSP نقي بدون خدمات Google).

أنواع System Images

إنشاء AVD عبر AVD Manager

AVD Manager هي أداة رسومية في Android Studio لإنشاء وإدارة الأجهزة الافتراضية. يمكن فتحها عبر القائمة Tools → Device Manager أو عبر أيقونة شريط الأدوات. يعرض AVD Manager قائمة الأجهزة المنشأة وحالتها (قيد التشغيل/متوقف) وإصدار Android والإجراءات المتاحة (بدء، إيقاف، مسح البيانات، تعديل).

لإنشاء AVD جديد، انقر على زر Create device. اختر ملف تعريف جهاز من القائمة الجاهزة — توفر Google ملفات تعريف لجميع الأجهزة الشائعة. بعد اختيار ملف التعريف، حدد System Image: إصدار Android ونوع الصورة. للمشاريع الجديدة، اختر أحدث إصدار مستقر مع صورة Google APIs. ثم قم بتكوين اسم AVD واتجاه الشاشة وحجم RAM و VM heap. بعد الإنشاء، يصبح AVD جاهزاً للتشغيل.

إنشاء AVD خطوة بخطوة من سطر الأوامر

# 1. قائمة System Images المتاحة
sdkmanager --list | grep system-images

# 2. تثبيت System Image لـ API 35 مع Google APIs
sdkmanager "system-images;android-35;google_apis;x86_64"

# 3. إنشاء AVD باسم pixel8_api35
avdmanager create avd -n pixel8_api35 \
    -k "system-images;android-35;google_apis;x86_64" \
    -d pixel_8

# 4. تشغيل AVD المنشأ
emulator -avd pixel8_api35 -gpu host -memory 2048

# 5. قائمة جميع AVD
avdmanager list avd

إعداد خصائص الأجهزة في AVD

يسمح AVD Manager بتكوين مفصل لخصائص الأجهزة للجهاز الافتراضي. المعلمات الرئيسية: RAM (ذاكرة الوصول العشوائي، القيمة الموصى بها 2048–4096 ميجابايت)، VM heap (حجم كومة الآلة الافتراضية، 256–512 ميجابايت)، Internal Storage (التخزين الداخلي، 2–8 جيجابايت) و SD Card (بطاقة SD افتراضية). تؤثر هذه المعلمات على أداء التطبيق وسلوكه عند نقص الذاكرة.

تشمل الإعدادات الإضافية: الكاميرا (مُحاكاة أو اتصال كاميرا الويب للمضيف)، أجهزة الاستشعار (مقياس التسارع، الجيروسكوب)، NFC، Bluetooth والبطارية. على سبيل المثال، لاختبار التطبيقات مع اكتشاف الموقع، يمكن محاكاة دوران الجهاز عبر أزرار التحكم في المحاكي أو عبر ADB. محاكاة أجهزة الاستشعار تسمح باختبار سيناريوهات يصعب إعادة إنتاجها على جهاز فعلي.

المعلمات الرئيسية لـ config.ini

تحسين أداء المحاكي

تعتمد سرعة AVD بشكل مباشر على المحاكاة الافتراضية للأجهزة. على Windows يُستخدم Windows Hypervisor Platform (WHPX)، على macOS — Hypervisor.Framework، على Linux — KVM. إذا كانت المحاكاة الافتراضية معطلة، يعمل AVD في وضع المحاكاة البرمجية البحتة، وهو أبطأ بمقدار 10–20 مرة. للتحقق من تفعيل المحاكاة الافتراضية، قم بتشغيل المحاكي مع العلم -accel-check.

العامل الرئيسي الثاني هو اختيار بنية System Image. تعمل صور x86_64 بشكل أسرع بكثير من arm64-v8a على أجهزة الكمبيوتر المزودة بمعالجات Intel و AMD، لأنها لا تتطلب ترجمة ديناميكية لتعليمات ARM. استخدم دائماً صور x86_64 للتطوير على Windows و macOS مع معالجات Intel. على معالجات Mac ARM (Apple Silicon)، استخدم الصور الأصلية arm64-v8a.

أعلام سطر الأوامر للتسريع

# تشغيل مع المحاكاة الافتراضية للأجهزة وتسريع GPU
emulator -avd pixel8_api35 -gpu host -memory 4096 -cores 4

# التحقق من دعم المحاكاة الافتراضية
emulator -accel-check

# تشغيل بدون واجهة رسومية (لـ CI)
emulator -avd pixel8_api35 -no-window -no-audio -gpu off

# استخدام اللقطات للتشغيل السريع
emulator -avd pixel8_api35 -snapshot mysnapshot -no-snapshot-save

نصائح أداء المحاكي

للحصول على أقصى أداء لـ AVD: خصص للمحاكي ما لا يقل عن 2–4 جيجابايت من RAM، فعّل GPU Host (يستخدم بطاقة رسوميات الكمبيوتر للتقديم)، أوقف الصوت (العلم -no-audio) إذا لم يكن مطلوباً، واستخدم اللقطات (Snapshots) للعودة السريعة إلى حالة نظيفة. تحفظ اللقطات حالة النظام بالكامل — يستغرق التشغيل من لقطة 2–5 ثوانٍ بدلاً من 30–60 ثانية للإقلاع الكامل.

يوصى أيضاً بتخزين AVD على قرص SSD — عمليات الإدخال/الإخراج أثناء إقلاع النظام وتثبيت APK تكون أسرع بكثير. لتشغيل عدة AVD في وقت واحد، قم بزيادة إجمالي RAM على الكمبيوتر واستخدم العلم -read-only للمحاكيات غير القابلة للتعديل.

إدارة AVD من سطر الأوامر

التحكم الكامل في AVD ممكن من سطر الأوامر بدون Android Studio. أدوات avdmanager و emulator هي جزء من Android SDK وتقوم بجميع العمليات: إنشاء وحذف وتشغيل وتكوين AVD. سطر الأوامر مفيد بشكل خاص في خطوط أنابيب CI/CD حيث لا توجد واجهة رسومية، ولأتمتة الاختبار.

الأوامر الأساسية لإدارة AVD

# إنشاء AVD بمعلمات مخصصة
avdmanager create avd -n test_device \
    -k "system-images;android-34;google_apis;x86_64" \
    --device "pixel_8" \
    --force

# حذف AVD
avdmanager delete avd -n test_device

# استنساخ AVD (عبر نسخ الملفات)
cp -r ~/.android/avd/pixel8_api35.avd ~/.android/avd/pixel8_clone.avd

# مسح بيانات AVD
emulator -avd test_device -wipe-data

# تثبيت APK على AVD قيد التشغيل
adb -s emulator-5554 install app-release.apk

ADB و AVD: الأوامر الرئيسية

بعد تشغيل AVD، يمكن العمل معه عبر ADB (Android Debug Bridge) تماماً كما هو الحال مع جهاز فعلي. يسمح ADB بتثبيت التطبيقات وإطلاق النوايا (intents) ومحاكاة الأحداث (المكالمات، SMS، GPS) والتقاط لقطات الشاشة وتسجيل فيديو الشاشة. هذا يجعل AVD بيئة كاملة للاختبار الآلي.

# قائمة الأجهزة المتصلة (بما في ذلك AVD)
adb devices

# محاكاة مكالمة واردة
adb emu gsm call +15551234567

# محاكاة إحداثيات GPS
adb emu geo fix -122.084 37.422

# التقاط لقطة شاشة
adb exec-out screencap -p > screenshot.png

# إرسال SMS
adb emu sms send +15551234567 "Hello from AVD"

التحقق من المحاكي في كود التطبيق

أحياناً يحتاج المطور إلى تحديد في الكود ما إذا كان التطبيق يعمل على محاكي أم على جهاز فعلي. قد يكون ذلك ضرورياً لتعطيل التحليلات (لتجنب تلويث بيانات الإنتاج)، أو تفعيل التسجيل الموسع، أو تعطيل الوظائف المعتمدة على الأجهزة التي لا تعمل على المحاكي. توفر Google طرقاً قياسية للتحقق عبر فئة Build وخصائص النظام.

طريقة التحقق عبر خصائص Build

object EmulatorDetector {
    fun isEmulator(): Boolean {
        return (Build.BRAND.startsWith("generic") &&
                Build.DEVICE.startsWith("generic")) ||
                Build.FINGERPRINT.startsWith("generic") ||
                Build.FINGERPRINT.startsWith("unknown") ||
                Build.HARDWARE.contains("goldfish") ||
                Build.HARDWARE.contains("ranchu") ||
                Build.MODEL.contains("google_sdk") ||
                Build.MODEL.contains("Emulator") ||
                Build.MODEL.contains("Android SDK")
    }
}

// الاستخدام
if (EmulatorDetector.isEmulator()) {
    Log.d("App", "Running on emulator — enable debug mode")
}

التحقق عبر خصائص النظام

طريقة إضافية هي قراءة خصائص النظام عبر Build.getRadioVersion() والتحقق من ro.kernel.qemu. على المحاكي، يعيد radio version القيمة null وخاصية qemu مضبوطة على 1. هذه الطريقة أكثر موثوقية في الإصدارات القديمة من Android حيث قد يكون Build.FINGERPRINT مزيفاً من قبل الشركة المصنعة للجهاز.

fun isRunningOnEmulator(): Boolean {
    // التحقق عبر radio version — على المحاكي دائماً null
    val radioVersion = try {
        Build.getRadioVersion()
    } catch (e: Exception) {
        null
    }
    if (radioVersion.isNullOrBlank()) return true

    // التحقق عبر خصائص النظام
    return try {
        val props = ProcessBuilder()
            .command("getprop", "ro.kernel.qemu")
            .start()
            .inputStream.bufferedReader().readText().trim()
        props == "1"
    } catch (e: Exception) {
        false
    }
}