Android Studio Iguana | 2023.2.1（2024 年 2 月）

Android Studio Iguana の新機能は次のとおりです。

パッチリリース

Android Studio Iguana と Android Gradle プラグイン 8.3 のパッチリリースを以下に示します。

Android Studio Iguana | 2023.2.1 パッチ 2 と AGP 8.3.2（2024 年 4 月）

このマイナー アップデートには こちらのバグの修正が含まれています。

Android Studio Iguana | 2023.2.1 パッチ 1 と AGP 8.3.1（2024 年 3 月）

このマイナー アップデートには こちらのバグの修正が含まれています。

IntelliJ IDEA 2023.2 プラットフォームのアップデート

Android Studio Iguana には、Studio IDE のエクスペリエンスを向上させる IntelliJ IDEA 2023.2 アップデートが含まれています。変更の詳細については、 IntelliJ IDEA 2023.2 リリースノートをご覧ください。

App Quality Insights でのバージョン管理システムの統合

App Quality Insights で、Crashlytics のスタック トレースから、クラッシュが発生した時点の関連するコードに移動できるようになりました。AGP は git コミット ハッシュデータをクラッシュ レポートに添付します。これにより、Android Studio はコードに移動し、問題が発生したバージョンでのコードの状態を表示できます。App Quality Insights でクラッシュ レポートを表示するときに、現在の git チェックアウトのコード行に移動するか、現在のチェックアウトとクラッシュを生成したコードベースのバージョンとの差分を表示するかを選択できます。

バージョン管理システムを App Quality Insights と統合するには、次の最小要件を満たす必要があります。

デバッグ可能なビルドタイプでバージョン管理統合を使用するには、モジュール レベルのビルドファイルで vcsInfo フラグを有効にします。リリース（デバッグ不可）ビルドの場合、このフラグはデフォルトで有効になっています。

Kotlin

android {
  buildTypes {
    getByName("debug") {
      vcsInfo {
        include = true
      }
    }
  }
}

Groovy

android {
  buildTypes {
    debug {
      vcsInfo {
        include true
      }
    }
  }
}

アプリをビルドして Google Play に公開すると、クラッシュ レポートに、IDE がスタック トレースからアプリの以前のバージョンにリンクするために必要なデータが含まれるようになります。

App Quality Insights で Crashlytics のクラッシュ バリアントを表示する

クラッシュの根本原因を分析するために、App Quality Insights を使用して、問題の バリアント（ 同様のスタック トレースを共有するイベントのグループ）ごとにイベントを表示できるようになりました。クラッシュ レポートの各バリアントのイベントを表示するには、プルダウンからバリアントを選択します。すべてのバリアントの情報を集計するには、[すべて] を選択します。

Compose UI チェック

デベロッパーが Jetpack Compose でより適応性の高いアクセシビリティ対応の UI を構築できるように、Android Studio Iguana Canary 5 で Compose プレビューに新しい UI チェックモードが導入されました。この機能は、ビューのビジュアル リンティング とアクセシビリティ チェックの統合 と同様に機能します。Compose UI チェックモードを有効にすると、Android Studio は Compose UI を自動的に監査し、大画面でのテキストの引き伸ばしや色のコントラストの低さなど、さまざまな画面サイズでの適応性とアクセシビリティの問題をチェックします。このモードでは、さまざまなプレビュー構成で見つかった問題がハイライト表示され、[問題] パネルに一覧表示されます。

この機能を試すには、Compose プレビューの [UI チェック] ボタン をクリックして、フィードバックをお送りください。

[Compose UI チェックモード] ボタンをクリックしてチェックを有効にします。

UI チェックモードの既知の問題:

  • [問題] パネルで選択した問題のフォーカスが失われることがある
  • [ルールを抑制] が機能しない
[問題] パネルに詳細が表示された状態で Compose UI チェックモードが有効になっています。

Compose プレビューのプログレッシブ レンダリング

Android Studio Iguana Canary 3 では、Compose プレビューにプログレッシブ レンダリングが導入されています。プレビューのパフォーマンスを向上させる継続的な取り組みの一環として、ビューから外れているプレビューのレンダリング品質を意図的に低下させ、使用するメモリを節約しています。

この機能は、1 つのファイルでより多くのプレビューを同時に処理できるようにすることで、プレビューのユーザビリティをさらに向上させることを目的に開発されています。ぜひ お試しいただき、フィードバックをお送りください。

ベースライン プロファイル モジュール ウィザード

Android Studio Iguana 以降では、新しいモジュール ウィザード（[File] > [New] > [New Module]）の [Baseline Profile Generator] テンプレートを使用して、アプリの ベースライン プロファイルを生成できます。

このテンプレートは、ベースライン プロファイルをサポートできるようにプロジェクトを設定します。新しいベースライン プロファイル Gradle プラグインを使用します。このプラグインは、1 つの Gradle タスクで必要な方法でプロジェクトを設定するプロセスを自動化します。

また、このテンプレートでは、[Select Run/Debug Configuration] プルダウン リストから 1 回クリックするだけでベースライン プロファイルを生成できる実行構成も作成されます。

Espresso Device API を使用して構成の変更に対するテストを行う

