fix(android): return real success value from initTerra and initConnection [UNVERIFIED ON LIVE]

[Ant1Miller]

Summary

The Android Flutter bridge hardcoded map.put("success", true) in both initTerra and initConnection, discarding the success boolean the native SDK returns. A failed Samsung Health permission/connect flow therefore reached Dart as success: true with only the error field populated, so a customer app branching on success saw a silent no-op rather than a failure.

Found while investigating ZD-6058 (Samsung Health integration dead on some devices: no permission dialog, no webhook, nothing surfaced to the app).

Changes

android/src/main/java/co/tryterra/terra_flutter_bridge/TerraFlutterPlugin.java

• initConnection forwards the native boolean: map.put("success", success). This matches the four sibling getters in the same file, which already do this.
• initTerra keys off error == null. A passthrough is not available here: Terra.Companion.instance's callback is (TerraManager, TerraError?) with no success flag, and TerraInterface.kt:27-31 force-unwraps a non-null TerraManager even on failure, so terraManager != null would be always-true and would silently reproduce the bug. Every SDK failure branch carries a non-null error and the sole success path is completion(true, null), so error == null is equivalent to the discarded flag.

Rebased onto samsung after 0.9.0-samsung.4 shipped; this releases as 0.9.0-samsung.5. Orthogonal to the 0.0.12 crash fix in 0.9.0-samsung.4: that one stops the init crash when Samsung Health is absent, this one stops a failed init from being reported as a success. A caller needs both to reliably detect and handle a bad Samsung connect.

Behaviour change

Apps that assumed success was always true will now start seeing success: false on genuine failures. That is the point of the fix, but it is visible, hence the CHANGELOG note. error is unchanged. iOS has always behaved this way (SwiftTerraFlutterPlugin.swift:176/180/201), so this brings Android to parity with the contract iOS already ships, and any app that handles iOS correctly already handles this.

Relationship to #19

#19 is the same initConnection one-liner but targets main, and has been open since 12 June. Samsung-tagged releases are published from samsung, so #19 does not reach the affected customer. This PR targets samsung.

main still needs both fixes. #19 covers only initConnection there; the initTerra bug exists on main too and is not covered by any open PR.

Verification

UNVERIFIED ON LIVE. The bug is confirmed by code read, and the fix is a two-line correction to a value that was provably discarded, reviewed against the native SDK's callback contracts. It has not been run against the customer's failing device, and this repo has no harness that can reach the Java bridge (test/terra_flutter_test.dart is an empty stub that mocks the MethodChannel; there is no android/src/test). Adding one would mean new test dependencies, deliberately left out of scope.

The real proof is the customer's next release build on a failing device surfacing an actual Samsung error string instead of nothing.

Follow-up, not in this PR

TerraInterface.kt:29 receives the real success: Boolean from createInstance and throws it away, forwarding only the error. This bridge's error == null is correct only because the SDK never calls completion(false, null) today. Widening that callback to pass the boolean through would make the invariant enforced rather than assumed.

🤖 Generated with Claude Code

[Ant1Miller]

/sfs

[mep-y]

calm

prIQ: 100

[Ant1Miller]

/sfs

[mep-y]

MEP — no new commits since my last review on this PR — nothing to add. push a commit and re-run / sfs if you want another pass.