This message was deleted.

The order in which the plugins are applied on the module remain the same. I apply the android plugin before I apply my custom plugin.

Generally you shouldn't depend on plugin application order (though it should be stable currently). If your plugin requires

com.android.library

just add

project.pluginManager.apply("com.android.library")

. If you want to do some configuration if that plugin applied to the project use

project.pluginManager.withPlugin("com.android.library") { .. }

, action will be called after android plugin is applied and extension would be available.

Thank you. That makes sense and your proposed solution works out for me! I wonder why the behaviour is different for plugins that are applied from different sources though.

the normal included builds doesn't add the plugin artifact to the classpath (any dependency on the build.gradle of the included build), buildSrc adds it, if you add agp to the buildscript or add it in the root project it should work

☝️ because of this, I would say it was more ‘accidental’ that it worked with buildSrc. Because buildSrc historically has some “quirks”. Alternatively to ‘withPlugin’, you can also apply the plugin in your convention plugin first. Then you have the guarantee that it was applied before. You can write

plugins { id("com.android.library") }

as many times as you like. Gradle only applies it once. So the first place it is applied controls the order.

Thanks , this explains the behaviour. IIRC the suggested mechanism for project specific plugins is to use composite builds instead of buildSrc right? I remember reading that somewhere but cannot find that reference right now.

Both are ok, but my personal preference is never too use

buildSrc

but always included builds, except for special cases like monkey-patching 3rd-party classes