First Build, Test And Commit

Lesson Goal

This lesson creates your first checkpoint: the app builds, the test suite passes, the app launches once, you change one line of text on the Splash screen, and Git holds exactly one safe commit.

Why This Checkpoint Matters

Reading architecture is much easier once the app runs. Without this checkpoint, every later error is ambiguous:

• Did an architecture change break something?
• Was the project never configured correctly?
• Is a local secret missing?
• Is Gradle failing because of the environment?

The checkpoint gives you a "known good" point in time. When something breaks, you compare against it instead of guessing.

Part 1: Build The Android App

Open the repo in Android Studio. After sync finishes, click the hammer icon at the top right to build.

Or run this from Android Studio's Terminal tab at the repo root:

./gradlew assembleDebug

In the Windows Command Prompt, type gradlew assembleDebug. The command passes when it ends with BUILD SUCCESSFUL.

Part 2: Run The Test Suite

Tests tell you that you haven't broken an existing feature while building a new one. Run:

./gradlew testDebugUnitTest testAndroidHostTest

This is also the command the repo's CI runs on every pull request (.github/workflows/pr-check.yml). It passes when it ends with BUILD SUCCESSFUL.

Why two tasks? Of the 14 Gradle modules, only :app is a plain Android module. The other 13 are Kotlin Multiplatform, and their tests don't run under the testDebugUnitTest task:

If you only run testDebugUnitTest, Gradle reports green while most of the suite never ran. You will meet this trap in every KMP project: the task names you know from plain Android no longer cover the shared code. When you pick up a new KMP project, confirm which test task actually reaches each module before you trust the green.

Tests of the KMP modules on the iOS Simulator only run on a Mac, through the iosSimulatorArm64Test task.

Part 3: Run The App Once

Pick an emulator or a real phone in the Android Studio toolbar and click Run. Wait until the app gets past the Splash screen and into the Menu.

Part 4: Make One Small Visible Change

Your first commit proves you can change one small detail, check it, and save it safely. Don't refactor a screen, rename a package or change navigation.

The line of text under the logo on the Splash screen is drawn by the SplashScreen composable, in:

shared-app/src/commonMain/kotlin/com/creative/kta/shared/splash/SplashScreen.kt

The file sits in commonMain, so Android and iOS draw the same screen. The text comes from the knowledge_is_power string resource through Compose Resources (Res.string.knowledge_is_power). Change this string's value in two files:

core/src/commonMain/composeResources/values/strings.xml
core/src/commonMain/composeResources/values-vi/strings.xml

The values file is used when the device is set to English, values-vi when it is set to Vietnamese. The Vietnamese text must differ from the English one: LocaleParityTest (which runs in :app's testDebugUnitTest) fails if a Vietnamese string is identical to the English one, or if a key has no values-vi entry.

The repo also has knowledge_is_power in app/src/main/res/values/strings.xml. That's an Android resource, and the Splash screen doesn't read it. Edit it there and nothing changes.

Run the tests from Part 2 again, run the app again and confirm the Splash screen shows the new text.

Part 5: Create A Safe Git Checkpoint

git status
git add core/src/commonMain/composeResources/values/strings.xml core/src/commonMain/composeResources/values-vi/strings.xml
git commit -m "Change splash tagline"

Read git status carefully before you commit. The modified list should only show the two strings files you just edited. local.properties and app/google-services.json don't show up because they are ignored.

Checkpoint

You are done with this lesson when:

• ./gradlew assembleDebug and ./gradlew testDebugUnitTest testAndroidHostTest both end with BUILD SUCCESSFUL,
• The Splash screen shows the new text in both English and Vietnamese,
• git log -1 shows your commit, and the commit holds only the two strings files.

The app builds, the tests are green and you have a first commit on Android. That's the checkpoint you come back to whenever a later change breaks the build.