How to Fix “Keystore was tampered with, or password was incorrect” in Android Studio

java.io.IOException: Keystore was tampered with, or password was incorrect

What Does “Keystore was tampered with, or password was incorrect” Mean?

A Java keystore stores cryptographic keys and certificates used to sign an Android application.

A typical Android release signing configuration uses:

• A keystore file
• A keystore password
• A key alias
• A key password

Android Gradle Plugin exposes these as separate properties. :contentReference[oaicite:14]{index=14}

storeFile storePassword keyAlias keyPassword

If Java cannot validate or open the keystore using the supplied store password, it can report:

Keystore was tampered with, or password was incorrect

Common Situations

The error often appears when:

• Generating a signed APK or App Bundle
• Running a release build
• Moving a project to another computer
• Restoring a keystore from backup
• Changing keystore.properties
• Editing Gradle signing configuration
• Managing multiple application keystores
• Using different store and key passwords
• Mixing JKS and PKCS12 keystores

Common Causes

1. The Keystore Password Is Wrong

This is the most common cause.

storePassword is the password used to open the keystore itself.

It is conceptually separate from the password for the private key associated with a key alias.

2. Store Password and Key Password Are Being Confused

Android signing configuration contains separate:

storePassword keyPassword

Android Gradle Plugin documents these as separate properties. :contentReference[oaicite:15]{index=15}

For newly created Android Studio keystores, Google’s current signing instructions tell you to make the key password the same as the keystore password. :contentReference[oaicite:16]{index=16}

Older keystores, however, may still use different passwords.

3. The Wrong Keystore File Is Selected

If several applications have files named release.jks or keystore.jks, it is easy to combine one application’s keystore with another application’s password.

4. The Keystore Path Is Wrong

The storeFile setting may point to a different file than you expect.

Google’s command-line build documentation requires the signing configuration to reference the correct keystore file. :contentReference[oaicite:17]{index=17}

5. keystore.properties or Environment Variables Are Wrong

If local builds work but CI builds fail, the CI secret or property value may be different.

6. Extra Whitespace Is Present in the Password

A copied password can accidentally include a trailing space or newline.

7. The Keystore Type Is Not What You Expect

Java supports multiple keystore formats, including JKS and PKCS12.

Android Gradle Plugin also provides a storeType property. :contentReference[oaicite:18]{index=18}

8. The Keystore File Is Damaged

A failed copy, storage problem, incorrect file transformation, or cloud-sync conflict can damage the file.

9. A Different JDK Is Being Used

On systems with multiple JDK installations, terminal keytool and Android Studio may use different Java runtimes.

Step 1: Open the Keystore Directly with keytool

Test the keystore independently of Android Studio:

keytool -list -v -keystore release.jks

Enter the keystore password when prompted.

If the password is correct, keytool should display aliases and certificate information.

If the same error appears, the problem is likely the keystore file, store password, or keystore format rather than Android Studio.

Step 2: Avoid Putting the Password Directly on the Command Line

The safer normal form is:

keytool -list -keystore release.jks

You can technically specify:

keytool -list -keystore release.jks -storepass YOUR_PASSWORD

but command-line passwords can remain in shell history or other process information.

Solution 1: Verify the Keystore Password

Make sure that the value being entered is the keystore password, not the key password.

Android Studio’s signed-build dialog presents separate fields for:

Key store password Key alias Key password

Solution 2: Test Candidate Passwords with keytool

For each possible store password, run:

keytool -list -keystore release.jks

If the alias list appears, you have confirmed the correct store password.

Solution 3: Verify the Keystore File Used by Gradle

Kotlin DSL example:

android { signingConfigs { create("release") { storeFile = file("release.jks") storePassword = "..." keyAlias = "release" keyPassword = "..." } } }

Groovy example:

android { signingConfigs { release { storeFile file("release.jks") storePassword "..." keyAlias "release" keyPassword "..." } } }

Google’s Android build documentation shows these same core signing values in release signing configuration. :contentReference[oaicite:19]{index=19}

Solution 4: Test Using an Absolute Path

To rule out accidentally opening a different file, use an absolute path.

macOS or Linux:

keytool -list -keystore /Users/user/keys/release.jks

Windows:

keytool -list -keystore "C:\Users\User\keys\release.jks"

Solution 5: Verify the Key Alias

Once the keystore opens successfully, list its contents:

keytool -list -v -keystore release.jks

If the output contains:

Alias name: release

then Gradle should use:

keyAlias = "release"

Solution 6: Keep storePassword and keyPassword Correct

An older keystore might have been created with:

Keystore password: StorePass123 Key password: KeyPass456

The Gradle configuration would therefore need:

storePassword = "StorePass123" keyPassword = "KeyPass456"

Android Gradle Plugin defines both independently. :contentReference[oaicite:20]{index=20}

Solution 7: Check keystore.properties

For example:

storeFile=/Users/user/keys/release.jks storePassword=StorePass123 keyAlias=release keyPassword=KeyPass456

Check for:

• Values copied from another application
• Trailing whitespace
• An incorrect keystore path
• An incorrect alias

Solution 8: Check Environment Variables

macOS or Linux:

printenv KEYSTORE_PATH printenv KEY_ALIAS

Windows PowerShell:

$env:KEYSTORE_PATH $env:KEY_ALIAS

Avoid printing secret password values into CI logs.

