Welcome to Part 3 of this review of the Pluralsight course Android for .NET Developers: 1 Getting Started by Jim Wilson
Jim has over 30 years of software engineering experience, with the past 15 years heavily focused on creating mobile device and location-based solutions. He has co-founded multiple software-related startups and has served in a consulting role at several more.
After nearly a decade as a Microsoft Device Application Development MVP, Jim now focuses on developing Android and iOS device applications. Jim’s passion is mentoring software developers. He blogs at hedgehogjim.wordpress.com.
Also in this series:
Part 1 – Series Overview
Part 2 – Setting up your environment
Part 3 – Android Toolset Fundamentals
Part 4 – Dalvik Debug Monitor Server
Part 5 – Understanding Android Projects
Part 6 – Android Studio
Part 7 – Understanding Android Versioning
Android Toolset Fundamentals
As a frame of reference Jim begins by discussing the .NET tools architecture: Visual Studio, our App, and our Desktop or Laptop.
Android development is a bit more complex. Android is a Linux-based platform which is optimized to run on a small device. It’s a very different environment from your desktop or laptop.
Jim also says Android is designed not to be tied to any one development environment. He introduces the Android Debug Bridge (ADB). There’s an ADB Server and an ADB Daemon which talk to each other.
The debugging uses a standard protocol called the Java Debuug Wire Protocol.
Jim says having a logging system is very important when doing Android development. The Logcat system is introduced.
The complete diagram is a bit intimidating at first but Jim says a lot of complexity starts getting hidden away once we understand the tools.
Key Android debugging tools
The majority of Android development is handled with 4 tools:
- Android Debug Bridge (ADB)
- Eclipse (or Android Studio)
- Dalvik Debug Monitor Server (DDMS)
For more command line tools see https://developer.android.com/studio/command-line/index.html
Android Debug Bridge
Jim says the Android Debug Bridge is far and away the most important development tool that we have.
It makes interaction between your desktop and device/AVD possible, and provides a command-line interface through the adb utility.
Jim goes over all the details in this lesson, including a look at the adb utility process control commands, and at the adb utility device commands.
For a complete list of features see https://developer.android.com/studio/command-line/adb.html
Multiple connected devices require special handling: you must specify the adb command target.
Walkthrough: Android Debug Bridge
Jim demonstrates using the ADB command line utility. He goes to the installation point and goes into the sdk folder, and then the platform-tools and finds adb.exe
He opens up a command prompt and shows us the commands we can use:
root@android:/ # ls
root@android:/ # ps
>adb -s 014696c40301D016
Jim describes Eclipse as the hub of our development work. It serves as the host user interface for other Android tools such as Logcat and DDMS.
DDMS is a powerful tool and Jim explains this in the next module.
Logcat is the Android logging system. It serves as a message repository, recording information about system events.
Messages written to Logcat using android.util.Log class static methods
They can be easily read and filtered, either via the logcat view within Eclipse, or through the adb utility using the logcat command.
Logcat information is stored as a consistent structure, with the following columns:
– Time stamp
– PID – process Id
– TID – thread id
– Name of source Application
– Tag – And Application defined label intended to identify the system, component or method
Jim runs through the different logcat levels: Silent, Assert, Error, Warning, Info, Debug and Verbose
We log out the most severe messages with the Log.wtf command. WTF stands for “What a terrible failure”
Walkthrough: Logcat filtering
We see the logcat view running within Eclipse. Jim changes the level to control how many messages he sees, and demonstrates how searchable it is.
Typing in “app:com.and” we see only the messages where the Application column starts with “com.android”
We can also read the contents of the Logcat buffers directly on the device by downloading an appropriate app. Jim likes aLogcat by Jeffrey Blattman.
He says it’s not as sophisticated as what you can do in Eclipse, but it’s a cool way to see the content without having to be connected up to a desktop or having access to the developer tools.
Jim explains that Logcat segments messages into buffers, and the overwhelming majority of messages go into the “main” buffer.
There are two special buffers: events, and radio. These are only accessible through the adb command-line utility. Use the logcat command with the -b option.
Walkthrough: Logcat buffers
Jim opens up the command prompt in \sdk\platform-tools\ and types
>adb -d logcat -b radio
We see a lot of messages that we would not otherwise be able to see. Jim says as we evolve through our development and start doing more sophisticated things that rely on the networking, this is important information.
We also see the events buffer:
>adb -d logcat -b events