DEV Community: Navya Sinha

Why Gradle 9 broke our Flutter SDK, and how we're fixing it

Navya Sinha — Thu, 22 Oct 2026 22:06:58 +0000

One of our partners upgraded their Android build tools and their app stopped building. The cause wasn't their code. It was a single outdated line in our Flutter plugins, pointing at a download server the new tools no longer know about.

The fix is two lines per plugin. The more interesting story is why it happened, why the fix lives where it does, and why we're deliberately not shipping the bigger upgrade at the same time.

A 60-second primer 🧠

Three names that come up regulary:

Gradle is the build tool. It takes an Android project, downloads the libraries it needs and compiles it into an app. Think of it as the cook.
AGP (Android Gradle Plugin) is Google's add-on that teaches Gradle how to build Android apps. It's the recipe book, and it has versions: 8.x, and now 9.x.
Kotlin is the language our Android plugin code is written in. Until AGP 9 you needed a separate Kotlin add-on (KGP), like a second cookbook. AGP 9 binds Kotlin into the main recipe book, which Google calls "built-in Kotlin".

The most important point: the partner's app picks the versions of all three, not us. Our SDK has to work with whatever kitchen it's dropped into.

What happened? 🔍

The partner builds its app with Gradle 9.1 and AGP 9.0.1, and the app uses our plugin. The build failed during setup, before our SDK ran a single line.

The culprit was one word in our plugin's build file: jcenter().

That line tells Gradle to download libraries from JCenter, an old public library server. JCenter stopped taking new uploads in 2021 and since then has only passed on copies of what's on Maven Central, the main public server. Gradle deprecated jcenter() in Gradle 7 and deleted it completely in Gradle 9. So when Gradle 9 reads our file, it hits a command it doesn't recognise and stops.

It wasn't just one partner's problem. Every version of our Gateway and Loans Flutter plugins we've published has that line, so any partner on Gradle 9 would hit the same wall.

Why is our file in their build at all?🤔

When a partner adds a Flutter plugin, Flutter pulls the plugin's Android folder into the partner's build, and the partner's Gradle runs it.

Our native Android SDK works differently: partners download it as a finished package from our Artifactory, and its build files never run on their machines. That's why the fix belongs in the Flutter plugin repo and not the Android SDK repo.

Why we don't just use the newest everything 🤷‍♀️

It's tempting to ask why our SDK wasn't already on the latest tools. The answer is that an SDK is a guest in someone else's kitchen.

Each partner decides when to upgrade their tools, and upgrading touches their whole app, so some move fast and many move slowly. If our SDK demanded the newest tools, every partner who hadn't upgraded would be stuck on an old version of our SDK, without our bug fixes.

So we deliberately support old setups: our plugins accept Flutter versions as old as 3.0 and Android versions as old as 5.0 (API 21).

The catch is that supporting old setups means keeping some old pieces in our files. Usually that's harmless. But sometimes the newest tools delete an old piece outright, and then partners on the newest tools break. That's exactly what happened with jcenter().

We call this staying on the borderline: our SDK has to work at both ends at the same time, the oldest setup partners still run and the newest one they're moving to.

The fix: small now, bigger later 🔨

We're shipping this as two separate changes, on purpose.

The patch

In both the Gateway and Loans plugins, jcenter() becomes mavenCentral(). That's two lines per plugin. Maven Central holds the same libraries JCenter was passing on, and it works on every Gradle version we support, old and new. Nothing else changes: same SDK features, same native SDK versions, same minimum Flutter and Android versions. A partner on older tools won't notice anything.

The upgrade

This moves the plugins fully onto AGP 9's way of doing things. It drops the separate Kotlin add-on and relies on AGP 9's built-in Kotlin, renames some old settings to their new names, and raises the minimum Flutter version to 3.44. It also upgrades our demo app to the newest tools so we can test it.

Why not just ship the upgrade?

Because it breaks the first rule. Raising the Flutter minimum, and depending on built-in Kotlin, would lock out partners who haven't upgraded. We expect that would include the partner who reported the bug, since they run AGP 9 with built-in Kotlin switched off. The patch unblocks everyone today, and the upgrade can follow as a planned, announced release.

One thing that confuses people: neither bumps the AGP version inside our plugins. That's because the plugins never choose AGP; the partner's app does. Being "AGP 9 ready" means our build file works when AGP 9 runs it.

What it means for partners?

The easiest way to see the impact is to picture three kinds of partner.

Partner A hasn't upgraded yet and is still on Gradle 8 or older

Today: everything works.
After the patch: still works, and nothing changes for them.
After the upgrade: likely breaks. Below Flutter 3.44 they can't install it at all, and without built-in Kotlin our plugin's Kotlin code wouldn't be compiled.

Partner B upgraded to AGP 9 but kept Kotlin the old way by switching built-in Kotlin off.

Today: the build fails on jcenter().
After the patch: the jcenter() error is gone, and we expect the build to work. We're testing that now.
After the upgrade: likely breaks, because the upgrade expects built-in Kotlin and they've switched it off.

Partner C upgraded fully and uses built-in Kotlin. This needs Flutter 3.47 or newer.

Today: the build fails on jcenter().
After the patch: probably still fails. Our plugin still adds the old Kotlin add-on, and built-in Kotlin replaces it.
After the upgrade: works. This is the setupthe upgrade is built for.

So the patch helps A and B and hurts nobody, and the upgrade is what C needs. Neither covers all three yet.

The open question for the upgrade is whether one version of our plugin can serve both B and C, for example by adding the old Kotlin add-on only when built-in Kotlin is switched off.

Why React lets your number input lie to you

Navya Sinha — Tue, 06 Oct 2026 20:04:06 +0000

const [amount, setAmount] = useState(0);

