Status Update
Comments
sg...@google.com <sg...@google.com>
sg...@google.com <sg...@google.com> #3
However, during predictive back animation the entering screen is drawn on top of the exiting screen as the video linked in the issue also reproduces
navigation library used: 2.8.0-alpha06
a....@gmail.com <a....@gmail.com> #4
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?
ag...@google.com <ag...@google.com> #5
Once a sample project is provided we will reopen this issue, as we cannot reproduce this at the moment.
sg...@google.com <sg...@google.com> #6
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)
a....@gmail.com <a....@gmail.com> #7
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
sg...@google.com <sg...@google.com> #8
The checkcast
instruction is most likely the cause after the null check is gone. Looking at 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.
a....@gmail.com <a....@gmail.com> #9
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
Description
I'm using AGP 8.6 and gradle 8.7, if I change it to normal for loop everything works as expected.