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 と統合するには、次の最小要件を満たす必要があります。

• Android Studio Iguana の最新の Canary バージョン
• Android Gradle プラグイン 8.3 の最新のアルファ版
• Crashlytics SDK v18.3.7（または Firebase Android 部品表 v32.0.0）

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

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

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 Check モードを有効にすると、Android Studio は Compose UI を自動的に監査し、大画面でテキストを引き伸ばしたり、色のコントラストが低いなど、さまざまな画面サイズでアダプティブ / ユーザー補助の問題がないかをチェックします。このモードでは、さまざまなプレビュー設定で見つかった問題がハイライト表示され、[問題] パネルに一覧表示されます。

Compose プレビューで UI チェックボタン をクリックして、この機能を今すぐお試しいただき、フィードバックをお寄せください。

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

• 問題パネルで選択した問題がフォーカスを失うことがある
• 「ルールを抑制」が機能しない

Compose プレビューの漸進的レンダリング

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

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

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

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

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

また、テンプレートによって実行構成も作成され、[Select Run/Debug Configuration] プルダウン リストからワンクリックでベースライン プロファイルを生成できます。

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

Espresso Device API を使用して、デバイスの回転や画面の展開など、デバイスで一般的な構成変更が行われたときにアプリをテストします。Espresso Device API を使用すると、これらの構成変更を仮想デバイスでシミュレートし、テストを同期的に実行できます。そのため、一度に実行される UI アクションまたはアサーションは 1 つのみであり、テスト結果の信頼性が高まります。詳しくは、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. テストデバイスにコマンドを渡すには、androidTest ソースセットのマニフェスト ファイルに INTERNET 権限と ACCESS_NETWORK_STATE 権限を追加します。

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

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

     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() {
  ...
}