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 از انواع مختلف دستگاه‌ها پشتیبانی می‌کند: تلفن‌ها (Phone)، تبلت‌ها (Tablet)، ساعت‌ها (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 Level، اندازه صفحه، مقدار RAM و VM heap. فایل در دایرکتوری $HOME/.android/avd/NameAVD.avd/ قرار دارد و می‌توان آن را به صورت دستی ویرایش کرد، اگرچه معمولاً از طریق AVD Manager ویرایش می‌شود.

علاوه بر config.ini، در دایرکتوری AVD ذخیره می‌شوند: userdata.img (تصویر داده‌های کاربر — برنامه‌ها، تنظیمات، فایل‌ها)، system.img (ارجاع به System Image نصب‌شده SDK Platform)، 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 و اقدامات موجود (اجرا، توقف، wipe data، ویرایش) را نشان می‌دهد.

برای ایجاد AVD جدید، دکمه Create device را کلیک کنید. یک پروفایل دستگاه از لیست آماده انتخاب کنید — Google برای تمام دستگاه‌های محبوب پروفایل ارائه می‌دهد. پس از انتخاب پروفایل، System Image را مشخص کنید: نسخه Android و نوع تصویر. برای پروژه‌های جدید، آخرین نسخه پایدار با تصویر Google APIs را انتخاب کنید. سپس نام AVD، جهت صفحه، مقدار RAM و VM heap را تنظیم کنید. پس از ایجاد، AVD آماده اجرا است.

ایجاد گام به گام AVD از خط فرمان

# لیست System Images موجود
sdkmanager --list | grep system-images

# نصب System Image برای API 35 با Google APIs
sdkmanager "system-images;android-35;google_apis;x86_64"

# ایجاد AVD با نام pixel8_api35
avdmanager create avd -n pixel8_api35 \
    -k "system-images;android-35;google_apis;x86_64" \
    -d pixel_8

# اجرای AVD ایجاد شده
emulator -avd pixel8_api35 -gpu host -memory 2048

# لیست تمام AVDها
avdmanager list avd

تنظیم ویژگی‌های سخت‌افزاری AVD

AVD Manager امکان تنظیم دقیق ویژگی‌های سخت‌افزاری دستگاه مجازی را فراهم می‌کند. پارامترهای اصلی: RAM (حافظه دسترسی تصادفی، مقدار توصیه شده 2048–4096 مگابایت)، VM heap (اندازه heap ماشین مجازی، 256–512 مگابایت)، Internal Storage (حافظه داخلی، 2–8 گیگابایت) و SD Card (کارت SD مجازی). این پارامترها بر عملکرد برنامه و رفتار آن در کمبود حافظه تأثیر می‌گذارند.

تنظیمات اضافی شامل: دوربین (شبیه‌سازی شده یا اتصال وب‌کام میزبان)، سنسورها (شتاب‌سنج، ژیروسکوپ)، NFC، بلوتوث و باتری. به عنوان مثال، برای تست برنامه‌های تشخیص موقعیت، می‌توان چرخش دستگاه را از طریق دکمه‌های کنترل شبیه‌ساز یا از طریق ADB شبیه‌سازی کرد. شبیه‌سازی سنسورها امکان تست سناریوهایی را فراهم می‌کند که بازتولید آنها روی دستگاه فیزیکی دشوار است.

پارامترهای کلیدی config.ini

بهینه‌سازی عملکرد شبیه‌ساز

سرعت کار AVD مستقیماً به مجازی‌سازی سخت‌افزاری بستگی دارد. در Windows از Windows Hypervisor Platform (WHPX)، در macOS از Hypervisor.Framework، در Linux از KVM استفاده می‌شود. اگر مجازی‌سازی غیرفعال باشد، AVD در حالت شبیه‌سازی کاملاً نرم‌افزاری کار می‌کند که 10–20 برابر کندتر است. برای بررسی فعال بودن مجازی‌سازی، شبیه‌ساز را با پرچم -accel-check اجرا کنید.

دومین عامل کلیدی انتخاب معماری System Image است. تصاویر x86_64 روی رایانه‌های دارای پردازنده Intel و AMD به طور قابل توجهی سریع‌تر از arm64-v8a کار می‌کنند، زیرا نیاز به ترجمه پویای دستورالعمل‌های ARM ندارند. همیشه از تصاویر x86_64 برای توسعه در Windows و macOS با پردازنده‌های Intel استفاده کنید. در پردازنده‌های ARM Mac (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

# استفاده از snapshotها برای راه‌اندازی سریع
emulator -avd pixel8_api35 -snapshot mysnapshot -no-snapshot-save

نکات عملکرد شبیه‌ساز

برای حداکثر عملکرد AVD: حداقل 2–4 گیگابایت RAM به شبیه‌ساز اختصاص دهید، GPU Host را فعال کنید (از کارت گرافیک رایانه برای رندر استفاده می‌کند)، صدا را غیرفعال کنید (پرچم -no-audio)، اگر لازم نیست، و از Snapshots برای بازگشت سریع به حالت تمیز استفاده کنید. 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 امکان نصب برنامه‌ها، اجرای intentها، شبیه‌سازی رویدادها (تماس‌ها، 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
    }
}