Google は、黒人コミュニティに対する人種平等の促進に取り組んでいます。取り組みを見る

Android Studio プレビュー版の新機能

Android Studio 4.0 は、Stable チャンネルにリリース済みです。 こちらからダウンロードできます。

Android Studio 4.1 は現在、Canary チャンネルと Dev チャンネルにリリースされています。

各リリースでの重要な修正のリストを含め、リリースに関する最新情報については、リリース アップデート情報もご覧ください。

プレビュー版 Android Studio の使用で問題が発生した場合は、お知らせください。ご提出いただいたバグレポートは、Android Studio の改善に役立たせていただきます。

Android Studio 4.2

v3 と v4 の署名のサポート

Android Gradle プラグイン 4.2 では、v3 と v4 の APK 署名方式がサポートされるようになりました。ビルドでこれらの形式のいずれかまたは両方を有効にするには、モジュール レベルの build.gradle または build.gradle.kts ファイルに次のプロパティを追加します。

Kotlin

// build.gradle.kts

android {
   ...
   signingConfigs {
      config {
          ...
          enableV3Signing(true)
          enableV4Signing(true)
      }
   }
}

Groovy

// build.gradle

android {
  ...
  signingConfigs {
    config {
        ...
        enableV3Signing true
        enableV4Signing true
    }
  }
}

v3 と v4 の署名には次のようなメリットがあります。

  • APK v3 署名では、鍵のローテーションを使用して、鍵の紛失の影響を最小限に抑えることができます。

  • APK v4 署名を使用すると、Android 11 で ADB の増分 APK インストールを使用して、サイズの大きな APK を迅速にデプロイできます。この新しいフラグでは、デプロイ プロセスで APK 署名の手順が考慮されます。

Jetpack Compose のサポート

Jetpack Compose ツールキットは、アプリの UI をビルドする最新の方法を提供します。 また、このツールキットにより、Kotlin の利点をあますところなく活用できるようになります。たとえば、Java と完全に相互運用可能である、簡潔で自然なコードを作成できます。

Jetpack Compose を使用して最適な開発を行うには、Android Studio 4.2 の最新バージョンを使用する必要があります。これにより、Android Studio を使用して Jetpack Compose でアプリを開発する際に、新しいプロジェクト テンプレートや Compose UI をすぐにプレビューできるなど、スマート エディタの機能を活用できます。

詳細については、Jetpack Compose の概要をご覧ください。

4.2 における新しい Jetpack Compose ツールのサポート

Android Studio では、Jetpack Compose を使用するアプリのプレビューとテストに関するサポートが追加されました。

Compose のプレビュー

@Preview メソッドで次のパラメータを使用できるようになりました。

  • showBackground: プレビューの背景をオンまたはオフにします。
  • backgroundColor: プレビュー サーフェスでのみ使用される色を設定します。
  • uiMode: この新しいパラメータには Configuration.UI_* 定数のいずれも指定可能で、プレビューの動作を変更できます。たとえば、テーマの反応を確認するために夜間モードに設定することができます。

インタラクティブ プレビュー

このモードでは、UI コンポーネントを操作したりクリックしたりして、状態がどのように変化するかを確認できます。UI の反応に関するフィードバックがすぐに得られ、アニメーションを迅速にプレビューできます。このモードを有効にするには、インタラクティブ アイコン をクリックします。プレビューのモードが切り替わります。

停止するには、上部のツールバーの [Stop Interactive Preview] をクリックします。

デバイスへのデプロイ

この機能を使用して、UI のスニペットをデバイスにデプロイします。アプリケーション全体を起動しなくても、デバイスでコードの小さな部分をテストできるようになります。

@Preview アノテーションの横、またはプレビューの上部にある「デバイスへのデプロイ」アイコン をクリックすると、Android Studio がその @Preview を接続済みのデバイスまたはエミュレータにデプロイします。

プレビューの Data Sources API

新しい Data Sources API を使用すると、データからプレビューを生成できます。既存のデータのリスト、またはテーマのリストがある場合、この API を使用すると、@Preview メソッドにパラメータとして挿入できます。

class HelloWorldProvider :
   CollectionPreviewParameterProvider<String>(
       listOf("Hello World", "Привет мир", "Olá Mundo", "Hola Mundo"))

