Develop Reference

Kotlin Native compile jar and framework

I'm building a multiplatform library for Android and iOS. My gradle file looks like this:
plugins {
id 'org.jetbrains.kotlin.multiplatform' version '1.4.0'
}
repositories {
mavenCentral()
}
group 'com.example'
version '0.0.1'
apply plugin: 'maven-publish'
kotlin {
jvm()
// This is for iPhone simulator
// Switch here to iosArm64 (or iosArm32) to build library for iPhone device
ios {
binaries {
framework()
}
}
sourceSets {
commonMain {
dependencies {
implementation kotlin('stdlib-common')
implementation("com.ionspin.kotlin:bignum:0.2.2")
}
}
commonTest {
dependencies {
implementation kotlin('test-common')
implementation kotlin('test-annotations-common')
}
}
jvmMain {
dependencies {
implementation("com.ionspin.kotlin:bignum:0.2.2")
}
}
jvmTest {
dependencies {
implementation kotlin('test')
implementation kotlin('test-junit')
}
}
iosMain {
}
iosTest {
}
}
}
configurations {
compileClasspath
}
Im using a third party library and I'm using it like this:
fun test(value: String): Int {
return BigDecimal.parseString(value).toBigInteger().intValue()
}
The problem is when I build the .jar the bignum library isn't included, and when I use the lib in an Android project I get an exception ClassNotFoundException: Didn't find class "com.ionspin.kotlin.bignum.decimal.BigDecimal".
Is there a way to include third party libs in the .jar for Android and .framework for iOS?

