Что может содержать отчет о сбое приложения для ведения дневника?
Отчет о сбое приложения для ведения дневника может включать технические подробности: трассировку стека сбоя, версии устройства и приложения, временные метки и сопутствующие диагностические события. В зависимости от операционной системы, службы отправки отчетов и конфигурации приложения он также может содержать логи, вложения или данные воспроизведения сессии (session replay), раскрывающие введенный или отображавшийся в приложении контент. Отчет не обязательно содержит записи дневника в каждом случае, однако ошибочно полагать, что их там гарантированно нет. Проверяйте конкретный отчет и настройки приложения перед отправкой.
Что отображается в стандартном отчете о сбое?
Трассировка стека (stack trace) перечисляет вызовы функций, связанные со сбоем. Она помогает разработчикам найти затронутый участок кода, но сама по себе обычно не объясняет всех обстоятельств и не подтверждает, что именно делал пользователь. В отчетах также могут указываться версии приложения и операционной системы, модель устройства, время сбоя и другие сведения об окружении. Apple описывает отчеты о сбоях как записи состояния приложения в момент падения и рекомендует анализировать полный системный отчет; в ее руководстве выделяются такие поля, как информация об устройстве, приложении и ОС. См. руководство Apple по [анализу отчетов о сбоях](https://developer.apple.com/documentation/xcode/analyzing-a-crash-report).
Формат отчета зависит от источника. Отчеты о сбоях Apple, собранные через Xcode, и отчеты об ошибках Android — это совершенно разные вещи. Официальное руководство Android указывает, что отчет об ошибке (bug report) может содержать системные логи устройства, трассировки стека, диагностический вывод системных служб, журналы ошибок и системные сообщения от приложений, использующих класс Android `Log`. Это значительно шире, чем просто запись о сбое. Содержимое каждого отдельного отчета всегда зависит от того, что было собрано и включено. См. [руководство Android по сбору и чтению отчетов об ошибках](https://developer.android.com/studio/debug/bug-report).
Может ли отчет содержать текст записей дневника?
При определенных конфигурациях это возможно, однако сам факт наличия отчета о сбое не означает, что в него непременно входит текст записей. Главный вопрос заключается в том, что приложение фиксирует вместе со сбоем и что охватывает формат отчета.
Например, разработчики приложения могут добавлять диагностические сообщения в журнал или кастомные события. Если эти сообщения содержат запись дневника, заголовок, поисковый запрос или текст, скопированный из редактора, эта информация может передаваться вместе с событием. Sentry описывает «breadcrumbs» (навигационные цепочки событий) как след действий перед возникновением проблемы; каждый шаг может содержать сообщение и произвольные структурированные данные. Breadcrumbs могут собираться автоматически через включенные интеграции или добавляться приложением вручную. См. [документацию Sentry по breadcrumbs](https://docs.sentry.io/product/issues/issue-details/breadcrumbs/). Отчеты об ошибках Android также включают журналы системных сообщений, куда могут попадать записи, созданные приложениями. Ни один из этих фактов не означает, что любое приложение обязательно логирует личный текст: всё зависит от реализации и настроек конкретного приложения.
Что такое логи, breadcrumbs, вложения и session replay?
Эти термины обозначают различные виды диагностических данных. Логи — это сообщения, записываемые приложением или системой. Breadcrumbs — это выбранная последовательность событий, предшествовавших ошибке, которая может включать временные метки, категории, сообщения и данные в формате «ключ-значение». И то, и другое может раскрыть больше контекста, чем трассировка стека, в зависимости от того, что именно записывает приложение.
Вложения — это файлы, отправляемые вместе с событием: например, файл журнала, скриншот или дамп сбоя. Sentry отмечает, что нативные минидампы могут содержать конфиденциальные сведения, такие как переменные окружения, локальные пути или представления полей ввода в оперативной памяти. В документации указано, что минидампы используются для создания событий и по умолчанию удаляются, но могут сохраняться как вложения, если включена соответствующая настройка; также отмечается, что правила очистки данных (data scrubbing) Sentry не распространяются на вложения. См. документацию Sentry по [данным о сбоях](https://docs.sentry.io/platforms/native/guides/crashpad/data-management/data-collected/) и [вложениям](https://docs.sentry.io/platforms/native/guides/crashpad/enriching-events/attachments/).
Воспроизведение сессий (session replay) — это отдельная, подключаемая по желанию функция, а не стандартный компонент каждого отчета о сбое. Документация Sentry по JavaScript-replay описывает ее как видеоподобную реконструкцию активности в браузере, включая состояние DOM и взаимодействия. Указывается, что SDK по умолчанию маскирует текст в DOM, изображения и пользовательский ввод, но при этом предоставляет параметры для настройки. Настройки маскирования и поддерживаемые платформы имеют решающее значение: нельзя делать вывод о том, скрыт ли контент дневника или виден, не проверив фактическую конфигурацию провайдера и настройки конфиденциальности. См. [руководство Sentry по JavaScript Session Replay](https://docs.sentry.io/platforms/javascript/session-replay/).
Что следует проверить перед отправкой отчета?
Используйте этот чек-лист для проверки самого файла или предпросмотра отчета, а также сверяйтесь с документацией по конфиденциальности приложения или сервиса, если содержимое отчета вызывает сомнения:
Этот чек-лист представляет собой практические редакционные рекомендации для пользователя дневника, проверяющего отчет перед отправкой. Он не заменяет инструкции разработчиков: создатели приложений сами контролируют настройки логирования, воспроизведения и вложений, должны документировать собираемые данные и проверять, могут ли диагностические поля содержать контент, введенный пользователем.
Почему отчеты различаются в зависимости от приложений и устройств?
Операционные системы формируют отчеты разных форматов и используют разные пути их сбора; разработчики также могут применять сторонние SDK с индивидуальными настройками. Apple указывает, что отчеты о сбоях из App Store и TestFlight доступны через Xcode, тогда как другие диагностические журналы может потребоваться переносить напрямую с устройства. Android разделяет полные системные отчеты об ошибках и отчеты о сбоях, передаваемые через такие сервисы, как Google Play или Firebase. Кроме того, настройки сервисов аналитики определяют, какие именно события, breadcrumbs, вложения или данные воспроизведения фиксируются и сохраняются. Опирайтесь на политику конфиденциальности приложения и фактическое содержимое отчета в каждом конкретном случае, не предполагая, что все сервисы отправляют один и тот же набор полей.