[eszter-varga]

The Play Billing library can invoke the response listener of a single async
call more than once (observed in production via its internal watchdog/timeout
path, zzaf.run → zzan.run, with the real response also arriving). A pigeon
reply may only be submitted once; the second completion throws
IllegalStateException: Reply already submitted on the main thread and kills
the process.

startConnection already guards against a double onBillingSetupFinished
with its alreadyFinished flag; this PR extends the same protection to the
other 9 async methods via a replyOnce(methodName, callback) wrapper — an
AtomicBoolean.getAndSet(true) single-shot around the pigeon callback. The
first completion wins; duplicates are dropped with a Log.d. Call sites bind
the pigeon parameter as rawCallback and rebind callback to the wrapper, so
the method bodies are otherwise unchanged and every completion path
(null-client error, null-activity error, listener response, RuntimeException
catch) is single-shot. Listener side effects (updateCachedProducts) still
run on dropped duplicates, so if an error response lands first and the real
one second, the product cache still receives real data for a later
launchBillingFlow.

Two JUnit regression tests fire a captured listener twice with distinct
results and assert exactly one pigeon completion holding the first result.

Developed with AI assistance; tested and verified by the submitter.

Fixes flutter/flutter#191832
Related: flutter/flutter#103432, flutter/flutter#134967

Pre-Review Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the AI contribution guidelines and understand my responsibilities, or I am not using AI tools.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter.
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I followed the version and CHANGELOG instructions, using semantic versioning and the repository CHANGELOG style, or I have commented below to indicate which documented exception this PR falls under¹.
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which test exemption this PR falls under¹.
• All existing and new tests are passing.

Note: this PR and #12639 both bump the package to 0.5.3; whichever lands
second will be rebased and re-bumped.

Footnotes

1. Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩²

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request introduces a replyOnce helper method in MethodCallHandlerImpl.java to prevent crashes caused by duplicate listener responses from the Play Billing library. The helper wraps asynchronous callbacks using an AtomicBoolean to ensure they are executed only once, dropping subsequent duplicate invocations. Corresponding regression tests have been added to MethodCallHandlerTest.java to verify this behavior, and the package version has been updated to 0.5.3 in pubspec.yaml and CHANGELOG.md. There are no review comments, so no additional feedback is provided.

[elliette]

[from triage] gentle ping - @gmackall are you still reviewing this PR? Thanks!

[gorkemdurgun]

We're hitting this in production as well (in_app_purchase_android 0.5.0 / Play Billing 8.0.0), on queryProductDetailsAsync, through a different internal path than the one in the description (zzN → zzap.run rather than zzaf.run → zzan.run):

java.lang.IllegalStateException: Reply already submitted
  at io.flutter.embedding.engine.dart.DartMessenger$Reply.reply (DartMessenger.java:431)
  at io.flutter.plugin.common.BasicMessageChannel$IncomingMessageHandler$1.reply (BasicMessageChannel.java:266)
  at io.flutter.plugins.inapppurchase.InAppPurchaseApi$Companion.setUp$lambda$24$lambda$23$lambda$22 (InAppPurchaseApi.java:1991)
  at io.flutter.plugins.inapppurchase.ResultCompat.success (ResultUtils.kt:17)
  at io.flutter.plugins.inapppurchase.MethodCallHandlerImpl.lambda$queryProductDetailsAsync$4 (MethodCallHandlerImpl.java:234)
  at com.android.billingclient.api.BillingClientImpl.zzN (BillingClientImpl.java:4)
  at com.android.billingclient.api.zzap.run (zzap.java:71)

Seen on Honor LLY-NX1 (Android 16), with the app resuming from background.

I also ran the Android unit tests on this branch (2d177ab) with Flutter 3.47.5:

• MethodCallHandlerTest: all 46 pass, including the two new *_duplicateListenerResponseIsIgnored tests.
• With the MethodCallHandlerImpl.java change reverted, both new tests fail, so they do cover the regression.

Would be great to see this land. Thanks @eszter-varga!

[alonaviram]

We hit this in production too, on in_app_purchase_android 0.5.2 with Play Billing 9.1.0. Over the last 90 days we logged 240 crashes from 235 installs. 93% happened while the app was in the background, mostly on Android 15/16 (Vivo, Oppo, Xiaomi and Realme).

In every 9.1.0 event, the crashing (second) reply comes from Billing's watchdog:

MethodCallHandlerImpl.lambda$queryProductDetailsAsync$5
  ← BillingClientImpl.zzaa ← zzbi.run ← zzbb.run ← Handler (main)

Here is what the 9.1.0 bytecode shows. queryProductDetailsAsync submits the query to the billing executor. It also posts a watchdog to the main handler at 0.95 × 30 s = 28.5 s. If the Future isn't done by then, the watchdog calls the listener with "Timeout communicating with service.". The worker calls the same listener from inside the Future, before the Future completes. So if the real response lands close to the 28.5 s mark, both paths reply. That fits our data: no crash happened sooner than 31 s after session start.

The replyOnce guard in this PR covers that path. Could it be rebased onto main to clear the conflicts so it can land? Thanks!

[camsim99]

LGTM!