Fixed
Status Update
Comments
il...@google.com <il...@google.com>
an...@google.com <an...@google.com> #2
Please include a sample project that reproduces your issue.
ap...@google.com <ap...@google.com> #3
Here is the sample project.
Steps to reproduce:
1. Press on "Search" icon;
2. Write something;
3. Search this text, keyboard will be dismissed;
4. Tap on "Dialog" button;
5. Dissmiss dialog;
With the new 1.5.0 fragment library version text will be cleared in the search box after dismissing dialog.
In the version 1.4.1 and lower text in the search is not clearing and this is correct behaviour.
Please suggest some workarounds or how to fix this issue?
Steps to reproduce:
1. Press on "Search" icon;
2. Write something;
3. Search this text, keyboard will be dismissed;
4. Tap on "Dialog" button;
5. Dissmiss dialog;
With the new 1.5.0 fragment library version text will be cleared in the search box after dismissing dialog.
In the version 1.4.1 and lower text in the search is not clearing and this is correct behaviour.
Please suggest some workarounds or how to fix this issue?
il...@google.com <il...@google.com> #4
Hello, have you checked sample project? I hope it will help find the issue.
sa...@peilicke.de <sa...@peilicke.de> #5
il...@google.com <il...@google.com> #6
Hello, any update please?
[Deleted User] <[Deleted User]> #7
Hello
I raised similar issue with this ticket
This makes the SearchView unusable/broken when fragments are changed (i.e base on searchView input query)
What can we do to fix this problem? What is the progress of work on solving this problem?
il...@google.com <il...@google.com> #8
@7 Check @5 for a workaround.
sa...@peilicke.de <sa...@peilicke.de> #9
Hi, i am also facing this issue after we dismiss a DialogFragment, the callback comes in the onPrepareOptionsMenu(), which is causing the issues for me.
Any idea on when it will be fixed?
Any idea on when it will be fixed?
aa...@gmail.com <aa...@gmail.com> #10
Hello, any estimate please?
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