AVD Android: ano ito, Android Virtual Device at paano i-configure ang emulator

Ano ang AVD

AVD (Android Virtual Device) — ay isang software configuration na naglalarawan ng isang virtual na Android device. Hindi tulad ng isang pisikal na telepono, ang AVD ay hindi nangangailangan ng hardware — ito ay pinapatakbo sa computer sa pamamagitan ng Android emulator na batay sa QEMU. Ang developer ay lumilikha ng maraming AVD hangga't kinakailangan para sa pagsubok: para sa iba't ibang bersyon ng Android, laki ng screen, dami ng memory, at density ng pixel.

Ang bawat AVD ay nakatali sa isang partikular na SDK Platform. Ito ay nangangahulugan na upang lumikha ng isang AVD na may Android 14 (API Level 34), kailangan munang i-install ang System Image ng bersyong ito sa pamamagitan ng SDK Manager. Ang System Image ay isang imahe ng operating system na kasama ang lahat ng system application, mga serbisyo ng Google (kung napili ang imaheng Google APIs), at mga bahagi ng runtime. Inirerekomenda ng Google ang paggamit ng mga imaheng Google APIs na may mga serbisyo ng Google Play para sa maximum na compatibility sa mga tunay na device.

Ang AVD ay kailangang-kailangan sa pag-develop para sa ilang kadahilanan. Una, pinapayagan nito ang pagsubok ng application sa iba't ibang bersyon ng Android nang hindi bumibili ng dose-dosenang device. Pangalawa, sinusuportahan ng AVD ang Snapshots — pag-save ng estado ng system, na nagpapabilis ng pagsisimula. Pangatlo, ang emulator ay isinama sa Android Studio: ang pag-install ng APK, debugging, at pag-log ay gumagana tulad ng sa isang pisikal na device.

Mga uri ng virtual na device

Sinusuportahan ng AVD ang iba't ibang uri ng device: mga telepono (Phone), tablet (Tablet), relo (Wear OS), telebisyon (Android TV), at mga sistema ng sasakyan (Android Automotive). Para sa bawat uri, ang AVD Manager ay nagbibigay ng mga handa nang profile mula sa Google: Pixel 8, Pixel 9 Pro, Nexus 7, Samsung Galaxy Tab at iba pa. Ang profile ng device ay tumutukoy sa laki ng screen, resolution, density ng pixel (dpi), at nabigasyon (mga galaw o pindutan).

Ano ang binubuo ng AVD

Ang bawat AVD ay isang set ng mga file ng configuration at imahe. Ang pangunahing file ng configuration — config.ini, na nag-iimbak ng mga parameter ng virtual na device: pangalan, uri, API Level, laki ng screen, dami ng RAM at VM heap. Ang file ay matatagpuan sa direktoryo $HOME/.android/avd/PangalanAVD.avd/ at maaaring baguhin nang manu-mano, bagaman karaniwang ine-edit ito sa pamamagitan ng AVD Manager.

Bukod sa config.ini, sa direktoryo ng AVD ay naka-imbak ang: userdata.img (imahe ng data ng user — mga application, setting, file), system.img (referensya sa System Image ng naka-install na SDK Platform), cache.img (cache), at sdcard.img (imahe ng SD card). Sa pagsasagawa ng Wipe Data, ang userdata.img ay tatanggalin at isang bagong walang laman na imahe ang malilikha. Ang mga Snapshot ay nai-save sa isang hiwalay na folder snapshots/ sa loob ng direktoryo ng AVD.

Ang System Image ay dina-download nang hiwalay mula sa AVD — isang imahe ay maaaring gamitin ng maraming virtual na device. Ang mga imahe ng system ay naka-imbak sa direktoryo ng Android SDK: $ANDROID_SDK/system-images/android-{API}/{type}/{arch}/. Mga uri ng imahe: google_apis (may mga serbisyo ng Google), google_apis_playstore (may Google Play Store), at default (purong AOSP nang walang mga serbisyo ng Google).

Mga uri ng System Images

Paglikha ng AVD sa pamamagitan ng AVD Manager

AVD Manager — ay isang graphical na tool sa Android Studio para sa paglikha at pamamahala ng mga virtual na device. Maaari itong buksan sa pamamagitan ng menu na Tools → Device Manager o sa pamamagitan ng icon sa toolbar. Ipinapakita ng AVD Manager ang listahan ng mga nilikhang device, ang kanilang katayuan (tumatakbo/huminto), bersyon ng Android, at mga available na aksyon (simulan, ihinto, wipe data, i-edit).

