在Eclipse中连接实时设备时，不正确的java开源视图 [英] Incorrect java open source view when stepping in Eclipse with live device connected

问题描述

我试图调试似乎只发生在三星的这个Android应用程序问题 G5 v4.4.4设备。要尝试跟踪NullPointerException的源代码，它将有助于逐步通过NPE发出信号的java开源代码。问题是，当我们使用三星G5 v4.4.4的模拟器时，应用程序不会抛出NPE ，我们可以逐行逐行浏览开源代码。然而，当我们将三星G5设备连接到Eclipse时，尝试逐步通过代码，当它进入java开源时，源代码被显示，但显然不正确。例如，我们知道这一点，因为它似乎是在开源中逐步注释行。已经审查了许多与源代码相关的文章没有找到，但在我们的例子中，我们似乎有一个正确的源代码，至少在模拟器调试模式下。如果有人可以就这个具体的调试问题提供指导，也许可以帮助我们隔离我们应用程序问题的原因（仅限于Samsung G5）。欢迎所有的建议。

• 开发平台Mac OSX 10.9.5。


• Eclipse 23.0.2.1259578。


• Android SDK工具24.0.2


• Android SDK平台工具第21版


• 工具Rev 21.1.2（也安装了Rev 20和Rev 19.1）


• 安装了各种Android API，其中包括API 21,20,19和18,17,16,14，


• 三星G5（Sprint）软件版本G900PVPU1ANK4，硬件版本G900P.04。 Android 4.4.4

更新：

我走过三星（源代码视图大多不正确），然后是Emulator（源视图是正确的）。两者都是Android 4.4.4，但我们假设三星已经从AOSP修改。通过比较代码行和一些可变状态，即使源代码视图不正确，我们也可以观看三星正在做什么。我不希望这种技术在任何人，但它的目的是帮助我们学习一些关于三星G5的应用程序观察到的错误，并在。

解决方案

这种情况下的首选方法可能是找到供应商特定的Android java源文件，并为Eclipse添加引用。然而，供应商并没有这么容易，我们从来没有找到它。

只要有其他程序具有足够的共性，小心谨慎，运气好一点。在我们的例子中，三星v4.4.4可以与Eclipse v4.4.2进行比较，并相关，以确定直到导致异常的代码行。首先了解与问题相关的代码区域（在您的应用程序中和相关的开放源代码）。然后，您将开始构建一个应该发生的映射（无错误）与故障设备发生的发生。这是基本的过程：
1.获取一个记事本记录一步一步的结果。我们有一列设备行号，然后是仿真器行号，然后是模块/方法名称，然后指令。
2.在应用软件中的一行代码中设置一个断点，您知道这将导致异常。
3.启动仿真器并运行debug到断点。
4.使用Step Into记录堆栈跟踪报告的每一行。注意模块/方法的变化，如果代码行似乎相关或有趣，也记录它。
5.继续在您的记事本上记录每个行执行的信息，直到知道您已经进入设备将抛出异常的那一点。
6.停止执行，（可能重新启动Eclipse），连接设备，并运行debug到断点。
7.在某些情况下，显示的源似乎是执行注释行，或者将跳转到方法的中间而不是其入口点。您正在寻找帮助您确定设备在源代码中可能运行的线索。一条证据是从一步到下一行的行数增加。显然，如果行数增加1，则其为单行指令。如果它跳了两个或几个，它可能是一个if。等等。另一个关键信息是调试变量。例如，如果已知好源中的一行代码是 a = 10; 则有时可以查看变量 a 之前的代码行（例如可能为null），然后再在该行代码之后。如果您对源的映射是正确的，那么您将看到 a 的值更改为10.

这只适用于相对相同的代码。例如，我们看到4.4.4三星的源头在某些情况下会被关闭50或甚至100多行，就好像供应商插入了一种新的方法。但是我们可以通过我们可以看到的来源追踪它。无论是否值得，都很难说。最后，我们意识到空指针是我们无法征服的，我们选择了完全不同的方法来实现目标。

