MuntashirAkon/AppManager · error · BackupException
Could not get metadata file.
Error message
Could not get metadata file.
What it means
verifyMetadata() (for v5+ backups) fetches the metadata file path via mBackupItem.getInfoFile(); an IOException there becomes this BackupException. Verification cannot compare the metadata checksum because the metadata file itself cannot be located or opened.
Solutions
- Ensure the metadata/info file exists in the backup directory and re-copy it if missing.
- Grant AppManager storage/All-Files-Access permissions so the file can be opened.
- Keep the backup directory name and layout exactly as produced by the backup operation.
- Confirm the backup is genuinely v5+; verify a pre-v5 backup with a matching AppManager version.
Example fix
// before: metadata file removed during manual cleanup backup/ # info.json deleted // after: keep all original backup files intact backup/ # backup.json, info.json, data, checksums
Defensive patterns
Strategy: validation
Validate before calling
// Check the metadata/info file is present and readable before verify
File info = new File(backupDir, "info.json"); // per v5+ layout
if (!info.isFile() || !info.canRead()) throw new IllegalStateException("metadata file missing/unreadable"); Try / catch
try {
new VerifyOp(backupItem).verify();
} catch (BackupException e) {
if ("Could not get metadata file.".equals(e.getMessage())) {
// restore missing file from source backup or re-grant storage access
}
} Prevention
- Keep backup directories byte-identical when moving them (no renaming, no pruning).
- Re-check storage permissions after Android upgrades before running verification.
- Archive backups as a single archive file to prevent partial copies.
When it happens
Trigger: verify() on a v5+ backup where getInfoFile() cannot resolve/open the metadata (info) file — the file is absent from the backup directory, unreadable due to permissions, or the backup item's paths are inconsistent with the on-disk layout.
Common situations: Backups copied without the metadata file, renamed backup directories breaking internal path resolution, restricted storage permissions after an Android update, or pre-v5 backup layouts misidentified as v5+.
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
- Could not get backup files.
- Could not get metadata file.
- Could not read backup metadata. Possibly due to a malformed…
- Could not retrieve metadata from backup.
- Couldn't get misc.am.tsv
AI-assisted analysis of MuntashirAkon/AppManager@0152f468fc (2026-09-12).
Data as JSON: /api/errors/9996842d744b2929.
Report an issue: GitHub.
Appendix: source
Thrown at app/src/main/java/io/github/muntashirakon/AppManager/backup/VerifyOp.java:114
}
if (mBackupFlags.backupRules()) {
verifyRules();
}
} catch (BackupException e) {
throw e;
} catch (Throwable th) {
throw new BackupException("Unknown error occurred", th);
}
}
private void verifyMetadata() throws BackupException {
boolean isV5AndUp = mBackupItem.isV5AndUp();
if (isV5AndUp) {
Path infoFile;
try {
infoFile = mBackupItem.getInfoFile();
} catch (IOException e) {
throw new BackupException("Could not get metadata file.", e);
}
String checksum = DigestUtils.getHexDigest(mBackupInfo.checksumAlgo, infoFile);
if (!checksum.equals(mChecksum.get(infoFile.getName()))) {
throw new BackupException("Couldn't verify metadata file." +
"\nFile: " + infoFile +
"\nFound: " + checksum +
"\nRequired: " + mChecksum.get(infoFile.getName()));
}
}
Path metadataFile;
try {
metadataFile = isV5AndUp ? mBackupItem.getMetadataV5File(false) : mBackupItem.getMetadataV2File();
} catch (IOException e) {
throw new BackupException("Could not get metadata file.", e);
}
String checksum = DigestUtils.getHexDigest(mBackupInfo.checksumAlgo, metadataFile);
if (!checksum.equals(mChecksum.get(metadataFile.getName()))) {
throw new BackupException("Couldn't verify metadata file." +View on GitHub (pinned to 0152f468fc)