Fixed
Status Update
No update yet.
Comments
su...@google.com
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit b55fe68edc02b253b908a1c7c2e98350ba67afe4
Author: Ian Lake <ilake@google.com>
Date: Wed Aug 12 14:21:57 2020
Ignore Animations/Animator when Transitions run
For a given Fragment, a single owner for its
transition from visible to non-visible is needed
to avoid conflicts as different systems try to
influence the same set of properties.
This has two consequences:
- Animations (which work at the parent container level)
will interfere if there are *any* Transitions run.
- Animators will interfere if there are any Transitions
run on that specific Fragment.
By tracking which Transitions were started and using
that information to selectively ignore conflicting
Animations/Animators, we can avoid visual artifacts.
Test: updated tests pass
BUG: 149569323
Change-Id: I9e5169ffd36853c3dfbd7f217837a74674a9508d
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentTransitionAnimTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
https://android-review.googlesource.com/1398530
Branch: androidx-master-dev
commit b55fe68edc02b253b908a1c7c2e98350ba67afe4
Author: Ian Lake <ilake@google.com>
Date: Wed Aug 12 14:21:57 2020
Ignore Animations/Animator when Transitions run
For a given Fragment, a single owner for its
transition from visible to non-visible is needed
to avoid conflicts as different systems try to
influence the same set of properties.
This has two consequences:
- Animations (which work at the parent container level)
will interfere if there are *any* Transitions run.
- Animators will interfere if there are any Transitions
run on that specific Fragment.
By tracking which Transitions were started and using
that information to selectively ignore conflicting
Animations/Animators, we can avoid visual artifacts.
Test: updated tests pass
BUG: 149569323
Change-Id: I9e5169ffd36853c3dfbd7f217837a74674a9508d
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentTransitionAnimTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
su...@google.com
There are two parallel systems in Android - the Animation system and the Animator system (which the Transition system is built on top of). With this change and Fragment 1.3.0-alpha08, no Animation will run if there are any Transitions kicked off at the same time and no Animator will run on Fragments that have Transitions directly associated with them (either via an enter/exit transition or as part of a shared element transition).
Description
Version used: 1.0.0-alpha06
Devices/Android versions reproduced on: Many
We can see a large number of ConcurrentModificationExceptions in WorkManager:
java.lang.RuntimeException: Error receiving broadcast Intent { act=android.net.conn.CONNECTIVITY_CHANGE flg=0x4000010 bqHint=4 (has extras) } in vu@2406837b
at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:988)
at android.os.Handler.handleCallback(Handler.java:739)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:145)
at android.app.ActivityThread.main(ActivityThread.java:7007)
at java.lang.reflect.Method.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1404)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1199)
Caused by: java.util.ConcurrentModificationException
at java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:346)
at java.util.LinkedHashMap$KeyIterator.next(LinkedHashMap.java:366)
at androidx.work.impl.constraints.trackers.ConstraintTracker.setState(OperaSrc:89)
at androidx.work.impl.constraints.trackers.NetworkStateTracker$NetworkStateBroadcastReceiver.onReceive(OperaSrc:157)
at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:978)
It looks like the mListeners set is being modified during the loop in ConstraintTracker.setState(). I see two potential issues with this method:
1. Maybe a listener is added or removed in onConstraintChanged(). I haven't seen this happen, but it might be good to make a copy of mListeners and iterate over the copy.
2. The NetworkStateTracker.mNetworkCallback is called on a different thread than the main thread. In consequence setState() is called on a different thread so there is a possibility that the main thread adds or removes a listener. This cannot be the (only) reason because the error happens in response to the CONNECTIVITY_CHANGE.
This may be fixed with synchronization or by registering mNetworkCallback to run on the main thread.