Am trying to debug this Android app issue that seems to occur only on Samsung G5 v4.4.4 device. To try to trace the source of the NullPointerException, it would help to step through the java open source code where the NPE is signaled. The problem is that when we use an emulator for Samsung G5 v4.4.4, the app does not throw an NPE and we are able to step through the open source line by line. However, when we connect the Samsung G5 device to Eclipse, and try to step through the code, when it enters java open source the source code is displayed but it is clearly incorrect. We know this for example because it appears to "step through" comment lines in the open source. Have reviewed many articles related to source code not found, but in our case we do seem to have correct source code, at least when in emulator debug mode.

If anyone can provide guidance on this specific debugging issue, perhaps it can help us isolate the cause of our app issue (on Samsung G5 only). All suggestions welcome.

• Development platform Mac OSX 10.9.5.
• Eclipse 23.0.2.1259578.
• Android SDK Tools 24.0.2
• Android SDK Platform-tools Rev 21
• Android SDK Built-tools Rev 21.1.2 (also Rev 20 and Rev 19.1 installed)
• Various Android API installed, including API 21, 20, 19m, 18, 17, 16, 14
• Samsung G5 (Sprint) Software version G900PVPU1ANK4, Hardware version G900P.04. Android 4.4.4

UPDATE:

To make a bit of progress, I stepped through Samsung (where source code view is mostly incorrect) and then Emulator (where source view is correct). Both are supposedly Android 4.4.4, but we assume that Samsung has modified from the AOSP. By comparing the lines of code and some variable states, we can "watch" what the Samsung is doing, even though the source code view is incorrect. I would not wish this technique on anyone, but it served a purpose to help us learn a little about the error observed from our app on Samsung G5 and reported on this SO question.

解决方案

The preferred approach in this case is probably to find the vendor-specific Android java source file and include a reference to it for Eclipse. However, the vendors don't make this easy, and we were never able to find it.

With care and patience, and a bit of luck, one can trace a program as long as it has enough commonality with another program. In our case, the Samsung v4.4.4 could be compared with the Eclipse v4.4.2 and correlated to determine down to the line of code causing the exception. First get a basic understanding of the area of code (in your app and across the relevant open source) that is relevant to the issue. Then you will begin to build a map of what "should" happen (no error) versus what "does" happen with the failure device. This was the basic process: 1. Get a notepad to record step by step results. We had a column for "device line number", then "emulator line number", then module/method name, then instruction. 2. Set a breakpoint on a line of code in the app software that you know will lead to the exception. 3. Start the emulator and run debug to the breakpoint. 4. Use Step Into to record each line reported by the stack trace. Note the module/method when it changes, and if the line of code seems relevant or interesting, record it also. 5. Continue recording this information on your notepad for every line executed until you know that you have progressed through the point where the device will throw the exception. 6. Stop the execution, (perhaps restart Eclipse), connect the device, and run debug to the breakpoint. 7. In some cases, the source being displayed will seem to be "executing" comment lines, or will jump into the middle of a method rather than to its entry point. You are looking for clues that help you determine where the device might be operating in the source code. One piece of evidence is the number of lines increase from one step to the next. Obviously, if the line number increases by one, its a one-line instruction. If it jumps by two or a few, its likely an if. And so on. The other key piece of information is the debug Variables. For example, if a line of code in the known "good" source is a = 10; then you can sometimes view the variable a before that line of code (it might be null for example), and then after that line of code. If you are correct about your mapping of the source, then you'll see the value of a change to 10.

This only works for code that is relatively the same. We saw for example, the 4.4.4 Samsung source would be off in some cases by 50 or even 100+ lines, as though the vendor had inserted a new method. But we were able to trace it through the source we could view. Whether it was worth the time or not, is hard to say. In the end we realized the null pointer was something we couldn't conquer, and we chose a completely different approach to achieve the goal.

这篇关于在Eclipse中连接实时设备时，不正确的java开源视图的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！