Wouldn’t it be nice to be able to have the `AndroidManifest.xml` file of a “pure” Kotlin Multiplatfo...

# multiplatform

[ribesg]

Wouldn’t it be nice to be able to have the AndroidManifest.xml file of a “pure” Kotlin Multiplatform library generated or hidden or something? I have multiple modules which are pure Kotlin and only have code in commonMain sourceSet but they all have to have an androidMain folder with an almost empty AndroidManifest.xml file. Anybody else finding that annoying or I am just nitpicking?

[hfhbd]

AGP 7.2 supports the namespace attribute in Gradle DSL, so you dont need a Android manifest anymore

[ribesg]

That’s interesting. But that version of AGP can’t be used with IntelliJ I think

[hfhbd]

You can use it with the latest EAP

[ribesg]

“Stable” versions of Jetbrains products are unstable enough but thanks

[ribesg]

I’ll try auto-manifest that @kenkyee linked and migrate when AGP 7.2 is supported in a few weeks/months I think

[drew]

The namespace Gradle DSL property works in AGP 7.0.4+ and the latest stable IntelliJ IDEA/AS.

[vanniktech]

It does work but databinding imports won't be resolved when using namespace with AGP 7.0.4 in IntelliJ 2022.1.*

[ribesg]

@drew oh, nice

@vanniktech does that mater in the context of a pure Kotlin “logic” library? Like a multiplatform implementation of an algorithm

[vanniktech]

Nope it should not

[andylamax]

if it's as pure mpp as you say it is, why do you even have an android target to begin with? you could just remove the android target, replace it with jvm, and it should work as a library on both android, and jvm.

On top of that, you get much faster compilation times because one, one few target to build for, and two jvm target is way faster to build than all other targets

[ribesg]

I was exposing a perfect example to get my point across and I agree that in this case I wouldn’t need an android target, but I’m in a project with dozens of kmp modules and they’re all configured the same, I don’t really want to try and find which ones need to have an android target and which don’t, and also don’t want to have to think about if I need/can add/remove the android target with each commit. Just having it is a simpler default, ease of mind is better than compilation time, especially as each module is compiled for the 3 iOS platforms with the new memory model, which takes much, much longer to compile than android targets

[Stylianos Gakis]

I’ve seen this PR recently on the dependency analysis android gradle plugin project. Maybe this can help you know which modules can be simplified like that without the hassle of finding out yourself. Note I haven’t tried it out myself.