Develop Reference

Unity Android app crashes after splash screen with Google Play Services for AR update (after April 11th 2020)

I'm working collaboratively on an Android app that uses AR Foundation. From one day to another (without making new builds) the app started to crash after the splash screen, every time. I'm working on my Huawei Mate 20 Pro, but my teammates use other Android phones (Samsung, Xiaomi and Motorola) and they continued to develop the app, and it works just fine for them. I pull their commits (which work for them), make no changes, and it keeps crashing on my phone. We are using Firebase so I have the info from Crashlytics, but I can't quiet understand it:
Unity version is 2019.4.8f1 LTS, and the Huawei phone runs on Android 10.
The complete crash log is:
Caused by java.lang.Error
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Version '2019.4.8f1 (60781d942082)', Build type 'Release', Scripting Backend 'mono', CPU 'armeabi-v7a'
Build fingerprint: 'HUAWEI/LYA-L29/HWLYA:10:user/release-keys' Revision: '0' ABI: 'arm'
Timestamp: 2020-08-13 14:12:37-0300 pid: 3571, tid: 3777,
name: UnityMain >>> com.app.name <<<
uid: 10315 signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
Cause: null pointer dereference r0 00000000 r1 00000000 r2 00000000 r3 00000000 r4 a965d490 r5 bd74a87c r6 80808080 r7 00000000 r8 be98f540 r9 00000000 r10 00000000 r11 b2f15f60 ip b2f4cc90 sp bd74a878 lr b2f1e859 pc 00000000
managed backtrace: #00 (wrapper managed-to-native)
UnityEngine.XR.ARCore.ARCoreSessionSubsystem/NativeApi:UnityARCore_session_update (UnityEngine.ScreenOrientation,UnityEngine.Vector2Int,intptr,UnityEngine.XR.ARSubsystems.Feature) #01
UnityEngine.XR.ARCore.ARCoreSessionSubsystem/ARCoreProvider:Update (UnityEngine.XR.ARSubsystems.XRSessionUpdateParams,UnityEngine.XR.ARSubsystems.Configuration) <0xef> #02
UnityEngine.XR.ARSubsystems.XRSessionSubsystem:Update (UnityEngine.XR.ARSubsystems.XRSessionUpdateParams) <0x1d3> #03
UnityEngine.XR.ARFoundation.ARSession:Update () <0x157> #04
(wrapper runtime-invoke) object:runtime_invoke_void__this__ (object,intptr,intptr,intptr)
UPDATE
I've managed to narrow down the crash to the following lines of code, inside the Update of ARSession script:
void Update()
{
if (subsystem?.running == true)
{
m_TrackingMode = subsystem.requestedTrackingMode.ToTrackingMode();
if (subsystem.matchFrameRateEnabled)
{
Application.targetFrameRate = subsystem.frameRate;
QualitySettings.vSyncCount = 0;
}
//subsystem.Update(new XRSessionUpdateParams
//{
// screenOrientation = Screen.orientation,
// screenDimensions = new Vector2Int(Screen.width, Screen.height)
//});
switch (subsystem.trackingState)
{
case TrackingState.None:
case TrackingState.Limited:
state = ARSessionState.SessionInitializing;
break;
case TrackingState.Tracking:
state = ARSessionState.SessionTracking;
break;
}
}
}
With those commented lines, the app starts but the camera won't work. If I uncomment them, it crashes. I know the problem is there because I placed a:
UnityEngine.Handheld.Vibrate();
Before and after, and the phone only vibrates once.

I updated the question's title because the problem is caused by an issue in the update of Google Play Services for AR. I managed to make my app work by manually downloading an older version of Google Play Services for AR, following the instructions here.
You can track the issue I opened in the ARCore Unity SDK repo here

Android UI tests with Espresso + MockK crash with SIGSEGV on emulators, fine on physical devices

