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はスナップショットをサポートしています。システム状態を保存することで起動を高速化します。第三に、エミュレーターは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とは別にダウンロードされます。1つのイメージを複数の仮想デバイスで使用できます。システムイメージは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フラグを付けてエミュレーターを実行します。

2番目の重要な要素は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フラグ）、スナップショットを使用してクリーンな状態にすばやく戻します。スナップショットはシステムの完全な状態を保存します。スナップショットからの起動は2〜5秒で、完全なブートの30〜60秒とは対照的です。

また、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に設定されています。この方法は、Build.FINGERPRINTがデバイスメーカーによって偽装される可能性がある古いAndroidバージョンでより信頼性があります。

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