docs: mark onNativeMessageReady as not invoked since 7.12.0

[bschmalb-ksta]

Hello — we are a Sourcepoint customer integrating the Android SDK in a new Flutter app. We evaluated rendering the first consent layer in our own UI via the native message API, spent a fair amount of time on it, and eventually concluded that the callback is never invoked. This PR records that so the next person does not repeat the exercise.

This changes no behaviour. It adds a deprecation notice and a note in the guide.

If we have this wrong, please close it and tell us what we missed — we would genuinely rather be wrong here, and we will happily adopt the feature if there is a configuration we have not found.

What we found

SpClient.onNativeMessageReady is declared, documented in NATIVEMESSAGE_GUIDE.md, and described as current on docs.sourcepoint.com, but nothing in the shipped library calls it.

From the published artifact. We pulled cmplibrary-7.15.10.aar from Maven Central, verified the checksum, and disassembled all 245 classes with javap -p -c. Exactly eight SpClient callbacks are invoked anywhere in the artifact:

onSpFinished, onConsentReady, onUIReady, onUIFinished,
onNoIntentActivitiesFound, onMessageInactivityTimeout, onError, onAction

onNativeMessageReady is not among them. It exists only as the interface declaration plus a Kotlin default-implementation bridge whose body is two null checks and a return. No reflective dispatch. NativeMessageController.sendConsent ships with no implementations. 7.15.13 is identical.

From this repository. Call sites under cmplibrary/src/main:

tag	call sites
v7.11.2	3 (all in SpConsentLibImpl.kt)
v7.12.0 and every tag since	0

c6c977ec deleted SpConsentLibImpl.kt, the only class that invoked it, as part of the mobile-core integration in #846. 1f382ac2 removed nat-message-demo from settings.gradle.

Configuration does not reach it either. MessageType has only MOBILE, OTT and LEGACY_OTT, and MessageType.fromMessageSubCategory maps everything outside the three OTT subcategories — including NoticeNative — to MOBILE. The only SPMessageUI implementor in the artifact is SPConsentWebView. So a property configured for a native message is rendered as a web message, with no callback and no error.

iOS is unaffected: onSPNativeMessageReady is still wired in ios-cmp-app at 7.12.10.

Why a PR rather than an issue

Issues are disabled on this repository, so there was no other way to raise it.

Notes for review

• The deprecation message deliberately mirrors the wording already on the neighbouring onMessageReady callback ("Currently this callback is disabled").
• Adding @Deprecated will produce warnings for integrators who still override the method. That is the intent — since 7.15.3 the method has a no-op default body, so there is currently no signal at all that an override is dead code. If your build treats warnings as errors and this is inconvenient, we are happy to reduce it to a KDoc note only.
• We would also value knowing whether the removal was intentional and whether native message support is expected to return, since that determines whether this notice should say "disabled" or "removed".

[atanurdemirci]

Hi Bastian,

native messaging is not supported anymore since we switched to SDK version > 7. We only support the WebView approach going forward, so you'll need to adjust your implementation accordingly.

There's also a Flutter bridge maintained by a client's dev, available here: https://github.com/thekorn/sourcepoint_unified_cmp/

[bschmalb-ksta]

Thanks, that's the confirmation we needed — we're on the WebView approach already.

Two questions:

1. Is it supported to point the mobile SDK at a property of type web? We use the same property our WebView content loads, so both resolve to one consent record, rather than a separate app property with a shared vendor list.
2. Can the mobile SDK's endpoint be overridden? Our web setup uses a first-party CMP subdomain, while the SDK appears to use the default with no override. We assume both reach the same backend and that records key on account, property and UUID rather than hostname.

Separately: the guide and the Native App Messages pages still present native messaging as current — that's what cost us the time here. A short note there would spare the next integrator the same detour.