Espresso Device API を使用すると、デバイスで一般的な構成の変更（回転や画面の展開など）が発生した場合にアプリをテストできます。Espresso Device API を使用すると、仮想デバイスでこれらの構成変更をシミュレートし、テストを同期的に実行できるため、一度に 1 つの UI アクションまたはアサーションのみが実行され、テスト結果の信頼性が向上します。Espresso で UI テストを 作成 する方法について詳しくは、こちらをご覧ください。

Espresso Device API を使用するには、次のものが必要です。

  • Android Studio Iguana 以降
  • Android Gradle プラグイン 8.3 以降
  • Android Emulator 33.1.10 以降
  • API レベル 24 以降を実行する Android 仮想デバイス

Espresso Device API 用にプロジェクトを設定する

プロジェクトを Espresso Device API をサポートするように設定する手順は次のとおりです。

  1. テストでテストデバイスにコマンドを渡せるように、 INTERNET と ACCESS_NETWORK_STATE 権限を androidTest ソースセットのマニフェスト ファイルに追加します。

      <uses-permission android:name="android.permission.INTERNET" />
  <uses-permission android:name="android.permissions.ACCESS_NETWORK_STATE" />

  2. ファイルで enableEmulatorControl 試験運用版フラグを有効にします。gradle.properties

      android.experimental.androidTest.enableEmulatorControl=true

  3. モジュール レベルのビルド スクリプトで emulatorControl オプションを有効にします。

    Kotlin

      testOptions {
    emulatorControl {
      enable = true
    }
  }

    Groovy

      testOptions {
    emulatorControl {
      enable = true
    }
  }

  4. モジュール レベルのビルドスクリプトで、Espresso Device ライブラリ をプロジェクトにインポートします。

    Kotlin

      dependencies {
    androidTestImplementation("androidx.test.espresso:espresso-device:3.6.1")
  }

    Groovy

      dependencies {
    androidTestImplementation 'androidx.test.espresso:espresso-device:3.6.1'
  }

一般的な構成の変更に対するテストを行う

Espresso Device API には、デバイス構成の変更をシミュレートするために使用できる画面の向きと折りたたみ状態が複数あります。

画面の回転に対するテストを行う

デバイスの画面が回転したときにアプリに何が起こるかをテストする例を次に示します。

  1. まず、開始状態を一定にするため、デバイスを縦向きに設定します 。

      import androidx.test.espresso.device.action.ScreenOrientation
  import androidx.test.espresso.device.rules.ScreenOrientationRule
  ...
  @get:Rule
  val screenOrientationRule: ScreenOrientationRule = ScreenOrientationRule(ScreenOrientation.PORTRAIT)

  2. テストの実行中にデバイスを横向きに設定するテストを作成します。

      @Test
  fun myRotationTest() {
    ...
    // Sets the device to landscape orientation during test execution.
    onDevice().setScreenOrientation(ScreenOrientation.LANDSCAPE)
    ...
  }

  3. 画面が回転したら、UI が新しいレイアウトに適切に適応していることを確認します。

      @Test
  fun myRotationTest() {
    ...
    // Sets the device to landscape orientation during test execution.
    onDevice().setScreenOrientation(ScreenOrientation.LANDSCAPE)
    composeTestRule.onNodeWithTag("NavRail").assertIsDisplayed()
    composeTestRule.onNodeWithTag("BottomBar").assertDoesNotExist()
  }

画面の展開に対するテストを行う

折りたたみ式デバイスでアプリを使用しているときに画面が展開された場合にアプリに何が起こるかをテストする例を次に示します。

  1. まず、デバイスが折りたたまれた状態で onDevice().setClosedMode() を呼び出してテストします。アプリのレイアウトがコンパクトな画面幅に適応していることを確認します。

      @Test
  fun myUnfoldedTest() {
    onDevice().setClosedMode()
    composeTestRule.onNodeWithTag("BottomBar").assetIsDisplayed()
    composeTestRule.onNodeWithTag("NavRail").assetDoesNotExist()
    ...
  }

  2. 完全に開いた状態に移行するには、 onDevice().setFlatMode() を呼び出します。アプリのレイアウトが 拡大されたサイズクラスに適応していることを確認します。

      @Test
  fun myUnfoldedTest() {
    onDevice().setClosedMode()
    ...
    onDevice().setFlatMode()
    composeTestRule.onNodeWithTag("NavRail").assertIsDisplayed()
    composeTestRule.onNodeWithTag("BottomBar").assetDoesNotExist()
  }

テストに必要なデバイスを指定する

折りたたみ式ではないデバイスで折りたたみアクションを実行するテストを実行すると、通常はテストが失敗します。実行中のデバイスに関連するテストのみを実行するには、@RequiresDeviceMode アノテーションを使用します。テストランナーは、テスト対象の構成をサポートしていないデバイスでのテストの実行を自動的にスキップします。デバイス要件ルールは、各テストまたはテストクラス全体に追加できます。

たとえば、フラット構成への展開をサポートするデバイスでのみテストを実行するように指定するには、次の @RequiresDeviceMode コードをテストに追加します。

@Test
@RequiresDeviceMode(mode = FLAT)
fun myUnfoldedTest() {
  ...
}