A Beginner’s Guide to Android Kernels

When people mention the advantages of rooting, one of those words that get thrown around a lot is “kernel.” When I first started looking into rooting, I was never quite sure what a kernel exactly was. Obviously it wasn’t a piece of popcorn, but nobody ever sufficiently explained what a it did and why I should be interested in them.

However, once I did figure out what they were it certainly changed my attitude toward them. Swapping out your kernel is one of the best ways to take advantage of rootingand I highly, highly recommend you try it. With the right kernel, you can double your battery life or squeeze it for that extra performance. Understanding this concept is very helpful, and here’s why.

Alright, What’s a Kernel?

The term kernel comes from Linux, which is kind of the forerunner of Android. All Android phones come with a kernel installed on them. It is the communication link between hardware and software. One of its most important functions is Battery usage and the kernel dictates the life of your phone battery.

Your phone ships with the stock kernel. Phone manufacturers like HTC and Samsung are not exactly known for their willingness to take risks. The stock kernel put in your phone by the manufacturers is nice and safe that won’t ever break down.


The stock kernel provides a constant stream of battery power to the phone. It doesn’t matter if the phone is on or off or using lots of processing power. It sends a steady and totally safe amount of battery.

However, that safety comes with a price. A phone with the stock kernel uses the same amount of power even when not in use. That’s not very efficient. Plus, what if you want to run a processing-intensive app like an N64 emulator? More processing requires more power, but the stock kernel won’t scale up the amount of battery used.

New and Improved Kernels

This is where the Android community comes in. If you’re rooted and have some sort of recovery system like ClockworkMod or Amon-Ra installed, you can flash (install) a new kernel that’s more efficient.

The advantage of custom one is that they can output variable amounts of power. Say you want to save the battery. You can undervolt the phone’s processor. Undervolting is when you tell the kernel to only provide a tiny amount of power for the phone to run.


Undervolting does make your phone lag quite a lot, but its ability to save battery is incredible. I doubled my phone’s battery life with undervolting. A phone modified in this way with a custom kernel can seriously go days without charging.

Alternatively, you can overclock a phone. This is when the kernel outputs large amounts of power, amounts higher than the phone usually uses. This will eat through a battery extremely quickly, but it is great for apps that would lag otherwise (like N64 emulators). Not to mention everything loads extremely quickly when a phone is overclocked.

There are a few risks to installing a new kernel. If you tell it to use an amount of battery that’s too small, there is a chance that the phone won’t be able to turn on. This is called bootlooping, or when the phone cannot access enough power in order to start itself. However, there is a way around bootlooping, as we will discuss later.

Picking a Kernel

There are a million different options out there. That’s probably a good thing, seeing as there are about a million different phone-ROM combinations with Android. Finding a good one for your specific phone and ROM can be a bit difficult, though.

I recommend starting with Kernel Manager Lite. It’s a free app from the Android Market that will list out a couple popular kernels for some of the more popular ROMs like CyanogenMod7 and MIUI.


When deciding a kernel, people will throw a lot of different terms at you. You’ll see abbreviations like CFS, HAVS, and SBC. Keeping track of what everything means is a chore, so we’ll summarize.

Each abbreviation and item like overclocking and undervolting is a power mode that comes with that kernel.CFSHAVS, and BFS are all power plans that scale the amount of power used up and down, depending on how much battery your phone requests. Each plan scales differently (faster or slower), but the concept is the same.

Terms Commonly Used with Kernels:

  • Completely Fair Scheduler (CFS) is generally more consistent and stable. Stock HTC kernel uses CFS.
  • Brain F*** Scheduler (BFS) is faster and generally gives more battery life but may be a bit inconsistent.
  • Hybrid Adaptive Voltage Scaling (HAVS) manipulates the phone voltage for a better battery life. Performance usually varies for different devices.
  • Static Voltage Scaling (SVS) provides a steady voltage.

You might also see SBC. That stands for Superior Battery Charging. Most phones battery percentage drops to 90% or so right after you unplug it due to the fast rate of charging. SBC charges a battery very slowly it doesn’t lose 10% immediately. Best used for charging phones overnight.


Undervolting and underclocking are different things but basically accomplish the same thing (saving battery). Overclocking is already explained.

When looking for a kernel, ideally you want one with as many of these features as possible. It’s nice to have choices. A good kernel comes at least undervolting, overclocking, and some sort of scaling plan (like CFS/HAVS/BFS).

If you don’t find any in Kernel Manager that look good, the last resort is lots of Googling. Just search “(your phone) (your ROM) kernels” and something from XDA Developers should come up.

Installing (Flashing) The Kernel:

Once you’ve found that perfect kernel that is compatible with your phone model and ROM, you have to actually install it. Download the kernel from whatever website or Kernel Manager. It should come as a .zip file. Copy that over to your SD card.

For installing a kernel, there are two options. If you pay for Kernel Manager Pro, the app will install the kernel for you. That’s the nice and easy way.


However, it’s not too hard to install a kernel without Kernel Manager. I wouldn’t recommend buying the Pro version. The other way to do it involves booting into recovery. If you don’t know how to do that on your phone, CM7’s wiki has a handy chart.

Once in recovery there are a few things that have to be done to prepare the way for the kernel. First and most importantly, make a nandroid backup of your phone. If anything goes wrong or if the phone gets stuck in an endless bootloop, this is how to fix it. Backups are very important.

There should be an option to “wipe cache.” Choose this and let it run. Next wipe the Dalvik cache. If you don’t see either of those options, look under “advanced” in ClockworkMod.

Now choose to install a .zip and choose the option to pick one from the SD card. Navigate to wherever you put the downloaded kernel. Pick the kernel and let it install. Once it’s finished, reboot your phone.


