IssueTracker

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 from https://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

There's nothing custom here in the before or after step and the purpose of copying the resources is just to get the correct behaviour. Since this is client work I'm not sure if I can share the app, but I can try to reproduce this in isolation, if I can't then there must be something else in the app setup that is messing with the transition somehow.

Here's an example project that shows the problem in isolation.

I think what you are seeing is that the fragment_open_exit is only fading out to 0.4 alpha, while the fragment_open_exit from the CL is fading out to 0 alpha.

This seems to be the same value as the platform version of activity_open_exit so in that sense it appears that the original CL had incorrect values, though I'd say that the effect as a default transition doesn't look very pleasing to me personally.

Using this project and replacing `setTransition(FragmentTransaction.TRANSIT_FRAGMENT_OPEN)` with `setCustomAnimations(R.anim.fragment_open_enter, R.anim.fragment_open_exit)` looks the same and it matches the animations for activity in the framework. So while the new animations might not be what is desired visually in this particular case, it is working as intended, and using `setCustomAnimations()` is the proper thing to do.

I'm going to do one last attempt to convince you :) Technically you are correct: the transitions are the same as the activity transitions. However, _visually_ they are not.
Activities always have a window background, while fragments may not have this, they rely on the activity window background. The transition only fades out the exiting fragment to 40% alpha, so it keeps bleeding through if you have no background set on your fragment which is very common.

My second argument here is that this will impact a lot of apps. Many apps use the default transitions and just upgrading to the latest fragment library will force them to implement custom transitions. You are really breaking a bunch of apps this way.

I would strongly ask to take another close look at how these transitions should look _visually_ with a common default setup like the test project I supplied, letting go from the fact that the transition files are technically the same as the platform supplied ones for the activities in the platform.

The main goal should be a sensible default transition for those who don't have or don't want to use setCustomAnimations. This was the case in previous releases of fragments and it's clearly not the case any more now. This is really a regression.

For reference I'm attaching the transition with the same layouts, but running the activity based transition + an updated project.

Please reopen this ticket.

The new transitions cause a breaking change and hence will put a lot of burden upon developers. A minor transition change would have been ok, but now apps will end up with visually broken transistions and they may not have an easy central way to opt out for all screens.

Even more, it might lead to developers resorting to a quick fix and just adding a window background to all fragments causing overdraw.

The new TRANSIT_FRAGMENT_OPEN animation looks significantly different from the old one and that was an intentional change in coordination with the Material Design team. The same is true for the CLOSE and FADE animations. You should expect those animations to continue to change with future releases of Fragments.

That being said, I will reopen the issue and share this information with the designers on the Material team so that they can modify the animations or confirm that what you're seeing is expected.

Project: platform/frameworks/support
Branch: androidx-master-dev

commit 0fb5fcd5139c455652796230b7982a9fc63c8f7a
Author: Jeremy Woods <jbwoods@google.com>
Date:   Thu Dec 05 15:03:24 2019

    Adjust the default fragment transition presets
   
    The current fragment transition presets did not take into consideration
    that fragments rarely have a non-opaque background. This change adjusts
    the fragment presets with specifications specifically for fragments.
   
    The open and close transitions now have a duration of 300 instead of 400
    and the fade transition has a duration of 150. The open transition fades
    the exiting view to an alpha of 0 instead of 0.4.
   
    Test: Tested in muliple applications
    BUG: 145468417
    Change-Id: I6e1be474d0bb218e4a519bb09ea5bc1fc1757dcf

M       fragment/fragment/src/main/res/anim/fragment_close_enter.xml
M       fragment/fragment/src/main/res/anim/fragment_close_exit.xml
M       fragment/fragment/src/main/res/anim/fragment_fade_enter.xml
M       fragment/fragment/src/main/res/anim/fragment_fade_exit.xml
M       fragment/fragment/src/main/res/anim/fragment_open_enter.xml
M       fragment/fragment/src/main/res/anim/fragment_open_exit.xml

https://android-review.googlesource.com/1183003

This has been fixed internally and will be available in the Fragment 1.2.0-rc04 release.

Here is how the new presets will look given sample app from #4.

Thanks, that looks much better!

  The following changes were cherrypicked through Coastguard (https://android-build.googleplex.com/coastguard/)
  Release Track: (https://android-build.googleplex.com/coastguard/dashboard/6552735953321984/#/history/all)
  Created: 2019-12-09 19:09:00.495077+00:00
  Changes: aosp/1183003