This application lets you access your Android’s built-in Linux command line shell. It emulates a Digital Equipment Corporation VT-100 terminal. You can use this application to run utility programs on your device.
This application lets you run Linux command line utilities on your Android phone. It is mostly useful for computer programmers. It might also be useful for people who want to explore the Linux internals of their Android phone.

ConnectBot
ConnectBot is a powerful open-source Secure Shell (SSH) client. It can manage simultaneous SSH sessions, create secure tunnels, and copy/paste between other applications.
This client allows you to connect to Secure Shell servers that typically run on UNIX-based servers.

HubDroid
Access GitHub from your Android device! Hubroid is the only full-featured GitHub client available on Android. Access repositories, gists, followers, news feed, issues, commits, and much more!

NFC on mobile phone will not only enable with card payment solutions, but it will also enable other solutions like device as Tag reader or in Peer to Peer data transfer.

Android latest release 2.3 has some set of API exposed for card reading, which is capable of reading various tags like Text record, URL record, or smart poster tag. The support for P2P communication is not yet available through the API.

With this limited set of capability available, one could still build some interesting use cases. If you have NFC equipped phone like Nexus-S and get hold of Some tags. In below video, we have tried to make use of the available API to read the Tag info of smart poster and retrieve the information from background web server.

Click here to Watch Video

Interesting applications can be built around the current capability of Andriod device like:

Provide the personal advertisement tags in conferences, so that your client can directly go to your website with simple swipe.
Stick the tags in shops, so user carrying the phone can swipe on tag to get the details of the product may see some promotion video on the product.
Enabling the Guest carrying NFC tag reader app to hook into your wifi network if you have tag storing needed access parameter.
Change the device setting, like stick tag in meeting room door, so when user swipes there phone while entering the device goes to silent automatically.
True sharing applications can be easily be built once we have full support like Peer to Peer share, instant BT paring, touch triggered sharing, Vcard exchange, and many others.

Easy access of tags to general public coupled with full support by leading OS vendors will bring the NFC into mainstream in wider markets quickly.

More info on NFC can be obtained at

http://www.nfc-forum.org/home/

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 queuing of messages and delivery to the target application running on the target device.

CHARACTERISTICS OF ANDROID CLOUD TO DEVICE MESSAGING (C2DM)

Primary characteristics of C2DM are:

1. 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.
2. 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.
3. It uses an existing connection for Google services. This requires users to set up their Google account on their mobile devices.

ARCHITECTURAL OVERVIEW

Cloud to Device Messaging includes key terms and concepts which can be classified in to two divisions. They are:

1. Components
2. Credentials

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.

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

It is the id of an 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 Accountfor C2DM to work, the mobile device must include at least one logged in Google account.

Sender Auth Token

A ClientLoginAuth 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.

LIFE CYCLE OF CLOUD TO DEVICE MESSAGING

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

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

   Enabling C2DM

   Following are 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 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.

   1. The C2DM server broadcasts a Intent which gives the application a registration ID.

   The application stores this ID for later use. Google may periodically refresh the registration ID, so the application is designed with the understanding that the REGISTRATIONntent may be called multiple times.

   1. 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 Registration Id is stored at the Application Server.

   There is one more thing that needs to be in place for the application server to send messages: a Client Login authorization token. The Client Login token authorizes the application server to send messages to a particular Android application. An application server has one Client Login 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 queues 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 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 Intent as a set of extras.
   3. The Android application extracts the raw data from the Intent by key and processes the data.

1. Google I/O talk – Android UI design patterns

In this session, the Android User Experience team will show the types of patterns you can use to build a great Android application. The talk directly comes from the Google UI/UX team and is really worth looking at!

2. Android Patterns

This website provides a set of interaction patterns that can help you design Android apps. You can view various patterns related to user input, navigation, notifications, screen interactions, personalization and social media interaction.

3. Android UI Design Patterns – Presentation

This presentation is given by Mike Wolfson of Phoenix Android Developers Group. It gives you a nice overview of Android UI Design Patterns and Best Practices.

Android 3.0 comes with a new UI designed from the ground up for tablets. With so many tablets in the market, UI is going to be a crucial factor to attract consumers to your device and the Google team has nailed it this time by providing an altogether new UI framework for developers, which will allow developers to create a richer, more interactive experience for users. We’re really excited about Activity fragments, which provide greater control of content and design flexibility.

This will allow developers to come up with apps, which are more intuitive and engaging thereby increasing the overall user experience. The Activity fragment feature is supplemented by redesigned UI widgets which can now be used as remote views in application widgets displayed on the home screen. Other exciting features of Android 3.0 Platform include Persistent Action Bar and Richer Notifications. It’s really a neat idea to provide each application with its own instance of the Action Bar at the top of the screen. This will allow developers to expose more features of their applications to users in a familiar location.

We know that the notification mode is arguably better on Android devices as compared to iOS. And this just got better with Android 3 SDK, which includes new builder class thereby allowing developers to quickly create notifications that include large and small icons, a title, a priority flag, and any properties already available in previous versions. In Android, all notifications are neatly organized in an expandable menu. So, whenever any of these notifications appear, they are quickly displayed for some time in a small strip that always stays at the top of the screen. iOS 4 still follows pop-up notifications, which may occasionally interfere with whatever apps you’re running at the time.

There’s also some good news for Android Game Developers. Android 3.0 offers a new hardware-accelerated OpenGL renderer that gives a performance boost to many common graphics operations for applications running in the Android framework. And if this was not enough, Google has also included RenderScript with Android 3.0, which is a runtime 3D framework for accelerating graphics operations and data processing. It seems like we are going to see some really exciting games for Android in the near future!

Android 3.0 also includes some other smart features likes HTTP Live streaming and Digital Media file transfer. Overall, it’s an impressive release and we hope that the developers will make full use of it!

1. Wikitude World Browser

2. 3D Compass

3. Tweeps Around