Upang lumikha ng bagong AVD, i-click ang button na Create device. Pumili ng profile ng device mula sa listahan ng mga handa nang profile — nagbibigay ang Google ng mga profile para sa lahat ng sikat na device. Pagkatapos pumili ng profile, tukuyin ang System Image: bersyon ng Android at uri ng imahe. Para sa mga bagong proyekto, piliin ang pinakabagong stable na bersyon na may imaheng Google APIs. Pagkatapos ay i-configure ang pangalan ng AVD, oryentasyon ng screen, dami ng RAM at VM heap. Pagkatapos malikha, ang AVD ay handa nang patakbuhin.

Hakbang-hakbang na paglikha ng AVD mula sa command line

# Listahan ng mga available na System Images
sdkmanager --list | grep system-images

# Pag-install ng System Image para sa API 35 na may Google APIs
sdkmanager "system-images;android-35;google_apis;x86_64"

# Paglikha ng AVD na may pangalang pixel8_api35
avdmanager create avd -n pixel8_api35 \
    -k "system-images;android-35;google_apis;x86_64" \
    -d pixel_8

# Pagpatakbo ng nilikhang AVD
emulator -avd pixel8_api35 -gpu host -memory 2048

# Listahan ng lahat ng AVD
avdmanager list avd

Pag-configure ng mga katangian ng hardware ng AVD

Pinapayagan ng AVD Manager ang detalyadong pag-configure ng mga katangian ng hardware ng virtual na device. Pangunahing mga parameter: RAM (random access memory, inirerekomendang halaga 2048–4096 MB), VM heap (laki ng heap ng virtual machine, 256–512 MB), Internal Storage (panloob na imbakan, 2–8 GB), at SD Card (virtual na SD card). Ang mga parameter na ito ay nakakaapekto sa pagganap ng application at pag-uugali nito kapag naubusan ng memory.

Ang mga karagdagang setting ay kinabibilangan ng: camera (emulated o pagkonekta ng webcam ng host), mga sensor (accelerometer, gyroscope), NFC, Bluetooth, at baterya. Halimbawa, para sa pagsubok ng mga application na may pagtukoy ng posisyon, ang pag-ikot ng device ay maaaring i-emulate sa pamamagitan ng mga control button ng emulator o sa pamamagitan ng ADB. Ang emulasyon ng sensor ay nagbibigay-daan sa pagsubok ng mga sitwasyong mahirap i-reproduce sa isang pisikal na device.

Mga pangunahing parameter ng config.ini

Pag-optimize ng pagganap ng emulator

Ang bilis ng operasyon ng AVD ay direktang nakadepende sa hardware virtualization. Sa Windows ay ginagamit ang Windows Hypervisor Platform (WHPX), sa macOS — Hypervisor.Framework, sa Linux — KVM. Kung ang virtualization ay naka-off, ang AVD ay gumagana sa purong software emulation mode, na 10–20 beses na mas mabagal. Upang suriin kung ang virtualization ay naka-on, patakbuhin ang emulator na may flag na -accel-check.

Ang pangalawang pangunahing kadahilanan ay ang pagpili ng arkitektura ng System Image. Ang mga imaheng x86_64 ay gumagana nang mas mabilis kaysa arm64-v8a sa mga computer na may Intel at AMD processors, dahil hindi nila kailangan ang dynamic na pagsasalin ng mga ARM instruction. Palaging gumamit ng x86_64 na mga imahe para sa pag-develop sa Windows at macOS na may Intel processors. Sa ARM processors ng Mac (Apple Silicon) gumamit ng native na arm64-v8a na mga imahe.

Mga flag ng command line para sa pagpapabilis

# Pagpatakbo na may hardware virtualization at GPU acceleration
emulator -avd pixel8_api35 -gpu host -memory 4096 -cores 4

# Pagsusuri ng suporta sa virtualization
emulator -accel-check

# Pagpatakbo nang walang graphical interface (para sa CI)
emulator -avd pixel8_api35 -no-window -no-audio -gpu off

# Paggamit ng mga snapshot para sa mabilis na pagsisimula
emulator -avd pixel8_api35 -snapshot mysnapshot -no-snapshot-save

Mga tip sa pagganap ng emulator

Para sa maximum na pagganap ng AVD: maglaan ng hindi bababa sa 2–4 GB RAM sa emulator, i-on ang GPU Host (ginagamit ang video card ng computer para sa rendering), i-off ang tunog (flag -no-audio), kung hindi kinakailangan, at gumamit ng Snapshots para sa mabilis na pagbabalik sa malinis na estado. Ang mga Snapshot ay nagse-save ng buong estado ng system — ang pagsisimula mula sa snapshot ay tumatagal ng 2–5 segundo sa halip na 30–60 segundo ng buong pag-load.

