Location and maps-based applications are compelling for mobile device users.

You can build application by android.location packages and com.google.android.maps.MapView which is sub class of ViewGroup in Andorid.

Location Services :

1.Android gives your applications access to the location services supported by the device through the classes in the android.location package.

2.The central component of the location framework is the LocationManager system service, which provides APIs to determine location and bearing of the underlying device (if available).

You do not instantiate a LocationManager directly. Rather, you request an instance from the system by calling getSystemService(Context.LOCATION_SERVICE). The method returns a handle to a new LocationManager instance.

Once your application has a LocationManager, your application is able to do three things:

1.we can Query for the list of all LocationProviders for the last known user location.

2.Register/unregister for periodic updates of the user's current location from a location provider .

3.Register/unregister for a given Intent to be fired if the device comes within a given proximity (specified by radius in meters) of a given lat/long.

Next Post we will see this location services with Examples.

Among the most important things to master for a mobile application developer is network programming. Every mobile application I have developed has involved some kind of network communication. During the year I have learned a thing or two. Read on to get some tips & trick from me.

Quite often the server is developed alongside the client. This means that you as a client developer have to wait for those awfully slow server programmers. Not every server programmer is slow, but most likely you have to wait for some server functionality. In situations like these, it is handy to roll your own server. But as a client developer, you do not want to spend an massive amount of time to setup a server. In fact, if it takes longer than a couple of minutes most client developers give up. What you need is a server that is very quick and easy to setup. Also it needs to be simple, yet powerful. Many server programmers would recommend you setting up a Tomcat server. The advantage of using a Tomcat server is that it is very versatile. But I do not really like Tomcat. It is to advanced for me. Another solution is to use a Jetty server. This is simpler to setup than Tomcat, but yet rather powerful. It could be executed from Maven. As such is is convenient to use for automated tests. Maven takes cares most of the work, including starting and stopping your Jetty server. But there is a new and rising star, the Sinatra server. The Sinatra server is actually a Ruby library. You use Ruby to program the behavior of your server.   

A simple “Hello World” implementation for Sinatra looks like the one below (from the Sinatra Book).

require 'rubygems'
require 'sinatra'

get '/' do
  "Hello world, it's #{Time.now} at the server!"
end

The file is saved as a file with .rb extension, in our example we save it as “hello.rb”. Then you start your server as simple as this:

ruby hello.rb

You get a nice line saying that Sinatra has taken the stage and that your server uses port 4567. This could of course be changed, if you want to mimic another server without changing your code. It is very easy to extend your server functionality. Ruby is easy to learn and powerful for making your own server without any big hazzle. Take a look at the “Sinatra Book” if you want to master Sinatra.

Another common scenario is that you need to figure out what happens when you make a certain URL request, for example if you do a REST request. Before even writing a single of code, you could use the cURL command line tool. Its available on most platforms, like Unix, Linux, Mac OS, Windows etc. For a matter of discussion, let us assume that you want to check that you programmed your Sinatra web server correctly. Then you the following command:

curl http://127.0.0.1:4567/

The response should look like this:

Hello world, it's Mon Oct 25 20:44:19 +0200 2010 at the server!

So now you know how to implement your own simple server, as well as how to debug your server request using curl. But wait, there is even more tricks I want to share with you. I hope that you feel like reading a little bit more.

I think that XML is a rather misused technologies around. It is used for many things, ranging from describing your builds (Ant, Maven, etc) to describing serialized objects traveling through cyberspace (SOAP, REST etc). When SOAP was introduced, one main argument for XML is that it human readable. What? Have you ever seen a SOAP request that is human readable? If you are about to send and/or receive objects there are much more suitable technologies than XML. Especially when making a mobile client, where XML parsing could take to much time and memory, it is important to understand that there are good alternatives. One good old technology is ASN.1, that is hugely underestimated. It was designed for communicating data between different architectures and CPUs. It is fast even on a 8-bit CPU. The biggest drawback is that it is not widely supported and it requires an ASN.1 compiler. However you could implement your own ASN.1 encoder/decoder quite easy. Another solution that is easier to use, but building on the same principles as ASN.1 is the Hessian protocol. It is a binary web service protocol. The specification is originally designed by Caucho, who did the Resin web server. The specification is open and implemented in many languages, including .NET, Flash, Ruby, Python, Objective-C etc. I have primarily used it for Java ME, where only a subset is implemented. If you use it in Java ME, I would recommend considering using it to store object data in the record store. But now it is more relevant for me to use it on Android or iPhone. The Objective-C variant for iPhone is called HessianKit. It is open source and released under Apache 2.0 license. Thus it is not a viral open source license, which I think is great. I will not describe how to use it, since there already is a good article on the subject “HessianKit Released”. I hope that you will consider using Hessian if you are in the position to decide what web service protocol to use. If you feel the urge to use XML for your web services, you could use Burlap which is the XML version of Hessian. The communication is as simple as it could get using XML.

