AVD Android: nó là gì, Android Virtual Device và cách cấu hình trình giả lập

AVD là gì

AVD (Android Virtual Device) là một cấu hình phần mềm mô tả một thiết bị Android ảo. Không giống như điện thoại vật lý, AVD không yêu cầu phần cứng — nó chạy trên máy tính thông qua trình giả lập Android dựa trên QEMU. Nhà phát triển tạo bao nhiêu AVD tùy theo nhu cầu kiểm thử: cho các phiên bản Android khác nhau, kích thước màn hình, dung lượng bộ nhớ và mật độ điểm ảnh.

Mỗi AVD được gắn với một SDK Platform cụ thể. Điều này có nghĩa là để tạo AVD với Android 14 (API Level 34), trước tiên bạn phải cài đặt System Image của phiên bản đó thông qua SDK Manager. System Image là một hình ảnh hệ điều hành bao gồm tất cả ứng dụng hệ thống, dịch vụ Google (nếu chọn hình ảnh Google APIs) và các thành phần thời gian chạy. Google khuyến nghị sử dụng hình ảnh Google APIs với dịch vụ Google Play để tương thích tối đa với các thiết bị thực.

AVD không thể thiếu trong phát triển vì nhiều lý do. Thứ nhất, nó cho phép kiểm thử ứng dụng trên các phiên bản Android khác nhau mà không cần mua hàng chục thiết bị. Thứ hai, AVD hỗ trợ Snapshot — lưu trạng thái hệ thống, giúp tăng tốc khởi động. Thứ ba, trình giả lập được tích hợp với Android Studio: cài đặt APK, gỡ lỗi và ghi nhật ký hoạt động giống như trên thiết bị vật lý.

Các loại thiết bị ảo

AVD hỗ trợ nhiều loại thiết bị khác nhau: điện thoại, máy tính bảng, đồng hồ Wear OS, Android TV và Android Automotive. Đối với mỗi loại, AVD Manager cung cấp các hồ sơ có sẵn từ Google: Pixel 8, Pixel 9 Pro, Nexus 7, Samsung Galaxy Tab và các hồ sơ khác. Hồ sơ thiết bị xác định kích thước màn hình, độ phân giải, mật độ điểm ảnh (dpi) và điều hướng (cử chỉ hoặc nút bấm).

AVD bao gồm những gì

Mỗi AVD là một tập hợp các tệp cấu hình và hình ảnh. Tệp cấu hình chính là config.ini, lưu trữ các tham số của thiết bị ảo: tên, loại, API Level, kích thước màn hình, RAM và kích thước VM heap. Tệp nằm trong thư mục $HOME/.android/avd/TênAVD.avd/ và có thể được sửa thủ công, mặc dù thường được chỉnh sửa qua AVD Manager.

Ngoài config.ini, thư mục AVD còn lưu trữ: userdata.img (hình ảnh dữ liệu người dùng — ứng dụng, cài đặt, tệp), system.img (liên kết đến System Image của SDK Platform đã cài đặt), cache.img (bộ nhớ đệm) và sdcard.img (hình ảnh thẻ SD). Khi thực hiện Wipe Data, userdata.img bị xóa và một hình ảnh trống mới được tạo. Snapshot được lưu trong thư mục riêng snapshots/ bên trong thư mục AVD.

System Image được tải riêng biệt với AVD — một hình ảnh có thể được sử dụng bởi nhiều thiết bị ảo. Hình ảnh hệ thống được lưu trữ trong thư mục Android SDK: $ANDROID_SDK/system-images/android-{API}/{type}/{arch}/. Các loại hình ảnh: google_apis (có dịch vụ Google), google_apis_playstore (có Google Play Store) và default (AOSP thuần túy không có dịch vụ Google).

Các loại System Images

Tạo AVD qua AVD Manager

AVD Manager là một công cụ đồ họa trong Android Studio để tạo và quản lý các thiết bị ảo. Có thể mở nó qua menu Tools → Device Manager hoặc qua biểu tượng trên thanh công cụ. AVD Manager hiển thị danh sách các thiết bị đã tạo, trạng thái của chúng (đang chạy/đã dừng), phiên bản Android và các hành động có sẵn (bắt đầu, dừng, xóa dữ liệu, chỉnh sửa).

