What causes "Could not cache splits" in MuntashirAkon/AppManager?

Check the cause: IOException means verify all split files exist and are readable in the source; RemoteException means retry once the system is stable.

MuntashirAkon/AppManager · error · BackupException

Could not cache splits

Error message

Could not cache splits

What it means

Thrown by SBConverter.generateMetadata when cacheAndGetSplitConfigs() fails to cache the APK split configuration files, via IOException (file I/O while copying splits into cache) or RemoteException ( PackageManager IPC failure). Splits are needed to record splitConfigs in the destination metadata for split-APK apps.

Source

Thrown at app/src/main/java/io/github/muntashirakon/AppManager/backup/convert/SBConverter.java:337

        try {
            mFilesToBeDeleted.add(getExtDataFile());
            flags.addFlag(BackupFlags.BACKUP_EXT_DATA);
            flags.addFlag(BackupFlags.BACKUP_CACHE);
        } catch (FileNotFoundException ignore) {
        }
        metadataV2.flags = flags;
        metadataV2.dataDirs = ConvertUtils.getDataDirs(mPackageName, mUserId, flags.backupInternalData(),
                flags.backupExternalData(), flags.backupMediaObb());
        try {
            mFilesToBeDeleted.add(getSplitFile());
            metadataV2.isSplitApk = true;
        } catch (FileNotFoundException e) {
            metadataV2.isSplitApk = false;
        }
        try {
            metadataV2.splitConfigs = cacheAndGetSplitConfigs();
        } catch (IOException | RemoteException e) {
            throw new BackupException("Could not cache splits", e);
        }
        metadataV2.userId = mUserId;
        metadataV2.tarType = Prefs.BackupRestore.getCompressionMethod();
        metadataV2.keyStore = false;
        metadataV2.installer = Prefs.Installer.getInstallerPackageName();
        return metadataV2;
    }

    @NonNull
    private Path getApkFile() throws FileNotFoundException {
        return mBackupLocation.findFile(mPackageName + ".app");
    }

    @NonNull
    private Path getSplitFile() throws FileNotFoundException {
        return mBackupLocation.findFile(mPackageName + ".splits");
    }

View on GitHub (pinned to 0152f468fc)

Solutions

Check the cause: IOException means verify all split files exist and are readable in the source; RemoteException means retry once the system is stable.
Ensure the source archive contains every split listed in the original backup, not just base.apk.
Free cache/storage space so split copying can complete.
If the app truly has no splits, ensure the source is exported as a non-split (single APK) backup.

Example fix

// before: convert with incomplete splits
converter.convert();
// after: verify splits before converting
for (String split : expectedSplits) {
    if (!new File(sourceDir, split).isFile())
        throw new IllegalStateException("missing split: " + split);
}
converter.convert();

Defensive patterns

Strategy: try-catch

Validate before calling

if (metadata.isSplitApk) {
    for (String split : metadata.splitConfigs) {
        if (!new File(sourceDir, split).isFile())
            throw new IllegalStateException("split missing in source: " + split);
    }
}

Try / catch

try { converter.convert(); }
catch (BackupException e) {
    if (e.getMessage().equals("Could not cache splits")
            && e.getCause() instanceof RemoteException) {
        // transient binder failure: wait and retry once
    }
}

Prevention

Export split-APK backups completely, including all split configs
Distinguish IOException (missing/corrupt splits) from RemoteException (binder, retryable)
Keep device storage free during split caching
Retry after system load subsides when the cause is RemoteException

When it happens

Trigger: A split-APK source backup whose split files are missing/unreadable mid-copy (IOException), or PackageManager binder calls dying during split resolution (RemoteException, e.g., system_server pressure or permission issues).

Common situations: Split config files truncated in the source archive; storage full during split caching; binder transaction failures on heavily loaded devices; converting split-APK backups where only base.apk was exported but metadata claims isSplitApk.

Understand the failure class

Background: "failed to read file", EACCES, ENOENT and "could not read <path>" errors: when a program can't read a file from disk — this error's family across 49 libraries.

Related errors

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