Another useful tool is a network analyzer. This is good for finding out what happens between the client and server. For example, if you want to take a look at the headers are many times auto generated. I have used Wireshark with great success. It would not say it is easy to use, but when you need to use it is priceless.

These are the tools that I think I use the most for network programming. What are your best tools when doing network programming?

In the Code Pollution series, I'll be writing about topics where a coding anti-pattern may work tactically for an individual application, but strategically will be bad for Android as a whole, just as pollution may benefit one firm while harming many others.

Many readers have, at one point in time or another, had a Windows PC that got overloaded with "cruft" and took forever and a day to boot up. Or, even if it would boot normally, it would be slow as a dog for the first minute or two after the desktop showed up.

While it would be fun and entertaining to bash Windows for this, in reality, it was probably third party applications causing a chunk of the problem. Lots of programs think that they just have to do something when the PC starts up, and too many of them bring the boot process to a halt.

The good news is that, for most people, Android is plenty stable enough not to require constant reboots. The bad news is that Android devices may still need to be rebooted from time to time, to process firmware upgrades, to recover from a dead battery, and the like.

One of the things the core Android team feared was too many applications asking to do something at boot time, via the BOOT_COMPLETED broadcast Intent, and causing the boot process to become horribly slow. That is why you need the REQUEST_BOOT_COMPLETED permission to receive BOOT_COMPLETED broadcasts -- the theory being that users who have had problems with slow boots might be less inclined to install other programs that demand boot-time access.

Still, though, it is up to us as developers to try to make the boot process as quick and painless as possible. Here are some ways you can help:

Do not request BOOT_COMPLETED broadcasts unnecessarily. For example, some developers may think it would be cool to steal three or four seconds of processing time at boot to do some sort of initialization, rather than have to deal with that work when their app is started. Tactically, this will improve responsiveness of that one application...at the cost of harming all applications on a reboot.
Do whatever you need to do quickly. If BOOT_COMPLETED is unavoidable, try to get in and out in few dozen milliseconds, not a few seconds.
Consider whether you can wait a bit. Many times, apps do not need to start up right at boot time, but rather sometime after a reboot. Unfortunately, there is no built-in way to ask for a "early, but not right away" broadcast...unless you set one up yourself. Consider whether you could use AlarmManager to do a one-shot alarm to fire your real boot-time code a minute or two after the boot is over. You only lose a minute, and it clears out the rest of the boot processing, and perhaps some initial user actions, before your code needs to join the fray.

QR Code for WalkyTalky:



QR Code for Intersection Explorer:

Today I received a brand new iPhone 4. Life was joyful. However it gave me some frustrating moments before I could use it for real. Here is the true story what happened when I got my iPhone 4.

I had prepared the migration by backing up my contacts from my HTC Hero. The HTC had no way to export contacts to a SIM card, but only to SD card. Strangely enough it was possible to import contacts from a SIM card. Anyway I did not consider this to be a big problem, since exporting to the SD card should work fine.The contacts was saved as a VCF file. This was easily imported by double-clicking on the file. When this was done, all the google contacts was on my Mac Book. After I started and initialized the iPhone, it was connected via a USB cable to the Mac Book. Consequently iTunes was started with a wizard. One of the steps was the sync setup. By default all contacts was to be synced. Perfect! This was exactly what I wanted. A couple of more steps and I pressed the “Sync”-button.

After a short while something really odd happened. A warning message saying that no synchronization of contacts was not possible, since the phone was not connected. What! The phone was connected. Not good! I discovered a button labeled “Restore”. The help text explained that this should be used when in trouble. I felt like being in trouble and hit the restore button. The process was really fast, but enough time to get some tea. Then the same procedure once more. Still the same problem. Next try; search the Internet. I found out that I was not alone with this problem. I tried out all of the different solutions explained in the forum. Do not know how many times I cleared the sync settings, restarted the phone, re-booted the computer and all other kinds of tricks. The Apple support pages did not contain any other suggestions than found in the forum. Now I was really frustrated. I should not be that complicated to get your contacts into your new phone. Time to get a break. Get your brain to think in a different way. Reset the brain. Get some food.

Several hours later it was time to try a new approach. I googled “Sync iPhone Google”. I found an article called “Google Sync: Set Up Your Apple Device for Google Sync“. It seemed to be exactly what I was looking for. The article explained how to use add an account in the iPhone to synchronize mail, contacts and calendar. In fact it was a Microsoft Exchange account. It took me less than 5 minutes to have mail, contacts and the calendar in sync.

