A compiled Android file can answer several important release questions before you touch the source project. This is useful when you inherited an app, lost contact with the original developer, or simply do not know what was used to build the current release.
What can be checked from an APK or AAB?
The final Android manifest and release metadata can reveal information such as:
- Package/application ID – the identity that must stay consistent for an update to the same Google Play app.
- versionName – the human-readable version shown to users.
- versionCode – the internal release number Google Play uses to order versions.
- minSdk – the minimum Android API level the app declares.
- targetSdk – the Android API level the app targets.
- Native libraries – packaged
.sofiles can signal that a deeper 16 KB compatibility review is required.
Android Studio’s APK Analyzer can inspect both APKs and Android App Bundles and reconstruct the final merged AndroidManifest.xml. That final manifest is often more useful than looking at one source manifest because libraries and build variants can contribute to the merged result.
Why package identity matters
If you intend to update an existing Google Play listing, the application identity must match the existing app. Accidentally rebuilding an old project under a new package creates a different app rather than an update.
This is one reason our first check always records the package value before repair work begins.
versionCode vs versionName
versionName is descriptive. You might call a release 2.4.0 or Summer Update. versionCode is different: it is an internal positive integer, and each new Google Play release must move forward rather than reuse an already-uploaded code.
When restoring an old project, record both values before rebuilding. A technically correct API update can still fail at upload time if its versionCode is not acceptable for the existing Play listing.
What target SDK tells you
The target SDK identifies the Android API level the build is designed and tested to target. For standard phone/tablet Google Play submissions from August 31, 2026, new apps and updates need to target API 36 or higher.
If a compiled build reports target SDK 35, that gives you a clear release-readiness signal: the next normal phone/tablet update needs migration to API 36.
What an APK/AAB cannot prove
A binary check is valuable, but it cannot tell you everything about the source project. It cannot reliably prove:
- whether the source still opens and builds cleanly;
- which Gradle/Android Gradle Plugin migration will be needed;
- whether old dependencies have breaking changes;
- whether Android 16 behaviour changes affect the app’s runtime;
- whether third-party native libraries are truly 16 KB compatible;
- whether the correct signing/upload key is available;
- whether the app meets every Google Play policy requirement.
Fastest way to check a build
Upload the APK or AAB to the free build checker →
The Studio checker reads the release metadata without installing or running the app. The result is deliberately written for app owners first: it tells you whether the current target looks ready or needs an update, then hides the developer-level details behind a separate section.
If the checker finds a problem
Do not modify the compiled APK as the primary repair method. Work from a clean copy of the real source project. Preserve the package identity, understand the existing versioning and signing setup, then rebuild and validate the new artifact.
Last verified: 17 August 2026
Official references
Need the facts from your APK or AAB?
Use the free Studio checker to read the important release facts directly from the compiled artifact. You do not need Android Studio or Android development knowledge.
Analyze APK / AAB →