Assigned
Status Update
Comments
gm...@google.com <gm...@google.com>
tw...@gmail.com <tw...@gmail.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...@google.com <pa...@google.com>
to...@yahoo.com <to...@yahoo.com> #3
Sorry and thank you for your time
gh...@google.com <gh...@google.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.
an...@google.com <an...@google.com> #5
Project: platform/frameworks/support
Branch: androidx-master-dev
commit b73a278881735861cd4a7c4b2f663aecbfce10d8
Author: Ian Lake <ilake@google.com>
Date: Fri Sep 27 15:40:11 2019
Fix lifecycle-runtime:2.2.0 + lifecycle-process:2.1.0
The lifecycle-runtime 2.2.0 switched away from
using ReportFragment on API 29+ devices. However,
lifecycle-process:2.1.0 and earlier still depend on
ReportFragment being there.
Given that lifecycle-process and lifecycle-runtime
do not have any strict Gradle version dependencies
set, it should be possible to mix and match these
dependencies as this is a relatively common operation
(say, if you upgrade to the latest fragments but don't
upgrade your lifecycle-extensions version).
This fixes the issue by continuing to add the
ReportFragment even on API 29+ devices, but ignore
the dispatch() of Lifecycle events from it, using it
solely for backward compatibility with the
ProcessLifecycleOwner of lifecycle-process 2.1.0
and earlier.
Test: tested in sample app
BUG: 141536990
Change-Id: I7f50c33dabe25c24647eec6169b1818d0a23895b
M lifecycle/lifecycle-runtime/src/main/java/androidx/lifecycle/ReportFragment.java
https://android-review.googlesource.com/1130355
https://goto.google.com/android-sha1/b73a278881735861cd4a7c4b2f663aecbfce10d8
Branch: androidx-master-dev
commit b73a278881735861cd4a7c4b2f663aecbfce10d8
Author: Ian Lake <ilake@google.com>
Date: Fri Sep 27 15:40:11 2019
Fix lifecycle-runtime:2.2.0 + lifecycle-process:2.1.0
The lifecycle-runtime 2.2.0 switched away from
using ReportFragment on API 29+ devices. However,
lifecycle-process:2.1.0 and earlier still depend on
ReportFragment being there.
Given that lifecycle-process and lifecycle-runtime
do not have any strict Gradle version dependencies
set, it should be possible to mix and match these
dependencies as this is a relatively common operation
(say, if you upgrade to the latest fragments but don't
upgrade your lifecycle-extensions version).
This fixes the issue by continuing to add the
ReportFragment even on API 29+ devices, but ignore
the dispatch() of Lifecycle events from it, using it
solely for backward compatibility with the
ProcessLifecycleOwner of lifecycle-process 2.1.0
and earlier.
Test: tested in sample app
BUG: 141536990
Change-Id: I7f50c33dabe25c24647eec6169b1818d0a23895b
M lifecycle/lifecycle-runtime/src/main/java/androidx/lifecycle/ReportFragment.java
Description
Android Studio (Ladybug) UI is slower than Koala. This manifests as noticeable lag in lots of operations. For example:
If I close Ladybug, open the project in Koala (and downgrade the AGP version 8.5.2, supported by Koala) this lag disappears. If I reopen the project in Ladybug with AGP 8.5.2 and clear caches/indexes the UI is still laggy.
I have also reset the Microsoft Defender notification and used the IDE to update the Defender configuration (the toast "Project paths were successfully added to the Microsoft Defender exclusion list" appears) just in case that could be the cause. However, the slowness remains after doing that.
Done.
Possibly related -- after clicking the "Sync project with Gradle files" icon at the top-right of the toolbar it's a coin toss as to whether or not the the "Gradle project sync in progress..." yellow notification will disappear after the Gradle project sync has completed (i.e., after it has disappeared from the list of background tasks that appears towards the bottom right of the UI).
Ladybug also frequently reports internal errors in Android related plugins that seem relevant. These exceptions are not present when I open the project in Koala. These exceptions include:
Plugin: Android Design Tools
Plugin: Android
Plugin: Android
For more information on how to get your bug routed quickly, seehttps://developer.android.com/studio/report-bugs.html