MuntashirAkon/AppManager · error · UnsupportedOperationException
Invalid key ${key}
Error message
Invalid key ${key} What it means
BloatwareOption.test() evaluates an app against the bloatware list using its key ("list" and "any", "type", "removal"); an unrecognized key reaches the default branch and throws UnsupportedOperationException("Invalid key " + key). It indicates the option was constructed with a key this class cannot evaluate.
Source
Thrown at app/src/main/java/io/github/muntashirakon/AppManager/filters/options/BloatwareOption.java:85
}
@NonNull
@Override
public TestResult test(@NonNull IFilterableAppInfo info, @NonNull TestResult result) {
DebloatObject object = info.getBloatwareInfo();
if (object == null) {
return result.setMatched(false);
}
// Must be a bloatware
switch (key) {
case KEY_ALL:
return result.setMatched(true);
case "type":
return result.setMatched((typeToFlag(object.type) & intValue) != 0);
case "removal":
return result.setMatched((object.getRemoval() & intValue) != 0);
default:
throw new UnsupportedOperationException("Invalid key " + key);
}
}
public int typeToFlag(@NonNull String type) {
switch (type) {
case "aosp":
return FILTER_LIST_AOSP;
case "carrier":
return FILTER_LIST_CARRIER;
case "google":
return FILTER_LIST_GOOGLE;
case "misc":
return FILTER_LIST_MISC;
case "oem":
return FILTER_LIST_OEM;
default:
throw new IllegalArgumentException("Unknown type: " + type);
}View on GitHub (pinned to 0152f468fc)
Solutions
- Construct BloatwareOption only with supported keys: "list", "type", or "removal"
- Add the missing case to test() if a new key is intended
- Correct any copy-pasted key strings from other option classes
- Validate persisted filter keys against the current schema before applying them
Example fix
// before
FilterOption opt = new BloatwareOption("bloat", "types"); // typo
boolean m = opt.test(packageInfo).isMatched(); // throws
// after
FilterOption opt = new BloatwareOption("bloat", "type"); // supported key
boolean m = opt.test(packageInfo).isMatched(); Defensive patterns
Strategy: type-guard
Validate before calling
Set<String> VALID = Set.of("list","any","type","removal"); if (!VALID.contains(key)) throw new IllegalArgumentException("Unsupported BloatwareOption key: " + key); Type guard
boolean isValidBloatKey(String key) { return key != null && Set.of("list","any","type","removal").contains(key); } Try / catch
try { boolean matched = option.test(packageInfo).isMatched(); } catch (UnsupportedOperationException e) { matched = false; /* ignore malformed bloat filter entry */ } Prevention
- Centralize bloatware filter key constants
- Migrate saved filters between app versions
- Don't copy key strings from other FilterOption classes
- Validate filter configs on import/export
When it happens
Trigger: Creating BloatwareOption with a key not in its switch (e.g. "app_type" or a misspelled "lst") and running app-list filtering; stale saved filters from older versions; copy-pasted option construction from another filter class.
Common situations: Renaming keys across filter classes without updating call sites; programmatic filter builders using wrong key constants; restoring exported filter configs from incompatible versions.
Understand the failure class
Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.
Related errors
AI-assisted analysis of MuntashirAkon/AppManager@0152f468fc (2026-09-12).
Data as JSON: /api/errors/d2b9b07050e169a9.
Report an issue: GitHub.