Use the current build interface
The Unity 6.0 Android build manual, reviewed on 29 September 2026, uses File → Build Profiles. Select or add an Android profile and switch to it. Other Unity versions may show different menus; use the manual matching your installed editor. Install Android support through Unity Hub when the platform is unavailable.
Install Android support through Unity Hub when the platform is unavailable.
Choose output and runtime settings
| Setting | Decision |
|---|---|
| APK vs app bundle | Direct installation or store distribution |
| Scripting backend | Supported Mono/IL2CPP choice for the project |
| Target architectures | Devices and store requirements |
| Development Build | Diagnostics versus intended public release |
| Package/version | Stable identity and valid update sequence |
The IL2CPP guide explains the ahead-of-time backend. Do not change backend merely to bypass an unrelated signing error.
Configure signing deliberately
Use Android signing guidance and Unity's publishing settings. Keep keystores and passwords outside public source and do not upload private keys to analysis tools.
A debug-signed build can be useful for development but is not the intended public release identity.
Test on the selected architecture
Install the APK on representative devices and exercise startup, native plugins, rendering and saved-state behavior. A build that works on one ARM64 phone does not establish that every selected ABI includes compatible plugins.
For Play distribution, build and test the required app-bundle path separately.
Archive reproducible inputs
Keep editor version, packages, player settings, source revision, artifact hash and symbols. APKLint's Unity APK Analyzer can help identify package structure and native libraries, but it cannot run scenes or certify game performance. The release record should include actual device tests and the exact build profile used.
Build a standalone level with a native plugin
Consider a game whose first scene works in the editor but whose Android release must also initialize a controller plugin. Start with an Android build profile in the installed editor and include the intended scenes. In the Unity 6.0 build workflow, Android support must be installed and the selected platform must be active. Record that editor version with the profile; menu names and supported settings can differ across engine releases.
Choose APK for this direct-install test. Leave development-only diagnostics enabled only when the candidate is explicitly for internal debugging. Confirm the package identifier, incremented version code and signing choice before producing a file. These settings determine which installed app the APK can update, independently of whether its scenes compile successfully.
Check the plugin against every selected architecture
Suppose the game targets two ABIs but the controller vendor supplies only one compatible native library. Selecting both architectures does not create the missing plugin binary. Inspect the plugin import settings and packaged libraries, then obtain a supported vendor build or adjust the product's supported-device scope deliberately. Do not copy the same binary under a second ABI directory: the directory name does not change machine code.
After installing the APK, launch it from the device without relying on an editor connection. Open the first scene, navigate to another included scene and exercise controller connection and disconnection. Check a cold launch after force-stopping the app, then resume a saved session. These observations cover different packaging and lifecycle boundaries that a successful build log cannot establish.
If the game uses IL2CPP, retain the matching release symbols before the build workspace is cleaned. If it relies on downloaded content, test its documented offline behavior and distinguish that content from assets included in the APK. Keep failures tied to the exact output digest so a later successful rebuild does not replace evidence about the original candidate.
Finally, produce an AAB separately when that is the intended store output, and test its distribution path. The directly installed APK establishes a useful device result, but split delivery and store signing can introduce additional conditions. A reviewable build record identifies the editor, profile, scenes, backend, architectures, signing certificate, artifact and actual device observations together.
Sources and further reading
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
