Debug vs release builds

You have only ever built half the story

Count the number of times you have pressed Run since Lesson 0.3. Dozens, probably a few hundred. Every single one of those produced the same kind of file: a debug build.

There is another kind. It comes from the same source code, the same Gradle and the same phone, and it is a noticeably different app when it lands. It is smaller. It starts faster. Its internals are unreadable. And out of the box, no phone on earth will install it.

That second kind is the release build, and this lesson is the whole of the difference.

Where the two builds come from

Both are already in your project. You did not add them and you cannot remove them — every Android project starts with exactly two build types called debug and release.

Here is the real buildTypes block out of Dice Duel, unedited:

The four things a debug build does for you

Every one of these is a favour, and every one of them has to be undone before anyone else sees your app.

1. It signs itself. Android refuses to install an unsigned app — there is no such thing as an install without a signature. So Android generates a throwaway key the first time you build anything, keeps it in a file called the debug keystore, and quietly signs every debug build with it. That is why pressing Run has never once asked you about keys.

2. It is debuggable. The finished app carries a flag saying "another program is allowed to attach to me and look inside". That is what makes a debugger possible, and it is exactly what you would never want in an app on a stranger's phone.

3. It skips the shrinking. No R8, no renaming, no deleting. Every class you compiled is in there, under its real name, including the thousands of Compose classes your one screen never touches. That is why the Dice Duel debug APK is about 8.7 MB for a game with one screen and one die.

4. It is fast to build. All of the above adds up: nothing to analyse, nothing to rewrite, no key to check. On a phone, that difference is minutes, not seconds.

The four things a release build does instead

Take the favours away and you get the other build.

The last row is the one that surprises people. Build a release APK today, with no key set up, and the build succeeds. It just hands you a file with a name that tells you exactly what is wrong with it:

1app/build/outputs/apk/debug/app-debug.apk
2app/build/outputs/apk/release/app-release-unsigned.apk

An unsigned APK is a complete, finished app. Every class, every picture, every string. Android will still not touch it. Lesson 6.6 is about fixing that.

Turning R8 on

R8 is the shrinker. On a release build it walks your entire program starting from the entry points, works out which code can possibly be reached, and deletes the rest. Then it renames what survives: GameViewModel.rollDice() becomes something like a.b(), which is shorter to store and impossible to skim.

Two settings switch it on, and a third tells it where your rules live:

1buildTypes {
2    release {
3        isMinifyEnabled = true
4        isShrinkResources = true
5        proguardFiles(
6            getDefaultProguardFile(
7                "proguard-android-optimize.txt"
8            ),
9            "proguard-rules.pro"
10        )
11    }
12}

• isMinifyEnabled runs R8 over your code.
• isShrinkResources does the same job for pictures, strings and layouts that nothing refers to. It only works when minifying is already on.
• getDefaultProguardFile(...) pulls in the rules Google ships for you — the ones that stop R8 breaking Android itself.
• proguard-rules.pro is your own file of keep rules, sitting in the app folder. Create it empty; you add to it only when something breaks.

These three apps ship with isMinifyEnabled = false, so this course has never measured a shrunk build of them. For a Compose app of this size, R8 usually removes well over half the file. What it definitely does is make a crash report unreadable, which is why R8 writes a mapping.txt every time it runs. Keep the one that matches each published version and you can translate a.b() back into GameViewModel.rollDice() later.

The task names

You already know assembleDebug from Lesson 2.5. Its siblings do the obvious thing:

1:app:assembleDebug     -> app-debug.apk
2:app:assembleRelease   -> app-release-unsigned.apk
3:app:bundleRelease     -> app-release.aab

The third one produces an AAB rather than an APK. That is the format Google Play wants, and Lesson 6.7 explains why.

What this costs you: nothing

Worth saying plainly, because this is the lesson where the two worlds meet.

Every build in this course is a debug build. Part 0 through to the end of Part 6, all three apps, every checkpoint — debug, all of it. Debug APKs are what the Pocket Studio Free tier produces, and they are all you need to finish everything here and keep building your own apps afterwards.

The Free tier caps how many builds you get. That is the only limit you have run into, and it is why this course keeps telling you to read your change before you press Run. Nothing in Part 6 asks you to pay to carry on learning.