Fixed
Status Update
Comments
il...@google.com <il...@google.com> #2
I created a thread on the android-developers forum related to this bug:
http://groups.google.com/group/android-
developers/browse_thread/thread/6caa57135927e242/86d4d895e88a5ebb?
lnk=gst&q=custom+account#86d4d895e88a5ebb
developers/browse_thread/thread/6caa57135927e242/86d4d895e88a5ebb?
lnk=gst&q=custom+account#86d4d895e88a5ebb
ap...@google.com <ap...@google.com> #3
My personal theory is that Google broke this part of the API intentionally to keep
the lock-in on sync functionality they've enjoyed since Android 1.0.....
the lock-in on sync functionality they've enjoyed since Android 1.0.....
Description
Component used: Fragment Version used: 1.3.0 Devices/Android versions reproduced on: Any
Occurs when we use BottomSheetDialogFragment after updating androidx.fragment:fragment from 1.2.5 to 1.3.0.
Steps to reproduce:
container
container
Expected: A child fragment is added into our container specified in the layout. Actual result: A child fragment added into the container used for CoordinatorLayout.Expected view hierarchy (1.2.5):
Actual view hierarchy (1.3.0):
It seems that it happens because in 1.3.0 a code for finding the right container to use for fragment transaction was changed. A new implementation for DialogFragment is looking for the container starting from the top of hierarchy (DecorView):
At the same time it's different for Fragment:
The only workaround we found is to use a different id for our container, anything but
container
. But this doesn't seem appropriate as we could have a ton of BottomSheets in the project and this kind of id clashing is resolved very well in ordinary fragments.