Tencent/tinker · error · DexException

bogus element_width: {}

Error message

bogus element_width: {}

What it means

InstructionPromoter rewrites 16-bit dex instructions into their wide-index (jumbo/promoted) forms while recomputing the promoted instruction address. Each instruction's code-unit width is derived from the backing array type (short[] = 1 unit per element, int[] = 2, long[] = 4); the switch's default branch fires when elementWidth is none of the handled values, i.e. an instruction format this promoter version does not know. The message is an internal invariant violation, not a normal data error.

Source

Thrown at third-party/aosp-dexutils/src/main/java/com/tencent/tinker/android/dx/instruction/InstructionPromoter.java:520

            case 1: {
                int length = ((byte[]) data).length;
                this.currentPromotedAddress += (length >> 1) + (length & 1);
                break;
            }
            case 2: {
                this.currentPromotedAddress += ((short[]) data).length * 1;
                break;
            }
            case 4: {
                this.currentPromotedAddress += ((int[]) data).length * 2;
                break;
            }
            case 8: {
                this.currentPromotedAddress += ((long[]) data).length * 4;
                break;
            }
            default: {
                throw new DexException("bogus element_width: " + Hex.u2(elementWidth));
            }
        }
    }
}

View on GitHub (pinned to 1b7ea02c23)

Solutions

  1. Upgrade the tinker dependency (which vendors aosp-dexutils) to a release whose dx instruction tables cover the dex format you are processing.
  2. Reproduce with a minimal dex and capture the opcode/format at the failure point (log elementWidth and the instruction) to confirm it is an unknown-format gap rather than corrupt input.
  3. If the input dex may simply be corrupt, validate it first with dexdump; a corrupt instruction stream can also yield an unhandled width.
  4. If the gap is confirmed, file an issue with the tinker project including the failing dex so the promoter's width table is extended.
Defensive patterns

Strategy: validation

Validate before calling

// Smoke-test the dex with dexdump before promoting instructions
boolean dexParsesCleanly(java.io.File dexFile) {
    try {
        Process p = new ProcessBuilder("dexdump", dexFile.getAbsolutePath()).start();
        return p.waitFor() == 0;
    } catch (Exception e) {
        return false;
    }
}

Try / catch

try {
    promoter.visit(instruction);
} catch (com.tencent.tinker.android.dex.DexException e) {
    if (e.getMessage() != null && e.getMessage().startsWith("bogus element_width")) {
        // unsupported instruction format: report dex + toolchain versions, abort this build
        throw new UnsupportedOperationException("unsupported dex instruction format; upgrade tinker/aosp-dexutils", e);
    }
    throw e;
}

Prevention

When it happens

Trigger: Promoting instructions (used when tinker rebuilds a dex with a promoter attached, typically to upgrade const-string to const-string/jumbo) and encountering an instruction whose element width is not 2, 4, or 8 — e.g. an opcode/format introduced by a newer dex spec or emitted by an exotic compiler.

Common situations: Parsing dex files produced by new AGP/d8 versions after an old aosp-dexutils was pinned; custom bytecode injected by an agent/framework using an instruction format the vendored dx code predates; version skew between the tool that built the dex and the vendored third-party/aosp-dexutils.

Related errors


AI-assisted analysis of Tencent/tinker@1b7ea02c23 (2026-08-14). Data as JSON: /api/errors/7ae4e938f75902cd. Report an issue: GitHub.