Every APK that comes out of Android Studio passes through Gradle first. There’s no way around it. Gradle is the build automation system bundled with the IDE, and it’s the thing actually compiling your source code, packaging your resources, and folding the manifest into one installable file.
That file is the Android Package, and it’s what Android actually installs, whether you’re pushing it over USB, dropping it onto an emulator, or shipping it through the Play Store. Most developers never think about this part of the process until something breaks.
Android Gradle Plugin 8.x also needs JDK 17 to run at all, a requirement Android Developers documentation confirmed after AGP 8.0 shipped in 2023. It trips up more people than you’d expect.
What Is an APK Build in Android Studio?
APK stands for Android Package Kit, though almost nobody ever says the full name out loud. What matters more is what goes into building one inside Android Studio: your Kotlin or Java source files, the resources (layouts, strings, images, the usual), and the AndroidManifest.xml file that declares permissions and the application ID. Gradle takes all three and folds them into a single installable package.
Android Studio, Google’s dedicated IDE for the platform, is what runs that process, though it’s really just handing the work to Gradle underneath.
The result is a build artifact, a packaged file the Android operating system can install and run. That’s not the same thing as publishing an app, and it’s easy to conflate the two when you’re new to this.
A finished apk build in Android Studio just sits on disk. Unsigned or debug-signed by default, waiting until someone installs it manually or a signed copy reaches a store. Every build starts from the same place regardless, the Build menu, whether you tap Run or generate the package file directly.
APK vs Android App Bundle: What Is the Difference?
Google Play stopped accepting plain universal APKs for new app submissions back in August 2021, per Android Developers documentation, so unless you’re distributing outside the Play Store, you’re probably dealing with both formats whether you like it or not.
An APK is the finished, installable file itself. An app bundle, by contrast, is more like a set of building blocks that Google Play assembles into device-specific APKs on demand, splitting out only the resources a given phone actually needs.
| Attribute | APK | Android App Bundle |
|---|---|---|
| Installable directly | Yes | No, Google Play generates APKs from it |
| File contents | Every resource for every device | Split by device configuration |
| Where it is used | Sideloading, direct sharing, third-party stores | Google Play submissions |
| Typical size impact | Larger download | Smaller, per-device download |
The size difference isn’t trivial. Top apps that switched from a universal APK to an app bundle saved an average of 15% in download size, according to Google’s Android Developers Blog, and Microsoft’s LinkedIn team reported a 23% size cut for its own Android app after making the switch, a result they presented at Google I/O 2018. Duolingo, Netflix, and Adobe are among the developers Google has pointed to as early adopters of the format.
None of that means an APK is obsolete. If you need a file to sideload, share directly, or install outside a store, that’s still an APK. Anything headed to Google Play goes through an app bundle instead. The choice of an APK or an AAB really just comes down to where the file is going, not which one is better on paper.
How Does Gradle Turn Source Code Into an APK?
Gradle handles this through a defined sequence of tasks, compiling, packaging, and signing the project, and Android Studio just triggers that sequence on command. Every one of those tasks reads its instructions from the project’s build files, never from anything you type directly into the code editor.
Gradle on its own is a general-purpose build automation tool. The Android Gradle Plugin, AGP for short, is what layers the Android-specific tasks on top of it.
Gradle Sync and the Build File
Dependencies, SDK versions, build variant rules, all of it lives in the build.gradle or build.gradle.kts file. Edit that file and you’ll be prompted to sync Gradle inside Android Studio, which re-reads the configuration and pulls down anything new it needs.
There are a few of these config files floating around a typical project, and it’s worth knowing which does what. The module-level build.gradle handles app-specific settings. The project-level build.gradle covers settings shared across modules. gradle.properties, meanwhile, controls JVM memory and build flags.
It’s worth flagging again that Android Gradle Plugin 8.x requires JDK 17 to run, according to Android Developers documentation. An older JDK doesn’t throw a helpful error either, it just stops the sync before it even gets going.
The Android Gradle Plugin’s Role
Once sync finishes, AGP works through the actual build in stages. Source code, whether it’s Kotlin or Java, gets compiled into DEX bytecode first. From there, manifests and resources from the app and its dependencies get merged together. Last, everything, the compiled code, the resources, the manifest, gets packaged into the APK container itself.
None of these steps run without a working Gradle Wrapper pinning a compatible Gradle version to the project. Miss that and the whole chain stalls before compilation even starts.
Debug and Release Build Variants
A build variant is a named configuration, and it’s what controls how Gradle assembles a particular version of the APK. Android Studio ships with two by default, debug and release, and most projects never need a third.
Debug Build Variant
A debug build stays unoptimized on purpose. It’s either unsigned or signed with a debug key Android Studio generates automatically the first time you build. That trade off buys you speed. Shrinking and obfuscation stay off, so compiling is faster, and it supports Apply Changes, which swaps code and resources without forcing a full reinstall every time you tweak something.
It installs on any device with developer options and USB debugging turned on. What it doesn’t do is get anywhere near a store. Most app stores reject a debug-signed APK outright, since it exists for iteration, not for anyone outside your own testing loop.
Release Build Variant
Release is the opposite end of things. Signed for actual distribution, and eligible for the code shrinking R8 handles (more on that below), it’s what a tester or a real user ends up installing. Debug relies on that throwaway key mentioned above and skips shrinking entirely, so the two builds can end up wildly different sizes even from identical source code.
Switching between them is just a dropdown in the Build Variants panel, no code changes required. Debug is for iterating on your own machine. Release is for everything that leaves it.
Which Minimum and Target SDK Version Should You Set?
Google Play has required new apps and updates to target Android 16 (API level 36) since August 31, 2026. Existing apps need to target at least Android 15 (API level 35) just to stay visible to new users, according to Android Developers documentation. Miss that window and your app effectively disappears from search for anyone who isn’t already using it.
minSdk and targetSdk get confused constantly, and it’s an easy mistake to make early on. minSdk sets the oldest Android version the APK is allowed to install on. Anything older simply won’t run it. targetSdk is different. It’s the API level the app is actually built and tested against, and that’s what determines which platform behaviors kick in at runtime. There’s a third value too, compileSdkVersion, which sets what the code compiles against and usually just tracks targetSdk closely.
Setting minSdk low widens the pool of devices that can install your app. But it comes at a cost, you end up giving up newer APIs unless you’re checking the version at runtime before using them, which adds its own maintenance headache. Each API level ships through the Android SDK tools inside Android Studio’s SDK Manager, so raising targetSdk usually starts there, installing the matching platform before anything else.
App Signing: Keystore, Key Alias and Play App Signing
Every installable Android package carries a digital signature. Android Studio simply won’t let a release build skip this step. That signature is what proves updates to an app are coming from the same source as the original install, and without it, there’s no way to tell a legitimate update from a hijacked one.
Creating a Local Keystore
A keystore is just a file holding one or more signing keys, each identified by a key alias. You generate it once, either through the Generate Signed Bundle / APK dialog or the keytool command, and it’s protected by a keystore password plus a separate key password. From that point on, the same file gets reused for every future release of the app.
Lose the file, or forget either password, and you’ve lost the ability to publish updates under that signature. Permanently. There’s no recovery path, which is why a lot of teams end up storing keystores in a password manager or a locked-down vault rather than on one developer’s laptop.
Enrolling in Play App Signing
Google Play requires this setup for any app bound by the app bundle rule covered earlier (apps already live before that rule took effect are exempt). Instead of you holding the actual signing key, Play App Signing lets Google Play hold and manage it on your behalf. You’re still responsible for the upload key, the one used to sign the bundle before it ever reaches Play Console, but if that gets lost, Play Console support can actually recover it. A lost local keystore never gives you that option.
Keeping your own keystore means full control, no dependency on Google’s systems, and it’s the only path if you’re distributing outside Google Play at all. The catch is that losing the file or its passwords blocks future updates under that signature for good. Handing signing over to Google removes that particular risk since a lost upload key is recoverable, though it does tie your updates to a Google Play account and whatever enrollment settings come with it. Which option makes more sense really depends on how much you trust your own key management versus Google’s account recovery process.
Code Shrinking and APK Size With R8
R8 is the default code shrinker built into the Android Gradle Plugin, and once a release build turns it on, it runs automatically, no extra configuration needed beyond that flag.
The numbers behind it are hard to argue with. Google’s own case study on the Google I/O conference app found it dropped from 18.55 MB to 6.45 MB after R8 shrinking, a 65% reduction in dex size, according to the Android Developers team on Medium. Method count fell from 150,220 to 45,831 in that same example, and the number of dex files went from three down to one.
What actually gets you there is a handful of things happening at once. Code and library classes the app never calls get stripped out entirely, that’s tree shaking. Methods get inlined and classes merged to cut overhead, which is the optimization pass. Then classes and methods get renamed to short, meaningless labels, a form of code obfuscation that makes reverse-engineering the compiled code a lot harder. If you enable it alongside R8, resource shrinking strips out unused drawables, layouts, and strings too.
None of this runs by default. You turn it on by setting minifyEnabled true and shrinkResources true in the release build type. Debug builds almost always skip it entirely, since the size savings matter a lot less than getting fast, repeated builds while you’re still testing.
Steps to Build a Debug APK
Building a debug APK takes one menu path and zero signing configuration, Android Studio handles the debug signature on its own, generating a key automatically the first time you build.
- Open the project you want to build in Android Studio.
- Select Build in the top menu, then Build Bundle(s) / APK(s).
- Choose Build APK(s) from that submenu.
- Wait for the notification confirming the build finished.
- Click Locate in that notification to open the file’s folder.
By default, the file lands at app/build/outputs/apk/debug/app-debug.apk, named after the module and the debug build variant. If you’d rather skip straight to testing, hitting the green Run arrow does the same compile-and-package work and installs the result directly on a connected device or emulator in one step.
Steps to Generate a Signed Release APK
A signed release APK needs a keystore ready before the build even starts (the signing section above covers setting that up).
- Select Build in the top menu, then Generate Signed Bundle / APK.
- Choose APK, not Android App Bundle, in the dialog that opens.
- Select an existing keystore or create a new one, then enter its passwords and key alias.
- Pick the release build variant and the destination folder for the output.
- Click Create, then wait for the build to finish.
The signed file saves to whatever folder you chose in step 4, typically nested under app/release. Android Studio remembers the keystore path for the project after that, so future release builds skip straight to entering the password, no need to browse for the file again.
There’s also a hard limit worth knowing about. A base APK past 200 MB can’t publish on Google Play at all without Play Asset Delivery or Play Feature Delivery splitting off the extra weight, according to Android Developers documentation.
How Do You Install and Test the Built APK?
An APK installs the same way regardless of where it came from, whether Android Studio just built it or someone emailed you the file five minutes ago. Most testing happens on an emulator running locally or on a physical device connected by cable, those are really the only two options that matter.
Installing on an Emulator
Clicking Run in Android Studio builds the APK and installs it straight onto whichever virtual device is selected in the toolbar, no cable, no developer options required. You can keep multiple emulator profiles installed at once too, covering different screen sizes and API levels, which is handy if you’re testing across a spread of devices. Drag-and-drop works as well, just pull an APK file onto a running emulator window and it installs directly.
The one downside is startup time. First launch takes noticeably longer than a physical device, since the virtual machine has to fully boot before installation can even begin.
Installing on a Physical Device
Developer options and USB debugging have to be turned on first, otherwise a phone or tablet just won’t show up as a target at all. Connecting a phone to Android Studio with USB covers that setup in detail, from enabling the option to authorizing the connection on the device itself. Once that’s sorted, the device shows up in Android Studio’s device dropdown the same way an emulator would.
If you already have an APK file and don’t want to open the project in Android Studio at all, a single ADB command handles it, one of the entries in the ADB commands cheat sheet:
- adb install path/to/app-debug.apk
If the device rejects the install with a signature mismatch, that almost always means an older version signed with a different key is already sitting on it.
Common APK Build Failures and Fixes
When a build fails, it’s usually memory, a dependency conflict, a manifest clash, or just a stale cache messing things up. The table below covers the specifics.
| Error | Typical Cause | Fix |
|---|---|---|
| Gradle sync failed | Incompatible library or plugin version | Check dependency versions against the AGP compatibility table |
| OutOfMemoryError during build | Default Gradle JVM heap too small | Raise org.gradle.jvmargs in gradle.properties |
| Manifest merger failed | Conflicting attribute values across manifests | Add a tools:replace override in the app’s manifest |
| Stale or corrupted build state | Cached Gradle outputs out of sync with source | Run a clean build, then rebuild the project |
On the memory front, Android’s own documentation flags garbage collection eating more than 15% of total build time as the signal that your JVM heap is too small. That’s usually the first thing worth checking if builds have gotten sluggish for no obvious reason.
Manifest conflicts come from a different place entirely. The manifest merger tool combines every AndroidManifest.xml in a project, the main source set, build variants, every imported library, into a single file, and when something clashes there, Android Developers documentation confirms it surfaces as a merging error with a suggested fix, usually a tools:replace attribute.
And when none of that explains it? Invalidating caches and restarting Android Studio clears state that a plain rebuild sometimes just doesn’t touch.
When the APK Build Process Does Not Apply
Everything above assumes a standard Android Studio project, Gradle driving the whole pipeline with nothing else layered in. That’s true for most apps, but not all of them.
- Games and performance-heavy apps using the NDK
- Headless CI pipelines running gradlew directly
- Kotlin Multiplatform projects sharing logic with iOS
Once C or C++ source enters the picture through the Android NDK, Gradle still drives the build overall, but CMake or ndk-build compiles the native libraries separately before anything gets packaged, a step that nothing covered above actually touches.
Command-line and CI builds work a little differently too, though the output is identical. A server running ./gradlew assembleRelease produces the exact same APK, just without Android Studio’s interface anywhere in the process. It’s really the Gradle Wrapper, not the IDE, that matters for reproducing a build outside a developer’s own machine.
Kotlin Multiplatform projects add another wrinkle. When Android and iOS share a business logic module through Kotlin Multiplatform, the Android target still compiles through Gradle same as always, but the shared module’s own build configuration lives outside the app module described in the steps above. Teams that have made this switch report real gains, 55% saw improved collaboration and 65% saw improved performance and quality after adopting Kotlin Multiplatform, according to JetBrains’ 2024 survey. Cash App and Forbes are among the companies JetBrains lists as production users of the approach.
The app bundle requirement covered earlier applies here too. The APK produced by the steps above isn’t actually what reaches most Play Store users, it’s what a developer tests with directly, nothing more.
And then there’s a separate category altogether, on-device, no-code app builders. Some Android tools assemble an APK from templates directly on a phone, no Gradle, no Android Studio, no traditional codebase involved at any point.
FAQ on How To Build Apk In Android Studio
Can You Build an APK Without Android Studio, From the Command Line?
The Gradle Wrapper included in every project handles this, running the exact same tasks from a terminal with ./gradlew assembleDebug or assembleRelease. Android Studio only provides the interface, not the actual build logic, which is why continuous integration servers rely on this command-line path routinely.
Do You Need a Google Play Developer Account Before Building an APK?
No. Building and testing an APK needs nothing beyond Android Studio and a project. A developer account only comes into play later, at the publishing step, once a signed release build actually reaches Google Play Console.
What JDK Version Does Android Studio Require to Run a Build?
Android Gradle Plugin 8.x requires JDK 17 to execute Gradle tasks. Most developers never touch this setting directly since Android Studio bundles a compatible JDK by default, it only becomes relevant once you’re running Gradle outside the IDE.
How Long Does an APK Build Normally Take?
It varies quite a bit, project size, module count, and whether the build is clean or incremental all factor in. A small single-module app can finish in seconds. A large multi-module project with native code takes noticeably longer, sometimes minutes.
Is It Safe to Share an APK File Outside Google Play?
A signed APK installs fine outside the Play Store, technically. But Android blocks installation from unknown sources by default, so recipients have to enable that setting manually first. And sideloaded files skip Google Play Protect’s automatic scanning entirely.
What Is Zipalign, and Do You Need to Run It Manually?
Zipalign aligns uncompressed data inside an APK on four-byte boundaries, which lets the system map resources into memory more efficiently. It used to be a manual step. These days Android Studio’s build and signing tools run it automatically, so you’d rarely need to touch it yourself.
Can the Built APK Be Inspected Without Installing It?
Android Studio’s APK Analyzer opens any APK file directly, no installation on a device or emulator needed first. It shows the manifest, resources, a DEX file breakdown, and method count, which is useful for tracking down what’s bloating a build.
Why Does Google Play Now Require an App Bundle for New Apps Instead of an APK?
Because it lets Google Play generate optimized, per-device APKs instead of shipping one universal file to everyone. That approach cuts download size and supports on-demand feature delivery, two benefits a single static APK just can’t offer.
What Should You Verify First in How to Build Apk in Android Studio?
Check things in order and you’ll save yourself a rebuild. Signing configuration comes first, since an unsigned file simply won’t install no matter what else is right. Target SDK version comes next, because Google Play rejects an outdated value outright regardless of how well the app itself works. R8 shrinking settings come last, since optimizing a build that’s already doomed to fail one of the first two checks just wastes the run.
There’s a real trade off in following that order. Catching a signing mistake early costs you almost nothing. But a rejected target SDK discovered only after the build finishes forces a fresh release build from that change forward. Android Studio doesn’t patch a signed file in place, so there’s no shortcut around redoing it.
Once a build clears all three checks, the next step is Google Play submission. Publishing an app on Google Play covers the account, listing, and review requirements a finished build still has to meet before it actually reaches anyone.
- MySQL Cheat Sheet - September 30, 2026
- How to Remove Duplicate Lines in Notepad++ (Sorted or Unsorted) - September 29, 2026
- Should Your Engineering Team Still Own the Marketing Website? - September 29, 2026
