MuntashirAkon/AppManager · error · BackupException

Rules backup is requested but encountered an error during fe

Error message

Rules backup is requested but encountered an error during fetching rules.

What it means

backupRules() fetches the pseudo-rules file (rules.am.tsv via getRulesFile) and encrypts/checksums it. Any IOException or IndexOutOfBoundsException during fetch/encrypt is wrapped in this BackupException indicating the requested rules backup failed.

Source

Thrown at app/src/main/java/io/github/muntashirakon/AppManager/backup/BackupOp.java:590

            mChecksum.add(miscFile.getName(), DigestUtils.getHexDigest(mMetadata.info.checksumAlgo, miscFile));
        } catch (IOException | IndexOutOfBoundsException e) {
            throw new BackupException("Couldn't get misc.am.tsv for generating checksum", e);
        }
    }

    private void backupRules() throws BackupException {
        try {
            Path rulesFile = mBackupItem.getRulesFile();
            try (OutputStream outputStream = rulesFile.openOutputStream();
                 ComponentsBlocker cb = ComponentsBlocker.getInstance(mPackageName, mUserId)) {
                ComponentUtils.storeRules(outputStream, cb.getAll(), true);
            }
            if (!rulesFile.exists()) return;
            rulesFile = mBackupItem.encrypt(new Path[]{rulesFile})[0];
            // Store checksum
            mChecksum.add(rulesFile.getName(), DigestUtils.getHexDigest(mMetadata.info.checksumAlgo, rulesFile));
        } catch (IOException | IndexOutOfBoundsException e) {
            throw new BackupException("Rules backup is requested but encountered an error during fetching rules.", e);
        }
    }
}

View on GitHub (pinned to 0152f468fc)

Solutions

  1. Check chained cause to distinguish fetch (IOException) vs encrypt (IndexOutOfBounds) failures
  2. If no rules exist for the package, disable the rules backup flag instead of failing
  3. Verify the backup directory is writable and crypto metadata is valid
  4. Return early when getRulesFile() yields a non-existent file (code already checks rulesFile.exists())

Example fix

// before
rulesFile = mBackupItem.encrypt(new Path[]{rulesFile})[0];
// after
Path[] enc = mBackupItem.encrypt(new Path[]{rulesFile});
if (enc.length == 0) { Log.w(TAG, "No encrypted output for rules file"); return; }
rulesFile = enc[0];
Defensive patterns

Strategy: try-catch

Validate before calling

if (rulesBackupRequested && !hasRulesForPackage(pkg)) {
    Log.i(TAG, "no rules; skipping rules backup");
    return;
}

Try / catch

try {
    backupRules();
} catch (BackupException e) {
    Log.e(TAG, "rules backup failed", e.getCause());
    // continue without rules or abort per policy
}

Prevention

When it happens

Trigger: mBackupItem.getRulesFile() throws IOException (backup dir not accessible) or encrypt(new Path[]{rulesFile})[0] throws IndexOutOfBoundsException (empty encryption output) or checksum read fails — all only when rules backup is requested via flags.

Common situations: Rules backup flag enabled but no rules exist for the package; destination directory missing; encrypted output filter excluding the rules file; crypto metadata absent.

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/197e1d2987bddf34. Report an issue: GitHub.