Status Update
Comments
jb...@google.com <jb...@google.com>
an...@google.com <an...@google.com> #2
Branch: androidx-master-dev
commit 164bb50bcabe96a05e80c2d9ce03533e1dc6d26e
Author: Ian Lake <ilake@google.com>
Date: Mon Oct 14 11:03:23 2019
Fix FragmentContainerView inflation with obfuscation
Instead of using a literal for the class name, using
FragmentContainerView.class.getName() to support
obfuscation via ProGuard.
Test: ran testapp with obfuscation
Fixes: 142657034
Change-Id: I9ae40ddb5d3308790d6963f09f3eb110837dbb4c
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentLayoutInflaterFactory.java
il...@google.com <il...@google.com> #3
an...@google.com <an...@google.com> #4
my...@gmail.com <my...@gmail.com> #5
ta...@gmail.com <ta...@gmail.com> #6
[Deleted User] <[Deleted User]> #7
mi...@gmail.com <mi...@gmail.com> #8
-keepnames class androidx.navigation.fragment.NavHostFragment
[Deleted User] <[Deleted User]> #9
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.
ey...@gmail.com <ey...@gmail.com> #10
Disabling the lint check is one thing, but lots of developers heard about this being the way forward for embedded fragments. They would probably assume that it would work with R8 (like I did), and possibly cause a crash in a production app (like I did; luckily in a pre release build).
ap...@google.com <ap...@google.com> #11
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
jb...@google.com <jb...@google.com> #12
This has been fixed internally, and should be available in the Android Gradle Plugin 4.1-alpha04 release.
my...@gmail.com <my...@gmail.com> #13
Will it get backported to 3.6 and 4.0?
im...@google.com <im...@google.com> #14
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 {
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" (
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.
ka...@gmail.com <ka...@gmail.com> #15
Can you add the alpha releases and their notes to the Android Gradle Plugin releases page? There's currently no mention of 4.1 on
e....@gmail.com <e....@gmail.com> #16
ga...@gtempaccount.com <ga...@gtempaccount.com> #17
This has not been fixed in 4.1.0, you need to use a workaround like
il...@google.com <il...@google.com> #18
Re #17 - this certainly has been fixed and verified when using Android Gradle Plugin 4.1.0 or higher. If you're seeing differently, please attach a sample project that reproduces your issue.
Description
Version used: 1.2.0-beta02
Devices/Android versions reproduced on: all
When the only reference to a Fragment is via a FragmentContainerView's android:name, it seems like ProGuard strips the class out, causing crashes in release builds. I expected it to work just like the <fragment> tag in that the class would automatically be kept.
Reproduction steps:
1) Check out Muzei's v3.3.0-beta2 tag
2) Add minifyEnabled true to the debug type in main/build.gradle
3) Build a debug APK / bundle
4) Inspect the dex output and note that the AutoAdvanceFragment (used in the choose_provider_fragment.xml layout) does not exist.
Switching back to <fragment> fixes the issue.