Để tạo AVD mới, nhấp vào nút Create device. Chọn một hồ sơ thiết bị từ danh sách có sẵn — Google cung cấp hồ sơ cho tất cả các thiết bị phổ biến. Sau khi chọn hồ sơ, chỉ định System Image: phiên bản Android và loại hình ảnh. Đối với các dự án mới, hãy chọn phiên bản ổn định mới nhất với hình ảnh Google APIs. Sau đó cấu hình tên AVD, hướng màn hình, RAM và kích thước VM heap. Sau khi tạo, AVD đã sẵn sàng để khởi chạy.

Tạo AVD từng bước từ dòng lệnh

# 1. Danh sách System Images khả dụng
sdkmanager --list | grep system-images

# 2. Cài đặt System Image cho API 35 với Google APIs
sdkmanager "system-images;android-35;google_apis;x86_64"

# 3. Tạo AVD có tên pixel8_api35
avdmanager create avd -n pixel8_api35 \
    -k "system-images;android-35;google_apis;x86_64" \
    -d pixel_8

# 4. Khởi chạy AVD đã tạo
emulator -avd pixel8_api35 -gpu host -memory 2048

# 5. Danh sách tất cả AVD
avdmanager list avd

Cấu hình đặc tính phần cứng của AVD

AVD Manager cho phép cấu hình chi tiết các đặc tính phần cứng của thiết bị ảo. Các tham số chính: RAM (bộ nhớ truy cập ngẫu nhiên, giá trị khuyến nghị 2048–4096 MB), VM heap (kích thước heap máy ảo, 256–512 MB), bộ nhớ trong (2–8 GB) và thẻ SD (thẻ SD ảo). Các tham số này ảnh hưởng đến hiệu suất ứng dụng và hành vi của nó khi thiếu bộ nhớ.

Các cài đặt bổ sung bao gồm: máy ảnh (mô phỏng hoặc kết nối webcam máy chủ), cảm biến (gia tốc kế, con quay hồi chuyển), NFC, Bluetooth và pin. Ví dụ, để kiểm thử ứng dụng có phát hiện vị trí, có thể mô phỏng xoay thiết bị qua các nút điều khiển trình giả lập hoặc qua ADB. Mô phỏng cảm biến cho phép kiểm thử các kịch bản khó tái tạo trên thiết bị vật lý.

Các tham số chính của config.ini

Tối ưu hóa hiệu suất trình giả lập

Tốc độ của AVD phụ thuộc trực tiếp vào ảo hóa phần cứng. Trên Windows sử dụng Windows Hypervisor Platform (WHPX), trên macOS — Hypervisor.Framework, trên Linux — KVM. Nếu ảo hóa bị tắt, AVD hoạt động ở chế độ mô phỏng phần mềm thuần túy, chậm hơn 10–20 lần. Để kiểm tra xem ảo hóa có được bật không, hãy chạy trình giả lập với cờ -accel-check.

Yếu tố chính thứ hai là lựa chọn kiến trúc System Image. Hình ảnh x86_64 hoạt động nhanh hơn đáng kể so với arm64-v8a trên máy tính có bộ xử lý Intel và AMD vì chúng không yêu cầu dịch động lệnh ARM. Luôn sử dụng hình ảnh x86_64 để phát triển trên Windows và macOS với bộ xử lý Intel. Trên bộ xử lý ARM Mac (Apple Silicon), sử dụng hình ảnh arm64-v8a gốc.

Cờ dòng lệnh để tăng tốc

# Khởi chạy với ảo hóa phần cứng và tăng tốc GPU
emulator -avd pixel8_api35 -gpu host -memory 4096 -cores 4

# Kiểm tra hỗ trợ ảo hóa
emulator -accel-check

# Chạy không có giao diện đồ họa (cho CI)
emulator -avd pixel8_api35 -no-window -no-audio -gpu off

# Sử dụng snapshot để khởi động nhanh
emulator -avd pixel8_api35 -snapshot mysnapshot -no-snapshot-save

Mẹo hiệu suất trình giả lập

Để có hiệu suất AVD tối đa: cấp cho trình giả lập ít nhất 2–4 GB RAM, bật GPU Host (sử dụng card đồ họa máy tính để kết xuất), tắt âm thanh (cờ -no-audio) nếu không cần và sử dụng Snapshot để quay lại trạng thái sạch nhanh chóng. Snapshot lưu trạng thái hệ thống hoàn chỉnh — khởi chạy từ ảnh chụp mất 2–5 giây thay vì 30–60 giây khởi động đầy đủ.

