> For the complete documentation index, see [llms.txt](https://cmp.docs.sirdata.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cmp.docs.sirdata.net/applications-mobiles-sdk-natif/mobile-sdk/logging.md). # 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` — `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. ```kotlin 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. ```kotlin // Android — lié au type de build (avec AGP 8, BuildConfig exige // buildFeatures { buildConfig = true } dans le module de votre app) val config = SirDataCMPConfig.Builder(partnerId, configId) .debugMode(BuildConfig.DEBUG) .build() ``` ```swift // iOS — builds de debug uniquement let config = IosCMPConfig.Builder(partnerId: partnerId, configId: configId) #if DEBUG .debugMode(debugMode: true) #endif .build() ``` 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](/applications-mobiles-sdk-natif/mobile-sdk/troubleshooting.md). Voir aussi [Installation — React Native](/applications-mobiles-sdk-natif/mobile-sdk/react-native-setup.md). ## 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 : ```kotlin // Android — awaitConsentDisplayDecision() suspend : appelez-la depuis une coroutine lifecycleScope.launch { val decision = SirDataCMPApi.awaitConsentDisplayDecision() Log.d("CMP", "display=${decision.shouldDisplay} workflow=${decision.workflow} reason=${decision.reason}") } ``` 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://cmp.docs.sirdata.net/applications-mobiles-sdk-natif/mobile-sdk/logging.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.