Dev/delivery 124647/rpc implementation

[af-obodovskyi]

Summary

Migrates the AppsFlyer Unity plugin's core API from the legacy AndroidJavaClass/DllImport native bridges to a unified, schema-driven RPC transport. Every public method and parameter is now aligned to a canonical JSON schema (appsflyer-plugins-rpc-schema.json) shared across platforms, replacing ad-hoc per-platform bridging code with a single dispatch path (AppsFlyerRPCClient → Fire/Query).

What changed

C# plugin API (Assets/AppsFlyer/AppsFlyer.cs)

• Every public method now routes through the RPC transport instead of AndroidJavaClass/P/Invoke calls; removed the old native bridge interfaces (IAppsFlyerAndroidBridge, IAppsFlyerIOSBridge, IAppsFlyerNativeBridge) and platform delegation classes (AppsFlyerAndroid.cs, AppsFlyeriOS.cs).
• Fixed a set of schema-alignment bugs found during a Unity-vs-schema-vs-RN audit:
  • isSessionReady() now performs a live RPC query instead of returning a stale client-cached flag.
  • enableDebug/setDisableNetworkData parameter names renamed to match the schema's canonical public contract (enabled / isDisable).
  • setLogLevel now accepts case-insensitive input (schema's canonical values are lowercase) and uppercases before firing the wire RPC.
  • generateInviteLink now remaps the canonical referrerCustomerId key to Android's wire key customerId internally, instead of requiring callers to know the platform-specific key.
  • updateServerUninstallToken (iOS) now hex-encodes the device token instead of Base64, matching the schema's required wire format.

Android native bridge

• Migrated AppsFlyerRPCBridge and PurchaseRevenueBridge from Java to Kotlin.
• Dependency/gradle updates: added play-services-ads-identifier (fixes a ClassNotFoundException reading GAID), and temporarily disabled purchase-connector due to an AGP8 manifest-namespace conflict with af-android-sdk (needs an upstream repackage before re-enabling).

iOS native bridge

• Added a Swift RPC wrapper (AppsFlyerRPCWrapper.swift) replacing the old Obj-C++ RPC wrapper.

Sample/test app

• Added AppsFlyerAPITester.cs — a UI-driven manual test harness covering the full RPC API surface.
• Added ATTPermissionRequest.mm for iOS App Tracking Transparency prompts; removed the old AppsFlyerOpenURL.mm.
• Updated Android manifest/gradle templates and QATestScript.cs for the new bridge.

Removed

• Stale prebuilt binaries that shouldn't have been in source control: the macOS bundle (test-app/Assets/AppsFlyer/Mac/...) and unitywrapper.aar.

Out of scope / explicitly excluded

• appsflyer-plugins-rpc-schema.json is intentionally not included in this MR.
• handleOpenUrl, handleLaunchOptions, continueUserActivity were audited against the schema (which flags them internal-only) but are kept public and unchanged — they're documented, tested, and tied to the native AppsFlyerAttribution handling; removing them would be a breaking change with no clear benefit.
• Build/run-generated artifacts (Xcode export, APKs, Editor-version churn, EDM4U-resolver-generated settings, backup files) were kept out of version control.

Testing

• Assets/AppsFlyer/Tests/Tests_Suite.cs updated for the new RPC-layer assertions.
• Manual verification recommended via the new AppsFlyerAPITester harness in the sample app on both platforms, particularly: isSessionReady (live query behavior), generateInviteLink (Android key remap), and updateServerUninstallToken (iOS hex encoding).
• No native SDK behavior changes required — confirmed via RPC mapping docs that both Android and iOS already implement the relevant RPC methods correctly.

[pazlavi]

The new TryGetConnector/TryCallStatic/WarnConnectorUnavailable guard correctly converts the disabled Android purchase-connector dependency from an unguarded NoClassDefFoundError crash into a logged warning, but has three residual gaps: (1) only the warning is deduplicated via _connectorUnavailableWarned — the new AndroidJavaClass(...) lookup itself is retried and re-fails on every subsequent call, paying needless JNI/exception overhead each time; consider caching the failure state, not just the warned flag. (2) _connectorUnavailableWarned is a static with no reset hook, a latent test-isolation hazard for whoever adds coverage next (there is currently none for this guard at all, and it can't be exercised by the Editor-based playmode suite since it's gated on UNITY_ANDROID && !UNITY_EDITOR). (3) since the entire Purchase Connector Android surface becomes a silent runtime no-op with no compile-time signal, consider marking the Android-facing entry points [Obsolete] (pointing at the AGP8 namespace-collision tracking issue) so integrators get a build-time warning instead of discovering the regression only when a purchase event never reports.

[Obsolete("Android Purchase Connector is temporarily non-functional (AGP8 namespace collision " +
          "with af-android-sdk, see AppsFlyerDependencies.xml). Track upstream fix before relying on this.")]
public static void init(MonoBehaviour unityObject, Store s) { ... }

References:

• Microsoft: ObsoleteAttribute
• NUnit test isolation guidance

[pazlavi]

Per the native SDK's own docs for the onPause RPC method: "For Cocos2dx platform only — Cocos2dx has its own applicationDidEnterBackground event. Therefore onPause will be called from C++ by JNI." This is a Cocos2dx-specific bridging requirement, not a Unity one — Unity already has its own reliable OnApplicationPause MonoBehaviour callback, so there is no engine-level gap for this RPC call to work around on the Unity side. The existing doc comment on this method (in AppsFlyer.cs, unchanged by this diff) misattributes the reason for keeping it, claiming Unity itself doesn't reliably deliver Android Activity foreground/background transitions — that justification belongs to Cocos2dx, not Unity. Recommend deleting OnApplicationPause/the onPause FireAsync call from this Unity plugin entirely rather than carrying over Cocos2dx-oriented boilerplate; confirm with the native SDK team that Unity's own Activity lifecycle already reports foreground/background correctly without this call before removing it.

[pazlavi]

AppsFlyerRPCClient.instance.InitBridge(...) is only ever called from inside init() (here and at line 92 for iOS/macOS), which means any RPC call made before AppsFlyer.init(...) has actually run has no native→Unity callback route wired yet. Confirmed this isn't a theoretical gap: _rpcBridge (AppsFlyerRPCClient.cs:167) is a static readonly field loaded via TryLoadAndroidBridge() at class-load time, independent of InitBridge — so the RPC dispatch machinery (Execute/ExecuteFire → fireJson/executeJson) is already available before init() ever runs, but responses/events routed back through the callbackObjectName channel InitBridge wires (_rpcBridge.CallStatic("init", callbackObjectName) on Android, _setRPCEventHandler on iOS) have nowhere to go until init() calls it. InitBridge should be called unconditionally as early as possible — e.g. from a static constructor or a [RuntimeInitializeOnLoadMethod] hook — rather than being gated behind init(), so the callback route exists as soon as the plugin loads regardless of call order.

[pazlavi]

The SDK mixes callback-delivery mechanisms and, in two cases, uses the wrong kind of mechanism for what the callback actually represents. Correct split per product intent (see the Flutter plugin's registerConversionListener for the reference shape: https://github.com/AppsFlyerSDK/appsflyer-flutter-plugin/blob/master/lib/src/appsflyer_sdk.dart): long-lived/recurring results — conversion data (onConversionDataSuccess/onConversionDataFail), deep link (OnDeepLinkReceived), session ready (OnSessionReady) — should be delivered via the register-function/event pattern; one-time results — request response, in-app/purchase-validation response, and generate-invite-link — should be delivered via an awaitable return value.

Current state against that split:

• OnDeepLinkReceived (line 991) is long-lived but wired backwards: it's a plain C# event whose add accessor (line 993, add { onDeepLinkReceived += value; registerDeepLinkListener(); }) triggers the RPC subscription as a side effect of subscribing via +=. Per the Flutter reference, the listener should instead be supplied directly as a parameter to registerDeepLinkListener(callback) — the register function itself is the API surface, not a += event with a hidden side effect in its accessor.
• OnSessionReady (line 997) is a plain C# event (add/remove, no side-effecting accessor) — likely fine as-is since session-ready has no separate native "subscribe" RPC call to trigger, but worth confirming with the same register-function shape for consistency if one gets added later.
• onConversionDataSuccess/onConversionDataFail (routed inside onRPCEvent, line ~1053) are long-lived by nature but still delivered via the legacy GameObject.SendMessage(eventType, dataStr, ...) idiom, and registerConversionListener() (line 409) takes no callback parameter at all — should be migrated to a single register function that takes the success/fail listeners as parameters, matching Flutter's registerConversionListener({onConversionDataSuccess, onConversionDataFail}).
• OnRequestResponse (line 979) and OnInAppResponse (line 985) are one-time results (an ack for a single track/request call, and a single purchase-validation response) but are currently implemented as long-lived C# events — this is backwards; they should instead be delivered as the awaitable return value of the call that triggers them (e.g. validateAndLogInAppPurchase at line 940/960 already returns Awaitable — OnInAppResponse firing alongside it as a second, separately-subscribed delivery path is redundant/conflicting).
• generateInviteLink (this line) is a one-time result but still uses the legacy GameObject.SendMessage("onInviteLinkGenerated"/"onInviteLinkGeneratedFailure", ...) wrapper instead of its already-correct awaitable twin, generateInviteLinkAsync (line 564).

Recommend: for deep link and conversion data, make the register function itself accept the listener(s) as parameters (registerDeepLinkListener(callback), registerConversionListener(onSuccess, onFail)) rather than exposing a separate += event; remove OnRequestResponse/OnInAppResponse as public events and instead surface their payloads as awaitable return values from the triggering calls; drop the SendMessage-based generateInviteLink wrapper in favor of generateInviteLinkAsync.

[pazlavi]

FireAsync is declared async Awaitable but its body is a single synchronous call (AppsFlyerRPCClient.instance.ExecuteFire(...)) with no await — the compiler synthesizes an already-completed-or-faulted Awaitable with nothing actually asynchronous happening. The doc comment above it (lines 23–30) correctly explains the consequence: an exception is only visible to a caller who awaits the result; a caller who doesn't gets the old "unobserved exception" silence. Every call site inside AppsFlyer.cs does await FireAsync(...), but nothing in the public API prevents an integrator from calling AppsFlyer.init(...)/AppsFlyer.start()/any other Awaitable-returning method without await — a very easy mistake coming from the pre-migration void-returning API — and on a bridge-load failure (e.g. IsBridgeAvailable == false) or any other RPC exception, that caller would get silent failure with only the new Debug.LogError path (which only covers the bridge-missing case, not a general RPC exception) to notice anything went wrong.

Recommend: catch and log inside FireAsync itself, the same way the old Fire() helper it replaced did, so the safety net doesn't depend on the caller choosing to await. The async Awaitable signature can stay (for call-site consistency with the other RPC methods) — the fix is just to not let an unobserved fault be the only failure path:

private static async Awaitable FireAsync(string method, Dictionary<string, object> parameters = null)
{
    try
    {
        AppsFlyerRPCClient.instance.ExecuteFire(method, parameters);
    }
    catch (Exception e)
    {
        AFLog(method, "RPC error: " + e.Message);
    }
}

References:

• C# async/await — exceptions in async void vs Task

[pazlavi]

getAppsFlyerUID()'s doc comment is the only synchronous getter still warning that calling it "deadlocks" on iOS's main thread. isSessionReady() and getSdkVersion() were already updated (in this diff) to the accurate "may block up to 5s" wording, reflecting that AppsFlyerRPCWrapper.swift's _afExecuteJson no longer hops through MainActor — it's a bounded rpcQueue-serialized semaphore wait now, not a deadlock. Leaving this one getter's comment stale will send integrators looking for a workaround to a problem that was fixed in this same commit.

References:

• Keep documentation in sync with source of truth

[pazlavi]

unregisterConversionListener() and the equivalent unregisterDeeplinkListener() (line 494) only fire the native RPC unregister call — neither one nulls the corresponding static callback field (onConversionDataSuccessCallback/onConversionDataFailCallback/onDeepLinkListenerCallback). After calling either, native stops delivering events, but the C# lambda reference stays alive in a static field for the lifetime of the process, keeping alive whatever it closes over (a MonoBehaviour, a scene object, a UI element) well past scene teardown — a static-lifetime delegate leak. Contrast with onSessionReady, which correctly clears its subscription via remove { onSessionReady -= value; }.

public static async Awaitable unregisterConversionListener()
{
#if UNITY_ANDROID
    await FireAsync("unregisterConversionListener");
#endif
    onConversionDataSuccessCallback = null;
    onConversionDataFailCallback = null;
}

References:

• .NET: static fields and GC roots

[pazlavi]

generateInviteLinkAsync's catch block only catches the base Exception type, so when native returns an RPC-level error, the structured AppsFlyerRPCException.Code/.Details are discarded — the caller only ever sees null back plus a log line. QueryValidateAndLogAsync (added in this same diff, for validateAndLogInAppPurchase) does this correctly: it catches AppsFlyerRPCException first to preserve .Details/.Message, then falls back to bare Exception. Callers of generateInviteLinkAsync can't distinguish a missing OneLink template from a network timeout from a malformed parameters dictionary — all three collapse to the same null.

Separately: generateInviteLinkAsync should be renamed to generateInviteLink now that the old fire-and-forget SendMessage-based generateInviteLink is gone and there's only one method left for this call.

References:

• Exception handling: catch specific types before general ones

[pazlavi]

fireJson's not-initialized path logs the full, unredacted $jsonRequest via Log.w. This is the serialized RPC request body — for methods like setCustomerUserId, logEvent/logAdRevenue (with purchase values), or setPhoneNumber/PII-bearing setters, that payload can contain customer identifiers and revenue data. Logcat output on a production device is not a safe sink for this — persisted device logs, bug-report captures, or a rooted/ADB-connected device can all read it. Redact or omit the payload from this log line (log the RPC method name only, not the full params).

References:

• OWASP MASVS: Sensitive data should not be logged

[pazlavi]

validateAndLogInAppPurchase is split into two method overloads distinguished only by parameter type — (AFPurchaseDetailsAndroid details, ...) (line 960) and (AFSDKPurchaseDetailsIOS details, ...) (line 982) — each independently gated by its own #if UNITY_ANDROID / #if UNITY_IOS || UNITY_STANDALONE_OSX block, and each returning null on the "wrong" platform. This is overloading standing in for what should be a single abstraction: AFPurchaseDetailsAndroid and AFSDKPurchaseDetailsIOS describe the same domain concept (a purchase to validate) but share no common type, so adding a third platform means adding a third overload rather than a third implementation of an existing contract — a SOLID (Open/Closed) violation. AFSDKValidateAndLogResult (the shared return type both overloads already converge on via QueryValidateAndLogAsync) should likewise be defined against an interface rather than as a single concrete class, so the result contract is explicit and not just an accident of both overloads happening to call the same private helper today.

Recommend: introduce a common purchase-details interface (e.g. IAFPurchaseDetails) implemented by AFPurchaseDetailsAndroid and AFSDKPurchaseDetailsIOS, and collapse the two overloads into one validateAndLogInAppPurchase(IAFPurchaseDetails details, Dictionary<string, string> additionalParameters) that dispatches to the platform-specific payload-building logic internally (or via a small per-platform strategy), rather than via overload resolution on the caller's static type. Define AFSDKValidateAndLogResult against a corresponding result interface for the same reason.

References:

• SOLID: Open/Closed Principle

[pazlavi]

Shipping both a synchronous and an *Async twin for the same underlying RPC call (isSessionReady()/isSessionReadyAsync() here, and the same pattern repeated for getSdkVersion, getAppsFlyerUID, getOutOfStore, isPreInstalledApp, getAttributionId, getHostName, getHostPrefix, isStopped) is redundant API surface — every one of these pairs hits the same native call, just via Query (blocking) vs QueryAsync (background-thread hop). Recommend converging on a single pattern without an Async suffix in the method name (i.e. every getter is simply awaitable), rather than maintaining two names, two doc comments, and two sets of tests per getter going forward.

[pazlavi]

This is the PR's headline iOS fix (resolving a "Library not loaded" dyld crash by embedding AppsFlyerLib.framework/PurchaseConnector.framework into the app bundle), but the embed step references the file at "Frameworks/" + frameworkFileName relative to BUILT_PRODUCTS_DIR. The surrounding comment justifies this by analogy to how Unity embeds UnityFramework.framework — but that framework is a genuine Xcode target product built directly into BUILT_PRODUCTS_DIR, whereas AppsFlyerLib.framework/PurchaseConnector.framework here are Swift Package Manager package library products consumed by the main target. Xcode's build system places package-library framework products under BUILT_PRODUCTS_DIR/PackageFrameworks/, not BUILT_PRODUCTS_DIR/Frameworks/ — a well-documented SPM/Xcode integration gotcha (see the referenced Firebase issue). If that's the case here, this embed step silently references a file that doesn't exist at the assumed path, and the exact crash this PR sets out to fix would persist (or the build fails outright with a missing-file error).

This needs to be verified against an actual Xcode build (inspect the generated project's DerivedData/.../Build/Products/<config>-iphoneos/ output) before merge — it's the difference between this PR's central fix working or not.

References:

• firebase-ios-sdk#9006 — "Library not loaded" with SPM PackageFrameworks directory

[pazlavi]

AddCopyFilesBuildPhaseBeforeTargetPostprocess(mainTarget, "Embed Frameworks", "", "10") unconditionally creates a new copy-files build phase in memory every run, before the per-file idempotency check (the raw-text scan a few lines below) has a chance to decide anything. It's currently masked because the write (proj.WriteToFile) is skipped whenever changed stays false, but there's no lookup-by-name for an existing "Embed Frameworks" phase — on any build where at least one framework still needs embedding (first build, or a project regenerated fresh), and on any future build with partially-persisted state from an earlier incremental build, this can end up persisting a second, duplicate "Embed Frameworks" phase. Two same-named copy-files phases targeting overlapping content is a known source of Xcode "Multiple commands produce..." build failures.

Recommend looking up an existing "Embed Frameworks" PBXCopyFilesBuildPhase by name first (via proj.GetAllBuildPhasesForTarget or similar) and reusing it, rather than assuming none exists.

References:

• Unity PBXProject API reference

[pazlavi]

This step (and its code sample at line 139 calling AppsFlyer.waitForATTUserAuthorizationWithTimeoutInterval(60)) documents an API that no longer exists — confirmed via Assets/AppsFlyer/Tests/Tests_Suite.cs:566, which asserts typeof(AppsFlyer).GetMethod("waitForATTUserAuthorizationWithTimeoutInterval") is null with the comment "confirmed out of scope." The sample app's own new code (QATestScript.cs:164) says outright: "This replaces waitForATTUserAuthorizationWithTimeoutInterval, which no longer exists in this plugin version... despite still being documented." A developer following this guide gets a compile error. docs/API.md:1494-1507 has the identical stale entry, and the removal isn't listed in CHANGELOG.md's breaking-changes bullet either.

Recommend replacing this step with guidance to request ATT authorization directly (e.g. via a small native call) and pointing to QATestScript.cs's RequestATTThenStart() as a reference implementation, removing the stale docs/API.md entry, and adding the removal to CHANGELOG.md's breaking-changes list.

References:

• Keep a Changelog — Removed section

[pazlavi]

This section documents only isStoppedAsync(), omitting the synchronous isStopped() twin that every other getter on this page documents alongside its *Async counterpart. More importantly, it omits a real platform limitation visible in the implementation's own doc comment (AppsFlyer.cs:888-889): there is no iOS RPC method for isStopped at all, so on iOS this always returns false regardless of actual SDK state — a silent wrong-answer risk for any integrator who checks this on iOS expecting it to reflect stop().

Note: AppsFlyer.cs:134 (checked, pending resolution) recommends collapsing the isStopped()/isStoppedAsync() sync/*Async duplication — and the same pattern across getSdkVersion, getAppsFlyerUID, isSessionReady, getOutOfStore, isPreInstalledApp, getAttributionId, getHostName, getHostPrefix — down to a single awaitable method per getter. If that's adopted, this doc fix applies to whichever single method survives rather than to an *Async-suffixed twin specifically; the missing-sync-signature half of this finding becomes moot, but the iOS-only caveat still needs documenting either way.

Recommend documenting both signatures together for now (matching the page's own convention) and adding an explicit "Android only — always returns false on iOS" note, revisiting once the sync/async consolidation in AppsFlyer.cs:134 is decided.

References:

• Keep a Changelog — documenting behavioral changes

[pazlavi]

Inline comment on Assets/AppsFlyer/AppsFlyerConsent.cs:60 (line not in diff — posted as general comment)

ForGDPRUser(...)/ForNonGDPRUser() are marked [Obsolete(...)] but still present and still what docs/BasicIntegration.md's "Manually collect consent data" examples (lines 220, 233) teach integrators to use, instead of the recommended new AppsFlyerConsent(isUserSubjectToGDPR:, hasConsentForDataUsage:, hasConsentForAdsPersonalization:, hasConsentForAdStorage:) constructor. This plugin version is already a major, breaking release — CHANGELOG.md's v7.0.1 entry states plainly "No backward-compatible aliases" for the other renamed APIs (initSDK→init, startSDK→start, etc.) — so keeping these two obsolete-but-functional methods around is inconsistent with that policy: a genuinely deprecated, superseded API should be removed now rather than carried forward with a warning into the next major version.

Recommend removing ForGDPRUser(...) and ForNonGDPRUser() from AppsFlyerConsent.cs in this release, updating both docs/BasicIntegration.md consent examples to use new AppsFlyerConsent(...) instead, and adding the removal to CHANGELOG.md's breaking-changes list alongside the other API renames.

References:

• Keep a Changelog — Removed section