Source Code Does Not Match the Bytecode' When Debugging on a Device

Source code does not match the bytecode' when debugging on a device

There's an open issue for this in Google's IssueTracker.

The potential solutions given in the issue (as of the date of this post) are:

• Click Build -> Clean
• Disable Instant Run, in Settings -> Build, Execution, Deployment

Source code does not match the bytecode for Android's View.java

I think I figured out what was happening and I have a solution for this problem when it happens with Android SDK files. Frighteningly, the Android SDK Platform gets updated to Revision 5, but the source package is not updated. It is still on Revision 1! Why this happened, I cannot explain: a reasonable person would expect both to be in sync. This screenshot shows the source code does not match the binary that Android Studio downloaded:

The only way around this is to manually download the files you need and patch them manually in your SDK source directory. It's ugly, it's unnecessary, but if you really want to step through a specific SDK file you have to do it.

1. Find out what Android build you have. On your device, go to "Settings" -> "About phone" -> "Android version", and note down your "Build number" value. Mine is QQ3A.200805.001.

2. Find out the Tag corresponding to your Build number using this page: https://source.android.com/setup/start/build-numbers#source-code-tags-and-builds. For my build number, the tag is: android-10.0.0_r41

3. Download the AOSP source for this tag. This takes a long time if you are doing this for the first time. See https://stackoverflow.com/a/14353644/259718 for an example on how to do that.

4. Copy the files to overwrite some of the source directories: cp -pr ~/android_src/frameworks/base/core/java/android/* ~/Library/Android/sdk/sources/android-29/android/ (use the correct location for your environment, here I am compiling with android-29)

While not all of the directories in the android sources folder are overwritten, the core android files are overwritten. These comprise the majority of the source material. If you need other directories (e.g. "filterpacks"), you'll have to find that in the other AOSP directories (e.g. frameworks/base/media for "filterpacks").

Here are the steps I followed to get just one individual file:

3. Find the file you need on https://android.googlesource.com. Using google.com, I found it at: https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/view/View.java
4. Determine the Android repo your file lives in. Looking at the previous URL, I can deduce it's at: https://android.googlesource.com/platform/frameworks/base/
5. Grab that repo using your tag. Or grab that tag's most recent revision of that individual file on-line, e.g.: https://android.googlesource.com/platform/frameworks/base/+log/refs/tags/android-10.0.0_r41/core/java/android/view/View.java, revision 18c0fbf.
   
   • To download the individual file, add "?format=text" to the URL to get the base64 encoded version. Then decode it: cat file | base64 --decode.
6. Now you have the file. Go to your SDK directory that contains the errant file: cd ~/Library/Android/sdk/sources/android-29/android/view/
7. Backup the old file (cp -pr View.java View.java.orig) if you want (you can always re-install the SDK source files if you mess up). Copy in your new file into the same location.
8. Now, your debugger will use the correct file! You will have to do this for each file that your debugger complains about.

I hope this helps someone else in the future. I spent a lot of time figuring this out and I sincerely hope someone else won't have to waste that time. Google needs to keep the source packages consistent with the release packages. Looking at all the past SDK releases, none of the source packages appear to be in sync with the latest release version. Maybe another ugly way to debug SDK files is to use a Revision #1 SDK release version that matches the Revision #1 source package.

Source code does not match the bytecode for system files on Huawei

Apparently Huawei forked AOSP and modified it's sources. This is what many manufacturers do and it's perfectly fine as long as source passes the Compatibility Test Suite. I myself saw encrypted video playback issues on Huawei P20 related to their approach to customizing the ROM.

But getting back to the point - you can get the exact framework code running on your device from /system/framework/arm/boot.oat or boot-framework.oat or /system/framework/boot.vdex. I don't know exactly how these files are structured but it varies between Android versions and between manufacturers. Once you get these files by adb pull (You surely need root to do this) you can perform oat->dex, dex->jar using dex2jar or other tools and you'll get the source. Traditionally it was possible to get framework code from /system/framework/framework.jar but after ART was introduced these files are often empty on system images and precompiled framework code is used instead.

Library source does not match the bytecode for class

There's nothing wrong with IDEA, nor your dependencies or local maven caches, it's correctly identifying the mismatch.

Here's how to check:

• Open class in question
• Click "Show diff"
• Choose "Ignore whitespaces and empty lines"

You can clearly see (ignoring JavaDoc and FQCNs) that the class file has extra checks included for the @NonNull annotated arguments. The import says lombok.NonNull, and the documentation shows this transformation will happen.

I guess the best course of action is either to ignore this warning or ask the project's maintainers to build the sources.jar from the lombok-processed source code if that's possible. I think they'll need to employ delomboking and this Maven plugin, but never built lombok code myself.

Source code doesn't match byte code IntelliJ 15 while debugging

You need to make absolutely sure that the source code you have in IDE corresponds to the classes loaded in the remote JVM.

It could be that you have some extra jar in the classpath with older class versions that overrides the more recent versions or the code is built without debug info, or some annotation processors/obfuscators have changed the target classes during the build process.

Using javap or a decompiler can help to detect classes that are not in sync.

As you have mentioned in the comment, the code running on the server was from the different git branch than the code you had in IDE. This could be avoided by rebuilding the project in IDE and deploying the actual code to the server.

---

Related Topics