JVM
So, the only way I've found to generate a Fat JAR that works like you expect is by adding two custom gradle tasks in project:build.gradle.kts of your KMP library after appling the java plugin.
plugins {
[...]
id("java")
}
[...]
kotlin {
jvm {
[...]
compilations {
val main = getByName("main")
tasks {
register<Copy>("unzip") {
group = "library"
val targetDir = File(buildDir, "3rd-libs")
project.delete(files(targetDir))
main.compileDependencyFiles.forEach {
println(it)
if (it.path.contains("com.")) {
from(zipTree(it))
into(targetDir)
}
}
}
register<Jar>("fatJar") {
group = "library"
manifest {
attributes["Implementation-Title"] = "Fat Jar"
attributes["Implementation-Version"] = archiveVersion
}
archiveBaseName.set("${project.name}-fat")
val thirdLibsDir = File(buildDir, "3rd-libs")
from(main.output.classesDirs, thirdLibsDir)
with(jar.get() as CopySpec)
}
}
tasks.getByName("fatJar").dependsOn("unzip")
}
}
[...]
}
You then must launch the fatJar gradle task that generate a .jar file with the 3rd libraries classes extracted from they corresponding jar archives.
You can customize the two custom gradle scripts even more in order to better fit your needs (here I only included com. package name starting deps).
Then in your Android app app:build.gradle file you can use it as you did or simply
implementation files('libs/KMLibraryTest001-fat-1.0-SNAPSHOT.jar')
iOS
As you ask also for the iOS part in your title (even if it's a second citizen in the main topic of your question) you need only to use api instead of implementation for your 3rd party library along with the export option of the framework.
ios() {
binaries {
framework() {
transitiveExport = true // all libraries
//export(project(":LibA")) // this library project in a trainsitive way
//export("your 3rd party lib") // this 3rd party lib in a transitive way
}
}
}
And you can find a full reference here.

If you see the Krypto library, it has
androidMain
jsMain
jvmMain
mingwX64Main
nativPosixMain
Which means 5 kind of binaries are generated to support 5 platforms
Convincingly, this explains that each platform expects its own binary
for example,
windows -- DLL file
linux -- so file
java -- JAR file
mac -- dylib file
A JAR gets loaded into JVM, but IOS does not use JVM
Separate your Utility functions which has a common logic and write gradle to target multiple platforms
If you want to start with pure multiplatform, you can try this Official Example
Or create a sub gradle module and create a library project which is common to IOS as well as Android
The possible targets are properly documented here
I have created a application which publishes the binary to local repository and re-uses in the MainActivity -- you can get the code here
modify the local.properties for android SDK location and use
gradlew assemble
to build the APK and test it yourself
open the mylib\build.gradle.kts folder and you can see the targets jvm and iosX64 , jvm is used for android

If I'm correct using api instead of implementation should fix your problem, though I didn't try it out yet on the Native part
See Api and implementation separation

Gradle build by selecting *Test.java files

My app is being tested by junit, robolectric and gradle build.
The test code follows below structure.
approot/mytest/com/xx/pkg/*.java
test {
java {
srcDir 'mytest'
}
}
This includes all the files under test pakage, needlessly including some of the utility files.
I have all the test files name xxxxxTest.java, yyyyTest.java etc.
So I thought to change srcDir to mytest/**/*Test.java or /mytest/com/xx/pkg/*Test.java, build does not compile any test code. However /mytest/com/xx/pkg/*.java picks all test source files.
Any pointers?
Thanks

You can use TestFilter to achieve this. Try the following:
test {
filter {
includeTestsMatching "*Test"
}
}

Build type specific folder not recognized for a product flavor

I have configured my project to have multiple product flavors. I have the following code in my module build.gradle:
android {
// Rest of the configuration omitted for clarity
buildTypes {
debug {
// ...
}
release {
// ...
}
}
productFlavors {
paid
free
}
}
If I create a file (any file: Java, resources, ...), in the paid, free, debug or release, it is recognized by Android Studio and I can use it in my project.
However, if the same file is created in paidDebug (or a similar folder) it is not recognized in Android Studio. Do I need any extra configuration for this to work? Is this not supported (yet)?

Source code files with the same name should be placed in all of the alternative source sets (but not in the 'main').
Either:
app/src/free/java/com/domain/myapp/MainActivity.java
app/src/paid/java/com/domain/myapp/MainActivity.java
Or:
app/src/freeDebug/java/com/domain/myapp/MainActivity.java
app/src/freeRelease/java/com/domain/myapp/MainActivity.java
app/src/paidDebug/java/com/domain/myapp/MainActivity.java
app/src/paidRelease/java/com/domain/myapp/MainActivity.java
Resource files with the same name can be placed in any source set, including 'main'.
app/src/main/res/layout/activity_main.xml
app/src/paidDebug/res/layout/activity_main.xml
app/src/paidRelease/res/layout/activity_main.xml
In this case, when building the 'free' flavor, the layout file from 'main' set will be used. But, during the build of the 'paid' flavor, the specific version of the layout will be used.

You can specify specific source directories in your build.gradle file. For example, to add testFreeRelease to unit test sources and testFree to android integration test sources:
android {
[...]
sourceSets {
main.java.srcDirs += 'src/main/java'
testFreeRelease.java.srcDirs += 'src/testFreeRelease/java'
androidTestFree.java.srcDirs += 'src/androidTestFree/java'
}
}
This also works for Kotlin. Just switch java with kotlin.

How to configure multiple java source directories using Android Studio Experimental Grade plugin?

Using Android Studio 2.1.1 with Experimental Grade plugin 0.7.2, I'm trying to add another Java source code directory to the module. Here's the relevant section from the module Gradle settings:
android.sources {
main {
java.source {
//srcDir "src/java"
//srcDir "../../JavaBindings/java"
//srcDirs += "src"
srcDirs += "../../JavaBindings/java" <--- DOES NOT WORK
}
jni.source {
srcDirs += "../../JavaBindings/jni" <--- THIS WORKS
}
}
}
After looking around on Google and Stack Overflow, I tried a number of different syntaxes, but no luck. The app/java directory in the Android Studio project structure UI only shows what's in src/java and does not include what's in ../../JavaBindings/java.
However for the app/jni directory, it works: both what's in src/jni and ../../JavaBindings/jni shows up.

After looking at the source code for the Gradle Experimental plug-in, I eventually figured it out:
java.source.srcDirs and jni.source.srcDirs do not behave the same: for the JNI case, even if you define the jni.source.srcDirs setting, src/main/jni is always included by default, but that's not the case for the Java case.
So the correct syntax becomes:
android.sources {
main {
java.source {
srcDirs += "src/main/java"
srcDirs += "../../JavaBindings/java"
}
jni.source {
srcDirs += "../../JavaBindings/jni"
}
}
}

Android build.gradle importing flavors from another file

I have put the product Flavors into another file called other.gradle and it looks like this:
project.ext.myflavors = {
mock {
applicationId "com.mysite.mock"
}
}
and i am able to successfully access the closure in my build.gradle file like this:
myflavors()
but i get an error that mock method is not defined.
Error:Gradle DSL method not found: 'mock()'
Is there no way to just define code from another file and import the code itself into the build file ? Or how can i import the flavors from another file ?

The build flavors could be defined in a separate file (build_flavors.gradle) like this:
android {
productFlavors {
flavorA {
// ...
}
flavorB {
// ...
}
}
}
and then imported into build.gradle:
apply plugin: 'com.android.application'
apply from: './build_flavors.gradle'
android {
// the rest of your android configuration
}

It is perfectly fine to access productFlavors multiple times. So adding some or all flavors in a script included by your build script will work.
Create a Gradle script that contains the logic that decides which flavor(s) should be added:
if (someCondition()) {
android {
productFlavors {
one {
applicationId = 'com.example.oneapp'
}
}
}
} else {
android {
productFlavors {
two {
applicationId = 'com.example.twoapp'
}
}
}
}
Now include this script from your build script. Reusing the scripts is easy if you put it under (a subfolder of) the root project. For example:
apply from: rootProject.file('build-scripts/flavor-picker.gradle')
Note that your IDE may not notice changes to the flavor selection script or gradle.properties, so if you make changes to them you will probably have to manually reimport the Gradle files to see the correct set of available tasks.