RAD Studio’s ability to do remote debugging of Android apps on device is fantastic for tracking down issues. However sometimes you have issues where the debugger can’t help. Case in point is one of the projects we were doing for a customer recently. The Android portion included a Service, which needed to be auto-started when the Android device booted. It worked fine if it was started manually, but auto-starting at boot resulted in a crash. We couldn’t use the RAD Studio debugger as it was all over so quickly at boot time. Fortunately we were already logging messages out to the Android logs from within our app, so we were able to track down the problem. How?
Let’s go through the two necessary pieces:
- Logging a Message
- Viewing the Android log
Logging a Message
As a test, I’ve got a simple Android app which has a TEdit and a TSpeedbutton. Whenever the TSpeedbutton is pressed I want to log whatever is typed into the TEdit.
So what goes into the TSpeedbutton.OnClick event? Well, you can muck around with a bunch of Android specific code but none of that is going to work with iOS, Windows, OSX, or Linux. Fortunately, Embarcadero have thought of this and FireMonkey already provides us a cross-platform logging mechanism in the form of the FMX.Types.Log class (note, no T prefix on the classname). There are a few overloaded versions of the Log.d class method, but at its simplest, we can use:
procedure TForm2.SpeedButton1Click(Sender: TObject);
Done! Not sure how it could be much easier.
Viewing the Android Log
There are a couple of different ways to view the log for an Android device. If you’re a command line type, you can use the logcat command inside adb. Start a command prompt and navigate to where adb.exe is installed (in my case it is in C:\Users\Public\Documents\Embarcadero\Studio\18.0\CatalogRepository\AndroidSDK-2433_18.0.25048.9432\platform-tools). Once there, type in the command adb devices to make sure you can see your android device, then type adb logcat. This will give you every message being sent to the log, in realtime. Be prepared for a lot of messages, but it can be very educational to see just what else is going on in your device.
In our case, we wanted to capture the messages from boot, so there is another nice feature. If you type in adb logcat before you’re device is powered on, you’ll get a message saying it is waiting for devices. As soon as your device starts up and connects to adb, you’ll start seeing output.
All that said, there is a nicer way to see the logcat output, which includes search, filtering and more. I’m talking about the built in Monitor tool that comes with your Android SDK. From that platform-tools directory you found before (the one containing adb.exe) go up one directory, and then down into the tools directory (ie. platform-tools and tools are sibling directories). In there you’ll find a monitor.bat file. Run this and you’ll (eventually) get an Eclipse-based GUI that includes a LogCat tab. This is worth the wait for Eclipse to start just for the ability to turn off scrolling and filter messages alone.
Not quite as nice as setting a breakpoint, but in our case much nicer than the other choices we had.