Android crash in Lime App


in the Google Play Console i see some crashes with my lime only app, but i was never able to reproduce any crash nor do i have a clue what this crash is actually about. Could you guys please have a look?

It happens especially on Huawei devices.

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 0 >>> <<<

  #00  pc 000000000006f06c  /apex/ (abort+160)
  #01  pc 00000000000500fc  /system/lib64/ (abort_message+232)
  #02  pc 0000000000050218  /system/lib64/ (demangling_terminate_handler()+44)
  #03  pc 00000000000646c4  /system/lib64/ (std::__terminate(void (*)())+12)
  #04  pc 000000000006466c  /system/lib64/ (std::terminate()+52)
  #05  pc 00000000000bb150  /system/lib64/ (std::__1::thread::~thread()+20)
  #06  pc 00000000000d0f68  /apex/ (__cxa_finalize+212)
  #07  pc 00000000000cc950  /apex/ (exit+24)
  #08  pc 0000000001808d10  /data/app/
  #09  pc 000000000149e438  /data/app/
  #10  pc 00000000008521dc  /data/app/
  #11  pc 0000000000ef973c  /data/app/
  #12  pc 0000000000e23cb0  /data/app/
  #13  pc 0000000000e2a724  /data/app/
  #14  pc 00000000008858fc  /data/app/
  #15  pc 0000000000886704  /data/app/
  #16  pc 00000000013d87fc  /data/app/
  #17  pc 00000000013d9d50  /data/app/
  #18  pc 00000000013da098  /data/app/
  #19  pc 00000000017c9c44  /data/app/
  #20  pc 0000000001045294  /data/app/
  #21  pc 00000000015e947c  /data/app/
  #22  pc 0000000000f46e38  /data/app/
  #23  pc 000000000083d094  /data/app/
  #24  pc 00000000017c9d98  /data/app/
  #25  pc 00000000015de93c  /data/app/
  #26  pc 00000000015d9178  /data/app/
  #27  pc 00000000015d94cc  /data/app/
  #28  pc 00000000017c9b7c  /data/app/
  #29  pc 00000000017c2c58  /data/app/
  #30  pc 00000000000a792c  /data/app/
  #31  pc 0000000000109c34  /data/app/
  #32  pc 0000000000109dd0  /data/app/
  #33  pc 0000000000107e88  /data/app/
  #34  pc 00000000000c759c  /data/app/
  #35  pc 00000000015d6cf8  /data/app/
  #36  pc 0000000000842110  /data/app/
  #37  pc 0000000000d8d1a8  /data/app/
  #38  pc 0000000000d8dde0  /data/app/
  #39  pc 00000000003704c4  /data/app/
  #40  pc 00000000017a172c  /data/app/
  #41  pc 00000000017a18d4  /data/app/ (hxcpp_main+40)
  #42  pc 000000000049e2b4  /data/app/ (Java_org_libsdl_app_SDLActivity_nativeRunMain+484)
  #43  pc 0000000000056f54  /data/app/ (art_jni_trampoline+228)
  #44  pc 00000000000e862c  /data/app/ (
  #45  pc 0000000000217fc8  /system/framework/arm64/boot.oat (
  #46  pc 0000000000143334  /apex/ (art_quick_invoke_stub+548)
  #47  pc 00000000001521a4  /apex/ (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+252)
  #48  pc 00000000004c84d8  /apex/ (art::(anonymous namespace)::InvokeWithArgArray(art::ScopedObjectAccessAlreadyRunnable const&, art::ArtMethod*, art::(anonymous namespace)::ArgArray*, art::JValue*, char const*)+104)
  #49  pc 00000000004c956c  /apex/ (art::InvokeVirtualOrInterfaceWithJValues(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jmethodID*, jvalue const*)+416)
  #50  pc 000000000050953c  /apex/ (art::Thread::CreateCallback(void*)+1176)
  #51  pc 00000000000ce1b0  /apex/ (__pthread_start(void*)+36)
  #52  pc 0000000000070ba8  /apex/ (__start_thread+64)

Without debug symbols it seems hard to know where the crash is originating

It is necessary to uncomment the line ‘<set name="nostrip" value="1" />’ in “.hxcpp_config.xml” and rebuild the same version with the same parameters. Then use “ndk-stack”.

So i create a production version to go live like always and additionally i create a unstripped version and then “ndk-stack” will show more debug information, right?

Yes exactly.
And more information

1 Like

I tried to build an unstripped version ( only an x86 apk had an increased size, all the other targets where the old size, just by the way :thinking: ), but with any folder i tried for “-sym”, i did not get any additional data. Which path should i use, and how can i see if the needed data there is available?


