here's my `build.gradle`

# kotlin-native

[David Stolarsky]

here's my build.gradle

build_gradle.groovy

[ribesg]

This build file does not support Android. Creating a jvm target and naming it android does not make it an android target. Use the android preset, the android plugin and have a proper android block.

[ribesg]

You usually do what you did when you actually don’t need Android platform APIs, this way you can publish your library as a JVM library and it’s simpler to build, deploy and use.

[ribesg]

If you need Android APIs, then you’re doing an actual Android library (.aar file) or an Android application (.apk file)

[David Stolarsky]

got it. i took that line (fromPreset(presets.jvm, 'android')) straight from the "Multiplatform Project: iOS and Android" tutorial

[David Stolarsky]

the tutorial demonstrates using platform.UIKit, so i assumed it was nearly demonstrating how to use platform.android. but i guess it is still a bit far from demonstrating platform.android use.

[ribesg]

Yes but this tutorial is for creating a library used by native applications. There’s a whole spectrum of multiplatform usage you can have. Your entire app could be multiplatform

[ribesg]

platform.* is a native thing. Android isn’t native (or at least that’s not what you want). To clarify, there’s no platform.android. You would just import Android APIs normally like in a normal Android project

[David Stolarsky]

i swear i saw import platform.android.* in a couple examples

[David Stolarsky]

i'm not really sure what i want. right now, instead of calling into android APIs from my native library, since i couldn't figure that out, i am declaring `interface`es in the native library, and having the host application pass in things that adhere to those interfaces, that perform that Android SDK stuff

[David Stolarsky]

seems like figuring out how to use `expects`/`actual` might save some lines of code and some OOP headaches

[David Stolarsky]

but i'm not sure

[ribesg]

Well there is a platform.android, but for Android Native development, which is a very different thing

[David Stolarsky]

like NDK?

[ribesg]

Yes

[David Stolarsky]

got it

[ribesg]

Usually you would use `expect`/`actual` yeah.

[David Stolarsky]

so i just need like apply plugin("com.android.library") and an android { } block?

[David Stolarsky]

in build.gradle?

[ribesg]

did you manage to make your android target work? An Android target is surprisingly harder to setup than a native one because you have to setup the whole android library thing

[ribesg]

Basically yes, and change the preset you use

[David Stolarsky]

my android app is running and it is using the kotlin multiplatform lib

[ribesg]

Also you can just do android() instead of some fromPreset thing

[David Stolarsky]

or is it kotlin native lib... dunno what's the difference between multiplatform / native, if any

[David Stolarsky]

(also my iOS app is running and is using the lib) *i think, lol

[ribesg]

Kotlin Native is for Native development only (Which still covers iOS, Linux, Windows, etc, all native). Multiplatform is “Kotlin everywhere”, including JVM, JS, Android

[ribesg]

But you can (and should, I think) use the multiplatform plugin when developing just for iOS. That’s what I do. This way you just get used to one way to make build files for any platform

[David Stolarsky]

i'm developing a lib that should have an Android flavor and an iOS flavor

[David Stolarsky]

the iOS flavor is output as a .framework and it is able to call into iOS platform APIs

[David Stolarsky]

the Android flavor is outputting as an Android lib and it works, but i'm not yet able to call Android platform APIs

[ribesg]

If you’re used to make android build files then doing the Android part should be dead simple

[David Stolarsky]

i am totally not used to making android anything

[ribesg]

That’s just because your “Android lib” was actually just a Java lib

[David Stolarsky]

ok

[David Stolarsky]

does any of this seem very hard or impossible? do i just need to edit my build.gradle file correctly?

[ribesg]

Here is a basic android block in the build file of one of my libs

android {

    compileSdkVersion(Versions.androidCompileSdk)

    defaultConfig {
        minSdkVersion(Versions.androidMinSdk)
        targetSdkVersion(Versions.androidTargetSdk)
        versionName = Versions.appVersionName
        versionCode = Versions.appVersionCode
    }

    sourceSets {
        getByName("main") {
            setRoot("src/androidMain")
        }
        getByName("test") {
            setRoot("src/androidTest")
        }
    }

    lintOptions {
        isAbortOnError = false
    }

}

[ribesg]

Just replace your jvm target with an android one and add the block above and it should just work

[ribesg]

Note: the android block should come before the kotlin block

[ribesg]

The android target expects the android plugin to be configured already

[David Stolarsky]

ok will try.... (btw, how do you define Versions? i would like to share that info with my app build.gradle)

[ribesg]

I’m using buildSrc, let’s see if I can find a tutorial on that

[ribesg]

https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:build_sources

[ribesg]

You’ll also need to define your android target like this if you want to enable publication, android artifactds aren’t published by default

android {
        publishAllLibraryVariants()
    }

(You can customize which variants are published, but if you only got release and debug variants, that works)

[David Stolarsky]

i don't want to publish

[ribesg]

Oh, I didn’t see but you’re using Groovy. The code I shown is written in Kotlin, you may need to adapt some stuff.

[David Stolarsky]

getByName("main").... what does "main" refer to?

[David Stolarsky]

should i have something called main somewhere?

[David Stolarsky]

i have folders src/commonMain/kotlin, src/androidMain/kotlin, and src/iosMain/kotlin

[ribesg]

No, it’s the default names. You don’t seem used to the Java world, but in this world the concept of “convention over configuration” is abused a lot.

[ribesg]

In Groovy you can replace getByName("main") with just main

[ribesg]

The entire idea of the sourceSets block in the android block is to just change main to androidMain, at least for the sourceSet location

[David Stolarsky]

ok so it complains there is no AndroidManifest.xml in androidMain/

[David Stolarsky]

i will add one... without an <application> inside...?

[David Stolarsky]

sorry this is going pretty deep on my Android noviceness

[ribesg]

Yeah by convention this file needs to exist even if it’s useless. Welcome to Android 😛
Here’s one of mine for example:

<?xml version="1.0" encoding="utf-8"?>
<manifest package="yourpackage" />

[ribesg]

Well it’s not entirely useless, your lib may need to define some meta values, ask for some permissions, I don’t know...

[David Stolarsky]

it builds!

[David Stolarsky]

awesome, it looks like i can use import android..... stuff now

[David Stolarsky]

thank you!