I have just started using MockK to mock all the Repositories / Services logic in an MVP-based app for UI tests.
I have some UI tests running a login activity where the Espresso inputs logins and passwords and using MockK I can fake various situation where the login fails or not.
All services & repositories are standard Kotlin object, so I am using mockkobject and every/coEvery to override and handle login requests & tasks.
On my physical devices, there are no issues with the tests at all, but as soon as I tried to run them on a emulator running Android P+ with recommended image, they constantly crash at random time. And on rare occasion they can survive long enough to work.
Looking at the logs, I got various SIGSEGV:
A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 10425 (e.android.debug), pid 10425 (e.android.debug)
A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xc in tid 10968 (HeapTaskDaemon), pid 10957 (e.android.debug)
A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 15050 (firebase-instal), pid 14972 (e.android.debug)
A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xd in tid 8902 (Measurement Wor), pid 8858 (e.android.debug)
A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 22004 (Binder:21832_5), pid 21832 (e.android.debug)
But looking deeper into the logs I believe I found the culprit:
InputDispatcher: channel '9fa7335 my.company.com.android.debug/my.company.com.ui.login.LoginActivity(server)' ~ Channel is unrecoverably broken and will be disposed!
Looking for solutions, it seems this could happen due to memory leaks ?
In any case, I made sure to launch the activity under test in a #Before method where all the mocks occur while I am clearing such mocks and verifies in the #After method.
Clearly I believe the tests do work just fine but something must be wrong with Espresso or all the mocking that occurs...
[EDIT 1]
Further looking at prior logs, this could be the reason why there are memory leaks:
ActivityThread: Service com.google.android.gms.autofill.service.AutofillService has leaked IntentReceiver com.google.android.gms.autofill.smsretriever.TracingSmsBroadcastReceiver#ce00658 that was originally registered here. Are you missing a call to unregisterReceiver()?
android.app.IntentReceiverLeaked: Service com.google.android.gms.autofill.service.AutofillService has leaked IntentReceiver com.google.android.gms.autofill.smsretriever.TracingSmsBroadcastReceiver#ce00658 that was originally registered here. Are you missing a call to unregisterReceiver()?
I disabled the AutoFillService (set to none in the relevant settings section) on my emulator. This seemed to improve my tests success rate at the beginning, but they keep crashing after several runs.
Now the logs are not showing this leak anymore, though.
[EDIT 2]
Apparently this issue could be related to MockK as I was able to retrieve more logs:
2020-07-24 11:57:15.955 15767-15780/com.my.company.android.debug A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 15780 (HeapTaskDaemon), pid 15767 (e.android.debug)
2020-07-24 11:57:15.997 15962-15962/? E/crash_dump32: failed to detach from thread 15773: No such process
2020-07-24 11:57:15.997 15962-15962/? E/crash_dump32: failed to detach from thread 15778: No such process
2020-07-24 11:57:15.997 15962-15962/? E/crash_dump32: failed to detach from thread 15779: No such process
2020-07-24 11:57:15.997 15962-15962/? E/crash_dump32: failed to detach from thread 15780: No such process
// 20 more times of exact same line //
2020-07-24 11:57:16.007 15962-15962/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
2020-07-24 11:57:16.007 15962-15962/? A/DEBUG: Build fingerprint: 'google/sdk_gphone_x86/generic_x86:10/QSR1.190920.001/5891938:user/release-keys'
2020-07-24 11:57:16.007 15962-15962/? A/DEBUG: Revision: '0'
2020-07-24 11:57:16.007 15962-15962/? A/DEBUG: ABI: 'x86'
2020-07-24 11:57:16.008 15962-15962/? A/DEBUG: Timestamp: 2020-07-24 09:57:16+0000
2020-07-24 11:57:16.008 15962-15962/? A/DEBUG: pid: 15767, tid: 15780, name: HeapTaskDaemon >>> com.my.company.android.debug <<<
2020-07-24 11:57:16.008 15962-15962/? A/DEBUG: uid: 10136
2020-07-24 11:57:16.008 15962-15962/? A/DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
2020-07-24 11:57:16.008 15962-15962/? A/DEBUG: Cause: null pointer dereference
2020-07-24 11:57:16.008 15962-15962/? A/DEBUG: eax 00000000 ebx ef8a6c34 ecx 00000000 edx f310b604
2020-07-24 11:57:16.008 15962-15962/? A/DEBUG: edi f3200380 esi 00000000
2020-07-24 11:57:16.008 15962-15962/? A/DEBUG: ebp e659d9a8 esp e659d940 eip ef7d89f4
2020-07-24 11:57:16.027 2044-2135/? E/InputDispatcher: channel '342ebda com.my.company.android.debug/com.my.compan.android.ui.error.LoginActivity (server)' ~ Channel is unrecoverably broken and will be disposed!
After further investigation, there is a 1-year-old issue on the Android Test Github repo showing the same problem (but issue is now closed): https://github.com/android/android-test/issues/352
A relevant issue at Mockk was opened here: https://github.com/mockk/mockk/issues/466
[EDIT 3]
I was exploring the alternative to go back to Mockito which has more history and more active development. It took a bit of time but I had no major issue migrating my UI tests to Mockito.
The results: well, at first the crash were completely gone. I could fire my tests run, 10, 20, 30 times without a hinch. At least on mobile.
However, on Android TV (still with a simulator), the crash reappeared rather quickly. And then on mobile as well, but way less often with the dreadful message from the InputDispatcher.
While setting up the migration to Mockito, I have noticed that Mockk shares the same restrictions & dependencies with Mockito when mocking on Android Test Instrumentation. I faced the same issues and the same difficulties.
So it led me to believe that neither of them are the culprit, but it could very well be the Android Instrumentation APIs.
I also noticed that manually rebooting the emulators greatly improved the situation.

