For the complete documentation index, see llms.txt. This page is also available as Markdown.

Logs

Le SDK n'a pas de mode verbeux, et il n'y a rien à activer. Sur Android, il écrit une ligne quand la configuration est chargée ; pour le reste, il n'écrit une ligne que lorsqu'un point demande votre attention.

Sur Android, cherchez dans Logcat les tags SirDataCMP et SirDataCMPManager :

  • la configuration éditeur chargée (Config loaded successfully), ou son échec de chargement, avec la raison (Config load failed: …), tous deux sous le tag SirDataCMPManager ;

  • une soumission de consentement en échec (Consent submission failed: …) ;

  • TC string generation failed: /consent-string … : malgré son libellé, c'est l'archivage serveur d'un choix enregistré qui a échoué. La chaîne TC elle-même est encodée sur l'appareil et stockée. La ligne s'écrit à l'enregistrement du choix suivant ; getLastTcStringError() renvoie le même message ;

  • une chaîne TC stockée qui n'a pas pu être relue ;

  • un adaptateur de consentement qui n'a pas pu transmettre un choix, sous le nom de l'adaptateur ;

  • un appel à initialize, shutdown ou setCcpaOptOut fait hors du fil principal.

L'échec de chargement de la configuration se lit aussi dans le code : SirDataCMPApi.getInitError() est un StateFlow<String?> — null pendant le chargement et une fois la configuration chargée, le message d'erreur quand un chargement a échoué. Le initialize suivant le remet à zéro.

lifecycleScope.launch {
    SirDataCMPApi.getInitError().collect { error ->
        if (error != null) Log.w("CMP", "Configuration failed to load: $error")
    }
}

Sur iOS, cherchez dans la console Xcode les lignes qui commencent par [CMP] : les mêmes échecs d'adaptateur, violations du fil principal et chaîne TC stockée illisible, plus une commande TCF ou GPP appelée hors du fil principal. Un échec d'initialisation n'est pas journalisé sur iOS : lisez-le avec IosCMPApi.shared.getInitError() — nil pendant le chargement et une fois la configuration chargée, le message d'erreur quand un chargement a échoué — une fois que getConsentState() a quitté LOADING. En 2.0.0, le SDK le renseigne sur le fil principal juste après ce changement : il peut donc valoir encore nil à l'instant précis où l'état passe à READY ; la prochaine version le renseigne avant.

debugMode

debugMode ne change pas ce qui est journalisé. Il fait lever une exception à un appel de initialize, shutdown ou setCcpaOptOut fait hors du fil principal, au lieu de seulement le journaliser, pour que le défaut apparaisse dans votre propre build de debug. Ne l'activez qu'en debug : le SDK ne regarde pas le type de build, et sur iOS l'exception termine l'app.

React Native : ne passez pas debugMode: true sur Android en 2.0.0 et 2.0.1. Le pont appelle initialize hors du fil principal : avec debugMode, la promesse est rejetée avec E_INIT — voir Dépannage. Voir aussi Installation — React Native.

Lire la décision d'affichage

Si la bannière ne s'affiche pas, l'objet de décision vous le dit avant même d'ouvrir un log :

Une fenêtre de capping active, un consentement stocké qui couvre encore toutes les finalités actives, ou un RGPD non applicable sont autant de raisons normales pour qu'une bannière ne s'affiche pas.

Le consentement n'est pas une donnée à journaliser

La chaîne TC et les champs de bits par finalité décrivent les choix d'un utilisateur identifié. Leur place est dans les logs de debug pendant le développement — pas dans un outil de crash reporting ni dans un événement analytics en production.

Mis à jour

Ce contenu vous a-t-il été utile ?