Отправить отчет после сигнала JNI Android / исключение

Я пытаюсь заставить Firebase работать с моим Android-приложением, но в основном это код C ++.
Скорее всего, если произойдет какой-либо сбой, это будет плохой доступ в части C ++.
Firebase хорошо работает с необработанными исключениями Java, однако я не могу заставить его работать с сигналами / исключениями JNI.

Насколько я знаю, он еще не совместим с JNI, но я думал, что обходной путь будет примерно таким:

Кто-то в C ++ добавляет обработчик сигналов для сигналов, которые мы хотели бы обработать, которые отправят его обратно на сторону Java и попытаются отправить отчет (с частью трассировки стека, если это возможно).

#include <cisgnal>
namespace
{
void SignalHandler( int sig )
{
// Code to call a static method in my Activity
}
}

CrashReporter::CrashReporter()
{
::signal( SIGABRT, & ::SignalHandler )
}

// In java
public static void SendReportOnCrash()
{
FirebaseCrash.report( new Exception( "OOPS" ) );
}

К сожалению, поддельные отчеты никогда не отправляются, однако я получаю обратный вызов в Java.
Я попытался запустить процесс, разделенный процессом, в котором я бы вызвал FirebaseCrash.report (), но нет нестатического пути к нему, поэтому он всегда завершается сбоем, так как FirebaseApp / Crash не создаются во вторичной активности.

Я пришел сюда, чтобы спросить, есть ли у кого-нибудь подсказка, как это сделать.

Моя последняя попытка, но наименее желательный тест состоял бы в том, чтобы записать трассировку стека в файл, и при новом запуске проверить, существует ли этот файл, если это так, используйте FirebaseCrash.log, а затем отправьте поддельный отчет …

1

Решение

Вы не гарантированно сможете выполнять какую-либо обработку Java после вызовов JVM abort() за фатальную ошибку. в документация по Java:

SIGABRT

Виртуальная машина HotSpot не обрабатывает этот сигнал. Вместо этого он вызывает прерывание
функция после обработки фатальной ошибки. Если приложение использует это
Сигнал затем следует прекратить процесс, чтобы сохранить ожидаемый
семантика.

Да, это для реализации Oracle. Скорее всего, это относится и ко всем другим реализациям.

Потому что в тот момент, когда он вызывает abort(), JVM ожидает быть убитым.

0

Другие решения

Других решений пока нет …