I used SplunkMINT for this purpose and have written a cn1lib wraps their Android and iOS SDKs and adds breadcrumbs, events, transactions etc., to the reporting and can be managed within Codename One code.
I haven't released it because my request for clarification on whether I could put it on github while bundled with their SDKs disappeared into their legal department years ago and I never heard back. You can get the log output and breadcrumbs and also time network transactions and so on. The problem is that the stack traces aren't symbolicated and as Codename One doesn't provide the dSYMs from the build process there is not really any way to make a whole lot of sense out of them. These types of errors I'm seeing at a rate around 0.03% compared to successful sessions and its my customer's call if its important to track down, if they decided it was at least there's something to go on (logs more than this stack trace). I've also used Countly for a similar purpose (and also wrapped its SDKs into cn1libs) now it supports crash reporting, though SplunkMINT is probably more useful as the logs can be attached. Might be worth looking at SplunkMINT or similar services and doing a native implementation into the parts of the SDK that you need and seeing if you can get the information you need. Example of the stack trace you'll get out of a crash that takes the whole app down and bypasses the CN1 crash reporters: 0 ConsumersApp 0x10057391c 0x1000d8000 + 4831516 1 ConsumersApp 0x100bc6b68 0x1000d8000 + 11463528 2 UIKit 0x186b27204 0x1868d4000 + 2437636 3 CoreFoundation 0x181790a60 0x181660000 + 1247840 4 CoreFoundation 0x181688488 0x181660000 + 165000 5 CoreFoundation 0x18168cdb0 0x181660000 + 183728 6 WebKitLegacy 0x1865ec21c 0x1865e8000 + 16924 7 CoreFoundation 0x18178ea1c 0x181660000 + 1239580 8 CoreFoundation 0x18168cc5c 0x181660000 + 183388 9 CoreFoundation 0x181790a60 0x181660000 + 1247840 10 CoreFoundation 0x181688488 0x181660000 + 165000 11 WebCore 0x18568649c 0x1855e0000 + 681116 12 CoreFoundation 0x18174109c 0x181660000 + 921756 13 CoreFoundation 0x181740b30 0x181660000 + 920368 14 CoreFoundation 0x18173e830 0x181660000 + 911408 15 CoreFoundation 0x181668c50 0x181660000 + 35920 16 GraphicsServices 0x182f50088 0x182f44000 + 49288 17 UIKit 0x186952088 0x1868d4000 + 516232 18 ConsumersApp 0x100a119b4 0x1000d8000 + 9673140 19 ConsumersApp 0x10017cc30 0x1000d8000 + 674864 20 ConsumersApp 0x10053d760 0x1000d8000 + 4609888 21 ConsumersApp 0x100b0bf00 0x1000d8000 + 10698496 22 ConsumersApp 0x100b0bf78 0x1000d8000 + 10698616 23 ??? 0x1812068b8 0x0 + 0 On Monday, August 15, 2016 at 7:08:57 PM UTC+12, Dave Dyer wrote: > > I have witnessed a couple cases where my IOS app crashes hard, leaving no > traces and no crash reports. Since this takes down the entire app, and > since I wrap all threads with crash reporters, I suspect this is a crash > inside the VM, not a controllable condition where the error is thrown > gracefully. > > So my question is how would an error of this kind manifest itself? > Also what should I do next to track these "down the rabbit hole" crashes? > -- You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/codenameone-discussions. To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/81b270aa-ec18-45ef-8c56-522cf6c72720%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
