fix: Android: webConsents is stale after customConsentGDPR / deleteCustomConsentTo

[cimperator]

Description

On Android, after calling customConsentGDPR (or deleteCustomConsentTo), the returned SPConsent is internally inconsistent:

gdpr.grants (the structured map) is correct — the updated vendor has granted = true.
webConsents is stale — inside gdpr.webConsentPayload, the same vendor still has vendorGrant: false and is missing from customVendorsResponse.consentedVendors.
Since preloadConsent injects webConsents into the WebView, embeds that depend on the vendor keep showing the consent placeholder after the grant — i.e. the consent doesn't appear to persist on WebView reopen, even though the native consent state is updated. iOS is not affected.

Root cause

In SourcePointUnifiedCmpData.kt:

fun SPConsents.toHostAPISPConsent() = HostAPISPConsent(
    gdpr = gdpr?.toHostAPIGDPRConsent(),
    webConsents = this.toWebViewConsentsJsonObject().toString()
)

toWebViewConsentsJsonObject() (from the SourcePoint native SDK) serializes from the SDK's cached state, which doesn't reflect the just-applied custom consent. So gdpr.grants and webConsents are derived inconsistently from the same object.

Proposed fix

Re-derive the webConsentPayload.grants from the authoritative structured grants:

fun SPConsents.toHostAPISPConsent() = HostAPISPConsent(
    gdpr = gdpr?.toHostAPIGDPRConsent(),
    webConsents = this.toWebViewConsentsJsonObject()
        .syncGrantsWith(gdpr?.consent?.grants)
        .toString()
)
private fun JSONObject.syncGrantsWith(grants: Map<String, GDPRPurposeGrants>?): JSONObject {
    if (grants == null) return this
    val gdpr = optJSONObject("gdpr") ?: return this
    val payloadStr = gdpr.optString("webConsentPayload").takeIf { it.isNotEmpty() } ?: return this
    val payload = JSONObject(payloadStr)
    val newGrants = JSONObject()
    val consentedVendors = JSONArray()
    grants.forEach { (vendorId, grant) ->
        newGrants.put(vendorId, JSONObject().apply {
            put("vendorGrant", grant.granted)
            put("purposeGrants", JSONObject(grant.purposeGrants as Map<*, *>))
        })
        if (grant.granted) consentedVendors.put(JSONObject().put("_id", vendorId))
    }
    payload.put("grants", newGrants)
    payload.optJSONObject("customVendorsResponse")?.put("consentedVendors", consentedVendors)
    gdpr.put("webConsentPayload", payload.toString())
    return this
}

This makes customConsentGDPR and deleteCustomConsentTo return a webConsents blob consistent with gdpr.grants, matching the iOS behavior. Ideally the underlying issue should also be reported to SourcePoint so toWebViewConsentsJsonObject() reflects custom consent natively.

[thekorn]

thanks @cimperator ill look into that.
however there is one thing which makes me struggle here with the proposed solution: with the entire implementation of this flutter plugin for source point i tried to be as lean as possible - as few as needed additional biz logic and complexity. at the end i am not owning the source point tech stack.
So the question i am asking myself here is: shouldn't there be either of those two:

• such mangling, or even a new data attribute doing that in the level of the source point sdks - which than in terms of this package is just exposed in some consentWithCustomGrants message?
• Alternatively shouldn't we move this data merging to the flutter layer, either of the package, or the application.

i just want to keep the message api (native <-> flutter) as lean as possible

[cimperator]

I’ve already implemented the merging of this data on the app side and it works. I was wondering if it would be possible to move the logic into the library. If you think it would complicate the implementation more than necessary, let’s leave it as it is and I’ll keep the logic on the app side.

[thekorn]

@cimperator i made a decision:

• i will not implement this in the plugin layer itself
• however ill be providing a "helper function" which will do the merging of the data in flutter land, but still as part of the source point_unified_cmp package.
• clients are free to use this method, but ill document it as "warning: not an official api"
• sure, the general logic will be tested and supported from plugin side, however I cannot guarantee that this api is going to be stable over time (/me not owning the upstream sdks)