KGP 2.2.10 + AGP: Use Android components to determine if source-sets are 'publishable'

[adam-enko]

Continuation of #4213

DGP should only document 'publishable' (i.e. main, non-test) source sets. DGP needs to extract this information from KGP and AGP.

For AGP projects, DPG currently uses KotlinJvmAndroidCompilation.androidVariant to determine publishability of a source set. However, this is deprecated in KGP 2.2.10. It will eventually be removed. This is because AGP will implement Kotlin compilation internally (AKA Kotlin built-in).

This PR uses an alternative AGP utility: AndroidComponentsExtension. DGP extracts Components from this extension and stores it in a separate data structure (to avoid Configuration Cache issues with serialising too much data). If a Component has at least one Variant, it is considered 'publishable'. Each Component is associated with a single KotlinCompilation (matched by name), and each KotlinSourceSet is associated with a list of KotlinCompilations.

While using AndroidComponentsExtension is required for AGP9, it also works for AGP7 and 8. To reduce complexity, this PR uses the same approach for all AGP versions.

---

This PR is the first part of supporting AGP 9 in DGP. The next PR is #4295, which will support and test AGP 9 with and without Kotlin built-in.

[whyoleg]

Is there a way to somehow test (I mean write a test), that it will be enough to support AGP with builtin Kotlin?

[adam-enko]

This change is only necessary to support AGP with Kotlin built-in, which is only supported in AGP v9+. AGP 9 isn't released yet, so we don't need to include this PR in the DGP 2.1.0 release.

[whyoleg]

Nice!

I do have some top-level comments:

1. Please change the PR name and so commit message, as this PR is about a different thing.
2. It would be nice to check in which AGP version those new APIs were added - just in case.
3. Is it right that this logic will stay the same when we support AGP9, but will be executed only for AGP8?

[adam-enko]

1. Please change the PR name and so commit message, as this PR is about a different thing.

Sorry, I'm not following, could you write the title you want to see?

I was going to update the commit message when squash-merging to use the issue body.

2. It would be nice to check in which AGP version those new APIs were added - just in case.

I believe the Components extension has been available since AGP 7.

https://developer.android.com/reference/tools/gradle-api/7.0/com/android/build/api/extension/AndroidComponentsExtension

3. Is it right that this logic will stay the same when we support AGP9, but will be executed only for AGP8?

Yes, this logic will work for AGP9. It will also work for AGP7 and AGP8. (Does this help? I'm not sure I understood your question.)

[whyoleg]

Sorry, I'm not following, could you write the title you want to see?
I was going to update the commit message when squash-merging to use the issue body.

I mean, the PR is not just about compatibility with KGP 2.2.10+, but mostly about the improvement of the association of kotlin compilations with AGP variants. And this helps Dokka to be compatible with KGP 2.2.10 at compile-time, as, as we discussed previously, at runtime we would never stumble on KotlinJvmAndroidCompilation.androidVariant having null. And so the current PR title is really confusing.

So maybe something like this would be a nice first line for the commit message (and PR name):

Update DGP logic for understanding if the Android compilation is `publishable` based on Android components

WDYT?
(the rest of the commit message could be based on the issue body)

I believe the Components extension has been available since AGP 7.
https://developer.android.com/reference/tools/gradle-api/7.0/com/android/build/api/extension/AndroidComponentsExtension

Nice, thanks! Though it's highlighted with strikethrough, is it deprecated in AGP9?

In any case, it's not a blocker for this PR.

Yes, this logic will work for AGP9. It will also work for AGP7 and AGP8. (Does this help? I'm not sure I understood your question.)

Got it, sorry for the confusion. For some reason, I was expecting that AGP9 would have some more incompatible APIs.

---

From my side, nothing is blocking the PR from merging. Thanks for answering!

[adam-enko]

Sorry, I'm not following, could you write the title you want to see?
I was going to update the commit message when squash-merging to use the issue body.

I mean, the PR is not just about compatibility with KGP 2.2.10+, but mostly about the improvement of the association of kotlin compilations with AGP variants. And this helps Dokka to be compatible with KGP 2.2.10 at compile-time, as, as we discussed previously, at runtime we would never stumble on KotlinJvmAndroidCompilation.androidVariant having null. And so the current PR title is really confusing.

So maybe something like this would be a nice first line for the commit message (and PR name):

Update DGP logic for understanding if the Android compilation is `publishable` based on Android components

WDYT? (the rest of the commit message could be based on the issue body)

Thanks! That helps. I'll update it.

I believe the Components extension has been available since AGP 7.
https://developer.android.com/reference/tools/gradle-api/7.0/com/android/build/api/extension/AndroidComponentsExtension

Nice, thanks! Though it's highlighted with strikethrough, is it deprecated in AGP9?

Yeah, I'm not sure about that. At least in the AGP 8 docs it says 'Added in 7.0.0'

EDIT: ah, I realised I linked to the wrong one. AGP7 has two AndroidComponentsExtension interfaces in different packages, and one is deprecated.

• https://developer.android.com/reference/tools/gradle-api/7.0/com/android/build/api/variant/AndroidComponentsExtension
• https://developer.android.com/reference/tools/gradle-api/7.0/com/android/build/api/extension/AndroidComponentsExtension

[ALikhachev]

We trigger this function with different plugins, like

withPlugin(PluginId.AndroidBase) { collectAndroidVariants(project, androidVariants) }
withPlugin(PluginId.AndroidApplication) { collectAndroidVariants(project, androidVariants) }
withPlugin(PluginId.AndroidLibrary) { collectAndroidVariants(project, androidVariants) }

however, we do not trigger it for the listed com.android.dynamic-feature or com.android.test, for example. Does it mean we cover those by com.android.base?

If yes, why just having com.android.base is not enough and we should explicitly react on com.android.application and com.android.library? The API for fetching variants seems lazy, so from my POV this causes collecting variants multiple times, but it has only a performance effect since duplicates are automatically excluded from the set constructed via androidVariants

[adam-enko]

we do not trigger it for the listed com.android.dynamic-feature or com.android.test, for example. Does it mean we cover those by com.android.base?

The behaviour by AGP isn't well specified, but I think the answer is 'no'.

[ALikhachev]

Does it mean then that this code does not cover some of the Android family plugins?

[adam-enko]

Good question...

Thinking again, I think com.android.base is non-functional here. Only the actual plugins should matter. But I'd prefer to keep it, just to be safe.

For com.android.dynamic-feature and com.android.test: I didn't add them here because we haven't had any requests to support them, we don't have any tests for them, and I'm not sure if anyone would ever want to generate Dokka docs for them.

@whyoleg Do you have any opinion on whether DGP should support projects with com.android.dynamic-feature or com.android.test plugins?

[whyoleg]

I see that KGP also does perform checks based on multiple ids (not using com.android.base), and I haven't found any tests which use com.android.dynamic-feature.
So I'm leaning more towards having the same behaviour as in KGP - react on all four plugins, even if we don't have tests for them.

Also, AFAIU, with AGP9, users will use kotlin built into those plugins, and this will be less of an issue in the future.

[adam-enko]

I updated DGP to react to all Android plugins.

UPDATE: oops, I updated it in #4295, not this PR

9ee88a1