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

Thanks for pointing this out. This is a limitation of aapt2, which has hardcoded support specifically for <fragment> to generate keep rules, but not for any kind of generic support that FragmentContainerView could use.

For the Fragment 1.2.0-rc01 release, we've disabled the Lint check that suggested moving from <fragment> to FragmentContainerView to avoid suggesting something that breaks your app in unpredictable ways.

FragmentContainerView is still useful in the cases where
1) Something outside of your Fragment references the Fragment class (this would prevent the class from being stripped entirely)
2) You do not use obfuscation (i.e., the name of the Fragment continues to match the name specified in your layout XML)

As we believe that is the majority of cases, we'll be leaving in support for android:name (and with the addition of https://issuetracker.google.com/issues/142722242, class="com.example.YourFragment") in FragmentContainerView for this release.

We'll also be working with the aapt2 team to make it easier for these automatic keep rules to be generated in such a way that would work for FragmentContainerView. I'll leave this issue open to track that work as well.

  The following changes were cherrypicked through Coastguard (https://android-build.googleplex.com/coastguard/)
  Release Track: (https://android-build.googleplex.com/coastguard/dashboard/6552735953321984/#/cherrypickHistory/all)
  Created: 2019-10-16 23:44:39.655960+00:00
  Changes: aosp/1145071
 

Fragment 1.2.0 stable is released. When is this getting fixed?

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