If everything went right, then you should have a new kernel. You can check by going to Settings > About phone > Software information and looking under “Kernel.” Hopefully, you’ll see the name of whatever kernel you flashed. Next step, controlling the kernel.

Apps for Kernel Management:

The kernel can work its magic now that it’s installed. However, you have to tell it to do so first. You can manually control it from the settings with certain ROMs like CyanogenMod. Everyone else will need third-party apps like SetCPU and Tasker.

SetCPU is simple and it works. Just tell it which power plan (undervolt, overclock, etc) you want to use and it does it for you. SetCPU works just fine with no glitches or anything. Just be careful how high you set the voltage- I crashed my phone once by overclocking it a little too much.


However, Tasker is my personal favorite app for the various purposes of controlling my kernel. Tasker automates certain processes, including kernel management. The best feature here is that you can set to app to automatically undervolt your phone every time the screen is off (like when you’re not using the phone).

This small change makes a titanic difference. Now my phone only uses a fraction of its battery power when it sits in my pocket. Instead of lasting about a day on a full charge, I can go twice as long without going near a power cord.

Of course, the ultimate judge of battery is how often you use your phone and how rigorously that usage gets. However, automated undervolting is a fantastic way to cut down on battery drain.

Final Thoughts

Installing a new kernel can be a bit dicey, but when done correctly there’s really a minimal risk. As long as you make a nandroid backup, there’s no reason to not try flashing a new, more efficient kernel. Besides, if you’re scared of diving into recovery mode you can just get Kernel Manager Pro to do the work for you.

Reference : http://www.vikitech.com/8239/beginners-guide-android-kernels

What is a kernel?

Android A to Z

What is a kernel?  If you spend any time reading Android forums, blogs, how-to posts or online discussion you’ll soon hear people talking about the kernel.  A kernel isn’t something unique to Android — iOS and MacOS have one, Windows has one, BlackBerry’s QNX has one, in fact all high level operating systems have one.  The one we’re interested in is Linux, as it’s the one Android uses. Let’s try to break down what it is and what it does.

Android devices use the Linux kernel, but it’s not the exact same kernel other Linux-based operating systems use.  There’s a lot of Android specific code built in, and Google’s Android kernel maintainers have their work cut out for them.  OEMs have to contribute as well, because they need to develop hardware drivers for the parts they’re using for the kernel version they’re using.  This is why it takes a while for independent Android developers and hackers to port new versions to older devices and get everything working.  Drivers written to work with the Gingerbread kernel on a phone won’t necessarily work with the Ice Cream Sandwich kernel.  And that’s important, because one of the kernel’s main functions is to control the hardware.  It’s a whole lot of source code, with more options while building it than you can imagine, but in the end it’s just the intermediary between the hardware and the software.

When software needs the hardware to do anything, it sends a request to the kernel.  And when we sayanything, we mean anything.  From the brightness of the screen, to the volume level, to initiating a call through the radio, even what’s drawn on the display is ultimately controlled by the kernel.  For example — when you tap the search button on your phone, you tell the software to open the search application.  What happens is that you touched a certain point on the digitizer, which tells the software that you’ve touched the screen at those coordinates.  The software knows that when that particular spot is touched, the search dialog is supposed to open.  The kernel is what tells the digitizer to look (or listen, events are “listened” for) for touches, helps figure out where you touched, and tells the system you touched it.  In turn, when the system receives a touch event at a specific point from the kernel (through the driver) it knows what to draw on your screen.  Both the hardware and the software communicate both ways with the kernel, and that’s how your phone knows when to do something.  Input from one side is sent as output to the other, whether it’s you playing Angry Birds, or connecting to your car’s Bluetooth.

It sounds complicated, and it is.  But it’s also pretty standard computer logic — there’s an action of some sort generated for every event.  Without the kernel to accept and send information, developers would have to write code for every single event for every single piece of hardware in your device.  With the kernel, all they have to do is communicate with it through the Android system API’s, and hardware developers only have to make the device hardware communicate with the kernel.  The good thing is that you don’t need to know exactly how or why the kernel does what it does, just understanding that it’s the go-between from software to hardware gives you a pretty good grasp of what’s happening under the glass.  Sort of gives a whole new outlook towards those fellows who stay up all night to work on kernels for your phone, doesn’t it?

Reference : http://www.androidcentral.com/android-z-what-kernel

Reversing Android Apps

First blog post in a long time, so I figured I should start back off with something I’ve been getting a lot of questions about lately, which is how to get started with learning more about Android application security.

I think the absolute best way to understand what’s going on is to start looking at real world applications. This tutorial will show you how to download an Android application and convert it back into a format that we prefer, which is its original Java code. Hopefully this will be the first tutorial of many, so be sure to check back from time to time.

I hope this post can be of use to developers as well, in order to better understand that the code they allow to be distributed on mobile devices can easily be decompiled. If you are storing hardcoded credentials or reference other things you don’t want the user (or bad guys) to know about, you should re-evaluate that design choice.

My disclaimer is that this should not be used for malicious purposes, etc etc and all of the other stuff no one will likely listen to.

To get started, you will need these applications on your box:

Android SDK
apktool (JAR and dependencies)
JD (or a similar Java decompiler)

The first step is to download the Android SDK (Software Development Kit). You will rely on this heavily when testing applications and interacting with Android devices. There are many useful utilities bundled with it including Android Debug Bridge (ADB) and the emulator.

The next step is to download an interesting application to rip open. Most of us are Twitter fans, so why don’t we take a look at the Twitter application for Android?

At this point, you have 2 choices:

-Download it to your physical Android device
-Download it to a virtual device running in the Android emulator

By default, the virtual devices available using the emulator that comes with the Android SDK do not have the Google Market application installed. You can either 1) spend time finding ways around this or 2) install an image that has the software pre-loaded. Here is an excellent tutorial on how to go that route, although you may want to use a more up to date image than the ones referenced. They use older versions of Android.

