Debugging, Testing & Publishing to Play Store

Debugging with Logcat

Logcat shows messages from your app and the system. Print your own with Log:

Log.d("TAG", "value = $value")   // debug
Log.e("TAG", "failed", exception) // error with stack trace

Filter by your tag or package to cut the noise.

The breakpoint debugger

Click in the gutter next to a line to set a breakpoint, then run with the debug ▶ button. Execution pauses there so you can inspect variables, step line by line, and understand exactly what your code is doing — far better than guessing.

Reading a crash (stack trace)

When an app crashes, Logcat prints a stack trace. Read it top-down: the first line names the exception (e.g. NullPointerException), and the first line mentioning your package points to the exact file and line number. Start there.

Basic testing

// Unit test (runs on your computer, fast)
class CalculatorTest {
    @Test fun adds() { assertEquals(4, add(2, 2)) }
}

Unit tests check pure logic (ViewModels, repositories). UI tests with Espresso check that screens behave correctly on a device.

Preparing a release

1. Set a unique applicationId and bump versionCode/versionName.
2. Create a signing key (keystore) — keep it safe; you need it for every future update.
3. Build a signed Android App Bundle (.aab): Build → Generate Signed Bundle.
4. Enable shrinking (R8) to reduce app size.

Publishing

Create a Google Play Console account (one-time fee), create your app listing (title, description, screenshots, icon), upload the .aab, fill the content rating and privacy details, then submit for review. Updates follow the same flow with a higher versionCode.

Common mistakes

• Losing the signing keystore — you can never update the app without it.
• Forgetting to raise versionCode on each upload.
• Leaving debug logs and test API keys in the release build.

Summary: Use Logcat and breakpoints to debug, write unit tests for logic, then build a signed .aab, keep your keystore safe, and ship via the Play Console.