So, what exactly is AR?
Wikipedia defines AR as a live direct or indirect view of a physical real-world environment whose elements are augmented by virtual computer-generated sensory input such as sound or graphics. Simply speaking, AR is the ability to overlay location data points on the live view of a mobile device’s camera.Thus, AR applications combine virtual data into the real world by utilizing the phone’s compass, camera, and GPS system.
You can get more information about AR here and here.
In this article, we will provide you some resources which will help you in developing your own AR applications for Android devices.

Android AR-Kit (Recommended)
An open source, Geographical based, Augmented Reality library.

Layar
The Layar Reality Browser shows what is around you by displaying real time digital information on top of the real world as seen through the camera of your mobile phone.You can use the Layar Platform to create your own AR Applications.

Mixare
mixare (mix Augmented Reality Engine) is a free open source augmented reality browser. It works as a completely autonomous application and is available as well for the development of own implementations.

Qualcomm Augmented Reality Platform
The Qualcomm Augmented Reality Platform provides developers the ability to create high-performance Android applications with C++ APIs.

Tutorial
Chris Haseman has also put together a nice tutorial for developing AR applications using the Android AR-Kit. Experienced Android Developers will find this tutorial very helpful.

We hope that you’ll find these resources useful. Let us know about your thoughts on AR application development in the comments section.

AndroidBook delivers the complete Facebook experience in a vastly superior mobile interface optimized specifically for the legion of Android-based handsets and hardware configs.

Speed, reliability, and best-in-class user interface are the AndroidBook keywords. Switch seamlessly between status updates, viewing video in the News Feed, uploading and browsing photos, and posting comments on friends’ Walls. You’re never more than a tap or two from where you’re going next.
Version 2.0 also brings some crucial new features and updates to the table:
1. Intelligent notifications
2. Improved Friend Finder
3. Upload and caption photos direct from camera or gallery
4. Easy password retrieval
5. Watch videos without ever leaving the app
AndroidBook boasts powerful functionality and hands down the best user experience for Facebook on Android – far better than even the ‘official’ app. For Android-toting Facebook mavens, AndroidBook is the clear choice.
Learn more about AndroidBook at the following URL:
http://www.spoonjuice.com/androidbook

• onCreate(): This is called when the activity first starts up. You can use it to perform one-time initialization such as launching the user interface. onCreate() utilizes one parameter that is either null or state information previously saved by the onSaveInstanceState( ) method, discussed below.
• onStart(): This indicates the activity is about to be displayed to the user.
• onResume(): This is called when the user can start interacting with the activity. This is a good place to start animations and music.
• onRestart(): If this is called, it indicates your activity is being redisplayed to the user from a stopped state.
• onFreeze(): Allows you to save your current state when one activity is being paused and another one resumes to interact with the user. After being paused, the system may at any time need to stop (or even outright kill) your application in order to claim resources for the current foreground activity. If this should happen, the state you supply here will later be recalled with onCreate(), when the user starts a new instance of your activity.
• onPause(): This runs when the activity is about to go into the background, usually because another activity has been launched in front of it. This is where you should save your program’s persistent state, such as a database record being edited.
• onStop(): This is called when your activity is no longer visible to the user and it won’t be needed for a while. If memory is tight, onStop() may never be called (the system may simply terminate your process).
• onDestroy(): This is called right before your activity is destroyed. If memory is tight, onDestroy( ) may never be called (the system may simply terminate your process).
• onSaveInstanceState(Bundle): Android calls this method to allow the activity to save per-instance states, such as a cursor position within a text field. Usually you won’t need to override it because the default implementation saves the state for user interface controls automatically.
• onRestoreInstanceState(Bundle): This is called when the activity is being reinitialized from a state previously saved by the onSaveInstanceState() method. The default implementation restores the state of your user interface.

I hope this brings you up to speed on Android Activity Classes. Be sure to have a thorough look at the attached diagram below (click –> full size) for a concrete overview of what we’ve been discussing here. The more familiar you are with Activity Classes and how and they affect the end user experience, the more successful your Android apps development will be.

If you have any questions or requests re: Android apps dev, drop us a line via the contact form at mothership Sourcebits and we’ll get back to you as soon as we can, perhaps even posting a tutorial here on these pages.

Best of luck,
Sudhir N Kamath
Sr. QA Engineer
Sourcebits Technologies, Ltd.

Learn it, Live it, Reap ze glory.

Step 1: Create a database-using application:

For example, as follows:

Application: TestDatabase

Package Name: com.android.TestDatabase

Database Name: TestingDatabase

Table Name: TestingTable

Step 2: Launch the application to create a database for the application.

Step 3: Open a command prompt. For example, on Windows, go to Start > Run and type “cmd”

Step 4: Navigate to the tools folder in the Android SDK.

Step 5: Input the following at the command prompt:

d:\android-sdk\tools>adb shell

# cd data/data

# cd com.android.TestDatabase

# cd databases

# sqlite3 TestingDatabase;

sqlite3 TestingDatabase

SQLite3 version x.x.x

Enter ".help" for instructions

sqlite>

Step 6: From here you can fire your queries.

For example:

sqlite> select * from TestingTable;

Step 7: To exit, press ctrl+c

Step 8: Then you can check the directories inside the folder.

For example, let’s check all the databases created in the folder “databases”

Type:

# cd databases

# ls

ls

TestingDatabase

Thanks for reading, and I hope this helps.  If you have any questions about this specific tutorial or any other issues re: coding for Android, drop us a line any time from our contact page!

Nirav Shah
Software Engineer
Sourcebits Tech Pvt Ltd.

Whenever a user launches an Android application, a thread called “main” is automatically created. This main thread, also called the UI thread, is crucial since it’s responsible for dispatching events to various widgets, including the drawing events. For careless Android developers, this single thread can be the overarching reason for poor app performance. With so much riding on a single thread performing long operations like network access or database queries, any interference on this thread will block up the entire user interface. No events can be dispatched – including drawing events – while long operations are underway, and from the user’s perspective, the application appears hung. Even worse, if the UI thread is blocked for more than a few seconds (about 5 seconds currently) the user will encounter the dreaded “application not responding” (ANR) dialog.

