Android Studio と Android Gradle プラグインに関する既知の問題

このページでは、Android Studio Iguana と Android Gradle プラグイン 8.3.0 に関する既知の問題をトラッキングしています。ここに掲載されていない問題が発生した場合は、バグを報告してください。

プレビュー版へのアップグレード: Android Studio および Android Gradle プラグインの各リリースの目的は、安定性およびパフォーマンスの改善と新機能の追加です。近くリリースされる予定の機能を今すぐ試すには、Android Studio プレビュー版をダウンロードしインストールしてください。

Android Studio に関する既知の問題

このセクションでは、Android Studio の最新の安定版に関する既知の問題について説明します。

Firebase Assistant ウィンドウにエラー メッセージが表示される

Firebase Assistant ウィンドウ（メインメニューから [Tools] > [Firebase]）でエラー メッセージが表示された場合は、キャッシュを無効にしてから Android Studio を再起動してエラーを修正してください。

Compose ノードの中に Layout Inspector を使用して検査できないものがある

Layout Inspector の使用時に、検査できない Compose ノードがある場合、Compose バージョン 1.5.0-alpha04 で修正されたバグが原因と考えられます。この問題が発生した場合は、Compose バージョン 1.5.0-alpha04 以降にアップグレードしてください。

Compose プレビューをレンダリングするとエラーになる

Android Studio Chipmunk 以降、問題パネルに java.lang.NoSuchFieldError: view_tree_saved_state_registry_owner または java.lang.ClassNotFoundException: androidx.savedstate.R$id が表示されている場合は、モジュールに androidx.lifecycle:lifecycle-viewmodel-savedstate への debugImplementation の依存関係が含まれていることを確認してください。

問題パネルに java.lang.NoSuchFieldError: view_tree_lifecycle_owner が表示されている場合は、モジュールに androidx.lifecycle:lifecycle-runtime への debugImplementation の依存関係が含まれていることを確認してください。

問題パネルに java.lang.NoClassDefFoundError: Could not initialize class androidx.customview.poolingcontainer.PoolingContainer または java.lang.NoClassDefFoundError: androidx/customview/poolingcontainer/PoolingContainerListener が表示されている場合は、モジュールに androidx.customview:customview-poolingcontainer への debugImplementation の依存関係が含まれていることを確認してください。

鍵とキーストアに異なるパスワードを使用するとエラーになる

バージョン 4.2 以降、Android Studio は JDK 11 で動作するようになりました。このアップデートにより、署名鍵に関連する基本的な動作変更が発生します。

[Build] > [Generate Signed Bundle / APK] に移動し、App Bundle または APK のアプリ署名を構成しようとすると、鍵とキーストアに異なるパスワードを入力した場合に、次のエラーが発生する可能性があります。

Key was created with errors:
Warning: Different store and Key passwords not supported for PKCS12 Key stores

この問題を回避するには、鍵とキーストアの両方に同じパスワードを入力します。

バージョン 4.2 のインストール後に Android Studio が起動しない

Studio は、以前の .vmoptions をインポートして、JDK 11 で使用されているガベージ コレクタで動作するようにサニタイズしようとします。この処理が失敗すると、.vmoptions ファイルでカスタム VM オプションを設定した特定のユーザーについて、IDE が起動しないことがあります。

この問題を回避するには、.vmoptions でカスタム オプションをコメントアウト（「#」文字を使用）することをおすすめします。.vmoptions ファイルは次の場所にあります。

Windows

C:\Users\YourUserName\AppData\[Local|Roaming]\Google\AndroidStudio4.2\studio64.exe.vmoptions

macOS

~/Library/Application Support/Google/AndroidStudio4.2/studio.vmoptions

Linux

~/.config/Google/AndroidStudio4.2/studio64.vmoptions

この回避策を試しても Studio が起動しない場合は、後述のアップグレード後に Studio が起動しないをご覧ください。

Database Inspector を使用するアプリが Android 11 エミュレータでクラッシュする

