IssueTracker

The sample project that produces the issue (as shown in BugVideo.mov) is available at:
https://github.com/ericmaxwell2003/issuetracker-131557151-fragment

I suspect that we're just not setting the default state to be capped at STARTED and you'd see the same oscillation with setUserVisibleHint(). We should just fix it for both cases though

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

commit 97519ce890a194fd21c47696996f90ac00920868
Author: jbwoods <jbwoods@google.com>
Date:   Mon Apr 29 13:18:22 2019

    Allow reordering when calling setMaxLifecycle in FragmentPagerAdapter
   
    When FragmentPagerAdapter (or FragmentStatePagerAdapter) call
    instantiateItem(), instead of the new added Fragment just being capped
    at the STARTED state, it first goes to RESUMED, then returns to the
    STARTED state.
   
    This is caused because setMaxLifecycle is split into 2 separate Ops (a
    set maxLifecycleState and an unset maxLifecycleState). These Ops are executed
    separately and both change the Fragment state. There is no need to unset
    the maxLifecycleState of a Fragment when it is first added, so the unset
    Ops becomes redundant. Setting allow reordering to true allows the
    FragmentManager to remove the redundant unset Op. This means new
    Fragments are correctly capped at STARTED, without the need to go to
    RESUMED first.
   
    Test: confirmed in test app
    Bug: 131557151
    Change-Id: I92feb1eeb3cbb0156d2d59eb698547fd5f061e85

M       fragment/src/main/java/androidx/fragment/app/FragmentPagerAdapter.java
M       fragment/src/main/java/androidx/fragment/app/FragmentStatePagerAdapter.java

https://android-review.googlesource.com/953918
https://goto.google.com/android-sha1/97519ce890a194fd21c47696996f90ac00920868

We've reverted the above change in https://android-review.googlesource.com/954182 since it is no longer needed - we've fixed setMaxLifecycle() to work with and without setReorderingAllowed(true) in https://android-review.googlesource.com/954024

This will be available in the next release of Fragments.

You can put a @Keep annotation over the Fragment classes used with FragmentContainerView. It's as easy as that.

Well it is easy to add the @Keep annotation if the fragment is yours... but what if you are using for example SupportMapFragment?

My solution for the NavHostFragment with the FragmentContainerView is to add this to your ProGuard rules:

-keepnames class androidx.navigation.fragment.NavHostFragment

Any plans on fixing it in nearest feature without workarounds?

P.S. Why it wasn't possible to fix the issue before releasing stable?
Adding @Keep manually sounds like it is 2015 now developers should struggle with their own set of rules for every single components.

Project: platform/frameworks/base
Branch: master

commit 4bdc698d9f8fb4f85464d554cabeb954104ec0a3
Author: Jeremy Woods <jbwoods@google.com>
Date:   Fri Feb 28 19:42:38 2020

    Generate "keep" rules for android:name and class attributes
   
    We should keep classes that are in the android:name or class xml
    attributes.
   
    Test: m -j aapt2_tests
    Bug: 142601969
    Change-Id: Ia67365bd702bae75d38b9572d68e9930e856e0f8

M       tools/aapt2/java/ProguardRules.cpp
M       tools/aapt2/java/ProguardRules_test.cpp

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

AGP will not back port these since it's too late in the release process for them. However, you can force older AGP to use the newer aapt2.
You can do it in two ways, with the first approach being much safer:
1) In your build.gradle force gradle to use the newer version:
configurations.matching { it.name == '_internal_aapt2_binary' }.all { config ->
        config.resolutionStrategy.eachDependency { details ->
            details.useVersion("4.1.0-alpha04-6296993")
        }
    }

2) If for some reason the above doesn't work, you can manually download the gmaven jar file for "com.android.tools.build:aapt2:4.1.0-alpha04-6296993" (https://dl.google.com/dl/android/maven2/com/android/tools/build/aapt2/4.1.0-alpha04-6296993/aapt2-4.1.0-alpha04-6296993-[windows/darwin/linux].jar - choose the right platform), unpack somewhere and use android.aapt2FromMavenOverride to set the path to the aapt2 executable you want to use. Be careful to use the right platform.

Note: check the version when it comes out, most likely it should match this but it's possible we update the prebuilts again before then. 4.1 canary 4 is not out yet, so this will only be available in gmaven once that canary is released.

Follow pre-release version updates here: https://androidstudio.googleblog.com/

Gracias