BaseAdapter is an Adapter object that acts as a bridge between an AdapterView and the underlying data for that view. The Adapter provides access to specific data points and is also responsible for making a View for each point in the data set. So, taking the example of downloading an image over HTTP, there may be some slowdown in our application with the Main UI thread getting blocked for more than a few seconds, and users might be presented with the ANR dialog. To avoid this situation I have some suggestions:

1. Use ExecuterService (Thread pool)
2. Use AsynTask
3. Use SoftReference Drawable Object
4. Create the ListView first, then download images
5. Make use of OnScrollListener Interface

I’ve written a sample application to help Android developers visualize this implementation.

Here we have AbastractListAdapter, an extension of BaseAdapterClass:

public abstract class AbstactListAdapter extends BaseAdapter {
	public AbstactListAdapter(Context context) {
		this.context = context;
	}
	public abstract void setScrollStatus(boolean scroll);
	public abstract void scrollIdle(AbsListView view);
}

There are two methods of implementation for Class ListAdapterScrollListener and Onscrollistner.

public void onScroll(AbsListView view, int firstVisibleItem,int visibleItemCount, int totalItemCount) {
		adapter.setScrollStatus(true);
	}
public void onScrollStateChanged(AbsListView view,intSrollState) {
		switch (scrollState) {
		case OnScrollListener.SCROLL_STATE_IDLE:
			adapter.scrollIdle(view);
			break;
		case OnScrollListener.SCROLL_STATE_TOUCH_SCROLL:
			adapter.setScrollStatus(true);
			break;
		case OnScrollListener.SCROLL_STATE_FLING:
			adapter.setScrollStatus(true);
			break;
		}
}

In my onCreate method I set up and configure the list view to load the views and set the listner for Scroll.

public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        Adapter mAdapter=new Adapter(this);
        setListAdapter(mAdapter);
        getListView().setOnScrollListener(new 		ListAdapterScrollListener(mAdapter));
      }

I use an Adapter class to extend AbstractAdapterClass and implement BaseAdapter, both of which help to load images when scrolling is idle.

The image is loaded in a separate threadpool. I have used Executerservice and assign a threadpool to download images. This method employs a runnable which will extend Assigntask. This ImageLoader class has a subclass, workerthread, which extends Assyntask and implements runnables. This class uses ExecutorService, and assigns 5 threads to do the work. Other implementations of this kind launch a separate thread per image, meaning that the network connection will become clogged with any image load. Assigning the task to the workerthread subclass and using onprogressupdate to notify the adapter to display the image reduces the burden.

You’ll notice the use of SoftReference here. While this appears to work well, I haven’t done any significant load or performance testing, so it may not be necessary. Since bitmap/drawable objects require memory, and Android supports 16mb of heap, it’s better to classify those objects as SoftReference objects. SoftReferences pointing to softly reachable objects are guaranteed to be cleared before the VM triggers an OutOfMemoryError. This can be written as follows:

 public class ImageLoader {

private class WorkerThread extends AsyncTask implements Runnable{
		public WorkerThread(String url,int pos) {
			this.url=url;
			intex=pos;
			}
		@Override
		protected void onProgressUpdate(Void... values) {
			mAdapter.notifyDataSetChanged();
			super.onProgressUpdate(values);
		}
		@Override
		public void run() {
			Cache.put(intex,new SoftReference(readDrawableFromNetwork(this.url)));
			publishProgress();
		}
	}

	public Drawable getDrawble(int pos)
	{
		SoftReference mReference=Cache.get(pos);;
		if(mReference!=null)
			return mReference.get();
		else
			return null;
	}

/*method to get Image if already or to start new task to download*/
	public void loadImage(int First,int Last) {
			try{
					_exec = Executors.newFixedThreadPool(5);
				for(int pos=First;pos<=Last;pos++){
					if(Cache.containsKey(pos)){
						if(Cache.get(pos).get()==null)
							_exec.execute(new  WorkerThread(Dataset.mStrings[pos],pos));
					}else{
						_exec.execute(new  WorkerThread(Dataset.mStrings[pos],pos));
					}
				}
			}catch (Exception e) {
				_exec.shutdown();
			}

	}//end of method

	private static Drawable readDrawableFromNetwork(String url ) {
	   Write code here to downlaod image from network.
	}//end of method
}

And that’s it!

For your reference, the code has been packaged for you to download and inspect here.

Anyone with significant time in mobile application development understands the challenges of writing portable applications. There are tons of reasons for this, but probably the biggest hurdles we face are:

• Varying screen sizes
• Varying screen resolutions
• Varying hardware configurations
• Varying media formats; such as for images, audio, video
• Varying input methods; e.g. touch screen, T9 key pad, qwerty keypad
• Non-standard, device-specific hardware keys

And so on and so forth >_<

Android engineers, anticipating the witches brew of OEM handsets they would encounter, took steps to try and alleviate the situation by standardizing some key features:

• A very rich widget set that can scale according to needs
• Standardized way of implementing custom widgets
• Standardized user interface conventions for touch screen devices
• Standardized image capture formats {still buggy from time to time}
• Standardized mechanism for sharing code across different components; such as user interface elements, fixed content or a specific activity
• Standardized on a base set of hardware keys; e.g. Home, Back, End, and Trackball

Above notwithstanding, with screen sizes and resolutions still very much device dependent {see: T-Mobile G1, Motorola Droid, Google Nexus One, HTC Hero and so on}, creating a consistent UI that both looks good and works well on all platforms has been a slog. For Android developers or those just interested in Android application development, here we present a method and a design pattern that can be utilized to achieve precisely that. The focus points are as follows:

• Understand the functionality that needs to be replicated per device. This can be represented by a Java interface to achieve, for example, scaled UI elements across varying screen sizes and resolutions.
• Separate device-specific features into device-specific implementations. For example, each phone {including from the same manufacturer} might have different hardware keys, or even different keypads (such as T9, QWERTY, or SureType). If an application is to work on different phones with different input mechanisms, it must take into account these differences when implementing.
• A Class Factory that can intelligently instantiate the device-specific components of multiple handset designs.