This was in my stacktrace:
W Unexpected CPU variant for X86 using defaults: x86
ActivityThread W Package uses different ABI(s) than its instrumentation:
Switching to a 64 bit emulator fixed the problem.

I too have been running into this issue with my instrumentation test suite and also suspect MockK to be (at least partially) at fault.
This is far from a true solution, but I've noticed that running MY tests with Android Test Orchestrator greatly reduces the chance of random failure due to test process crash (caused by the above segfault). (If you are running tests with Firebase Test Lab emulators, this could be particularly helpful.)
Another bonus of using Orchestrator, it does a really good job of digging through the logs (in Firebase Test Lab) to find the root error if your test does fail in an Orchestrator process.
I'm not certain this will work well for everyone, but if it does, it likely indicates that MockK (if it truly is the source of this issue) isn't cleaning up fully and is leaking into other tests.

I had exactly the same case where my tests were crashing randomly on the Emulator with Process crashed error saying check the Logcat. There was SIGSEGV error on the Logcat but not always.
In my case it was com.linkedin.dexmaker:dexmaker-mockito-inline causing the random crashes. I had to add it to mock a Kotlin data class in Instrumentation tests which I didn't need after all. So removing this dependency solved my issue.
I recommend to investigate after which point your tests started crashing, then it will be easier to get to bottom of it.

Unity Android signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0

