Android Studio verbindet auf Ziel-VM auf dem Gerät aber nicht Debuggen - die meiste Zeit
Bin ich mit Android Studio 1.0.2 in ubuntu 14.04 auf einem app-Projekt der Migration von Eclipse. Ich bin neu auf Studio/IntelliJ und Gradle. Wenn ich auf Debuggen Sie die app, indem Sie auf das debug-Symbol im Studio:
- die app wurde von Gradle
- das Dialogfeld "Gerät Wählen" erscheint und ich kann wählen, mein Handy
- die Debug-Bereich sagt unter Variablen: "in Verbindung mit dem Ziel-VM, - Adresse: "localhost:8601' -, transport -: 'socket'
aber keine debugger-Symbole für Schritt in oder über den code, etc, aktiviert sind und der debugger wird nicht aufhören, an alle Haltepunkte.
Habe ich noch nicht festgelegt android:debuggable="true"
in meinem manifest als das zu sein scheint veraltet jetzt.
Ich habe versucht, das entfernen Sie alle aber eine JDK wie vorgeschlagen hier aber ich habe immer noch das problem.
Komisch ist, dass manchmal der debugger hat Verhalten, als erwartet, aber 8 oder 9 mal out of 10, es will einfach nicht funktionieren. Das ist ungemein frustrierend! Bekomme ich das gleiche Verhalten mit dem gleichen code und die version von Studio auf einem anderen Computer als auch. Irgendwelche Ideen auf, wie man Studio-debugger, um zuverlässig verhält, bitte?
Update 23 Jan: Der gleichen Instanz von Studio in der Lage ist, zu Debuggen eines neu geschaffenen "Hallo Welt" - app gut, so ist es wahrscheinlich etwas zu tun mit meinem app-Projekt, das ist das problem, aber ich weiß nicht, was. Vielleicht ist es tritt nur bei einigen Projekten Migration von Eclipse - z.B., wenn manifestiert zusammengeführt werden; aber das ist eine komplette Vermutung.
Update 7. Feb: Wenn ich den debugger zu unterbrechen auf eine Ausnahme dann sehe ich diese Ausnahme zunächst: libcore.io.ErrnoException: access failed: ENOENT (No such file or directory)
. Der stacktrace für den Haupt-thread ist:
<1> main@830017070344, prio=5, in group 'main', status: 'RUNNING'
at libcore.io.ForwardingOs.access(ForwardingOs.java:38)
at java.io.File.doAccess(File.java:283)
at java.io.File.exists(File.java:363)
at dalvik.system.DexPathList.splitAndAdd(DexPathList.java:168)
at dalvik.system.DexPathList.splitPaths(DexPathList.java:149)
at dalvik.system.DexPathList.splitLibraryPath(DexPathList.java:130)
at dalvik.system.DexPathList.<init>(DexPathList.java:98)
at dalvik.system.BaseDexClassLoader.<init>(BaseDexClassLoader.java:52)
at dalvik.system.PathClassLoader.<init>(PathClassLoader.java:65)
at android.app.ApplicationLoaders.getClassLoader(ApplicationLoaders.java:57)
at android.app.LoadedApk.getClassLoader(LoadedApk.java:317)
at android.app.LoadedApk.makeApplication(LoadedApk.java:493)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4170)
at android.app.ActivityThread.access$1400(ActivityThread.java:134)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1278)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:4867)
at java.lang.reflect.Method.invokeNative(Method.java:-1)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1007)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:774)
at dalvik.system.NativeStart.main(NativeStart.java:-1)
Dies ist, gefolgt von Belastungen der BootClassLoader Ausnahmen wie der classloader versucht und schlägt fehl, zum laden der Klassen in meiner app, und Google-Klassen. Auf meinem Gerät sehe ich die action bar - sonst nichts:(. Ich sah, dass jemand anderes ein ähnliches problem hier. Interessanterweise ist Sie auch nach der Migration von Eclipse zu IntelliJ aber, im Gegensatz zu Ihnen hatte ich nicht das problem in Eclipse schon, soweit ich weiß. Sie nie schien, um dem auf den Grund gehen. Irgendwelche Ideen, bitte? Ich verstehe immer noch nicht, was löst das, weil manchmal der debugger funktioniert wie erwartet.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Kurze Antwort: es gibt einen bekannten bug in den Google Play Services v6.5.87 was bedeutet, dass Google Analytics (GA) ist sehr wahrscheinlich in die Sackgasse, wenn
GoogleAnalytics.getInstance()
versucht, laden Sie die XML-tracker-Datei definiert, die in Ihrem manifest. Sie können es umgehen, konfigurieren Sie Ihren GA-tracker Programm, wie ich es Tat, oder durch Downgrade von der version von Google Play-Dienste, die Sie verwenden (oder wartet auf ein Update in einer späteren Version!). Sehen hier, hier und hier für mehr info.Mein 'Hello World' - app gearbeitet, weil es nicht GA. Ich bemerkte, dass die Abhängigkeiten Abschnitt meiner app bauen.gradle Datei in Android-Studio gesagt hatte:
Ich vermute, dass die original-Eclipse-version meiner app wurde mit Bezug auf eine ältere version der Google Play-Dienste, die nicht dieses Problem haben und dass, wenn die app migriert wurde, um Android-Studio-es war zufällig gegeben v6.5.87 mit diesem bug. Vielen Dank, Google! Ich hab da änderte sich die obige Zeile zu
so weiß ich wenigstens genau, was ich bekomme und kann selbst entscheiden, Wann zu aktualisieren!
Als für die class-loading-Fehler, die Sie zu sein scheinen, nicht (und harmlos?) aber ich weiß noch nicht, was Sie verursacht.
Lange Antwort: ich verzweigten mein code und entfernt werden, die app auf das wesentliche mit nur einer einzelnen Aktivität. Es war immer noch Absturz beim Start, aber dieses mal bemerkte ich diese Zeile im LogCat:
Ich habe diesen Befehl in meinem Dateisystem ziehen Sie die trace-dump von meinem Handy zu meinem computer:
Auf dem Kopf traces.txt ich sah diese (meine app-Pakete und-Namen wurden geändert):
Können Sie sehen, thread-id (tid) 1, "main", ruft GoogleAnalytics.getInstance() aber blockiert, wartet auf lock <0x420608a0> gehalten durch tid=13 (client_id_fetcher)
Aber Gewinde 13, "client_id_fetcher", ist blockiert, wartet auf lock <0x4205af48> gehalten durch tid=1 (main). Deadlock! (Thread 12, "GAThread" ist auch blockiert, wartet auf die gleichen lock.) Nach der Besichtigung war ich in der Lage, um mit Google nach deadlock in GoogleAnalytics.getInstance() und führte mich zu der oben genannten workarounds. Hoffe, das hilft jemand anderem, denn es hat mich eine lange Zeit zu verfolgen, diese nach unten!