Let’s take for example the case of displaying a splash screen at application launch. Here we address the issue of supporting for multiple devices. The first act of separating the functionality begins with this interface:

public interface SplashableScreen {
public void showSplashImage(ImageView mView);
public void startSpalshing() throws Exception;
public void SetSplashDuration(int time);

}

Any screen that can be shown as a splash has the functionality as described by the methods indicated.

A device-specific implementation / screen-specific implementation can be written as follows:

public class SplashScrren_320_480 implements SplashableScreen{
public void showSplashImage(ImageView mView){
// Write code speficic to this resolution.
}

}

And a proper implementation can be instantiated and used as follows:

public class SplashFactory{
public static SplashableScreen getSplashScreen(){
// Given a device metrics, instantiate appropriate class and return.
}
}

We’re pleased to offer the full code for this useful application for download here.

Android facebook users, you don’t have to feel left out of the facebook juggernaut anymore – you get the same easy to use, popular facebook that is making waves on the iPhone, on your Android.

The Design follows the same popular features of facebook you are used to, and far superior to the clones that are a dime a dozen on the android market.

Of course you have to use certain features like registering for an account and editing your profile settings on the popular facebook website , but this app comes very close to the home grown iPhone app. Actually, it beats it in looks and some features of user-intuitiveness.

Facebook opened up its API for 3^rd party development, saying they were not interested to pursue other platforms after having developed an in-house version for the iPhone. RIM engineers also collaborated with Facebook to develop one for the blackberry. One is not aware of the reason why this step motherly treatment for Android, but it is. This could be due to Google going the MySpace way, but it is true that Facebook has even stopped building their API in java since mid 2008.

Facebook has not opened up its API fully. It is still holding on to Chat and Inbox APIs. A lot of Android and 3^rd party apps out there are only catering to obtaining News Feeds, friend -lists from Facebook and sending SMSs in the form of status updates, and thats about it!.

AndroidBook has broken the barrier, it is the closest you can get to the iPhone app developed by Facebook. We did it the tough way – but we did it!. This despite the fact that facebook for iPhone is a homegrown application, which had access to the closed facebook APIs.

Features of AndroidBook:

• Login – Login to Facebook, and provide link to Facebook website for Sign Up

Home:

• News Feeds (Status Updates and Links)
• Notifications (Updates to Photos)
• Requests (Friend requests)

Profile:

• Wall (Compose status updates on wall)
• Info (Information of Logged in User)
• Photos, Take, Replace and Upload to personal Album.

Friends:

• Friends Search and Friends Profile

Chat:

• Chat with Available friends

E-mail:

• Inbox (Select, Compose, Reply and Send)
• Sent (Delete)
• Updates (Events Notifications)

Take Photo, Cancel, Replace or Save photo (store locally or upload to personal album)
Logout

Compared to investments of Apple, which has a $100 million fund to seed iPhone applications, and RIM, which has $150 million fund to seed Blackberry applications, the Google investment is a far cry away.

Judging for ADC 2 is different from ADC 1 in that there will be 30 winners against the 50 last year, and 45% of weightage for an application is decided by the community vote and 55% by the judges.
It is mandatory to submit applications that run on Android 1.5 and be in English, and those that are unpublished and non-upgraded.

ADC2 will have two rounds of judging, the first round results in 200 apps total(in 10 categories), that will proceed to the second round. Out of which 30 entries will be winners with 3 entries within the 30 picking up the prizes in the overall winners category.

The contest is expected to start in August 09 and winning entries declared by November 09. We could see a drop in the Android market uploads, as the opportunity cost of waiting is pretty high. We could also see a host of entries in the Lite version (Full-featured with expiry time), so popular applications could potentially rake in money in both places (ADC 2 and The Android Market).

One bone of contention is the ‘Supposed ban on Open Source apps ‘ My comments here.

More details on creation of AVDs and version notes detailing the usage of minSDKVersion for developers.

Compiling our source with a build target of 1.1, went smoothly and hardly any change in code was needed for a build target of 1.5. However, moving to build target of Android 1.5 would not suffice for a project that used Maps, we had to select the ‘Google APIs’ build target (understandable as the maps package was moved out).  Respective Deployment targets were selected for running the apk in the emulator.

It was a joy to see the soft-keys come up when I hit the text box, I have to admit!.

‘The Plateau‘ takes Android’s touch screen capabilites to a whole new level.
Code is performance optimized, so lag is non-existant as you un-entangle the crossed lines by moving the orbs. To top it all, the background music is bound to leave you in a trance.

There are two modes of ‘The Plateau‘ – Challenge and Arcade.
In the non-timed Challenge mode, you can leisurely work out each level and thus help build your own strategies.
The strategy skills that you have thus acquired will help you beat the time for each level in the Arcade mode.

Every level has orbs that randomly change their color – your perceptiveness and responsiveness can help you alter your score to your advantage.
You can resume every level where you ended, you can submit your score and check your position in the high scores list – fight against yourself or the competition, which you will have in plenty,  i.e.,  if you can let go.

Be warned, this game is highly addictive, and promises to entangle you in its web and launch you to a rarefied atmosphere in outer space.

Prominent features of the new SDK are :
Speech Recognition, Soft keyboard, Improved accelerometer and Video recording and uploading capability.
A complete list of the Android 1.5 Highlights.

The biggest improvement from a developers perspective is the AVD Concurrency. Developers can now create Android Virtual Devices with different names and work with emulators in parallel. Also, the choice of multiple targets (including Android 1.1 and Android 1.5), means that developers can continue to test their compilations for older targets (1.1 and earlier), but the catch is, you lose network connectivity (known issue in this SDK). So if you are developing an application which uses network access, then you have to wait for the release version of Android 1.5 SDK.

Eclipse developers, will have to uninstall the ADT 0.8 plugin and install the ADT 0.9 plugin to make use of the new SDK.

It is not yet clear if the team has enhanced the code to handle errors such as – memory overrun that needs ‘bitmap recycle’ and ‘audio flinger ‘ when looping sound files, atleast in this release.

