Exoplayer: "Library source does not match the bytecode for ..." in Android Studio

Created on 19 May 2020  路  1Comment  路  Source: google/ExoPlayer

Issue description

I just updated gradle dependencies from

implementation 'com.google.android.exoplayer:exoplayer:2.10.6'

to

implementation 'com.google.android.exoplayer:exoplayer:2.11.4'

and everything seems to work fine, except that now when I open com.google.android.exoplayer2.mediacodec.MediaCodecRenderer

,Android Studio is showing a pink/red bar on top of the editor area, where the following text is displayed:
_Library source does not match the bytecode for class MediaCodecRenderer_

This class file is located here

/home/user_name/.gradle/caches/transforms-2/files-2.1/601bc75bec507940ee72ea05899eb65c/jetified-exoplayer-core-2.11.4/jars/classes.jar!/com/google/android/exoplayer2/mediacodec/MediaCodecRenderer.class

and its source file is here:

/home/user_name//.gradle/caches/modules-2/files-2.1/com.google.android.exoplayer/exoplayer-core/2.11.4/c531cb088bd69d20eefb51c60aaa96281425263c/exoplayer-core-2.11.4-sources.jar

It looks like they are some other files with the same problem:

/home/user_name/.gradle/caches/transforms-2/files-2.1/601bc75bec507940ee72ea05899eb65c/jetified-exoplayer-core-2.11.4/jars/classes.jar!/com/google/android/exoplayer2/extractor/ts/Ac3Reader.class
/home/user_name/.gradle/caches/transforms-2/files-2.1/601bc75bec507940ee72ea05899eb65c/jetified-exoplayer-core-2.11.4/jars/classes.jar!/com/google/android/exoplayer2/extractor/ts/Ac4Reader.class
...

I already completely wiped the Android Studio and .gradle/ caches, but the issue is still present.

Maybe there is an issue with the content of exoplayer-core-2.11.4-sources.jar ?

Reproduction steps

Using Android Studio, create a project with gradle dependency

implementation 'com.google.android.exoplayer:exoplayer:2.11.4'

then, within Android Studio, open the following class:

com.google.android.exoplayer2.mediacodec.MediaCodecRenderer

Link to test content

NA - There is no actual error at runtime

A full bug report captured from the device

NA - There is no actual error at runtime

Version of ExoPlayer being used

'com.google.android.exoplayer:exoplayer:2.11.4'

Device(s) and version(s) of Android being used

NA - There is no actual error at runtime

question

Most helpful comment

I'm pretty sure that the sources jar is correct. It's easy to verify this by taking one of the files from the sources jar and comparing it against the source code for the 2.11.4 release, here. Short of a tool chain problem, which seems very unlikely to me, the class files were definitely generated from these sources too.

I'd therefore conclude that the most likely cause of the warning is that the decompiler isn't decompiling the bytecode in the class file back to something that's close enough to the original source file for it to be deemed equivalent. For example in Ac3Reader the decompiled class version contains this:

  private boolean skipToNextSync(ParsableByteArray pesBuffer) {
    while(pesBuffer.bytesLeft() > 0) {
      if (!this.lastByteWas0B) {
        this.lastByteWas0B = pesBuffer.readUnsignedByte() == 11;
      } else {
        int secondByte = pesBuffer.readUnsignedByte();
        if (secondByte == 119) {
          this.lastByteWas0B = false;
          return true;
        }

        this.lastByteWas0B = secondByte == 11;
      }
    }

    return false;
  }

whereas the original is this functionally equivalent, but different, piece of code

  private boolean skipToNextSync(ParsableByteArray pesBuffer) {
    while (pesBuffer.bytesLeft() > 0) {
      if (!lastByteWas0B) {
        lastByteWas0B = pesBuffer.readUnsignedByte() == 0x0B;
        continue;
      }
      int secondByte = pesBuffer.readUnsignedByte();
      if (secondByte == 0x77) {
        lastByteWas0B = false;
        return true;
      } else {
        lastByteWas0B = secondByte == 0x0B;
      }
    }
    return false;
  }

It's unclear whether it's this that causes the difference warning to be shown for Ac3Reader, since there are lots of other differences that are presumably common for all classes (e.g., constant inlining, some annotations being removed, this. prefixes being added everywhere). But it does look like a more significant structural deviation compared to some of the other differences.

Unless this is causing a real problem, I don't think we need to do anything about this. If it is causing a real problem, it's probably necessary to file a bug on IntelliJ or Android Studio for routing.

>All comments

I'm pretty sure that the sources jar is correct. It's easy to verify this by taking one of the files from the sources jar and comparing it against the source code for the 2.11.4 release, here. Short of a tool chain problem, which seems very unlikely to me, the class files were definitely generated from these sources too.

I'd therefore conclude that the most likely cause of the warning is that the decompiler isn't decompiling the bytecode in the class file back to something that's close enough to the original source file for it to be deemed equivalent. For example in Ac3Reader the decompiled class version contains this:

  private boolean skipToNextSync(ParsableByteArray pesBuffer) {
    while(pesBuffer.bytesLeft() > 0) {
      if (!this.lastByteWas0B) {
        this.lastByteWas0B = pesBuffer.readUnsignedByte() == 11;
      } else {
        int secondByte = pesBuffer.readUnsignedByte();
        if (secondByte == 119) {
          this.lastByteWas0B = false;
          return true;
        }

        this.lastByteWas0B = secondByte == 11;
      }
    }

    return false;
  }

whereas the original is this functionally equivalent, but different, piece of code

  private boolean skipToNextSync(ParsableByteArray pesBuffer) {
    while (pesBuffer.bytesLeft() > 0) {
      if (!lastByteWas0B) {
        lastByteWas0B = pesBuffer.readUnsignedByte() == 0x0B;
        continue;
      }
      int secondByte = pesBuffer.readUnsignedByte();
      if (secondByte == 0x77) {
        lastByteWas0B = false;
        return true;
      } else {
        lastByteWas0B = secondByte == 0x0B;
      }
    }
    return false;
  }

It's unclear whether it's this that causes the difference warning to be shown for Ac3Reader, since there are lots of other differences that are presumably common for all classes (e.g., constant inlining, some annotations being removed, this. prefixes being added everywhere). But it does look like a more significant structural deviation compared to some of the other differences.

Unless this is causing a real problem, I don't think we need to do anything about this. If it is causing a real problem, it's probably necessary to file a bug on IntelliJ or Android Studio for routing.

Was this page helpful?
0 / 5 - 0 ratings