DEV Community: ColtonIdle

How to create a "convention" plugin for your multi-module Android app

ColtonIdle — Sun, 25 Jan 2026 23:49:29 +0000

One thing that trips me up all the time is how to common-ize my build files in a multi-module Android app. Every time I try to learn it, I give up because of overloaded terms, potential footguns, and possible slowdowns in my app. IMO this should be a lot easier, so I end up just duplicating code and sometimes I will just have some sort of subprojects.all{} block in my root build.gradle to apply something to all of my modules instead.

I'm trying to learn once more with a very simple case where I have:

Android app module
Android library lib1 module
Android library lib2 module

And I want to extract the common code in the android libraries (lib1 and lib2)

Some general notes:

According to https://docs.gradle.org/current/userguide/best_practices_structuring_builds.html#favor_composite_builds) that buildSrc isn't recommended and so I should go down a path of a convention plugin for sharing build logic
Convention plugin is a loaded term and you can have convention plugins in both buildSrc and build-logic . Similarly, you can write your convention plugins as "precompiled script plugins" (.kts ) or regular "binary plugins" (.kt)
https://github.com/autonomousapps/gradle-glossary is a good resource to brush up on gradle terms
In Android you have gradle "modules", but these modules are really "projects" in the eyes of gradle. Similarly, you might be used to call something a gradle "project" if it uses gradle to build, but in the eyes of gradle this is called a "build". Hence why adding a convention plugin requires you to create another gradle build in your repo, and add it to your initial gradle build via "includedBuild"
NowInAndroid saved ~12s in some cases by removing precompiled script plugins
If you want the fastest possible performance, you want to publish your convention plugins (annoying for your "typical" android app) (see here)
If you see kotlin-dsl in your build, you can treat this as an indication that you can try to remove it in order to gain some build speed
Read https://mbonnin.net/2025-07-10_the_case_for_kgp/
Many definitions of a "convention plugin"
1. Convention plugins are just regular plugins
2. A "convention plugin" is a plugin that only your team uses
3. A "convention plugin" is a plugin that you share in your build, and so you could say every plugin is a convention plugin, but typically "convention plugins" are understood as being part of your repo
id("java-gradle-plugin") and `java-gradle-plugin`
are interchangable. Same with maven-publish See here
subprojects and allprojects break project isolation, but if you don't care about project isolation then it should be fine to use. Read more here about why it should not: https://docs.gradle.org/current/userguide/sharing_build_logic_between_subprojects.html#sec:convention_plugins_vs_cross_configuration

This was like 90% done put together with help from Martin Bonnin, but I had to write it down so I don't forget it

Conversion

So let's just pretend we did file > new project, then added two new android lib modules (lib1 and lib2). By default we'll have this duplicate code in the two lib modules. (this is default code that AS new module wizard will generate in Jan of 2026):

plugins {
  alias(libs.plugins.android.library)
}

android {
  namespace = "com.cidle.lib1"
  compileSdk {
    version = release(36)
  }

  defaultConfig {
    minSdk = 27

    testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
    consumerProguardFiles("consumer-rules.pro")
  }

  buildTypes {
    release {
      isMinifyEnabled = false
      proguardFiles(getDefaultProguardFile("proguard-android-optimize.txt"), "proguard-rules.pro")
    }
  }
  compileOptions {
    sourceCompatibility = JavaVersion.VERSION_11
    targetCompatibility = JavaVersion.VERSION_11
  }
}

dependencies {
  implementation(libs.androidx.core.ktx)
  implementation(libs.androidx.appcompat)
  implementation(libs.material)
  testImplementation(libs.junit)
  androidTestImplementation(libs.androidx.junit)
  androidTestImplementation(libs.androidx.espresso.core)
}

Let's de-duplicate with a convention plugin!

Steps

1: Create build-logic directory
2: Add settings.gradle.kts in build-logic and fill it with

dependencyResolutionManagement {
    repositories {
        google()
        mavenCentral()
    }
    versionCatalogs {
        create("libs") {
            from(files("../gradle/libs.versions.toml"))
        }
    }
}

rootProject.name = "build-logic"

3: Inside of this new build-logic dir create a build.gradle.kts

plugins {
  id("java-gradle-plugin")
  alias(libs.plugins.kotlin.jvm)
}

java {
  toolchain {
    languageVersion.set(JavaLanguageVersion.of(17))
  }
}

dependencies {
  compileOnly(libs.android.gradlePlugin)
  implementation(gradleKotlinDsl())
}

gradlePlugin {
  plugins {
    register("androidLibrary") {
      id = "libtest.android.library"
      implementationClass = "AndroidLibraryConventionPlugin"
    }
  }
}

Note: You can’t replace “java-gradle-plugin” with a toml entry since it is a built-in plugin inside Gradle, it’s not a dependency so it doesn’t belong to the version catalog.

When it comes to
"dependencies {
implementation(libs.android.gradlePlugin)
implementation(gradleKotlinDsl())
}"
you needs those as well. gradleKotlinDsl() is not strictly required but it can help with things like tasks.withType() instead of tasks.withType(Jar::class.java) or extensions.configure

4: Then in convention dir, create new package and class structure of src/main/kotlin/AndroidLibraryConventionPlugin.kt

import com.android.build.api.dsl.LibraryExtension
import org.gradle.api.JavaVersion
import org.gradle.api.Plugin
import org.gradle.api.Project
import org.gradle.api.artifacts.VersionCatalogsExtension
import org.gradle.kotlin.dsl.configure
import org.gradle.kotlin.dsl.dependencies
import org.gradle.kotlin.dsl.getByType