I'm building an Android App with Unity 2018.1.0f2 and get some kind of segmentation fault while running it. The exact error is the following:
05-16 20:54:11.834: E/SamsungIME(9413): <AbstractKeyboardView> - onDraw() called
05-16 20:54:12.142: E/ViewRootImpl(17850): sendUserActionEvent() mView == null
05-16 20:54:12.146: E/SKBD KeyboardInfoUtils(9413): getInstance start
05-16 20:54:12.146: E/SKBD KeyboardInfoUtils(9413): sendSIPInformation state:6 isAbstractKeyboardView : true
05-16 20:54:12.151: E/SKBD KeyboardInfoUtils(9413): sending null keyboardInfo as SIP is closed
05-16 20:54:15.401: A/libc(17850): Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 17865 (UnityMain)
05-16 20:54:15.401: A/libc(17850): [ 05-16 20:54:15.407 3096: 3096 W/ ]
05-16 20:54:15.401: A/libc(17850): debuggerd: handling request: pid=17850 uid=10350 gid=10350 tid=17865
05-16 20:54:15.633: A/DEBUG(17987): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
05-16 20:54:15.634: A/DEBUG(17987): Build fingerprint: 'samsung/heroltexx/herolte:7.0/NRD90M/G930FXXS2DRDI:user/release-keys'
05-16 20:54:15.635: A/DEBUG(17987): Revision: '8'
05-16 20:54:15.635: A/DEBUG(17987): ABI: 'arm'
05-16 20:54:15.635: A/DEBUG(17987): pid: 17850, tid: 17865, name: UnityMain >>> de.zoomapp.zoom <<<
05-16 20:54:15.635: A/DEBUG(17987): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
05-16 20:54:15.636: A/DEBUG(17987): r0 00000000 r1 c7ad20b0 r2 cf9ffc24 r3 efc62308
05-16 20:54:15.637: A/DEBUG(17987): r4 c7ad20b0 r5 c7ad20cc r6 ffffffff r7 00000000
05-16 20:54:15.637: A/DEBUG(17987): r8 00000000 r9 ee67ecb4 sl ee67ebc8 fp ee67e5e8
05-16 20:54:15.637: A/DEBUG(17987): ip c7ad20b0 sp ee67e5c8 lr cf9ffc3c pc f2386338 cpsr a00e0030
05-16 20:54:15.651: A/DEBUG(17987): backtrace:
05-16 20:54:15.652: A/DEBUG(17987): #00 pc 00018338 /system/lib/libc.so (strcmp+47)
05-16 20:54:15.652: A/DEBUG(17987): #01 pc 0014bc38 /data/app/de.zoomapp.zoom-1/lib/arm/libunity.so
05-16 20:54:15.652: A/DEBUG(17987): #02 pc 00008484 <anonymous:c7275000>
05-16 20:54:17.518: E/audit(4645): type=1701 audit(1526496857.505:4791): auid=4294967295 uid=10350 gid=10350 ses=4294967295 subj=u:r:untrusted_app:s0:c512,c768 pid=17865 comm="UnityMain" exe="/system/bin/app_process32" sig=11
05-16 20:54:17.562: E/lowmemorykiller(3180): Error writing /proc/17850/oom_score_adj; errno=22
I try to provide each screen in landscape and portrait mode. When the user is in the login screen and clicks the login button, a UnityWebRequest is sent to the server. If the server responds with a positive result, the UI transitions opens a loading screen, in the background multiple UnityWebRequests are sent to retrieve more information about icons and images to show. When loading is done the main menu is shown and in the background the game is already loaded, but paused. This game consists of only showing a bunch of images and is pretty static, which is the reason why I don't describe it in detail here.
The said crash occurs, if the user rotates his phone from portrait to landscape right after clicking login and while the loading screen shows. I could reproduce this error all the time on my Samsung Galaxy S7, but could not make a minimal example in a clean project.
It might be a problem with yielding the web requests maybe? I put log messages all over my code and before the crash I often saw the yield statement of some web request. I have more coroutines loading some images in async. If I comment out all coroutines it runs fine, but I don't know if this is due to the loading running very fast or if coroutines cause the problem.
I then searched on the internet and found to use addr2line tool. It produced for the address 0014bc38:
operator delete[](void*, std::nothrow_t const&)
I can't find the exact problem. I hope maybe someone has a hint how I can search for this.
Thank you guys.
Regards,
Michael

SEG_MAPERR with address of 0x0 is null pointer dereference.
It's valid to delete a null pointer (and should be for the delete[] operator). I suspect that you have some sort of race condition. Put some logs when you delete or free anything (although everything is GC...)
Also, check the official bug tracker and submit a new bug if you can't find something similar. I suspect that it is trying to access a null pointer when the new window parameters are sent to the app.

Getting a a Fatal Signal 11 (SIGSEGV), code 1 using Realm

