IssueTracker

Thank you for reporting this issue. For us to further investigate this issue, please provide the following additional information:

Please provide a sample project or apk to reproduce the issue. Also mention the steps to be followed for reproducing the issue with the given sample project or apk.

Android bug report (to be captured after reproducing the issue) For steps to capture a bug report, please refer: https://developer.android.com/studio/debug/bug-report#bugreportdevice

Note: Please avoid uploading directly to the issue using attachments. Please upload to google drive and share the folder to android-bugreport@google.com, then share the link here.

We are using Bazel internally at spotify. I have tried reproducing using Gradle but no luck.

The class posted above compiles with the new and the old android jar on the classpath, but it compiles to different bytecode as you can see from my original post.

Do you have any special handling in the AGP for this? Would a Bazel sample project help?

Essentially the Jake wharton blogpost here: https://jakewharton.com/kotlins-jdk-release-compatibility-flag/ describes the situation. In one of the last paragraphs he says:

Users of the Kotlin Android plugin or the Android targets of the Kotlin multiplatform plugin do not need to do this, as the use of the android.jar as the boot classpath limits the java.* APIs to those of your compileSdk (and Android Lint ensures you don’t use anything newer than your minSdk).

But since the android.jar in the android 35 sdk does have the conflicting method I'm suprised I'm not seeing the same issue when using the AGP to build a sample app using the problematic APIs.

Actually a Bazel project would probably not be possible to provide since our kotlin to android integration is custom in our Bazel setup.

The question still stands if there is any special handling of this in the AGP.

I was able to reproduce the issue using Gradle and I created a repo here: https://github.com/gabrielborglund/break-android-35-preview. The main bit is in the MainActivity. If I change the compileSdk to be 34, then this compiles and works on both an android 15 and an android 14 device. But when using compileSdk 35 there is a runtime crash even tho I'm not explicitly using any android 15 APIs (Although the code compiles to use the new List interface method introduced in compileSdk 35 which is the problematic part.).

To reproduce this I had to bump kotlin from 1.9.0 to 1.9.20.

Please share the bugreport to proceed further

Here is the bug report: https://drive.google.com/file/d/1-39d4qmw-gEngiB7I7pmR0ODwA8hVt72/view

We have passed this to the development team and will update this issue with more information as it becomes available.

Thank you!

Hey gabrielb@, I am from the build team.

IIUC, the problem is users kotlin extension function is shadowed by the new function introduced in jdk21. I think the best way is to change your extension function to avoid the conflict.

If you end up using the new api introduced in jdk21 and want it to be available in android 14- device, that is a story of desugaring new java api. (I can ask r8 forlks to checkout our support of desugaring jdk21 apis)

Hi!

These extension functions are not written by us. This is part of the Kotlin standard library: https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/remove-first.html. The issue here is that we didn't make any code changes, compilation passed just like it should have but still there was a runtime crash just by changing the compileSdk. The IDE will correctly highlight the line where the call is made and tell you that you are using a 35 API, but that is hard to catch if you don't explicitly open the code using the API in Android Studio. This caused runtime issues in an internal release for us.

If this would be fixed by r8 desugaring that would be great!

We could definitely change our calls, but that doesn't change the fact that this is hard to detect if not impossible if you are not using android studio.

Soren, can you share our status regarding supporting jdk21 apis? I assume we don't have support yet because it is quite new. However, given the conflict is between kotlin standard library vs jdk21, it is more helpful than others.

(Based on my research, the compiler only raises warning instead of error when the kotlin extension function is shadowed by the jdk21 function. )

thanks for taking the time to file this issue and for creating a simple test case, Spotify team. We've been

If you're in need of a workaround, the straightforward one is to replace the calls with code that has the same semantics (see https://issuetracker.google.com/issues/348683480#comment12)

This behaviour change has now also been documented at the Android 15 Behavior Changes page

This is an unfortunate interaction between the Android runtime evolving and how Kotlin extension functions works. See https://developer.android.com/about/versions/15/behavior-changes-15#openjdk-api-changes for the official guidance.

We did consider adding backporting/desugaring, using code like this, but decided against it.

public static <T> T removeFirst(List<T> list) {
  if (Build.VERSION.SDK_INT >= 35) {
     return list.removeFirst();
  } else if (list.getClass() == ArrayList.class) {
     return list.remove(0);
  } else {
    try {
      Method removeFirst =
          list.getClass().getDeclaredMethod("removeFirst");
      try {
        return (T) removeFirst.invoke(list);
      } catch (IllegalAccessException
          | InvocationTargetException e) {
        throw new RuntimeException(
            "removeFirst backport failed", e);
      }
    } catch (NoSuchMethodException e) {
      return list.remove(0);
    }
  }
}

