Showing posts with label Android. Show all posts
Showing posts with label Android. Show all posts

Sunday, February 10, 2019

Don't clear logs after app get crashed - Android Studio

Currently, I am working on one app which keep getting crash at PIE version and I was not getting any crash log under logcat.

After some research here and there, I get to know that by default logcat logs based on selected process and once your app get crashes, it will clear the crash log as the existing process is gone.

To see the crash logs:
·        Goto logcat and click on right hand side drop down button and select Edit Configuration.

·        Add Filter Name as your app Name and project Name as Package Name. Save it.

Now try again. You will able to see your app crash log now. 

Thank you. Happy Coding…!!!

Thursday, October 27, 2011

How to install Subversion,Google App Engine,Android with Eclipse.

This is tutorial assumes you already have Eclipse installed.

You can install the any plugin for Eclipse using the Software Update feature of Eclipse.
To install the plugin, using Eclipse:
Select the Help menu > Install New Software....
In the Work with text box, enter:

For Subversion:

For Android:

For Google App Engine:

Eclipse 3.6 (Helios):
Eclipse 3.5 (Galileo):
Eclipse 3.4 (Ganymede):
Eclipse 3.3 (Europa):

Click OK
In the Available Software dialog, select the checkbox next to Developer Tools and click Next.
In the next window, you'll see a list of the tools to be downloaded. Click Next.
Read and accept the license agreements, then click Finish.
Note: If you get a security warning saying that the authenticity or validity of the software can't be established, click OK.
When the installation completes, restart Eclipse.

Additional Info:

Saturday, July 16, 2011

MyAppSharer:An easy way to share apps with friends

Do you have friends that are constantly bothering you to “send them that app you used last week”? Tired of trying to hold hands while sending them to the Market? Well, thankfully, that painful part of your Android know how may be coming to an end, thanks to an awesome new app: MyAppSharer.

The app allows you to not only send them a direct Market link, but also to send them the APK directly via bluetooth, what's app, email, dropbox, SMS or QR code – which has the potential to be wonderful for either pulled apps or apps in development. If you want to get your hands on MyAppSharer, it’s a free download via the market link below. Be sure to check it out and sound off with your reviews in the comments!

                                                           Market Link

Android Interview Question

HI, these are the few Android questions that was asked during my interview and some basic questions too that you have to know before going to any interview, I am sharing with you guys. Hope It would help you in your interview too... 
It is impossible for me to give every and each answer over here,but yes if you are not getting any answer from anywhere then just let me know...:)

1) What is Android?

2) Features and Architecture of Android?

3) What is Android Market?

4) What is ADT, AVD, DVM, DDMS, Logcat?

5) Anatomy of an Android Application?

6) What are the basic Components in Android?

7) Describe the .apk format?

8) What is an action, resources.

9) How is nine-patch image different from a regular bitmap?

10) What are the dialog boxes that are supported in android? Explain.

11) What languages does Android support for application development?

12) What is the use of AndroidManifest.xml file in Android Application and the content too?

13) Difference between the android: versionCode and android: versionName Attributes in the AndroidManifest.xml file?

14) What is Activity, Intent, intent-filter ,stickyintent and PendingIntent ?

15) Life Cycle of an Activity?

16) How to Link Activities with Intents?

17) Difference between Toast and NotificationManager class?

18) Passing data to an Activity (Use of Bundle Object).

19) Which event is always called when you killed or sent an activity to background?(onPause() event)

20) View and ViewGroups.

21) What are all the ViewGroups supported by Android and the difference between them?

22) Screen Orientations(portrait and landscape) and techniques to handle changes in Orientation(Anchoring and Resizing and repositioning).

23) Units of Measurement (dp,sp,pt,px),160dp=1 inch

24) Difference between the dp and px unit?

25) Why is AbsoluteLayout not recommended for use?

26) Name the three events you can override to save an activity’s State.

27) Different types of menus supported by Android and the method name you need to override while implementing in your activity

28) Name the three basic ways of persisting data in your Android Application.

