Status Update
Comments
jb...@google.com <jb...@google.com> #2
Jeremy, is this still an issue? I think the problem was that you had two transitions targeting the same View for the same action (e.g. two Slide() transitions).
kj...@google.com <kj...@google.com>
mk...@google.com <mk...@google.com>
mk...@google.com <mk...@google.com> #3
I have a similar issue with plain AnimatorSet:
set.start()
set.pause()
set.setCurrentPlayTime(100)
set.setCurrentPlayTime(0)
set.setCurrentPlayTime(100)
set.resume()
doesn't play animation in resume().
ga...@google.com <ga...@google.com> #4
Should clarify that if I filter out setCurrentPlayTime(0)
(or replace it with setCurrentPlayTime(1)
) it works well.
Also even with setCurrentPlayTime(0)
, onAnimationEnd
is notified with correct delay (as if the animation has played).
sg...@google.com <sg...@google.com> #5
@
I think that is intended for Animator. If you set the currentPlayTime
to 0 or the total duration the animator completes. We do some
ga...@google.com <ga...@google.com> #6
Did some investigation on the Fragment side and it seems like the merged transition is targeting correctly.
Exiting Transition: Slide@aa9288e: tgts(android.widget.LinearLayout{f9add3d})
>>>>> ExitingViews <<<<<
View: android.widget.LinearLayout{f9add3d}
Entering Transition: Slide@35b8af: tgts(android.widget.LinearLayout{b7f24bc})
>>>>> EnteringViews <<<<<
View: android.widget.LinearLayout{b7f24bc}
Final merged transition: TransitionSet@7bc1c45:
TransitionSet@e133f9a:
Slide@aa9288e: tgts(android.widget.LinearLayout{f9add3d})
Slide@35b8af: tgts(android.widget.LinearLayout{b7f24bc})
merged transition passed to controlDelayedTransition: TransitionSet@7bc1c45:
TransitionSet@e133f9a:
Slide@aa9288e: tgts(android.widget.LinearLayout{f9add3d})
Slide@35b8af: tgts(android.widget.LinearLayout{b7f24bc})
Still digging.
sg...@google.com <sg...@google.com> #7
Branch: androidx-main
commit 567b7459329d1ec8d27a8c6fe1c4a86442065d7d
Author: Jeremy Woods <jbwoods@google.com>
Date: Tue Sep 26 20:06:54 2023
Add additional logging for transitions
Adding more debug logging in transitions to track the entering and
exiting transitions as well as the final merged transition and its
targets.
Test: added logging
Bug: 300157785
Change-Id: I0d9ad72b865422493c6c895ddb6115abf85eed16
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.kt
py...@squareup.com <py...@squareup.com> #8
So I have isolated this outside of fragment into something much simpler and I think it breaks down when it comes to the adding and removing of Views with animateToStart.
The attached sample is a simple add that goes between two screens BLUE
and GREEN
. It has code for both the 1.5.0-alpha03
and 1.5.0-alpha04
versions, but I think alpha04 is currently broken in another way so I will upload the alpha03 version here.
This is integrated with predictive back similar to how fragment is, so upon cancelling we call animateToStart
, then we do a beginDelayedTransition
on a 0
duration Fade()
and we reverse the view visibility back to what it was prior to starting the transition.
If you only do visibility, cancel always works the view never goes away, it is wonderful, but when you do adding and removing views like we need to in fragment it fails.
First the code for beginDelayedTransition goes from this:
TransitionManager.beginDelayedTransition(container, Fade().apply {
duration = 0
})
reverseViews()
to this:
TransitionManager.beginDelayedTransition(container, Fade().apply {
duration = 0
addListener(onEnd = {
reverseViews()
blueScreen.visibility = View.VISIBLE
greenScreen.visibility = View.VISIBLE
})
})
reverseViews(useVisibility = true)
We need to make this change because after the animateToStart()
view is still parented by the overlay, so we call reverseViews(useVisibility = true)
to only change the visibility and then once the transition finishes we can call reverseViews()
to parent the view properly, then we make both views visible again.
From our perspective after the 0
duration transition our views are back in the proper state, but they do not transition properly after a cancel.
If the app is doing this wrong and we can make the appropriate fixes, doing the same in fragment should resolve this. There is logging available that shows the state of the views when we start the transition.
xa...@google.com <xa...@google.com> #9
The API has changed since that project was created in a way that makes the API more robust. I'm hoping that has fixed this...
sg...@google.com <sg...@google.com> #10
There appears to be a problem with the order of operations. I'm going to look into fixing that.
ga...@google.com <ga...@google.com> #11
Branch: androidx-main
commit e57dd5f9ac6cbb8cf83b221e2d5b3fbd3e88ce6b
Author: George Mount <mount@google.com>
Date: Thu Nov 09 14:33:53 2023
Fix animateToStart with Slide.
Fixes: 300157785
Slide was not repositioning the View to its proper
translation after animating it to the start position.
This fixes that so that it is moved.
Test: new test
Change-Id: I698f4dbcef46304f9aa545847d205f7b70c80d63
M transition/transition/src/androidTest/java/androidx/transition/SlideEdgeTest.java
M transition/transition/src/androidTest/java/androidx/transition/TranslationAnimationCreatorTest.java
M transition/transition/src/main/java/androidx/transition/TranslationAnimationCreator.java
xa...@google.com <xa...@google.com> #12
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.transition:transition:1.5.0-alpha05
ga...@google.com <ga...@google.com> #13
We were emitting warnings for every missing type, but because libraries ship with JVM and android code in the same jar, some types cannot be resolved correctly for code that's unreachable and users were complaining about the noisy logging, so we downgraded to info.
Using compileOnly
is very common for annotation processors, so disabling artifact transforms in this use case may impact significant number of users unnecessarily.
ga...@google.com <ga...@google.com>
il...@google.com <il...@google.com> #14
FWIW, we've added a workaround in the Lifecycle library for this particular problem in
If testing a fix on the AGP side, make sure to Lifecycle 2.5.0-rc01 or earlier to reproduce this crash as we'll silently be working around the incorrectly generated output on later versions.
to...@gmail.com <to...@gmail.com> #15
However, this solution will no longer be available. This is because this option has been deprecated in AGP 8.0 and will be removed in 8.2.
Could you please postpone the removal of the enableDexingArtifactTransform until the desugar issue regarding compileOnly is resolved?
to...@gmail.com <to...@gmail.com> #16
hu...@google.com <hu...@google.com> #17
Could you please postpone the removal of the enableDexingArtifactTransform until the desugar issue regarding compileOnly is resolved?
Yes, we'll need to fix this issue first before removing the property.
This is puzzling, but in my project, if I enable minify in the app module, desugar seems to run fine even with enableDexingArtifactTransform=true.
That's correct, it's because with minifyEnabled = true
we have a different pipeline which doesn't use dexing transforms.
hu...@google.com <hu...@google.com> #18
Update: Starting with AGP 8.3.0-alpha06, the workaround for this issue is to enable the following property in gradle.properties
:
android.useFullClasspathForDexingTransform = true
For more details on this property, please see
We're not enabling this property by default yet because it has some performance overhead and most projects don't need it.
Next steps:
- Measure the performance impact of enabling this property. (Please let us know if it significantly slows down your build.)
- Measure how many projects need to use this property.
hu...@google.com <hu...@google.com> #19
Downgrading this issue to P2 as there is a workaround & we will address this issue in a future release once we have more data (
z-...@unext.jp <z-...@unext.jp> #20
The workaround android.useFullClasspathForDexingTransform = true
breaks baseline profile generation.
You can simply reproduce it in NowInAndroid. Just add android.useFullClasspathForDexingTransform = true
into gradle.properties
and run ./gradlew :app:generateBaselineProfile
.
It will output many errors like this:
Found multiple transforms that can produce a variant of com.caverock:androidsvg-aar:1.4 with requested attributes:
- artifactType 'android-asm-instrumented-jars'
- com.android.build.api.attributes.AgpVersionAttr '8.3.0'
- com.android.build.api.attributes.BuildTypeAttr 'nonMinifiedRelease'
- com.android.build.api.attributes.ProductFlavor:contentType 'demo'
- org.gradle.category 'library'
- org.gradle.jvm.environment 'android'
- org.gradle.usage 'java-runtime'
- org.jetbrains.kotlin.platform.type 'androidJvm'
Found the following transforms:
- From 'com.caverock:androidsvg-aar:1.4 configuration runtime':
- With source attributes:
- artifactType 'aar'
- org.gradle.category 'library'
- org.gradle.libraryelements 'jar'
- org.gradle.status 'release'
- org.gradle.usage 'java-runtime'
- Candidate transform(s):
- Transform 'AarToClassTransform -> AsmClassesTransform' producing attributes:
- artifactType 'android-asm-instrumented-jars'
- asm-transformed-variant 'demoBenchmarkRelease'
- org.gradle.category 'library'
- org.gradle.libraryelements 'jar'
- org.gradle.status 'release'
- org.gradle.usage 'java-runtime'
- Transform 'AarToClassTransform -> AsmClassesTransform' producing attributes:
- artifactType 'android-asm-instrumented-jars'
- asm-transformed-variant 'demoDebug'
- org.gradle.category 'library'
- org.gradle.libraryelements 'jar'
- org.gradle.status 'release'
- org.gradle.usage 'java-runtime'
- Transform 'AarToClassTransform -> AsmClassesTransform' producing attributes:
- artifactType 'android-asm-instrumented-jars'
- asm-transformed-variant 'demoNonMinifiedRelease'
- org.gradle.category 'library'
- org.gradle.libraryelements 'jar'
- org.gradle.status 'release'
- org.gradle.usage 'java-runtime'
- Transform 'AarToClassTransform -> AsmClassesTransform' producing attributes:
- artifactType 'android-asm-instrumented-jars'
- asm-transformed-variant 'demoRelease'
- org.gradle.category 'library'
- org.gradle.libraryelements 'jar'
- org.gradle.status 'release'
- org.gradle.usage 'java-runtime'
- Transform 'AarToClassTransform -> AsmClassesTransform' producing attributes:
- artifactType 'android-asm-instrumented-jars'
- asm-transformed-variant 'prodBenchmarkRelease'
- org.gradle.category 'library'
- org.gradle.libraryelements 'jar'
- org.gradle.status 'release'
- org.gradle.usage 'java-runtime'
- Transform 'AarToClassTransform -> AsmClassesTransform' producing attributes:
- artifactType 'android-asm-instrumented-jars'
- asm-transformed-variant 'prodDebug'
- org.gradle.category 'library'
- org.gradle.libraryelements 'jar'
- org.gradle.status 'release'
- org.gradle.usage 'java-runtime'
- Transform 'AarToClassTransform -> AsmClassesTransform' producing attributes:
- artifactType 'android-asm-instrumented-jars'
- asm-transformed-variant 'prodNonMinifiedRelease'
- org.gradle.category 'library'
- org.gradle.libraryelements 'jar'
- org.gradle.status 'release'
- org.gradle.usage 'java-runtime'
- Transform 'AarToClassTransform -> AsmClassesTransform' producing attributes:
- artifactType 'android-asm-instrumented-jars'
- asm-transformed-variant 'prodRelease'
- org.gradle.category 'library'
- org.gradle.libraryelements 'jar'
- org.gradle.status 'release'
- org.gradle.usage 'java-runtime'
The generation will also be failed if you disable this property due to the crash described in this issue. Any way to fix or avoid this error? If not, could you please upgrade this issue?
hu...@google.com <hu...@google.com> #21
Thanks a lot for letting us know!
I've filed
hu...@google.com <hu...@google.com> #22
cc team for visibility: The android.useFullClasspathForDexingTransform = true
flag (java.lang.AbstractMethodError
issues (e.g.,
Description
Lifecycle: 2.5.0-alpha01 - 2.5.0-beta01
Devices/Android versions reproduced on: Emulator & various tablets 5.0 - 11.
If this is a bug in the library, we would appreciate if you could attach:
Anything with a minsdk under API 24 will cause the crash. So it somehow ties into the Java 8, desugaring, and Kotlin interface default methods I think.
Seehttps://github.com/square/leakcanary/issues/2314 for extra details.