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

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?

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.

Unfortunately curious_george's solution only works if the device has a version of Android built directly from the published Google sources. Device manufacturers are not obliged to do that, and the Apache Licence used by Google, unlike the GPL, does not oblige publishers of derivative works to give access to their sources.

My device is a Samsung Galaxy S21, and the build number of the currently installed Android is
SP1A.210812.016.G998BXXU4BULF, which is of course not listed in https://source.android.com/setup/start/build-numbers#source-code-tags-and-builds.

The versions of the sources tagged 210812.016 listed there are

210812.016.A1 android-12.0.0_r3 Tue Aug 24 18:43:39 2021
210812.016.A2 android-12.0.0_r25 Tue Aug 24 18:43:39 2021
210812.016.B1 android-12.0.0_r30 Fri Dec 24 23:08:44 2021
210812.016.C1 android-12.0.0_r31 Sat Dec 25 00:36:35 2021

They all appear to have the same version of View.Java, and Android Studio says that it isn't the version in my device. Even a comment change can confuse the debugger since it looks for the code at a particular line number.

At the moment I also can't debug using the emulator, which would presumably have a genuine Google release of Android, since the latest release of Android Studio (Android Studio BumbleBee | 2021.1.1 Patch 2, Build #AI-211.7628.21.2111.8193401, built on February 17,2022) seems to have broken it. The emulator either locks up its UI or crashes when started, and the debugger can't connect to it.

So there seems currently to be no way of solving the originally posted problem.

HELP!!