Database Inspector を使用するアプリは、Android 11 エミュレータでの実行時にクラッシュすることがあります。その場合、logcat に次のようなエラーが表示されます。

 Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)

この問題を解決するには、[Tools] > [SDK Manager] に移動して、Android 11 エミュレータをバージョン 9 以降にアップグレードしてください。[SDK Platforms] タブで、[Show Package Details] チェックボックスをオンにし、Android 11 エミュレータのリビジョン 9 以降を選択します。

アップグレード後に Studio が起動しない

アップグレード後に Studio が起動しない場合は、前のバージョンの Android Studio からインポートされた無効な Android Studio 設定または互換性のないプラグインが原因の可能性があります。回避策として、Android Studio のバージョンとオペレーティング システムに応じて、以下のディレクトリを削除（バックアップする場合は名前を変更）してから、Android Studio を再起動してください。これにより、Android Studio がデフォルトの状態にリセットされ、サードパーティのプラグインはすべて削除されます。

Android Studio 4.1 以降の場合:

  • Windows: %APPDATA%\Google\AndroidStudio<version>
    例: C:\Users\your_user_name\AppData\Roaming\Google\AndroidStudio4.1

  • macOS: ~/Library/Application Support/Google/AndroidStudio<version>
    例: ~/Library/Application Support/Google/AndroidStudio4.1

  • Linux: ~/.config/Google/AndroidStudio<version> および ~/.local/share/Google/AndroidStudio<version>
    例: ~/.config/Google/AndroidStudio4.1 および ~/.local/share/Google/AndroidStudio4.1

Android Studio 4.0 以前の場合:

  • Windows: %HOMEPATH%\.AndroidStudio<version>\config
    例: C:\Users\your_user_name\.AndroidStudio3.6\config

  • macOS: ~/Library/Preferences/AndroidStudio<version>
    例: ~/Library/Preferences/AndroidStudio3.6

  • Linux: ~/.AndroidStudio<version>/config
    例: ~/.AndroidStudio3.6/config

なお、Android Studio の Canary リリースとベータ版リリースの場合、<version> は X.Y ではなく PreviewX.Y になります。たとえば、Android Studio 4.1 Canary ビルドは、リリース候補と安定版リリースが使用する AndroidStudio4.1 ディレクトリではなく、AndroidStudioPreview4.1 を使用します。

Kotlin マルチプラットフォーム プロジェクトでのコンパイルの問題

Kotlin MPP コードで、シンボルの欠落によるコンパイル エラーが発生する場合があります。 この問題は、Kotlin プラグインをバージョン 1.4 にアップグレードすることで解決できます。

Linux でのキーマッピングの競合

Linux では、一部のキーボード ショートカットが、デフォルトの Linux キーボード ショートカットや、KDE、GNOME などのよく使用されるウィンドウ マネージャのキーボード ショートカットと競合します。 このように競合するキーボード ショートカットは、Android Studio では正常に動作しないことがあります。

この問題の詳細（可能な回避策を含む）については、IntelliJ のバグトラッカーをご覧ください。

ChromeOS の UI テキストの文字が小さい

ChromeOS のテキストが、以前のリリースよりもはるかに小さく表示されることがあります。この問題を回避するには、次のようにします。

  1. [File] > [Settings] をクリックして [Settings] ウィンドウを開きます。
  2. [Appearance & Behavior] > [Appearance] に移動します。
  3. [Use custom font] を選択します。
  4. フォントサイズを拡大します。
  5. [Settings] ウィンドウで、[Editor] > [Font] に移動します。
  6. フォントサイズを拡大します。
  7. [OK] をクリックします。

コードの編集

このセクションでは、コードエディタに関連する既知の問題について説明します。

キーボード入力がフリーズする - Linux の「iBus」問題