Inirerekomenda din na iimbak ang AVD sa SSD drive — ang mga I/O operation sa pag-load ng system at pag-install ng APK ay makabuluhang pinapabilis. Para sa pagtatrabaho sa maraming AVD nang sabay-sabay, dagdagan ang kabuuang dami ng RAM sa computer at gamitin ang flag na -read-only para sa hindi nababagong mga emulator.

Pamamahala ng AVD mula sa command line

Ang buong kontrol sa AVD ay posible mula sa command line nang walang Android Studio. Ang mga tool na avdmanager at emulator ay bahagi ng Android SDK at ginagawa ang lahat ng operasyon: paglikha, pagtanggal, pagpapatakbo, at pag-configure ng AVD. Ang command line ay lalong kapaki-pakinabang sa mga pipeline ng CI/CD, kung saan walang graphical na interface, at para sa automation ng pagsubok.

Mga pangunahing command sa pamamahala ng AVD

# Lumikha ng AVD na may custom na parameter
avdmanager create avd -n test_device \
    -k "system-images;android-34;google_apis;x86_64" \
    --device "pixel_8" \
    --force

# Tanggalin ang AVD
avdmanager delete avd -n test_device

# I-clone ang AVD (sa pamamagitan ng pagkopya ng file)
cp -r ~/.android/avd/pixel8_api35.avd ~/.android/avd/pixel8_clone.avd

# I-reset ang data ng AVD
emulator -avd test_device -wipe-data

# Mag-install ng APK sa tumatakbong AVD
adb -s emulator-5554 install app-release.apk

ADB at AVD: mga pangunahing command

Pagkatapos simulan ang AVD, maaari itong gamitin sa pamamagitan ng ADB (Android Debug Bridge) tulad ng isang pisikal na device. Pinapayagan ng ADB ang pag-install ng mga application, pagpapatakbo ng mga intent, pag-emulate ng mga kaganapan (tawag, SMS, GPS), pagkuha ng screenshot, at pag-record ng video ng screen. Ginagawa nitong kumpletong kapaligiran ang AVD para sa automated na pagsubok.

# Listahan ng mga konektadong device (kasama ang AVD)
adb devices

# Emulasyon ng papasok na tawag
adb emu gsm call +15551234567

# Emulasyon ng GPS coordinates
adb emu geo fix -122.084 37.422

# Kumuha ng screenshot
adb exec-out screencap -p > screenshot.png

# Magpadala ng SMS
adb emu sms send +15551234567 "Hello from AVD"

Pagsusuri ng emulator sa code ng application

Minsan kailangan ng developer na matukoy sa code kung ang application ay tumatakbo sa isang emulator o sa isang pisikal na device. Ito ay maaaring kailanganin para i-off ang analytics (upang hindi dumihan ang production data), i-on ang extended logging, o i-off ang mga function na umaasa sa hardware na hindi gumagana sa emulator. Nagbibigay ang Google ng mga karaniwang pamamaraan ng pagsusuri sa pamamagitan ng Build class at mga property ng system.

Pamamaraan ng pagsusuri sa pamamagitan ng Build property

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")
    }
}

// Paggamit
if (EmulatorDetector.isEmulator()) {
    Log.d("App", "Running on emulator — enable debug mode")
}

Pagsusuri sa pamamagitan ng mga property ng system

Karagdagang pamamaraan — pagbabasa ng mga property ng system sa pamamagitan ng Build.getRadioVersion() at pagsusuri ng ro.kernel.qemu. Sa emulator, ang radio version ay nagbabalik ng null, at ang qemu property ay nakatakda sa 1. Ang pamamaraang ito ay mas maaasahan sa mga lumang bersyon ng Android kung saan ang Build.FINGERPRINT ay maaaring baguhin ng manufacturer ng device.

fun isRunningOnEmulator(): Boolean {
    // Pagsusuri sa pamamagitan ng radio version — sa emulator palaging null
    val radioVersion = try {
        Build.getRadioVersion()
    } catch (e: Exception) {
        null
    }
    if (radioVersion.isNullOrBlank()) return true

    // Pagsusuri sa pamamagitan ng mga property ng system
    return try {
        val props = ProcessBuilder()
            .command("getprop", "ro.kernel.qemu")
            .start()
            .inputStream.bufferedReader().readText().trim()
        props == "1"
    } catch (e: Exception) {
        false
    }
}