IssueTracker

Please upload a minimal sample project that reproduces this issue.

Whenever this is a pop, the exiting screen should always be on top. (see code here)

It looks like a possible root cause could be that the exiting destination is correctly drawn on top when there's a pop, but predictive back press isn't actually pop and therefore isn't drawn on top.

Most of the logic seems to check composeNavigator.isPop.value || inPredictiveBack, but targetZIndex only checks pop when it should instead probably check for either pop or inPredictiveBack?

link

Once a sample project is provided we will reopen this issue, as we cannot reproduce this at the moment.

I have created a sample project which reproduces the issue, and attached a video.

When enableOnBackInvokedCallback is enabled in manifest, the pop exiting destination is incorrectly drawn underneath the pop entering destination. When it is disabled, everything works as expected (but no predictive back)

https://github.com/adrian-shape/predictivebackbug

Nope, no luck

09a2b0:                                        |[09a2b0] com.example.myapplication.InitializerApplication.onCreate:()V
09a2c0: 6f10 4100 0200                         |0000: invoke-super {v2}, Landroid/app/Application;.onCreate:()V // method@0041
09a2c6: 1c00 6504                              |0003: const-class v0, Lcom/example/myapplication/Service; // type@0465
09a2ca: 6e10 1014 0000                         |0005: invoke-virtual {v0}, Ljava/lang/Class;.getClassLoader:()Ljava/lang/ClassLoader; // method@1410
09a2d0: 0c01                                   |0008: move-result-object v1
09a2d2: 7120 b815 1000                         |0009: invoke-static {v0, v1}, Ljava/util/ServiceLoader;.load:(Ljava/lang/Class;Ljava/lang/ClassLoader;)Ljava/util/ServiceLoader; // method@15b8
09a2d8: 0c00                                   |000c: move-result-object v0
09a2da: 7210 5914 0000                         |000d: invoke-interface {v0}, Ljava/lang/Iterable;.iterator:()Ljava/util/Iterator; // method@1459
09a2e0: 0c00                                   |0010: move-result-object v0
09a2e2: 7210 7d15 0000                         |0011: invoke-interface {v0}, Ljava/util/Iterator;.hasNext:()Z // method@157d
09a2e8: 0a01                                   |0014: move-result v1
09a2ea: 3801 0c00                              |0015: if-eqz v1, 0021 // +000c
09a2ee: 7210 7e15 0000                         |0017: invoke-interface {v0}, Ljava/util/Iterator;.next:()Ljava/lang/Object; // method@157e
09a2f4: 0c01                                   |001a: move-result-object v1
09a2f6: 1f01 6504                              |001b: check-cast v1, Lcom/example/myapplication/Service; // type@0465
09a2fa: 7210 af13 0100                         |001d: invoke-interface {v1}, Lcom/example/myapplication/Service;.print:()V // method@13af
09a300: 28f1                                   |0020: goto 0011 // -000f
09a302: 0e00                                   |0021: return-void

I might be wrong, but could the problem be with this CHECKCAST instruction?

L0
    LINENUMBER 16 L0
    LDC Lorg/example/Service;.class
    LDC Lorg/example/Service;.class
    INVOKEVIRTUAL java/lang/Class.getClassLoader ()Ljava/lang/ClassLoader;
    INVOKESTATIC java/util/ServiceLoader.load (Ljava/lang/Class;Ljava/lang/ClassLoader;)Ljava/util/ServiceLoader;
    DUP
    LDC "load(...)"
    INVOKESTATIC kotlin/jvm/internal/Intrinsics.checkNotNullExpressionValue (Ljava/lang/Object;Ljava/lang/String;)V
    CHECKCAST java/lang/Iterable
    ASTORE 1
   L1
    ICONST_0
    ISTORE 2
   L2
    LINENUMBER 22 L2
    ALOAD 1
    INVOKEINTERFACE java/lang/Iterable.iterator ()Ljava/util/Iterator; (itf)
    ASTORE 3

Compare this to a regular for-loop call

L0
    LINENUMBER 8 L0
    LDC Lorg/example/Service;.class
    LDC Lorg/example/Service;.class
    INVOKEVIRTUAL java/lang/Class.getClassLoader ()Ljava/lang/ClassLoader;
    INVOKESTATIC java/util/ServiceLoader.load (Ljava/lang/Class;Ljava/lang/ClassLoader;)Ljava/util/ServiceLoader;
    INVOKEVIRTUAL java/util/ServiceLoader.iterator ()Ljava/util/Iterator;
    DUP
    LDC "iterator(...)"
    INVOKESTATIC kotlin/jvm/internal/Intrinsics.checkNotNullExpressionValue (Ljava/lang/Object;Ljava/lang/String;)V
    ASTORE 1

The checkcast instruction is most likely the cause after the null check is gone. Looking at https://r8.googlesource.com/r8/+/refs/heads/main/src/main/java/com/android/tools/r8/ir/optimize/ServiceLoaderRewriter.java#313 that is most likely the case. In the DEX above the check-cast is removed, as it is redundant, but maybe still there when the ServiceLoaderRewriter optimization is running.

If you add the rule "-whyareyounotinlining class java.util.ServiceLoader { *** load(...); } and build with INFO level (./gradlew --info ...) the actual reason for the missing optimization should be reported.

It says

.../StudioProjects/MyApplication/app/build/tmp/kotlin-classes/debug/com/example/myapplication/InitializerApplication.class: R8: Could not inline ServiceLoader.load of type com.example.myapplication.Service: The returned ServiceLoader instance must only be used in a call to `java.util.Iterator java.lang.ServiceLoader.iterator()`, but found other usages