Android Emulator Tutorial

Assuming you have either plugged your phone in or started an Android virtual machine, in the tools folder of the Android SDK folder, you’ll find several utilities incuding ADB. I recommend familiarizing yourself with it, as you will use it almost constantly if you are working with the Android platform.

ADB allows us to do many things including connect to the device and have shell access. We first need to figure out where the application we downloaded is stored. Under the /data/app/ directory, we will find all of the APK files for applications we’ve downloaded. Under /system/app is all of the applications included with your Android distribution. For this tutorial, we are concerned with /data/app as this is where our Twitter application will be located.

Now that we know what we want to download, we need to transfer the file to our local system for further analysis. This can be achieved also by using ADB.

We will not be using the shell this time, but rather the “pull” command which allows us to select and retrieve files from the Android device. The general format for this command is: adb pull apk_file destination_directory

Now that we have the APK file, we’ll need to unzip it. The APK is simply in standard ZIP format, so any of your existing ZIP compatible utilities will work.

After unzipping the APK file, there are two things you should be primarily concerned with at this point: looking at the manifest file, and getting the .DEX file into a more desirable format to work with. The manifest contains juicy information like permissions, intent filters, and lots more. If you aren’t familiar with the manifest file and how its used with Android applications, I highly recommend reading the documentation on the Android development site:

Manifest Intro

If you try to open the AndroidManifest.xml file that was just unzipped, you’ll find that it isn’t in plain text. We’ll use apktool at this point to convert it into a format we are comfortable with. We’ll use apktool to decode the entire APK, and then the manifest file should be much easier on the eyes:

After running apktool, this is what the AndroidManifest.xml file should look like when viewed in a text editor or Eclipse:

The classes.dex file in the originally unzipped APK file is the crown jewel here. It contains all of the application’s code, but in the Dalvik Executable format.

There are tools such as dedexer and apktool that will convert .DEX into smali assembly format, but again we are concerned with looking at the Java code. We can use dex2jar to achieve this:

dex2jar.bat path_to_classes.dex

Once we’ve run dex2jar, there will be a classes.dex.dex2jar.jar file in the folder where the original .DEX file was located. Simply unzip this JAR file. Upon unzipping it, we see a bunch of .class files.

Nothing to worry about, this is familiar territory at this point. Simply use your favorite Java decompiler to convert from bytecode to easily readable code.

We now have complete access to the entire client application. In the tutorials to come, I’ll show you some things you should be paying close attention to when reviewing or designing an Android application.


Reference : http://jack-mannino.blogspot.com/2010/09/reversing-android-apps-101.html

Android Cloud to Device Messaging Framework

Android Cloud to Device Messaging (C2DM) is  a   service that helps developers  send data from servers to their applications on  Android devices. The  service provides a simple, lightweight mechanism that servers can use  to tell mobile applications to contact the server directly, to fetch  updated application or user data. The C2DM service handles all aspects  of queueing of messages and delivery to the target application running  on the target device.


Here are the primary characteristics of Android Cloud to Device  Messaging (C2DM):

  • It allows third-party application servers to send lightweight messages to their Android applications. The messaging service is not designed for sending a lot of user content via the messages. Rather, it should be used to tell the application that there is new data on the server, so that the application can fetch it.
  • C2DM makes no guarantees about delivery or the order of messages. So, for example, while you might use this feature to tell an instant messaging application that the user has new messages, you probably would not use it to pass the actual messages.
  • An application on an Android device doesn’t need to be running to receive messages. The system will wake up the application via Intent broadcast when the the  message arrives, as long as the application is set up with the proper broadcast receiver and permissions.
  • It does not provide any  built-in user interface or other handling for message data. C2DM  simply passes raw message data received straight to the application,  which has full control of how to handle it. For example, the application might post a notification, display a custom user interface, or  silently sync data.
  • It requires devices running Android 2.2 or higher that also have the Market application installed. However, you are not limited to deploying your applications through Market.
  • It uses an existing connection for Google services. This requires users to set up their Google account on their mobile devices.

Architectural Overview

This section gives an overview of how C2DM works.

This table summarizes the key terms and concepts involved in C2DM. It is divided into these categories:

  • Components — The physical entities that play a role in C2DM.
  • Credentials — The IDs and tokens that are used in different stages of C2DM to ensure that all parties have been authenticated, and that the message is going to the correct place.
Mobile Device The device that is running an Android application that uses C2DM. This must be a 2.2 Android device that has Market installed, and it must have at least one logged in Google account.
Third-Party Application Server An application server that  developers  set up as part of implementing C2DM in their applications. The third-party application server sends data to an Android application on the device via the C2DM server.
C2DM Servers The Google servers involved in taking messages from the third-party application server and sending them to the device.
Sender ID An email account associated with the application’s developer. The sender ID is used in the registration process to identify a Android application that is permitted to send messages to the device. This ID is typically role-based rather than being a personal account—- for example,my-app@gmail.com.
Application ID The application that is registering to receive messages. The application is identified by the package name from the manifest. This  ensures that the messages are targeted to the correct application.
Registration ID An ID issued by the C2DM servers to the Android application that allows it to receive messages. Once the application has the registration ID, it sends it to the third-party application server, which uses it to identify each device  that has registered to receive messages for a given application. In other words, a registration ID is tied to a particular application running on a particular device.
Google User Account For C2DM to work, the mobile device must include at least one logged in Google account.
Sender Auth Token A ClientLogin Auth token that is saved on the third-party application server that gives the application server authorized access to Google services. The token is included in the header of POST requests  that send messages. For more discussion of ClientLogin Auth tokens, see ClientLogin for Installed Applications.

Lifecycle Flow