It seems this error is caused by bugs in native code, and that this is due to the Realm library -- based on seeing the phrase librealm-jni.so in the "Build Fingerprint" beneath the error. I have the latest version of Realm installed -- 1.2.0.
Here's the error code:
Fatal signal 11 (SIGSEGV), code 1, fault addr 0x14c in tid 7837 (ator.app)
Here's the "Build Fingerprint:"
Build fingerprint: 'generic/vbox86p/vbox86p:5.0/LRX21M/buildbot11172321:userdebug/test-keys'
26643-26643/? I/DEBUG: Revision: '0'
26643-26643/? I/DEBUG: ABI: 'x86'
26643-26643/? I/DEBUG: pid: 7837, tid: 7837, name: ator.app >>> com.lockedout.app <<<
26643-26643/? I/DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x14c
26643-26643/? I/DEBUG: eax 00000148 ebx ffffffff ecx 7470d340 edx 00000002
26643-26643/? I/DEBUG: esi 00000000 edi 00000002
26643-26643/? I/DEBUG: xcs 00000023 xds 0000002b xes 0000002b xfs 00000007 xss 0000002b
26643-26643/? I/DEBUG: eip e2f6d025 ebp ffd3cd58 esp ffd3cd50 flags 00210246
26643-26643/? I/DEBUG: backtrace:
26643-26643/? I/DEBUG: #00 pc 0002a025 /data/app/com.lockedout.app-1/lib/x86/librealm-jni.so
26643-26643/? I/DEBUG: #01 pc 0009c141 /data/app/com.lockedout.app-1/lib/x86/librealm-jni.so
26643-26643/? I/DEBUG: #02 pc 0009c299 /data/app/com.lockedout.app-1/lib/x86/librealm-jni.so
26643-26643/? I/DEBUG: #03 pc 004002d3 /data/dalvik-cache/x86/data#app#com.lockedout.app-1#base.apk#classes.dex
26643-26643/? I/DEBUG: #04 pc 00000002 <unknown>
26643-26643/? I/DEBUG: Tombstone written to: /data/tombstones/tombstone_06
Update:
I narrowed down the problem to happening after I call notifyDataSetChanged on my RecyclerView.Adapter, but my code doesn't do anything else after that executes. So I narrowed down the problem area even further to line 135 in android's Looper class:
Message msg = queue.next(); // might block
I'm not sure what this means, but I imagine someone who knows the internals of Realm may be able to shed some insight on why the error is being caused in Looper.
Some more information about the changes that occured in Realm before the error:
notifyDataSetChanged is triggered inside of a RealmChangeListener set on a RealmObject aka "User". The transaction that caused the change deleted a custom RealmObject aka "Item" from User's RealmList<Item>. I know for a fact that that is the only transaction and operation that occurs because of my code. Here is the code that deletes the Item:
RealmSingleton.getUserInstance().executeTransaction(new Realm.Transaction() {
#Override
public void execute(Realm realm) {
UserSingleton.getUser().deleteItem(mItem.getClassId());
}
});
Update:
The exact line of Realm code that causes the error is line 149 in SharedGroup:
148 void commitAndContinueAsRead() {
149 nativeCommitAndContinueAsRead(nativePtr);
150 }

(I am still not an official Realm person)
Note: In order to actually answer this question, I'd have to see the full code. After all, Realm handles most possible crashes on the native side and throw it as an exception to Java, so you're probably doing something very wrong. :P
Guesses:
1.) you're using asynchronous queries combined with synchronous write on the UI thread, thus creating detached row accessors that you then try to delete based on ID despite it not being its latest version.
(Asynchronous queries aren't immediately executed, you need to listen to its completion using RealmChangeListener, but if you mix them with synchronous writes on the UI thread, you force the query to become synchronous.)
2.) You modified something on a background thread which has not yet updated the RealmResults on the UI thread (running the event handling with the looper), and the element you're trying to use in the transaction is not up to date, so its deletion crashes.
Possible solutions:
a.) Use executeTransactionAsync() instead of executeTransaction() when you're on the UI thread.
b.) In your method
UserSingleton.getUser().deleteItem(mItem.getClassId());
Not sure what UserSingleton is, but before you delete an element, you should consider requerying it based on ID inside the transaction to obtain the latest version of the element (which is potentially not updated yet in this particular case, synchronous transaction on the UI thread, after all)
Possible course of action:
If you want to help out Realm, if this crash is reproducible, consider sending the project over to help[at]realm.io so that they can look at it and fix it up. After all, you should get Java exceptions, not native crashes.

