Logging Your Android Device – The LOGCAT!




Whenever you create an android app or when you develop an Rom , it is important that you must deliver GOOD QUALITY APP or ROM , that are rid of Bugs ..Eventually you might come across a situation when your APP or ROM isn’t working or it is bricking the device or some things are not working .These situation can be tackled only with a proper debugging tools ..So ADB ( android debug bridge) is a powerful Debugging tool and a tool which allows us to step through each line of code and examine the value of each variable.It offers us some of the powerful tools ..Debugging is not a big deal for the people who come from a JAVA programming background .Dalvik VM in android supports java debug wire protocol to attach to the device over ADB

ADB or ANDROID DEBUG BRIDGE is a command-line utility that is often used to communicate over the debug channel with a connected phone or virtual device (emulator). ADB can control your device over USB from a computer, copy files back and forth, install and uninstall apps, run shell commands, and more…

1) Install Java JDK :-

Before installing the Android SDK, you’ll have to install Oracle’s Java development kit. You can download it from here…(click me !!)

Even if you already have the Java runtime (JRE) installed, you’ll need to install the JDK as well.

After installing Java JDK , you can now download the Android SDK from Google .
NOTE:- If you see a any type of Java-related error during installation, then download and install the x86 version of the JDK, not the x64 one ..

2) Installing android SDK:-
Download Android SDK from here…(click me !!!)

After clicking on “DOWNLOAD FOR OTHER PLATFORMS” , you will get an extended menu ..

After downloading the .exe file , then Double click on the .exe file and install it in C:\ Drive or on whichever drive you wanna install .

3) Android SDK Setup
Once the Android SDK is downloaded and installed, launch the SDK Manager application from your Start menu.

Enable the Android SDK tools and SDK Platform-tools checkbox and click the Install button. This downloads and installs the platform-tools package, which contains ADB and other utilities.

After installing these packages , Go to the place where you installed ANDROID SDK . IN MY CASE , IT IS :-

C:\Program files(x86)l\Android\android-sdk\platform-tools

If you used a different install location, you’ll find ADB in the platform-tools directory,inside your ANDROID-SDK directory .

Browse to platform tools and hold Shift and right-click inside it, and select Open command window here…


Note :- To use ADB with your Android device 

1) you must enable USB debugging on it. You’ll find this option under Developer Options on your device’s Settings screen

2)You must install your device drivers :- Individual OEM USB drivers for windows are available for each manufacturer and are listed in the official document ..
After you have downloaded you device drivers, then we have to install on our pc. for that :-

a) connect the device to the computer

b) right click on MY COMPUTER and click manage

c) go to devices > other devices and right click on device and select update driver software.
d) you should see an option to ” BROWSE MY COMPUTER FOR DRIVER SOFTWARE” , which you nedd to click on and point to the location of your device driver installation file..
 To test whether ADB is working properly, connect your Android device to your computer using a USB cable and run the following command:
adb devices

Now it will show the devices connected

Now you have sucessfully installed ADB and now we are good to go further..


Logcat is the command to view the internal logs of the Android system. Viewing logs is often the best way to diagnose a problem, and is required for many issues. This way you’ll find out what apps are doing in the background without you noticing.


Now type this in the terminal

adb logcat -v long > logcat.txt


adb logcat > logcat.txt

you shall have a log file called name of logcat.txt inside your ADB folder.


adb install C:\package.apk

– Installs the package located at C:\package.apk on your computer on your device.
EG -adb install G:\xda.apk

adb uninstall package.name

– Uninstalls the package with package.name from your device.
EG :- you’d use the name com.quoordy.xdadevelopers to uninstall the Xda developers app.

adb push C:\file /sdcard/file

– Pushes a file from your computer to your device. the command here pushes the file located at C:\file on your computer to /sdcard/file on your device .
EG :-adb push G:\system\framework\framework-res.apk /system/framework

adb pull /sdcard/file C:\file

– Pulls a file from your device to your computer – works like adb push, but in reverse. EG :-adb pull /system/app G:\rom\system\app\

adb logcat

– View your Android device’s log. Can be useful for debugging apps.

adb shell

– Gives you an interactive Linux command-line shell on your device.

adb shell command

– Runs the specified shell command on your device.

Dalvik vs. ART: Android Virtual Machines

Dalvik vs. ART: Android Virtual Machines

A huge advantage that devices powered by the Android operating system have over virtually every other OS is the use of a virtual machine in which apps run. Yes, virtual machines, but we’ll get to those in just a moment. What makes all this relevant now is the decision by Google to include a new runtime in Android 4.4 KitKat — one that promises to make your device faster, your battery last longer, and give you thicker, more manageable hair. Wait, not that last one.

Before we jump into this brand new VM, and why it’s turned off by default, let’s make sure everyone understands what we’re talking about.

What’s a virtual machine?

Physical machines are just that: physical. They’re tangible, you can touch them. They’re the computer under your desk, the notebook on your lap, the server in the closet down the hall. When you think of a computer, this is what you’re probably picturing.

