1

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.

Community
  • 1
  • 1
ssurfr
  • 71
  • 7

1 Answers1

1

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.

ssurfr
  • 71
  • 7