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

このページには、Android Studio 3.5 と Android Gradle プラグイン 3.5.0 に関する既知の問題を掲載します。ここに記載されていない問題に遭遇した場合は、バグの報告をご確認ください。

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

Android Studio に関する既知の問題

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

コード編集

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

誤った XML コードスタイル

XML コードを編集する際に、メニューバーから [Code] > [Reformat Code] を選択すると、IDE が誤ったコードスタイルを適用することがあります。この問題を解決するには、次のようにして該当の Android コードスタイルをリセットします。

  1. [File] > [Settings](macOS では [Android Studio] > [Preferences])をクリックして、[Settings] ウィンドウを開きます。
  2. 左側のパネルで、[Editor] > [Code Style] > [XML] をクリックします。
  3. 右側のパネルの右上隅で、[Set from] > [Predefined Style] > [Android] を選択します。
  4. [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 の入力方法のみを無効にします。実行する可能性のあるその他のアプリケーションの入力は無効になりません。(ibus-daemon -rd を実行するなどして)Android Studio の実行中にデーモンを再起動した場合、それ以外のアプリケーションの入力方法が実質的に無効になり、Android Studio の JVM もセグメンテーション エラーによりクラッシュする可能性がありますので、ご注意ください。
  • 回避策 3: ショートカットのバインディングを調べて、「次の入力」のショートカットとして 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 を再インストールします。Ubuntu ユーザーに影響する既知の問題が存在するため、空の /etc/ssl/certs/java/cacerts が発生します。この問題を回避するには、コマンドラインで以下を実行します。
    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 ランタイムの問題によりエラーがスローされる

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

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

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

この問題により変更の適用が失敗すると、Android Studio は次のメッセージを表示します。

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 コード内の行でデバッガが実行を一時停止したときに [Step Into] をクリック)して Java コードに戻る場合は、([Step Out] または [Step Over] ではなく)[Resume Program] をクリックしてください。アプリのプロセスはまだ一時停止しているため、[your-module-java] タブで [Resume Program] をクリックして再開します。詳しくは、問題 224385 をご覧ください。

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

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

改行(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 3.3.1 で修正

  • 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 以上には影響を与えません。