¿Qué puede contener el informe de bloqueo de una aplicación de diario?
El informe de bloqueo de una aplicación de diario puede incluir detalles técnicos como la traza de la pila de llamadas (stack trace), versiones del dispositivo y de la aplicación, marcas de tiempo y eventos de diagnóstico cercanos. Según el sistema operativo, el servicio de informes y la configuración de la aplicación, también podría incluir registros, archivos adjuntos o datos de repetición de sesión (session replay) que expongan contenido introducido o mostrado en la app. Un informe no contiene automáticamente las entradas del diario en todos los casos, pero tampoco es seguro asumir que nunca lo hace. Revise el informe concreto y cómo está configurada la aplicación antes de compartirlo.
¿Qué muestra un informe de bloqueo estándar?
Una traza de la pila (stack trace) enumera las llamadas a funciones asociadas con el bloqueo. Ayuda a los desarrolladores a localizar la ruta de código implicada, pero por sí sola no suele explicar todas las circunstancias ni demostrar qué estaba haciendo el usuario. Los informes también pueden identificar las versiones de la aplicación y del sistema operativo, el modelo del dispositivo, la hora del bloqueo y otros detalles del entorno. Apple describe los informes de bloqueo como registros del estado de la aplicación en el momento de un fallo y recomienda analizar el informe completo del sistema operativo; su guía identifica campos como información del dispositivo, de la app y del SO. Consulte la [guía de análisis de informes de bloqueo de Apple](https://developer.apple.com/documentation/xcode/analyzing-a-crash-report).
El formato del informe depende de su origen. Los informes de bloqueo de Apple recopilados a través de Xcode y un informe de errores (bug report) de Android son elementos distintos. La guía oficial de Android indica que un informe de errores puede contener registros del dispositivo, trazas de la pila, salidas de diagnóstico de servicios del sistema, registros de errores y mensajes del sistema de aplicaciones que utilizan la clase `Log` de Android. Eso abarca mucho más que un registro exclusivo de bloqueo. El contenido de un informe individual sigue dependiendo de lo que se haya recopilado e incluido. Consulte la [guía de Android para capturar y leer informes de errores](https://developer.android.com/studio/debug/bug-report).
¿Puede el informe incluir el texto del diario?
Puede hacerlo, bajo ciertas configuraciones, pero la mera existencia de un informe de bloqueo no determina que incluya el texto de las entradas. La cuestión clave es qué registra la aplicación junto con el fallo y qué captura el formato del informe.
Por ejemplo, los desarrolladores de la aplicación pueden añadir mensajes de registro de diagnóstico o eventos personalizados. Si esos mensajes incluyen una entrada del diario, un título, un término de búsqueda o texto copiado de un editor, esa información podría enviarse con el evento. Sentry describe los rastros de migas de pan (breadcrumbs) como un historial de eventos previo a un problema; cada uno puede tener un mensaje y datos estructurados arbitrarios. Los breadcrumbs pueden recopilarse automáticamente a través de integraciones habilitadas o ser añadidos por una aplicación. Consulte la [documentación de breadcrumbs de Sentry](https://docs.sentry.io/product/issues/issue-details/breadcrumbs/). Los informes de errores de Android también incluyen registros de mensajes del sistema, que pueden contener mensajes escritos por las aplicaciones. Ninguno de estos hechos significa que todas las aplicaciones registren texto privado: eso depende de la implementación y configuración de la app.
¿Qué son los registros, breadcrumbs, archivos adjuntos y repeticiones de sesión?
Estos términos se refieren a tipos distintos de datos de diagnóstico. Los registros (logs) son mensajes guardados por la aplicación o el sistema. Los breadcrumbs son una secuencia seleccionada de eventos que conducen a un error, y pueden incluir marcas de tiempo, categorías, mensajes y datos clave-valor. Ambos pueden revelar más contexto que una traza de la pila, dependiendo de lo que registre la aplicación.
Los archivos adjuntos son ficheros que se envían junto con un evento, como un archivo de registro, una captura de pantalla o un volcado de memoria de bloqueo (crash dump). Sentry señala que los minivolcados (minidumps) nativos pueden contener material confidencial como variables de entorno, rutas locales o representaciones en memoria de campos de entrada de texto. Su documentación indica que los minidumps se utilizan para crear eventos y se descartan por defecto, pero pueden almacenarse como archivos adjuntos si esa opción está activada; también menciona que los archivos adjuntos no están cubiertos por la depuración de datos (data scrubbing) de Sentry. Consulte la documentación de Sentry sobre [datos de bloqueo](https://docs.sentry.io/platforms/native/guides/crashpad/data-management/data-collected/) y [archivos adjuntos](https://docs.sentry.io/platforms/native/guides/crashpad/enriching-events/attachments/).
La repetición de sesión (session replay) es una función independiente y opcional, no un componente estándar de todos los informes de bloqueo. La documentación de repetición de JavaScript de Sentry describe una reconstrucción similar a un vídeo de la actividad del navegador, incluidos el estado del DOM y las interacciones. Señala que el SDK enmascara por defecto el texto del DOM, las imágenes y las entradas del usuario, ofreciendo además opciones de configuración. Los ajustes de enmascaramiento y las plataformas compatibles son determinantes: no deduzca que el contenido del diario está visible o protegido sin comprobar la configuración real del proveedor y las opciones de privacidad. Consulte la [guía de Session Replay para JavaScript de Sentry](https://docs.sentry.io/platforms/javascript/session-replay/).
¿Qué debería revisar antes de compartir un informe?
Utilice esta lista de comprobación sobre el archivo real o la vista previa del informe, y consulte la documentación de privacidad de la aplicación o del proveedor si el contenido del informe no está claro:
Esta lista de comprobación es una guía práctica de orientación editorial para el usuario de un diario que revisa un informe antes de enviarlo. Es independiente de las instrucciones para desarrolladores: estos controlan sus propios ajustes de registro, repetición y archivos adjuntos, y deben documentar qué recopilan dichas funciones, además de verificar si los campos de diagnóstico pueden contener contenido introducido por el usuario.
¿Por qué los informes pueden diferir entre aplicaciones y dispositivos?
Los sistemas operativos generan formatos de informe y vías de recopilación diferentes; además, los desarrolladores pueden emplear un SDK de terceros con una configuración personalizada. Apple señala que los informes de bloqueo de App Store y TestFlight están disponibles a través de Xcode, mientras que otros registros de diagnóstico podrían requerir ser transferidos directamente desde un dispositivo. Android diferencia los informes de errores completos de los informes de bloqueo suministrados mediante servicios como Google Play o Firebase. Los ajustes del proveedor pueden determinar, asimismo, qué eventos, breadcrumbs, archivos adjuntos o datos de repetición se capturan y almacenan. Tome el aviso de privacidad de la app y el informe concreto como referencia para cada caso particular, en lugar de asumir que todos los servicios envían los mismos campos.