Cosa potrebbe contenere la segnalazione di arresto anomalo di un'app diario?
La segnalazione di arresto anomalo (crash report) di un'app diario può includere dettagli tecnici come la traccia dello stack del crash, le versioni del dispositivo e dell'app, timestamp ed eventi di diagnostica contigui. A seconda del sistema operativo, del servizio di segnalazione e della configurazione dell'app, può contenere anche log, allegati o dati di riproduzione della sessione (session replay) che espongono i contenuti inseriti o visualizzati nell'app. Una segnalazione non contiene automaticamente le voci del diario in ogni situazione, ma non è prudente dare per scontato che non lo faccia mai. Esamina il report specifico e la configurazione dell'app prima di condividerlo.
Cosa mostra una segnalazione di arresto anomalo standard?
Uno stack trace elenca le chiamate di funzione associate all'arresto anomalo. Aiuta gli sviluppatori a individuare il percorso del codice interessato, ma di solito, da solo, non spiega l'intero contesto né dimostra cosa stesse facendo l'utente. I report possono anche identificare le versioni dell'app e del sistema operativo, il modello del dispositivo, l'orario del crash e altri dettagli dell'ambiente. Apple descrive i crash report come registrazioni dello stato dell'app al momento dell'arresto anomalo e raccomanda di analizzare il report completo del sistema operativo; le sue linee guida identificano campi quali informazioni sul dispositivo, sull'app e sul sistema operativo. Consulta la [guida all'analisi dei crash report di Apple](https://developer.apple.com/documentation/xcode/analyzing-a-crash-report).
Il formato del report dipende dalla sua origine. I crash report di Apple raccolti tramite Xcode e un bug report di Android sono artefatti diversi. La guida ufficiale di Android indica che un bug report può contenere log di dispositivo, stack trace, output di diagnostica dei servizi di sistema, log di errore e messaggi di sistema provenienti da app che utilizzano la classe `Log` di Android. Si tratta di un ambito più ampio rispetto a un semplice record di arresto anomalo. I contenuti di un singolo report dipendono comunque da ciò che è stato raccolto e incluso. Consulta la [guida di Android all'acquisizione e alla lettura dei bug report](https://developer.android.com/studio/debug/bug-report).
Il report può includere il testo del diario?
Può accadere, in determinate configurazioni, ma la semplice presenza di un crash report non certifica che esso includa il testo delle annotazioni. La questione chiave risiede in ciò che l'app registra insieme al crash e in ciò che il formato del report acquisisce.
Ad esempio, gli sviluppatori dell'app potrebbero aggiungere messaggi di log diagnostici o eventi personalizzati. Se tali messaggi includono una voce del diario, un titolo, un termine di ricerca o un testo copiato da un editor, queste informazioni potrebbero viaggiare insieme all'evento. Sentry descrive i breadcrumb come una traccia di eventi che precedono un problema; ciascuno di essi può contenere un messaggio e dati strutturati arbitrari. I breadcrumb possono essere raccolti automaticamente tramite integrazioni abilitate o aggiunti dall'app. Consulta la [documentazione sui breadcrumb di Sentry](https://docs.sentry.io/product/issues/issue-details/breadcrumbs/). Anche i bug report di Android includono i log dei messaggi di sistema, che potrebbero contenere messaggi scritti dalle app. Nessuna di queste circostanze implica che ogni app registri testi privati: tutto dipende dall'implementazione e dalla configurazione dell'app.
Cosa sono log, breadcrumb, allegati e replay?
Questi termini si riferiscono a tipi distinti di dati diagnostici. I log sono messaggi registrati dall'app o dal sistema. I breadcrumb sono una sequenza selezionata di eventi che precedono un errore, e possono includere timestamp, categorie, messaggi e dati chiave-valore. Entrambi possono rivelare un contesto maggiore rispetto a un semplice stack trace, a seconda di ciò che l'app registra.
Gli allegati sono file inviati insieme a un evento, come un file di log, uno screenshot o un dump di crash. Sentry osserva che i minidump nativi possono contenere materiale sensibile come variabili d'ambiente, percorsi locali o rappresentazioni in memoria dei campi di inserimento. La sua documentazione afferma che i minidump vengono utilizzati per creare eventi e scartati per impostazione predefinita, ma possono essere archiviati come allegati se tale impostazione è abilitata; specifica inoltre che gli allegati non sono coperti dall'offuscamento dei dati (data scrubbing) di Sentry. Consulta la documentazione di Sentry sui [dati di crash](https://docs.sentry.io/platforms/native/guides/crashpad/data-management/data-collected/) e sugli [allegati](https://docs.sentry.io/platforms/native/guides/crashpad/enriching-events/attachments/).
La registrazione della sessione (session replay) è una funzionalità separata e facoltativa, non un componente standard di ogni crash report. La documentazione di Sentry sul replay JavaScript descrive una ricostruzione in formato video dell'attività nel browser, compresi lo stato del DOM e le interazioni. Precisa che l'SDK maschera per impostazione predefinita il testo del DOM, le immagini e l'input dell'utente, offrendo al contempo opzioni di configurazione. Le impostazioni di mascheramento e le piattaforme supportate sono aspetti cruciali: non presumere che il contenuto del diario sia visibile o protetto senza aver prima verificato la configurazione effettiva del provider e della privacy. Consulta la [guida di Sentry a JavaScript Session Replay](https://docs.sentry.io/platforms/javascript/session-replay/).
Cosa dovresti verificare prima di condividere una segnalazione?
Utilizza questa checklist sul file effettivo o sull'anteprima del report e consulta la documentazione sulla privacy dell'app o del fornitore qualora i contenuti della segnalazione non siano chiari:
Questa checklist è una guida editoriale pratica destinata a chi usa un'app diario per esaminare una segnalazione prima dell'invio. Si distingue dalle istruzioni per i creatori dell'app: gli sviluppatori gestiscono le proprie impostazioni di log, replay e allegati, e dovrebbero documentare ciò che tali funzionalità raccolgono, valutando attentamente se i campi diagnostici possano contenere contenuti inseriti dall'utente.
Perché le segnalazioni possono differire a seconda dell'app e del dispositivo?
I sistemi operativi generano formati di segnalazione e percorsi di raccolta differenti; gli sviluppatori possono inoltre ricorrere a un SDK di terze parti con una configurazione personalizzata. Apple specifica che i crash report di App Store e TestFlight sono accessibili tramite Xcode, mentre altri log di diagnostica potrebbero dover essere trasferiti direttamente dal dispositivo. Android distingue tra bug report completi e segnalazioni di crash fornite tramite servizi quali Google Play o Firebase. Le impostazioni del provider possono ulteriormente determinare quali eventi, breadcrumb, allegati o dati di replay vengano acquisiti e archiviati. Fai riferimento all'informativa sulla privacy dell'app e al report specifico per valutare il singolo caso, evitando di dare per scontato che ogni servizio trasmetta gli stessi campi.