For the user, however, the question remains how far the G1 will continue. With the 1.5 SDK onslaught, we are definitely looking at a G3 (as per the API Level). There are inherent limitations to firmware upgrades, as it needs a supporting underlying hardware. Also, with the addition of the soft keypad, can we expect the new device be thinner ?

The G1 device certainly needs more RAM (55MB ? come on guys – the iPhone 3G will have 128MB, what is Google thinking?)

But for now, it is hoping for rosy days ahead for our favourite platform – Android.

If you wish to publish your application to other users, you are required to sign your application with your own personal certificate. You can generate your own certificate by using the keytool.exe that comes with the JDK/bin folder. In most cases, you can tell the SDK build tools how to find keytool by making sure that your JAVA_HOME environment variable is set and that it references a suitable JDK. Alternatively, you can add the JDK version of Keytool to your PATH variable.

To generate your own certificate, issue the following command:

keytool –genkey –v –keystore sourcebits.keystore –alias CoolApp –keyalg RSA –validity 10000

The above command generates a certificate named sourcebits.keystore with the key alias sourcebits, generated using the RSA algorithm, and with a validity of 10,000 days (this is the minimum recommended).

You will be prompted for some information:

What is your first and last name?

[unknown]: <enter your first and last name>

What is the name of your organizational unit?

[unknown]: <enter your organizational unit>

What is the name of your organization?

[unknown]: <enter the name of your company>

What is the name of your City or Locality?

[unknown]: <enter the name of your city>

What is the name of your State or Province?

[unknown]: <enter the name of your state>

What is the two-letter country code for this unit?

[unknown]: <enter the two digit country code> e.g for USA it is US.

If you are publishing your application for the Android Market, your keystore must have a validity period that ends after 22 October 2033 (which is the reason greater than 10000 days validity is recommended).

Keytool prompts you to provide passwords for the keystore and key. It then generates the keystore as a file called sourcebits.keystore. The keystore and key are protected by the passwords you entered. The keystore contains a single key, valid for 10000 days. The alias is a name that you — will use later, to refer to this keystore when signing your application. Secure and protect these two passwords so that only people who are authorized to sign your applications know about them.

Signing your Android application:

All Android applications must be signed before they are allowed to be deployed onto a device. Android Market Place has made it mandatory to at-least Self-Sign your app before it is accepted. Unlike other mobile platforms, you need not purchase digital certificates from a certificate authority (CA). Instead, you can self-sign (generate your own personal certificate and use it to sign your Android applications).

To sign your application manually:

Have a project that generates your executable with the name you desire for your application.

(PAIN POINT: Your signing may fail otherwise).

Go to Eclipse, right-click on the project ->Android Tools->Export Unsigned Application Package and Select the apk file. You will then be asked to select a directory for exporting the application. For convenience you can export the Android package (with the .apk extension) to JDK/bin.

jarsigner -verbose -keystore sourcebits.keystore CoolApp.apk CoolApp

When prompted for the password for the keystore, use the password that was supplied during the key generation.

To verify that the application is signed correctly, you can use the –verify option with jarsigner.exe.

To verify that your .apk is signed, you can use a command like this:

$ jarsigner -verify CoolApp.apk

If the .apk is signed properly, Jarsigner prints “jar verified”. If you want more details, you can try one of these commands:

$ jarsigner -verify -verbose CoolApp.apk

or

$ jarsigner -verify -verbose -certs CoolApp.apk

The command above, with the –certs option added, the details of the certificate used to sign the application can be seen.

NOTE:

Select strong passwords for the keystore and key.

When you use keytool and jarsigner, do not supply the -storepass and -keypass options at the command line

I have added the solutions to the pain points after going through the upgrade process myself, from version 1.0 to 1.1 to 1.5 on an ADP1 device.

From the above HTC support link, download the actual Radio and System image binaries, as well as the fastboot executable, to help you flash the images to your device.

With the above files, you can:

• Keep your Dev Phone up to date with the latest Android system images
• Test your application on multiple Android platform versions, to ensure compatibility
• Restore a corrupted device to a factory state

When flashing your device, make sure that you follow all of the instructions below, in the order that they are given.

Note that you can flash a system only to a supported device, as described in the following sections.

Overview

The sections below describe two alternative methods that you use to flash your device with a factory Android system image:

* Flashing the device using an updated recovery image (recovery-image method)

This approach involves using the adb tool, available in the Android SDK, to copy updated radio and recovery images to the device’s recovery partition on the SD card. It’s a straightforward operation that you can run in a Windows, OS X, or Linux environment. If you are an Android application developer, this method of flashing your device is recommended. Note that to use this method, the device must have the original factory bootloader that came with the device (hboot 0.95.3000).

* Flashing the device using fastboot commands (fastboot method)

This approach is slightly more complicated and involves using the adb tool to update the radio image and the fastboot tool to flash a system image to the device. Flashing your device in this way is useful if you need to install the radio and system images independently or you are already familiar with fastboot and are using it successfully in your environment. To use this method, your device must have a fastboot-compatible bootloader. Having the original factory bootloader included on ADP devices is not required.

Before you get started, decide which of these two methods is appropriate for you, then follow the instructions below, in the order given. The flashing process for both methods is similar ??the main difference is that the recovery-image method does not require the fastboot tool. Rather than using fastboot to flash a system image to the device, you use adb to copy an updated recovery image to the device. All other steps are the same.

Supported Devices

The system images provided on this page are designed only for installation on devices that meet the following requirements:

• HTC Dream hardware platform only
• Device must include a development bootloader that supports fastboot

You cannot flash these system images to other hardware platforms or to versions of HTC Dream hardware that don’t have a development bootloader that supports fastboot (fastboot is described in the next section). For example, the bootloader on T-Mobile G1 devices (and similar consumer devices) is not a development bootloader and does not support fastboot, so you cannot flash a new system image to those devices.

Get the Tools

To flash a system image to your device, you need a command-line tool called fastboot and the adb tool provided in the Android SDK.

The information of the executables that can be downloaded from the support site

On OS X and Linux, you can store the fastboot executable anywhere on your machine. On Windows, you must store the fastboot executable where it can find the AdbWinApi.dll file (included with the Android SDK), otherwise it will not work properly.