Here are the primary processes involved in cloud-to-device messaging:

  • Enabling C2DM. An Android application running on a mobile device registers to receive messages.
  • Sending a message. A third-party application server sends messages to the device.
  • Receiving a message. An Android application receives a message from a C2DM server.

These processes are described in more detail below.

Enabling C2DM

This is the sequence of events that occurs when an Android application running on a mobile device registers to receive messages:

  1. The first time the application needs to use the messaging service, it fires off a registration Intent to a C2DM server.This registration Intent (com.google.android.c2dm.intent.REGISTER)  includes the sender ID (that is, the account authorized to send messages to the  application, which is typically the email address of an account set up by the  application’s developer), and the application ID.
  2. If the registration is successful, the C2DM server broadcasts aREGISTRATIONIntent which gives the application  a registration ID.The application should store this ID for later use. Note that Google may periodically refresh the registration ID, so you should design your application with the understanding that the REGISTRATION Intent may be called multiple times. Your application needs to be able to respond accordingly.
  3. To complete the registration, the application sends the registration ID to the application server. The application server typically stores the registration ID in a database.

The registration ID lasts until the application explicitly unregisters itself, or until Google refreshes the registration ID for your application.

Sending a Message

For an application server to send a  message, the following things must be in place:

  • The application has a registration ID that allows it to receive messages for a particular device.
  • The third-party application server has stored the registration ID.

There is one more thing that needs to be in place for the application server to send messages:  a ClientLogin authorization token. This is something that the developer must have already set up on the application server for the application (for more discussion, seeRole of the Third-Party Application Server). Now it will get used to send messages to the device.

The ClientLogin token authorizes the application server to send messages to a particular Android application. An application server has one ClientLogin token for a particular 3rd party app, and multiple registration IDs. Each registration ID represents a particular device that has registered to use the messaging service for a particular 3rd party app.

Here is the sequence of events that occurs when the application server sends a  message:

  1. The application server sends a  message to  C2DM servers.
  2. Google enqueues and stores the message in case the device is inactive.
  3. When the device is online, Google sends the message to the device.
  4. On the device, the system  broadcasts the  message to the specified application via Intent broadcast with proper permissions, so that only the targeted application gets the message. This wakes the application up. The application does not need to be running beforehand to receive the message.
  5. The application processes the message. If the application is doing non-trivial processing, you may want to grab a wake lock and do any processing in a Service.

An application can  unregister C2DM if it no longer wants to receive  messages.

Receiving a Message

This is the sequence of events that occurs when an Android application running on a mobile device receives a message:

  1. The system receives the incoming message and extracts the raw key/value pairs from the message payload.
  2. The system passes the key/value pairs to the targeted Android application in a com.google.android.c2dm.intent.RECEIVE Intent as a set of extras.
  3. The Android application extracts the raw data from the RECEIVE Intent by key and processes the data.

What Does the User See?

When mobile device users install an applications that include C2DM, they will get a permission from Android Market informing them that the application includes C2DM. They must approve the use of this feature to install the application. Depending on the implementation of the application, it may offer users the option of unregistering to receive messages. Uninstalling the application also has the effect of unregistering.

Writing Android Applications that Use C2DM

To write Android applications that use C2DM, you must have an application server that can perform the tasks described in Role of the Third-Party Application Server. This section describes the steps you take to create a client application that uses C2DM.

Remember that there is no user interface associated with the C2DM Framework. However you choose to process messages in your application is up to you.

There are two primary steps involved in writing a client application:

  • Creating a manifest that contains the permissions the application needs to use C2DM.
  • Implementing your Java code. To use C2DM, this implementation must include:
    • Code to start and stop the registration service.
    • Receivers  for com.google.android.c2dm.intent.C2D_MESSAGEand com.google.android.c2dm.intent.REGISTRATION.

Creating the Manifest

Every application must have an AndroidManifest.xml file (with precisely that   name) in its root directory.  The manifest presents essential information about   the application to the Android system, information the system must have before   it can run any of the application’s code (for more discussion of the manifest file, see the Android Developers Guide). To use the C2DM feature, the manifest must include the following:

  • com.google.android.c2dm.permission.RECEIVE states that the application has permission register and receive messages.
  • android.permission.INTERNET states that the application has permission to send the receiver key to the 3rd party server.
  • applicationPackage + ".permission.C2D_MESSAGE prevents other applications from registering and receiving the application’s messages.
  • Receivers for com.google.android.c2dm.intent.RECEIVE andcom.google.android.c2dm.intent.REGISTRATION, with the category set as applicationPackage. The receiver should require thecom.google.android.c2dm.SEND permission, so that only the C2DM Framework can send it the message. Note that both registration and the receiving of messages are implemented as Intents.
  • If the C2DM feature is critical to the application’s function, be sure to set android:minSdkVersion="8" in the manifest. This ensures that the application cannot be installed in an environment in which it could not run properly.

Received C2D_MESSAGE Intents  have all key/value pairs sent by the 3rd party server as extras. One special key is collapse_key, which is specified by the sender to allow handling of messages waiting for an off-line device.

Here are excerpts from a manifest that supports C2DM:

<manifest package="com.example.myapp" ...>
   <!-- Only this application can receive the messages and registration result -->     <permission android:name="com.example.myapp.permission.C2D_MESSAGE" android:protectionLevel="signature" />    <uses-permission android:name="com.example.myapp.permission.C2D_MESSAGE" />
   <!-- This app has permission to register and receive message -->    <uses-permission android:name="com.google.android.c2dm.permission.RECEIVE" />
   <!-- Send the registration id to the server -->    <uses-permission android:name="android.permission.INTERNET" />
   <application...>       <!-- Only C2DM servers can send messages for the app. If permission is not set - any other app can generate it -->        <receiver android:name=".C2DMReceiver" android:permission="com.google.android.c2dm.permission.SEND">           <!-- Receive the actual message -->           <intent-filter>               <action android:name="com.google.android.c2dm.intent.RECEIVE" />               <category android:name="com.example.myapp" />           </intent-filter>           <!-- Receive the registration id -->           <intent-filter>               <action android:name="com.google.android.c2dm.intent.REGISTRATION" />               <category android:name="com.example.myapp" />           </intent-filter>       </receiver>       ...    </application>    ... </manifest>

