Add password (numeric-password) variation to TextInputType.numberWithOptions #190204

Use case

Flutter already exposes the text-class password variations through TextInputType.visiblePassword (added in #36695, closing #31738), which maps to Android's TYPE_TEXT_VARIATION_VISIBLE_PASSWORD.

The numeric-class counterpart — TYPE_NUMBER_VARIATION_PASSWORD — has no representation in TextInputType. TextInputType.numberWithOptions currently exposes only signed and decimal, so there is no way for a Flutter field to declare itself as a numeric-password input to the platform / IME. The engine's Android TextInputPlugin NUMBER branch never sets TYPE_NUMBER_VARIATION_PASSWORD, and — correctly — obscureText is not used to derive it, because visual obscuring is a Flutter rendering concern independent of the platform input classification.

Concretely, a native Android field declared as

inputType = TYPE_CLASS_NUMBER | TYPE_NUMBER_VARIATION_PASSWORD  // 2 | 16 = 18

is also the canonical form documented by the platform as android:inputType="numberPassword" — i.e. Android itself treats this combination as a first-class, named input type. It cannot be produced from Flutter public API today.

Real-world numeric password fields in native apps (banking PIN entry, OTP screens) are routinely built with inputType == 18; a Flutter port has to settle for inputType == 2 and give up any platform-level cues tied to the numeric-password classification (IME candidate policy, contextual suggestions, form-manager heuristics, per-IME learning behavior).

Why not use existing knobs

• obscureText: true — wrong tool. It masks the glyphs Flutter renders; consumers that draw their own cells (custom PIN widgets) need the raw text visible while still declaring the field as numeric-password to the platform.
• TextInputType.visiblePassword — text class, not numeric; brings up a full alphanumeric keyboard.
• AutofillHints / enableIMEPersonalizedLearning — orthogonal signals (autofill hints and imeOptions respectively); they don't set inputType.
• A pub.dev package — not viable: the inputType mapping lives in the engine's TextInputPlugin and is not pluggable from Dart.

Proposal

Add a password parameter to TextInputType.numberWithOptions, symmetric to the visiblePassword precedent:

const TextInputType.numberWithOptions({
  this.signed = false,
  this.decimal = false,
  this.password = false,   // NEW
});

Default false — construction of existing TextInputType.number and TextInputType.numberWithOptions(...) is byte-for-byte unchanged. toJson, operator ==, hashCode, and toString are updated to include the new field.

Serialization — additive JSON field; older engines that don't parse it fall back to today's behavior:

{
  "name": "TextInputType.number",
  "signed": false,
  "decimal": false,
  "password": true
}

Platform mapping

• Android (TextInputPlugin.inputTypeFromTextInputType, NUMBER branch):

  int textType = InputType.TYPE_CLASS_NUMBER;
  if (type.isSigned)   textType |= InputType.TYPE_NUMBER_FLAG_SIGNED;
  if (type.isDecimal)  textType |= InputType.TYPE_NUMBER_FLAG_DECIMAL;
  if (type.isPassword) textType |= InputType.TYPE_NUMBER_VARIATION_PASSWORD;

  obscureText remains orthogonal — it neither implies nor is implied by TYPE_NUMBER_VARIATION_PASSWORD. This preserves behavior for every existing keyboardType: number + obscureText: true field.

• iOS — iOS traits are independent, not a bit field. password: true is a no-op for UIKeyboardType (stays .numberPad) and does not set isSecureTextEntry. obscureText continues to drive masking; AutofillHints.oneTimeCode continues to drive .oneTimeCode.

• Web — inputmode="numeric" unchanged; HTML type="password" continues to be driven by obscureText.

• Windows / macOS / Linux — no-op in v1, documented.

Backward compatibility

• Additive; default false; no behavior change for existing callers.
• JSON is additive.
• No change to obscureText, AutofillHints, or enableIMEPersonalizedLearning semantics.

Docs will state explicitly: password: true declares the platform input classification only. It does not obscure Flutter-rendered glyphs — use obscureText for that. It is currently a no-op on iOS / web / desktop.

Tests

• Framework: default value, toJson, ==, hashCode, toString, unchanged signed/decimal behavior.
• Android engine inputType matrix: number→2, number+password→18, number+signed→4098, number+decimal→8194, JSON without password→2.
• Orthogonality: obscureText alone doesn't set the variation; enableIMEPersonalizedLearning: false still only touches imeOptions; AutofillHints.oneTimeCode still only touches autofill hints.

Landing order — per Tree Hygiene, engine JSON parsing + Android mapping first, framework field once the engine revision is available; happy to split PRs that way.

Filing this issue before sending a PR to align on API shape. Precedent: #36695 / #31738.

References:

• android:inputType XML attribute (numberPassword enum)
• InputType constants