Fixed
Status Update
Comments
il...@google.com <il...@google.com>
ap...@google.com <ap...@google.com> #2
When you include androidx.lifecycle:lifecycle-runtime-ktx:2.2.0-alpha05, you are upgrading all of its transitive dependencies, which includes lifecycle-runtime. However, you are *not* upgrading lifecycle-process, which is still using the version of lifecycle from your lifecycle-extensions dependency (2.1.0).
You do any one of the following:
- Add an explicit dependency on lifecycle-process:2.2.0-alpha05 to pull in the new version that is compatible with lifecycle-runtime:2.2.0-alpha05
- Upgrade your lifecycle:extensions dependency to 2.2.0-alpha05 so that lifecycle-process is upgraded
- Remove the lifecycle:extensions dependency entirely and use only the lifecycle libraries you need (for example, use lifecycle-viewmodel-ktx if you want ViewModels) so that you don't pull in lifecycle-process at all
Mixing and matching Lifecycle versions is not a supported configuration, so I'd recommend keeping to using just a single version.
You do any one of the following:
- Add an explicit dependency on lifecycle-process:2.2.0-alpha05 to pull in the new version that is compatible with lifecycle-runtime:2.2.0-alpha05
- Upgrade your lifecycle:extensions dependency to 2.2.0-alpha05 so that lifecycle-process is upgraded
- Remove the lifecycle:extensions dependency entirely and use only the lifecycle libraries you need (for example, use lifecycle-viewmodel-ktx if you want ViewModels) so that you don't pull in lifecycle-process at all
Mixing and matching Lifecycle versions is not a supported configuration, so I'd recommend keeping to using just a single version.
pa...@gmail.com <pa...@gmail.com> #4
After thinking about this some more, I think we can do something here to maintain compatibility since I suspect that there will be other cases where lifecycle-runtime is updated through some other dependency and that shouldn't force you to upgrade lifecycle-extensions / lifecycle-process.
Description
Component used: Fragment
Version used: 1.3.0
Devices/Android versions reproduced on: Android Studio Emulator with Android 11
I found a bug that requires the use of the Fragment library from 1.3.0 and up (I still reproduce the bug in the version 1.4.0-alpha06), custom animations in FragmentTransactions and a RecyclerView (of androidx.recyclerview:recyclerview:1.2.1).
If a fragment over which the soft keyboard is shown (because an EditText is focused for example), is replaced with a new fragment that shows a RecyclerView, and custom animations are set in the FragmentTransaction, then the soft keyboard is not automatically dismissed and is displayed over the second fragment. If the second fragment does not show a RecyclerView, or custom animations are not set in the FragmentTransaction, then the soft keyboard is automatically dismissed.
It is a regression since the soft keyboard was dismissed correctly when using a version of the Fragment library below 1.3.0.
I suspect that the issue comes from the new fragment state manager since I could not reproduce the issue when disabling it with the method:
I attached a screen recording of the issue captured on a Samsung Galaxy Tab s7, and a sample project.