Recommended Android Market screenshot format

In the Android Developer Console you can upload the screenshots of your app (max 8 currently) in several sizes, like 320x480, 480x800, 480x854 and 1280x800.

But it turns out that sometimes (always?) if you upload in the higher resolutions (like 480x800), the images get cropped in a weird way in the market on your phone (at least the Nexus One). The images will look fine in the online Android market, but not on a physical device. Actually, when you look closely, the dev-console gives a thumbnail of the screenshots and there you can already see that the images are cropped strangely sometimes; like the left 20-50 pixels just cut off. And that's actually how they also appear in the market on devices!
After some experimenting, it turns out this does not happen when you upload in 320x480 format.
Thus the recommended resolution to upload screenshots seems to be 320x480! Doesn't matter if you use a device (like the Galaxy S2) or emulator to take the screenshots.

Note I didnt check if the browser market image quality decreased when going from 480x800 to 320x480. Though clicking on an image in the webmarket shows the 320x480 uploaded image quite fine.

Number of downloaded apps/installs of an android app

Online android market website gives more details on the number of downloads/installs of an app than the market on a device (phone)!
Check for example 3D Light Racer Basic. On my Nexus One it says it has > 250000 downloads. But on the website it says 500000 - 1000000 installs! See the red arrow.


Can be pretty useful for competitor analysis for example :)

My experience with Android Market Licensing and LVL

This post describes my lessons learned with the Android Market Licensing service and the accompanying License Verification Library (LVL). I used it the first time for a completely new application, never published on the market before.


Getting started
From the description and instructions page you can read:
"Android Market offers a licensing service that lets you enforce licensing policies for paid applications that you publish through Android Market. With Android Market Licensing, your applications can query Android Market at run time to obtain their licensing status for the current user, then allow or disallow further use as appropriate".
"The License Verification Library (LVL) handles all of the licensing-related communication with the Android Market client and the licensing service. With the LVL integrated, your application can determine its licensing status for the current user by simply calling a library checker method and implementing a callback that receives the status".


That page is quite elaborate and definitely a good starting point for integrating the LVL into your project. Note that your app needs to support SDK 1.5 or higher (API level 3 and onwards).

The LVL I did not set up as a Library Project in Eclipse because it messed up my Subversion. It got totally confused, indicating stuff wasn't checked in, but I also could not check anything in even after a cleanup. Or it kept indicating there were waiting changes to check in, even though I had it checked in. Maybe it's Eclipse Ganymede, maybe it's me :). So I just imported the source code in my project. Disadvantage is I'll have to update each project that uses the LVL when an update of the LVL arrives.

Furthermore I used the ServerManagedPolicy and changed the salt for the AESObfuscator (which is used to securely obfuscate data written to and read from storage).
Note that the AESObfuscator has been reported to be quite slow.

Setting up a test response for license checks works fine for brand spanking new apps like mine was. On my emulator I used my developer account, on the real device (a Nexus One) another gmail account as test-account.

Quite essential in the documentation is the line "Signing in using a publisher account offers the advantage of letting your applications receive static test responses even before the applications are uploaded to the publisher site".
It took me (and apparently others) quite a while to figure out that that means that the test accounts only get the Test response when you've uploaded the app to the market and saved it! Otherwise they will get ERROR_NOT_MARKET_MANAGED.


To obfuscate or not to obfuscate
I decided not to obfuscate my application. Main reasons being:

• It won't prevent hackers from decompiling your code for 100% sure.


• It gets a real pain in the @ss to figure out the real line of the code when you get an error report or exception.


• You should do a full regression test after obfuscation. Of course :) you have that all automated but still...

Note also that the post explaining ProGuard obfuscation requires a fix (it obfuscates too much). It might be updated now.
Here's a tip when you're using Proguard obfuscation to easily indicate which classes shouldn't be obfuscated (in short: by letting those implement a specificly named interface and put that as a keep-rule in the proguard config).

Great tip here to even more minimize the number of classes/interfaces you shouldn't obfuscate.

For another nice introduction and more in-depth details on why you could use Proguard for obfuscation, shrinking and optimization, see this post.


Server Response Extras
During testing on the emulator I found out that the Server Response Extras are never set for the test responses, so it's quite hard to test different behaviour here on different values. On the other hand, the default implementation seems to handle it quite ok. If you don't like it, you'll have to dive into the LVL code...