Virtual machines?! “Heyya! It’s all ball bearings nowadays!”

Virtual machines aren’t physical, but they do run on physical hardware. Confused yet? Say your desktop computer is a Mac and you’re running some flavor of OS X. You’ve got a couple programs that you want to run that don’t work in your OS. You might want to load up a couple virtual machines and install Windows into one and Linux into another. These virtual machines emulate all the hardware that is needed for you to install and run an operating system. You can literally run a complete Windows environment in a window on your Mac, and the same goes for Linux or almost any other operating system. Pretty cool, eh?

Other than the obvious, one of the main advantages of utilizing a virtual machine is the physical separation of each environment. Apps that run in the VM are separate from those running in the host environment. Viruses, malware, and even crashed apps are all kept apart from your main OS, insulating you from the implications of such occurrences. Another advantage of VMs is the ability to run programs written for one architecture on a box that runs something different. For example, the ability to run programs compiled to run on an ARM-based CPU when your computer is running an Intel-based processor.

To better illustrate that last point, let’s take a look back at Windows Mobile and Pocket PC. Back then developers would write their apps, then compile them for several platforms: ARM version 4, Intel XScale, MIPS, or SH3 CPUs. Each processor had its own advantages and disadvantages, but they all required separately compiled versions of every app that you hoped to run on any one of them. When Pocket PC 2002 was announced, Microsoft standardized on ARM.

Today’s Androids use a specialized virtual machine in which they run their apps. Developers write code which you, the end user, install from the Play Store or some other source. This code is mostly uncompiled. That means it’s slower than compiled code would be, but your device gets the “insulation” advantages that VMs provide, and developers don’t have to worry about re-compiling their code to run on some other CPU — like a new tablet, PC,  TV, watch, or even a rice cooker.


When you install an app on your Android today it will use the Dalvik VM to compile and run it. This process utilizes a concept called just-in-time, or JIT. It’s a great concept, but one that has quite a bit of overhead when you first launch apps.

Let’s take the process apart and see how it works. You download and install an app to your phone or tablet. It sits there on your internal storage until you launch it. When you do, Android pulls all the uncompiled data together, compiles it, and loads the app into memory (RAM). As long as the app is there, after the initial load time, it’s pretty snappy.  If you use a task killer, manually kill the app, or navigate away and load up other apps, the first app is unloaded, freeing up the RAM it had been using. When you go back to it, it’s got to go through the whole process all over again.

ART should increase performance by… “Moon River! … Yeah, breathe easy. Using the whole fist, Doc?!”

Android 4.4 KitKat, at least on the Nexus 5, includes a new runtime call “Android runtime”, ART. Though it’s not a very creative name, it is pretty creative in what it does. Unlike JIT, which must compile every app whenever it’s loaded, ART works on a concept called ahead-of-time (AOT) compilation. With ART, when you download and install an app it automatically pre-compiles. This takes up more space on your device and takes longer to initially install when compared to Dalvik. However, apps launch quicker and are arguably faster when run using ART rather than Dalvik. What’s more, since less time is required to run apps, your processor doesn’t get worked as hard and your battery life may benefit as a result.

All that sounds great, right? It is! Or, rather, it will be.

ART is experimental

ART(Android RunTime) is currently experimental. Very experimental. Not every app works properly in ART, and if you already installed all your apps under Dalvik, you’ll need to reboot and wait up to 20 minutes (less if you have fewer apps, more if you’ve got a bunch) for that first boot to complete. You see, it’s got to pre-compile all of them so they’re ready for you. Basically it pre-compiles them into a format called OAT. You see the default RT is Dalvik which uses the ODEX files. So when you switch to ART, it has to convert all these ODEX files to OAT. For all of those reasons, ART is disabled by default.
Excerpt from XDA : Switching from Dalvik to ART switches from the libdvm.so library to libart.so. And rather than the ODEX files read by the Dalvik VM, ART appears to use OAT files. Accordingly, Android 4.4 source also includes a dex2oat program  to convert ODEX files into OAT files compatible with ART.

Experimental? No more than a white guy with an afro playing for the Lakers!

The benefits? Some sources are reporting a 50% increase in speed. Others say it’s closer to 100%. Many claim they’ve seen their battery life increase by 25% or more! Still more say that all of this is likely just a placebo effect, and the reality is much less noticeable. So, we’re not going to go on the record with a bunch of synthetic benchmark scores between Dalvik and ART, nor are we going to claim you’ll see a huge improvement in everything. Not right now anyway.

Sure, I tried ART for a few days. It was fabulous, and horrible, and not noteworthy — all at the same time. Feel free to try it out yourself, just don’t expect that it will be fantastic. Not now.

AOT compilation is the future, and ART is the way Google is going to get us there. This is just the first little step toward a much more lofty goal. Perhaps ART will be the standard runtime in Android 5.0?

Your turn

Have you played with ART on your Nexus 5? Did you notice anything good, bad, or ugly? Let us know your experience with AOT compilation in the comments below!