How to Fix “Failed to read key from store” in Android Studio

Failed to read key from store

Failed to read key release from store "release.jks"

What Does “Failed to read key from store” Mean?

An Android Release build must retrieve a private signing key from a keystore.

A typical signing configuration contains:

storeFile storePassword keyAlias keyPassword

storePassword opens the keystore itself.

keyAlias identifies the specific entry to use, while keyPassword protects the private key associated with that entry.

Google’s Android build documentation uses these separate values when configuring Release signing. :contentReference[oaicite:13]{index=13}

Common Situations

• Generating a signed APK or App Bundle
• Running a Release build
• Moving the project to another computer
• Restoring a keystore from backup
• Editing build.gradle or build.gradle.kts
• Editing keystore.properties
• Changing a key alias
• Changing the keystore or key password
• Changing JDK versions
• Migrating between JKS and PKCS12

Common Causes

1. The Key Alias Is Wrong

This is one of the most common causes.

If the real alias is:

release

but Gradle contains:

keyAlias = "my-release"

the required private key cannot be selected.

2. The Key Password Is Wrong

The keystore may open successfully with the correct storePassword, while the private key still cannot be recovered because keyPassword is incorrect.

Oracle’s keytool documentation states that if no key password is supplied, it first tries the keystore password to recover the private or secret key. If that attempt fails, it prompts for the key’s password. :contentReference[oaicite:14]{index=14}

3. Store Password and Key Password Are Being Confused

storePassword → opens the keystore keyPassword → unlocks the private key

The two passwords may be identical, but older keystores can use different values.

4. The Wrong Keystore File Is Being Used

Developers often have several similarly named files:

release.jks keystore.jks upload.jks

Using one application’s passwords with another application’s keystore will fail.

5. The Alias Is Not a Private-Key Entry

A keystore can contain private keys as well as trusted certificate entries.

Android application signing requires a usable private-key entry.

6. The Keystore Type Is Different Than Expected

Common keystore types include JKS and PKCS12.

Explicitly testing the format can help when moving older projects between Java environments.

7. The Keystore Is Damaged

A failed file copy, cloud-sync conflict, or storage problem can corrupt a keystore.

8. keystore.properties Contains Incorrect Values

If Gradle loads signing values from a separate property file, the stored alias or password may be stale.

9. CI/CD Secrets Are Outdated

If local builds work but CI builds fail, the remote secrets may contain an old key alias or password.

10. A Different JDK or keytool Is Being Used

Systems with multiple JDK installations can use different Java environments in Android Studio and the terminal.

Step 1: Inspect the Keystore with keytool

Start by testing the keystore independently from Gradle:

keytool -list -v -keystore release.jks

Enter the keystore password when prompted.

Oracle documents -list as the command for displaying entries stored in a keystore. :contentReference[oaicite:15]{index=15}

A valid keystore should display alias information such as:

Alias name: release

Step 2: Compare the Alias with Gradle

You can also run:

keytool -list -keystore release.jks

Compare the returned alias exactly with the value assigned to keyAlias.

Solution 1: Configure the Correct Key Alias

If keytool reports:

Alias name: upload

use:

keyAlias = "upload"

Kotlin DSL example:

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

Solution 2: Verify the Key Password

If the store password opens the keystore but signing still fails, verify the private-key password.

Oracle documents that keytool first tries the keystore password when a separate key password is not supplied and asks for another password if recovery fails. :contentReference[oaicite:16]{index=16}

An older keystore can therefore have:

Keystore password: StorePass123 Key password: KeyPass456

Solution 3: Make Sure the Passwords Were Not Swapped

An incorrect configuration can look like:

storePassword = "KEY_PASSWORD" keyPassword = "STORE_PASSWORD"

Use the correct original values:

storePassword = "STORE_PASSWORD" keyPassword = "KEY_PASSWORD"

Solution 4: Verify the Exact Keystore File

Use an absolute path to remove ambiguity.

Windows:

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

macOS or Linux:

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

Confirm that the expected alias appears.

Solution 5: Check Gradle storeFile

Kotlin DSL:

storeFile = file("release.jks")

Groovy:

storeFile file("release.jks")

Google’s Android signing documentation configures storeFile, storePassword, keyAlias, and keyPassword separately. :contentReference[oaicite:17]{index=17}

Solution 6: Check keystore.properties

For example:

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

Check:

• The file path
• The store password
• The key alias
• The key password
• Trailing spaces
• Unexpected line breaks

Solution 7: Check Alias Spelling Carefully

For example:

Actual alias: release-key

Configured alias:
release_key

These are different values.

Copy the alias exactly as displayed by keytool.

Solution 8: Confirm the Alias Contains a Private Key

Run:

keytool -list -v -keystore release.jks -alias release

The entry used to sign an Android application must contain a private key.

A trusted certificate entry alone cannot sign an APK or App Bundle.

Solution 9: Test the Keystore as JKS

keytool -list -v -keystore release.jks -storetype JKS

Solution 10: Test the Keystore as PKCS12

keytool -list -v -keystore release.p12 -storetype PKCS12

Oracle’s keytool supports the -storetype option for selecting the keystore type. :contentReference[oaicite:18]{index=18}

Solution 11: Specify storeType in Gradle

JKS example:

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

For PKCS12:

storeType = "PKCS12"

Solution 12: Check Whether the Key Password Was Changed

Java keytool provides the -keypasswd command for changing the password protecting a key entry. :contentReference[oaicite:19]{index=19}

If the password was changed previously, an old Gradle or CI configuration can still contain the previous value.

Solution 13: Change the Key Password If You Know the Existing One

