AVD Android: یہ کیا ہے، Android Virtual Device اور ایمولیٹر کیسے ترتیب دیں

AVD کیا ہے

AVD (Android Virtual Device) ایک سافٹ ویئر کنفیگریشن ہے جو مجازی Android ڈیوائس کی وضاحت کرتی ہے۔ جسمانی فون کے برعکس، AVD کو ہارڈویئر کی ضرورت نہیں ہوتی — یہ QEMU پر مبنی Android ایمولیٹر کے ذریعے کمپیوٹر پر چلتا ہے۔ ڈیولپر جانچ کے لیے ضرورت کے مطابق کئی AVD بناتا ہے: Android کے مختلف ورژنز، اسکرین سائزز، میموری گنجائشوں اور پکسل کثافتوں کے لیے۔

ہر AVD ایک مخصوص SDK Platform سے منسلک ہوتا ہے۔ اس کا مطلب ہے کہ Android 14 (API Level 34) کے ساتھ AVD بنانے کے لیے، پہلے SDK Manager کے ذریعے اس ورژن کی System Image انسٹال کرنی ہوگی۔ System Image ایک آپریٹنگ سسٹم امیج ہے جس میں تمام سسٹم ایپلیکیشنز، Google خدمات (اگر Google APIs امیج منتخب کی گئی ہو) اور رن ٹائم اجزاء شامل ہوتے ہیں۔ Google سفارش کرتا ہے حقیقی آلات کے ساتھ زیادہ سے زیادہ مطابقت کے لیے Google Play خدمات والی Google APIs امیجز استعمال کریں۔

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 Level، اسکرین سائز، RAM اور VM ہیپ سائز۔ فائل $HOME/.android/avd/AVDنام.avd/ ڈائریکٹری میں واقع ہوتی ہے اور اسے دستی طور پر تبدیل کیا جا سکتا ہے، اگرچہ اسے عام طور پر AVD Manager کے ذریعے ترمیم کیا جاتا ہے۔

config.ini کے علاوہ، AVD ڈائریکٹری میں درج ذیل ذخیرہ ہوتے ہیں: userdata.img (صارف ڈیٹا امیج — ایپلیکیشنز، ترتیبات، فائلیں)، system.img (انسٹال کردہ SDK Platform کی System Image کا لنک)، cache.img (کیش) اور sdcard.img (SD کارڈ امیج)۔ Wipe Data کرنے پر، userdata.img حذف ہو جاتا ہے اور ایک نیا خالی امیج بنایا جاتا ہے۔ سنیپ شاٹس AVD ڈائریکٹری کے اندر ایک علیحدہ snapshots/ فولڈر میں محفوظ ہوتے ہیں۔

System Image AVD سے علیحدہ ڈاؤن لوڈ کی جاتی ہے — ایک امیج کئی مجازی آلات استعمال کر سکتے ہیں۔ سسٹم امیجز Android SDK ڈائریکٹری میں محفوظ ہوتی ہیں: $ANDROID_SDK/system-images/android-{API}/{type}/{arch}/۔ امیج کی اقسام: google_apis (Google خدمات کے ساتھ)، google_apis_playstore (Google Play Store کے ساتھ) اور default (Google خدمات کے بغیر خالص AOSP)۔

System Images کی اقسام

AVD Manager کے ذریعے AVD بنانا

AVD Manager Android Studio میں مجازی آلات بنانے اور ان کے نظم کے لیے ایک گرافیکل آلہ ہے۔ اسے Tools → Device Manager مینو یا ٹول بار آئیکن کے ذریعے کھولا جا سکتا ہے۔ AVD Manager بنائے گئے آلات کی فہرست، ان کی حالت (چل رہا/بند)، Android ورژن اور دستیاب کارروائیاں (شروع، روکیں، ڈیٹا مٹائیں، ترمیم کریں) دکھاتا ہے۔

نیا AVD بنانے کے لیے، Create device بٹن پر کلک کریں۔ تیار شدہ فہرست سے ایک ڈیوائس پروفائل منتخب کریں — Google تمام مشہور آلات کے لیے پروفائلز فراہم کرتا ہے۔ پروفائل منتخب کرنے کے بعد، System Image کی وضاحت کریں: Android ورژن اور امیج کی قسم۔ نئے منصوبوں کے لیے، Google APIs امیج کے ساتھ تازہ ترین مستحکم ورژن منتخب کریں۔ پھر AVD نام، اسکرین واقفیت، RAM اور VM ہیپ سائز ترتیب دیں۔ بنانے کے بعد، AVD لانچ کرنے کے لیے تیار ہے۔