Testing new versions of an app
I also found out that if you increase the versionCode of your app, and try to test that app on a real phone with a test account, you'll get back ERROR_NOT_MARKET_MANAGED. Most likely this is because of the new versionCode, which the market licensing service does not recognize/accept. I have not seen the ability to just upload a new version of an app and only save it, it seems you can only publish it... And this thus means your test accounts can't test the app before release...

Looking at a reply in this post it seems you don't even want to save a newer version because the current version of your app disappears from the market! Another report of this here.

As mentioned in the first post, the only way to test a newer version seems to set the versionCode to the currently published version and use that during testing on a real device with test accounts. Sounds doable, there's not too much risk of forgetting to increase the versionCode when publishing: the market won't let you upload an app with the same versionCode as already published.

Note: Maybe the new "draft upload" feature fixes the above issues (see sixth item in this post), didn't try that out yet.

Some answers from Trevor Johns in the post clarify things re: responses a bit but not all:

"If an app is not published AND not draft, then you'll get
ERROR_NOT_MARKET_MANAGED."
Yes, but if your testing with your developer account on the emulator, you get back whatever is set in the test response. Even for an app with a newer versionCode.

"If an app is in draft (never published), then we send LICENSED for all requests for that app."
Is it? It seems it sends back to test accounts on a real device what's set in the Test response. Not tested yet for increased versionCode.
The reply on 6aug10 from Trevor Johns in this thread says it too. Unless I did something wrong, I noticed different behaviour.

"If an app is published (or has been published then unpublished), then
the response is driven by the dev console settings for the developer/testers, and purely by purchase history for everyone else."
Yes, but if you have increased the versionCode, test accounts on a real phone get back ERROR_NOT_MARKET_MANAGED.

See also other responses in this post.

I also wanted to test what happens when I publish a new version, would people with an older purchased version of the app still get verified successfully, and what does the provided LVL code do when it gets back LICENSED_OLD_KEY?
My conclusion: that combination seems only testable on the emulator for the developer account before publishing the app (note I didn't try the scenario on a real device with the developer account). After really publishing the app you can test it of course, but that's a bit late, you want to try it before publishing, before the world can download it.
For an app never published before, you can test the LICENSED_OLD_KEY as described here.


More securing your implementation
Of course I followed also most steps described in Securing Android LVL Applications. I did not add a CRC check. Tips on how to do that can also be found here and here.


Wishes
What would be great to have available in the developer console is to see how many verification requests failed, and with what error. This way you can get an indication on how many people try to illegally use your app, and get an indication whether something might be competely wrong with your app (e.g nobody gets correctly verified anymore).
You could then also see how many people haven't upgraded yet via distinct the OLD_LICENSE_KEY responses.
As long as this kind of statistics is not provided by the market, but you still want to know about these kind of failures, what you could do is report any error results to your own separate server (though of course a skilled hacker could prevent that from being sent).

Finally: don't forget to add any issues you find to the market licensing issues page.

Saving precious Android Market description text space

Pretty annoying that you only have 325 characters in the description field when submitting an app right? You really have to use the space wisely.

One of the things you usually want to put in what you have added/changed in the current release, so people who want to update know what to expect.
That takes up precious space of those 325 characters. But from now on you don't need to worry about that anymore because... it turns out you can put any text in the android:versionName attribute in the AndroidManifest.xml!

So what I usually do is put in versionName the digits from the android:versionCode attribute separated by dots, then a space and then a short description of what has changed since the last version. For example, suppose android:versionCode="103" then androidName becomes:

android:versionName="1.0.3 Preferences are now correctly stored"

So what does it look like? Well here's first a screenshot of an app that only puts in a version number in the android:versionName attribute:


And here's an example of an app that fully uses that attribute:


I do not know what the maximum lenght is of the versionName field, but apparently you can put quite some text in there, as can be seen from above screenshot.

Update: well, putting the version information in the versionName is not necessary anymore, since from now on there's a separate field to put the recent changes into. What now quickly comes to mind to put into the versionName could be the minimal SDK version number your app supports. That can be useful for people who want/need to get your app on non-Google markets. This way they get at least an indication whether the app can run on their phone or not.

Update: and recently (definitely since 23 Feb 2011) they have limited the length of the versionName field to 30 characters, because if you exceed that, at apk-upload time you'll see: "The versionName in AndroidManifest.xml exceeds maximum (30)."