TargetSdkVersion Android 4.0 crashes on lock

Hi all,

I’ve bumped my Android targetSdkVersion to “14” (Android 4.0) and now I’m getting a SIGSEGV with the following backtrace in my project when I lock and then try to resume the app. It’s limited to Android 4.0 devices only and seems to function fine on Android 2.3.3 devices. Has anyone else seen this in android?

I/DEBUG (12382): backtrace:
I/DEBUG (12382): #00 pc 0031daa2 /data/app-lib/com.myco.game-1/libcom_myco_game.so (JS::InNoGCScope()+17)
I/DEBUG (12382): #01 pc 004c36b9 /data/app-lib/com.myco.game-1/libcom_myco_game.so
I/DEBUG (12382): #02 pc 003e2d91 /data/app-lib/com.myco.game-1/libcom_myco_game.so
I/DEBUG (12382): #03 pc 003e2175 /data/app-lib/com.myco.game-1/libcom_myco_game.so (js::baseops::LookupProperty(JSContext*, JS::Handle<JSObject*>, JS::Handle, JS::MutableHandle<JSObject*>, JS::MutableHandlejs::Shape*)+20)
I/DEBUG (12382): #04 pc 0031bb1d /data/app-lib/com.myco.game-1/libcom_myco_game.so
I/DEBUG (12382): #05 pc 00321b31 /data/app-lib/com.myco.game-1/libcom_myco_game.so (JS_HasPropertyById+56)
I/DEBUG (12382): #06 pc 00321c03 /data/app-lib/com.myco.game-1/libcom_myco_game.so (JS_HasProperty+70)
I/DEBUG (12382): #07 pc 00143de7 /data/app-lib/com.myco.game-1/libcom_myco_game.so
I/DEBUG (12382): #08 pc 00143f29 /data/app-lib/com.myco.game-1/libcom_myco_game.so (ScriptingCore::executeSchedule(int, float, cocos2d::CCNode*)+232)
I/DEBUG (12382): #09 pc 00604ba7 /data/app-lib/com.myco.game-1/libcom_myco_game.so (cocos2d::CCScheduler::update(float)+162)
I/DEBUG (12382): #10 pc 006184c9 /data/app-lib/com.myco.game-1/libcom_myco_game.so (cocos2d::CCDirector::drawScene()+24)
I/DEBUG (12382): #11 pc 00618549 /data/app-lib/com.myco.game-1/libcom_myco_game.so (cocos2d::CCDisplayLinkDirector::mainLoop()+28)
I/DEBUG (12382): #12 pc 00636b43 /data/app-lib/com.myco.game-1/libcom_myco_game.so (Java_org_cocos2dx_lib_Cocos2dxRenderer_nativeRender+10)
I/DEBUG (12382): #13 pc 0001e290 /system/lib/libdvm.so (dvmPlatformInvoke+112)
I/DEBUG (12382): #14 pc 0004d411 /system/lib/libdvm.so (dvmCallJNIMethod(unsigned int const**, JValue**, Method const**, Thread**)+396)
I/DEBUG (12382): #15 pc 000276e4 /system/lib/libdvm.so
I/DEBUG (12382): #16 pc 000fedd0 [stack:10357]

I’ve narrowed this down even further. It seems that any scheduled update for Javascript will crash the app on resume. Repro is simple: create an empty javascript project, add a scene with a layer and schedule an update on that layer using scheduleUpdate. then lock the app and resume.

This is also reproducable using the TestJavascript project by loading the ParticleTest, locking, then resuming. The crash is similar in nature but at a different location:

