Pin com.posthog:posthog-android instead of using open version range [3.38.0,4.0.0)

Summary

posthog_flutter declares its native Android SDK dependency as an open version range:

// posthog_flutter-5.23.1/android/build.gradle
implementation 'com.posthog:posthog-android:[3.38.0,4.0.0)'

This is non-deterministic — Gradle resolves to whatever posthog-android patch is latest at build time. For any consumer that needs reproducible builds across short time windows (CI matrix re-runs, hotfix patch builds, regulated release pipelines), this is a footgun. Plugin pubspec versions are pinned (posthog_flutter: 5.23.1), but the native dep silently drifts.

Concrete impact: shorebird patches break

We use Shorebird for Dart-only OTA patches. Shorebird verifies that a patch build's native artifacts are byte-identical to the release artifact — any native diff aborts the patch with UnpatchableChangeException.

Released 0.148.1+9 on 2026-04-24 with com.posthog:posthog-android:3.42.1 (whatever Gradle resolved to that day). Tried to ship a Dart-only hotfix on 2026-04-27 — Gradle resolved to 3.43.0 (PostHog published it in the meantime), and shorebird rejected the patch:

[WARN] Your app contains native changes, which cannot be applied with a patch.
    Changed files:
        base/dex/classes.dex
Breaking differences (2):
  - com.posthog.PostHogConfig: bytecode changed in <init>(Ljava/lang/String;, Ljava/lang/String;)V
  - com.posthog.android.PostHogAndroid: bytecode changed in a(Landroid/content/Context;, ...)V

Both classes embed a sdkVersion constant from BuildConfig.VERSION_NAME, which differs between 3.42.1 and 3.43.0 — pure version drift, no source change on our side.

Workaround we shipped

Pin in app build.gradle.kts:

dependencies {
    constraints {
        implementation("com.posthog:posthog-android:3.42.1") {
            because("posthog_flutter ships an open range; pin so shorebird patches dex-match the release")
        }
    }
}

This unblocks us, but every consumer hits this independently and most won't know to look.

Ask

Pin to an exact posthog-android version per posthog_flutter release:

implementation 'com.posthog:posthog-android:3.x.y'  // exact, bumped intentionally per posthog_flutter release

This is the convention nearly every other Flutter plugin follows (e.g. firebase_*, google_sign_in, auth0_flutter) precisely so the unit of upgrade is the Flutter plugin version, not "whatever happens to be on Maven today." Open ranges trade upstream agility for consumer reproducibility — the trade-off doesn't favor consumers, especially for SDKs whose bytecode bakes in version constants.

If exact pinning is undesirable, even a narrow range (3.42.x) would let consumers pin transitively without surprises.

Environment

• posthog_flutter: 5.23.1
• Flutter: 3.41.6
• AGP: (Flutter default for this version)
• Affected posthog-android versions: any pair where the patch number differs (saw 3.42.1 → 3.43.0)

Happy to send a PR if there's appetite for the change.

Start with posthog_flutter-5.23.1/android/build.gradle and inspect how the posthog-android dependency is declared and resolved. Verify the selected exact version against the plugin release, then run the available Flutter and Android checks to confirm the dependency resolves reproducibly and the plugin still builds.