Debug Versus Release Builds

A build type changes how the same source is compiled and packaged. debug exists implicitly; BookNest configured release piece by piece through this chapter, and now it adds a version and a real key:

BookNest's two build types
debug release
Debuggable (debugger, run-as) Yes No
R8 234 and resource shrinking (R8) Off On
BuildConfig.DEBUG, composition logs (Recomposition Counts) true, logged false, compiled out
Log.d/Log.v calls Kept Removed by the keep rule (ProGuard Rules and Keep Lists)
Baseline profile (Baseline Profiles) None From src/release/generated/
Signed with SDK debug key Upload key (App Signing and the Upload Key)
APK size 21,981,979 bytes (How R8 Works) 4,422,522 bytes (Building an Android App Bundle)

debugImplementation dependencies (Compose 234 tooling, the test manifest) never reach a release, and speed is measured only on release-like builds such as Performance's benchmarkRelease.

Versions work as in Versions and App IDs: versionName is the label users see, and versionCode is the integer Play compares, higher on every upload. BookNest 1.0.0 sets versionName = "1.0.0" and versionCode = 10000 (major x 10000 + minor x 100 + patch) in defaultConfig. Its applicationId must change from com.example.booknest, which Play refuses, to a domain you own before a real upload; the namespace for R and BuildConfig can stay. A productFlavors block (free and paid, or staging) combines with each build type into a variant such as stagingRelease.