Cũng nên lưu trữ AVD trên ổ SSD — các thao tác I/O trong quá trình khởi động hệ thống và cài đặt APK nhanh hơn đáng kể. Để chạy nhiều AVD cùng lúc, hãy tăng tổng dung lượng RAM trên máy tính và sử dụng cờ -read-only cho các trình giả lập bất biến.

Quản lý AVD từ dòng lệnh

Có thể kiểm soát hoàn toàn AVD từ dòng lệnh mà không cần Android Studio. Các công cụ avdmanager và emulator là một phần của Android SDK và thực hiện tất cả các thao tác: tạo, xóa, khởi chạy và cấu hình AVD. Dòng lệnh đặc biệt hữu ích trong các pipeline CI/CD, nơi không có giao diện đồ họa và cho tự động hóa kiểm thử.

Các lệnh quản lý AVD cơ bản

# Tạo AVD với tham số tùy chỉnh
avdmanager create avd -n test_device \
    -k "system-images;android-34;google_apis;x86_64" \
    --device "pixel_8" \
    --force

# Xóa AVD
avdmanager delete avd -n test_device

# Nhân bản AVD (bằng cách sao chép tệp)
cp -r ~/.android/avd/pixel8_api35.avd ~/.android/avd/pixel8_clone.avd

# Đặt lại dữ liệu AVD
emulator -avd test_device -wipe-data

# Cài đặt APK trên AVD đang chạy
adb -s emulator-5554 install app-release.apk

ADB và AVD: các lệnh chính

Sau khi khởi chạy AVD, có thể làm việc với nó qua ADB (Android Debug Bridge) giống như với thiết bị vật lý. ADB cho phép cài đặt ứng dụng, khởi chạy intent, mô phỏng sự kiện (cuộc gọi, SMS, GPS), chụp ảnh màn hình và quay video màn hình. Điều này biến AVD thành một môi trường hoàn chỉnh cho kiểm thử tự động.

# Danh sách thiết bị đã kết nối (bao gồm AVD)
adb devices

# Mô phỏng cuộc gọi đến
adb emu gsm call +15551234567

# Mô phỏng tọa độ GPS
adb emu geo fix -122.084 37.422

# Chụp ảnh màn hình
adb exec-out screencap -p > screenshot.png

# Gửi SMS
adb emu sms send +15551234567 "Hello from AVD"

Kiểm tra trình giả lập trong mã ứng dụng

Đôi khi nhà phát triển cần xác định trong mã xem ứng dụng đang chạy trên trình giả lập hay trên thiết bị vật lý. Điều này có thể cần thiết để tắt phân tích (tránh làm nhiễu dữ liệu sản xuất), bật ghi nhật ký mở rộng hoặc tắt các chức năng phụ thuộc vào phần cứng không hoạt động trên trình giả lập. Google cung cấp các phương pháp kiểm tra tiêu chuẩn thông qua lớp Build và các thuộc tính hệ thống.

Phương pháp kiểm tra qua thuộc tính 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")
    }
}

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

Kiểm tra qua thuộc tính hệ thống

Một phương pháp bổ sung là đọc các thuộc tính hệ thống qua Build.getRadioVersion() và kiểm tra ro.kernel.qemu. Trên trình giả lập, radio version trả về null và thuộc tính qemu được đặt thành 1. Phương pháp này đáng tin cậy hơn trên các phiên bản Android cũ nơi Build.FINGERPRINT có thể bị nhà sản xuất thiết bị làm giả.

fun isRunningOnEmulator(): Boolean {
    // Kiểm tra qua radio version — trên trình giả lập luôn null
    val radioVersion = try {
        Build.getRadioVersion()
    } catch (e: Exception) {
        null
    }
    if (radioVersion.isNullOrBlank()) return true

    // Kiểm tra qua thuộc tính hệ thống
    return try {
        val props = ProcessBuilder()
            .command("getprop", "ro.kernel.qemu")
            .start()
            .inputStream.bufferedReader().readText().trim()
        props == "1"
    } catch (e: Exception) {
        false
    }
}