Linux の iBus デーモンと Android Studio の間に干渉があることが確認されています。状況によっては、IDE でキーボードへの反応が止まり、ランダムな文字を入力し始めることがあります。このバグは、iBus と XLib + AWT の間でなんらかの同期が失われると発生します。この問題は JetBrains と iBus のサポートサイトにすでに報告されています。現在、この問題には 3 つの回避策があります。

  • 回避策 1: iBus を強制的に同期モードにします。Android Studio を起動する前に、コマンドラインで
    $ IBUS_ENABLE_SYNC_MODE=1 ibus-daemon -xrd
    を実行します。
  • 回避策 2: Android Studio で iBus 入力を無効にします。Android Studio でのみ iBus 入力を無効にするには、コマンドラインで次のコマンドを実行します。 
    $ XMODIFIERS= ./bin/studio.sh
    この回避策は、Android Studio の入力方法のみを無効にします。実行中の他のアプリでは無効にします。Android Studio の実行中に（ibus-daemon -rd を実行するなどして）デーモンを再起動すると、他のすべてのアプリケーションの入力方法は実質的に無効になり、セグメンテーション エラーにより Android Studio の JVM もクラッシュする可能性があります。
  • 回避策 3: ショートカットの割り当てを調べて、[Next input method] のショートカットとして Ctrl+Space が設定されていないことを確認します。このキーの組み合わせは、Android Studio のコード補完のショートカットでもあるためです。Ubuntu 14.04（Trusty）では Super+Space がデフォルトのショートカットですが、以前のバージョンの設定がまだ残っている可能性もあります。ショートカットの割り当てを確認するには、コマンドラインで ibus-setup を実行して [IBus Preferences] ウィンドウを開きます。 [Keyboard Shortcuts] の下にある [Next input method] を確認します。Ctrl+Space に設定されている場合は、Super+Space または別の任意のショートカットに変更します。

プロジェクト構成

このセクションでは、プロジェクト構成と Gradle 同期に関連する既知の問題について説明します。

Gradle の同期が失敗しました: パイプが無効です

この問題は、Gradle デーモンにより IPv6 ではなく IPv4 が使用されることで発生します。

  • 回避策 1: Linux では、~/.profile または ~/.bash_profile に次の行を挿入します。 
    export _JAVA_OPTIONS="-Djava.net.preferIPv6Addresses=true"
  • 回避策 2: Android Studio の vmoptions ファイルで、-Djava.net.preferIPv4Addresses=true の行を -Djava.net.preferIPv6Addresses=true に変更します。詳しくは、Networking IPv6 User Guide をご覧ください。

Gradle 同期または SDK Manager での「ピアが認証されていません」エラー

このエラーの根本原因は、$JAVA_HOME/jre/lib/certificates/cacerts に証明書がないことです。解決するには、次の手順を行います。

  • プロキシを介している場合は、直接接続してみてください。直接接続すると機能する場合は、keytool を使用して cacerts ファイルにプロキシ サーバーの証明書を追加することで、プロキシ経由で接続できる可能性があります。
  • 変更が加えられていない、サポート対象の JDK を再インストールします。ただし、/etc/ssl/certs/java/cacerts が空になるという、Ubuntu ユーザーに影響する既知の問題があります。この問題を回避するには、コマンドラインで
    sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure
    を実行します。

デプロイ

このセクションでは、接続デバイスへのアプリのデプロイに関連する既知の問題について説明します。

[Mac OS のみ] /System/Volumes/Data 下に保存されるプロジェクトでの Gradle ファイル監視機能に関する問題のため、増分更新が適用されない。

Gradle の問題 18149 は、Gradle バージョン 7.0 以上を必要とする Android Gradle プラグイン バージョン 7.0 以上に影響します。Gradle 7.0 以降では、ファイル監視機能がデフォルトで有効です。Mac OS 環境で、プロジェクトを /System/Volumes/Data 下に保存している場合、Gradle ファイル監視機能はファイルの変更を管理できません。このため、ビルドシステムはファイル変更を認識せず、その結果、APK は更新されません。ローカルの APK の状態はデバイス上と同じであるため、増分デプロイコードは何も実行しません。

この問題を回避するには、プロジェクトのディレクトリをユーザー ディレクトリ、つまり /Users/username 下に移動します。これで、Gradle ファイル監視機能からビルドシステムにファイル変更が適切に通知され、増分変更が正しく適用されるようになります。

