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

  1. Construct BloatwareOption only with supported keys: "list", "type", or "removal"
  2. Add the missing case to test() if a new key is intended
  3. Correct any copy-pasted key strings from other option classes
  4. 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

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.