The recommended place to store the fastboot executable on Windows is with the other tools in the Android SDK, in the <sdk>/tools directory. On all platforms, you may want to add the location to your PATH, for convenience.

If your command line interface does not recognise fastboot,

On Windows, where <sdk>/tools has been added to path, Click START->Run. Type ‘cmd’ and click ENTER, In the console type ‘cmd’ and then type ‘fastboot’ and press ENTER

You cannot proceed with the upgrade of the System Image without fastboot, so the above steps are A MUST.

If you do not have the Android SDK installed on your local machine, download the latest version from this location and install it:

http://developer.android.com/sdk/1.5_r1/index.html

Once you install the SDK, the adb tool will be available to you.

If your development machine is running Windows, you should make sure to update your USB driver before continuing. For your convenience, the Android SDK (1.0 r2 or later) includes an updated USB driver that you can install. For more information, see Setting up a Device for Development on the Android Developers Site.

Download the Image Packages

To flash a new system image to your device, you need to download two image packages to your local machine.

• If you are flashing your device using the recovery-image method, you need to download a recovery image package and a radio image package only.
• If you are flashing your device using the fastboot method, you need to download a system image package and a radio image package only.

Radio Image Download

Each Android platform version is designed to run on top of a specifc version of the radio firmware. Typically, each successive release of the Android platform relies on a newer version of the radio firmware, so whenever you are planning to flash a new system image to your device, whether upgrade or downgrade, you should also update the radio firmware to the version expected by the platform. If you do not update your radio image, the system may encounter problems.

Download the signed radio image packages that you need from support site. The platform version compatibility of each radio image package is indicated in its filename.

Once you’ve downloaded a radio image package, you do not need to extract it — you can reference the image package directly from adb commands, as described in the sections below. You can store the radio image package anywhere on your machine, but make sure to store to maintain its version-specific naming.

System Image Download

Download the signed system image packages that you need from support site. Multiple versions of the Android platform are available, so make sure that you understand what version(s) you need and what version(s) you are downloading.

For development, you should select the lowest possible Android platform version that meets the needs of your applications. For example, if you are working in the Android 1.1 SDK and your application is using APIs introduced in Android 1.1, then you should download the Android 1.1 system image. If you are using the Android 1.1 SDK but your application does not use Android 1.1 APIs, then using Android 1.0 image is sufficient.

For testing, consider downloading all platform versions with which your application is compatible, then running your applications on those platform versions to ensure that they work as designed.

Each system image package is a .zip archive that includes several images that you will flash to your device:

• A boot image — contains the kernel and initrd.
• A recovery image — contains files used for rebuilding/updating the system.
• A system image — contains the Android platform/apps of the specified version.

Note that the images in each package are mutually dependent, so you must flash them all to your device together. For example, you should not flash a system image to the device without also flashing the boot and recovery images included in the same image package.

Once you’ve downloaded a system image package, you do not need to extract it — you can reference the image package directly from fastboot commands, as described in the sections below. You can store the system image package anywhere on your machine, but make sure to store to maintain its version-specific naming.

Recovery Image Download

If you are flashing your device using the recovery-image method, download the recovery image package(s) that you need from the list of links in the table above. Currently, a recovery image packages is available only for the Android 1.1 platform version.

Each recovery image package is a .zip archive containing the full contents of a recovery partition, including:

• A boot image – contains the kernel and initrd.
• A recovery image – contains files used for rebuilding/updating the system.
• A system image – contains the Android platform/apps of the specified version.
• A radio image – contains the compatible radio firmware.

Note that the images in each recovery package are mutually dependent, so you must copy them all to your device together. For example, you should not copy a system image to the device without also copying the boot and recovery images included in the same image package.

Once you’ve downloaded a recovery image package, you do not need to extract it – you can reference the image package directly from adb commands, as described in the sections below. You can store the recovery image package anywhere on your machine, but make sure to store to maintain its version-specific naming.

PAINPOINT: Cannot downgrade to Android 1.1 with recovery package 142608

If you are using the recovery-image method and had previously downloaded and the Android 1.1 recovery package signed-dream_devphone-ota-142608.zip, you should make sure to download the replacement recovery package signed-dream_devphone-ota-142608-b.zip (see the download link at the top of this page).

This is necessary because the recovery package signed-dream_devphone-ota-142608.zip prevents you from downgrading to it from a higher version of the recovery image. Therefore, if you upgrade to the Android 1.5 recovery image, you won’t be able to downgrade to Android 1.1 unless you use the replacement package signed-dream_devphone-ota-142608-b.zip.

Update the Device Radio Firmware

Follow the steps below to update the radio image on the device.

1. Ensure that a SD card is inserted in the device
2. Boot the device normally
3. Connect the device to your development machine over USB.
4. At a command line, ensure that adb recognizes your device by issuing this command:
5. $ adb devices
   You should see your device in the console output generated by the command
6. Use the adb push command to copy the contents of the radio image package to the update.zip archive on the device’s SD card:
7. $ adb push <radio-image-package>.zip /sdcard/update.zipThe command prints the number of bytes copied and the elapsed time, then completes. However, note that the files are still being copied in the background, so wait a minute or two before continuing. If you continue too soon and terminate the operation before it is complete, you will get a “bad update.zip” error later, when you try to install the update. To ensure that the entire radio image package is copied before you continue, use this command:

   $ adb shell sync

   When sync returns, all of the data has been copied to the device.
   PAIN POINT: I never got a ! icon following step 8 from the Support site. And without completing the steps below, the installation is NOT complete. Turn off your Phone:Press ‘Menu’ to go to Main Screen with Wallpaper.Keep the ‘Call end’ button pressed till you get the Phone options, and select Power Off option. Select OK to shut down.

