次のbuild.gradle設定があります。
compileSdkVersion 21
buildToolsVersion '21.1.1'
defaultConfig {
minSdkVersion 18
targetSdkVersion 21
}
問題は、KitKatデバイス(Genymotionまたはデバイスでは19)でAndroid SDKソースにステップインするときに、19ではなくAndroid-21ソースへのステップインを要求することです。
上記の設定のいずれかを変更すると、v21コードがあるため、アプリのコンパイルが中断されます。 19の呼び出しはすべて適切に保護されており、コードworksは19で、ソースコードのリンクアップだけが正しくありません。
スタックオーバーフローの兄弟姉妹、事前に乾杯!
編集(2016年7月1日):
Android Studio 2.2はそれを修正し、実際に実行しているデバイスに対応するAPIレベルのソースにジャンプします(これらのソースがインストールされている限り)。発表されました こちら 。
次の回避策が私にとってうまくいきました:
File
> Project Structure
に移動し、app
モジュール(またはオプションでその他のモジュール)を見つけて、Compile Sdk Version
をお使いのデバイスに一致するものに変更します再デバッグ(つまり19)。別の回答で述べたように、Android Studio 2.2( bug report ))で修正されました。
ただし、Android Studio 3.0)でも機能しませんでした。[設定]で[代替ソースの切り替えを表示する]をオンにした後にのみ機能しました。
Android 5.0.x Lollipopイメージを実行しているエミュレータでソースにデバッグしようとするとどうなりますか?それは正しい情報源を強調していますか?私もこれに苦労しており、問題はハードウェアベンダーによるAndroidソースのカスタマイズが原因であるという結論に達しました。
4.4.2 KitKatを実行しているsamsungデバイスでAndroidソースコードをステップ実行しようとしています。うまく並んでいるファイルもあれば、数行ずれているファイルもあり、残りのファイルはとんでもなく抜けています。 Instrumentation.Javaは、私が日常的に使用しているものです。5行ほどずれています。
では、なぜベンダーがAndroidソースをカスタマイズしたと思いますか? ActivityThread.JavaとInstrumentation.Javaでアプリケーションの起動をステップスルーしました。ソースが揃っていなくても、デバッガは正しくステップします。私はgrepcode.comのAndroidソースコードを使用して、ルーチンを相互参照しました。最終的に、grepcodeに投稿されたJavaファイルのどのバージョンにも存在しない関数呼び出しへのデバッガーのステップが表示されます。
具体的な例を次に示します。ActivityThread.HandleLaunchActivity。デバッガがこれらの呼び出しを行うのを見ました
unscheduleGcIdler : present in Android source
intent.getWindowStyle : not present. Samsung customization?
handleConfigurationChanged : present
私が正しい場合、デバッガーはベンダーがカスタマイズしたコードを含まないため、エミュレートされたイメージを正しく処理する必要があります。