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 チェックアウトのコード行に移動するか、現在のチェックアウトとクラッシュを生成したコードベースのバージョンの差分を表示するかを選択できます。

注: 現在、この機能は git を使用したバージョン管理のみをサポートしています。

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

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

デバッグ可能なビルドタイプにバージョン管理の統合を使用するには、モジュール レベルのビルドファイルで 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 チェックモードが導入されました。この機能は、ビューのビジュアル lint チェックおよびユーザー補助機能チェックの統合と同様に機能します。Compose UI Check モードを有効にすると、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]）の ベースライン プロファイル ジェネレータ テンプレートを使用して、アプリのベースライン プロファイルを生成できます。

このテンプレートを使用すると、ベースライン プロファイルをサポートするようにプロジェクトを設定できます。新しいベースライン プロファイル 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 デバイス ライブラリをプロジェクトにインポートします。

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