Wrong open java view when logging into Eclipse with a connected device attached
I am trying to debug this Android app issue that seems to only happen on a Samsung G5 v4.4.4 device. To try and trace the source of the NullPointerException, this will help you navigate through open source java where NPE is signaled. The problem is that when we use the emulator for Samsung G5 v4.4.4, the app doesn't throw NPE and we can go through open source line by line . However, when we connect Samsung G5 device to Eclipse and try to execute the code, when it comes in open source java, the original code is displayed, but it is clearly incorrect... We know this, for example, because it seems to "step over" comment lines in open source. Have looked at many articles related to source code that were not found, but in our case we do have the correct source code, at least in emulation mode of the emulator.
If anyone can provide guidance on this particular debugging issue, maybe it can help us isolate the root cause of the problem with our apps (Samsung G5 only). All suggestions are welcome.
- Mac OSX 10.9.5 development platform.
- Eclipse 23.0.2.1259578.
- Android SDK Tools 24.0.2
- Android Platforms SDK Rev 21
- Android SDK Built-tools Rev 21.1.2 (Rev 20 and Rev 19.1 was also installed)
- Various Android APIs, including API 21, 20, 19m, 18, 17, 16, 14
- Samsung G5 (Sprint) G900PVPU1ANK4 software version, G900P.04 hardware version. Android 4.4.4
UPDATE:
To go a little further, I stepped through Samsung (where the source code is mostly wrong) and then the emulator (where the original view is correct). Both are presumably Android 4.4.4, but we're guessing Samsung changed from AOSP. By comparing lines of code and some of the state variables, we can "observe" what Samsung is doing, although the representation of the source code is incorrect. I wouldn't wish this technique on anyone, but it helped us learn a bit about the error we observed in our app on Samsung G5 and reported this issue to SO .
source to share
The preferred approach in this case is probably to find the vendor-specific java source file and include a link to it for Eclipse. However, the vendors don't make it easy, and we were never able to find it.
With care and patience, and a little luck, it is possible to trace a program if it has enough commonality with another program. In our case Samsung v4.4.4 can be compared with Eclipse v4.4.2 and correlated to determine up to the line of code that is throwing the exception. First, let's get a basic understanding of the area of code (in your application and through the associated open source code) that is relevant to the problem. Then you start to build a map of what should happen (without errors) versus what "happens" to 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 application software,which you know will throw an exception. 3. Start the emulator and debug up to the breakpoint. 4. Use Step Into to record each line listed in the stack trace. Pay attention to the module / method when it changes, and if a line of code seems relevant or interesting, write it down as well. 5. Continue writing this information in your notepad for each line until you know that you have advanced to the point where the device will throw an exception. 6. Stop execution (perhaps restart Eclipse), plug in the device, and debug up to the breakpoint. 7. In some cases, the rendered source seems to "execute" comment lines or jump to the middle of the method rather than its entry point. Are you looking for clues to help you determinewhere the device can run in source code. One piece of evidence is that the number of lines increases from one step to the next. Obviously, if the number of lines is increased by one, then this is a one-line statement. If he's jumping two or more, it's probably something. Etc. Another key piece of information is debug variables. For example, if a line of code in a known "good" sourcea = 10;
then you can sometimes look at the variable a
up to that line of code (it could be null, for example) and then after that line of code.If you have specified your source mapping correctly, you will see the value a
change to 10.
This only works for code that is relatively the same. For example, we saw that the 4.4.4 Samsung source would be disabled on 50 or even 100+ lines in some cases, as if the seller had inserted a new method. But we were able to trace it through a source that we could see. Whether this time is worth it or not is hard to say. In the end, we realized that the null pointer was something we couldn't beat, and we took a completely different approach to achieve the goal.
source to share