The final solution was much simpler than copying contacts via the computer. The intent was to only transfer the contacts and then set up a mail account on the phone. Now I get an all-in-one solution,  with mail, contacts and calendar synchronization. Now my life is joyful again.

Each year since its inception, I have attended the Öredev developer conference. What makes it special is that it is a combined conference, with not only Java. This year it is especially important for me, since I can learn about both Android and iPhone development.

I will attend this year. Will you?

Do not forget to register at the Öredev site.

The Android Market licensing service is a powerful tool for protecting your applications against unauthorized use. The License Verification Library (LVL) is a key component. A determined attacker who’s willing to disassemble and reassemble code can eventually hack around the service; but application developers can make the hackers’ task immensely more difficult, to the point where it may simply not be worth their time.

Out of the box, the LVL protects against casual piracy; users who try to copy APKs directly from one device to another without purchasing the application. Here are some techniques to make things hard, even for technically skilled attackers who attempt to decompile your application and remove or disable LVL-related code.

1.You can obfuscate your application to make it difficult to reverse-engineer.

2.You can modify the licensing library itself to make it difficult to apply common cracking techniques.

3.You can make your application tamper-resistant.

4.You can offload license validation to a trusted server.

This can and should be done differently by each app developer. A guiding principle in the design of the licensing service is that attackers must be forced to crack each application individually, and unfortunately no client-side code can be made 100% secure. As a result, we depend on developers introducing additional complexity and heterogeneity into the license check code — something which requires human ingenuity and and a detailed knowledge of the application the license library is being integrated into.

Technique: Code Obfuscation

The first line of defense in your application should be code obfuscation. Code obfuscation will not protect against automated attacks, and it doesn’t alter the flow of your program. However, it does make it more difficult for attackers to write the initial attack for an application, by removing symbols that would quickly reveal the original structure of a compiled application. As such, we strongly recommend using code obfuscation in all LVL installations.

To understand what an obfuscator does, consider the build process for your application: Your application is compiled and converted into .dex files and packaged in an APK for distribution on devices. The bytecode contains references to the original code — packages, classes, methods, and fields all retain their original (human readable) names in the compiled code. Attackers use this information to help reverse-engineer your program, and ultimately disable the license check.

Obfuscators replace these names with short, machine generated alternatives. Rather than seeing a call to dontAllow(), an attacker would see a call to a(). This makes it more difficult to intuit the purpose of these functions without access to the original source code.

There are a number of commercial and open-source obfuscators available for Java that will work with Android. We have had good experience with ProGuard, but we encourage you to explore a range of obfuscators to find the solution that works best for you.

We will be publishing a separate article soon that provides detailed advice on working with ProGuard. Until then, please refer to the ProGuard documentation.

Technique: Modifying the license library

The second line of defense against attack from crackers is to modify the license verification library in such a way that it’s difficult for an attacker to modify the disassembled code and get a positive license check as result.

This actually provides protection against two different types of attack: it protects against attackers trying to crack your application, but it also prevents attacks designed to target other applications (or even the stock LVL distribution itself) from being easily ported over to your application. The goal should be to both increase the complexity of your application’s bytecode and make your application’s LVL implementation unique.

When modifying the license library, there are three areas that you will want to focus on:

The core licensing library logic.
The entry/exit points of the licensing library.
How your application invokes the licensing library and handles the license response.
In the case of the core licensing library, you’ll primarily want to focus on two classes which comprise the core of the LVL logic: LicenseChecker and LicenseValidator.

Quite simply, your goal is to modify these two classes as much as possible, in any way possible, while still retaining the original function of the application. Here are some ideas to get you started, but you’re encouraged to be creative:

Replace switch statements with if statements.
Use XOR or hash functions to derive new values for any constants used and check for those instead.
Remove unused code. For instance, if you’re sure you won’t need swappable policies, remove the Policy interface and implement the policy verification inline with the rest of LicenseValidator.
Move the entirety of the LVL into your own application’s package.
Spawn additional threads to handle different parts of license validation.
Replace functions with inline code where possible.

For example, consider the following function from LicenseValidator:

public void verify(PublicKey publicKey, int responseCode, String signedData, String signature) {
// ... Response validation code omitted for brevity ...
switch (responseCode) {
// In Java bytecode, LICENSED will be converted to the constant 0x0
case LICENSED:
case LICENSED_OLD_KEY:
LicenseResponse limiterResponse = mDeviceLimiter.isDeviceAllowed(userId);
handleResponse(limiterResponse, data);
break;
// NOT_LICENSED will be converted to the constant 0x1
case NOT_LICENSED:
handleResponse(LicenseResponse.NOT_LICENSED, data);
break;
// ... Extra response codes also removed for brevity ...
}


In this example, an attacker might try to swap the code belonging to the LICENSED and NOT_LICENSED cases, so that an unlicensed user will be treated as licensed. The integer values for LICENSED (0x0) and NOT_LICENSED (0x1) will be known to an attacker by studying the LVL source, so even obfuscation makes it very easy to locate where this check is performed in your application’s bytecode.

To make this more difficult, consider the following modification:

public void verify(PublicKey publicKey, int responseCode, String signedData, String signature) {
// ... Response validation code omitted for brevity …

// Compute a derivative version of the response code
// Ideally, this should be placed as far from the responseCode switch as possible,
// to prevent attackers from noticing the call to the CRC32 library, which would be
// a strong hint as to what we're done here. If you can add additional transformations
// elsewhere in before this value is used, that's even better.
java.util.zip.CRC32 crc32 = new java.util.zip.CRC32();
crc32.update(responseCode);
int transformedResponseCode = crc32.getValue();

// ... put unrelated application code here ...
// crc32(LICENSED) == 3523407757
if (transformedResponse == 3523407757) {
LicenseResponse limiterResponse = mDeviceLimiter.isDeviceAllowed(userId);
handleResponse(limiterResponse, data);
}
// ... put unrelated application code here ...
// crc32(LICENSED_OLD_KEY) == 1007455905
if (transformedResponseCode == 1007455905) {
LicenseResponse limiterResponse = mDeviceLimiter.isDeviceAllowed(userId);
handleResponse(limiterResponse, data);
}
// ... put unrelated application code here ...
// crc32(NOT_LICENSED) == 2768625435
if (transformedResponseCode == 2768625435):
userIsntLicensed();
}
}

In this example, we’ve added additional code to transform the license response code into a different value. We’ve also removed the switch block, allowing us to inject unrelated application code between the three license response checks. (Remember: The goal is to make your application’s LVL implementation unique. Do not copy the code above verbatim — come up with your own approach.)

For the entry/exit points, be aware that attackers may try to write a counterfeit version of the LVL that implements the same public interface, then try to swap out the relevant classes in your application. To prevent this, consider adding additional arguments to the LicenseChecker constructor, as well as allow() and dontAllow() in the LicenseCheckerCallback. For example, you could pass in a nonce (a unique value) to LicenseChecker that must also be present when calling allow().

Note: Renaming allow() and dontAllow() won’t make a difference, assuming that you’re using an obfuscator. The obfuscator will automatically rename these functions for you.

Be aware that attackers might try and attack the calls in your application to the LVL. For example, if you display a dialogue on license failure with an “Exit” button, consider what would happen if an attacker were to comment out the line of code that displayed that window. If the user never pushes the “Exit” button in the dialog (which is no not being displayed) will your application still terminate? To prevent this, consider invoking a different Activity to handle informing a user that their license is invalid, and immediately terminating the original Activity; add additional finish() statements to other parts of your code that get will get executed in case the original one gets disabled; or set a timer that will cause your application to be terminated after a timeout. It’s also a good idea to defer the license check until your application has been running a few minutes, since attackers will be expecting the license check to occur during your application’s launch.

Finally, be aware that certain methods cannot be obfuscated, even when using a tool such as ProGuard. As a key example, onCreate() cannot be renamed, since it needs to remain callable by the Android system. Avoid putting license check code in these methods, since attackers will be looking for the LVL there.

Technique: Make your application tamper-resistant

In order for an attacker to remove the LVL from your code, they have to modify your code. Unless done precisely, this can be detected by your code. There are a few approaches you can use here.

The most obvious mechanism is to use a lightweight hash function, such as CRC32, and build a hash of your application’s code. You can then compare this checksum with a known good value. You can find the path of your application’s files by calling context.GetApplicationInfo() — just be sure not to compute a checksum of the file that contains your checksum! (Consider storing this information on a third-party server.)

[In a late edit, we removed a suggestion that you use a check that relies on GetInstallerPackageName when our of our senior engineers pointed out that this is undocumented, unsupported, and only happens to work by accident. –Tim]

Also, you can check to see if your application is debuggable. If your application tries to keep itself from performing normally if the debug flag is set, it may be harder for an attacker to compromise:

boolean isDebuggable = ( 0 != ( getApplcationInfo().flags &= ApplicationInfo.FLAG_DEBUGGABLE ) );
Technique: Offload license validation to a trusted server

If your application has an online component, a very powerful technique to prevent piracy is to send a copy of the license server response, contained inside the ResponseData class, along with its signature, to your online server. Your server can then verify that the user is licensed, and if not refuse to serve any online content.

