Fixed
Status Update
No update yet.
Comments
ma...@google.com
sg...@google.com
sg...@google.com
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.
ap...@google.com
Sorry and thank you for your time
sg...@google.com
pr...@google.com
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.
za...@yandex.ru
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
DateRangePickerdoesn't allow selecting a range of 1 day (a range starting and ending on the same day). Date range picker fromcom.google.android.material:material:1.8.0allows 1-day ranges. Another example is the Pixel clock app allows 1-day ranges when pausing alarms. In general this is a valid edge use case.Looks like
DateInputValidatormarks a range like this invalid, but it's unclear if this is on purpose. The code is surrounded with comments that say "Additional validation when the InputIdentifier is for start of end dates in a range input" and "The input start date is after the end date, or the end date is before the start date." which strikes me as something where the intent wasn't to also reject when start date and end date are equal.