Building the Contact-Centre Apps

The contact-centre apps are the Android and Windows clients of the Unified Contact Center: an agent signs in and answers conversations away from the browser. Neither is on a store or a download page yet, so somebody builds them. This page is for that person: by the end you have a Windows installer for the agents’ PCs and an Android build you can put on a phone.

Both come from one Kotlin Multiplatform repository, akn-kotlin-ucc-app, and both call the same API as the applet: the conversations they show are the applet’s, and Tasks, Notifications and Outbound Leads still show sample data, as the agent guides say. What the agents do with them is in UCC Desktop App and UCC Mobile App.

Before you start

A clone of the akn-kotlin-ucc-app repository.
JDK 21 (a full JDK — the Android Studio runtime will not do, as it has no jpackage).
A Windows machine for the Windows installer. macOS (.dmg) and Linux (.deb) targets are configured but are built on those platforms.

Step 1: Raise the version, then build the Windows installer

The outcome: a .msi that installs over the build the agents already have.

Open composeApp/build.gradle.kts and raise packageVersion under nativeDistributions (it reads 1.0.1 at commit a60f772, 26 October 2026). Do this before every build. Windows Installer tells one build from another by its version, so a second installer with the same version as the one on the PC does not upgrade it: Windows reports that the product is already installed. Then:

./gradlew :composeApp:packageMsi

The result lands in composeApp/build/compose/binaries/main/msi/. The installer registers the app as BLG UCC and installs it to C:\Program Files\BLG UCC\BLG UCC.exe. A build from the repository as it stands since 26 October 2026 also adds a Start-menu entry under BigLedger and names BigLedger as the vendor; an older installer has no Start-menu entry and names the vendor Unknown.

That change was checked on a macOS build only. On your first Windows build after it, look for the Start-menu entry, and check Installed apps: the vendor is part of how Windows may identify the product, so that one build might install beside the old one instead of over it. If BLG UCC is listed twice, uninstall the older entry. This has not been confirmed on Windows.

Step 2: Run the desktop app without installing

The outcome: the desktop app open on your own machine, for a quick check. From the repository:

./gradlew :composeApp:run

Step 3: Build the Android app

The outcome: an APK for a test phone, or a signed bundle for Google Play.

For a phone you are testing on, build a debug APK:

./gradlew :composeApp:assembleDebug

It lands in composeApp/build/outputs/apk/debug/, and installs on Android 8.0 or later. The repository’s CI builds the same thing on every pull request.

A release goes through CI once the app exists on Google Play (the first bundle is uploaded by hand, PUBLISHING.md §4). From then on every push to main builds a signed bundle, numbers it one above the latest build on Google Play, and uploads it as a draft to Play’s internal testing track; somebody then releases it there and promotes it by hand in Play Console. PUBLISHING.md in the repository sets that up once: the upload keystore, the CI signing and the Play service account. To build a signed bundle on your own machine instead, put the keystore details in a keystore.properties file in the project root (it is git-ignored) and run ./gradlew :composeApp:bundleRelease.

Without signing details, the release build stays unsigned and does not fail, so a green build is not proof that it is signed. And the package name, com.bigledger.ucc, can never change after the first upload to Google Play.

What success looks like

On a Windows PC that already has the app, run your new installer: there is no already installed message, Installed apps lists BLG UCC once, at your new version, and BLG UCC is in the Start menu under BigLedger. Sign in and open a conversation, as UCC Desktop App › What success looks like describes. On a test phone, install the debug APK and sign in.

Common mistakes

Symptom	Cause	Fix
Windows says the product is already installed, and the agents keep the old build	`packageVersion` was not raised, so both installers carry one version	Raise it and build again (Step 1)
`packageMsi` fails for want of `jpackage`	The build ran on the Android Studio runtime	Point the build at a full JDK 21
The installed app has no Start-menu entry and the vendor reads Unknown	The installer was built before 26 October 2026	Build from the repository as it stands now, with a raised version
A release build you handed on turns out unsigned	No signing details were found, and the build does not fail for that	Add `keystore.properties` (Step 3) and build again