const handleAmountChange = (e: React.ChangeEvent<HTMLInputElement>) => {
  const val = parseFloat(e.target.value);
  setAmount(isNaN(val) ? 0 : val);
};

<input type="number" value={amount || ''} onChange={handleAmountChange} />

If we type 0, then 5. The field shows 05.

State said 5. The payload we'd send said 5. The screen said 05. That's a controlled
component, which is supposed to mean "the DOM always shows state", and yet here it was
showing something else.

It isn't a bug in React, and it isn't a bug in our code either. It's a deliberate
trade-off, and to understand it you need to look at two layers: the browser and
React DOM.

Layer 1: what the browser thinks "05" is

An <input type="number"> keeps a string value, like every input. The HTML spec defines
a value sanitization algorithm for number inputs: if the value isn't a valid
floating-point number, the browser sets it to the empty string.

Is "05" a valid floating-point number? The spec grammar is roughly: an optional -,
then digits, then optionally . and more digits, then optionally an exponent. Nothing
there says "no leading zeros". So "05" is perfectly valid, and the browser leaves it
alone:

input.value          // "05"   ← the string, as typed
input.valueAsNumber  // 5      ← the parsed number

What if the user types something that isn't valid yet, like - or 1e? The browser
can't sanitize a half-typed string, so it reports:

input.value            // ""     ← yes, empty, even though you can see "-" on screen
input.validity.badInput // true

Remember that one. It comes back later.

Layer 2: what React does on every render

A "controlled" input works like this: after each render, React DOM compares the value
prop with the DOM node's current value, and writes the prop to the DOM if they differ.
For most inputs the comparison is a strict string comparison.

For type="number" it's different. Here's the relevant code from React DOM
(ReactDOMInput.js, React 18.2; React 19 has the same check):

if (type === 'number') {
  if (
    (value === 0 && node.value === '') ||
    // We explicitly want to coerce to number here if possible.
    // eslint-disable-next-line
    node.value != value
  ) {
    node.value = toString(value);
  }
} else if (node.value !== toString(value)) {
  node.value = toString(value);
}

That != is loose equality, used on purpose. Our case works out like this:

node.value = "05";   // what the user typed
value      = 5;      // our state

"05" != 5   // → false, because "05" is coerced to 5

React decides the DOM already shows the right thing and doesn't write to it. The
input keeps showing 05.

Why would React do that on purpose?

Imagine React used strict comparison instead. The user wants to type 1.5:

Keystroke	`node.value`	`parseFloat` → state	React writes	User sees
`1`	`"1"`	`1`	—	`1`
`.`	`"1."`	`1`	`"1"` 💥	`1`
`5`	`"15"`	`15`	—	`15` 😱

With strict comparison, every normal parse-on-change handler would make it impossible
to type a decimal point, and the same goes for 1.0, - or 1e3. The number is fine,
but the text representation gets rewritten underneath the user's cursor.

Loose equality says: "if the DOM's text already means the same number as the prop,
leave the user's text alone." That keeps typing smooth for 1., 1.50 and -0. The
side effect is that 05 also counts as "the same number as 5".

So the input isn't really lying. It's showing the user's text, while your state holds
the number that text means.

Proof: pass a string instead

Loose equality only coerces when one side is a number. Give React a string and it's a
plain string comparison:

<input type="number" value={amount.toString()} onChange={...} />

"05" != "5"   // → true, so React overwrites the DOM with "5"

Now 05 snaps to 5. We had this exact pattern in another screen (the loan-amount editor
passes loanAmount.toString()), and there the leading zero disappears. It's the same
component type, but a different prop type, so it behaves differently.

Of course, that brings back the decimal problem. "1." != "1", so the dot gets removed
again. Neither option is free.

The bonus bug: onChange that never fires

Remember badInput? React's onChange for inputs is built on a value tracker. It only
fires when the DOM value actually changed since last time.

Start with an empty field and type -:

before: input.value === ""
after:  input.value === ""      (badInput, because "-" isn't a number yet)

As far as the value tracker can see, nothing changed, so your onChange doesn't
run. The user sees a - on screen that your state knows nothing about. Type -5 and
you get the event, with "-5". This explains another class of odd reports ("I typed
e and the validation didn't show").

Other things `type="number"` does that you probably don't want

Mouse wheel changes the value while the input is focused and hovered. Scroll the page, and your loan amount goes from ₹50,000 to ₹49,999.
e, E, +, - and . are allowed anywhere, because scientific notation is a valid number.
maxLength is ignored. The spec only applies it to text-like input types.
Localisation: some browsers accept , as a decimal separator depending on the locale, so value changes meaning across users.
Spinner buttons appear on desktop unless you hide them with vendor CSS.

What we did

We switched to a text input with a numeric keyboard hint:

<TextInput
  type="text"
  inputMode="numeric"
  value={amount || ''}
  onChange={onAmountChange}
/>

inputMode="numeric" still shows the number pad on mobile, which is the main reason people choose type="number" anyway.
The value is a normal string, so React compares strictly and what you see is exactly what's in state.
We handle parsing and validation ourselves (strip non-digits, clamp to the max amount), so behaviour is identical in every browser.

Use inputMode="decimal" if you need a decimal point, and keep the raw string in
state (e.g. "1.") instead of parsing on every keystroke. Parse when you submit or blur.

Takeaways

A controlled input doesn't mean "the DOM is always a serialization of state". React DOM makes different trade-offs for different input types.
For type="number", React compares with loose equality on purpose, so users can type intermediate states like 1.. The same rule keeps 05.
Passing a number vs a string to value changes the behaviour.
input.value can be "" while the user sees text on screen (badInput), and React's onChange may not fire at all in that case.
For amounts, use type="text" + inputMode + your own parsing.