Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@libraries/expo-iap/android/src/main/java/expo/modules/iap/ExpoIapModule.kt`:
- Around line 678-706: The categories handling in showInAppMessagesAndroid
currently uses mapNotNull, which silently drops invalid category strings instead
of surfacing a bad input or preserving native default behavior. Update the
categories parsing in ExpoIapModule.kt to either reject unknown values with a
promise.reject/exception or return null when no supplied categories map
successfully, and keep valid categories mapped through mapInAppMessageCategory.
Make the behavior explicit in the AsyncFunction("showInAppMessagesAndroid") flow
so callers don’t get an empty list when they passed only unsupported values.

In `@libraries/godot-iap/addons/godot-iap/types.gd`:
- Around line 4069-4085: `InAppMessageParamsAndroid` is serializing and
deserializing `categories` with raw enum values instead of the JSON string
format expected by Android. Update the generator that produces `types.gd` so
`InAppMessageParamsAndroid.to_dict()` converts each
`InAppMessageCategoryAndroid` entry to its string/json representation, and
`from_dict()` maps each incoming string back through
`InAppMessageCategoryAndroid.fromJson(...)` when populating `categories`.

In `@libraries/godot-iap/android/src/main/java/dev/hyo/godotiap/GodotIap.kt`:
- Around line 861-868: The Billing Choice dialog flow in
GodotIap.showBillingProgramInformationDialog currently falls back to an empty
externalTransactionToken, which hides a required input from callers. Update the
JSON parsing logic to validate externalTransactionToken before constructing
BillingProgramInformationDialogParamsAndroid, and if it is missing or blank,
return a local error/result immediately instead of calling
store.showBillingProgramInformationDialog. Keep the check alongside the existing
billingProgram parsing so the failure is handled in the same GodotIap code path.

In
`@libraries/kmp-iap/library/src/androidMain/kotlin/io/github/hyochan/kmpiap/InAppPurchaseAndroid.kt`:
- Around line 1847-2059: The new reflective entry points in
getBillingChoiceInfoAndroid, showBillingProgramInformationDialogAndroid, and
showInAppMessagesAndroid only check billingClient for null, so a disconnected
stale client can still be used. Add a readiness guard using client.isReady
alongside the existing billingClient check, and fail fast with the same
NotPrepared PurchaseException path before any reflective invocation if the
client is not ready.
- Around line 2063-2072: The reflection-based setup in the In-App message
request builder is constructing InAppMessageParams.Builder with a no-arg
constructor, which will fail at runtime. Update the logic in the
InAppPurchaseAndroid InAppMessageParams setup to obtain the builder via
InAppMessageParams.newBuilder() instead of
Class.forName(...Builder).getConstructor().newInstance(), then keep the existing
category population and build flow unchanged.

In `@libraries/maui-iap/src/OpenIap.Maui/Types.cs`:
- Around line 4081-4092: The MAUI Billing Choice parameter types are stricter
than the underlying schema and other bindings, so callers cannot omit fields
that already have defaults. Update the Android parameter models, especially
BillingProgramInformationDialogParamsAndroid and
GetBillingChoiceInfoParamsAndroid, to either make billingProgram and
playBillingChoiceImageLayout optional or apply their schema defaults before
serialization so the public C# API matches the existing behavior.

In `@packages/docs/src/pages/docs/types/billing-programs.tsx`:
- Around line 412-468: The Android billing docs currently claim billingProgram
defaults to BILLING_CHOICE, but both
BillingProgramInformationDialogParamsAndroid.billingProgram and
GetBillingChoiceInfoParamsAndroid.billingProgram are required and fromJson()
uses BillingProgramAndroid.Unspecified when omitted. Update the summaries in
billing-programs.tsx and the related Android API docs to reflect the required
parameter and the Unspecified fallback, not a BILLING_CHOICE default.

In `@packages/google/openiap/src/amazon/java/dev/hyo/openiap/OpenIapModule.kt`:
- Around line 668-687: The Billing Choice stubs in OpenIapModule should all
return the same unsupported signal so callers can handle Amazon-only behavior
consistently. Update showBillingProgramInformationDialog and showInAppMessages
to use the same permanent not-supported/error path as getBillingChoiceInfo,
instead of returning SERVICE_UNAVAILABLE or NoActionNeeded. Keep the
platform-specific behavior explicit in these methods and align the
returned/raised result with the existing OpenIapError.FeatureNotSupported
pattern.

In `@packages/google/openiap/src/main/java/dev/hyo/openiap/Types.kt`:
- Around line 4621-4643: The InAppMessageParamsAndroid.fromJson deserializer
currently relies on InAppMessageCategoryAndroid.fromJson, which can throw on
unknown values and break forward compatibility. Update the categories parsing in
InAppMessageParamsAndroid.Companion.fromJson to safely handle unrecognized
strings by mapping them to UnknownInAppMessageCategoryId instead of calling the
throwing path. Keep the toJson behavior unchanged and make the fallback logic
explicit where the categories list is built.

In `@packages/google/openiap/src/play/java/dev/hyo/openiap/OpenIapModule.kt`:
- Around line 1018-1042: The showInAppMessages flow in OpenIapModule should not
turn a non-OK BillingResult into InAppMessageResultAndroid(NoActionNeeded).
Update the submitResult handling so any immediate failure from the reflective
showInAppMessages invocation is surfaced as an exception or failure result
instead of resuming success; use the existing OpenIapLog and
resumer.resumeWithException/OpenIapError paths alongside showInAppMessages,
BillingResult, and InAppMessageResultAndroid to keep the error visible to
callers.

---

Outside diff comments:
In
`@libraries/kmp-iap/example/composeApp/src/commonMain/kotlin/dev/hyo/martie/screens/AlternativeBillingScreen.kt`:
- Around line 363-372: Route BillingProgramAndroid.BillingChoice through its own
Billing Choice purchase flow instead of handleAndroidBillingPrograms in
AlternativeBillingScreen.handlePurchase. Update the Android branch to call a
dedicated Billing Choice handler that performs the metadata fetch, required
information dialog, billing type selection, and Play in-app message steps
described in this screen, while leaving BillingProgramAndroid.ExternalOffer,
BillingProgramAndroid.ExternalPayments, and
BillingProgramAndroid.ExternalContentLink on the generic flow.

---

Duplicate comments:
In `@packages/google/openiap/src/horizon/java/dev/hyo/openiap/OpenIapModule.kt`:
- Around line 1207-1233: Align the unsupported-platform handling in
OpenIapModule’s showBillingProgramInformationDialog and showInAppMessages with
getBillingChoiceInfo and the Amazon variant: these Meta Horizon-only stubs
should signal FEATURE_NOT_SUPPORTED instead of returning a success-like
BillingResultAndroid/InAppMessageResultAndroid. Update the response in
showBillingProgramInformationDialog to the unsupported-feature code and make
showInAppMessages use the same unsupported-path pattern (throwing
OpenIapError.FeatureNotSupported or an equivalent unsupported result), so all
three methods report the same platform limitation consistently.

---

Nitpick comments:
In `@libraries/expo-iap/src/modules/android.ts`:
- Around line 396-416: `createBillingProgramReportingDetailsAndroid` should be
aligned with the same `MutationField` type-safety used by the other Android
wrappers in this file. Update its signature to match the canonical
`MutationCreateBillingProgramReportingDetailsAndroidArgs` contract from
`types.ts`, and if you must preserve the old string-style call, use TypeScript
overloads so the implementation still conforms to the mutation field shape. Keep
the implementation in `createBillingProgramReportingDetailsAndroid` and
`ExpoIapModule.createBillingProgramReportingDetailsAndroid` compatible with the
generated args map, rather than relying on an untyped union plus a second
positional parameter.

In
`@libraries/maui-iap/android/openiap/src/main/java/dev/hyo/openiap/maui/OpenIapMauiModule.kt`:
- Around line 230-244: `createBillingProgramReportingDetailsAndroid` and
`createBillingProgramReportingDetailsAndroidWithType` duplicate the same
`parseProgram` plus `module.createBillingProgramReportingDetails` flow, so the
overloads can drift. Update
`OpenIapMauiModule.createBillingProgramReportingDetailsAndroid` to delegate to
`createBillingProgramReportingDetailsAndroidWithType` with a null
developerBillingTypeJson, keeping the parsing and JSON conversion in one place.

In
`@libraries/react-native-iap/android/src/main/java/com/margelo/nitro/iap/HybridRnIap.kt`:
- Around line 1819-1945: The catch blocks in getBillingChoiceInfoAndroid,
showBillingProgramInformationDialogAndroid, and showInAppMessagesAndroid are
swallowing the original exception cause, so the stack trace is lost. Update the
thrown OpenIapException in each of these methods to include the caught err as
the cause, matching the existing pattern used elsewhere in HybridRnIap. Keep the
current logging and parseOpenIapError/toErrorJson flow, but preserve the
original throwable when rethrowing.

In `@libraries/react-native-iap/src/__tests__/index.test.ts`:
- Around line 2254-2305: Add non-Android rejection coverage for the Android-only
APIs to match the existing `getBillingChoiceInfoAndroid` pattern. In
`index.test.ts`, extend the test blocks for
`IAP.createBillingProgramReportingDetailsAndroid`,
`IAP.showBillingProgramInformationDialogAndroid`, and
`IAP.showInAppMessagesAndroid` with assertions that they throw or reject when
`Platform.OS` is not android, using the same style already used for
`getBillingChoiceInfoAndroid`. Keep the focus on the public wrapper methods and
verify no native mock calls are made on non-Android paths.

In `@packages/google/openiap/src/main/java/dev/hyo/openiap/Types.kt`:
- Around line 4601-4612: The companion object method
GetBillingChoiceInfoParamsAndroid.fromJson is marked nullable even though it
always returns a constructed GetBillingChoiceInfoParamsAndroid using defaults.
Update the return type to non-nullable and keep the existing parsing/defaulting
logic intact, mirroring how the method actually behaves; use the fromJson symbol
in GetBillingChoiceInfoParamsAndroid to locate and adjust the signature.

In `@packages/gql/src/api-android.graphql`:
- Around line 69-81: Update the doc block for
createBillingProgramReportingDetailsAndroid to document the developerBillingType
argument and its default behavior. Mention that this parameter is optional, and
when program is BILLING_CHOICE and developerBillingType is omitted, the native
OpenIapModule.kt behavior defaults it to IN_APP. Keep the public API contract
clear for consumers by reflecting this behavior in the schema comments near
createBillingProgramReportingDetailsAndroid and BillingProgramAndroid.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@libraries/flutter_inapp_purchase/scripts/verify-android-consumer-build.sh`:
- Around line 42-68: Add validation in verify-android-consumer-build.sh around
read_google_plugin_version and the perl -0pi edits: after reading the
com.android.library, org.jetbrains.kotlin.plugin.compose, and
com.vanniktech.maven.publish versions, fail fast if any value is empty instead
of writing a blank version into settings.gradle(.kts). Also check each perl
substitution against the settings_file update in both branches so the script
errors out if the plugins block pattern is not found, with a clear message
identifying the affected settings file.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@packages/gql/codegen/plugins/csharp.ts`:
- Around line 411-417: In csharp.ts, fix the non-nullable property emission in
the branch that uses buildDefaultValueExpression so that if the default cannot
be converted, the property falls back to being marked required instead of being
emitted without required or an initializer. Also update
buildDefaultValueForType’s string handling to escape C# string literal
characters such as " and \ before interpolating the default value, so generated
properties in emit stay valid.

In `@packages/gql/codegen/plugins/kotlin.ts`:
- Around line 895-901: The scalar default formatting in the Kotlin codegen path
is treating all numeric defaults the same, which causes whole-number
Float/Double defaults to emit invalid Kotlin literals. Update the default-value
formatting logic in the scalar-handling branch of the Kotlin plugin so it checks
the target GraphQL scalar type before serializing numbers, and when the field
maps to Float/Double, emit a Kotlin floating-point literal instead of using
String(defaultValue). Keep the existing string/boolean handling intact, and
adjust the helper that formats defaults so it can distinguish the Float scalar
case.

---

Outside diff comments:
In `@packages/google/openiap/src/horizon/java/dev/hyo/openiap/OpenIapModule.kt`:
- Around line 810-831: The Horizon overrides for
showBillingProgramInformationDialogAndroid and showInAppMessagesAndroid
currently mix placeholder result returns with FeatureNotSupported exceptions,
which creates inconsistent failure handling. Update the OpenIapModule.kt
implementations so both unsupported paths use the same failure shape as the rest
of the API, either by consistently returning the corresponding result object or
consistently throwing FeatureNotSupported from the named lambdas, and make the
behavior match across both functions.

In `@packages/gql/codegen/plugins/dart.ts`:
- Around line 838-849: The buildFromJsonExpression list branch currently applies
a non-nullable cast before checking defaultExpression, so non-null list fields
with schema defaults can throw on null before the fallback runs. Update the list
handling in buildFromJsonExpression so the null check happens on the raw
sourceExpr (or use a nullable cast whenever defaultExpression is present), then
only cast/map after the default fallback has been selected. Keep the behavior
aligned for both nullable and non-nullable list types, especially when
defaultExpression is set.

---

Duplicate comments:
In `@packages/google/openiap/src/main/java/dev/hyo/openiap/Types.kt`:
- Around line 4441-4467: The Billing Choice enum parsing in
BillingProgramInformationDialogParamsAndroid.fromJson and
GetBillingChoiceInfoParamsAndroid.fromJson is still calling fromJson directly,
unlike the rest of this file’s safe enum parsing pattern. Update the parsing in
these methods to use runCatching around BillingProgramAndroid.fromJson and
BillingChoiceImageLayoutAndroid.fromJson, then fall back to the corresponding
Unknown-style member if present; if no fallback exists, add one consistently.
Keep the fix aligned with the existing enum deserializers in Types.kt and with
the already-correct InAppMessageParamsAndroid.categories handling.