skylot/jadx · error · JadxRuntimeException

Unsupported Arg Type:

Error message

Unsupported Arg Type: 

What it means

Thrown by ClsSet.readArgType() when deserializing an ArgType from the binary .clst classpath file. The switch covers all seven TypeEnum values (WILDCARD, GENERIC, GENERIC_TYPE_VARIABLE, OUTER_GENERIC, OBJECT, ARRAY, PRIMITIVE); the default branch is an exhaustive-switch guard. Hitting it means the .clst data stream produced a TypeEnum ordinal outside the known set, which can only happen if the file was written by a newer or incompatible jadx version that added a new TypeEnum constant.

Source

Thrown at jadx-core/src/main/java/jadx/core/clsp/ClsSet.java:447

				return ArgType.generic(clsType, readArgTypesList(in));

			case GENERIC_TYPE_VARIABLE:
				String typeVar = readString(in);
				List<ArgType> extendTypes = readArgTypesList(in);
				return ArgType.genericType(typeVar, extendTypes);

			case OBJECT:
				return classes[in.readInt()].getClsType();

			case ARRAY:
				return ArgType.array(Objects.requireNonNull(readArgType(in)));

			case PRIMITIVE:
				char shortName = (char) in.readByte();
				return ArgType.parse(shortName);

			default:
				throw new JadxRuntimeException("Unsupported Arg Type: " + ordinal);
		}
	}

	private static void writeString(DataOutputStream out, String name) throws IOException {
		byte[] bytes = name.getBytes(STRING_CHARSET);
		int len = bytes.length;
		if (len >= 0xFF) {
			throw new JadxRuntimeException("String is too long: " + name);
		}
		writeUnsignedByte(out, bytes.length);
		out.write(bytes);
	}

	private static String readString(DataInputStream in) throws IOException {
		int len = readUnsignedByte(in);
		return readString(in, len);
	}

View on GitHub (pinned to e738a26571)

Solutions

  1. Regenerate the .clst classpath file using the same jadx version you are running with (run the ClsSet export/save utility for the matching build).
  2. Ensure the jadx-core JAR and its embedded CLST_PATH resource come from the exact same release — do not mix JARs across versions.
  3. If the file is corrupted, delete the cached/local .clst and let jadx load the bundled one from the classpath resource.

Example fix

// before: mixing versions
//   jadx-core-1.5.x.jar with .clst from jadx-core-1.4.x
// after: use matching release
//   rebuild/re-download the full jadx distribution so core JAR and .clst align
Defensive patterns

Strategy: validation

Validate before calling

// Validate .clst file before loading
File clstFile = new File(path);
if (!clstFile.exists() || clstFile.length() < MIN_CLST_SIZE) {
    throw new IllegalArgumentException("Invalid or missing .clst file: " + path);
}
// Best prevention: ensure the .clst matches the jadx-core version
String coreVersion = ClsSet.class.getPackage().getImplementationVersion();
// Do not mix .clst files across jadx releases

Try / catch

try {
    clspGraph.loadClsSetFile();
} catch (JadxRuntimeException e) {
    if (e.getMessage().contains("Unsupported Arg Type")) {
        // Version mismatch — regenerate or use bundled .clst
        logger.error("Classpath file version mismatch. Use the .clst bundled with this jadx release.", e);
    }
    throw e;
}

Prevention

When it happens

Trigger: Loading a .clst classpath file (via ClsSet.loadFromClstFile or ClspGraph.loadClsSetFileFile) that was generated by a jadx build with a different TypeEnum. A corrupted or truncated .clst stream where the ordinal byte is read at the wrong offset can also produce an out-of-range enum index.

Common situations: Upgrading or downgrading jadx versions where the embedded android.clst resource was regenerated with an extra TypeEnum. Manually swapping the bundled .clst file with one from another jadx release. Running a custom build that modified the TypeEnum enum.

Related errors


AI-assisted analysis of skylot/jadx@e738a26571 (2026-08-14). Data as JSON: /api/errors/ebb3e2e42cf552b0. Report an issue: GitHub.