O que um relatório de falha de aplicativo de diário pode conter?
Um relatório de falha de aplicativo de diário pode incluir detalhes técnicos como o rastreamento de pilha (stack trace) da falha, versões do dispositivo e do aplicativo, carimbos de data/hora e eventos de diagnóstico próximos. Dependendo do sistema operacional, do serviço de relatórios e da configuração do aplicativo, ele também pode incluir logs, anexos ou dados de reprodução de sessão (session replay) que exponham o conteúdo inserido ou exibido no aplicativo. Um relatório não contém automaticamente entradas de diário em todos os casos, e não é seguro presumir que ele nunca as contenha. Verifique o relatório específico e como o aplicativo está configurado antes de compartilhá-lo.
O que um relatório de falha padrão mostra?
Um rastreamento de pilha lista chamadas de função associadas à falha. Ele ajuda os desenvolvedores a localizar o caminho do código envolvido, mas geralmente não explica, por si só, todas as circunstâncias nem prova o que o usuário estava fazendo. Os relatórios também podem identificar as versões do aplicativo e do sistema operacional, o modelo do dispositivo, a hora da falha e outros detalhes do ambiente. A Apple descreve relatórios de falha como registros do estado do aplicativo no momento de uma falha e recomenda a análise do relatório completo do sistema operacional; suas diretrizes identificam campos como informações de dispositivo, aplicativo e sistema operacional. Consulte o [guia de análise de relatórios de falha da Apple](https://developer.apple.com/documentation/xcode/analyzing-a-crash-report).
O formato do relatório depende de sua origem. Relatórios de falhas da Apple coletados por meio do Xcode e um relatório de bugs do Android são artefatos diferentes. O guia oficial do Android diz que um relatório de bugs pode conter logs do dispositivo, rastreamentos de pilha, saídas de diagnóstico de serviços do sistema, logs de erros e mensagens de sistema de aplicativos que usam a classe `Log` do Android. Isso é mais abrangente do que um registro restrito a falhas. O conteúdo de um relatório individual ainda depende do que foi coletado e incluído. Consulte o [guia do Android para capturar e ler relatórios de bugs](https://developer.android.com/studio/debug/bug-report).
O relatório pode incluir o texto do diário?
Ele pode, sob algumas configurações, mas a mera presença de um relatório de falha não estabelece que ele inclua o texto das entradas. A questão central é o que o aplicativo registra junto com a falha e o que o formato do relatório captura.
Por exemplo, desenvolvedores de aplicativos podem adicionar mensagens de log de diagnóstico ou eventos personalizados. Se essas mensagens incluírem uma entrada de diário, um título, um termo de pesquisa ou um texto copiado de um editor, essas informações poderão viajar com o evento. O Sentry descreve breadcrumbs como um rastro de eventos antes de um problema; cada um pode ter uma mensagem e dados estruturados arbitrários. Os breadcrumbs podem ser coletados automaticamente por meio de integrações ativadas ou adicionados por um aplicativo. Consulte a [documentação sobre breadcrumbs do Sentry](https://docs.sentry.io/product/issues/issue-details/breadcrumbs/). Relatórios de bugs do Android também incluem logs de mensagens do sistema, que podem conter mensagens escritas por aplicativos. Nenhum dos fatos significa que todo aplicativo registra textos privados: isso depende da implementação e da configuração do app.
O que são logs, breadcrumbs, anexos e replay?
Esses termos referem-se a tipos distintos de dados de diagnóstico. Logs são mensagens gravadas pelo aplicativo ou pelo sistema. Breadcrumbs são uma sequência selecionada de eventos que antecederam um erro, potencialmente incluindo carimbos de data/hora, categorias, mensagens e dados de chave-valor. Ambos podem revelar mais contexto do que um rastreamento de pilha, dependendo do que o aplicativo registra.
Anexos são arquivos enviados com um evento, como um arquivo de log, captura de tela ou despejo de memória da falha (crash dump). O Sentry observa que minidumps nativos podem conter material confidencial, como variáveis de ambiente, caminhos locais ou representações na memória de campos de entrada. Sua documentação informa que minidumps são usados para criar eventos e descartados por padrão, mas podem ser armazenados como anexos se essa configuração estiver habilitada; ela também diz que anexos não são cobertos pela filtragem de dados (data scrubbing) do Sentry. Consulte a documentação do Sentry sobre [dados de falhas](https://docs.sentry.io/platforms/native/guides/crashpad/data-management/data-collected/) e [anexos](https://docs.sentry.io/platforms/native/guides/crashpad/enriching-events/attachments/).
A reprodução de sessão (session replay) é um recurso separado e opcional, não um componente padrão de todo relatório de falha. A documentação do Sentry para replay em JavaScript descreve uma reconstrução em estilo de vídeo da atividade do navegador, incluindo estado e interações do DOM. Ela informa que o SDK mascara texto do DOM, imagens e entradas do usuário por padrão, além de oferecer opções de configuração. As configurações de mascaramento e as plataformas suportadas importam: não deduza que o conteúdo do diário está visível ou protegido sem verificar a configuração real do provedor e as definições de privacidade. Consulte o [guia de Session Replay em JavaScript do Sentry](https://docs.sentry.io/platforms/javascript/session-replay/).
O que você deve verificar antes de compartilhar um relatório?
Use esta lista de verificação no arquivo real ou na prévia do relatório e consulte a documentação de privacidade do aplicativo ou provedor quando o conteúdo do relatório não for claro:
Esta lista de verificação é uma orientação editorial prática para o usuário do diário que analisa um relatório antes de enviá-lo. Ela independe das instruções dos desenvolvedores: os desenvolvedores controlam suas próprias configurações de logs, replay e anexos, e devem documentar o que esses recursos coletam e avaliar se os campos de diagnóstico podem conter conteúdo inserido pelo usuário.
Por que os relatórios podem variar entre aplicativos e dispositivos?
Os sistemas operacionais geram diferentes formatos de relatório e caminhos de coleta; os desenvolvedores também podem usar um SDK de terceiros com configuração personalizada. A Apple afirma que relatórios de falhas da App Store e do TestFlight estão disponíveis pelo Xcode, enquanto outros logs de diagnóstico podem precisar ser transferidos a partir do dispositivo. O Android distingue relatórios completos de bugs de relatórios de falha fornecidos por serviços como o Google Play ou o Firebase. As configurações do provedor podem determinar ainda quais eventos, breadcrumbs, anexos ou dados de reprodução são capturados e armazenados. Considere a declaração de privacidade do aplicativo e o relatório real como guia para um caso específico, em vez de presumir que todos os serviços enviem os mesmos campos.