Introduction

Android applications usually expose two version values: a user-facing version name and an internal build version code. You can read them either from generated build constants or from package metadata at runtime, and the right choice depends on whether you need your own app's version or the installed package information from the system.

Understand versionName and versionCode

In Android builds, the common pair is:

• 'versionName: the string shown to users, such as 2.4.1'
• version code: the monotonically increasing build number used for upgrade ordering

Modern Android still relies on the same idea, but newer APIs expose the code as a long-capable value through longVersionCode.

Example Gradle configuration:

1android {
2    defaultConfig {
3        versionCode = 42
4        versionName = "2.4.1"
5    }
6}

Once the app is built, those values are available to your code.

Use BuildConfig for Your Own App

If you just need the current app's build information, BuildConfig is the simplest path.

1import android.util.Log
2
3Log.d("Version", "name=${BuildConfig.VERSION_NAME}")
4Log.d("Version", "code=${BuildConfig.VERSION_CODE}")

This is fast and convenient because the constants are generated at build time.

For Java:

Log.d("Version", "name=" + BuildConfig.VERSION_NAME);
Log.d("Version", "code=" + BuildConfig.VERSION_CODE);

This works well for about screens, logging, and feature diagnostics tied to your own package.

Use PackageManager When You Need Installed Package Info

If you need runtime package metadata, or you want to inspect another installed package, use PackageManager.

1import android.content.pm.PackageManager
2import androidx.core.content.pm.PackageInfoCompat
3
4fun readOwnVersion(pm: PackageManager, packageName: String): Pair<String, Long> {
5    val info = pm.getPackageInfo(packageName, 0)
6    val versionName = info.versionName ?: "unknown"
7    val versionCode = PackageInfoCompat.getLongVersionCode(info)
8    return versionName to versionCode
9}

Usage inside an activity:

val (name, code) = readOwnVersion(packageManager, packageName)
println("versionName=$name versionCode=$code")

The compatibility helper is useful because older and newer Android API levels expose the code slightly differently.

Show the Version in UI Safely

Displaying version information in a settings screen is a common use case.

1binding.versionText.text = buildString {
2    append("Version ")
3    append(BuildConfig.VERSION_NAME)
4    append(" (")
5    append(BuildConfig.VERSION_CODE)
6    append(")")
7}

That keeps the text tied directly to the built artifact, which is better than hardcoding it in a resource string that can drift out of sync.

If you use product flavors or build variants, remember that each variant can have different version metadata. Logging version info during startup is often helpful in QA builds.

Prefer the Right Source for the Job

A practical rule:

• 'BuildConfig for your own app's compile-time version constants'
• 'PackageManager for installed-package queries and runtime package metadata'

If you only need one line in an about screen, BuildConfig is enough. If you are writing support diagnostics, crash reports, or version-aware tooling, package metadata may be more appropriate.

Also be aware that library modules do not always expose the same application-level BuildConfig values you expect. Read the app module's constants, not a random library module's generated class.

Common Pitfalls

• Using a library module's BuildConfig instead of the app module's version constants gives the wrong value.
• Assuming versionCode is always enough without considering newer long version-code handling.
• Hardcoding version strings in UI resources creates drift from the actual built artifact.
• Catching NameNotFoundException for your own package and ignoring it can hide setup problems that should never happen.
• Forgetting that different build variants may produce different version values during testing.

Summary

• Android exposes a user-facing version name and an internal version code.
• Use BuildConfig when you need your own app's generated version constants.
• Use PackageManager and PackageInfoCompat when you need installed package metadata.
• Show version text from the actual build values instead of hardcoded strings.
• Be careful with build variants and module-specific BuildConfig classes.