macOS High Sierra の Android Emulator には HAXM が必要

macOS High Sierra（10.13）の Android Emulator では、macOS との互換性と安定性を高めるために HAXM 6.2.1 以降が必要です。ただし、macOS 10.13 には、HAXM などのカーネル拡張機能をインストールするためのより複雑なプロセスがあります。次のように、カーネル拡張機能自体のインストールを手動で許可する必要があります。

  1. まず、SDK Manager で HAXM 最新バージョンのインストールを試みます。
  2. macOS で、[システム環境設定] > [セキュリティとプライバシー] に移動します。

  3. 「開発元 "Intel Corporation Apps" のシステム ソフトウェアの読み込みがブロックされました」という警告が表示されたら、[許可] をクリックします。

詳細な情報と回避策については、Apple のウェブページと問題 62395878 をご覧ください。

Apply Changes

このセクションでは、Apply Changes に関連する既知の問題について説明します。

新しいアプリ名が適用されない

アプリの名前を変更してからその変更を適用しようとすると、変更した名前が反映されない場合があります。この問題を回避するには、実行アイコン 実行アイコン をクリックしてアプリを再デプロイし、変更を反映します。

Android ランタイムの問題によりエラーがスローされる

Android 8.0 または 8.1 を搭載したデバイスを使用している場合、特定の種類の変更を適用しようとすると「VERIFICATION_ERROR」メッセージが表示されることがあります（特に Kotlin を使用している場合）。このメッセージが表示されるのは Android ランタイムの問題が原因で、Android 9.0 以上では修正済みです。この問題により Apply Changes は失敗しますが、実行アイコン 実行アイコン を再度クリックすると変更を反映できます。ただし、デバイスを Android 9.0 以上にアップグレードすることをおすすめします。

デバッグとテスト

このセクションでは、アプリのデバッグとテストに関連する既知の問題について説明します。

Android Studio から JUnit テストを実行したときにクラスパスでリソースが見つからない

Java モジュール内に特定のリソース フォルダがある場合、IDE からテストを実行したときにそれらのリソースが見つかりません。コマンドラインから Gradle でテストを実行すると、正常に機能します。IDE から Gradle check タスクを実行しても機能します。詳しくは、問題 64887 をご覧ください。

この問題が発生する原因は、IntelliJ 13 ではクラスパスとして 1 つのフォルダのみが要求されることです。IntelliJ のビルダーではすべてのリソースがそのビルドフォルダにコピーされますが、Gradle ではそれらのリソースはコピーされません。

  • 回避策 1: 単体テストを実行する代わりに、IDE から Gradle check タスクを実行します。
  • 回避策 2: リソースをビルドフォルダに手動でコピーするように、ビルド スクリプトを更新します。詳しくは、コメント #13 をご覧ください。

JUnit テストを実行するとコードが 2 回コンパイルされることがある

新しいプロジェクトを作成すると、「起動前」の 2 つのステップ（Make と Gradle-aware Make）を含むテンプレートの JUnit 構成が作成される場合があります。この構成が、それ以降に作成されるすべての JUnit 実行構成に引き継がれます。

  • 現在のプロジェクトでこの問題を解決するには、[Run] > [Edit Configurations] をクリックし、デフォルトの JUnit 構成を変更して、Gradle-aware Make ステップのみが含まれるようにします。
  • 今後のすべてのプロジェクトについてこの問題を修正するには、[File] > [Close Project] をクリックします。ウェルカム画面が表示されます。次に、[Configure] > [Project Defaults] > [Run Configurations] をクリックし、JUnit 構成を変更して、Gradle-aware Make ステップのみが含まれるようにします。

テスト実行構成の一部が機能しない

テスト方法を右クリックしたときに表示される実行構成の一部が有効ではありません。具体的には、次の構成が有効ではありません。

  • Gradle 実行構成（アイコンとして Gradle ロゴが表示されるもの）が機能しません。
  • JUnit 実行構成（アイコンに緑色の Android マスコットがないもの）はインストルメンテーション テストに適用されず、ローカル JVM では実行できません。