Registering for C2DM

An Android application needs to register with  C2DM servers before receiving any message. To register it needs to send an Intent (com.google.android.c2dm.intent.REGISTER), with 2 extra parameters:

  • sender is the ID of the account authorized to send messages to the application, typically the email address of an account set up by the application’s developer.
  • app is the application’s ID, set with a PendingIntent to allow the registration service to extract application information.

For example:

Intent registrationIntent = new Intent("com.google.android.c2dm.intent.REGISTER"); registrationIntent.putExtra("app", PendingIntent.getBroadcast(this, 0, new Intent(), 0)); // boilerplate registrationIntent.putExtra("sender", emailOfSender); startService(registrationIntent);

Registration is not complete until the application sends the registration ID to the third-party application server. The application server  uses the registration ID to send messages that are targeted to the application running on that particular device.

Unregistering from C2DM

To unregister from C2DM:

Intent unregIntent = new Intent("com.google.android.c2dm.intent.UNREGISTER"); unregIntent.putExtra("app", PendingIntent.getBroadcast(this, 0, new Intent(), 0)); startService(unregIntent);

Handling Registration Results

As discussed in Creating the Manifest, the manifest defines a receiver for com.google.android.c2dm.intent.REGISTRATION. It also defines a receiver forcom.google.android.c2dm.intent.RECEIVE. Note that both registration and the receiving of messages are implemented as Intents.

The main use of REGISTRATION is to allow the application to receive the registration  ID. The Intent can be sent at any time. Google may periodically refresh the receiver ID. An application receiving this Intent with a registration_id parameter must ensure that the third-party application server receives the registration ID. It may do so by saving the registration ID and sending it to the server. If the network is down or there are errors, the application should retry sending the registration ID  when the network is up again or the next time it starts. An application should keep track of its registration status and attempt to register again if the process is not fully completed.

The REGISTRATION Intent is generated with an errorparameter if the registration couldn’t be completed. If that happens, the application should try again later with exponential back off. When the application unregisters, the REGISTRATION Intent will be sent with an unregistered extra parameter.

Here are the possible error codes for the REGISTRATIONIntent:

Error Code Description
SERVICE_NOT_AVAILABLE The device can’t read the response, or there was a 500/503 from the server that can be retried later. The application should use exponential back off and retry.
ACCOUNT_MISSING There is no Google account on the phone.  The application should ask the user to open the account manager and add a Google account. Fix on the device side.
AUTHENTICATION_FAILED Bad password. The application should ask  the user to enter his/her password, and let user retry manually later. Fix on the device side.
TOO_MANY_REGISTRATIONS The user has too many applications registered.  The application should tell the user to uninstall some other applications, let user retry  manually. Fix on the device side.
INVALID_SENDER The sender account is not recognized.
PHONE_REGISTRATION_ERROR Incorrect phone registration with Google. This phone doesn’t currently support C2DM.

The application receives a REGISTRATION Intent broadcast whenever the application server attempts to send a message to it. But  registration IDs can be nonexistent or invalid for a variety of reasons:

  • If an application is running for the first time, it has no registration ID yet.
  • If the application unregistered, it has no registration ID.
  • The C2DM server periodically refreshes registration IDs.

An application must be prepared to handle every case. For example:

public void onReceive(Context context, Intent intent) {     if (intent.getAction().equals("com.google.android.c2dm.intent.REGISTRATION")) {         handleRegistration(context, intent);     } else if (intent.getAction().equals("com.google.android.c2dm.intent.RECEIVE")) {         handleMessage(context, intent);      }  }
private void handleRegistration(Context context, Intent intent) {     String registration = intent.getStringExtra("registration_id");      if (intent.getStringExtra("error") != null) {         // Registration failed, should try again later.     } else if (intent.getStringExtra("unregistered") != null) {         // unregistration done, new messages from the authorized sender will be rejected     } else if (registration != null) {        // Send the registration ID to the 3rd party site that is sending the messages.        // This should be done in a separate thread.        // When done, remember that all registration is done.      } }

Handling Received Data

When the C2DM server receives a message from the third-party application server, C2DM extracts the raw key/value pairs from the message payload and passes them to the Android application in thecom.google.android.c2dm.intent.RECEIVE Intent as a set of extras. The application extracts the data by key and processes it, whatever that means for that application.

Here is an example:

protected void onReceive(Context context, Intent intent) {     String accountName = intent.getExtras().getString(Config.C2DM_ACCOUNT_EXTRA);     String message = intent.getExtras().getString(Config.C2DM_MESSAGE_EXTRA);     if (Config.C2DM_MESSAGE_SYNC.equals(message)) {         if (accountName != null) {             if (Log.isLoggable(TAG, Log.DEBUG)) {                 Log.d(TAG, "Messaging request received for account " + accountName);             }                          ContentResolver.requestSync(                 new Account(accountName, SyncAdapter.GOOGLE_ACCOUNT_TYPE),                 JumpNoteContract.AUTHORITY, new Bundle());         }     } }

Developing and Testing Your Applications

Here are some guidelines for developing and testing an Android application that uses the C2DM feature:

  • To develop and test your C2DM applications, you need to run and debug the applications on an Android 2.2 system image that includes the necessary underlying Google services.
  • To develop and debug on an actual device, you need a device running an Android 2.2 system image that includes the Market application.
  • To develop and test on the Android Emulator, you need to download the Android 2.2 version of the Google APIs Add-On into your SDK using the Android SDK and AVD Manager. Specifically, you need to download the component named “Google APIs by Google Inc, Android API 8”. Then, you need to set up an AVD that uses that system image.
  • If the C2DM feature is critical to the application’s function, be sure to set android:minSdkVersion="8" in the manifest. This ensures that the application cannot be installed in an environment in which it could not run properly.

Role of the Third-Party Application Server

Before you can write client applications that use the C2DM feature, you must have an HTTPS application server that meets the following criteria:

  • Able to communicate with your client.
  • Able to  fire off HTTP requests to the C2DM server.
  • Able to handle requests and queue data as needed. For example, it should be able to perform exponential back off.
  • Able to store the ClientLogin Auth token and client registration IDs. The ClientLogin Auth token  is included in the header of POST requests that send messages. For more discussion of this topic, see ClientLogin for Installed Applications. The server should store the token and have a policy to refresh it periodically.

How the Application Server Sends Messages

This section describes how the third-party application server sends messages to a 3rd party client application running on a mobile device.

Before the third-party application server can send a  message to an application, it must have received a registration ID from it.

To send a  message, the application server issues a POST request tohttps://android.apis.google.com/c2dm/send that includes the following:

Field Description
registration_id The registration ID retrieved from the Android application on the phone. Required.
collapse_key An arbitrary string that is used to collapse a group of like messages when the device is offline, so that only the last message gets sent to the client. This is intended to avoid sending too many messages to the phone when it comes back online. Note that since there is no guarantee of the order in which messages get sent, the “last” message may not actually be the last message sent by the application server. Required.
data.<key> Payload data, expressed as key-value pairs. If present, it will be included in the Intent as application data, with the <key>. There is no  limit on the number of key/value pairs, though there is a limit on the total size of the  message. Optional.
delay_while_idle If included, indicates that the message should not be sent immediately if the device is idle. The server will wait for the device to become active, and then only the last message for each collapse_key value will be sent. Optional.
Authorization: GoogleLogin auth=[AUTH_TOKEN] Header with a ClientLogin Auth token. The cookie must be associated with the ac2dm service. Required.

This table lists the possible response codes:

Response Description
200 Includes body containing:

  • id=[ID of sent message]
  • Error=[error code]
    • QuotaExceeded — Too many messages sent by the sender. Retry after a while.
    • DeviceQuotaExceeded — Too many messages sent by the sender to a specific device. Retry after a while.
    • InvalidRegistration — Missing or badregistration_id. Sender should stop sending messages to this device.
    • NotRegistered — The registration_idis no longer valid, for example user has uninstalled the application or turned off notifications. Sender should stop sending messages to this device.
    • MessageTooBig — The payload of the message is too big, see the limitations. Reduce the size of the message.
    • MissingCollapseKey — Collapse key is required. Include collapse key in the request.
503 Indicates that the server is temporarily unavailable (i.e., because of timeouts, etc ). Sender must retry later, honoring any Retry-Afterheader included in the response. Application servers must implement exponential back off. Senders that create problems risk being blacklisted.
401 Indicates that the ClientLoginAUTH_TOKEN used to validate the sender is invalid.


Here are a few complete examples to get you started:

  • JumpNote. JumpNote is a sample two-way notes application, with auto-sync. JumpNote shows how to use the Android Cloud to Device Messaging Framework, as well as the Android Sync framework. JumpNote runs on top of Google App Engine, and it uses GWT for the web user interface.
  • Google Chrome to Phone Extension. “Chrome to Phone” lets  users send content from the Chrome browser to their mobile device.

To view the source code, open the Source tab and click Browse. From there, you can navigate through the source  tree.


C2DM imposes the following limitations:

  • The message size limit is 1024 bytes.
  • Google limits the number of messages a sender sends in aggregate, and  the number of messages a sender sends to a specific device

Reference : https://developers.google.com/android/c2dm/

How to Implement Push Notifications for Android


It’s been around 4 months now since I’ve started developing apps on the Android platform. It began with me scoring a free Nexus One phone at one of the Android Developer Labs.  Obviously, I couldn’t resist trying to hack around with some code, so I downloaded the SDK and dove in. I guess in some sense, that’s exactly what Google was hoping for when they starting giving out free phones. While it might sound like I got lucky, in the end Google is the one who won.

Anyway, developing for the Android platform turned out to the a pleasure. The SDK was easy to setup, easy to use and and easy to understand. Putting together your first app was a breeze. I was very impressed.

Unfortunately, I soon realized that Android is not perfect. One of the things that really disappointed me was the lack of a native method for performing push notifications. Over the past year push notifications became almost a standard in the mobile space thanks to Apple. Even though BlackBerry utlilized Push since god knows when, it was Apple that really brought Push mainstream. Obviously, lack of native Push on Android seems like a huge drawback. Naturally, I started looking around for a solution. After Googling through dozens and dozens of blogs and message boards, I’ve realized that there are 3 generally accepted ways to implement push notifications for your Android app. All of which are non-trivial, hacky and have their own disadvantages. Let’s go over the list:

  • Poll? The name obviously tells you that it’s really not even push. The idea here is to periodically poll the server for new messages from a background local or remote service. The more often you poll the closer you get to the real-time push.
Advantages: easy to implement. no cost solution
Disadvantages: Obviously, you will never be actually real-time. If you polling interval is 30 min, you can get a message that is 29 minutes and 59 seconds late. Moreover, polling more often than every 15-30 min will kill your battery pretty quickly: https://labs.ericsson.com/apis/mobile-java-push/blog/save-device-battery-mobile-java-push
  • SMS Android allows you to intercept SMS messages. Your server sends a specially encoded SMS to your phone, whenever there is something new. Your app intercepts all messages, looks for the ones from the server, then pops up a notification.
Advantages: easy to implement. Fully real-time updates. Known drop-in solutions exist such as one provided by Ericsson  Labs: https://labs.ericsson.com/apis/mobile-java-push/
Disadvantages: Can be costly to you and the user. There are only a few services that allow you send around free SMS and even those are often limited to North America. If you want to have a reliable SMS-based service that is available worldwide, you will likely need to pay. Similar goes for the users. Not everyone has an SMS plan and you don’t want your users getting charged by 3rd party for using your app.
  • Persistent TCP/IP The phone initiates a long-lived mostly idle TCP/IP connection with the server and maintains it by occasionally sending keepalive messages. Whenever there is something new on the server, it sends a messages to the phone over the TCP connection.
Advantages: Fully real-time updates.
Disadvantages: Hard to implement a reliable service on both the phone and the server side. The Android OS is known to be able to kill services when it’s running low on memory, so your notifications service can easily disappear. What happens when your phone goes to sleep? Some people complain about battery life issues related to maintaining an active connection.

The first two methods have significant disadvantages that we cannot do anything about. However, the third method’s drawbacks are not as severe. It seems like with enough work and a good design, the persistent TCP/IP method can work. After all, that’s how GMail, GTalk and Google Voice implement their real-time updates. In fact, many developers out there agree that it is probably the best way to go until Google actually takes the matter in their own hands.

Persistent TCP/IP

After more Googling around I was able to come across three reasonable efforts to implement push notifications using a persistent TCP/IP connection:

While all of the work done by these guys is incredible, none of their results are quite ready for drop-in use by other developers. In my effort to implement push notifications, I decided to put the pieces of the puzzle together and combine their results to produce a relatively stable way of implementing push. The example that I provide you with further, is a combination of Josh Guilfoyle’s TestKeepAlive project and Dale Lane’s MQTT work. I borrow quite a bit of code from those guys, so they should get most of the credit.  Anyways, enough for the introduction, let’s get to the good stuff.

My Idea

The problem with the TestKeepAlive project is that it creates a raw TCP connection, which means that you need write your own server to take care of push on the other side. While it’s, without a question, doable, it is exactly why TestKeepAlive is far from a working solution. On the other hand, the MQTT example shown by Dale Lane uses the IBM’s MQTT broker to handle the server work. To backup a little, MQTT stands for MQ Telemetry Transport, which is a protocol developed by IBM. Let’s take a quick look at the man page:

mqtt is a publish/subscribe messaging protocol intended that is designed to be lightweight. It is useful for use with low power sensors, but is applicable to many scenarios.

Did you see the part about ‘low power’? So did I. Basically, the reason why one might consider using MQTT is that it was designed to be very lightweight, so that it doesn’t consume much power. This is ideal for a mobile push solution as it addresses many battery life related concerns about persistent TCP/IP connections. Obviously, MQTT also has some disadvantages such as privacy, but we can talk about that later.

So, my idea consists of taking a KeepAliveService and replacing the raw TCP/IP connection with an MQTT connection. In this case, each device can simply subscribe to a unique topic which is based on its device ID. Now, assuming that your server knows the device ID, it can push data to the device over MQTT by publishing to that unique topic.


In my example, I utilize a PHP script as a server. This uses the Simple Asynchronous Messaging  library (see project SAM http://project-sam.awardspace.com/) to publish MQTT messages to the broker on which I host on my server. Let’s have a look at the overall system diagram:


wmqtt.jar is a simple drop-in implementation of MQTT protocol provided by IBM. It can be downloaded from http://www-01.ibm.com/support/docview.wss?rs=171&uid=swg24006006. The file that you download has a bunch of different stuff. Just look for the right jar file. You can include this jar as a part of your Android app.

Really Small Message Broker (RSMB) is a simple MQTT broker also provided by IBM http://www.alphaworks.ibm.com/tech/rsmb. It runs on port 1883 by default. In our architecture it accepts messages from the server and passes them on to the right devices. RSMB can also be replaced by the Mosquitto server http://mosquitto.atchoo.org/.

SAM is a drop-in PHP library for MQTT and other stuff. You can either get it as PECL extension or download the source online http://pecl.php.net/package/sam/download/0.2.0.

send_mqtt.php is a simple PHP script that accepts messages over POST and uses SAM to pass-on messages to the broker.

Sample Code and Demo


The goal of my work on push notifications was to develop a working demo, which is what all other examples out there lack. I’m happy to say that I accomplished my objective. You can download the sample android app on GitHub.

This app (shown on the left) has a TextView and two buttons. The TextView contains your device ID and the buttons are used to start and stop the push notifications service. Once you have the app on your phone, start the service. Then go to http://tokudu.com/demo/android-push/ and enter the device ID in the first text box and enter the message text in the textarea below. Press “Send Push Message” and you should get a notification on your phone. It’s as easy as that.

You can see the source code for andoid-push in this GitHub project. It contains the aforementioned send_mqtt.php script.

If you didn’t get a notification, make sure you have network connectivity. It can also be that the broker is down on my server (see server status on the page). If that’s the case, please post a comment and I will look into it bringing the broker back up.

Final Thoughts and Comments

MQTT is definitely not the best way to implement push for Android, but it does work. One of the main drawbacks of MQTT is that anyone who knows the IP and the PORT at which the broker is running can connect and intercept your Push messages. So it’s probably a good idea to encrypt them. Alternatively, you could write your own broker and introduce some sort of authentication to MQTT.

The code I provide here for the push service still needs more testing. Reliability is definitely the main question. I think the code can definitely be improved to better handle connectivity loss and other erroneous situations. You are welcome to post your comments here regarding how it can be improved.

Also let me know if you find any bad bugs. Good luck testing!

Anton Lopyrev

Reference : http://tokudu.com/2010/how-to-implement-push-notifications-for-android/


How to Create QuickAction Dialog in Android

Official Twitter application for Android  has introduced new Android UI features and behavior patternssuch as Dashboard, Search Bar, QuickAction and Action Bar. One of the interesting pattern isQuickActions that displays contextual actions in a list view. This pattern actually already exists inQuickContact dialog/bar in default Contact application (since Android 2.0).

QuickContact QuickContact

The QuickActions dialog is not included in standard Android SDK, so we have to create it manually. At first, i had no idea on how to create it so i decided to download and read the Contact app source code from  Android git. I found that the QuickContact dialog  uses private API call (com.android.internal.policy.PolicyManager) that does not exists in standard SDK. After posting question about it on google groups and stack overflow, i got the solution for it from Qberticus (thanx Qberticus!).

Qberticus’s QuickActions uses simple/plain layout so i have to create a custom layout so it will look like QuickContact in Contact app or QuickActions in Twitter app. Based on QuickContact source code, i made a slight modification on Qberticus’s BetterPopupWindow class and extended it to implement custom layout. I also made it customizeable, so the icon and text in action list can be customized.

Here are the screenshoots of QuickActions demo:

QuickContact / Twitter-like QuickActions


Code snippet
Create action items

//Add action item
ActionItem addAction = new ActionItem();
//Accept action item
ActionItem accAction = new ActionItem();
//Upload action item
ActionItem upAction = new ActionItem();

Line 02: Create new action item
Line 04: Set action title
Line 05: Set action icon

Create quickaction instance and setup listener

final QuickAction mQuickAction  = new QuickAction(this);
//setup the action item click listener
mQuickAction.setOnActionItemClickListener(new QuickAction.OnActionItemClickListener() {
        public void onItemClick(int pos) {
        if (pos == 0) { //Add item selected
           Toast.makeText(Example1Activity.this, "Add item selected", Toast.LENGTH_SHORT).show();
        } else if (pos == 1) { //Accept item selected
           Toast.makeText(Example1Activity.this, "Accept item selected", Toast.LENGTH_SHORT).show();
        } else if (pos == 2) { //Upload item selected
           Toast.makeText(Example1Activity.this, "Upload items selected", Toast.LENGTH_SHORT).show();

Line 1: Create quickaction instance
Line 3-5: Add the action items into quikaction
Line 8: Setup listener for action item clicked, the pos argument on onItemClick method shows which action item is clicked.

Show quickAction dialog

btn1.setOnClickListener(new View.OnClickListener() {
public void onClick(View v) {

Line 04: Show quickaction dialog, the v argument used as the anchor where the quickaction displayed.

Gallery3D-like QuickActions


Implementation on My Application



Minapolitan (Prototype)


Buy me a coffee

If you found this stuff useful to your work, please consider a donation.
By doing this you will be helping me to keep improving this stuff and to continue to help anyone who needs, and maybe keep on helping you in the future.

Reference : http://www.londatiga.net/it/how-to-create-quickaction-dialog-in-android/


It is a tool for reengineering 3rd party, closed, binary Android apps. It can decode resources to nearly original form and rebuild them after making some modifications; it makes possible to debug smali code step by step. Also it makes working with app easier because of project-like files structure and automation of some repetitive tasks like building apk, etc.

It is NOT intended for piracy and other non-legal uses. It could be used for localizing, adding some features or support for custom platforms and other GOOD purposes. Just try to be fair with authors of an app, that you use and probably like.


  • decoding resources to nearly original form (including resources.arsc, XMLs and 9.png files) and rebuilding them
  • smali debugging: SmaliDebugging
  • helping with some repetitive tasks


  • JRE 1.6 (Java Runtime Environment)
  • aapt command in a PATH
  • basic knowledge of what is SDK, aapt, PATH, smali and Google search engine may be useful

Installation for noobs

  • Windows:
    1. Download apktool-install-windows-* file
    2. Download apktool-* file
    3. Unpack both to your Windows directory
  • Linux:
    1. Download apktool-install-linux-* file
    2. Download apktool-* file
    3. Unpack both to /usr/local/bin directory (you must have root permissions)
  • Mac OS X:
    1. Download apktool-install-macos-* file
    2. Download apktool-* file
    3. Unpack both to /usr/local/bin directory (you must have root permissions)

Installation of framework files


  • Open terminal/command line and type “apktool <enter>“. Then you should see usage help.

Discuss it: Google Groups or XDA


  • 2011.05.15: apktool v1.4.1 has been released! It’s a quick fix for v1.4.0. Download Changes
  • 2011.05.15: apktool v1.4.0 has been released! Download Changes Migration instructions
  • 2010.06.04: updated install packages to r04-brut1 version.
  • 2011.01.19: sources were released! BuildApktool
  • 2010.09.03: apktool v1.3.2 has been released! Changes
  • 2010.09.03: install-windows-2.2_r01-3
    • fixed an issue when path to apktool.bat contains spaces ( Issue 81 )
  • 2010.06.14: apktool v1.3.1 has been released! Changes
  • 2010.06.12: apktool v1.3.0 has been released! Changes
  • 2010.06.04: updated install packages to 2.2r01-1 version
  • 2010.06.03: apktool v1.2.0 has been released! Changes
  • 2010.04.29: apktool v1.1.1 has been released! Changes
  • 2010.04.28: apktool v1.1.0 has been released! Changes
  • 2010.04.02: apktool v1.0.0 has been released! Changes
  • 2010.03.13: apktool v0.9.2 has been released! Changes
  • 2010.03.02: apktool v0.9.1 has been released! Changes
  • 2010.03.01: apktool v0.9.0 has been released.