8. Hold the home key and power key to boot and enter the recovery mode. When the device enters recovery mode, it displays a “!” icon.
9. With the recovery console displayed, open the sliding keyboard and hold down the ALT+l key combination to enable log output in the recovery console and continue.
10. Next, hold down the ALT+s key combination to install the update. An “installing update” icon and progress bar are displayed (keep holding the ALT+s combination) — when the progress bar completes, the installation is finished.
11. Press the HOME-BACK key combination to write the radio image, update the firmware, and automatically reboot. Note that if you do not use HOME-BACK at this point, the device will not load the updated radio image. After writing the radio image, the device shows a “updating firmware” icon for a few seconds and then automatically reboots in normal mode.

After the device reboots normally, you can update the system image, as described in the next section.

To check the radio image version, you can start the device in fastboot mode (see below). If you still find the old image version, your update was not complete.

Copy the Recovery Image Package to the Device
For the recovery-image method only, after you’ve successfully updated the radio firmware, the next (and final) step is using the adb tool to copy the recovery image package to the device SD card. (If you are using the fastboot method, you do not need to copy a recovery image to the device – see Flash the System Image Package to the Device instead.)

follow the steps below to update the recovery image on the device.

1. Ensure that a SD card is inserted in the device
2. Boot the device normally
3. Connect the device to your development machine over USB.
4. At a command line, ensure that adb recognizes your device by issuing this command:
5. $ adb devices
   You should see your device in the console output generated by the command
6. Use the adb push command to copy the contents of the recovery image package to the update.zip archive on the device’s SD card:
7. $ adb push <recovery-image-package>.zip /sdcard/update.zipThe command prints the number of bytes copied and the elapsed time, then completes. However, note that the files are still being copied in the background, so wait a minute or two before continuing. If you continue too soon and terminate the operation before it is complete, you will get a “bad update.zip” error later, when you try to install the update. To ensure that the entire recovery image package is copied before you continue, use this command:

   $ adb shell sync

   When sync returns, all of the data has been copied to the device.

   PAIN POINT: I never got a ! icon following step 8 from the Support site. And without completing the steps below, the installation is NOT complete. Turn off your Phone:Press ‘Menu’ to go to Main Screen with Wallpaper.Keep the ‘Call end’ button pressed till you get the Phone options, and select Power Off option. Select OK to shut down.

8. Hold the home key and power key to boot and enter the recovery mode. When the device enters recovery mode, it displays a “!” icon.
9. With the recovery console displayed, open the sliding keyboard and hold down the ALT+l key combination to enable log output in the recovery console and continue.
10. Next, hold down the ALT+s key combination to install the update. An “installing update” icon and progress bar are displayed (keep holding the ALT+s combination) — when the progress bar completes, the installation is finished.
11. Press the HOME-BACK key combination to write the recovery image, update the firmware, and automatically reboot. Note that if you do not use HOME-BACK at this point, the device will not load the updated recovery image. After writing the recovery image, the device shows a “updating firmware” icon for a few seconds and then automatically reboots in normal mode.

After the device reboots normally, the operation is complete.

Flash the System Image to the Device
For the fastboot method only, after you’ve successfully updated the radio firmware, the next (and final) step is using the fastboot tool to flash the system image package to the device. Note that you should always update the radio image whenever you update the Android system image on your device. (If you are using the recovery-image method, you do not need to flash the system image package to the device – see Copy the Recovery Image Package to the Device instead.)

Follow the steps below to flash a system image package to your device:

1. Boot the device in fastboot mode.PAIN POINT: Hold the Camera button and the power button at the same time when powering on, the phone will boot into Boot Loader Mode.Make sure the display on the phone changes from “Serial0″ to “FASTBOOT”. If it doesn’t, try pressing the back button.The device is now in fastboot mode and is ready to receive fastboot commands. (I have had success doing this with usb plugged in the whole time, but others haven’t. If you have trouble, try it w/ usb unplugged until you see the skateboards screen.).If you want to exit fastboot mode at this point, you can hold down the keys MENU+Call Start + Call End together.
   Note that the bootloader screen may vary across devices.
   For Android Dev Phone devices, the bootloader screen shows an image of skateboarding robots. Other devices may show a different image or color pattern. In all cases, the bootloader screen shows the text “FASTBOOT” when in fastboot mode. The bootloader also shows the radio version.
2. Connect the device to your development machine over USB, if it isn’t currently connected.
   • USBClass_ff&SubClass_42&Prot_03
   • USBClass_ff&SubClass_42
   • USBClass_ff