I/DEBUG ( 6599): backtrace:
I/DEBUG ( 6599): #00 pc 006090a6 /data/app-lib/org.cocos2dx.testjavascript-1/libtestjavascript.so (cocos2d::CCTexture2D::initWithImage(cocos2d::CCImage*)+29)
I/DEBUG ( 6599): #01 pc 0060b2af /data/app-lib/org.cocos2dx.testjavascript-1/libtestjavascript.so (cocos2d::VolatileTexture::reloadAllTextures()+350)
I/DEBUG ( 6599): #02 pc 0060b2eb /data/app-lib/org.cocos2dx.testjavascript-1/libtestjavascript.so (cocos2d::CCTextureCache::reloadAllTextures()+2)
I/DEBUG ( 6599): #03 pc 0013e72d /data/app-lib/org.cocos2dx.testjavascript-1/libtestjavascript.so (Java_org_cocos2dx_lib_Cocos2dxRenderer_nativeInit+84)
I/DEBUG ( 6599): #04 pc 0001e290 /system/lib/libdvm.so (dvmPlatformInvoke+112)
I/DEBUG ( 6599): #05 pc 0004d411 /system/lib/libdvm.so (dvmCallJNIMethod(unsigned int const**, JValue**, Method const**, Thread**)+396)
I/DEBUG ( 6599): #06 pc 000276e4 /system/lib/libdvm.so
I/DEBUG ( 6599): #07 pc 000fedd0 [stack:3788]
I/DEBUG ( 6599):

My current theory is that this seems to be caused by Android 4.0 changing the GL thread on resume. Has anyone seen or found a way to work around this issue? Unfortunately we need to support targetSdkVersion 14 for our projects.

Hi, do you mean this crash happens only when you switch to targetSdkVersion 14?

James Chen wrote:

Hi, do you mean this crash happens only when you switch to targetSdkVersion 14?

Hi James,

That’s correct. With API Version 8, everything works fine. Seems the particle system repro I posted above is non-deterministic (I’m testing on a Nexus 4).

I’ve narrowed this down even further. It seems that any scheduled update for Javascript will crash the app on resume. Repro is simple: create an empty javascript project, add a scene with a layer and schedule an update on that layer using scheduleUpdate. then lock the app and resume.

So only after app resumes from background, it crashes?
Did it just crash on your Nexus 4 or any android devices?

James Chen wrote:

> I’ve narrowed this down even further. It seems that any scheduled update for Javascript will crash the app on resume. Repro is simple: create an empty javascript project, add a scene with a layer and schedule an update on that layer using scheduleUpdate. then lock the app and resume.
>
So only after app resumes from background, it crashes?
Did it just crash on your Nexus 4 or any android devices?

That’s correct, on resume it crashes with the SIGSEGV you see above. Our working theory is that Android 4.0 changed the way GLSurfaceView works. GLSurfaceView in 4.0 kills the thread and restarts it after detatching/attaching the window. Since JS is running on the thread, it causes a crash. This is most prevalant if you have an update func that gets executed immediately.

It crashed on more than one device, both were running Android 4.0+. Runs fine on our 2.3.x devices.

Also note that I have to change both project.properties to android-14 and to repro. Clean/Full-rebuild will cause crash on lock/reload. Device must be Android 4.0+ as well.

amitt mahajan wrote:

Also note that I have to change both project.properties to android-14 and to repro. Clean/Full-rebuild will cause crash on lock/reload. Device must be Android 4.0+ as well.

Thank you. I’ll check this issue.
Issue http://www.cocos2d-x.org/issues/2066 was created.

Hey James,

I figured out the issue. Seems that in Android 13+, activities can get destroyed for additional reasons. So the AndroidManifest.xml Activity configChanges attribute needs “orientation|keyboardHidden|screenSize” to prevent the main activity from getting destroyed and recreated. Everything, as far as I can tell, works great now.

-Amitt

Thanks for your solution, I’ll check it out.

amitt mahajan wrote:

Hey James,
>
I figured out the issue. Seems that in Android 13+, activities can get destroyed for additional reasons. So the AndroidManifest.xml Activity configChanges attribute needs “orientation|keyboardHidden|screenSize” to prevent the main activity from getting destroyed and recreated. Everything, as far as I can tell, works great now.
>
-Amitt

Hi, amitt mahajan
Sorry for my late reply.
I did the test on four different android devices, but none of them could reproduce this issue.
I used cocos2d-x 2.2.1, and followed your step

Also note that I have to change both project.properties to android-14 and to repro. Clean/Full-rebuild will cause crash on lock/reload. Device must be Android 4.0+ as well.

Could you also test it with the 2.2.1 version and give me the feedback?
thanks.

BTW, I used G14, G17, Note2, Meizu MX2 TD. Their os version are all greater than 4.0