class AndroidLibraryConventionPlugin : Plugin<Project> {
    override fun apply(target: Project) {
        with(target) {
            with(pluginManager) {
                apply("com.android.library")
            }

            extensions.configure<LibraryExtension> {
                compileSdk = 36

                defaultConfig {
                    minSdk = 27
                    testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
                    consumerProguardFiles("consumer-rules.pro")
                }

                buildTypes {
                    release {
                        isMinifyEnabled = false
                        proguardFiles(
                            getDefaultProguardFile("proguard-android-optimize.txt"),
                            "proguard-rules.pro"
                        )
                    }
                }

                compileOptions {
                    sourceCompatibility = JavaVersion.VERSION_11
                    targetCompatibility = JavaVersion.VERSION_11
                }
            }

            val libs = extensions.getByType<VersionCatalogsExtension>().named("libs")

            dependencies {
                add("implementation", libs.findLibrary("androidx-core-ktx").get())
                add("implementation", libs.findLibrary("androidx-appcompat").get())
                add("implementation", libs.findLibrary("material").get())
                add("testImplementation", libs.findLibrary("junit").get())
                add("androidTestImplementation", libs.findLibrary("androidx-junit").get())
                add("androidTestImplementation", libs.findLibrary("androidx-espresso-core").get())
            }
        }
    }
}

Note: I wish there was a better way to use our toml file here. I'm not fond of libs.findLibrary, etc. It might be related to this: https://github.com/gradle/gradle/issues/15383

5: Update :lib1 and :lib2 respective build.gradle.kts to be

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

android {
  namespace = "com.cidle.lib1"
}

and

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

android {
  namespace = "com.cidle.lib2"
}

We basically went down from 37 lines to 6 lines... in 2 modules! So for every time we add a new module, we save at least those 30 lines and as our "base" android library definition expands (adds more dependencies, lint configuration, etc) then you save yourself from having to re-write those lines too.

6: In your settings.gradle.kts you need to add one line to add this new build-logic module as an "included build"

pluginManagement {
  includeBuild("build-logic") <===== this is the line you add!
  repositories {
    google {
      content {
        includeGroupByRegex("com\\.android.*")
        includeGroupByRegex("com\\.google.*")
        includeGroupByRegex("androidx.*")
      }
    }
    mavenCentral()
    gradlePluginPortal()
  }
}

7: In your toml add (under libraries)

android-gradlePlugin = { group = "com.android.tools.build", name = "gradle-api", version.ref = "agp" }

and under plugins add

kotlin-jvm = { id = "org.jetbrains.kotlin.jvm", version.ref = "kotlin" }

Done!

Thank you again Martin Bonnin for all of the teaching on this subject!

TL;DR: I think the biggest concept to overcome when trying to setup a convention plugin is that you need another gradle build in your repository. Example: if you had a file > new android project, and then created two android libs (lib1 and lib2) and wanted to have common dependencies/configuration between those two android library modules, you would need to create (what looks like) a brand new build-logic module, but this "module" isn't just "another" module you might be used to in your android project — instead it has to be a new little gradle "project" (the gradle term for this is a new gradle build), which is why you need to write another settings.gradle.kts in build-logic dir, etc. In order for your actual android project to use this new build-logic gradle build, you need to reference it via includeBuild() Get it? Instead of your usual one gradle build in your repo, you will have two, hence the need to call includeBuild()

Please vote for clearer documentation from the Gradle team: https://github.com/gradle/gradle/issues/36495

How to install tailscale on your Unifi router (UDM)

ColtonIdle — Thu, 09 Oct 2025 19:47:00 +0000

I've become a bit enamored with tailscale. All I wanted to do is replace the "teleport" connection I use from my mobile device to my at home network. This led me down a bit of a rabbit hole. I wanted to install on my UDM Pro Max since it seems like the right "device" on my network that should handle it and I noticed that glinet routers have tailscale support built in. Super cool!

For now upvote for native tailscale support on unifi hardware and I'll walk you through how to install. https://community.ui.com/questions/Feature-Request-Support-Tailscale-under-VPN-options/d9ecb8cc-9f25-41bf-b19d-85615c27a857

For me... there are 3 things things I wanted to make sure this tailscale setup would support... mimicking what unifis teleport does for me

My 3 goals:

access my photo and media server by hitting their IPs directly (192.168.1.116 and 192.168.1.122)
access my servers via custom dns entries I created on my router (ie. my.media/ and my.photos/
I can log into my home tv service app and it thinks I'm at home so I can watch my content

Install steps

1. Enable ssh on unifi. Go to "Control Plane" > Console > SSH and enable it

2. SSH into your UDM ssh root@[YOUR UDM IP]

3. Install tailscale via https://github.com/SierraSoftworks/tailscale-udm so use curl -sSLq https://raw.github.com/SierraSoftworks/tailscale-udm/main/install.sh | sh

4. Run tailscale up. You might hit an error. If so it's because you have to use a workaround for newer unifi network updates

If you hit an error you can do:

vim /etc/apt/sources.list

then identify the line for bullseye-backports and update it to

deb https://archive.debian.org/debian/ bullseye-backports main

then save.

See: https://github.com/SierraSoftworks/tailscale-udm/issues/116 for more info

5. Then to patch DNS not working you must do

touch /run/dnsmasq.dhcp.conf.d/tailscale0.conf
vim /run/dnsmasq.dhcp.conf.d/tailscale0.conf

Add this line to the file
interface=tailscale0
and save

After saving the file, run pkill dnsmasq

If dns still doesn't work, you might have to kill it via

killall dnsmasq
then
pgrep dnsmasq
to confirm it was back up

See: https://github.com/SierraSoftworks/tailscale-udm/issues/122 for more info

6. Done (mostly) with setup

Going back to my 3 things I outlined

1. access my photo and media server by hitting their IPs directly (192.168.1.116 and 192.168.1.122)

Enable subnet routing... and then this works!

2. access my servers via custom dns entries I created on my router (ie. my.media/ and my.photos/

Go to tailscale admin console > DNS > Override global dns then > Insert IP of router. And it works!

3. I can log into my home tv service app and it thinks I'm at home so I can watch my content

Enable exit node on the UDM, then use UDM as an exit node when you need this

Ask Unifi to support tailscale as a first class citizen!

https://community.ui.com/questions/Feature-Request-Support-Tailscale-under-VPN-options/d9ecb8cc-9f25-41bf-b19d-85615c27a857

Android Dev and zscaler

ColtonIdle — Fri, 19 Sep 2025 17:50:00 +0000

Are you installing cacerts into every jdk?

How about just adding onto your global gradle.properties (i.e. ~/.gradle/gradle.properties)

For Gradle:
# local zScaler proxy host and port
systemProp.https.proxyHost=127.0.0.1
systemProp.https.proxyPort=9000
# to support zScaler TLS inspection, use the Windows cert storage with the zScaler cert
systemProp.javax.net.ssl.trustStoreType=Windows-ROOT
# macOS
systemProp.javax.net.ssl.trustStoreType=KeychainStore

On my mac, all I needed was systemProp.javax.net.ssl.trustStoreType=KeychainStore but I'm including everything else above just in case.

You can also set this on java instead of gradle. This could be helpful if running tools like gradle-profiler which don't automatically detect your gradle user home.

export JAVA_TOOL_OPTIONS="-Djavax.net.ssl.trustStoreType=KeychainStore"

Last resort:
~/.gradle/init.d/certs.init.gradle.kts

add this

import java.security.KeyStore
import java.security.cert.CertificateFactory
import java.security.cert.X509Certificate

val trustStoreProp = "javax.net.ssl.trustStore"
val privateRootFile = file("private.pem")

beforeSettings {
    if (System.getProperty(trustStoreProp)?.endsWith("+private") == true) return@beforeSettings
    val defaultTrustStore = System.getProperty(trustStoreProp)?.let { File(it) }
        ?: File(System.getProperty("java.home"), "lib/security/cacerts")
    val alternateTrustStore = File(rootDir, "build/tmp/cacerts+private")
    try {
        val keyStore = KeyStore.getInstance(KeyStore.getDefaultType())
        val trustStorePassword = System.getProperty("${trustStoreProp}Password")?.toCharArray()
        if (defaultTrustStore.exists()) defaultTrustStore.inputStream().use { keyStore.load(it, trustStorePassword) }
        val privateRoot = privateRootFile.inputStream()
            .use(CertificateFactory.getInstance("X.509")::generateCertificate) as X509Certificate
        keyStore.setCertificateEntry(privateRoot.subjectX500Principal.name, privateRoot)
        alternateTrustStore.parentFile.mkdirs()
        alternateTrustStore.outputStream().use {
            keyStore.store(it, trustStorePassword ?: "changeit".toCharArray())
        }
    } catch (e: Exception) {
        if (alternateTrustStore.exists()) alternateTrustStore.delete()
        throw e
    }
    System.setProperty(trustStoreProp, alternateTrustStore.absolutePath)
    logger.info("$trustStoreProp set to $alternateTrustStore")
}

Compose for Desktop: App size comparison

ColtonIdle — Tue, 25 Mar 2025 04:07:31 +0000

While trying to figure out how to use Compose for Desktop with proguard (and conveyor) I got some interesting stats:

I used an empty template app from https://kmp.jetbrains.com

I'll be using an apple silicon mac as my benchmark for app sizes.

./gradlew packageDmg

64.9MB for .dmg
124.1MB for .app (what you get when you open .dmg)

This doesn't use conveyor, but we can use it as a baseline.

./gradlew packageReleaseDmg

51.9MB for .dmg
109.9MB for .app (what you get when you open .dmg)

This is all we need to run proguard apparently as any release task will have proguard enabled. See: https://www.jetbrains.com/help/kotlin-multiplatform-dev/compose-native-distribution.html#minification-and-obfuscation

./gradlew packageReleaseDmg but with obfuscate.set(true)

48MB for .dmg
105.8MB for .app (what you get when you open .dmg)

./gradlew desktopJar && conveyor make site A regular unproguarded app with conveyor

71.5MB example-1.0.0-mac-aarch64.zip
120.9MB Example.app

At this point I have a minimal conveyor.conf

include "#!./gradlew -q printConveyorConfig"

app {
  display-name = "SampleProject"
  site.base-url = "localhost:3000"
}
conveyor.compatibility-level = 17

./gradlew desktopJar && conveyor make site A regular unproguarded app with conveyor but enables "native library extraction" (I still don't really know what it is, but it seems like it's the recommended way to distribute apps with conveyor, even though it's off by default) See: https://github.com/hydraulic-software/compose-multiplatform-starter/blob/master/conveyor.conf#L5-L10

62.3MB example-1.0.0-mac-aarch64.zip
123.8MB Example.app

My conveyor.conf

include "#!./gradlew -q printConveyorConfig"

include required("https://raw.githubusercontent.com/hydraulic-software/conveyor/master/configs/jvm/extract-native-libraries.conf")

app {
  display-name = "SampleProject"
  site.base-url = "localhost:3000"
}
conveyor.compatibility-level = 17

Surprisingly small zip!

./gradlew proguardReleaseJars && conveyor make site Proguarded app with conveyor

58.6MB example-1.0.0-mac-aarch64.zip
106.3MB Example.app

My conveyor.conf gets a little tricky. You can figure out the paths at the bottom by running ./gradlew printConveyorConfig See: https://conveyor.hydraulic.dev/17.0/configs/jvm/#proguard-obfuscation

include "#!./gradlew -q printConveyorConfig"
gradle-cache = ${env.HOME}/.gradle    # Note: UNIX specific config!

app {
  display-name = "SampleProject"
  site.base-url = "localhost:3000"

  # Import all the obfuscated JARs, except the JAR that contains the platform native graphics code.
  inputs = [{
        from = composeApp/build/compose/tmp/main-release/proguard
        remap = [
            "**"
            "-skiko-awt-runtime-*.jar"
        ]
      }]

      # Put the dropped JAR back with the right version for each platform.
      linux.amd64.inputs = ${app.inputs} [ ${gradle-cache}/caches/modules-2/files-2.1/org.jetbrains.skiko/skiko-awt-runtime-linux-x64/0.9.3/e6fa1645020a9ed8ca2c1058f541dfeff8a9df6/skiko-awt-runtime-linux-x64-0.9.3.jar ]
      mac.aarch64.inputs = ${app.inputs} [ ${gradle-cache}/caches/modules-2/files-2.1/org.jetbrains.skiko/skiko-awt-runtime-macos-arm64/0.9.3/9fb269f5829942f307e14d0f9bafdd30c886cabc/skiko-awt-runtime-macos-arm64-0.9.3.jar ]
      mac.amd64.inputs = ${app.inputs} [ ${gradle-cache}/caches/modules-2/files-2.1/org.jetbrains.skiko/skiko-awt-runtime-macos-x64/0.9.3/33b53df6426efa34461268b1005cb8c9ceaffce1/skiko-awt-runtime-macos-x64-0.9.3.jar ]
      windows.amd64.inputs = ${app.inputs} [ ${gradle-cache}/caches/modules-2/files-2.1/org.jetbrains.skiko/skiko-awt-runtime-windows-x64/0.9.3/89198469fcb0543ccd8e09a0cfbe0334d4a1f6dd/skiko-awt-runtime-windows-x64-0.9.3.jar ]
}
conveyor.compatibility-level = 17

./gradlew proguardReleaseJars && conveyor make site Proguarded app with conveyor with "native library extraction"

49.4MB example-1.0.0-mac-aarch64.zip
109.2MB Example.app

Same conveyor.conf as above, but adds

include required("https://raw.githubusercontent.com/hydraulic-software/conveyor/master/configs/jvm/extract-native-libraries.conf")

.zip format seems to really like when you enable native library extraction

./gradlew proguardReleaseJars && conveyor make site Proguarded app with conveyor with obfuscate.set(true)

54.6MB example-1.0.0-mac-aarch64.zip
102.3MB Example.app

Same conveyor.conf as above, but now we remove

include required("https://raw.githubusercontent.com/hydraulic-software/conveyor/master/configs/jvm/extract-native-libraries.conf")

./gradlew proguardReleaseJars && conveyor make site Proguarded app with conveyor with "native library extraction" with obfuscate.set(true)

45.5MB example-1.0.0-mac-aarch64.zip
105.2MB Example.app

Same conveyor.conf as above, but adds

include required("https://raw.githubusercontent.com/hydraulic-software/conveyor/master/configs/jvm/extract-native-libraries.conf")

Short n' Sweet

./gradlew packageDmg No conveyor.

64.9MB for .dmg
124.1MB for .app (what you get when you open .dmg)

./gradlew packageReleaseDmg No conveyor, but runs proguard.

51.9MB for .dmg
109.9MB for .app (what you get when you open .dmg)

./gradlew packageReleaseDmg No conveyor, but runs proguard with obfuscate.set(true)

48MB for .dmg
105.8MB for .app (what you get when you open .dmg)

./gradlew desktopJar && conveyor make site A regular unproguarded app with conveyor

71.5MB example-1.0.0-mac-aarch64.zip
120.9MB Example.app

./gradlew desktopJar && conveyor make site A regular unproguarded app with conveyor + conveyor's "native library extraction"

62.3MB example-1.0.0-mac-aarch64.zip
123.8MB Example.app

./gradlew proguardReleaseJars && conveyor make site Proguarded app with conveyor

58.6MB example-1.0.0-mac-aarch64.zip
106.3MB Example.app

./gradlew proguardReleaseJars && conveyor make site Proguarded app with conveyor with conveyor's "native library extraction"

49.4MB example-1.0.0-mac-aarch64.zip
109.2MB Example.app

./gradlew proguardReleaseJars && conveyor make site Proguarded and obfuscated app with conveyor

54.6MB example-1.0.0-mac-aarch64.zip
102.3MB Example.app

./gradlew proguardReleaseJars && conveyor make site Proguarded and obfuscated app with conveyor with conveyor's "native library extraction"

45.5MB example-1.0.0-mac-aarch64.zip
105.2MB Example.app

The winner!

I care about initial download size. An app built with conveyor + conveyor's "native library extraction" + proguard + obfuscation (arguably the combo that everyone should aim for) comes in at the smallest download size of 45.5MB. And that contains extra code in there for sparkle (the update framework) that you don't get with the typical gradlew package* tasks (and its also supposed to help with small delta updates). Way cool!

How to profile your Android app's build time

ColtonIdle — Fri, 14 Mar 2025 17:39:06 +0000

If you've ever wondered "Will my project build faster with 8 gigs of ram vs 4" then this article is for you.

Today we'll be talking about the standalone gradle-profiler tool. There's a nice little intro into using it here: https://developer.android.com/studio/build/profile-your-build but a lot of the stuff there still went over my head. I am but a measly android developer, who still feels like I need a PhD to understand gradle.

I've got two typical scenarios I want to test that I run into every day.

Builds after a clean
Incremental builds

Builds after a clean seem to take my project around 3 minutes on average. This is completely unmeasured, but mostly this is what I see in the bottom right hand corner in Android Studio "You build finished in 3 minutes and 02 seconds". Going through a clean is pretty popular for me because sometimes things just don't work in the IDE (I think a lot of it is/might be due to kapt), but regardless I have to clean/invalidate caches/restart/hope that my build is fixed. And then re-run. This is the scenario I want to test first.

Install gradle-profiler

git clone https://github.com/gradle/gradle-profiler
    && cd gradle-profiler
    && ./gradlew installDist

Edit: Now available on brew

brew install gradle-profiler

CD into the gradle-profiler

CD into the profiler build/install/gradle-profiler/bin

Create a scenarios.txt

A scenarios.txt lists all of the scenarios that the gradle-profiler will run through. I found that the one that is in the Android Studio docs wasn't that helpful to me in testing my first scenario. I did get a ton of help from Paul Merlin who works on the Gradle team.

This is mine

clean_build_1gb {
    tasks = [":app:assembleFreeDebug", "--rerun-tasks"]
    jvm-args = ["-Xmx1024m", "-Dkotlin.daemon.jvm.options=-Xmx1024m"]
}

clean_build_2gb {
    tasks = [":app:assembleFreeDebug", "--rerun-tasks"]
    jvm-args = ["-Xmx2048m", "-Dkotlin.daemon.jvm.options=-Xmx2048m"]
}

clean_build_4gb {
    tasks = [":app:assembleFreeDebug", "--rerun-tasks"]
    jvm-args = ["-Xmx4096m", "-Dkotlin.daemon.jvm.options=-Xmx4096m"]
}

clean_build_8gb {
    tasks = [":app:assembleFreeDebug", "--rerun-tasks"]
    jvm-args = ["-Xmx8192m", "-Dkotlin.daemon.jvm.options=-Xmx8192m"]
}

clean_build_16gb {
    tasks = [":app:assembleFreeDebug", "--rerun-tasks"]
    jvm-args = ["-Xmx16384m", "-Dkotlin.daemon.jvm.options=-Xmx16384m"]
}

clean_build_32gb {
    tasks = [":app:assembleFreeDebug", "--rerun-tasks"]
    jvm-args = ["-Xmx32768m", "-Dkotlin.daemon.jvm.options=-Xmx32768m"]
}

As you can see, I test from 1 to 32GB (my machine has a lot of ram), and I set the JVM args and kotlin jvm args to that same amount. I suppose that it would be good if I could tweak both of them to variable and just run this overnight and somehow have it run in a bunch of combinations to see what works best, but I haven't figure out how to do that yet.

You can note that I also added "--rerun-tasks" argument because according to (Paul Merlin)[https://github.com/eskatos] this means "If you want to benchmark a "rebuild everything" scenario you can ... use --rerun-tasks."

Run the profiler

./gradle-profiler --benchmark --project-dir ~/dev/rollertoaster --scenario-file ~/dev/rollertoaster/scenarios.txt

This runs the profiler, pointed at my project file, and points it at the scenarios file in my project. (I'm saving the scenarios there so that other people on my team can easily benchmark and update their local gradle.properties file. The entire thing that has caused me to really try the profiler was the fact that my CI has wildly different ram, vs my desktop, vs my laptop, and all of us adhering to a single gradle.properties felt stupid)

After

Running the profiler could take some time as it runs a few iterations, but it will eventually give you a directory to open. In this directory you'll have an html document and you can pretty much look at the "Mean" column and choose the fastest one for you. Here I'm showing the .CSV output and you can see that my 1GB and 2GB builds failed completely, but to my surprise there wasn't much difference in adding RAM after 4GB.

Then try no-op scenario.

From Tony Robalik

It is named noop (for "no-op"), which runs the :app:assembleDebug task. I call it "no-op" because there are no file changes in this scenario, so every assemble after the first should be a "no-op." This scenario tests whether your primary daily task is well-configured: the task and all its dependencies should all be UP-TO-DATE; this build should be very fast.

noop {
  tasks = [":app:assembleDebug"]
}

Next up, incremental changes!

IN PROGRESS

Thanks to Adam Bennet's article that introduced me to gradle-profiler and how simple it was to get started.

Also see: https://dev.to/autonomousapps/benchmarking-builds-with-gradle-profiler-oa8

I use this:
https://gist.github.com/ColtonIdle/6122faf5aa99740fe8e61487e9a60f27

How to sign and notarize a macOS app with Conveyor

ColtonIdle — Thu, 13 Mar 2025 15:32:19 +0000

Pre-reqs

On a mac (possibly not needed, but I didn't test on windows/linux)
Want a notarized mac app (self-distribution, not on mac app store, although it may still work for mac app store, not sure)
Need an apple dev account ($100 a year)
Integrate conveyor via these instructions https://conveyor.hydraulic.dev/17.100.1/tutorial/tortoise/2-gradle/ and this sample https://github.com/hydraulic-software/compose-multiplatform-starter

Go to ~/Library/Preferences/Hydraulic/Conveyor/ Inside of that folder there will be apple.csr

Source: https://conveyor.hydraulic.dev/17.0/running/#initial-setup-and-default-config

Go to https://developer.apple.com/account/resources/certificates/add and click "Developer ID Application". The page will now show you two different certs. It seems like an "older" cert format is auto-selected, but the new one works and has a longer expiration.

Apple will give you a .cer. Place it somewhere (I just put it in my Conveyor Prefs directory)
Now you need an api key to use apple's notarization service. Go to https://appstoreconnect.apple.com/access/integrations/api and create it with the "Developer" role.

Source: https://conveyor.hydraulic.dev/17.0/configs/keys-and-certificates/#configure-apple-notarization

Your final defaults.conf:

# Your private root key, from which all other generated keys are deterministically derived.
app.signing-key = "keyring"

# Credentials needed for the macOS app approval process.
 app.mac.notarization {
   issuer-id = abc-123-123-123-ABC123
   key-id = ABC123123
   private-key = /Users/cidle/Library/Preferences/Hydraulic/Conveyor/AuthKey_ABC123.p8
 }

app.mac.certificate = /Users/cidle/Library/Preferences/Hydraulic/Conveyor/cert_from_apple.cer

Note: Even though the docs make it seem like you might need app.mac.signing-key, you do not.

Note 2: app.mac.certificate can be a relative path (to the defaults.conf) it doesn't have to be absolute

How to setup compose desktop hot reload

ColtonIdle — Tue, 11 Mar 2025 04:04:40 +0000

Steps:

Use Kotlin 2.1.20-RC (or any higher if released)
Apply the plugin
Wrap the content of a window with DevelopmentEntryPoint {}
Use OptimizeNonSkippingGroups (optional, but a better experience for me).
Then in a KMP project and IntelliJ, just using main function run gutter to run the APP.
If you're using Kotlin JVM or Android Studio, then configure the jvmRun task or provide
./gradlew jvmRun -DmainClass=path.toMain.MainKt

Basically, running compose apps is the easiest if using KMP + IntelliJ.

Note: Must use JVM that is shipped with Intellj. Navigate to Settings > Gradle > JDK and make sure IntelliJ JDK is selected

Compose for Desktop: Window party tricks

ColtonIdle — Mon, 03 Mar 2025 17:40:33 +0000

Just a random collection of window tricks I've accumulated while trying to build a desktop app.

1. Size the window to your content

Sometimes you just want your window to match the size of your content. I've found this to be true for settings windows for example. Simply use:

val state = rememberWindowState(
    size = DpSize(Dp.Unspecified, Dp.Unspecified)
)

Make sure your root layouts don't have fillMaxSize() or else this won't work. You can optionally also make the Window non-resizable via resizable = false on the Window.

If you need the window size to adjust to your content size, checkout https://gist.github.com/ColtonIdle/df23e3dc8e72569a28a4c64197bed14c

More info: https://kotlinlang.slack.com/archives/C01D6HTPATV/p1740892851067859

2. Start with the window centered

Use:

Window(
state = rememberWindowState(position = WindowPosition(Alignment.Center))

(Barely) More info: https://kotlinlang.slack.com/archives/C01D6HTPATV/p1739326963488559

3. Remove title bar

Use:

fun main() = application {
    Window(
        onCloseRequest = ::exitApplication,
        title = ""
    ) {
        Box(Modifier.fillMaxSize().background(Color.Red))
        LaunchedEffect(window.rootPane) {
            with(window.rootPane) {
                putClientProperty("apple.awt.transparentTitleBar", true)
                putClientProperty("apple.awt.fullWindowContent", true)
            }
        }
    }
}

More info:
https://kotlinlang.slack.com/archives/C01D6HTPATV/p1739449034315049

4. Bring window to front and into focus

If you need to bring it to the foreground and focussed

Desktop.getDesktop().requestForeground(true)

More info:
https://github.com/JetBrains/compose-multiplatform/issues/4231#issuecomment-1952205605
and
https://kotlinlang.slack.com/archives/C01D6HTPATV/p1739152698052949

5. Customize UI stuff on Java/macOS: https://developer.apple.com/library/archive/technotes/tn2007/tn2196.html

Source: https://kotlinlang.slack.com/archives/C01D6HTPATV/p1741607313291729

6. Custom title bar

Apparently some stuff changed in later JDK versions?

See: https://gist.github.com/adrientetar/b039998a0752261d2ee7db9ade3e7c15

How to use Hydraulic Conveyor with KMP Compose for Desktop

ColtonIdle — Tue, 25 Feb 2025 19:57:54 +0000

Download a new project from https://kmp.jetbrains.com/ and be sure to select a desktop application
In your app level build.gradle add id("dev.hydraulic.conveyor") version "1.12"

You may want to include it in your root build.gradle with apply false if you get any issues in the future as per: https://programminghard.dev/gradle-plugins-best-practices/

In app level build.gradle.kts add (this does not go into any block. just goes at the top level of this file)

version = "1.0"

This is needed even though a version is already declared in the nativeDistributions block.

In app build.gradle.kts under jvm("desktop") add

    jvmToolchain {
        languageVersion.set(JavaLanguageVersion.of(21))
        vendor.set(JvmVendorSpec.JETBRAINS)
    }

In app build.gradle.kts at the top level add a dependencies block (it most likely wont be there unless you're building an android app). You will already have 2 other dependencies blocks most likely, but those are nested inside of the kotlin and sourceSets blocks. This one is needed at the top level.

 dependencies {
     debugImplementation(compose.uiTooling) <=== This will only be here if you are building an android app

    // Use the configurations created by the Conveyor plugin to tell Gradle/Conveyor where to find the artifacts for each platform.
    linuxAmd64(compose.desktop.linux_x64)
    macAmd64(compose.desktop.macos_x64)
    macAarch64(compose.desktop.macos_arm64)
    windowsAmd64(compose.desktop.windows_x64)
 }

In app level build.gradle.kts you will find

         nativeDistributions {
             targetFormats(TargetFormat.Dmg, TargetFormat.Msi, TargetFormat.Deb)
             packageName = "org.example.project"
             packageVersion = "1.0.0"
         }
     }
 }

but for some reason conveyor doesn't work with package names that are reverse dns. Replace that with packageName = "example-project"

In app level build.gradle.kts at the top level you can add

// Work around temporary Compose bugs.
configurations.all {
    attributes {
        // https://github.com/JetBrains/compose-jb/issues/1404#issuecomment-1146894731
        attribute(Attribute.of("ui", String::class.java), "awt")
    }
}

In settings.gradle.kts you can add

plugins {
    id("org.gradle.toolchains.foojay-resolver-convention") version("0.8.0")
}

This has to be declared after your plugin dependency block.

Add a minimal conveyor.conf file

include "#!./gradlew -q printConveyorConfig"

app {
  display-name = My Amazing Project
  site.base-url = localhost/some/path
}
conveyor.compatibility-level = 17

See: https://conveyor.hydraulic.dev/17.0/configs/ for more configuration

Run ./gradlew desktopJar (Conveyor doesn't trigger your build for you yet so you still need to run this)
Run conveyor make site
When you make an update to your desktop app, update the version number we declared earlier, run ./gradlew desktopJar, and then conveyor make site --overwrite

🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉

Note: You may want to call ./gradlew proguardReleaseJars instead of desktopJar, but you need to setup proguard. I have not done this yet, but I will link it here if I figure out how to do that.

How to use htmx with ktor

ColtonIdle — Wed, 17 Apr 2024 03:05:34 +0000

1 Clone this repo https://github.com/tom-delalande/html-to-kotlin-converter and open in intellij
2 In the root of that project folder, create input.txt and add the component/html that you want to convert (feel free to pick a component from tailwind), run main in that project and it'll be converted to kotlin ktor html DSL in output.txt (basically, that's the readme of that project lol)
3 in your ktor project (make sure you already added ktor-html from kotlin team), respond to a route like so

call.respondHtml(HttpStatusCode.OK) {
    head {
        title {
            +"tailwind sample"
        }
        script { src = "https://cdn.tailwindcss.com" }
    }
    body {
    //paste the output of the input.txt
    }

4 Some tags are missing, so feel free to add them yourself as such

import kotlinx.html.FlowContent
import kotlinx.html.HTMLTag
import kotlinx.html.HtmlBlockTag
import kotlinx.html.HtmlTagMarker
import kotlinx.html.TagConsumer
import kotlinx.html.attributesMapOf
import kotlinx.html.visit

@HtmlTagMarker
inline fun FlowContent.path(classes : String? = null, crossinline block : PATH.() -> Unit = {}) : Unit = PATH(
    attributesMapOf("class", classes), consumer).visit(block)

@Suppress("unused")
open class PATH(initialAttributes : Map<String, String>, override val consumer : TagConsumer<*>) : HTMLTag("path", consumer, initialAttributes, null, false, false), HtmlBlockTag {

}

5 done!

Thanks prime for the video, and a big thanks to Tom Delalande for this video https://www.youtube.com/watch?v=9OYn48xBzOY and the code snippets above. Join his discord here if you have more questions https://discord.com/invite/Cg66xQ8KgP

How to deploy a Ktor app on Railway

ColtonIdle — Wed, 10 Apr 2024 20:51:44 +0000

Deploying Ktor onto Railway isn't too popular, but I have found two different ways to do it.

Option 1

use https://start.ktor.io/ and just download the baseline project there
On railway set build command to ./gradlew buildFatJar
On railway set deploy command to ./gradlew runFatJar
On railway Set a variable of PORT to 8080

Note: In railway free tier, ./gradlew runFatJar seems to sometimes time-out so you can instead use java -jar thejarname-all.jar seems to work fine without causing issues

Option 2

use https://start.ktor.io/ and just download the baseline project there
On railway set PORT variable to 8080
Add a nixpacks.toml to the root of your project containing...

[start]
cmd = 'java $JAVA_OPTS -jar build/libs/*-all.jar'

(Basically the same as setting the start command in option 1)

Option 3

Docker or Docker Compose
https://ktor.io/docs/docker.html
https://ktor.io/docs/docker-compose.html

Bonus tips:

Downtime/503's should be non-existent if you use railway's health-check feature + set the overlap time. This will make sure that your old service is still running until the new service is actually up and running.

Set a healthcheck path at railway > [Your Project] > Settings > Healthcheck https://docs.railway.app/reference/healthchecks
~~Set the RAILWAY_DEPLOYMENT_OVERLAP_SECONDS more info~~ Edit: As of July 20th, 24 you don't need this if you move to the new Edge Proxy (Beta) "Opt-in to try our latest proxy. Deploy faster, and help us build our next edge." Enable this under "Settings" of your service.
You can skip setting a PORT variable in Option 1, 2 and railway will randomly assign one. Then in your ktor code you can use System.getenv("PORT") to get the port from railway.
Instead of using nixpacks.toml you can use railway.json since it will do schema validation for you.

{
    "$schema": "https://schema.up.railway.app/railway.schema.json",
    "build": {
        "builder": "NIXPACKS",
        "buildCommand": "./gradlew -p server clean build -x check -x test"
    },
    "deploy": {
        "startCommand": "java $JAVA_OPTS -jar server/build/libs/*-all.jar"
    }
}

Thanks @Brody and @Aleks for all of your help!

The unfortunate challenge in signing a new app to release on Google Play in Nov of 2021

ColtonIdle — Fri, 19 Nov 2021 21:20:16 +0000

I'm trying to deploy an app to Google Play and it's been challenging.

First I'm greeted with this page. Wojtek Kaliciński has a video on this and it was amazingly helpful in deciding the right choice for me. I wish this video was linked on the play console 😄

My choice is to go with "Export and upload a key from Java keystore".

Next, I went to download the PEPK tool, but was greeted with this 404 page. After ~~complaining~~ notifying @googleplay, @googleplaydev and Wojtek about it on Twitter... Wojtek got back to me first to tell me it was fixed. Hooray Wojtek and developer relations!

Now that I actually have the pepk.jar I stumbled a bit more unfortunately. Firstly, I went to create the keystore.

I had a few problems with this dialog and overall I feel like it should get some attention from the AS team. First is when you try to choose a keystore path, it just creates a file with no extension. This is weird to me because I (think) that the file should be a .jks extension(but what do I know)? I don't actually know for sure if it's important, but it feels weird that the wizard doesn't default to it.

Update: Wojtek said "the extension of the keystore doesn't really matter, that said on Linux it did create .jks for me" With that said, I'm going to always use .jks as that shows me what the intent of the file is. I do wish that they just used .jks everywhere instead of jumping between a bunch of different name schemes.

The next issue is adding a password. Following the docs:

Create and confirm a secure password for your key. This should be different from the password you chose for your keystore.

If you actually try to put a different password for the keystore and the alias you're greeted with this.

As a non-expert in security... I don't know what the hell is going on. I suppose that I'll just try to create the keystore and alias with the same password.

Someone should file a bug for that. Oh right! I did a few months back.

Okay... so I have a keystore... now it's time to run the pepk command we saw at the top!

Run the tool using the command below to export and encrypt your private key. Replace the arguments, and enter your keystore and key passwords when prompted.

Okay... so I have to replace the bolded text...

--keystore=foo.keystore --alias=foo --output=output.zip

Okay... so I'm having this jks "issue" again? Is it .jks or is it .keystore or does it not have an ext at all? The alias (I think) should just be key0 (I left it as the default alias name in the AS keystore generation wizard) and the output.zip name seems fine.

Okay... so I will now run this command. Note that I added the extension .jks to the prod file that was generated.

$ java -jar pepk.jar --keystore=prod.jks --alias=key0 --output=output.zip --include-cert --encryptionkey=abc123abc123abc123abc123abc123abc123abc123abc123abc123abc123abc123abc123abc123abc123

Another error!

Error: No value provided for flag: include-cert
USAGE:
       java -jar pepk.jar --keystore <release_keystore> --alias <key_alias> --encryptionkey=<encryption_key_hex> --output=<output_file>

Okay... so now I'm lost again. Is include-cert needed or not?

For now... let's just drop that flag and see what happens.

$ java -jar pepk.jar --keystore=prod.jks --alias=key0 --output=output.zip --encryptionkey=abc123abc123abc123abc123abc123abc123abc123abc123abc123abc123abc123abc123abc123abc123

Update: The problem was that I was using Java 15. I downloaded a Java 11 jar and used that instead and everything worked! I filed a bug to update pepk tool, or to add a warning that the pepk tool only works with (presumably) Java 11 and lower.

It asks me for the store password and then a key password. Now I'm starting to feel really bad that I created both store and key with the same password. The docs said to use a different password too. Oh well. I'll accept the risk I suppose.

Hooray! I think we're getting somewhere! output.zip was generated!

One last step! Wojtek's video said that it's recommended to create a new upload key. Let's do that!

The screenshot above says "For increased security, create a new upload key (optional)." so it sounds like I'll want it!

All I need is a single command, and replace the bolded keywords...

keytool -export -rfc -keystore upload-keystore.jks -alias upload -file upload_certificate.pem

Okay. Now I'm confused again... It's talking about an upload-keystore.jks... is this different than the foo.keystore they were talking about? I don't know... but I'm going to assume that it's actually the same keystore. All this time... I'm still confused if I should be using prod, prod-keystore or prod.jks. Someone send help!!!

Okay. What's the alias? upload? Should I use key0? Send more help!!!

The command I ended up with is

keytool -export -rfc -keystore prod.jks -alias key0 -file upload_certificate.pem

As you can hopefully tell... I opted not to create a new keystore in the AS wizard... I just used the keystore I already created and I'm assuming that it'll create the upload key from that.

Update: As per Wojtek, you should be using a new key/alias or a new keystore entirely.

"You can run it again and generate a new keystore with a new key. A keystore can contain multiple keys, but it might be easier to just keep them separate. A keystore is just a file container for keys" -Wojtek

"it" in the context above is the "AS keystore generation wizard"

Upload time!

I upload the generated zip... and the key certificate... and...

@!%@

I give up (for now). If someone from the Play Console or Android Studio team in general read this... please send help. :sweat-smile:

Update! It works!

With some help on Twitter from Wojtek I was able to figure everything out.

The gist of it is:

The pepk tool is no longer 404'ing
The pepk tool doesn't work with Java 15, but worked with Java 11.
The docs still say to use a different password for the keystore and alias, but it seems that using the same one is fine
To use the additional security of an upload key, you can just generate another keystore + alias combo for uploading.
At the end of these steps you'll have a
- app-signing.jks that Google will use to sign your app, and you can use this for other stores/dist methods. Never lose this.
- app-upload.jks is what you will use to sign your app when uploading to google play, and google will then use the app-signing.jks to sign on your behalf. If this upload key is lost or falls into the wrong hands, you can request a new one!
- output.zip which is the output of the pepk command. After you upload this, you are safe to delete it. It is only necessary in order to give google your encrypted private key.
- upload.pem is your public key that you give google so they know when they receive a valid app upload that was signed with your private key. You are safe to delete this as well after you upload it.