Since the license response is cryptographically signed, your server can check to make sure that the license response hasn’t been tampered with by using the public RSA key stored in the Android Market publisher console.

When performing the server-side validation, you will want to check all of the following:

That the response signature is valid.
That the license service returned a LICENSED response.
That the package name and version code match the correct application.
That the license response has not expired (check the VT license response extra).
You should also log the userId field to ensure that a cracked application isn’t replaying a license response from another licensed user. (This would be visible by an abnormally high number of license checks coming from a single userId.)
To see how to properly verify a license response, look at LicenseValidator.verify().

As long as the license check is entirely handled within server-code (and your server itself is secure), it’s worth nothing that even an expert cracker cannot circumvent this mechanism. This is because your server is a trusted computing environment.

Remember that any code running on a computer under the user’s control (including their Android device) is untrusted. If you choose to inform the user that the server-side license validation has failed, this must only be done in an advisory capacity. You must still make sure that your server refuses to serve any content to an unlicensed user.

Conclusion

In summary, remember that your goal as an application developer is to make your application’s LVL implementation unique, difficult to trace when decompiled, and resistant to any changes that might be introduced. Realize that this might involve modifying your code in ways that seem counter-intuitive from a traditional software engineering viewpoint, such as removing functions and hiding license check routines inside unrelated code.

For added protection, consider moving the license check to a trusted server, where attackers will be unable to modify the license check code. While it’s impossible to write 100% secure validation code on client devices, this is attainable on a machine under your control.

And above all else, be creative. You have the advantage in that you have access to a fully annotated copy of your source code — attackers will be working with uncommented bytecode. Use this to your advantage.

Remember that, assuming you’ve followed the guidelines here, attackers will need to crack each new version of your application. Add new features and release often, and consider modifying your LVL implementation with each release to create additional work for attackers.
And above all else, listen to your users and keep them happy. The best defense against piracy isn’t technical, it’s emotional.

Google Android recently launched Voice Actions in the new Google Voice Search for Android — an awesome new way to search, control, and communicate on your phone faster than ever before, by using your voice.

One of these new Voice Actions lets users find and automatically play music. By speaking something like “listen to They Might Be Giants” into the new Voice Search, users can quickly find the music they want online and play it, using any number of different apps. (Pandora, Last.fm, Spotify, mSpot, and Rdio are among the first apps to support this.)

To do this, Google leveraged a very common little piece of Android magic: a new Intent. If you develop a music app that supports open-ended music search, you can make it work with users speaking “listen to” Voice Actions simply by registering for the new intent we’ve defined. This new intent isn’t defined as a constant in the SDK yet, but google wanted to make sure music app developers had all the information needed to use it right away.

Here’s all you should need to know::

1.In your AndroidManifest.xml, just register one of your activities for the new intent android.media.action.MEDIA_PLAY_FROM_SEARCH:

EX:









2.When your activity receives this intent, you can find the user’s search query inside the SearchManager.QUERY string extra:

import android.app.Activity;
import android.app.SearchManager;

public class MusicActivity extends Activity {
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
String query = getIntent().getStringExtra(SearchManager.QUERY);
// Do something with query...
}
}

This will represent everything the user spoke after “listen to”. This is totally open-ended voice recognition, and it expects very flexible search — so, for example, the string could be the name of any artist (“they might be giants”), an album (“factory showroom”), a song (“metal detector”), or a combination of any of these (“metal detector by they might be giants”).

A few subtle details worth understanding about this intent:

Your app should do its best to quickly find and automatically play music corresponding to the user’s search query. The intention here is to get users to their desired result as fast as possible, and in this case, that means playing music quickly.

This will really only work well for music apps that can find music across a very large corpus of options. Because our voice recognition doesn’t currently support any way to provide a list of specific songs to be recognized, trying to use it against a small set of music choices will work poorly — things which are not in the set will be over-recognized, and things which are in the set may not be recognized well. So if you’re not the developer of a large-scale cloud music application, this intent is probably not for you.

Uploading applications

Once you've registered, it's easy to upload your application to Android Market. From the home screen, select "Upload Applications." You'll be asked to fill in the following information for your app.

Listing Details

Language:
This is to denote the language of your application. Default language is US English. More languages will become available as Android-powered devices become available in those languages.

Title:
The name of your application as you would like it to appear in Android Market. You may add one per language.

Description:
The description of your application as you would like to appear in
Android Market.

Application Type:
Android Market is divided into 2 major applications types: "Applications" and "Games." Please choose one.
Category:You must select a category for your application. Read more about categories.

Publishing options
Copy protection: Copy protection helps prevent applications from being copied from a device. Increases the amount of memory on the phone required to install the application. (You may also implement your own copy protection scheme.)

