1

I have several Android projects in an Eclipse workspace:

  • a stand-alone application project with a class my.package.Foo
  • a library project with a different class my.package.Foo
  • two application projects that depend on the library project and contain no source code

The problem comes when working with one of the applications built on top of the library project. When it crashes (sadly, a frequent occurrence), I double-click on a line of the stack trace in the logcat to go to the relevant source. The problem is, if the line is for Foo.java, Eclipse always opens the source from the stand-alone project. The only way I can direct Eclipse to the right source is to close the stand-alone project, which is somewhat inconvenient.

Is there any way to get Eclipse to pay attention to which application actually crashed when it looks for the relevant source file? I assume that this is some sort of classpath problem (similar to that described in this post). However, I don't see anything in the Android run configuration properties for modifying the class path. Eclipse always seems to run through the workspace projects in alphabetical order by name and opens the first my/package/Foo.java it finds.

I'm using the latest Android ADT and SDK versions.

Community
  • 1
  • 1
Ted Hopp
  • 232,168
  • 48
  • 399
  • 521
  • I had a similar case, but even during compilation it took the other class (which I was not aware of assuming it takes the class in my project). I just added the full path/package name in the source code to the class and then compiling AND debugging worked with the correct class – user387184 Apr 17 '12 at 22:52
  • @user387184 - Eclipse and the Android packaging tools are definitely using the correct class during build. It's only a problem of interpreting a stack trace. – Ted Hopp Apr 17 '12 at 22:57
  • I understand, however, I would try to add the full path/package anyway and see if that helps to identify the correct java source file for the class during the crash - possibly worth a try? – user387184 Apr 17 '12 at 22:59
  • @user387184 I don't understand your recommendation. Are you suggesting changes to the Java source code that uses class `Foo`? Both `Foo` classes are in the same package -- they just happen to be in different projects, and there's no way to specify a project path in Java source. – Ted Hopp Apr 17 '12 at 23:03
  • sorry, I guess then I missundertood your problem... – user387184 Apr 17 '12 at 23:11
  • 1
    I think this is related http://code.google.com/p/android/issues/detail?id=18514&can=1&q=logcat%20wrong%20file&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars – blessanm86 Apr 18 '12 at 00:09
  • @blessenm - Thanks for that link. It's exactly the same issue. – Ted Hopp Apr 18 '12 at 00:26
  • It seems ur post on the bug list got the issue finally assigned to someone. :) – blessanm86 Apr 18 '12 at 04:23
  • @blessenm Yes, it seems to have woken someone up or something. :) – Ted Hopp Apr 18 '12 at 05:11

1 Answers1

0

Per the link provided in the comment by @blessenm, this is an issue with logcat in Eclipse. We should see a fix in Release 20 of the SDK tools. As can be seen here, the patch that fixes it has been completed and is in line for final approval.

Meanwhile, the best thing to do is to change the logcat preferences (Window -> Preferences -> Android -> LogCat) so that the double-click action is "Go to Problem (method declaration)" instead of the default "Go to Problem (error line)". This isn't foolproof: it will at least open the file but if there are multiple methods with the same name, it will go to the first method, regardless of signature. (When the fix is incorporated, there will be no need for options for double-click action and it should disappear from the preferences.)

Ted Hopp
  • 232,168
  • 48
  • 399
  • 521