特定のクラスやメソッドを右クリックするなど、特定のコンテキストで作成された実行構成も Android Studio に記憶されますが、それらがその後の異なる構成での実行に使用されることはありません。これを修正するには、[Run] > [Edit Configurations] をクリックし、誤って作成された構成を削除します。

ネイティブ コード デバッグ中の Java ブレークポイントの追加

ネイティブ コードのブレークポイントでアプリが一時停止しているとき、設定した新しい Java ブレークポイントが Auto デバッガと Dual デバッガにすぐに認識されないことがあります。この問題を回避するには、デバッグ セッションの開始前か、アプリが Java ブレークポイントで一時停止しているときに、Java ブレークポイントを追加してください。詳しくは、問題 229949 をご覧ください。

ネイティブ デバッガからのステップアウト

Auto デバッガまたは Dual デバッガを使用して Java とネイティブのコードをデバッグしているときに、Java コードからネイティブ関数にステップイン（たとえば、Java コード内のネイティブ関数を呼び出す行でデバッガが実行を一時停止したときにステップイン ボタン をクリックするなど）し、その後 Java コードに戻る際には、（ステップアウト ボタン やステップ オーバー ボタン ではなく）プログラムを再開ボタン をクリックしてください。それでもアプリのプロセスは一時停止しているため、[your-module-java] タブでプログラムを再開ボタン をクリックして再開してください。詳しくは、問題 224385 をご覧ください。

ライブラリの読み込み中にネイティブ デバッガがハングする

Android Studio 4.2 以降へのアップグレード後に初めてネイティブ デバッガを使用すると、Android デバイスからライブラリを読み込む際にネイティブ デバッガが応答を停止することがあります。この問題は、デバッガを停止して再起動しても引き続き発生します。この問題は、$USER/.lldb/module-cache/ で LLDB キャッシュを削除すると解決します。

ネイティブ デバッガがクラッシュし、「デバッガ プロセスが終了コード 127 で終了した」が表示される

このエラーは、ネイティブ デバッガの起動時に Linux ベースのプラットフォームで発生します。これは、ネイティブ デバッガに必要なライブラリの 1 つがローカル システムにインストールされていないことを示します。不足しているライブラリの名前は、idea.log ファイルにすでに出力されている可能性があります。出力されていない場合は、ターミナルを使用して Android Studio のインストール ディレクトリに移動し、bin/lldb/bin/LLDBFrontend --version コマンドラインを実行すると、不足しているライブラリを確認できます。一部の最新の Linux ディストリビューションはすでに ncurses6 にアップグレードされているため、一般に、不足しているライブラリは ncurses5 です。

プロファイラ

ここでは、プロファイラの既知の問題について説明します。

Native Memory Profiler: アプリの起動時にプロファイリングを使用できない

現在、Native Memory Profiler はアプリの起動時に使用できません。このオプションは、今後のリリースで提供される予定です。

回避策として、Perfetto スタンドアロン コマンドライン プロファイラを使用して、起動プロファイルをキャプチャできます。

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 の関連エントリを含めてバグを報告してください。

デバッグまたはプロファイル時の adb 例外

Platform Tools 29.0.3 を使用している場合、ネイティブ デバッグと Android Studio プロファイラが正常に動作せず、[Help] > [Show Log] を選択すると idea.log ファイルに「AdbCommandRejectedException」または「Failed to connect port」が表示される場合があります。Platform Tools を 29.0.4 以降にアップグレードすると、両方の問題が解決します。

Platform Tools をアップグレードする方法は次のとおりです。

  1. Android Studio で、[Tools] > [SDK Manager] をクリックするか SDK Manager ボタン をクリックして SDK Manager を開きます。

  2. [Android SDK Platform-Tools] の横にあるチェックボックスをクリックしてオンにします。ダウンロード アイコン が左側の列に表示されます。

  3. [Apply] または [OK] をクリックします。

プラグインによってビルド出力ウィンドウが機能しない