@Preview
@Composable
fun HelloWorldPreview(
   @PreviewParameter(HelloWorldProvider::class) text: String
) {
   MaterialTheme {
       Text(text = text)
   }
}

上記の機能を有効にするには、モジュールの build.gradle に次の設定を含める必要があります。

  android {
  …
  buildFeatures {
    compose true
  }
  composeOptions {
     kotlinCompilerExtensionVersion = "0.1.0-dev13"
     kotlinCompilerVersion = "1.3.70-dev-withExperimentalGoogleExtensions-20200424"
   }
}

Compose のプレビューに関する既知の問題

現在、androidx.ui.foundation.Dialog は Compose のプレビューではサポートされていません。

インストルメンテーション テストの改善

Android Studio 4.2 Canary 1 以降では、複数のデバイスで並行してインストルメンテーション テストを実行し、専用のインストルメンテーション テスト結果パネルを使用して調査できるようになりました。このパネルを使用すると、テストが失敗した原因が API レベルとハードウェアのどちらのプロパティにあるのかを判断できます。

インストルメンテーション テスト パネル

さまざまな API レベルとフォーム ファクタでアプリをテストすることは、すべてのユーザーがアプリを快適に利用できるようにするための最適な方法の一つです。

この機能を利用する方法は次のとおりです。

  1. 対象デバイスのプルダウン メニュー(IDE の上部中央)で [Modify Device Set] を選択します。

    対象デバイスのプルダウン

  2. 対象デバイスを選択し、[OK] をクリックします。

    [Modify Device Set] ダイアログ

  3. 対象デバイスのプルダウン メニューで [Multiple Devices] を選択し、テストを実行します。

    対象デバイスのプルダウンから [Multiple Devices] を選択します

[Run] パネルでテスト結果を表示するには、[View] > [Tool Windows] > [Run] に移動します。

新しいテスト結果パネルでは、ステータス、デバイス、API レベルでテスト結果をフィルタリングできます。また、ヘッダーをクリックして各列を並べ替えることもできます。個々のテストをクリックすると、デバイスごとにログとデバイス情報を個別に表示できます。

Android Studio 4.1

このセクションでは、Android Studio 4.1 の新機能や変更内容の概要について説明します。

システム トレース UI: より簡単な選択、新しい分析タブ、フレーム レンダリング データの増加

Android Studio プロファイラのシステム トレース UI では、次の点が改善されています。

  • ボックス選択: [Threads] セクションでは、マウスをドラッグして長方形領域のボックス選択を行えるようになりました。右上の [Zoom to Selection] ボタンをクリックして(または M キーボード ショートカットを使用して)ズームできます。隣同士にある同様のスレッドをドラッグ&ドロップすると、複数のスレッドを選択してすべてを一度に調査できます。たとえば、複数のワーカー スレッドで分析を実行できます。

  • [Summary] タブ: [Analysis] パネルの新しい [Summary] タブには次の項目が表示されます。

    • 特定のイベントのすべての発生に関する集計データ(発生回数や最小 / 最大期間など)。
    • 選択した発生に関するトレース イベントの統計情報。
    • スレッドの状態分布に関するデータ。
    • 選択したトレース イベントのうち最も実行時間の長い発生。

    別の発生に移動するには、表から別の行を選択します。

  • [Display] のデータ: [Display] セクションでは、SurfaceFlingerVSYNC の新しいタイムラインを使用して、アプリの UI におけるレンダリングの問題を調査できます。

システム トレースの記録に関する基本的な使用方法については、CPU Profiler を使用して CPU アクティビティを検査するトレースを記録するをご覧ください。

スタンドアロン プロファイラの提供

メインの Android Studio ウィンドウとは別のウィンドウで Android Studio プロファイラにアクセスできるようになりました。

