Fixed
Status Update
No update yet.
Comments
il...@google.com
jb...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit 57ca221882695bd6a52549f4d9ea3b812e6fe87c
Author: Simon Schiller <simonschiller@users.noreply.github.com>
Date: Mon Mar 22 16:09:30 2021
[GH] [FragmentStrictMode] Detect <fragment> tag usage
## Proposed Changes
- Detect `<fragment>` tag usage inside XML layouts
## Testing
Test: See `FragmentStrictModeTest#detectFragmentTagUsage`
## Issues Fixed
Fixes: 153738235
This is an imported pull request fromhttps://github.com/androidx/androidx/pull/141 .
Resolves #141
Github-Pr-Head-Sha: 4ea052596e4341b9f11bcf335e2bc38045a91f19
GitOrigin-RevId: 62e7487aa4874eef6bb556490e193717cf937251
Change-Id: Iae48578e85e4e4897f806d7ade2e2a660adf9479
M fragment/fragment/api/public_plus_experimental_current.txt
M fragment/fragment/api/restricted_current.txt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/strictmode/FragmentStrictModeTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentLayoutInflaterFactory.java
M fragment/fragment/src/main/java/androidx/fragment/app/strictmode/FragmentStrictMode.java
A fragment/fragment/src/main/java/androidx/fragment/app/strictmode/FragmentTagUsageViolation.java
https://android-review.googlesource.com/1649748
Branch: androidx-main
commit 57ca221882695bd6a52549f4d9ea3b812e6fe87c
Author: Simon Schiller <simonschiller@users.noreply.github.com>
Date: Mon Mar 22 16:09:30 2021
[GH] [FragmentStrictMode] Detect <fragment> tag usage
## Proposed Changes
- Detect `<fragment>` tag usage inside XML layouts
## Testing
Test: See `FragmentStrictModeTest#detectFragmentTagUsage`
## Issues Fixed
Fixes: 153738235
This is an imported pull request from
Resolves #141
Github-Pr-Head-Sha: 4ea052596e4341b9f11bcf335e2bc38045a91f19
GitOrigin-RevId: 62e7487aa4874eef6bb556490e193717cf937251
Change-Id: Iae48578e85e4e4897f806d7ade2e2a660adf9479
M fragment/fragment/api/public_plus_experimental_current.txt
M fragment/fragment/api/restricted_current.txt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/strictmode/FragmentStrictModeTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentLayoutInflaterFactory.java
M fragment/fragment/src/main/java/androidx/fragment/app/strictmode/FragmentStrictMode.java
A fragment/fragment/src/main/java/androidx/fragment/app/strictmode/FragmentTagUsageViolation.java
jb...@google.com
Sorry, that message is not correct yet.
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 47c5e9d30d0304a7d1ac6a522c01a055b858ff28
Author: Jeremy Woods <jbwoods@google.com>
Date: Mon Aug 24 14:47:02 2020
Use view alpha to store the view animation state
Currently when using the new state manager, we save the visibility of
the view from onViewCreated() to do proper effects. This visibility
is restored after onStart() when any special effects are complete.
Because we always restore the visibility to whatever it was in
onViewCreated(), we fail to capture any changes that could have been
made by the user between onViewCreated() and onStart(). This means if
view animating in is set to INVISIBLE in onStart(), we force it back to
VISIBILE once the animation is complete.
Since there are still cases where users set their visibility directly on
their views, we need to ensure we are backward compatible. To do so,
instead of storing the view visibility, we should use the view alpha.
Anything above an alpha of 0 is considered visibile. Doing this means we
can handle the case where the visibility is changed, but the
suggestively more rare case of the alpha changing will suffer from the
old issue.
Test: FragmentViewTest, PostponedTransitionTest
Bug: 164481490
Change-Id: I9df6398af8e0404638e83b69319e4bd32bdbc3f2
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentAnimationTest.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentAnimatorTest.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentViewTest.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/PostponedTransitionTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/Fragment.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentStateManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/SpecialEffectsController.java
https://android-review.googlesource.com/1404407
Branch: androidx-master-dev
commit 47c5e9d30d0304a7d1ac6a522c01a055b858ff28
Author: Jeremy Woods <jbwoods@google.com>
Date: Mon Aug 24 14:47:02 2020
Use view alpha to store the view animation state
Currently when using the new state manager, we save the visibility of
the view from onViewCreated() to do proper effects. This visibility
is restored after onStart() when any special effects are complete.
Because we always restore the visibility to whatever it was in
onViewCreated(), we fail to capture any changes that could have been
made by the user between onViewCreated() and onStart(). This means if
view animating in is set to INVISIBLE in onStart(), we force it back to
VISIBILE once the animation is complete.
Since there are still cases where users set their visibility directly on
their views, we need to ensure we are backward compatible. To do so,
instead of storing the view visibility, we should use the view alpha.
Anything above an alpha of 0 is considered visibile. Doing this means we
can handle the case where the visibility is changed, but the
suggestively more rare case of the alpha changing will suffer from the
old issue.
Test: FragmentViewTest, PostponedTransitionTest
Bug: 164481490
Change-Id: I9df6398af8e0404638e83b69319e4bd32bdbc3f2
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentAnimationTest.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentAnimatorTest.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentViewTest.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/PostponedTransitionTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/Fragment.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentStateManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/SpecialEffectsController.java
il...@google.com
This has been fixed internally and will be available in the next release of Fragments.
Description
When using the new state manager released in fragment 1.3.0-alpha08, if you manually (without using the hide/show fragment transactions) set the visibility state of your view after the SpecialEffectsController has started any animations/transitions on your view, the visibility changes are ignored.
The reason this happens is because the new state manager saves the visibility state of the view in
onViewCreated()as the final state and then restores that visibility state once the special effect completes afteronStart(). This means that any changes made by the user to the view visibility state betweenonViewCreate()andonStart()are completely ignored.This becomes apparent in two particular cases:
There is a fragment that is always added, but has its visibility state updated based on some internal data (i.e. an error screen that is set to
View.INVISIBLEwhen there is no error andView.VISIBLEwhen there is one). If the view state changes toINVISIBLEinonStart(), the fragment should not be shown once the add transaction completes.A entering fragment is postponed and while it is postponed, its view visibility state is set to
View.INVISIBLE. Even once the fragment is no longer postponed, its view should still beINVISIBLEuntil the user changes it again manually.The new state manager should defer view visibility state control to the user no matter when the state is changed. Doing so would ensure that the user always has the source of truth for their Fragment's view visibility.