The lint error and quick fix mentioned in https://developer.android.com/about/versions/15/behavior-changes-15#openjdk-api-changes is the way to handle this. If similar situations happen in the future with other APIs being added to Android this will be handled on a case-by-case basis. The semantics of kotlinc resolution will most likely not change and at the same time the Java API surface of Android should follow OpenJDK as closely as possible.

@mh...@snapchat.com, thank you for the reporting the issue with reversed. Can you give some additional information on how to reproduce that. If I use Kotlin 1.9.22 or 2.0.10 and the following code

fun removeFirst(list: MutableList<String>) {
    list.removeFirst()
}

fun reversed(list: MutableList<String>) {
    list.reversed()
}

I get a lint warning on removeFirst, but not on reversed, as kotlinc generated this code:

  public static final void reversed(java.util.Collection<java.lang.String>);
    descriptor: (Ljava/util/Collection;)V
    flags: (0x0019) ACC_PUBLIC, ACC_STATIC, ACC_FINAL
    Code:
      stack=2, locals=1, args_size=1
         0: aload_0
         1: ldc           #12                 // String list
         3: invokestatic  #18                 // Method kotlin/jvm/internal/Intrinsics.checkNotNullParameter:(Ljava/lang/Object;Ljava/lang/String;)V
         6: aload_0
         7: checkcast     #49                 // class java/lang/Iterable
        10: invokestatic  #52                 // Method kotlin/collections/CollectionsKt.reversed:(Ljava/lang/Iterable;)Ljava/util/List;
        13: pop
        14: return
      LineNumberTable:
        line 20: 6
        line 21: 14
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0      15     0  list   Ljava/util/Collection;
    Signature: #47                          // (Ljava/util/Collection<Ljava/lang/String;>;)V
    RuntimeInvisibleParameterAnnotations:
      parameter 0:
        0: #8()
          org.jetbrains.annotations.NotNull

The list is cast to java.lang.Iterable (not sure why kotlinc decides to do that), and Iterable does not reversed method, so resolution with the android-35 SDK with SequencedCollection included will not find a reversed method and the extension method is used as before. This results in the following DEX:

.method public static final removeFirst(Ljava/util/List;)V
    .locals 1
    .param p0, "list"    # Ljava/util/List;
    .annotation system Ldalvik/annotation/Signature;
        value = {
            "(",
            "Ljava/util/List<",
            "Ljava/lang/String;",
            ">;)V"
        }
    .end annotation

    const-string v0, "list"

    invoke-static {p0, v0}, Lkotlin/jvm/internal/Intrinsics;->checkNotNullParameter(Ljava/lang/Object;Ljava/lang/String;)V

    .line 16
    invoke-interface {p0}, Ljava/util/List;->removeFirst()Ljava/lang/Object;

    .line 17
    return-void
.end method

.method public static final reversed(Ljava/util/List;)V
    .locals 1
    .param p0, "list"    # Ljava/util/List;
    .annotation system Ldalvik/annotation/Signature;
        value = {
            "(",
            "Ljava/util/List<",
            "Ljava/lang/String;",
            ">;)V"
        }
    .end annotation

    const-string v0, "list"

    invoke-static {p0, v0}, Lkotlin/jvm/internal/Intrinsics;->checkNotNullParameter(Ljava/lang/Object;Ljava/lang/String;)V

    .line 20
    move-object v0, p0

    check-cast v0, Ljava/lang/Iterable;

    invoke-static {v0}, Lkotlin/collections/CollectionsKt;->reversed(Ljava/lang/Iterable;)Ljava/util/List;

    .line 21
    return-void
.end method

This happens with reversed in our codebase too, when it is invoked on the Stack object:

java.lang.NoSuchMethodError: No virtual method reversed()Ljava/util/List; in class Ljava/util/Stack; or its super classes (declaration of 'java.util.Stack' appears in /apex/com.android.art/javalib/core-oj.jar)

    compileOptions {
        sourceCompatibility JavaVersion.VERSION_17
        targetCompatibility JavaVersion.VERSION_17
    }

    kotlinOptions {
        freeCompilerArgs = ['-Xjvm-default=enable']
        jvmTarget = JavaVersion.VERSION_17.toString()
    }

kotlin = "1.8.10"

If libraries are compiled with a bootclasspath without removeFirst/removeLast, then kotlinc will have used the extension function, and the library will not have calls to removeFirst/removeLast. If the library is compiled with a bootclasspath with removeFirst/removeLast, then they will stay, and there is not much you can do as a user of the dependency. However, the provider of the dependency should have gotten lint warnings about using APIs only present from API level 35.

If you have Kotlin reflect issues related to this, please open a new issue on that.

Android lint check didn't report the "reversed()" method being called.

Which lint warning are you getting for removeFirst/removeLast? Is it the one to rewrite the to use removeAt?