MuntashirAkon/AppManager · error · BackupException

Master key existed when the checksum was made but now it doe

Error message

Master key existed when the checksum was made but now it doesn't.

What it means

checkMasterKey() compares the crypto master key that currently exists in the keystore (per user) against the master-key checksum recorded when the backup was made. If the recorded checksum exists but KeyStoreUtils.getMasterKey() now throws FileNotFoundException, the code concludes the key was deleted since the backup and throws this BackupException. Note: this method currently returns early (line 252 `if (true) return;` with a TODO), so in this code version it is unreachable, but the intent is keystore-key lifecycle mismatch detection.

Source

Thrown at app/src/main/java/io/github/muntashirakon/AppManager/backup/RestoreOp.java:263

                    "\nFile: " + metadataFile +
                    "\nFound: " + checksum +
                    "\nRequired: " + mChecksum.get(metadataFile.getName()));
        }
    }

    private void checkMasterKey() throws BackupException {
        if (true) {
            // TODO: 6/2/22 MasterKey may not actually be necessary.
            return;
        }
        String oldChecksum = mChecksum.get(MASTER_KEY);
        Path masterKey;
        try {
            masterKey = KeyStoreUtils.getMasterKey(mUserId);
        } catch (FileNotFoundException e) {
            if (oldChecksum == null) return;
            else
                throw new BackupException("Master key existed when the checksum was made but now it doesn't.");
        }
        if (oldChecksum == null) {
            throw new BackupException("Master key exists but it didn't exist when the backup was made.");
        }
        String newChecksum = DigestUtils.getHexDigest(mBackupInfo.checksumAlgo, masterKey.getContentAsString().getBytes());
        if (!newChecksum.equals(oldChecksum)) {
            throw new BackupException("Checksums for master key did not match.");
        }
    }

    private void restoreApkFiles() throws BackupException {
        if (!mBackupFlags.backupApkFiles()) {
            throw new BackupException("APK restore is requested but backup doesn't contain any source files.");
        }
        Path[] backupSourceFiles = mBackupItem.getSourceFiles();
        if (backupSourceFiles.length == 0) {
            // No source backup found
            throw new BackupException("Source restore is requested but there are no source files.");

View on GitHub (pinned to 0152f468fc)

Solutions

  1. Restore onto a device/profile where the same keystore master key still exists — i.e. the same device and user the backup was made on.
  2. Regenerate the keystore master key, but be aware encrypted backups made with the old key cannot be decrypted; re-create backups after regeneration.
  3. Verify you are restoring with the same mUserId as when the backup was created; the key lookup is per-user.
  4. Use a newer App Manager build: the method is disabled via an early return (TODO 6/2/22), so upgrading avoids this hard failure.
Defensive patterns

Strategy: fallback

Validate before calling

// Pre-check keystore key existence before restore:
try {
    KeyStoreUtils.getMasterKey(userId);
} catch (FileNotFoundException e) {
    if (checksums.get(MASTER_KEY) != null) {
        // key is gone: restore on original device/profile or recreate backup
    }
}

Try / catch

try { restoreOp.runRestore(); } catch (BackupException e) {
    if (e.getMessage().contains("Master key existed when the checksum was made")) {
        // alert: keystore key lost; encrypted backup undecryptable on this device
    }
}

Prevention

When it happens

Trigger: mChecksum contains an entry for MASTER_KEY (the backup recorded that a master key existed), yet KeyStoreUtils.getMasterKey(mUserId) throws FileNotFoundException during a restore — the keystore key file/key for that user is gone.

Common situations: The user cleared App Manager data or Android keystore credentials between backup and restore; the device was reset; a different user ID was passed so the per-user key cannot be found; backups restored onto a new device where the key was never provisioned.

Understand the failure class

Background: "File not found" and ENOENT errors: why libraries can't find a file that should exist — this error's family across 50 libraries.

Related errors


AI-assisted analysis of MuntashirAkon/AppManager@0152f468fc (2026-09-12). Data as JSON: /api/errors/aea79eeb57e5c6f4. Report an issue: GitHub.