I am attempting to debug my Android app. When the debugger gets to the View.java file, I receive the message, “Source code does not match the bytecode”. I can see that the debugger is in the wrong part of the file. Does anyone know how to fix this?
I am debugging on an Android 10 (API 29) device. In the Android Studio Preferences -> Appearance & Behavior -> System Settings -> Android SDK, I’ve made sure everything is up to date. I’ve also cleaned and rebuilt multiple times, removed caches, restarted Android Studio and the device, uninstalled/re-installed, updated Android Studio to 4.0.1. In the Module Settings, the “Compile Sdk Version” is 29, and the Target SDK Version and Min SDK Version to 29. Nothing helps or has any effect. Many of these steps were suggested in similar posts.
The View.java file it tries to open is at: ~/Library/Android/sdk/sources/android-29/android/view/View.java. This should be the correct file, yet the debugger is in the wrong part of the file while I get the error message.
Putting on my black hat, let’s assume that my laptop’s View.java is correct for that API level: could my phone be running non-standard code, and is there any way to detect that or rule it out?
Advertisement
Answer
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.
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.
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
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.
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:
- 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
- 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/
- 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.
- Now you have the file. Go to your SDK directory that contains the errant file: cd ~/Library/Android/sdk/sources/android-29/android/view/
- 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.
- 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.