スタンドアロン プロファイラを実行するには、次の手順を行います。

  1. システムで Android Studio が実行中でないことを確認します。
  2. インストール ディレクトリに移動し、bin ディレクトリに移動します。

    Windows / Linux: <studio-installation-folder>/bin

    macOS: <studio-installation-folder>/Contents/bin

  3. OS に応じて、profiler.exe または profiler.sh を実行します。Android Studio のスプラッシュ画面が表示されます。

    スプラッシュ画面が消えると、プロファイラ ウィンドウが開きます。

  4. Android Emulator を起動するか Android デバイスに接続して、ホーム画面が読み込まれるまで待ちます。コマンドラインからエミュレータを実行するには、コマンドラインからのエミュレータの起動をご覧ください。Android Studio からエミュレータを起動する場合は、エミュレータの起動後に Android Studio を閉じてください。

    スタンドアロン プロファイラのメニューで ボタンをクリックすると、接続されているデバイスとエミュレータがすべて表示されます。

    例として、エミュレータで Google マップを開きます。プルダウンからエミュレータを選択し、com.google.android.apps.maps (...) を選択して、新しいプロファイリング セッションを作成します。プロファイリング セッションが開始されます。

地図を操作すると、タッチイベントと CPU 使用率がプロファイラに表示されます。CPU、メモリ、ネットワーク、エネルギーのグラフをクリックすると、詳細が表示されます。

ボタンをクリックして、プロファイリング セッションを終了します。

これで、プロファイラを使用して、アプリのパフォーマンス特性を調査できるようになりました。詳しくは、アプリ パフォーマンスをプロファイリングするをご覧ください。

マテリアル デザイン コンポーネント: 新しいプロジェクト テンプレートのテーマとスタイルの更新

アニメーション: 新しいマテリアル デザインのプロパティを使用して Android Studio でプロジェクトを作成します。

[Create New Project] ダイアログの Android Studio テンプレートはマテリアル デザイン コンポーネント(MDC)を使用するようになりました。テーマとスタイルに関するガイドラインの更新版をデフォルトで遵守しています。更新の内容は次のとおりです。

  • MDC: プロジェクトは build.gradle.com.google.android.material:material に依存します。ベースアプリのテーマは Theme.MaterialComponents.* の親を使用し、MDC の更新された色と「on」属性をオーバーライドします。
  • カラーリソース: colors.xml のカラーリソースではリテラル名を使用します(たとえば、colorPrimary ではなく purple_500 を使用します)。
  • テーマリソース: テーマリソースは(styles.xml ではなく)themes.xml に含まれており、Theme.<ApplicationName> の名前を使用します。
  • ダークテーマ: ベースアプリのテーマは DayNight の親を使用し、res/valuesres/values-night に分かれています。
  • テーマ属性: ハードコードされた色を避けるため、カラーリソースはレイアウトとスタイルでテーマ属性として参照されます(例: ?attr/colorPrimary)。

Canary 9 における IDE 構成ディレクトリの変更

Canary 9 リリースでは、ユーザー構成ディレクトリの場所が次のように変更されました。

Windows

構文: %APPDATA%\Google\<product><version>

例: C:\Users\YourUserName\AppData\Roaming\Google\AndroidStudioPreview4.1

macOS

構文: ~/Library/Application Support/Google/<product><version>

例: ~/Library/Application Support/Google/AndroidStudioPreview4.1

Linux

構文: ~/.config/Google/<product><version>

例: ~/.config/Google/AndroidStudioPreview4.1

この新しいディレクトリの場所は、Android Studio の基盤となる IDE である IntelliJ IDEA の最近のアップデートと一致しています。

Dagger のナビゲーションのサポート

Dagger のコンシューマとプロバイダに移動するための IDE のガター アクション

Android Studio では、新しいガター アクションを用意し、[Find Usages] ウィンドウでのサポートを拡張することで、Dagger 関連のコード間を簡単に移動できるようにしています。

  • 新しいガター アクション: Dagger を使用するプロジェクトの場合、IDE には、Dagger のアノテーションが付いたコード間を移動するためのガター アクションが用意されています。たとえば、特定のタイプを使用するメソッドの横にある ガター アクションをクリックすると、そのタイプのプロバイダに移動します。反対に、 ガター アクションをクリックすると、そのタイプが依存関係として使用されている箇所に移動します。

  • [Find Usages] ノード: 特定のタイプのプロバイダで [Find Usages] を呼び出すと、[Find] ウィンドウにはそのタイプのコンシューマを一覧表示した [Dependency consumer(s)] ノードが表示されるようになりました。反対に、Dagger によって挿入された依存関係のコンシューマでこのアクションを呼び出すと、[Find] ウィンドウにはその依存関係のプロバイダが表示されます。

Android Studio で Android Emulator を直接実行する

