0

I know this question will be very vague, I'm sorry.

We have a native C++ application in development on Android and iOS, both platforms share the majority of code (only very little, platform specific, stuff). Our QA reported quite a few relatively random crashes on Android, which are either completely burried in libc++, libc or some third-party code we're using.
It's working perfectly on iOS.

How would one, realistically, approach such a situation and fix these crashes? Unfortunately Android is very bad in terms of native development, attaching a debugger on Samsung devices is sheer impossible, as well as getting meaningful stacktraces.

Leandros
  • 16,805
  • 9
  • 69
  • 108
  • There are many tutorials on how to debug android applications on the device using 'gdb', for example: https://mhandroid.wordpress.com/2011/01/25/how-cc-debugging-works-on-android/ . What's not ok with that? – Ctx Feb 20 '16 at 17:04
  • @Ctx Samsung devices have a bug since Android 2.3 which is still not fixed to this current day, which doesn't allow gdb debugging. And most, if not all, crashes are on Samsung devices. – Leandros Feb 20 '16 at 17:12
  • I'm not really familiar with Android development, but what about getting coredumps or using something like [Google Breakpad](http://stackoverflow.com/questions/9752759/using-google-breakpad-for-android-ndk) to pull some data off the device? – mindriot Feb 20 '16 at 17:16
  • Really freaking explicit log files, but if the app is in client hands, this will be problematic. I assume the core logic works just fine when abused in simulation? – user4581301 Feb 20 '16 at 17:52
  • You might want to try using valgrind and/or llvm's address-santizer. It can take a bit of work to get things running, but it's certainly possible (I've used both of them). You may have to root your device, but that's usually not that difficult. – Michael Feb 20 '16 at 18:06

1 Answers1

0

Create you own logging system. Every record should have a date and time stamp along with some description.

On my embedded system, we save: filename, function name, line number, event ID, and description of every system failure. On the next generation, we will be backing up these entries to an SDCard.

This is one of many logs that allow us to perform "forensics" when a device crashes. The test team or forensics team extracts the logs and attaches them to the defect report.

Edit 1: Characterizing behavior
Another aspect to the logging is to place logging function calls at various places in the code. This will show you the last know place before the crash and give you a characterization of the device's behavior.

Thomas Matthews
  • 56,849
  • 17
  • 98
  • 154