keytool -keypasswd -alias release -keystore release.jks

Enter the current and new passwords when prompted.

Solution 14: Test a Specific Alias

keytool -list -v -keystore release.jks -alias release

If the alias does not exist, correct the Gradle keyAlias value.

Solution 15: Check Which keytool Is Running

Windows:

where keytool

macOS or Linux:

which keytool

If multiple Java installations are returned, verify that you are using the intended one.

Solution 16: Check the Java Version

java -version keytool -J-version

Compare it with the JDK used by Android Studio and Gradle.

Solution 17: Check Android Studio’s Gradle JDK

Open:

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

Verify that the project is using the expected JDK.

Solution 18: Do Not Assume Gradle Cache Is the Root Cause

This error concerns reading a signing key, so deleting caches alone often does not solve it.

Verify the keystore directly first:

keytool -list -v -keystore release.jks

Solution 19: Clean and Build Again

After correcting the signing configuration:

macOS or Linux:

./gradlew clean ./gradlew assembleRelease

Windows:

gradlew.bat clean gradlew.bat assembleRelease

For an App Bundle:

./gradlew bundleRelease

Solution 20: Re-enter Signing Information in Android Studio

Open:

Build → Generate Signed App Bundle or APK

Verify:

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

Solution 21: Test a Backup Keystore

Do not overwrite the original file.

Test a separate backup copy:

keytool -list -v -keystore backup-release.jks

If the backup works but the current file does not, the current keystore may be damaged.

Solution 22: Check the Keystore File Size

macOS or Linux:

ls -lh release.jks

Windows PowerShell:

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

A zero-byte file or a size that differs dramatically from a known backup can indicate corruption.

Solution 23: Check CI/CD Secrets

If the local build works but CI reports:

Failed to read key from store

compare the remote values for:

• Keystore file
• Store Password
• Key Alias
• Key Password

A common problem is updating one password locally but leaving an older secret in CI.

Solution 24: Verify a Keystore Restored from Base64

CI systems sometimes store a keystore as Base64 and recreate the binary file during the build.

An incorrect decoding step can produce a file named .jks whose contents are invalid.

After reconstruction, run:

keytool -list -v -keystore release.jks

If keytool cannot inspect the reconstructed file, fix the CI restoration step first.

Difference from “Keystore was tampered with, or password was incorrect”

This message:

Keystore was tampered with, or password was incorrect

usually points more directly to opening the keystore itself with the store password.

By contrast:

Failed to read key from store

can occur when the keystore is accessible but the requested private key cannot be retrieved.

Difference from “Alias does not exist”

A missing alias can produce a more explicit error such as:

Alias ... does not exist

However, build tools can wrap a lower-level alias error inside a broader “Failed to read key from store” failure.

Always verify aliases directly with keytool -list.

If “Cannot recover key” Also Appears

You may see a lower-level cause such as:

Cannot recover key java.security.UnrecoverableKeyException

In this situation, focus strongly on the key password.

Oracle’s keytool documentation confirms that key recovery may require a password separate from the keystore password. :contentReference[oaicite:20]{index=20}

If You Forgot the Key Password

Check:

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

Without the correct key password, the existing private key cannot normally be used for signing.

Should You Create a New Keystore?

For an unpublished application, creating a new signing keystore may be possible.

For an already published app, do not simply replace the existing signing key.

If Google Play App Signing is enabled, the app signing key and upload key may also be managed separately, so verify the current signing configuration before changing anything.

Security Note About Passwords in Gradle

This is technically possible:

storePassword = "password" keyPassword = "password"

but committing real signing credentials to GitHub or another public repository is unsafe.

Treat the keystore and its passwords as secrets.

Fastest Diagnostic Order

1. Run keytool -list -v -keystore release.jks.
2. Confirm that the store password opens the keystore.
3. Read the real alias from the keystore.
4. Match Gradle’s keyAlias to that alias.
5. Verify keyPassword.
6. Verify that storeFile points to the correct keystore.
7. Check JKS versus PKCS12.
8. Compare with a known backup.

If the Problem Still Occurs

Verify all of the following:

• The keystore password is correct.
• The key password is correct.
• The two passwords have not been confused.
• The key alias is correct.
• The alias actually exists.
• The alias contains a private key.
• The correct keystore file is being used.
• storeFile points to the correct path.
• keystore.properties does not contain stale values.
• CI/CD secrets do not contain stale values.
• No accidental whitespace or line breaks exist in passwords.
• The keystore type is correct.
• The expected JDK is being used.
• The keystore file is not corrupted.
• A known backup has been tested.

Summary

The Android Studio “Failed to read key from store” error usually means that the required private key cannot be successfully retrieved from the selected keystore.

The most common causes are:

• Incorrect key alias
• Incorrect key password
• Confusing the store password and key password
• Selecting the wrong keystore
• Keystore format or file corruption problems

Start with:

keytool -list -v -keystore release.jks

Oracle documents -list as the command for inspecting keystore entries. :contentReference[oaicite:21]{index=21}

Then verify that the actual alias matches the Gradle signing configuration:

storeFile storePassword keyAlias keyPassword

Google’s Android signing documentation defines these as separate values for Release signing. :contentReference[oaicite:22]{index=22}

If the keystore opens correctly but the underlying error contains Cannot recover key or UnrecoverableKeyException, focus on the private key password. Oracle’s keytool documentation confirms that private-key recovery can require a password separate from the keystore password. :contentReference[oaicite:23]{index=23}

Finally, never delete or overwrite the original signing keystore of a published Android application while troubleshooting. Work from copies and preserve verified backups.