From your computer command line type > fastboot devices.(Keep the emulator off, and the device should be indicated:
List of devices attached
HTXXXXXXXXXX device

PAIN POINT: Device is not seen in fastboot mode.

(NOTE: Check the USB device in Computer Manager when the phone IS IN fastboot mode. The computer sees the phone in fastboot mode as a different device than the phone in normal mode)

When the Device is in fastboot mode:

If it asks you to install drivers, then go ahead and use the same usb drivers that you used to get adb working. You can skip the rest of the instructions. Fastboot should be working for you now.
If it doesn’t ask you to install a driver, you need to figure out if the correct driver is loaded already.
Right click on My Computer, and click Manage, then go to the device manager

If you see an “ADB Interface” category at/near the top, with “HTC Dream” under it, then you’re good to go. Fastboot should be working for you.

In the device manager, go down to “Universal Serial Bus Controllers”, and see if you have at least one “USB Mass Storage device”. If you have multiple ones, you’ll need to go through each to find the correct one.

To find the correct one, right click on the USB Mass Storage device and click Properties. Go to the Details tab. In the combo box at the top that says “Device Instance Id”, bring up the pull down and choose “Compatible Ids”. If that is the correct device, then you will see 3 entries:

Once you find the correct device, go to the driver tab, and click “Update Driver”. Choose “No, not this time”, then “Install from a list or specific location”, then “Don’t search, I will choose the driver to install”, and then choose the same usb driver that you used to get adb to work (most probably located in the <sdk>/usb_drivers or its sub-folder)

PAIN POINT: If you don’t see an “ADB Interface” category, then it’s likely that windows loaded the USB Mass Storage driver for it automatically OR If the ADB Interfaces category is seen, but ADB devices/fastboot devices command is not able to list the device.

Unplug all your USB devices, and plug only the G1 device,

Then Uninstall the

ADB Interface->HTC Dream Composite ADB Interface (if present).

USB Serial Bus Controllers->USB Composite Device

USB Serial Bus Controllers ->USB Mass Storage Device

Now Use the USB cord to plug in the G1 Device to your computer, You will be prompted for drivers. Choose to “Install from a list or specific location”, then “Don’t search, I will choose the driver to install”, and then choose the same usb driver that you used to get adb to work (most probably located in the <sdk>/usb_drivers or its sub-folder).

After that’s done, you should be good to go. Open a command prompt and type fastboot devices and it should list the phone.

Note that, rather than using separate fastboot commands to erase the userdata and cache partitions, as described in the previous steps, you can simply supply the -w option when flashing the system image, which has the same result.

3. Next, use this fastboot command to flash the contents of the image package to the device:
4. $ fastboot update <imagepackage>.zip [-w] With this command, fastboot copies all of the images in <system-image-package>.zip to the appropriate partitions on the device. During the process, it prints status messages to the command shell. Depending on your bootloader version, fastboot may also print status messages to the bootloader screen.When all image are copied to the device successfully, fastboot displays a success message.PAIN POINT: Even though I had completed a successful radio image update, and had the proper bootloader version 0.95.3000, I was not able to successfully update the System Image.Unzip the System image and extract these files to your <sdk>/tools and flash the boot.img, recovery.img and system.img individually:

   $fastboot flash boot boot.img
   $fastboot flash recovery recovery.img
   $fastboot flash system system.img

   You may want erase the contents of the userdata partition, by using this fastboot command:

   $ fastboot erase userdata

   This will remove all of the installed applications and their data, but it is a useful step when debugging because it ensures a clean execution environment for the application. Erasing the user data may also be necessary when you are flashing a lower (downgrade) platform version to your device. However, it is not strictly necessary to erase the userdata partition when upgrading to a higher (upgrade) platform version, which is the typical use-case in consumer devices.

   You may also want to erase the cache partition, using this fastboot command:

   $ fastboot erase cache

5. Reboot the device. In most cases, fastboot should reboot the device automatically after copying the image files.
   If necessary, you can reboot the device manually using these fastboot commands:
   $ fastboot reboot or $ fastboot reboot-bootloaderYou can also reboot from the device from the fastboot mode, by holding down the key combination MENU+Call Start + Call End.For information about other fastboot commands, use$ fastboot

• Windows XP or Vista
• Mac OS X 10.4.8 or later (x86 only)
• Linux (Linux Ubuntu Dapper Drake)

The following sections are covered:

1. Installing the .apk file on a new G1 device
2. Installing the .apk file on a device where section 1 has already been followed for steps 1 to 5
3. Uninstalling the .apk file from the G1 device before installing the same .apk again.
4. Uninstalling the .apk file (from the Device or Emulator) using adb shell .

Section 1: Installing the .apk file on a new G1 Device:

1. Installing The Android SDK on your computer.
   • First you will need to download the Android SDK pack .zip archive, once downloaded find a suitable installation location on your machine and extract the zipped files.
   • Please note: This installation location will be referred to as $ANDROID_SDK_PATH in the following sections.
   • Alternatively you can add /tools to your root path which will prevent the need to specify the full path to the tools directory along with enabling you to run Android Debug Bridge (adb) along with other command line tools.
2. To add /tools to System PATH:
   Windows XP / Vista
   • Right click on the My Computer icon and select the properties tab.
   • Select the Advanced tab and click the Environment Variables button.
   • In the new dialog box double-click on Path (located under System Variables) and type in the full path location to the tools directory.

   Alternately, create a System Variable, called ANDROID_SDK_PATH and append %ANDROID_SDK_PATH%\tools to your System PATH variable.

   Linux

   • Edit the ~/.bash_profile or ~/.bashrc files looking for a line that sets the PATH variable.
   • Add the full path location to your $ANDROID_SDK_PATH/tools location for the PATH variable.
   • If no PATH line exists you can add the line by typing the following:
   • Export PATH=${PATH}:<path to your $ANDROID_SDK_PATH /tools>

   Mac OS X

   • In the home directory locate the .bash_profile and locating the PATH variable add the location to your $ANDROID_SDK_PATH /tools folder.
3. Connect the G1 device to the computer through the USB port. (If connecting for the first time, User is prompted to install the drivers in which case, point to $ANDROID_SDK_PATH/usb_driver, the drivers will get installed.)
4. You might have to change your settings to permit apps that don’t come from the Google Market by going to the G1 home screen and choosing MENU > Settings > Applications > Unknown Sources.
5. Turn USB debugging ON on your phone, On your G1 go to the home screen, press MENU > Settings > Applications > Development, then enable USB debugging.
6. From Command line on your computer enter
   ‘adb install <APK_FILE_PATH><APK_FILE>’
   (e.g. adb install C:/AndroidApps/NightStand.apk)
7. Check the MENU from the home screen on the G1 for the installed applications icon.

Section 2: Installing the .apk file on a device where section 1 has already been followed for steps 1 to 5

1. Follow steps 6 and 7 of Section 1.

Section 3: Uninstalling the .apk file from the G1 device before installing the same .apk again.

1. In the G1 Phone, Go to Applications Menu ->Settings->Manage Applications.
2. Select the application which you want to Uninistall, and click on the ‘Uninstall’ button.
3. Follow steps 6 and 7 of Section 1.

Section 4: Uninstalling the .apk file (from the Device or Emulator) using adb shell.

There is an adb uninstall command which always shows Failure!!!

Using adb shell :
Important: The device has to be unplugged from USB if you are trying to uninstall from the emulator, else emulator should not be open and device needs to be plugged in the USB of the PC if you are trying to uninstall from the G1 Device. If either of them are not connected the adb shell command will not work

Go to the shell and making sure adb is in PATH:

Go to shell (from cmd->adb shell or directly through a terminal)

#

#cd data
#cd app
#cd ls

You will get a list of installed application with the complete package name of the package containing the main activity. e.g com.company.product.apk

#rm com.company.product.apk

#cd ls

You will not find the application – you just removed it!.