Crash Logs

In the case of severe bugs which lead to a crash of the app, crash logs (log- information about the crash) can be very helpful for the developer.  In the case of crashes which happen sporadically, crash logs are often the only way to find out the problem. Because of this it is important to add crash logs to these bugs. Below you will find instructions of how to get crash logs from your ios and android devices.


The Android Debug Bridge (adb) uses the most reliable way to ask for log-information. If you want to use it you need to install it but it will be very useful for screenshots and screencasts (depending on the android version) in the future. At first the adb installation and the preparation of the device will be described. The adb is part of the Android sdk-tools that can be downloaded here.

SDK-tools are provided as zip-data with the name It is no normal installation- only the archive needs to be decompressed.

Because the decompressed files need to be available on the computer, we recommend saving in the index of users. After doing this you will find a sub folder “platform-tools”, that contains the program adb.

For using adb you have to activate usb-debugging on your device. The exact position in the settings depends on the device.

You can find the relevant point most often under ‘setting options’ in the menu ‘options’ and is called ‘usb-debugging’. There you have to confirm the feature.


Especially for new android versions: it can happen that the setting options are not shown in the settings. To activate them you have to push the build number a few times in the area ‘about the phone’. After that the developer options are offered in the menu (sometimes under ‘systems’).

If you connect your device to the computer now you should be able to access the device per adb. Depending on the device or producer you might be asked to install a certain driver.

You can use the ‘adb devices’ in order to check if your device is shown correctly.

You will need to open the prompt character (windows) or a terminal-window (Mac OS X) and navigate to the above-named file ‘platform-tools’. With Windows you have to open ‘adb.exe devices’, with Mac OS X you open ‘./adb devices’.

A distribution of a correctly identified device looks like this:

If this test got closed successfully the log-distributions can be accessed. The relevant command is called ‘adb.exe logcat’ or ‘./adb logcat’. After this command the buffered log-distribution of the last minutes get distributed and from that all of the arising log-distributions. Because of the brief buffer action you can also retrieve crash logs- if you hurry and if the device was not connected.


You can add the folder ‘platform tools’ to the path so that you do not have to navigate to it every time.

Because the log distributions are very extensive – and can partly contain private information- you should search for the crash point and copy only the relevant one (i.e. In a simple text file) and add it to the bug. However there should not be too much information cut so that the reason of the bug can still be found.

A typical muster for a crash is the so called stacktrace which is often found very easily by the characteristic indent and also by similar line beginnings in the log-flow:

Another possibilty is to search ‘exception’ which is often found in this connection.

In general you can say that such StackTraces often happen with crashes but are not always found. In order to identify the relevant part a search for the app-name might be helpful.

The execution of ‘adb logcat’ can be closed by pushing Strg+C


Crash Logs get put down in seperate files (ending ‘ips’ or ‘crash’) – one file per crash.

The calculated files can be broadcast to the computer very easily via iTunes. It is only necessary to synchronize the device with iTunes. After the synchronization the files are in a defined folder:

Windows XP


The files you can find there are most often named in the way ‘NAME_DATE_TIME’. Instead of app-name it can also be something generic like ‘LowMemory’ – the time of the crash normally shows which file is the correct one.

2 thoughts on “Crash Logs”

    1. Hi,

      I guess that it’s not a real crash but a critical bug if it’s reproducible.

      Kind regards,

      A. Niemeier


Comments are closed.