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

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

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

Android Studio に関する既知の問題

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

macOS Big Sur で Android Studio がフリーズする

macOS Big Sur を搭載したマシンでダイアログを開くと、Android Studio 4.1 がフリーズすることがあります。

この問題を回避するには、次のいずれかを行います。

  • Apple メニューに移動し、[システム環境設定] > [一般] の順に選択します。[書類を開くときはタブで開く] で [しない] を選択します。Android Studio を再起動します。
  • 現在ベータ版チャンネルで入手可能な Android Studio 4.2 にアップグレードします。

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 にアップグレードすることで解決できます。

実行、デバッグ、プロファイルの各ボタンがツールバーに見つからない

操作ボタンの [Run/Debug] グループをカスタマイズした場合([Settings] ウィンドウまたは [Preferences] ウィンドウの [Appearance & Behavior] > [Menus and Toolbars] にあるオプションを編集した場合など)、IDE を再起動すると、ツールバーから操作ボタンが消えることがあります。これは、Android Studio 4.0 がベースとしている IntelliJ バージョンの既知の問題です(問題 IDEA-228450 を参照)。

この問題を解決するには、これらのボタンに行ったカスタマイズを次のように元に戻します。

  1. [File] > [Settings](macOS の場合、[Android Studio] > [Preferences])を選択します。
  2. ウィンドウの左側で [Appearance & Behavior] > [Menus and Toolbars] に移動します。
  3. ウィンドウの右側で [Main Toolbar] > [Toolbar Run Actions] に移動し、[Run/Debug] を選択します。
  4. ウィンドウ上部近くにある元に戻すボタン をクリックし、[Restore Run/Debug] を選択します。
  5. [OK] をクリックします。見つからなかったボタンがツールバーに表示されます。

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

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

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

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

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

  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 の間でなんらかの同期が失われると発生します。この問題は JetBrainsiBus のサポートサイトにすでに報告されています。現在、この問題には 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.preferIPv6Addresses=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

デプロイ

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

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 をご覧ください。

Android Studio によりアプリが不適切に強制停止される

Android Studio 4.0.x または 4.1 を使用している場合、デバッグ可能アプリを閉じると、Android Studio によりそのアプリが不適切に強制停止されます。

この問題により、次のような好ましくない結果が生じる場合があります。

  • START_STICKY を使用して開始したサービスがスティッキーとして扱われない(問題 156855259)。
  • バックグラウンドで実行するようにスケジュールされているジョブとアラームがキャンセルされる(問題 165787618)。
  • 強制停止イベントが logcat に記録される(問題 168311418)。

Apply Changes

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

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

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

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

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

Apply Changes が ShellCommandUnresponsiveException で失敗する

Android Studio 4.1 以前で Apply Changes を使用すると、デバイスがどのような変更も受け付けない状態になる可能性があります。この問題が発生すると、Apply Changes が ShellCommandUnresponsiveException で失敗します。

これを回避するには、次の adb コマンドを実行します。

adb shell rm -fr /data/local/tmp/.studio

android:sharedUserId を使用していると変更を適用できない

アプリが次のいずれかの方法で構成されている場合、実行中のアプリにまだデプロイされていないクラスを変更しようとすると、Apply Changes が失敗します。

この問題により Apply Changes が失敗すると、次のメッセージが表示されます。

Changes were not applied. JVMTI error: UNKNOWN_JVMTI_ERROR

Android Studio 3.5 でこの問題を回避するには、実行アイコン 実行アイコン をクリックし、アプリを再デプロイして変更を反映します。

デバッグとテスト

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

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 をご覧ください。

プロファイラ

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

システム トレース UI のラベルが表示されない

スケーリング ファクタが 125% または 175% の Windows マシンで、スレッド アクティビティ タイムラインなど、特定のシステム トレース UI のラベルが表示されなくなる場合があります。この問題を回避するには、ディスプレイのスケーリング ファクタを 125% と 175% 以外の値に変更してください。

この問題は Android Studio 4.2 で修正されています。

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] をクリックします。

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

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

マニフェスト クラスがない

アプリのマニフェストでカスタム権限を定義している場合、Android Gradle プラグインは通常、カスタム権限を文字列定数として含む Manifest.java クラスを生成します。Android Gradle プラグインはこのクラスをアプリにパッケージ化するため、ランタイムにこれらの権限を簡単に参照できます。

現在、Android Gradle プラグイン 3.6.0 以上ではマニフェスト クラスが生成されません。このバージョンのプラグインでアプリをビルドし、そのアプリでマニフェスト クラスを参照すると、ClassNotFoundException 例外が発生することがあります。この問題を解決するには、以下のいずれかを行います。

  • カスタム権限を完全修飾名で参照します。次に例を示します。 "com.example.myapp.permission.DEADLY_ACTIVITY"
  • 次のように独自の定数を定義します。

    public final class CustomPermissions {
      public static final class permission {
        public static final String DEADLY_ACTIVITY="com.example.myapp.permission.DEADLY_ACTIVITY";
      }
    

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

JAR 署名(v1 スキーム)は、改行(CR)文字を含むファイル名をサポートしません(問題 63885809 をご覧ください)。

API の変更

Android Gradle プラグイン 3.0.0 以上で導入された API の変更により特定の機能が削除されるため、既存のビルドが失敗する恐れがあります。今後のプラグイン バージョンで、利用不可となった機能の代わりとなる新しい公開 API を導入する可能性があります。

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

新しいプラグインでは、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)
        }
    }
}

解決済みの既知の問題

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

Android Studio 4.1 で修正

  • 前のバージョンの IDE からメモリ設定を引き継ぐには再起動が必要: Android Studio を更新した後で、以前のバージョンの IDE から移行したメモリ設定を適用するには、Android Studio を再起動する必要があります。

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 がスキャンする場合、最初の共通ディレクトリの下にあるすべてのディレクトリがスキャンの対象となります。多数のディレクトリとファイルをスキャンすると、メモリ不足エラーを引き起こす可能性があります。

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