The libraries ( must be larger than usual. I have about x10

Thank you very very much, this worked fine and the magic happend :smiley:

Turns out that the “crash” which lowered my “sessions without a crash” to 87% in android vitals ( I think you get a visibility penalty below 98,5% or so ) was caused by System.exit(0); wenn the users pressed the apps exit button. :thinking:

How to solve this ( beside just removing the exit button )?

Stack frame   #00  pc 000000000006f06c  /apex/ (abort+160)
Stack frame   #01  pc 00000000000500fc  /system/lib64/ (abort_message+232)
Stack frame   #02  pc 0000000000050218  /system/lib64/ (demangling_terminate_handler()+44)
Stack frame   #03  pc 00000000000646c4  /system/lib64/ (std::__terminate(void (*)())+12)
Stack frame   #04  pc 000000000006466c  /system/lib64/ (std::terminate()+52)
Stack frame   #05  pc 00000000000bb150  /system/lib64/ (std::__1::thread::~thread()+20)
Stack frame   #06  pc 00000000000d0f68  /apex/ (__cxa_finalize+212)
Stack frame   #07  pc 00000000000cc950  /apex/ (exit+24)
Stack frame   #08  pc 00000000018123c0  /data/app/ Routine __hxcpp_exit(int) at C:/HaxeToolkit/haxe/lib/hxcpp/4,1,15/src/hx/StdLibs.cpp:309
Stack frame   #09  pc 00000000014a7ae8  /data/app/ Routine Sys_obj::exit(int) at C:\depot\mars\mainline\client3\bin\android\obj/./src/Sys.cpp:235
Stack frame   #10  pc 000000000085587c  /data/app/ Routine lime::_hx_system::System_obj::exit(int) at C:\depot\mars\mainline\client3\bin\android\obj/./src/lime/system/System.cpp:176
Stack frame   #11  pc 0000000000efade4  /data/app/ Routine _hx_run at C:\depot\mars\mainline\client3\bin\android\obj/./src/game/AppManager.cpp:209`

It’s generally bad practice to include an exit button in apps on mobile platforms, like Android and iOS. Just look at all native apps created by Apple or Google. They don’t have anything like that, so it’s actually really weird when anyone else adds them to other apps.

Users know how to manage which apps they have open using the native task switchers. Even if someone doesn’t, Android and iOS are good at automatically suspending apps that are in the background when another app needs any resources that they may be using.

So, basically, just get rid that exit button.

1 Like

Don’t have an exit button, just standard lime functions. And in 10 android these glitches began to appear.
Possible Solution

1 Like

I will continue a little.
We have android 10 and gesture control.
Sometimes when minimizing the application, nativePause fires before nativeFocusChanged (approximately 50/50). Accordingly, the NativeApplication -> handleWindowEvent() event does not occur. WINDOW_DEACTIVATE and AudioManager.suspend() fail. We get a “stuck partial blocking prohibition” AudioMix.
When the application is activated, WINDOW_DEACTIVATE and WINDOW_ACTIVATE are immediately executed one after the other with a delay of one frame.

Well, the Event.DEACTIVATE event itself is impossible to catch reliably and carry out the necessary actions.

According to statistics, AudioMix blocking occurs on other versions of android, but it was more reliable to catch on version 10.

Have you looked, maybe there is a fix in upstream SDL to improve this?

I rechecked everything and described the bug.

temporary solution:


     protected void onPause () {
         Log.v (TAG, "onPause ()");
         super.onPause ();

         if (mHIDDeviceManager! = null) {
             mHIDDeviceManager.setFrozen (true);
         if (! mHasMultiWindow) {
             pauseNativeThread ();

add onWindowFocusChanged (false):

     protected void onPause () {
         Log.v (TAG, "onPause ()");
         super.onPause ();

         if (mHIDDeviceManager! = null) {
             mHIDDeviceManager.setFrozen (true);
         onWindowFocusChanged (false);
         if (! mHasMultiWindow) {
             pauseNativeThread ();

I did some digging and I believe that the native pause will trigger the following events:

Could you take a look at things on the Lime side and see if we are handling MINIMIZED or WILLENTERBACKGROUND or DIDENTERBACKGROUND events? It looks like we need to handle a case where we did not lose focus but we did minimize


SDL_WINDOWEVENT_MINIMIZED is also caught and executed perfectly

set traces and looked at the order of events

classic control

minimize app


maximize app


gesture control

minimize app


maximize app


It turns out that AudioManager.suspend () should be executed, but comes only when the app is maximized.

I got another System.exit-crash in the start function of ApplicationMain.hx:

var result = app.exec();
#if (sys && !ios && !nodejs && !emscripten)

Comment of exec is:

	Execute the Application. On native platforms, this method
	blocks until the application is finished running. On other
	platforms, it will return immediately

So it looks like the app has finished running which may be fine, but how to avoid the “crash”

I don’t think you are supposed to exit on Android. Do we need an #if !android or #if !mobile as well?

1 Like