I have been thinking through why, when comparing app stores, Android has by far the greatest proportion of freeware.

Apart from the fact that many commercial entities are taking a ‘let’s wait and see’ approach, there some aspects of the Android Market that are discouraging sellers. These include the lack of a desktop web site, a way for developers to see and respond to comments, larger descriptions and support for multiple versions of the same app (for different OS versions). As it happens, there’s a petition in progress to try to get some improvements.

However, the problems run deeper and more commercial. Here, I examine some of the problems and give some solutions.

There’s only a limited number of countries to which apps can be sold.

As of writing this, the countries only include Austria, France, Germany, Italy, Japan, Netherlands, New Zealand, Spain, Switzerland, United Kingdom and United States. The lack of countries has contributed to what has become a thriving pirated software sub-culture.

If you are seller, you can mitigate some of the losses to unsupported countries by either creating your own additional payment system using PayPal IPN or by using one of the 3rd party Apps Stores such as SlideME and AndAppStore.

Purchasing cross currency can result in excessive credit card fees

This confuses buyers who don’t know (or realise) how much they will be charged.

There’s lots of piracy

It’s typical for only about 20% of installs to be from the official Android Market. Piracy is nothing new - there’s piracy on all smartphone platforms.

Most developers (on all platforms) ignore piracy and guess that most people copying apps wouldn’t buy them anyway. However, as more and more applications are using data at the developer’s server, data use, bandwidth and resource usage at the server can become problematic. It turns out that use of the server is a great way to discourage piracy which I will explain later on.

The particular problem with Android is that there are several factors that are contributing rather than stemming the privacy…

Google’s copy protection for purchased apps is very poor

It’s possible to easily copy APKs so that they can be either be purchased and refunded under the 24 refund policy or, more damaging, offered via file sharing sites and services. Google might say that it’s up to the app provider to provide copy protection. However, this requires that the app developer tie a purchase with an app install that also has its idiosyncrasies…

Google Android Market Checkout Notification API doesn’t work

The XML http notification of a sale doesn’t seem to work.  Many developers give up at this stage.

However, there’s a 2nd API that allows you to view historical transactions which does work. It’s also easier to use as it doesn’t require you to implement SSL (cert) on your server. Furthermore, it doesn’t rely in you having to store payment notifications on your server. Heikki Toivonen has a php implementation and there’s also an Android open source implementation (although I strongly wouldn’t recommend embedding your username/password in sold apps to do the checking directly from the app itself).

Even when you tie the install to the purchase, this isn’t always foolproof

CoPilot and MyBackupPro ask the user for their Google order number yet these apps have also been pirated. The problem is that it’s possible to reverse engineer the code and modify it to circumvent the checks. Obfuscation of the code (recommended) can make it harder for hackers but, with Java, it’s still easier to change the code than with native environments such as Windows Mobile and Symbian. Note that it’s not possible for the hacker to re-package up the APK so it looks like it came from the original provider. Hence, end-users using such APKs are taking risks that other malicious things haven’t been added.

If you are just performing a check and storing the result then this will eventually be circumvented by a determined hacker. The only way to discourage, and in some cases prevent, piracy is to make some of your  app functionality at the server. If the information stored at the server is personalised (only really suitable for that user) and tied to the purchase id then they will dissuaded from sharing their purchase id.

You can also tie the purchase id to the user’s IMEI and only allow a few changes of IMEI (for when the user changes their phone) after which the purchase id is disabled for further activations. Server side, you can also implement more elaborate schemes such as sending the purchase id and IMEI in every server request and detecting fraudulent patterns, for example, more than 2 IMEIs being used over a short space of time.

While talking of pivacy and user authenication, Artful bits have an Anti piracy check. You can try it now by adding an IMEI after the =

http://www.artfulbits.com/android/antipiracycheck.ashx?IMEI=123456789123478

While mechanisms such as this seem ok, they break down (cause you tech support headaches) when, for example, the user decides to purchase the product after trying a pirate version, the user changes their phone or someone buys a second hand phone that has been blacklisted.

With all the problems with the Android Market, some people are suggesting different business models. AndroidGuys has an excellent list of 40 Android Business Models (also here and here).

One interesting model is to give the app away free and charge the user for something else via another payment system (eg. PayPal) over which you have easier control of the payment notification and support for all countries. However…

The Android Market Developer Distribution Agreement is open to interpretation

“All fees received by Developers for Products distributed via the Market must be processed by the Market’s Payment Processor.”

This means you can’t charge for the product other than via the Android Market. However, what constitutes the ‘product’? Is the server side part of the ‘product’ on Android. Is a free application that allows access to a paid service covered by this? This is a grey area. Remember the Milk uses this model.