Android Studio で Android Emulator を直接実行できるようになりました。この機能を使用すると、画面のスペースを節約し、ホットキーを使用してエミュレータとエディタ ウィンドウ間をすばやく移動し、IDE とエミュレータ ワークフローを 1 つのアプリケーション ウィンドウ内で整列できます。

Android Studio のツール ウィンドウ内にエミュレータが起動します。

Android Studio でエミュレータを実行するには、Android Studio 4.1 とバージョン 30.0.10 以降の Android Emulator を使用していることを確認してから、次の手順を行います。

  1. [File] > [Settings] > [Tools] > [Emulator](または macOS では [Android Studio] > [Preferences] > [Tools] > [Emulator])をクリックし、ツール ウィンドウで [Launch] を選択して、[OK] をクリックします。
  2. エミュレータ ウィンドウが自動的に表示されない場合は、[View] > [Tool Windows] > [Emulator] をクリックして開きます。
  3. AVD Manager を使用するか、アプリの実行時にターゲットに設定することで、仮想デバイスを起動します。

制限事項

現時点では、エミュレータがツール ウィンドウで実行されている場合、エミュレータの拡張コントロールは使用できません。開発ワークフローが拡張コントロールに大きく依存している場合は、引き続き Android Emulator をスタンドアロン アプリケーションとして使用してください。また、Android TV や折りたたみ式デバイスなどの特定の仮想デバイスは、特別な UI の要件があったり、拡張コントロールに重要な機能があったりするため、Android Studio で実行できません。

Database Inspector

Android Studio 4.1 Canary 6 以降では、新しい Database Inspector を使用してアプリのデータベースを検査、クエリ、変更できます。たとえば、実行中のアプリをデバッグするには、データベース内の値を変更し、その変更をデバイス上でテストします。

表の値を変更し、実行中のアプリでその変更を確認する

まず、API レベル 26 以上が搭載されているデバイスにアプリをデプロイし、メニューバーから [View] > [Tool Windows] > [Database Inspector] を選択します。

[Database Inspector] ウィンドウでアプリのプロセスが自動的に選択されない場合は、プルダウン メニューから選択します。

表の検査と変更

[Databases] パネルでは、アプリのデータベースが表示され、データベース ノードを展開すると表が表示されます。表をダブルクリックすると、以下のスクリーンショットのように、Inspector では右側の別のタブに表が表示されます。そこでは、デバイスでのアプリの使用中に、データの検査、列の並べ替え、値の変更ができます。

表のセルの値を変更するには、セルをダブルクリックして値を変更し、Enter キーを押します。Room 永続ライブラリを使用して、(LiveData などによって)データベースを監視している場合、これらの変更は実行中のアプリにすぐに表示されます。そうでない場合は、アプリのデータベースのクエリを更新して変更内容を確認する必要がある場合があります。

アプリのデータベースの検査、クエリ、変更

アプリでデータベースが更新された際に、それらの更新を Inspector ウィンドウに自動的に表示させたい場合は、[Live updates] チェックボックスをオンにします。ただし、このオプションが有効であっても、Inspector の表は読み取り専用になるため、値の変更はできないことにご注意ください。

また、データを手動で更新するには、[Refresh Table] をクリックします。同様に、データベース スキーマに変更がある場合は、[Databases] パネルで [Refresh Schema] をクリックします。

データベースにクエリを実行する

データベースにクエリを実行するには、[Databases] パネルで [Open New Query tab] をクリックします。右側に [New Query] タブが開きます。アプリに複数のデータベースが含まれている場合は、タブウィンドウのプルダウン メニューで、クエリを実行するデータベースを選択します。テキスト フィールドで、SQLite クエリを指定し、[Run] をクリックします。Inspector がアプリのデータベースにクエリを実行し、次のように結果を返します。

データベースにクエリを実行する

Room 永続ライブラリを使用する場合、Android Studio では、@Query アノテーションで定義したクエリをすばやく実行するためのガター アクションも提供します。アプリが対応デバイスにデプロイされており、[Database Inspector] が IDE で開いている場合は、以下に示すように @Query アノテーションの横にある ボタンをクリックします。

Room Query アノテーションのガター アクション

Database Inspector で新しいタブが開き、クエリが実行され、結果が返されます。 クエリに :name のような名前付きバインド パラメータが含まれている場合、Android Studio では、クエリを実行する前に各パラメータの値がリクエストされます。

