Falhas no App Center (React Native)
Importante
O Visual Studio App Center está programado para ser desativado em 31 de março de 2025. Embora você possa continuar a usar o Visual Studio App Center até que ele seja totalmente desativado, há várias alternativas recomendadas para as quais você pode considerar a migração.
As falhas do App Center gerarão automaticamente um log de falhas sempre que o aplicativo falhar. O log é gravado pela primeira vez no armazenamento do dispositivo e, quando o usuário iniciar o aplicativo novamente, o relatório de falha será enviado para o App Center. A coleta de falhas funciona para aplicativos beta e ao vivo, ou seja, aqueles enviados ao Google Play. Os logs de falha contêm informações valiosas para ajudar a corrigir a falha.
Siga a seção Introdução se você ainda não configurou o SDK em seu aplicativo.
Onde quer que você esteja usando falhas do App Center, adicione a seguinte importação na parte superior do arquivo.
// Import App Center Crashes at the top of the file.
import Crashes from 'appcenter-crashes';
Gerar uma falha de teste
As falhas do App Center fornecem uma API para gerar uma falha de teste para facilitar o teste do SDK. Essa API só pode ser usada em aplicativos de teste/beta e não fará nada em aplicativos de produção.
Crashes.generateTestCrash();
Também é fácil gerar uma falha do JavaScript. Adicione a linha a seguir ao código, o que gera um erro JavaScript e causa uma falha.
throw new Error('This is a test javascript crash!');
Dica
Seu aplicativo React Native precisa ser compilado no modo de versão para que essa falha seja enviada ao App Center.
Observação
No momento, o App Center não dá suporte a mapas de origem para desminificar rastreamentos de pilha javaScript para aplicativos do Android React Native.
Observação
É uma prática recomendada evitar a instrução JavaScript throw com um valor de cadeia de caracteres (por exemplo: throw 'message'), pois React Native não preserva a pilha JavaScript completa neste cenário. Em vez disso, throw um JavaScript Error (por exemplo: throw Error('message')).
Obter mais informações sobre uma falha anterior
O App Center Crashes tem duas APIs que fornecem mais informações caso seu aplicativo tenha falhado.
O aplicativo recebeu um aviso de memória baixa na sessão anterior?
A qualquer momento após iniciar o SDK, você poderá marcar se o aplicativo recebeu um aviso de memória na sessão anterior:
const hadLowMemoryWarning = await Crashes.hasReceivedMemoryWarningInLastSession();
Observação
Em alguns casos, um dispositivo com memória baixa pode não enviar eventos.
O aplicativo falhou na sessão anterior?
A qualquer momento após iniciar o SDK, você poderá marcar se o aplicativo falhou na inicialização anterior:
const didCrash = await Crashes.hasCrashedInLastSession();
Isso é útil caso você deseje ajustar o comportamento ou a interface do usuário do aplicativo após uma falha. Alguns desenvolvedores optaram por mostrar uma interface do usuário adicional para pedir desculpas aos usuários ou querem entrar em contato após uma falha.
Detalhes sobre a última falha
Se o aplicativo falhou anteriormente, você poderá obter detalhes sobre a última falha.
const crashReport = await Crashes.lastSessionCrashReport();
Personalizar o uso de falhas do App Center
O App Center Crashes fornece retornos de chamada para que os desenvolvedores executem ações adicionais antes e ao enviar logs de falha para o App Center.
Falha no processamento no JavaScript
Para que seus Crash.setListener métodos funcionem conforme o esperado, você precisará marcar se o aplicativo estiver configurado corretamente.
- Abra o arquivo do
ios/YourAppName/AppDelegate.mprojeto e verifique se você tem[AppCenterReactNativeCrashes register];em vez de[AppCenterReactNativeCrashes registerWithAutomaticProcessing];. - Abra o arquivo do
android/app/src/main/res/values/strings.xmlprojeto e verifique seappCenterCrashes_whenToSendCrashesele está definido comoASK_JAVASCRIPT.
Todos os diferentes retornos de chamada do ouvinte de eventos são discutidos um por um neste documento, mas você precisa definir um ouvinte de evento que defina todos os retornos de chamada ao mesmo tempo.
A falha deve ser processada?
Implemente esse retorno de chamada se você quiser decidir se uma falha específica precisa ser processada ou não. Por exemplo, pode haver uma falha no nível do sistema que você gostaria de ignorar e que não deseja enviar para o App Center.
Crashes.setListener({
shouldProcess: function (report) {
return true; // return true if the crash report should be processed, otherwise false.
},
// Other callbacks must also be defined at the same time if used.
// Default values are used if a method with return parameter isn't defined.
});
Observação
Para usar esse recurso, você precisa configurar seu aplicativo corretamente para o serviço Crash.
Esse recurso depende de falhas de processamento no JavaScript.
Solicitar o consentimento do usuário para enviar um log de falhas
Se a privacidade do usuário for importante para você, você deverá obter a confirmação do usuário antes de enviar um relatório de falha para o App Center. O SDK expõe um retorno de chamada que informa que o App Center falha para aguardar a confirmação do usuário antes de enviar relatórios de falha.
Se você optar por fazer isso, será responsável por obter a confirmação do usuário, por exemplo, por meio de um prompt de caixa de diálogo com uma das seguintes opções: Sempre Enviar, Enviar e Não enviar. Com base na entrada, você informará às Falhas do App Center o que fazer e a falha será tratada de acordo.
Observação
O SDK não exibe uma caixa de diálogo para isso, o aplicativo deve fornecer sua própria interface do usuário para solicitar o consentimento do usuário.
O retorno de chamada a seguir mostra como informar o SDK para aguardar a confirmação do usuário antes de enviar falhas:
Crashes.setListener({
shouldAwaitUserConfirmation: function (report) {
// Build your own UI to ask for user consent here. SDK doesn't provide one by default.
// Return true if you built a UI for user consent and are waiting for user input on that custom UI, otherwise false.
return true;
},
// Other callbacks must also be defined at the same time if used.
// Default values are used if a method with return parameter isn't defined.
});
Se você retornar true, seu aplicativo deverá obter (usando seu próprio código) a permissão do usuário e atualizar o SDK com o resultado usando a seguinte API:
import Crashes, { UserConfirmation } from 'appcenter-crashes';
// Depending on the user's choice, call Crashes.notifyUserConfirmation() with the right value.
Crashes.notifyUserConfirmation(UserConfirmation.DONT_SEND);
Crashes.notifyUserConfirmation(UserConfirmation.SEND);
Crashes.notifyUserConfirmation(UserConfirmation.ALWAYS_SEND);
Observação
Para usar esse recurso, configure seu aplicativo corretamente para o serviço Crash. O recurso depende de falhas de processamento no JavaScript.
Obter informações sobre o envio de status para um log de falhas
Às vezes, você deseja saber o status da falha do aplicativo. Um caso de uso comum é que talvez você queira mostrar a interface do usuário que informa aos usuários que seu aplicativo está enviando um relatório de falha ou, caso seu aplicativo esteja falhando rapidamente após a inicialização, você deseja ajustar o comportamento do aplicativo para garantir que os logs de falha possam ser enviados. O App Center Crashes tem três retornos de chamada diferentes que você pode usar em seu aplicativo para ser notificado sobre o que está acontecendo.
Para fazer isso, defina um ouvinte de eventos em seu código, conforme mostrado no exemplo a seguir:
Crashes.setListener({
onBeforeSending: function (report) {
// called after Crashes.process and before sending the crash.
},
onSendingSucceeded: function (report) {
// called when crash report sent successfully.
},
onSendingFailed: function (report) {
// called when crash report couldn't be sent.
}
// Other callbacks must also be defined at the same time if used.
// Default values are used if a method with return parameter isn't defined.
});
Todos os retornos de chamada são opcionais. Você não precisa fornecer todos os três métodos no objeto do ouvinte de eventos, por exemplo, você pode implementar apenas onBeforeSending.
Observação
Para usar esse recurso, você precisa configurar seu aplicativo corretamente para o serviço Crash.
Esse recurso depende de falhas de processamento no JavaScript.
Observação
Se Crashes.setListener for chamado mais de uma vez, o último vencerá; ele substituirá os ouvintes definidos anteriormente por Crashes.setListener.
onSendingFailed Receber significa que ocorreu um erro não recuperável, como um código 4xx. Por exemplo, 401 significa que o appSecret está errado.
Esse retorno de chamada não será disparado se for um problema de rede. Nesse caso, o SDK continua tentando novamente (e também pausa novas tentativas enquanto a conexão de rede está inativa). Caso tenhamos problemas de rede ou uma interrupção no ponto de extremidade e você reinicie o aplicativo, onBeforeSending será disparado novamente após a reinicialização do processo.
Adicionar anexos a um relatório de falha
Você pode adicionar anexos binários e de texto a um relatório de falha. O SDK os enviará junto com a falha para que você possa vê-los no portal do App Center. O retorno de chamada a seguir é invocado logo antes de enviar a falha armazenada de inicializações de aplicativos anteriores. Ele não será invocado quando a falha acontecer. Verifique se o arquivo de anexo não está nomeado minidump.dmp , pois esse nome está reservado para arquivos de minidump. Aqui está um exemplo de como anexar texto e uma imagem a uma falha:
import Crashes, { ErrorAttachmentLog } from 'appcenter-crashes';
Crashes.setListener({
getErrorAttachments(report) {
const textAttachment = ErrorAttachmentLog.attachmentWithText('Hello text attachment!', 'hello.txt');
const binaryAttachment = ErrorAttachmentLog.attachmentWithBinary(`${imageAsBase64string}`, 'logo.png', 'image/png');
return [textAttachment, binaryAttachment];
}
// Other callbacks must also be defined at the same time if used.
// Default values are used if a method with return parameter isn't defined.
});
O fileName parâmetro é opcional (pode ser null) e é usado apenas no portal do App Center. Em uma ocorrência de falha específica no portal, você pode ver anexos e baixá-los. Se você especificou um nome de arquivo, esse será o nome do arquivo a ser baixado, caso contrário, o nome do arquivo será gerado para você.
Para configurar o getErrorAttachments retorno de chamada para trabalhar com funções assíncronas/await do ES2017, retorne uma Promessa cumprida. O exemplo a seguir anexa um texto e uma imagem a uma falha de maneira assíncrona:
import Crashes, { ErrorAttachmentLog } from 'appcenter-crashes';
Crashes.setListener({
getErrorAttachments(report) {
return (async () => {
const textContent = await readTextFileAsync(); // use your async function to read text file
const binaryContent = await readBinaryFileAsync(); // use your async function to read binary file
const textAttachment = ErrorAttachmentLog.attachmentWithText(textContent, 'hello.txt');
const binaryAttachment = ErrorAttachmentLog.attachmentWithBinary(binaryContent, 'logo.png', 'image/png');
return [textAttachment, binaryAttachment];
})();
}
// Other callbacks must also be defined at the same time if used.
// Default values are used if a method with return parameter isn't defined.
});
Observação
Para usar esse recurso, você precisa configurar seu aplicativo corretamente para o serviço Crash.
Esse recurso depende de falhas de processamento no JavaScript.
Observação
Atualmente, o limite de tamanho é de 1,4 MB no Android e 7 MB no iOS. Tentar enviar um anexo maior disparará um erro.
Erros tratados
O App Center também permite que você acompanhe erros usando exceções tratadas por meio trackError do método . Opcionalmente, um aplicativo pode anexar propriedades ou/e anexos a um relatório de erro manipulado para fornecer mais contexto.
try {
// Throw error.
} catch (error) {
// Prepare properties.
const properties = { 'Category' : 'Music', 'Wifi' : 'On' };
// Prepare attachments.
const textAttachment = ErrorAttachmentLog.attachmentWithText('Hello text attachment!', 'hello.txt');
const attachments = [textAttachment];
// Create an exception model from error.
const exceptionModel1 = ExceptionModel.createFromError(error);
// ..or generate with your own error data.
const exceptionModel2 = ExceptionModel.createFromTypeAndMessage("type", "message", "stacktrace");
// Track error with custom data.
Crashes.trackError(exceptionModel1, properties, attachments);
Crashes.trackError(exceptionModel1, properties, nil);
Crashes.trackError(exceptionModel2, nil, attachments);
Crashes.trackError(exceptionModel2, nil, nil);
}
Breakpad
O App Center dá suporte a falhas de Breakpad do NDK do Android em um React Native aplicativos.
Siga as etapas normais de instalação acima e, em sua MainActivity.java substituição OnCreate , adicione a configuração de minidump e chame em seu código nativo que define a configuração do Breakpad.
Exemplo:
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
Crashes.getMinidumpDirectory().thenAccept(new AppCenterConsumer<String>() {
@Override
public void accept(String path) {
// Path is null when Crashes is disabled.
if (path != null) {
// links to NDK
setupBreakpadListener(path);
}
}
});
}
Habilitar ou desabilitar falhas do App Center em runtime
Você pode habilitar e desabilitar falhas do App Center em runtime. Se você desabilitá-lo, o SDK não fará nenhum relatório de falha para o aplicativo.
await Crashes.setEnabled(false);
Para habilitar falhas do App Center novamente, use a mesma API, mas passe true como um parâmetro.
await Crashes.setEnabled(true);
O estado é persistido no armazenamento do dispositivo entre as inicializações do aplicativo.
Verificar se as falhas do App Center estão habilitadas
Você também pode marcar se falhas do App Center estiverem habilitadas ou não:
const enabled = await Crashes.isEnabled();