{"file": ".trellis/spec/guides/code-reuse-thinking-guide.md", "reason": "Look for repeated Android bridge numeric forwarding patterns that should use typed helpers consistently."}
{"file": ".trellis/tasks/05-12-audit-android-int-long-native-parameter-mismatches-against-sdk-core/prd.md", "reason": "Task scope, confirmed crash, signature findings, and acceptance criteria for the Android int/long mismatch audit."}
# audit android int-long native parameter mismatches against sdk core
## Goal
Audit the Flutter Android bridge managers against the bound SDK core signatures, find places where Flutter `int` values are forwarded with the wrong boxed Java type (`Integer` vs `Long` / `int32`-style expectations), and fix confirmed mismatch risks to prevent more runtime `ClassCastException` failures.
## What I already know
- A real crash was reproduced in `getChannelHistoryMessages` on Android: `java.lang.Integer cannot be cast to java.lang.Long`.
- The fixed plugin call site was `android/src/main/java/io/openim/flutter_openim_sdk/manager/ChannelManager.java`, where `count` was passed via `value(...)` instead of numeric conversion.
- Flutter side sends Dart `int` values through `MethodChannel`, which arrive on Android as boxed Java numbers.
- This repo’s Android bridge currently mixes raw `value(methodCall, key)` and `int2long(methodCall, key)` for numeric parameters.
- iOS already uses typed accessors like `methodCall[int:]`, `methodCall[int32:]`, `methodCall[int64:]`.
- SDK core source is available at `/mnt/d/workspace/go/im_dev/openim-sdk-core` for signature comparison.
-`gomobile`/`gobind` Java bindings map Go `int` and `int64` to Java `long`, while `int32` maps to Java `int`; this is a common source of cross-platform bridge confusion.
## Assumptions (temporary)
- The Android binding layer should match the generated Java API’s expected boxed types exactly enough to avoid reflection/runtime cast failures.
- Some existing `value(...)` calls on numeric args are safe when the generated Java signature expects Java `int`/boxed `Integer`, but unsafe when it expects Java `long`/boxed `Long`.
- The task likely includes both audit and code fixes for confirmed risks, not just reporting.
## Open Questions
- Should this task only fix confirmed Android mismatches found by comparing to SDK core/bound signatures, or also refactor the bridge toward explicit typed helpers (`int32` / `int64`) even for currently-safe call sites?
## Requirements (evolving)
- Compare Android manager numeric forwarding against SDK core signatures and binding behavior.
- Identify confirmed mismatch sites and distinguish them from safe `int32` call sites.
- Fix confirmed mismatch sites with minimal behavior change.
- Summarize findings clearly, including why each changed call needed conversion.
- If a broader pattern is found, capture it in spec/guides to prevent recurrence.
## Acceptance Criteria (evolving)
- [ ] All Android manager numeric parameters that should be passed as Java `Long` are identified and fixed.
- [ ] No confirmed `Integer` → `Long` mismatch remains in audited Android manager methods.
- [ ] Findings are backed by SDK core signature comparison.
- [ ] Any preventive guidance learned from the audit is written back into `.trellis/spec/`.
## Definition of Done (team quality bar)
- Audit completed across Android managers
- Code changes applied only where signature comparison justifies them
- Relevant docs/specs updated if a reusable lesson is found
- Build/test verification run as feasible for the touched layer
## Out of Scope (explicit)
- Changing SDK core public APIs
- Large redesign of the plugin dispatch/reflection mechanism unless separately required
- iOS behavior changes unless needed for parity documentation
@@ -106,7 +106,7 @@ public class ChannelManager extends BaseManager {
newOnBaseListener(result,methodCall),
value(methodCall,"operationID"),
value(methodCall,"channelID"),
value(methodCall,"count"),
int2long(methodCall,"count"),
int2long(methodCall,"sinceSeq")
);
}
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.