IssueTracker

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.

Sorry and thank you for your time

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.

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

This has been fixed internally. It missed the cutoff for the next version of Lifecycle (2.2.0-beta01), but we'll make sure it is in the next release. The guidance in comment#2 still applies - it is best to not mix and match lifecycle versions.

Well it is easy to add the @Keep annotation if the fragment is yours... but what if you are using for example SupportMapFragment?

My solution for the NavHostFragment with the FragmentContainerView is to add this to your ProGuard rules:

-keepnames class androidx.navigation.fragment.NavHostFragment

Any plans on fixing it in nearest feature without workarounds?

P.S. Why it wasn't possible to fix the issue before releasing stable?
Adding @Keep manually sounds like it is 2015 now developers should struggle with their own set of rules for every single components.

Project: platform/frameworks/base
Branch: master

commit 4bdc698d9f8fb4f85464d554cabeb954104ec0a3
Author: Jeremy Woods <jbwoods@google.com>
Date:   Fri Feb 28 19:42:38 2020

    Generate "keep" rules for android:name and class attributes
   
    We should keep classes that are in the android:name or class xml
    attributes.
   
    Test: m -j aapt2_tests
    Bug: 142601969
    Change-Id: Ia67365bd702bae75d38b9572d68e9930e856e0f8

M       tools/aapt2/java/ProguardRules.cpp
M       tools/aapt2/java/ProguardRules_test.cpp

https://android-review.googlesource.com/1247267

AGP will not back port these since it's too late in the release process for them. However, you can force older AGP to use the newer aapt2.
You can do it in two ways, with the first approach being much safer:
1) In your build.gradle force gradle to use the newer version:
configurations.matching { it.name == '_internal_aapt2_binary' }.all { config ->
        config.resolutionStrategy.eachDependency { details ->
            details.useVersion("4.1.0-alpha04-6296993")
        }
    }

2) If for some reason the above doesn't work, you can manually download the gmaven jar file for "com.android.tools.build:aapt2:4.1.0-alpha04-6296993" (https://dl.google.com/dl/android/maven2/com/android/tools/build/aapt2/4.1.0-alpha04-6296993/aapt2-4.1.0-alpha04-6296993-[windows/darwin/linux].jar - choose the right platform), unpack somewhere and use android.aapt2FromMavenOverride to set the path to the aapt2 executable you want to use. Be careful to use the right platform.

Note: check the version when it comes out, most likely it should match this but it's possible we update the prebuilts again before then. 4.1 canary 4 is not out yet, so this will only be available in gmaven once that canary is released.

Follow pre-release version updates here: https://androidstudio.googleblog.com/

Gracias