新しいデータベースと既存のデータベースを終了しないようにする

アプリがデータベースへの接続と切断を頻繁に行う場合、データベースを検査するのが難しくなることがあります。これは、データベースの検査、クエリ、変更を行うには、アプリがデータベースとの有効な接続を維持する必要があるためです。[Database Inspector] ウィンドウではアイコンを使用して、開いているデータベース()と閉じているデータベース()を識別できるようにしています。

これらのデータベースの検査をしやすくするため、[Keep database connections open] をクリックして、データベースへの新しい接続と既存の接続が終了するのを防ぐことができます。この動作が有効になっている場合、[Keep database connections open] ボタンは に変わります。

ネイティブ クラッシュ レポートのシンボリケーション

ネイティブ コードでクラッシュや ANR が発生すると、システムはスタック トレースを生成します。スタック トレースとは、クラッシュの時点までにプログラムで呼び出された、ネストされた関数のシーケンスのスナップショットです。このスナップショットは、ソース内の問題を特定して修正するのに役立ちますが、最初にシンボリケートして、マシンアドレスを人が読める形式の関数名に変換する必要があります。

アプリやゲームが C++ などのネイティブ コードを使用して開発されている場合、アプリのバージョンごとにデバッグ シンボル ファイルをアップロードできます。Play Console は、これらのデバッグ シンボル ファイルを使用してアプリのスタック トレースをシンボリケートし、クラッシュや ANR を分析しやすくします。

デバッグ シンボル ファイルをアップロードする方法

デバッグ シンボル ファイルをアップロードするには、Android Gradle プラグイン バージョン 4.1 以降を使用する必要があります。

デバッグ シンボル ファイルをアップロードする方法は、Android App Bundle または APK のどちらを使用してアプリをビルドするかによって異なります。

  • Android App Bundle を使用してアプリをビルドする場合: プロジェクトで Android App Bundle をビルドする場合、デバッグ シンボル ファイルを自動的に含めることができるため、ファイルを手動でアップロードする必要はありません。このファイルを含めるには、アプリの build.gradle ファイルに次の行を追加します。

    android.defaultConfig.ndk.debugSymbolLevel = 'FULL'
    
  • APK を使用してアプリをビルドする場合: プロジェクトで APK をビルドする場合、デバッグ シンボル ファイルは個別にビルドされます。アプリの build.gradle ファイルに次の行を追加します。

    android.defaultConfig.ndk.debugSymbolLevel = 'FULL'
    

    ビルドプロセスの一環として、Android Gradle プラグインは次のプロジェクトの場所にデバッグ シンボル ファイルを出力します。

    app/build/outputs/native-debug-symbols/variant-name/native-debug-symbols.zip
    

    このデバッグ シンボル ファイルを Play Console にアップロードします。

Native Memory Profiler

Android Studio の Memory Profiler に、Android 10 以降を搭載する物理デバイスにデプロイされるアプリ向けの Native Memory Profiler が追加されました。32 バイトのサンプルサイズを持つ Nativer Memory Profiler は、特定の期間のネイティブ コードのオブジェクトの割り当てと割り当て解除を追跡し、次の情報を提供します。

  • Allocations: 選択した期間中に malloc() または new 演算子によって割り当てられたオブジェクトの数。
  • Deallocations: 選択した期間中に free() または delete 演算子によって割り当て解除されたオブジェクトの数。
  • Allocations Size: 選択した期間中のすべての割り当ての合計サイズ(バイト単位)。
  • Deallocations Size: 選択した期間中のすべての解放されたメモリの合計サイズ(バイト単位)。
  • Total Count: [Allocations] 列の値から [Deallocations] 列の値を引いた値。
  • Remaining Size: [Allocations Size] 列の値から [Deallocations Size] 列の値を引いた値。

Native Memory Profiler

記録を開始するには、Memory Profiler ウィンドウの上部にある [Record native allocations] をクリックします。

[Record native allocations] ボタン

記録を完了する準備ができたら、[Stop recording] をクリックします。

NDK パスを設定する

モジュールの build.gradle ファイルの android.ndkPath プロパティを使用して、ローカルの NDK インストールのパスを設定できます。

