platform-channel-debug

name	platform-channel-debug
description	Debug communication issues between C# code and native Android/iOS implementations in the AppsFlyer Unity plugin.

Platform Channel Debug

Use this skill when a C#-to-native or native-to-C# flow is not working correctly.

Goal

Find where the Unity native bridge is broken between C#, the platform-specific wrappers, and native SDK integration.

Workflow

1. Identify the failing flow: C# → native method call | native → C# callback | initialization/registration issue.
2. Trace the path end-to-end:
   • C# AppsFlyer.cs → AppsFlyerAndroid.cs (AndroidJavaClass) | AppsFlyeriOS.cs ([DllImport])
   • → AppsFlyerAndroidWrapper.java | AppsFlyeriOSWrapper.mm
   • → Native AppsFlyer SDK callback
3. Verify argument and payload mapping.
4. Check for mismatches: method names, argument types, platform guards (#if UNITY_IOS / #if UNITY_ANDROID), null handling, callback thread assumptions.
5. Identify the first broken point in the chain.
6. Recommend the smallest safe fix.

What to Check

• AppsFlyer.cs — public API call and platform delegation
• AppsFlyerAndroid.cs — AndroidJavaClass/AndroidJavaObject call
• AppsFlyeriOS.cs — DllImport extern function signature
• AppsFlyerAndroidWrapper.java — Java bridge method signature
• AppsFlyeriOSWrapper.mm — Objective-C++ bridge function signature
• Callback propagation back to C# (Unity main thread safety)
• Assembly definition boundaries

Output Format

Return:

• Failing scenario
• Expected flow
• Actual break point
• Evidence
• Suspected root cause
• Recommended fix
• Validation steps

Rules

• Do not say the issue is in native SDK behavior unless the bridge has been verified first.
• Unity requires callbacks to be dispatched to the main thread — verify threading.
• Prefer tracing the real execution path over guessing.
• Separate confirmed breakage from hypotheses.
• If evidence is incomplete, say needs verification.