CMake シンプル ハイライタ プラグインを使用すると、[Build Output] ウィンドウにコンテンツが表示されません。ビルドは実行され、[Build Output] タブは表示されますが、出力されません（問題 #204791544）。

インストール順序が原因で起動しない

最新バージョンの Android Studio を以前のバージョンの前にインストールすると、以前のバージョンが起動しなくなることがあります。たとえば、Canary バージョンの Android Studio をインストールした後で、安定版をインストールして起動しようとすると、安定版が起動しないことがあります。このような場合は、安定版（古いバージョン）が起動するようキャッシュを削除する必要があります。macOS でキャッシュを削除するには、Library/ApplicationSupport/Google/AndroidStudioversion_number ディレクトリを削除します。Windows でキャッシュを削除するには、ディスク クリーンアップを使用します。

Compose で Espresso テスト レコーダーが機能しない

Espresso テスト レコーダーは、Compose を含むプロジェクトでは動作しません。Compose を含むプロジェクトの UI テストを作成するには、Compose レイアウトのテストをご覧ください。

Logcat のショートカットが英語以外のキーボードのレイアウトと競合する

英語以外のキーボード レイアウトを使用していると、デフォルトの Logcat キーボードのショートカットがそのレイアウトと競合し、Android Studio でテキストを編集する際に特定の文字を入力できなくなることがあります。この問題を回避するには、競合する Logcat のキーマップを削除するか、再マッピングします。Android Studio で Logcat のキーマップを編集するには、[Android Studio] > [Settings] > [Keymap] に移動し、キーマップのリストで「Logcat」を検索します。詳しくは、問題 #263475910 をご覧ください。

この問題は、Android Studio Electric Eel パッチ 1 で Logcat のショートカットを削除することで解決されます。

Android Gradle プラグインの既知の問題

このセクションでは、Android Gradle プラグインの最新の安定版に関する既知の問題について説明します。

動的機能のライブラリ依存関係がすべて lint チェックされるわけではない

アプリ モジュールから checkDependencies = true で lint を実行したとき、アプリ依存関係でもある場合を除き、動的機能のライブラリ依存関係はチェックされません（問題 #191977888）。回避策として、これらのライブラリで lint タスクを実行できます。

改行文字を含む名前の署名ファイル

JAR 署名（v1 スキーム）は、改行文字を含むファイル名をサポートしません（問題 #63885809）。

ビルド時のバリアント出力の変更が動作しない可能性

新しいプラグインでは、Variant API を使用してバリアント出力を操作することができません。ビルド時に APK 名を変更するといった単純なタスクについては、引き続き機能します。

// If you use each() to iterate through the variant objects,
// you need to start using all(). That's because each() iterates
// through only the objects that already exist during configuration time—
// but those object don't exist at configuration time with the new model.
// However, all() adapts to the new model by picking up object as they are
// added during execution.
android.applicationVariants.all { variant ->
    variant.outputs.all {
        outputFileName = "${variant.name}-${variant.versionName}.apk"
    }
}

ただし、outputFile オブジェクトへのアクセスが必要な複雑なタスクは機能しなくなりました。バリアント固有のタスクは、設定段階では生成されなくなったことが原因です。結果的に、プラグイン側では事前にすべての出力を把握できないものの、設定に要する時間は短縮されます。

manifestOutputFile の無効化

processManifest.manifestOutputFile() メソッドは利用できなくなったため、呼び出すと次のエラーが発生します。

A problem occurred configuring project ':myapp'.
   Could not get unknown property 'manifestOutputFile' for task
   ':myapp:processDebugManifest' of type
   com.android.build.gradle.tasks.ProcessManifest.

manifestOutputFile() を呼び出してバリアントごとのマニフェスト ファイルを取得する代わりに、processManifest.manifestOutputDirectory() を呼び出すことで、生成されたマニフェストすべてを含むディレクトリのパスを取得できます。これにより、マニフェストを特定してロジックを適用できます。次のサンプルでは、マニフェストでバージョン コードを動的に変更しています。