Locations: These are the locations in which you may distribute your applications.
Not all locations listed currently have users with Android-powered devices.
You may select locations one-by-one or choose the "All current and future locations" option. This option means that, as we add more distribution locations, these locations will be enabled for your app. Before you check this option, please brush up on Export Compliance.

Note: At this time, you may only sell applications to users in these locations.

Contact information

You must pick one support channel for your app - Website, Email, or Phone
This information is viewable to users from Android Market
You may choose to offer multiple channels for support

Transaction Fee & Profit:

or applications that you choose to sell in Android Market, the transaction fee is equivalent to 30% of the application price. For example, if you sell your application at a price of $10.00, the fee will be $3.00, and you will receive $7.00 in payment.

Setting Price of an Application:


Once you've set a price for an application, you may choose to change it at any time.

If you have previously published an application for free, you cannot change it to have a price. You'll need to upload a new APK and add a price.
Allowable price ranges:

CAD: 0.99 CAD - 210 CAD
CHF: 0.99 CHF - 200 CHF
DKK: 6 DKK - 1200 DKK
EUR: 0.50 EUR - 100 EUR
GBP: 0.50 GBP - 100 GBP
HKD: 7 HKD - 1500 HKD
JPY: 99 JPY - 20000 JPY
NOK: 6 NOK - 1200 NOK
NZD: 0.99 NZD - 280 NZD
SEK: 7 SEK - 1500 SEK
SGD: 0.99 SGD - 270 SGD
USD: $0.99 - $200

If you're already an Android Market Publisher, make sure that you've signed up as a Google Checkout Merchant so that you may sell apps:

1.Log into your Android Market account at http://market.android.com/publish/

2.Click on the "Edit profile" link.

3.Select "Setup a Merchant Account at Google Checkout."

This will take you to the Google Checkout site to sign up as a Merchant; you'll need to have information about your business handy to complete this step. Learn more about the requirements to be a Google Checkout Merchant.

Once you've set up a Google Checkout account, you'll need to take steps to ensure your apps are sold with the proper tax for your location.


Changing your Email Address ;

Changing your application's support address:
You can change the email address that is displayed with your app in Android Market by following these steps:
Log into your Android Market account
Select the application.
Under "Contact Information," input the new email address.
Click "Save" to save your settings.

Changing your Android Market contact address:
You can change the email address that used by Android Market to contact you by following these steps:

Log into your Android Market account
Click on the "Edit profile" link. This should bring you to this page http://market.android.com/publish/editProfile.
Input the new email address.
Click "Save" to save your settings.

Changing your sign-in address:
Currently, it is not possible to change the Google Account that is associated with signing-in your Android Market publisher account.


Application Statistics:

At the moment, you will be able to view the following statistics about your published applications:
Star ratings
Number of installs
Number of active installs (number of installs - uninstalls)
Please note that the statistics remain constant for the same package name, i.e. every time you upload a new version of your application, the stats will not change.

We're working hard to add more information about your applications, so please stay tuned!

Ratings:

Ratings are determined by our Android Market users. After downloading an app, users can give a star rating and a comment. They are only able to rate or comment once per app.
Please note that currently ratings and comments carry forward through different version of the same package (i.e. ratings do not re-start when you publish a new version of your app.)

Supporting for User from Android Market:

To create the best possible user experience and quickly grow your application's popularity, we recommend that you create comprehensive help resources. Users are more likely to continue to use your app and to share it with their friends if they understand how it works and how to contact you with questions or bugs. The Android Market team won't provide user support for individual apps. By offering support for your application, you'll not only help create a great user experience, but also be able to leverage user feedback to enhance and grow your application.

The following list specifies the minimum support requirements you should include:
Your name or the name of your organization so users can easily identify the authors.
A basic level of FAQ/help content hosted somewhere externally (e.g. on your site or blog). This could include a summary of the app's purpose, information on basic functionality and use, and any questions you frequently receive from users.
The URL to the help content so that it can be linked from the "About this App" page.
Provide users with a way to contact you (email address, webpage, or forum which you regularly monitor and participate in). This is an important part of creating a positive community surrounding your app, getting user feedback, and troubleshooting assistance with bugs.
Managing a high support volume:
We highly recommend using a webpage with a contact form instead of an email address. We also recommend creating an autoreply that communicates common answers to users and sets expectations on the support level you are able to provide.

Android Market Issues
Please direct users to the Market Help Center and Forum for questions related to the following:

Download or installation issues
Problems accessing Android Market
Payment or Google Checkout questions
Problems finding applications

History of GPS:

he design of GPS is based partly on similar ground-based radio navigation systems, such as LORAN and the Decca Navigator developed in the early 1940s, and used during World War II. In 1956 Friedwardt Winterberg[12] proposed a test of general relativity using accurate atomic clocks placed in orbit in artificial satellites. To achieve accuracy requirements, GPS uses principles of general relativity to correct the satellites' atomic clocks. Additional inspiration for GPS came when the Soviet Union launched the first man-made satellite, Sputnik in 1957. A team of U.S. scientists led by Dr. Richard B. Kershner were monitoring Sputnik's radio transmissions. They discovered that, because of the Doppler effect, the frequency of the signal being transmitted by Sputnik was higher as the satellite approached, and lower as it continued away from them. They realized that since they knew their exact location on the globe, they could pinpoint where the satellite was along its orbit by measuring the Doppler distortion (see Transit (satellite)).

The first satellite navigation system, Transit, used by the United States Navy, was first successfully tested in 1960. It used a constellation of five satellites and could provide a navigational fix approximately once per hour. In 1967, the U.S. Navy developed the Timation satellite that proved the ability to place accurate clocks in space, a technology that GPS relies upon. In the 1970s, the ground-based Omega Navigation System, based on phase comparison of signal transmission from pairs of stations,[13] became the first worldwide radio navigation system. However, limitations of these systems drove the need for a more universal navigation solution with greater accuracy.

While there were wide needs for accurate navigation in military and civilian sectors, almost none of those were seen as justification for the billions of dollars it would cost in research, development, deployment, and operation for a complex constellation of navigation satellites. However during the Cold War arms race, the nuclear threat to the very existence of the United States was the one need that did justify this cost in the view of the US Congress. This deterrent effect is why GPS was funded. The nuclear triad consisted of the US Navy's submarine-launched ballistic missiles (SLBMs) along with the US Air Force's strategic bombers and intercontinental ballistic missiles (ICBMs). Considered vital to the nuclear deterrence posture, accurate determination of the SLBM launch position was a force multiplier.

Precise navigation would enable US submarines to get an accurate fix of their positions prior to launching their SLBMs.[14] The US Air Force with two-thirds of the nuclear triad also had requirements for a more accurate and reliable navigation system. The Navy and Air Force were developing their own technologies in parallel to solve what was essentially the same problem. To increase the survivability of ICBMs, there was a proposal to use mobile launch platforms so the need to fix the launch position had similarity to the SLBM situation.

In 1960, the Air Force proposed a radio-navigation system called MOSAIC (Mobile System for Accurate ICBM Control) that was essentially a 3-D LORAN. A follow-on study called Project 57 was worked in 1963 and it was "in this study that the GPS concept was born." That same year the concept was pursued as Project 621B, which had "many of the attributes that you now see in GPS"[15] and promised increased accuracy for Air Force bombers as well as ICBMs. Updates from the Navy Transit system were too slow for the high speeds that the Air Force operated at. The Navy Research Laboratory continued advancements with their Timation (Time Navigation) satellites, first launched in 1967, and with the third one in 1974 carrying the first atomic clock put into orbit.[16]

With these parallel developments out of the 1960s, it was realized that a superior system could be developed by synthesizing the best technologies from 621B, Transit, Timation and SECOR in a multi-service program. Over the Labor Day weekend in 1973, a meeting of about 12 military officers at the Pentagon discussed the creation of a Defense Navigation Satellite System (DNSS). It was at this meeting that "the real synthesis that became GPS was created." Later that year, the DNSS program was named Navstar. With the individual satellites being associated with the name Navstar (as with the predecessors Transit and Timation), a more fully encompassing name was used to identify the constellation of Navstar satellites. This more complete name was Navstar-GPS, which was later shortened simply to GPS.[17]

After Korean Air Lines Flight 007, carrying 269 people, was shot down in 1983 after straying into the USSR's prohibited airspace,[18] in the vicinity of Sakhalin and Moneron Islands, President Ronald Reagan issued a directive making GPS freely available for civilian use, once it was sufficiently developed, as a common good.[19] The first satellite was launched in 1989, and the 24th satellite was launched in 1994.

Initially, the highest quality signal was reserved for military use, and the signal available for civilian use was intentionally degraded ("Selective Availability", SA). This changed with U.S. President Bill Clinton ordering Selective Availability turned off at midnight May 1, 2000, improving the precision of civilian GPS from 300 meters (about 1000 feet) to 20 meters (about 65 feet). The U.S. military by then had the ability to deny GPS service to potential adversaries on a regional basis.[20]

Basic Introduction about GPS:

The Global Positioning System (GPS) is a network of 24 Navstar satellites orbiting Earth at 11,000 miles. Originally established by the U.S. Department of Defence (DOD) at a cost of about US$13 billion, access to GPS is free to all users, including those in other countries. The system’s positioning and timing data are used for a variety of applications, including air, land and sea navigation, vehicle and vessel tracking, surveying and mapping, and asset and natural resource management. With military accuracy restrictions partially lifted in March 1996 and fully lifted in May 2000, GPS can now pinpoint the location of objects as small as a penny anywhere on the earth’s surface.

The first GPS satellite was launched in 1978. The first 10 satellites were development satellites, called Block I. From 1989 to 1993, 23 production satellites, called Block II were launched. The launch of the 24th satellite in 1994 completed the system. The DOD keeps 4 satellites in reserve to replace any destroyed or defective satellites. The satellites are positioned so that signals from six of them can be received nearly 100 percent of the time at any point on earth.

GPS provides specially coded satellite signals that can be processed in a GPS receiver, enabling the receiver to compute position, velocity and time. Basically GPS works by using four GPS satellite signals to compute positions in three dimensions (and the time offset) in the receiver clock. So by very accurately measuring our distance from these satellites a user can triangulate their position anywhere on earth.

GPS receivers have been miniaturised to just a few integrated circuits and so are becoming very economical. And that makes the technology accessible to virtually everyone. These days GPS is finding its way into cars, boats, planes, construction equipment, movie making gear, farm machinery, even laptop computers. This report shows the various features of GPS and the reasons why it may soon become almost as basic as the telephone.

Structure :

GPS consists of three parts: the space segment, the control segment, and the user segment. The U.S. Air Force develops, maintains, and operates the space and control segments. GPS satellites broadcast signals from space, which each GPS receiver uses to calculate its three-dimensional location (latitude, longitude, and altitude) plus the current time.[2]

The space segment is composed of 24 to 32 satellites in medium Earth orbit and also includes the boosters required to launch them into orbit. The control segment is composed of a master control station, an alternate master control station, and a host of dedicated and shared ground antennas and monitor stations. The user segment is composed of hundreds of thousands of U.S. and allied military users of the secure GPS Precise Positioning Service, and tens of millions of civil, commercial, and scientific users of the Standard Positioning Service (see GPS navigation devices).

Appcelerator, leading provider of mobile and desktop applications for web developers, partnered with International Data Corporation (IDC (News - Alert)), to conduct a joint Appcelerator-IDC survey, interviewing around 2,400 application developers worldwide. As per the survey results, developers are planning to build applications for mobile and tablet platforms using their preferred mobile API.


The Appcelerator-IDC Q4 Mobile Developer Report revealed that in the entertainment market, including Television and embedded devices, Titanium developers prefer Android (News - Alert) over iOS platform. Popular social, advertising, commerce, media, and other web-based APIs are competing against each other and the survey provides a fresh insight into who’s winning the war in the mobile application landscape.

The Appcelerator-IDC survey’s key findings helped uncover Android’s strategic advantage, showcasing that almost 72 percent of developers found Android to empower large number of next generation connected devices compared to 25 percent for Apple’s (News - Alert) iOS. In contrast, iOS currently dominates across all categories in terms of revenue/market opportunity and current devices. Almost 91 percent of the developers are more interested in developing for Apple phones compared to 82 percent for Android phones. The survey reveals that 44 percent of the developers are interested in developing for Google TV while 40 percent for Apple TV. Also around 62 percent of developers show strong interest in Android tablets compared to the low interest shown for webOS and BlackBerry tablets; thus encouraging the growth of Android based device OEMs. The only Google drawback seems to be Fragmentation with 74 percent of developers voting for the least fragmented Apple iOS.

Appcelerator Titanium mobile API powers over 4,000 applications while developers are extensively leveraging third party social, commerce, advertising, messaging, media, and analytic APIs. The survey throws light on whose gaining market and who’s going down. In the social sector, Facebook leads, compared to Twitter and Foursquare (News - Alert), due to the popularity of its primary identity system for mobile applications. iOS in-app purchasing and PayPal payments are going head-to-head to dominate mobile commerce sector with PayPal (News - Alert) gaining popularity in European and Asian market. Mobile cameras are scoring better compared to photo sharing services such as Flickr and TwitPic due to advanced applications such as barcode scanning and augmented reality. iAds richer ad units and high click-through rates places it at a higher position compared to Admobs while Application analytics is gaining market with strong interest in transaction and geo-analytics mobile applications.

adb Wireless & Some other applications are to enable/disable the wireless connection

ADB (Android Debug Bridge) interface only one click button. After enabling the

connection works as if we had the phone connected via USB.

Pre-Condition : Rooted Phone Only!!!

Download :

Download directly from your Android device by searching for

1.adbWireless
2.ADB over WIFI Widget

in the Market application Free of Cost.