29) Sharing data in Android(Content Provider).

30) Difference between geocoding and reverse geocoding

31) What is Service?

32) How an activity and a service communicate?

Friday, June 10, 2011

Android Cloud to Device Messaging(C2DM):Project

Android Push application is an Android Application which is registers to the C2DM Server.It allows user to send and store contact,message,images,maps from the Server to your Device.
It uses a features Cloud to Device Messaging to deliver messages that actually pushes the messages to your device, therefore it saves much more battery and best of all,there is nothing you need to do to enable it.

The entire project(Android Cloud to Device Messaging) is mainly divided into three parts i,e the primary processes involves in this project are

     -Android Push Application
     - Cloud to Device Messaging framework.
     - Android Push server thats sends message via C2DM Server.

Overview of LifeCycle:

Check following URL too to know more about C2DM,Authorization Token And Third Party Application Server.

Some Screenshot:


You will get Notification when there is a new message

If the push data are Map,Image or Number,it will open on your device according to that

Thursday, June 9, 2011

Android Code Style

Android follow standard Java coding conventions. We add a few rules:
  1. Exceptions: Never catch and ignore them without explanation.
  2. Exceptions: do not catch generic Exception, except in library code at the root of the stack.
  3. Finalizers: generally don't use them.
  4. Imports: Fully qualify imports.

1.Exceptions: do not ignore:

Never do this.Never write code that completely ignores an exception like this:

void setServerPort(String value) {
    try {
        serverPort = Integer.parseInt(value);
    } catch (NumberFormatException e) { }

  • Throw the exception up to the caller of your method.
void setServerPort(String value) throws NumberFormatException {
    serverPort = Integer.parseInt(value);  }
  • Throw a new exception that's appropriate to your level of abstraction.
void setServerPort(String value) throws ConfigurationException {
    try {
        serverPort = Integer.parseInt(value);
    } catch (NumberFormatException e) {
        throw new ConfigurationException("Port " + value + " is not valid.");
Handle the error gracefully and substitute an appropriate value in the catch {} block.

/** Set port. If value is not a valid number, 80 is substituted. */
void setServerPort(String value) {
    try {
        serverPort = Integer.parseInt(value);
    } catch (NumberFormatException e) {
        serverPort = 80;  // default port for server 
If you are confident that actually ignoring the exception is appropriate then you may ignore it, but you must also comment why with a good reason:

/** If value is not a valid number, original port number is used. */
void setServerPort(String value) {
    try {
        serverPort = Integer.parseInt(value);
    } catch (NumberFormatException e) {
        // Method is documented to just ignore invalid user input.
        // serverPort will just be unchanged.

2.Don't Use Finalizers

3.Fully Qualify Imports
There are two possible ways to import it:
  1. import foo.*;
  2. import*;
2 reduces the number of import statements.It makes code more readable for maintainers.
Every file should have a copyright statement at the top. Then a package statement and import statements should follow, each block separated by a blank line. And then there is the class or interface declaration. In the Javadoc comments, describe what the class or interface does.
 * Copyright (C) 2010 The Android Open Source Project 


import android.os.Blah;
import android.view.Yada;

import java.sql.ResultSet;
import java.sql.SQLException;

 * Does X and Y and provides an abstraction for Z.
public class Foo {
Every class and nontrivial public method you write must contain a Javadoc comment with at least one sentence describing what the class or method does. This sentence should start with a 3rd person descriptive verb. Examples:

/** Returns the correctly rounded positive square root of a double value. */
static double sqrt(double a) {

 * Constructs a new String by converting the specified array of 
 * bytes using the platform's default character encoding.
public String(byte[] bytes) {
Every method you write, whether public or otherwise, would benefit from Javadoc. Public methods are part of an API and therefore require Javadoc.

Short methods
To the extent that it is feasible, methods should be kept small and focused. It is, however, recognized that long methods are sometimes appropriate, so no hard limit is placed on method length. If a method exceeds 40 lines or so, think about whether it can be broken up without harming the structure of the program.
Define Fields in Standard Places
Fields should be defined either at the top of the file, or immediately before the methods that use them.

Local variables

The scope of local variables should be kept to a minimum (Effective Java Item 29). By doing so, you increase the readability and maintainability of your code and reduce the likelihood of error. Each variable should be declared in the innermost block that encloses all uses of the variable.
Local variables should be declared at the point they are first used. Nearly every local variable declaration should contain an initializer. If you don't yet have enough information to initialize a variable sensibly, you should postpone the declaration until you do.
One exception to this rule concerns try-catch statements. If a variable is initialized with the return value of a method that throws a checked exception, it must be initialized inside a try block. If the value must be used outside of the try block, then it must be declared before the try block, where it cannot yet be sensibly initialized:
// Instantiate class cl, which represents some sort of Set 
Set s = null;
try {
    s = (Set) cl.newInstance();
} catch(IllegalAccessException e) {
    throw new IllegalArgumentException(cl + " not accessible");
} catch(InstantiationException e) {
    throw new IllegalArgumentException(cl + " not instantiable");

// Exercise the set 
But even this case can be avoided by encapsulating the try-catch block in a method:
Set createSet(Class cl) {
    // Instantiate class cl, which represents some sort of Set 
    try {
        return (Set) cl.newInstance();
    } catch(IllegalAccessException e) {
        throw new IllegalArgumentException(cl + " not accessible");
    } catch(InstantiationException e) {
        throw new IllegalArgumentException(cl + " not instantiable");


// Exercise the set 
Set s = createSet(cl);
Loop variables should be declared in the for statement itself unless there is a compelling reason to do otherwise:
for (int i = 0; i n; i++) {

for (Iterator i = c.iterator(); i.hasNext(); ) {


The ordering of import statements is:
  1. Android imports
  2. Imports from third parties (com, junit, net, org)
  3. java and javax
To exactly match the IDE settings, the imports should be:
  • Alphabetical within each grouping.
  • Capital letters are considered to come before lower case letter (e.g. Z before a).
  • There should be a blank line between each major grouping (android, com, junit, net, org, java, javax).


Originally there was no style requirement on the ordering. This meant that the IDE's were either always changing the ordering, or IDE developers had to disable the automatic import management features and maintain the imports by hand. This was deemed bad. When java-style was asked, the preferred styles were all over the map. It pretty much came down to our needing to "pick an ordering and be consistent." So we chose a style, updated the style guide, and made the IDEs obey it. We expect that as IDE users work on the code, the imports in all of the packages will end up matching this pattern without any extra engineering effort.
The style chosen such that:
  • The imports people want to look at first tend to be at the top (android)
  • The imports people want to look at least tend to be at the bottom (java)
  • Humans can easily follow the style
  • The IDE's can follow the style

What about static imports?

The use and location of static imports have been mildly controversial issues. Some people would prefer static imports to be interspersed with the remaining imports, some would prefer them reside above or below all other imports. Additinally, we have not yet come up with a way to make all IDEs use the same ordering.
Since most people consider this a low priority issue, just use your judgement and please be consistent.


We use 4 space indents for blocks. We never use tabs. When in doubt, be consistent with code around you.
We use 8 space indents for line wraps, including function calls and assignments. For example, this is correct:
Instrument i =
        someLongExpression(that, wouldNotFit, on, one, line);
and this is not correct:
Instrument i =
    someLongExpression(that, wouldNotFit, on, one, line);

Field Names

  • Non-public, non-static field names start with m.
  • Static field names start with s.
  • Other fields start with a lower case letter.
  • Public static final fields (constants) are ALL_CAPS_WITH_UNDERSCORES.
public class MyClass {
    public static final int SOME_CONSTANT = 42;
    public int publicField;
    private static MyClass sSingleton;
    int mPackagePrivate;
    private int mPrivate;
    protected int mProtected;


class MyClass {
    int func() {
        if (something) {
            // ...
        } else if (somethingElse) {
            // ...
        } else {
            // ...
We require braces around the statements for a conditional. Except, if the entire conditional (the condition and the body) fit on one line, you may (but are not obligated to) put it all on one line. That is, this is legal:

if (condition) {
    body(); // ok 
if (condition) body(); // ok
but this is still illegal:
if (condition)
    body(); // bad

Line length

Each line of text in your code should be at most 100 characters long.
There has been lots of discussion about this rule and the decision remains that 100 characters is the maximum.
Exception: if a comment line contains an example command or a literal URL longer than 100 characters, that line may be longer than 100 characters for ease of cut and paste.
Exception: import lines can go over the limit because humans rarely see them. This also simplifies tool writing.

Java 1.5 Annotations

Annotations should precede other modifiers for the same language element. Simple marker annotations (e.g. @Override) can be listed on the same line with the language element. If there are multiple annotations, or parameterized annotations, they should each be listed one-per-line in alphabetical order.
Android -standard practices for the three predefined annotations in Java 1.5's are:


The @Deprecated annotation must be used whenever the use of the annotated element is discouraged. If you use the @Deprecated annotation, you must also have a @deprecated Javadoc tag and it should name an alternate implementation. In addition, remember that a @Deprecated method is still supposed to work.
If you see old code that has a @deprecated Javadoc tag, please add the @Deprecated annotation.


The @Override annotation must be used whenever a method overrides the declaration or implementation from a super-class.
For example, if you use the @inheritdocs Javadoc tag, and derive from a class (not an interface), you must also annotate that the method @Overrides the parent class's method.


The @SuppressWarnings annotation should only be used under circumstances where it is impossible to eliminate a warning. If a warning passes this "impossible to eliminate" test, the @SuppressWarnings annotation must be used, so as to ensure that all warnings reflect actual problems in the code.
When a @SuppressWarnings annotation is necessary, it must be prefixed with a TODO comment that explains the "impossible to eliminate" condition. This will normally identify an offending class that has an awkward interface. For example:
// TODO: The third-party class com.third.useful.Utility.rotate() needs generics 
List<String> blix = Utility.rotate(blax);
When a @SuppressWarnings annotation is required, the code should be refactored to isolate the software elements where the annotation applies.

TODO style

Use TODO comments for code that is temporary, a short-term solution, or good-enough but not perfect.
TODOs should include the string TODO in all caps, followed by a colon:
// TODO: Remove this code after the UrlTable2 has been checked in.

// TODO: Change this to use a flag instead of a constant.
f your TODO is of the form "At a future date do something" make sure that you either include a very specific date ("Fix by November 2005") or a very specific event ("Remove this code after all production mixers understand protocol V7.").


Our parting thought: BE CONSISTENT. If you're editing code, take a few minutes to look at the code around you and determine its style. If they use spaces around their if clauses, you should too. If their comments have little boxes of stars around them, make your comments have little boxes of stars around them too.
The point of having style guidelines is to have a common vocabulary of coding, so people can concentrate on what you're saying, rather than on how you're saying it. We present global style rules here so people know the vocabulary. But local style is also important. If code you add to a a file looks drastically different from the existing code around it, it throws readers out of their rhythm when they go to read it. Try to avoid this.


While logging is necessary it has a significantly negative impact on performance and quickly loses its usefulness if it's not kept reasonably terse. The logging facilities provides five different levels of logging. Below are the different levels and when and how they should be used.
  • ERROR: This level of logging should be used when something fatal has happened, i.e. something that will have user-visible consequences and won't be recoverable without explicitly deleting some data, uninstalling applications, wiping the data partitions or reflashing the entire phone (or worse). This level is always logged. Issues that justify some logging at the ERROR level are typically good candidates to be reported to a statistics-gathering server.
  • WARNING: This level of logging should used when something serious and unexpected happened, i.e. something that will have user-visible consequences but is likely to be recoverable without data loss by performing some explicit action, ranging from waiting or restarting an app all the way to re-downloading a new version of an application or rebooting the device. This level is always logged. Issues that justify some logging at the WARNING level might also be considered for reporting to a statistics-gathering server.
  • INFORMATIVE: This level of logging should used be to note that something interesting to most people happened, i.e. when a situation is detected that is likely to have widespread impact, though isn't necessarily an error. Such a condition should only be logged by a module that reasonably believes that it is the most authoritative in that domain (to avoid duplicate logging by non-authoritative components). This level is always logged.
  • DEBUG: This level of logging should be used to further note what is happening on the device that could be relevant to investigate and debug unexpected behaviors. You should log only what is needed to gather enough information about what is going on about your component. If your debug logs are dominating the log then you probably should be using verbose logging. This level will be logged, even on release builds, and is required to be surrounded by an if (LOCAL_LOG) or if (LOCAL_LOGD) block, where LOCAL_LOG[D] is defined in your class or subcomponent, so that there can exist a possibility to disable all such logging. There must therefore be no active logic in an if (LOCAL_LOG) block. All the string building for the log also needs to be placed inside the if (LOCAL_LOG) block. The logging call should not be re-factored out into a method call if it is going to cause the string building to take place outside of the if (LOCAL_LOG) block. There is some code that still says if (localLOGV). This is considered acceptable as well, although the name is nonstandard.
  • VERBOSE: This level of logging should be used for everything else. This level will only be logged on debug builds and should be surrounded by if (LOCAL_LOGV) block (or equivalent) so that it can be compiled out by default. Any string building will be stripped out of release builds and needs to appear inside the if (LOCAL_LOGV) block.

Naming test methods

When naming test methods, you can use an underscore to seperate what is being tested from the specific case being tested. This style makes it easier to see exactly what cases are being tested.
testMethod_specificCase1 testMethod_specificCase2void testIsDistinguishable_protanopia() {
    ColorMatcher colorMatcher = new ColorMatcher(PROTANOPIA)
    assertFalse(colorMatcher.isDistinguishable(Color.RED, Color.BLACK))
    assertTrue(colorMatcher.isDistinguishable(Color.X, Color.Y))

Monday, May 30, 2011

Android Progress Dialog Example

In situations when you need to wait some operation it is good practice to notify user that operation is in progress.For this cases in Android present several classes which can help with this. One of them I am going to demonstrate.

In this tutorial, I will show you how to add a progress dialog to your Android application. A dialog is usually a small window or tab that appears before any activity in your application. It is intended to display alerts or information to the user. A progress dialog can be used to either show some processing activity to the user or to show the progress of some custom activity using the progress bar.

To create a Progress Dialog, we can make use of the ProgressDialog class which is an extension of the AlertDialog class. It can be used to display a standard progress dialog with a spinning wheel and some custom text. You can display your Progress Dialog using a simple show () call on your dialog object.

Here's the syntax to create a standard Progress dialog:
ProgressDialog MyDialog = MyActivity.this, "TITLE " , " Loading. Please wait ... ", true);
It has four parameters:
1. The application context
2. The title of the Dialog
3. The Dialog Text or Message which is displayed in the dialog
4. A boolean value indicating whether the progress is indeterminate

and to disapper the ProgressDialog you have to add dismiss() like this:

Now I will show how to use ProgressDialog class for showing progress dialog. I will show how to create progress dialog with title and without title.

With TItle:, "In progress", "Loading");

What if I you want to hide the title? just put empty string as title parameter., "", "Loading...");


//in the class...
private ProgressDialog progressBar;

//when you want the dialog to show the first time.
progressBar =, "Disconnecting", "Please wait for few secs...");

//when you want the progressbar to disappear
if (progressBar.isShowing()) {

Friday, May 27, 2011

Error: Unable to open class file and How to fix it.

[2011-05-27 12:12:39 - listActivity] ERROR: Unable to open class file /root/workspace/ No such file or directory

[2011-05-27 13:50:38 - listActivity] ERROR: Unable to open class file /root/workspace// No such file or directory and is a automatically generated file.

The ADT has a few such annoying bugs. But you can sort them out..
What usually helps is:

1. Close Project->Open Project > Build Automatically .
2.Another thing that sometimes helps is right click project > android tools > fix project properties and remove unnecessary content or jar files.

3.Or you can do Project->clean and Refresh .

If still it not generating files then check your class there must be a extra line..

Import*; Remove that and then do all the above one by one..

Hope it help ..

If someone know other way please let me know.



Tuesday, May 24, 2011

Conversion to Dalvik format failed with error 1

Sometime You will encounter this problem when trying to Build Android Project on Eclipse..
 You will get such output in console:

[2011-05-24 09:25:03 - Android C2DM] Dx 1 error; aborting
[2011-05-24 09:25:03 - Android C2DM] Conversion to Dalvik format failed with error 1

You can solve this problem:

Go to Project » Properties » Java Build Path » Libraries and remove all except the "Android X.Y" (in my case Android 2.2). click OK. 
and then
Go to Project » Clean » Clean projects selected below » select your project and click OK.

 That work for me. Hope it works for you too.!!!!

Tuesday, May 17, 2011

Third Party Applcation Server

The Third Party Server is *your* server and can actually be any process written in any language (for example, it can be a batch process or a cron script). The role of the 3rd party "server" is to send the message to the device.

The Server will store (or update) the registrationID received into its local database. So, eventually the server will have registrationIDs from the devices.
Your server needs to get a ClientLogin Auth token in order to talk to the C2DM servers. When it wants to push a message to the device.
For ClientLogin Auth_Token: Click Here

To send a message to a particular device, the Server needs to POST to the C2DM Service the following 4 things:
  1.  The accountName which will be .
  2. An authentication Token.
  3. The registrationID of the device it wants to send the message. 
  4. The message itself (Message limit 1024 Bytes)


// Create a new HttpClient and Post Header 
HttpClient httpclient = new DefaultHttpClient(); 
HttpPost httppost = new HttpPost(""); 

//Your Authorization Token
httppost.addHeader("Authorization", "GoogleLogin auth="+authToken); 
// Add your data 
List<NameValuePair> nameValuePairs = new ArrayList<NameValuePair>(2); 
nameValuePairs.add(new BasicNameValuePair("registration_id",regId)); 
nameValuePairs.add(new BasicNameValuePair("collapse_key", "TEST")); 

//.<message> is the key and Message is "Push Contact"
nameValuePairs.add(new BasicNameValuePair("data.message","Push Contact")); 
httppost.setEntity(new UrlEncodedFormEntity(nameValuePairs,"UTF-8")); 

// Execute HTTP Post Request 
System.out.println("Executing  sendMessage"); 
HttpResponse response = httpclient.execute(httppost); 
if (response.getEntity() != null) 

This code work properly on Apache Tomcat Server but while deploying this code on the Google App Engine you will get the Restricted class issues..So if you are thinking of deploying on Google App Engine Try this...

// Send a sync message to this Android device.

URL url = new URL("");
HttpURLConnection urlConnection = (HttpURLConnection) url.openConnection();
urlConnection.setRequestProperty("Authorization", "GoogleLogin auth="+Constants.authToken); 
urlConnection.setRequestProperty("Accept", "text/html, */*");
urlConnection.setRequestProperty("Connection", "keep-alive");

//Send MEssage
StringBuilder postDataBuilder = new StringBuilder();
postDataBuilder.append("registration_id"). append("=").append("YOUR_REGISTRATION_ID");
byte[] postData = postDataBuilder.toString().getBytes(URLEncoder.encode("UTF-8"));

//Executing  sendMessage
OutputStream outputStream = urlConnection.getOutputStream();

int responseCode = urlConnection.getResponseCode();

If you like this post..Please do comments..


Wednesday, May 11, 2011

ClientLogin for Installed Applications for C2DM - Tutorial

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.

The ClientLogin authorization process:
Authorization with ClientLogin involves a sequence of interactions between three entities: the installed application, Google services, and the user. This diagram illustrates the sequence:

  1. When the third-party application needs to access a user's Google service, it retrieves the user's login name and password.
  2. The third-party application then makes a ClientLogin call to Google's Authorization service.
  3. If the Google Authorization service decides additional vetting is necessary, it returns failure response with a CAPTCHA token and challenge, in the form of a URL for a CAPTCHA image. 
  4. If a CAPTCHA challenge is received, the third-party application displays the CAPTCHA image for the user and solicits an answer from the user. 
  5. If requested, the user submits an answer to the CAPTCHA challenge. 
  6. The third-party application makes a new ClientLogin call, this time including the CAPTCHA answer and token (received with the failure response). 
  7. On a successful login attempt (with or without CAPTCHA challenge), the Google Authorization service returns a token to the application. 
  8. The application contacts the Google service with a request for data access, referencing the token received from the Google Authorization service. 
  9. If the Google service recognizes the token, it supplies the requested data access.

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 to that includes the following:
registration_idThe registration ID retrieved from the Android application on the phone. Required.
collapse_keyAn 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.
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_idleIf 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:
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 bad registration_id. Sender should stop sending messages to this device.
    • NotRegistered — The registration_id is 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.
503Indicates that the server is temporarily unavailable (i.e., because of timeouts, etc ). Sender must retry later, honoring any Retry-After header included in the response. Application servers must implement exponential back off. Senders that create problems risk being blacklisted.
401Indicates that the ClientLogin AUTH_TOKEN used to validate the sender is invalid


// Create a new HttpClient and Post Header 
HttpClient httpclient = new DefaultHttpClient(); 
HttpPost httppost = new HttpPost(""); 
// this is for proxy settings 

HttpParams params = httpclient.getParams(); 
params.setParameter("content-type", "application/x-www-form-urlencoded"); 
try { 
           // Add your data 
           List<NameValuePair> nameValuePairs = new ArrayList<NameValuePair>(2); 
           nameValuePairs.add(new BasicNameValuePair("accountType","HOSTED_OR_GOOGLE")); 
           nameValuePairs.add(new BasicNameValuePair("Email","ar*****")); 
           nameValuePairs.add(new BasicNameValuePair("Passwd","W******21")); 
           nameValuePairs.add(new BasicNameValuePair("service", "ac2dm")); 
           nameValuePairs.add(new BasicNameValuePair("source",   "arxxus.push.1.1")); 
           httppost.setEntity(new UrlEncodedFormEntity(nameValuePairs)); 
           // Execute HTTP Post Requestu 
           HttpResponse response = httpclient.execute(httppost); 
          BufferedReader in = new BufferedReader(new InputStreamReader(response.getEntity().getContent())); 
          StringBuffer sb = new StringBuffer(""); 
          String line = ""; 
          while ((line = in.readLine()) != null) 
         String result = sb.toString(); 
         String authToken=result.substring(result.indexOf("Auth=")+5); 


This code work properly on Apache Tomcat Server but while deploying this code on the Google App Engine you will get the Restricted class issues..So if you are thinking of deploying on Google App Engine Try this...

HttpURLConnection urlConnection;
URL url = new URL("");
urlConnection = (HttpURLConnection) url.openConnection();
StringBuilder content = new StringBuilder();
content.append("&source=").append( "arxxus.push.1.1");
OutputStream outputStream = urlConnection.getOutputStream();
int responseCode = urlConnection.getResponseCode();
StringBuffer resp = new StringBuffer(); 
if (responseCode == HttpURLConnection.HTTP_OK) 
   InputStream inputStream = urlConnection.getInputStream();
     BufferedReader rd = new BufferedReader(new InputStreamReader(inputStream));
     String line; 
     while ((line = rd.readLine()) != null) 
String authToken=resp.toString();

If you like this post..Please do comments..

How TOPT Works: Generating OTPs Without Internet Connection

Introduction Have you ever wondered how authentication apps like RSA Authenticator generate One-Time Passwords (OTPs) without requiring an i...