کمانڈ لائن سے مرحلہ وار AVD بنانا

# 1. دستیاب System Images کی فہرست
sdkmanager --list | grep system-images

# 2. Google APIs کے ساتھ API 35 کے لیے System Image انسٹال کریں
sdkmanager "system-images;android-35;google_apis;x86_64"

# 3. pixel8_api35 نام سے AVD بنائیں
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 MB)، VM ہیپ (ورچوئل مشین ہیپ سائز، 256–512 MB)، اندرونی اسٹوریج (2–8 GB) اور SD کارڈ (ورچوئل 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 امیجز Intel اور AMD پروسیسر والے کمپیوٹرز پر arm64-v8a سے نمایاں طور پر تیز کام کرتی ہیں، کیونکہ انہیں ARM ہدایات کے متحرک ترجمے کی ضرورت نہیں ہوتی۔ Intel پروسیسر والے Windows اور macOS پر ڈیولپمنٹ کے لیے ہمیشہ x86_64 امیجز استعمال کریں۔ Mac ARM پروسیسر (Apple Silicon) پر، مقامی arm64-v8a امیجز استعمال کریں۔

تیز رفتاری کے لیے کمانڈ لائن پرچم

# ہارڈویئر ورچوئلائزیشن اور GPU ایکسلریشن کے ساتھ لانچ کریں
emulator -avd pixel8_api35 -gpu host -memory 4096 -cores 4

# ورچوئلائزیشن سپورٹ کی جانچ کریں
emulator -accel-check

# GUI کے بغیر چلائیں (CI کے لیے)
emulator -avd pixel8_api35 -no-window -no-audio -gpu off

# تیز اسٹارٹ اپ کے لیے سنیپ شاٹس استعمال کریں
emulator -avd pixel8_api35 -snapshot mysnapshot -no-snapshot-save

ایمولیٹر کارکردگی کے نکات

زیادہ سے زیادہ AVD کارکردگی کے لیے: ایمولیٹر کو کم از کم 2–4 GB RAM مختص کریں، GPU Host فعال کریں (رینڈرنگ کے لیے کمپیوٹر کا گرافکس کارڈ استعمال کرتا ہے)، اگر ضرورت نہ ہو تو آواز بند کریں (پرچم -no-audio)، اور صاف حالت میں تیزی سے واپسی کے لیے سنیپ شاٹس استعمال کریں۔ سنیپ شاٹس مکمل سسٹم حالت محفوظ کرتے ہیں — سنیپ شاٹ سے لانچ ہونے میں 30–60 سیکنڈ کے مکمل بوٹ کے بجائے 2–5 سیکنڈ لگتے ہیں۔

AVD کو SSD ڈرائیو پر ذخیرہ کرنے کی بھی سفارش کی جاتی ہے — سسٹم بوٹ اور APK انسٹالیشن کے دوران I/O آپریشنز نمایاں طور پر تیز ہوتے ہیں۔ ایک ساتھ کئی AVD چلانے کے لیے، کمپیوٹر پر RAM کی کل مقدار بڑھائیں اور ناقابل تبدیل ایمولیٹرز کے لیے -read-only پرچم استعمال کریں۔

کمانڈ لائن سے AVD کا نظم کرنا

Android Studio کے بغیر کمانڈ لائن سے AVD پر مکمل کنٹرول ممکن ہے۔ 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

# چلنے والے AVD پر APK انسٹال کریں
adb -s emulator-5554 install app-release.apk

ADB اور AVD: اہم کمانڈز

AVD لانچ کرنے کے بعد، ADB (Android Debug Bridge) کے ذریعے جسمانی آلے کی طرح اس کے ساتھ کام کیا جا سکتا ہے۔ ADB ایپلیکیشنز انسٹال کرنے، انٹینٹس لانچ کرنے، واقعات (کال، 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 {
    // ریڈیو ورژن کے ذریعے جانچ — ایمولیٹر پر ہمیشہ 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
    }
}