It's happening now, watch the livestream.

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

このページには、Android Studio と Android Gradle プラグインに関する最新の既知の問題を掲載します。ここに記載されていない問題を報告するには、バグを報告するをご覧ください。

Android Studio に関する既知の問題

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

    プロジェクトでこの動作が発生する場合は、Android Studio 3.2 を使用することをおすすめします。この問題について詳しくは、問題に関連するバグをご覧ください。

  • Espresso テスト レコーダーのコンパイル エラー: Espresso テスト レコーダーを使用するプロジェクトをビルドしようとすると、Execution failed for task ':app:compileDebugAndroidTestJavaWithJavac' というメッセージが表示されてコンパイルが失敗します。この問題は、バージョン 3.0.2 以上の espresso-core 依存関係を使用しているバージョン 3.2 未満の Android Studio に影響を与えます。この問題は Android Studio 3.2 以上には影響を与えません。

    Android Studio 3.1 以下を使用している場合は、バージョン 3.0.2 未満の espresso-core 依存関係を設定するか、別の rules 依存関係を追加することで、この問題を回避できます。詳しくは、Espresso の設定手順をご覧ください。

  • Windows マシンで @RestrictTo lint チェックが機能しない: Android Studio 2.3 では、Windows マシンで @RestrictTo lint チェックを実行した場合にエラー メッセージが正しく出力されません。

  • 名前にかっこが含まれる仮想デバイスを実行できない: Android Studio バージョン 2.2 では、仮想デバイスの名前にかっこを含めることができますが(実際に、Android TV などの一部のデバイスでは、自動的に名前にかっこが含まれます)、名前にかっこを使用している仮想デバイスを実行できません。この問題を回避するには、仮想デバイスを編集して、名前から「(」と「)」の文字を削除してください。

    この問題は Android Studio 2.3 で解決されました。

  • Instant Run が Jack に対応していない: 現在、Instant Run は Jack コンパイラと互換性がありません。そのため、Jack コンパイラを使用するプロジェクトでは無効になります(Jack コンパイラの使用は、Java 8 言語の機能を使用している場合にのみ必要になります)。

  • アプリのクラスファイルを必要とするツールやライブラリが Jack に対応していない: 現在、.class ファイルを読み込むさまざまなツール(JaCoCo、Mockito、一部の lint チェックなど)が Jack コンパイラに対応していません。

  • プロジェクトが Linux 上の NTFS にある場合、Gradle ビルドが出力フォルダを削除できない: Windows マシンの場合、NTFS のファイルロック動作のために、Android Studio はインデックス登録の前にクラスの JAR ファイルを別の場所に自動的にコピーすることで、以降の Gradle ビルドがビルドやツリーを削除したり、変更を加えたりできるようにします。詳しくは、問題 202297 をご覧ください。この動作は、Linux または OSX マシンで NTFS を使用している場合は有効になりませんが、以下の行のコメントを解除することで、idea.properties ファイルで手動で指定することができます。

    idea.jars.nocopy=false

  • Mac のパフォーマンス: Mac では、Studio 2.2 にバンドルされている OpenJDK 1.8.0_76 にいくつかの問題があります。問題 203412IDEA-144261 に記述されているように、解像度がスケーリングされている外部の 4K モニタを使用すると、IDE が反応しなくなるほど、レンダリングのパフォーマンスに悪影響を与えることがありあます。また、問題 223749IDEA-158500 で報告されているとおり、Mac 10.12(Sierra)ではスクロールがかなり影響を受けます。

  • 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 を再インストールします。Ubuntu ユーザーに影響する既知の問題があり、その結果として空の /etc/ssl/certs/java/cacerts が発生します。この問題を回避するには、コマンドラインで以下を実行します。
      $ sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure
  • 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] をクリックし、Gradle-aware Make タスクのみが含まれるようにデフォルトの JUnit 構成を変更します。
    • 今後のすべてのプロジェクトについてこの問題を修正するには、[File] > [Close Project] をクリックします。ウェルカム画面が表示されます。[Configure] > [Project Defaults] > [Run Configurations] をクリックし、Gradle-aware Make タスクのみが含まれるように JUnit 構成を変更します。
  • 一部のテスト実行構成が機能しない: テスト方法を右クリックしたときに表示される実行構成のうち、一部は有効ではありません。具体的には、次の構成が有効ではありません。

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

  • Linux と Awesome WM 3.4: Android Studio バージョン 0.8.3 以上は「Awesome WM」ウィンドウ マネージャー バージョン 3.4 と適切に連携しない場合があります。この問題を解決するには、Awesome WM バージョン 3.5 にアップグレードしてください。

  • キーボード入力がフリーズする - 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 の入力方法のみを無効にします。実行する可能性のあるその他のアプリケーションの入力は無効になりません。(ibus-daemon -rd を実行するなどして)Android Studio の実行中にデーモンを再起動した場合、それ以外のアプリケーションの入力方法が実質的に無効になり、Android Studio の JVM もセグメンテーション エラーによりクラッシュする可能性がありますので、ご注意ください。
    • 回避策 3: ショートカットのバインディングを調べて、「次の入力」のショートカットとして Ctrl+Space が設定されていないことを確認します。これは、Ctrl+Space が Android Studio では「コード補完」のショートカットでもあるためです。Ubuntu 14.04(Trusty)では Super+Space がデフォルトのショートカットですが、以前のバージョンの設定がまだ残っている可能性もあります。ショートカットのバインディングを確認するには、コマンドラインで ibus-setup を実行して [IBus Preferences] ウィンドウを開きます。[Keyboard Shortcuts] の下にある [Next input method] を確認します。Ctrl+Space に設定されている場合は、Super+Space または別の任意のショートカットに変更します。
  • Ubuntu と JAyatana: JAyatana を使用すると、Java Swing アプリケーションを Ubuntu の Unity グラフィカル シェルのグローバル メニューに統合できます。場合によっては、Android Studio で Unity の NullPointerException が発生し、次のようなエラー メッセージが表示されることがあります。

    java.lang.NullPointerException
        at com.jarego.jayatana.swing.SwingGlobalMenu.getSwingGlobalMenuWindowController(SwingGlobalMenu.java:204)
        at com.jarego.jayatana.swing.SwingGlobalMenu.installLockParentGlobalMenu(SwingGlobalMenu.java:160)
        at ...
    詳しくは、問題 187179 をご覧ください。この問題があるため、Ubuntu の新しいバージョンでは、デフォルトで JAyatana が無効になっています。この問題が発生した場合は、2 つの回避策が考えられます(詳しくは、Stack Overflow のこちらの投稿をご覧ください)。

    • 回避策 1: Android Studio を実行するときに JAVA_TOOL_OPTIONS 環境変数の設定を解除します。
    • 回避策 2: JAyatana をアンインストールします。
  • ネイティブ コードのデバッグ中の Java ブレークポイントの追加: Auto デバッガと Dual デバッガでは、ネイティブ コードのブレークポイントでアプリが一時停止しているときに、設定された新しい Java ブレークポイントをすぐに認識できない場合があります。この問題を回避するには、デバッグ セッションの開始前か、アプリが Java ブレークポイントで一時停止しているときに、Java ブレークポイントを追加してください。詳しくは、問題 229949 をご覧ください。

  • ネイティブ デバッガのステップアウト: Auto または Dual デバッガを使用して Java コードとネイティブ コードをデバッグする場合、Java コードからネイティブ関数にステップインして(たとえば、ネイティブ関数を呼び出す Java コード内の行でデバッガが実行を一時停止し、ユーザーが [Step Into] をクリックする場合)、Java コードに戻りたい場合は、([Step Out] または [Step Over] ではなく)[Resume Program] をクリックしてください。アプリのプロセスはまだ一時停止しているため、[your-module-java] タブで [Resume Program] をクリックして再開します。詳しくは、問題 224385 をご覧ください。

  • 不要なレンダリング例外: 具体的には「The following classes could not be found: - android.support.v7.internal.app.WindowDecorActionBar.」というレンダリング エラー メッセージが表示されます。エラー メッセージが表示されても、レイアウト プレビューは正確なため、このメッセージは無視してかまいません。

    この問題は Android Studio 2.0 プレビュー版で修正されています。

  • 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 Gradle プラグインの既知の問題

  • Gradle 4.6 以上でのオンデマンドの構成: Android Gradle プラグイン 3.0.x または 3.1.x と Gradle 4.6 以上を使用している場合は、予期しないビルドエラーを避けるためにオンデマンドの構成を無効にする必要があります(Android Gradle プラグイン 3.2.0 以上では、オンデマンドの構成を無効にするための対応策は必要ありません)。

    次のように、gradle.properties ファイルでオンデマンドの構成を無効にします。

    org.gradle.configureondemand=false
        

    Android Studio の設定でオンデマンドの構成を無効にするには、[File] > [Settings](Mac の場合は [Android Studio] > [Preferences])を選択し、左ペインで [Compiler] カテゴリを選択して、[Configure on demand] チェックボックスをオフにします。

    Android Studio 3.2 Beta 1 以上では、オンデマンドの構成を有効にするオプションは削除されています。

  • Android プラグイン 3.0.0 を複数回読み込んだ場合のプロジェクト同期エラー: 1 回のビルドで Android プラグインを複数回読み込むと、プロジェクト同期エラーが発生します。このエラーは、buildscript のクラスパスに Android プラグインが含まれているサブプロジェクトが複数存在すると、発生する場合があります。これは Gradle の新たなバリアント識別による依存関係管理に伴う制限です。この機能はまだ、複数の異なるクラスローダで属性が一致する状況に対処できません。Android プラグイン 3.0.0 以下を使用している場合は、プラグインを Android プラグイン 3.1.0 以上にアップグレードするか、以下の手順に沿って、この問題を解決してください。

    • マルチモジュール ビルド: 次のように、Android プラグインを最上位の build.gradle ファイルのビルド クラスパスのみに追加するようにします。

      // Additionally, make sure that you don't wrap this in a
          // subprojects block.
          buildscript {
              ...
              dependencies {
                  classpath 'com.android.tools.build:gradle:3.4.2'
              }
          }
          
    • コンポジット ビルド: メイン プロジェクトと Android プラグインを使用するそれぞれの個別のプロジェクトで、buildscript のクラスパスが同一であることを確認します。buildscript ブロックに追加するクラスパスの順序も同一である必要があります。たとえば、メイン プロジェクトの build.gradle ファイルに含まれる、以下のクラスパス依存関係を考えます。

      buildscript {
              ...
              dependencies {
                  classpath "com.android.tools.build:gradle:3.4.2"
                  classpath "me.tatarka:gradle-retrolambda:3.7.0"
              }
          }
          

      次に、コンポジット ビルドに含まれる別のプロジェクトの build.gradle ファイルと見比べます。

      buildscript {
              dependencies {
                  // Note that the order of plugins differs from that
                  // of the main project's build.gradle file. This results
                  // in a build error because Gradle registers this as a
                  // different classloader.
                  classpath "me.tatarka:gradle-retrolambda:3.7.0"
                  classpath "com.android.tools.build:gradle:3.4.2"
              }
          }
          
  • Firebase プラグイン バージョン 1.1.0 での Guava 依存関係の不一致によるエラー: Firebase プラグイン バージョン 1.1.0 によって Guava 依存関係の不一致が生じ、結果的に次のエラーが発生することがあります。

        Error:Execution failed for task ':app:packageInstantRunResourcesDebug'.
        com.google.common.util.concurrent.MoreExecutors.directExecutor()Ljava/util/concurrent/Executor;
        
    このビルドエラーを回避するには、プロジェクト レベルの build.gradle ファイルの dependencies ブロックに以下を追加します。

    dependencies {
            classpath ('com.google.firebase:firebase-plugins:1.1.0') {
                        exclude group: 'com.google.guava', module: 'guava-jdk5'
            }
            ...
        }
        

    詳しくは、問題 #63180002 をご覧ください。

  • Protobufs を使用するには、Protobuf プラグインをバージョン 0.8.2 以上にアップグレードする必要があります。

  • サードパーティの android-apt プラグインのサポートは終了しました。組み込みのアノテーション プロセッサのサポートに切り替えてください。こちらは、依存関係の遅延解決を処理できるように改良されています。

  • 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)
            }
        }
    }