android {
   ndkPath "your-custom-ndk-path"
}

このプロパティを android.ndkVersion プロパティと併用する場合、このパスには android.ndkVersion と同じバージョンの NDK ディレクトリが含まれている必要があります。

TensorFlow Lite モデルを使用する

ML Model Binding を使用すると、簡単に .tflite モデルファイルを直接インポートしてプロジェクトで使用できます。Android Studio では使いやすいクラスが作成されるため、モデルを実行する際のコードが減り、型の安全性が高まります。

サポートされているモデル

ML Model Binding の現在の実装では、画像分類モデルやスタイル転送モデルがサポートされています(ただし、メタデータで拡張されている場合)。今後、物体検知、画像セグメンテーション、テキスト分類など、他の問題領域にもサポートを拡大していく予定です。

TensorFlow Hub には、メタデータを含むさまざまな事前トレーニング済みのモデルが用意されています。また、TensorFlow Lite モデルにメタデータを追加するに記載されているように、TensorFlow Lite モデルにメタデータを自分で追加することもできます。

モデルファイルをインポートする

サポートされているモデルファイルをインポートする手順は次のとおりです。

  1. [File] メニューで [File] > [New] > [Other] > [TensorFlow Lite Model] を選択し、TensorFlow Lite モデルのインポート ダイアログを開きます。
  2. 以前にダウンロードまたは作成した .tflite モデルファイルを選択します。
  3. [Finish] をクリックします。

この操作により、モデルファイルがプロジェクトにインポートされ、ml/ フォルダに配置されます。ディレクトリが存在しない場合は、Android Studio によって作成されます。

TensorFlow Lite モデルをインポートする

モデルのメタデータと使用方法の表示

インポートしたモデルの詳細とアプリでの使用方法を確認するには、プロジェクト内のモデルファイルをダブルクリックして、モデルビューア ページを開きます。モデルビューア ページには、次の内容が表示されます。

  • Model: モデルの概要
  • Tensors: 入力テンソルと出力テンソルの説明
  • Sample code: アプリのモデルとのやり取りの例

mobilenet_v1_0.25_160_quantized.tflite を使用した例は次のとおりです。

TensorFlow Lite モデルビューアのスクリーンショット

この例で示されるように、Android Studio はモデルを操作するための MobilenetV1025160Quantized というクラスを作成します。

モデルにメタデータがない場合、この画面には最小限の情報しか表示されません。

既知の問題と回避策

  • 現在、画像分類とスタイル転送以外の問題領域に対する TensorFlow Lite モデルのサポートは制限されています。インポートは正常に機能しますが、一部のモデル入力やモデル出力は、わかりやすい型ではなく TensorBuffers で表されます。メタデータのないモデルの場合、モデルの入力と出力はすべて TensorBuffer になります。
  • 入力データ型と出力データ型が DataType.UINT8 または DataType.FLOAT32 と異なるモデルは、サポートされていません。

この機能はまだ開発中ですので、フィードバックをお送りいただくか、バグをご報告ください

デバッグビルドでのアサーション

デバッグ バージョンのアプリをデプロイする際、Java コード内のアサーションが有効になりました。Android ランタイムはランタイム時のアサーションの有効化(つまり -ea / -enableassertions フラグと同等のものを Java VM に渡すこと)をサポートしていないため、これまでアプリ内のアサーションは効果がありませんでした。

これからは、Android Gradle プラグイン 4.1.0-alpha01 以降でデバッグ バージョンのアプリをビルドしてデプロイすると、内蔵されたコンパイラ(D8)がコンパイル時のアサーションを有効にするようにコードを書き換えるため、アサーションのチェックが常に有効になります。

Apply Changes

アプリを反復開発する際の生産性を向上させるため、Android 11 デベロッパー プレビュー 3 以降を実行するデバイス向けの Apply Changes を次のように改良しました。

デプロイ速度の向上

アプリをインストールせずにデバイス上で変更をデプロイして永続化する方法を開発することにより、反復開発の速度の最適化に大きく投資しました。最初のデプロイ後に [Apply Code Changes] または [Apply Changes and Restart Activity] を使用して Android 11 デバイスにデプロイする処理は、速度が向上しています。

2 つのアクションの違いについては、Apply Changes をご覧ください。

追加のコード変更のサポート

