IssueTracker

Here are the release APKs for different compose dev version so you can have a look without compiling:

yes, we have to add dependencies on appcompat and fragments even if we don't use them.
well, no-one is reading the documentations. if we remove it and user has older version of appcompat everything will compile but the app crash in runtime with some weird issue.
I think we should explore how studio can help to verify the versions for us. We can also write a clear error message so when it will crash in runtime we will ask to update the dependency.
For now, before we reach beta I think it is fine for us to include these dependencies, and it also gives people time to start using this never versions.

Context:
Previously we had to add
implementation "androidx.fragment:fragment:1.3.0-alpha07"
implementation "androidx.appcompat:appcompat:1.3.0-alpha01"
dependencies to compose:ui:ui module in https://aosp/1311537 in order to make sure our view always have correct ViewTreeLifecycleOwner and ViewTreeSavedStateRegistryOwner. We use them in AndroidComposeView.onAttachedToWindow() and in ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed
Why we need appcompat:
a) because there was a bug where AppCompatActivity even that it extends ComponentActivity were not populating the lifecycle owner: http://aosp/1261719
b) we also introduced ViewTreeViewModelStoreOwner in the same release, so it is not populated before that release: http://aosp/1300264
Why we need fragment:
a) we populate SavedStateRegistryOwner only starting from that release: aosp/1298680
b) this bug fix is pretty important for the state restoration to work correctly in fragments: http://aosp/1326611

In order to remove these dependencies we should:
1) Make a clear crash message mentioning something like "If you use ComposeView from Appcompat activity make sure you have this version, if you use from Fragment make sure...". We should do it in AbstractComposeView.onAttachedToWindow(). It is a bit weird that we should do it there, and not in AndroidComposeView.onAttachedToWindow() as we currently have a duplication of this logic and do it both in AndroidComposeView and for AbstractComposeView via ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed.
2) ComponentActivity.setContent(from androidx.activity.compose) can hack it a bit via doing
        ViewTreeLifecycleOwner.set(getWindow().getDecorView(), this);
        ViewTreeSavedStateRegistryOwner.set(getWindow().getDecorView(), this);
        ViewTreeViewModelStoreOwner.set(getWindow().getDecorView(), this);
if we detect the issue - any of these owner are nulls.

It can be tested via tests we currently have in ui module: LifecycleOwnerIn*Test and SavedStateRegistryOwnerIn*Test. They currently pass only because we add these dependencies. Once you remove it the tests should fail