The concept of “bug-free” apps is a myth that hasn’t been proved yet. Regardless of how simple your mobile application is, there are always some users who would experience issues because of unforeseen circumstances. It is almost impossible to reproduce a particular bug in controlled environment that means developers rely on the information provided by the users. However, there are two major issues associated with this approach.
- Most users do not provide logs when they experience a particular issue on their device.
- Even users who go the extra mile and submit a report sometimes do not provide necessary information to reproduce the bug.
If you’re experiencing issues with Printoid and would like to report your problem to the developer, there’s no better way to do it than by capturing a Logcat. Android keeps track of all the commands that have been executed by various apps and services, which means that when something goes wrong, the error is clearly shown in this so-called Logcat.
Most of the time, I will ask you for a Logcat when you submit a bug report, because otherwise, there simply wouldn’t be enough information to get to the root of your problem. So to help you get this issue solved once and for all, I’ll go over two methods below for capturing a Logcat with a rooted device, as well as a non-rooted device.
Once the Logcat has been captured, please send me the file to printoid.for.octoprint@gmail.com
Don’t forget to add as many details as possible in your email to describe your issue!!
- An email with a Logcat but without details is useless for me
- An email without a Logcat but with details is, most of time, not so useful
- An email with Logcat + details = best way to solve the issue as fast as possible!
Method 1: ADB (non-rooted devices)
This first method does not require root access, but there is a bit of manual setup involved. For starters, you’ll need to have a computer and a USB data cable handy, because capturing a Logcat without root requires the use of ADB commands.
Step 1: Configure ADB
To make sure everything goes off without a hitch, you’ll need to have the Android SDK installed on a computer so that you can use the full suite of ADB commands. For instructions on getting the Android SDK and ADB up and running on Windows, Mac, or Linux, see Method 1 in Andrew’s full tutorial at the following link:
On top of that, you’ll need to have “USB debugging” enabled on your Android phone or tablet, and you’ll also need to make sure that you’ve allowed USB debugging access from your computer. For help on getting those two things set up, see my full tutorial at the following link:
Step 2: Change Folder Properties (Windows Only)
From here, Windows users will need to adjust the security properties of their ADB installation folder. To start, navigate to C:\Program Files (x86)\Android\android-sdk\, then right-click the platform-tools folder and choose “Properties.”
Next, click the “Security” tab in the following pop-up window, then select the “Users (Computer\Users)” entry in the first list and click the “Edit” button directly beneath this menu.
From the window that pops up next, select “Users (Computer\Users)” again, then in the menu towards the bottom of this window, tick the “Allow” box next to the “Full control” entry. From here, click “OK” on both pop-up windows, then you’ll be ready to capture a logcat.
Step 3: Capture a Logcat
Once you’ve taken care of that, open a command window in the platform-tools folder inside of your Android SDK installation directory. For Windows users, this can be done by navigating to the platform-tools folder, then holding the Shift key, right-clicking any empty space, and choosing “Open command window here.”
Mac users will need to make sure “New Terminal at Folder” is enabled in their keyboard settings (System Preferences -> Keyboard -> Shortcuts -> Services). Then, just right-click on the platform-tools folder, hover over “Services,” then select “New Terminal at Folder.”
Next, it’s finally time to actually capture your Logcat. This is best done after you’ve experienced a bug that you want to tell the developer about, in a situation where you haven’t rebooted since. So when you’re ready, type the following command and press Enter.
- adb logcat > logcat.txt
After a few moments, your logcat will be generated and saved as a text file. You’ll find the file in the platform-tools folder inside of your Android SDK installation directory, and it will be named “logcat.txt.”
When you’re sending your bug report to the developer, simply attach this file in your email, and the developer will be able to get a clear picture of what went wrong.
Method 2: aLogcat App (Rooted Users Only)
If you’re a rooted user, you have the luxury of being able to avoid ADB altogether, since a nice, simple root app can capture a logcat for you at the press of a button.
Step 1: Install aLogcat from Google Play
There are several apps on the Play Store that claim to be able to capture a logcat without root, but these are only compatible with Android 3.0 or lower. Since 96.8% of Android phones and tablets are running 4.0 or higher, this means you’ll likely need a logcat app that utilizes root. The best such app we’ve found is called [ROOT] aLogcat, and it’s completely free, so head to the following link to get it installed:
Step 2: Capture a Logcat
Once you’ve installed the app, simply open it up and tap “Grant” on the superuser access request. From here, make sure the logcat-capturing service is running by tapping the play/pause button at the top of the screen. Then, once you’ve reproduced the bug that you’d like to report, tap the three-dot menu button and choose “Save” to generate a copy of your Logcat.
The Logcat will be saved as a text file in the aLogcat folder on your SD card or internal storage, so when you’re ready to submit your bug report, simply attach this file in the email.
This tutorial is provided by android.gadgethacks.com
Printoid for OctoPrint 
One thought on “Trick #19: How to report a crash of the app to the developer”