Solution 9: Test the Keystore as JKS

If you know the file is JKS:

keytool -list -keystore release.jks -storetype JKS

If this works, you have confirmed the format.

Solution 10: Test the Keystore as PKCS12

For a PKCS12 file:

keytool -list -keystore release.p12 -storetype PKCS12

Android Gradle Plugin supports a signing storeType setting. :contentReference[oaicite:21]{index=21}

Solution 11: Specify storeType in Gradle

JKS example:

signingConfigs { create("release") { storeFile = file("release.jks") storePassword = "..." keyAlias = "release" keyPassword = "..." storeType = "JKS" } }

For PKCS12:

storeType = "PKCS12"

Solution 12: Check the JDK and keytool Being Used

Run:

java -version keytool -J-version

Then determine which keytool executable is active.

macOS or Linux:

which keytool

Windows:

where keytool

If multiple JDKs are installed, verify that you are not testing the keystore with an unexpected Java installation.

Solution 13: Check Android Studio’s Gradle JDK

Open:

Settings → Build, Execution, Deployment → Build Tools → Gradle → Gradle JDK

Use the JDK intended for the project.

Solution 14: Check the Keystore File Size

macOS or Linux:

ls -lh release.jks

Windows PowerShell:

Get-Item .\release.jks | Select-Object Name, Length

If the file is zero bytes or differs dramatically from a known backup, suspect corruption.

Solution 15: Test a Backup Keystore

Do not overwrite the current file.

Copy the backup to another location and test:

keytool -list -keystore backup-release.jks

If the backup opens and the current file does not, the current file may be damaged.

Solution 16: Re-enter the Signing Information in Android Studio

Open:

Build → Generate Signed App Bundle or APK

Re-enter:

• Key store path
• Key store password
• Key alias
• Key password

Google’s current Android Studio signing instructions use these values when generating signed APKs and App Bundles. :contentReference[oaicite:22]{index=22}

Solution 17: Should You Create a New Keystore?

For an application that has never been published, creating a new keystore may be possible.

For an already published application, do not replace the signing keystore casually.

The correct key depends on the application’s existing signing and Google Play App Signing configuration.

Solution 18: Change the Keystore Password

If you know the current store password, run:

keytool -storepasswd -keystore release.jks

You will be asked for the existing password and the new password.

This cannot reset a password that you no longer know.

Can a Forgotten Keystore Password Be Recovered?

There is no normal keystore command that simply displays a forgotten password.

Check:

• Your password manager
• An older development computer
• CI/CD secrets
• Securely stored property files
• Your team’s secret-management system
• Backups

For a published app, Google Play App Signing may provide different recovery options depending on whether the lost credential is an upload key or the app signing key.

Difference Between This Error and “Cannot recover key”

This error:

Keystore was tampered with, or password was incorrect

often occurs when the keystore itself cannot be opened.

Errors such as:

Cannot recover key UnrecoverableKeyException

can occur after the keystore has been opened but the private key cannot be recovered with the supplied key password.

A useful mental model is:

storePassword → opens the keystore keyPassword → unlocks the private key for the alias

Difference from “Failed to read key from store”

If you see:

Failed to read key from store

the keystore may already be accessible, while the alias, key password, or private-key entry is wrong.

For “Keystore was tampered with, or password was incorrect,” prioritize the keystore file and store password first.

Should Passwords Be Stored Directly in Gradle?

It is technically possible, and Google’s command-line build documentation uses direct values in examples for clarity. :contentReference[oaicite:23]{index=23}

In a real project, signing passwords should be treated as secrets.

Fastest Diagnostic Order

1. Verify the exact keystore file being used.
2. Run keytool -list -keystore release.jks.
3. Confirm that the store password opens the keystore.
4. Check the alias.
5. Verify Gradle’s storePassword and keyPassword.
6. Verify the storeFile path.
7. Test JKS or PKCS12 explicitly if necessary.
8. Compare with a backup keystore.

If the Problem Still Occurs

Verify the following:

• The keystore password is correct.
• You are not confusing it with the key password.
• The correct keystore file is selected.
• You are not using another file with the same name.
• The storeFile path is correct.
• keystore.properties contains the correct values.
• Environment variables do not contain stale values.
• The password does not contain accidental whitespace.
• The key alias is correct.
• You tested JKS and PKCS12 appropriately.
• You checked the active JDK and keytool.
• The keystore file is not zero bytes or damaged.
• You tested a known backup.

Summary

The Android Studio “Keystore was tampered with, or password was incorrect” error usually means that the selected keystore cannot be opened with the supplied store password, the wrong keystore was selected, or the keystore cannot be read correctly.

The best first test is to use keytool directly:

keytool -list -v -keystore release.jks

If the correct password displays the aliases, the keystore and store password are valid.

Then verify:

storeFile storePassword keyAlias keyPassword storeType

Android Gradle Plugin defines these as separate signing configuration properties. :contentReference[oaicite:24]{index=24}

Google’s current Android Studio instructions for creating a new keystore also instruct developers to use the same password for the key and keystore. :contentReference[oaicite:25]{index=25}

Older keystores can still use different passwords, so do not change configuration based on assumptions. Verify the existing keystore with keytool.

Finally, treat the signing keystore of a published app as a critical asset. Do not delete, overwrite, or replace the original file while troubleshooting; work from copies and backups instead.