Developing a mobile product is only half the journey that the creator has to go through. The final and critical step before publishing on Google Play is the cryptographic signature procedure. Without a valid digital certificate, the operating system Android will simply refuse to install your software product on the user's device, and the application store will not allow it for moderation.
This process may seem confusing to beginners due to the abundance of terminology: keystore, alias, v1/v2 signing. However, if you break it down, it becomes clear that this is a standard procedure for protecting copyright and code integrity. In this article we will look in detail at how to correctly generate a key, set up a project and release a finished build.
It is worth noting that signing is necessary not only for the release version, but is also often required for debugging on real devices if strict security policies are enabled. Let's move from theory to practice and look at two main ways to accomplish this task.
Why do you need to sign applications at all?
A digital signature is a guarantor of software authenticity. When you upload a file to the store, the system checks the certificate to ensure that the update was actually issued by you and not by an attacker. This protects users from code substitution and the introduction of malicious modules into popular apps.
In addition, the signature mechanism allows the system to update applications without losing user data. If the new package is signed with the same key as the previous one, Android perceives this as a legitimate update. Otherwise, you will need to completely remove the old version, which leads to the loss of settings and progress.
⚠️ Attention: Losing the keystore file means that you will not be able to release updates for your application. It is technically impossible to recover the key, so store backup copies in a secure location, such as an encrypted cloud or physical storage.
Google Play requires the use of modern signature schemes to ensure maximum security. Older methods often contain vulnerabilities that can be used to modify the APK file after it has been created. Therefore, it is important to understand the difference between protocol versions.
Generating a signing key through the IDE interface
The most obvious way to create a new key is to use the built-in wizard in the development environment. This method is ideal for those who prefer a graphical interface and don't want to bother with console commands initially. The process begins by selecting the appropriate item in the menu.
In the top menu, select Build, then go to the section Generate Signed Bundle / APK. A window will open where you need to select the output file format. To publish in a modern store, it is better to immediately select Android App Bundleas this allows Google Play to optimize the download size for each specific device.
After clicking the button Next the system will offer to create a new keystore if you do not already have one. You will need to fill in several required fields:
- 🔑 Key store path: path to the file where the key will be saved (usually with a .jks extension).
- 🔒 Password: password for access to the storage itself.
- 👤 Alias: alias for the key inside the storage.
- 📅 Validity: key validity period (it is recommended to set it to 25 years or more).
Filling out the certificate data (name, organization, city) is a formality, but some fields are required for filling. After entering all the data, click OK, and the wizard will create the file. Don't forget to remember your passwords, as they will be needed every time you automatically build a release version.
Use a password manager to save data from the .keystore file. A forgotten storage password will render the file useless, and you will have to generate a new key, which will require creating a new package in the Google Play Console.
Setting up automatic signing in Gradle
Manually entering passwords with each build quickly gets boring and increases the risk of errors. It is much more efficient to configure automatic signature through the configuration file build.gradle. This is an industry standard that allows you to build release versions with one team or through continuous integration systems.
First, create a file keystore.properties at the root of your project. It stores sensitive data, so this file must be added to .gitignorein order not to end up in a public repository. Example of file contents:
storePassword=your_storage_passwordkeyPassword=your_key_password
keyAlias=your_alias
storeFile=path/to/file.keystore
Next you need to edit the module level file (usually this is build.gradle module level (usually this app/build.gradle). In the block android a section is added signingConfigsthat reads data from the previously created property. This allows you to bind the build configuration release to your key.
| Parameter | Description | Data source |
|---|---|---|
storeFile |
Path to the key file | keystore.properties |
storePassword |
Password for access to the storage | keystore.properties |
keyAlias |
Name of the key inside the storage | keystore.properties |
keyPassword |
Password for a specific key | keystore.properties |
After setting, do not forget to add a block signingConfig signingConfigs.release inside the block buildTypes for the type assembly release. Now, when executing the build command, the project will automatically sign the artifact with the required certificate.
☑️ Checking the Gradle configuration
Differences in signature schemes V1, V2, V3 and V4
In the signature wizard settings you will see checkboxes for selecting versions signature schemes. Understanding their differences is important for your application's compatibility with different operating system versions. Old devices may not support new protocols, but new ones may require them.
The scheme V1 (Jar Signature) signs each file inside the APK separately. This is the only method supported by devices running Android 6.0 and below. However, it has a drawback: if you change even one byte in the file after the signature, the signature will become invalid, but the system may not notice this during installation.
The V2 (Full APK Signature)scheme introduced in Android 7.0 signs the entire archive. This ensures the highest integrity: any change to the file will result in an installation failure. For modern projects, using V2 is mandatory, since Google Play requires it for all new applications.
⚠️ Attention: Starting with Android 11 (API level 30), when targeting this version and higher, using the V2 signature scheme is mandatory. Ignoring this requirement will result in refusal to install the application on modern smartphones.
Schemes V3 and V4 add key rotation capabilities and optimization for streaming installations, respectively. It is recommended to always select the V2 and V3 checkboxes at the same time to ensure maximum compatibility and security without extra effort.
What is key rotation in the V3 scheme?
The V3 signing scheme allows you to change the application signing key during its lifecycle. This is useful if you think that an old key may have been compromised, but want to retain the ability to update the application without creating a new package in the store.
Signing via the command line (Terminal)
Sometimes the graphical interface can fail, or you need to sign the application on a server without a graphical shell. In such cases, the utility jarsigner or a more modern one apksignerthat is included in Android SDK Build-tools.
comes to the rescue. To work with apksigner you need to add the path to the tools to the PATH environment variable or specify the full path. The process consists of two stages: first resource leveling (zipalign), then the signature itself. Alignment is critical to the performance of the application.
The command for signing is as follows:
apksigner sign --ks path_to_key.jks --out application-signed.apk application.apkAfter executing the command, the system will ask for passwords. Make sure that you use it apksignerand not the old jarsigneras the latter does not support V2 and higher schemes, which will lead to installation problems on modern devices.
Using apksigner is preferable to jarsigner, since it supports all modern signature schemes (V2-V4) and automatically verifies the validity signed file before shutting down.
Common errors and ways to solve them
Even experienced developers encounter problems with signing. One of the most common mistakes is INSTALL_PARSE_FAILED_NO_CERTIFICATES. It occurs when the application is built in debug mode, but the device or emulator requires a release signature, or when the signature file is damaged.
Another common problem is conflicting signature scheme versions. If you try to install an APK signed only under the V1 scheme on Android 12, the system may throw an error. Always check that the required protocol versions are activated in the build settings.
You should also pay attention to the message Signature verification failed. This may mean that the file was modified after signing (for example, by a virus or an incorrect archiver). In this case, you need to rebuild the project from scratch.
⚠️ Attention: Android Studio interfaces and versions of the Build Tools are updated regularly. Menu item names or options in gradle may change slightly. Always check the official Google documentation if the standard instructions do not work in your version of the IDE.
Questions and answers (FAQ)
Is it possible to use the same key for different applications?
Technically this is possible, and some developers do this to simplify management. However, from a security point of view this is not recommended. If the key of one application is compromised, an attacker will be able to sign a malicious update for all your projects in the store.
What should I do if I lost the keystore file?
Unfortunately, it is impossible to recover the key due to the nature of cryptography. You will have to create a new key, register the application in the Google Play Console as new (with a new package name) and ask users to delete the old version and install the new one.
Is it necessary to sign the application for testing on the emulator?
By default, Android Studio signs debug versions (debug build) automatically with a temporary key. This is enough for the emulator. Manual signing is only required for release builds (release build) or if you have changed the project security settings.
What is the difference between APK and AAB when signing?
The signing process is identical for both formats. The difference lies in the file structure: AAB (Android App Bundle) is a container from which Google Play generates optimized APKs for specific devices. You need to sign the AAB file itself before loading it into the console.
How long is a signing certificate valid?
When creating a key, you specify the validity period in days. It is recommended to set the maximum value (for example, 25 years or 9000+ days) since the application may be supported for decades. An expired certificate will not allow you to issue an update.