What process should be used to compress SKMaps.zip file for use in Skobbler powered app?

I'm currently using the Skobbler SDK in an Android app to handle mapping and turn-by-turn direction tasks. One issue that came up was the desire to change to frequency at which audio advice is issued from the SDK so that we don't have too many instructions being fired off one after the other.
I found this answer to another question which explains the need to modify an advice_places.adv file which I was able to find within the SDK provided SKMaps.zip file.
The issue I'm experiencing seems to be related to how I re-archive the zip file once I've finished making changes to the advice_places.adv file. I'm working on a Mac and it seems that regardless of if I use the built-in "Compress..." context menu option or if I perform a zip operation via the command line similar to:
zip -vr SKMaps.zip SKMaps/ -x "*.DS_Store"; chmod +x SKMaps.zip
I still can't seem to load my app without it crashing during the Skobbler SDK map initialization process.
I've narrowed down the issue to it being a zip/unzip related issue since I can recreate the crash even if I don't modify any of the contents of the SKMaps.zip but only unzip and then rezip.
Here is a dump of the logs that I see when my app crashes.
SKMaps D SKMapViewHolder----#onResume
D SKMapSurfaceView----#onResume
D SKMapSurfaceView----#onResume preserve GL context is TRUE
WindowManager V Adding window Window{278f3a43 u0 com.company.mymapapp/com.company.mymapapp.activities.MainActivity} at 23 of 32 (before Window{246caca8 u0 SurfaceView})
V Adding window Window{1b0d49f9 u0 SurfaceView} at 23 of 33 (before Window{278f3a43 u0 com.company.mymapapp/com.company.mymapapp.activities.MainActivity})
SKMaps D MapRenderer----#onSurfaceCreated
D MapRenderer----#onSurfaceCreated LinInitialized = true
D MapRenderer---- #initGLView
SkobblerNG D set density JNI - before NG_SetScreenScale
D set density JNI - after NG_SetScreenScale
libc F Fatal signal 11 (SIGSEGV), code 1, fault addr 0x4 in tid 24828 (GLThread 44711)
btif_config_util D btif_config_save_file(L188): in file name:/data/misc/bluedroid/bt_config.new
DEBUG I *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I Build fingerprint: 'google/shamu/shamu:5.1/LMY47I/1767468:user/release-keys'
I Revision: '33696'
I ABI: 'arm'
I pid: 24493, tid: 24828, name: GLThread 44711 >>> com.company.mymapapp <<<
I signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4
I r0 00000001 r1 00000000 r2 00000001 r3 00000029
I r4 a0edfcd0 r5 00000000 r6 a0edfc00 r7 a044a9b0
I r8 00000000 r9 a044a9d8 sl 00000001 fp 13250820
I ip 80000000 sp a044a978 lr 9e8d5efd pc 9e8d5f22 cpsr 600f0030
I backtrace:
I #00 pc 0018ef22 /data/app/com.company.mymapapp-1/lib/arm/libngnative.so (EarthSphere::SetupTextureInBufferFromTex(SK_WTEXTURE_ID&)+113)
I #01 pc 0018ff23 /data/app/com.company.mymapapp-1/lib/arm/libngnative.so (EarthSphere::Init(unsigned int, unsigned int)+190)
I #02 pc 0011dc7d /data/app/com.company.mymapapp-1/lib/arm/libngnative.so (MapRenderer::InitializeGlobeAndWorldTextures()+116)
I #03 pc 000fe1bd /data/app/com.company.mymapapp-1/lib/arm/libngnative.so (NG_InitializeGL+52)
I #04 pc 000e7fcf /data/app/com.company.mymapapp-1/lib/arm/libngnative.so (Java_com_skobbler_ngx_map_MapRenderer_initgl+14)
I #05 pc 0064b963 /data/dalvik-cache/arm/data#app#com.company.mymapapp-1#base.apk#classes.dex
I Tombstone written to: /data/tombstones/tombstone_07
ActivityManager W Force finishing activity 1 com.company.mymapapp/.activities.MainActivity
BootReceiver I Copying /data/tombstones/tombstone_07 to DropBox (SYSTEM_TOMBSTONE)
JavaBinder E !!! FAILED BINDER TRANSACTION !!!
WindowState I WIN DEATH: Window{23adbb9a u0 SurfaceView}
NetlinkEvent E NetlinkEvent::FindParam(): Parameter 'INTERFACE' not found
E NetlinkEvent::FindParam(): Parameter 'TIME_NS' not found
NetdConnector E Error handling '613 IfaceClass active (null)': java.lang.NumberFormatException: Invalid int: "(null)"
WindowState I WIN DEATH: Window{246caca8 u0 SurfaceView}
I WIN DEATH: Window{259e40bc u0 com.company.mymapapp/com.company.mymapapp.activities.IntroActivity}
I WIN DEATH: Window{278f3a43 u0 com.company.mymapapp/com.company.mymapapp.activities.MainActivity}
I WIN DEATH: Window{1b0d49f9 u0 SurfaceView}
Zygote I Process 24493 exited due to signal (11)
ActivityManager W Exception thrown during pause
W android.os.TransactionTooLargeException
W at android.os.BinderProxy.transactNative(Native Method)
W at android.os.BinderProxy.transact(Binder.java:496)
W at android.app.ApplicationThreadProxy.schedulePauseActivity(ApplicationThreadNative.java:704)
W at com.android.server.am.ActivityStack.startPausingLocked(ActivityStack.java:825)
W at com.android.server.am.ActivityStack.finishActivityLocked(ActivityStack.java:2726)
W at com.android.server.am.ActivityStack.finishTopRunningActivityLocked(ActivityStack.java:2583)
W at com.android.server.am.ActivityStackSupervisor.finishTopRunningActivityLocked(ActivityStackSupervisor.java:2497)
W at com.android.server.am.ActivityManagerService.handleAppCrashLocked(ActivityManagerService.java:11500)
W at com.android.server.am.ActivityManagerService.makeAppCrashingLocked(ActivityManagerService.java:11397)
W at com.android.server.am.ActivityManagerService.crashApplication(ActivityManagerService.java:12081)
W at com.android.server.am.ActivityManagerService.handleApplicationCrashInner(ActivityManagerService.java:11592)
W at com.android.server.am.NativeCrashListener$NativeCrashReporter.run(NativeCrashListener.java:86)
lowmemorykiller E Error opening /proc/24493/oom_score_adj; errno=2
Process com.company.mymapapp (PID: 24493) ended
If anyone has any information as to the preferred method of generating a zip file on a Mac for use with the Skobbler SDK in this fashion, I would appreciate any guidance.
Thank you!
Keith

I've had the same issue (I did the zipping/unzipping manually) - I did not get to the bottom of the problem but the trick is not to zip the SkMaps folder (that you get when unzipping) but the content of that folder (all the subfolders) in an archive named SkMaps.zip (go in the unpacked folder, SKMaps, select all the folder and compress them to an SKMaps.zip.
I'm not sure if this is Mac specific or zip specific. The SDK expects that when unzipping SKMaps.zip it will find a number of folders, but when you compress the SKMaps folder directly you end up with an archive that has as root folder a folder named SkMaps (which is wrong) and only inside that folder the correct folder structure.