我有一个使用 NativeActivity 类的单活动本机应用程序。如果应用程序崩溃，它会立即重新启动。我整天在互联网上搜索这个问题。
当使用以下任何一种（SIGSEGV 信号）时会发生这种情况：
- assert.h 中的 assert()
- android/log.h 中的 __android_log_assert()
- abort() - pthread_exit()
我做了一些研究：
https://stackoverflow.com/a/7387659
没用，发送 SIGKILL 会导致发送另一个 SIGSEGV 并重新启动应用程序。
https://stackoverflow.com/a/6121393/1374605
https://stackoverflow.com/a/2632649
我尝试只运行一项活动。我错过了什么吗？
当一个 JNI 函数（JNIEnv 成员）调用抛出并且另一个 JNI 函数被调用而不在它们之间调用 ExceptionClear() 时，也会发生重新启动。这与JVM有关吗？
任何想法为什么应用程序在崩溃后重新启动以及如何防止它？
更新（logcat）：
// 之前的内存转储到此结束
09-26 15:36:48.771: I/BootReceiver(2374): Copying /data/tombstones/tombstone_06 to DropBox (SYSTEM_TOMBSTONE)
09-26 15:36:48.781: I/ActivityManager(2374): Process net.devenec.devengine.sample (pid 4750) has died.
09-26 15:36:48.791: I/ActivityManager(2374): Start proc net.devenec.devengine.sample for activity net.devenec.devengine.sample/android.app.NativeActivity: pid=4763 uid=10075 gids={50075, 1028}
09-26 15:36:48.801: D/Zygote(1953): Process 4750 terminated by signal (11)
09-26 15:36:48.801: D/dalvikvm(4763): Late-enabling CheckJNI
09-26 15:36:48.826: I/dalvikvm(4763): Turning on JNI app bug workarounds for target SDK version 9...
09-26 15:36:48.841: W/Trace(4763): error opening trace file: No such file or directory (2)
// My code starts here
09-26 15:36:48.856: D/DevEngine(4763): [Application] Create
09-26 15:36:48.856: A/libc(4763): source/android/AndroidApplication.cpp:141: static void Platform::Application::create(ANativeActivity*): assertion "false" failed
09-26 15:36:48.856: A/libc(4763): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1), thread 4763 (evengine.sample)
09-26 15:36:48.956: I/DEBUG(1950): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
09-26 15:36:48.956: I/DEBUG(1950): Build fingerprint: 'samsung/m3xx/m3:4.1.2/JZO54K/I9305XXBMA6:user/release-keys'
09-26 15:36:48.956: I/DEBUG(1950): Revision: '2'
09-26 15:36:48.956: I/DEBUG(1950): pid: 4763, tid: 4763, name: evengine.sample >>> net.devenec.devengine.sample <<<
09-26 15:36:48.956: I/DEBUG(1950): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad
// 内存转储从这里开始
编辑：
关于将此问题标记为重复，我已经解释了为什么在第一个链接之后这会有所不同。该解决方案在我的情况下不起作用。