Android 11 デベロッパー プレビュー 3 以降を実行するデバイスの場合、メソッドと static final のプリミティブ フィールドを追加してから、[Apply Code Changes] または [Apply Changes and Restart Activity] をクリックすることで、それらの変更を実行中のアプリにデプロイできるようになりました。

また、リソースを追加してから、[Apply Changes and Restart Activity] をクリックすることで、それらの変更を Android 11 デバイスで実行中のアプリにデプロイできるようになりました。

AAR から C / C++ の依存関係をエクスポートする

Android Gradle プラグイン 4.0 では、後述のように、AAR の依存関係にある [Prefab] パッケージをインポートする機能が追加されました。Canary 10、バージョン 4.1 以降では、Android ライブラリ プロジェクト向けに AAR 内の外部ネイティブ ビルドからライブラリをエクスポートできます。

ネイティブ ライブラリをエクスポートするには、ライブラリ プロジェクトの build.gradle ファイルの android ブロックに次の行を追加します。

buildFeatures {
    prefabPublishing true
}

prefab {
    mylibrary {
      headers "src/main/cpp/mylibrary/include"
    }

    myotherlibrary {
        headers "src/main/cpp/myotherlibrary/include"
    }
}

この例では、ndk-build または CMake 外部ネイティブ ビルドの mylibrary ライブラリと myotherlibrary ライブラリが、ビルドによって生成された AAR にパッケージ化され、それぞれが指定されたディレクトリから依存先にヘッダーをエクスポートします。

CMake で使用されるビルド済みの依存関係

Android Gradle プラグイン 4.0 以降を使用している場合、ビルド済みのネイティブ ライブラリのインポートに関する構成設定が変更されました。詳しくは、AGP リリースノートをご覧ください。

4.1 Preview に関する既知の問題

このセクションでは、Android Studio 4.1 Preview の現在判明している問題について説明します。

4.1 Canary 10 でパッチが機能しない

Android Studio 4.1 Canary 10 のパッチは現在機能しません。Android Studio 4.1 の新バージョンに更新するには、Android Studio をシャットダウンしてから最新のパッケージをダウンロードしてインストールします。

この問題は Android Studio 4.1 ベータ版 1 で修正されています。

Canary 9 で Kotlin プラグインが見つからない場合の回避策

Android Studio 4.1 Canary 9 では、アップグレード後に初めて Android Studio を起動すると、次のエラーが表示されることがあります。

missing essential plugin org.jetbrains.android

この問題は、以前のバージョンの Android Studio から設定をインポートするときに発生することがあります。これは通常、新しい IDE と互換性のない Kotlin プラグインがローカルにインストールされていることを意味します。

この問題を解決するには、次の場所から Kotlin ディレクトリを削除します。

Linux: ~/.local/share/Google/AndroidStudioPreview4.1

Windows: C:\Users\YourUserName\AppData\Roaming\Google\AndroidStudioPreview4.1

MacOS: ~/Library/Application Support/Google/AndroidStudioPreview4.1

現在、Canary 9 と互換性のある Kotlin プラグインは JetBrains から提供されていないため、Google は Canary 9 アップデートに独自の Kotlin プラグインをバンドルしています。そのため、Kotlin プラグインを手動でインストールする必要はありません。

CPU Profiler のタイムアウト エラー

[Sample Java Methods] 構成または [Trace Java Methods] 構成を選択すると、Android Studio の CPU Profiler で「記録が停止できませんでした」というエラーが発生する場合があります。多くの場合、特に idea.log ファイルに次のエラー メッセージが表示された場合、これはタイムアウト エラーです。

Wait for ART trace file timed out

タイムアウト エラーは、サンプリングされたメソッドよりもトレースされたメソッドに、短い記録よりも長い記録に影響を与える傾向があります。一時的な回避策として、短い記録を試して、エラーが消えるかどうかを確認することをおすすめします。

Profiler でタイムアウトの問題が発生した場合は、デバイスのメーカーやモデル、および idea.log と logcat の関連エントリを含むバグを報告してください。

IDE の Git バージョン管理エラー

Android Studio 4.1 Canary 1 の IDE では、Git バージョン管理での認証が必要なオペレーションが機能しません。

この問題を解決するには、Android Studio 4.1 Canary 2 にアップグレードしてください。