Status Update
No update yet.
Comments
il...@google.com
an...@google.com
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
ap...@google.com
Branch: androidx-master-dev
commit 41c9e54ce4ab51f95d19a55fa92a56b6bd018c62
Author: Ian Lake <ilake@google.com>
Date: Mon Mar 23 16:07:32 2020
Allow obfuscation of kept Fragments
Fragments that are kept solely by class
can safely be obfuscated.
By switching to keepclasseswithmembers,
only classes with a default constructor
will qualify to be kept. This also allows
shrinking of classes that are constructed
through a custom FragmentFactory.
Test: tested in sample app at
BUG: 151605338
Change-Id: I68ea8779bce80f33f27658cf87a94ccede5376b0
M fragment/fragment/proguard-rules.pro
il...@google.com
While -keepclassmembers caused a regression in the allowsObfuscation to allow even kept fragments to be obfuscated.
This will be available in the upcoming Fragment 1.2.4 and 1.3.0-alpha03.
sa...@peilicke.de
The new release 1.2.4 now leads to a direct crash on app-start, i.e. when Android tries to inflate any Fragment referenced in the main navigation graph.
il...@google.com
Re #5 - please file a new bug with a sample project that reproduces your issue.
[Deleted User] <[Deleted User]>
This change in 1.2.4 also leads to ClassNotFoundException when a fragment is created by providing a name attribute to a FragmentContainerView if the referenced fragment class name is not explicitly kept and obfuscation is enabled:
<androidx.fragment.app.FragmentContainerView
...
android:name="fullClassName"
... />
This, of course, is the expected behavior, but I think it is too much of an API-breaking change for a patch release.
il...@google.com
Re #7 - please make sure you've followed the instructions in FragmentContainerView referenced classes as per the
If you're using Android Gradle Plugin 4.1 Canary 4 or higher and you're not getting your classes properly kept and non-obfuscated when using FragmentContainerView, please
sa...@peilicke.de
Re #6: It's essentially
aa...@gmail.com
Thanks everyone
Description
Version used: androidx.fragment-fragment-1.2.2
Devices/Android versions reproduced on:
Either Android Gradle Plugin 3.5.3 or 3.6.0, build tools 28.0.3
Related (but not equivalent) issues:
Concerning the following consumer proguard rules we inherit:
# The default FragmentFactory creates Fragment instances using reflection
-if public class ** extends androidx.fragment.app.Fragment
-keep public class ** extends androidx.fragment.app.Fragment {
public <init>();
}
My understanding is that FragmentFactory requires R8 to be told that the default constructor to be kept, so it can be invoked via reflection. However I don't believe that requires the class' *name* to be kept, maybe I'm wrong here? A narrower rule that would meet the first requirement would be:
-keepclassmembers,allowobfuscation
Keeping the class name also keeps the package name the class is in, which also leads to greater portions an obfuscated app's internal directory structure appearing in clear text. (As a workaround we've often packaged Activities and Views separately and accepted that they're not well obfuscated, though it was a great convenience to us this was no longer the case with fragments). As a consequence, post-upgrade to 1.2.2 we notice many fragments and their directories appearing inside our app's APK, or by manual inspection of the mapping.txt