android.applicationVariants.all { variant ->
    variant.outputs.all { output ->
        output.processManifest.doLast {
            // Stores the path to the maifest.
            String manifestPath = "$manifestOutputDirectory/AndroidManifest.xml"
            // Stores the contents of the manifest.
            def manifestContent = file(manifestPath).getText()
            // Changes the version code in the stored text.
            manifestContent = manifestContent.replace('android:versionCode="1"',
                    String.format('android:versionCode="%s"', generatedCode))
            // Overwrites the manifest with the new text.
            file(manifestPath).write(manifestContent)
        }
    }
}

AGP 7.3.0 AIDL サポートと Kotlin 1.7.x に関する問題

Kotlin 1.7.x で KAPT と AGP 7.3.0 を使用すると、特定のビルド バリアントの AIDL ソースセットが削除されます。main/、ビルドタイプ、プロダクト フレーバー、プロダクト フレーバーの組み合わせなど、他の AIDL ソースセットは引き続き使用できます。バリアント固有の AIDL ソースセットを使用する必要がある場合は、引き続き Kotlin 1.6.21 をご使用ください。

解決済みの既知の問題

このセクションでは、最近のリリースで解決された既知の問題について説明します。下記の問題が発生した場合は、最新の安定版またはプレビュー版に Android Studio を更新する必要があります。

Android Studio 2021.1.1 で修正

  • lint 出力がない: lint タスクが UP-TO-DATE の場合に lint テキストが stdout に出力されません（問題 #191897708）。この問題は AGP 7.1.0-alpha05 で修正されました。
  • Hilt プラグインを使用するアプリ プロジェクトの単体テストに関する問題: 単体テストのクラスパスには、インストルメント化されていないアプリクラスが含まれます。つまり、Hilt は、単体テストの実行時に依存関係の挿入を処理するためにアプリクラスをインストルメント化しません（問題 #213534628）。この問題は AGP 7.1.1 で修正されました。

Android Studio 2020.3.1 で修正

  • Kotlin プロジェクトでの lint 例外: checkDependencies = true を設定している Kotlin プロジェクトでは、null ポインタ例外やエラーが発生することがあります（issue #158777858）。

Android Studio 4.2 で修正

  • macOS Big Sur で IDE がフリーズする: ダイアログを開くと、Android Studio 4.1 がフリーズすることがあります。

Android Studio 4.1 で修正

  • 前のバージョンの IDE からメモリ設定を引き継ぐには再起動が必要: Android Studio を更新した後で、以前のバージョンの IDE から移行したメモリ設定を適用するには、Android Studio を再起動する必要があります。
  • カスタム権限の文字列を含むマニフェスト クラスがデフォルトで生成されなくなった: クラスを生成する場合は、android.generateManifestClass = true を設定します。

Android Studio 3.6 で修正

  • LineageOS での APK インストール エラー: 特定のバージョンの LineageOS または CyanogenMod を搭載するデバイスでは、アプリのデプロイが失敗し、INSTALL_PARSE_FAILED_NOT_APK 例外がスローされる場合があります。

    Android Studio 3.6 Beta 1 以降では、LineageOS や CyanogenMod デバイスにアプリをデプロイする場合は、完全インストールを実行することでこの例外に対処しています。これにより、デプロイ時間が長くなる可能性があります。

Android Studio 3.5.2 で修正

  • XML コードスタイルの破損: XML コードを編集する際に、メニューバーから [Code] > [Reformat Code] を選択すると、誤ったコードスタイルが適用される場合があります。

Android Studio 3.3.1 で修正

  • C++ ベースのプロジェクトをスキャンする場合のメモリ不足エラー: 同じドライブの複数の場所に C++ コードがあるプロジェクトを Gradle がスキャンする場合、最初の共通ディレクトリの下にあるすべてのディレクトリがスキャンの対象となります。多数のディレクトリとファイルをスキャンすると、メモリ不足エラーを引き起こす可能性があります。

    この問題について詳しくは、問題に関連するバグをご覧ください。