331

I'm just about ready to publish my first app to the Android market, and I'd like to know if any of you have any tips about any experiences you may have encountered in regard to publishing an app that goes beyond the obvious and already documented.

Any hidden caveats and/or ideas about what to do before publishing an app to the market? For instance, a buddy of mine recommended that I remove any and all comments in my code just in case someone gets to the source code, thus making it more difficult for the would-be "code jacker" to decipher the code. I thought that was a sensible suggestion.

What are all the things to do before posting their app to the Android market?

Cœur
  • 37,241
  • 25
  • 195
  • 267
dell116
  • 5,835
  • 9
  • 52
  • 70

12 Answers12

355

Hope it's not too late, here is some advice:

  • Launch your app at the end of the week (Thursday afternoon is usually a good time). Why so? Well, no companies would like to publish an app only 1.5 day before the week end -> too dangerous (in case there is a problem that needs a quick reaction time).

  • Use proguard on your app (usually, you just have to add this line: proguard.config=proguard.cfg in the default.properties file). This will optimize, shrink and obfuscate your code, very useful for preventing from code thieves. You don't have to delete any comments, they are automatically deleted at compile time.

  • Optimize your images (using Paint.NET, PNGCrush or OptiPNG).

  • Optimize your layouts for most of screen sizes. You can do this by simply changing the screen size while editing a layout in AndroidStudio or Eclipse.

  • Try/catch all exceptions on the UI and display a simple toast which indicate to the user that something wrong happened. In the meantime, retrieve the error with Crashlytics or something similar.

  • Don't use too much .jar libraries, prefer library projects (optimize the code size) and add them using gradle.

  • Prefer using vector images since it will reduce APK size and fit correctly on all devices.

  • Don't use the Android preferences windows -> that's not really beautiful, even if it's in the Android guidelines, prefer making your own settings page. But if you keep Android preferences: consider adding icons and colors.

  • Don't show the title of your app on the main screen (this.requestWindowFeature(Window.FEATURE_NO_TITLE);): good brands don't need to take so much space on a screen to be recognized (show some icon or title in the menu or somewhere that is not always visible), and consider using the fullscreen mode (this.getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN, WindowManager.LayoutParams.FLAG_FULLSCREEN);) when dealing with games and very immersive content.

  • Use Google Analytics, Fabric Answers or Flurry for future analytics -> try to get as much information as possible, but don't grab anything that violates the anonymous identity of the customer. Don't forget to retrieve exceptions (errors and stack traces) that happens on the user side.

  • Ask your friends to do monkey tests, learning from users usually brings many good things (such as priorities and new ideas).

  • Consider publishing your app before having finished all features (most important feature only), you don't already know what your users will want or need besides your main feature .

  • Add a section "More apps", or "More from developer" in your app, that's free ads.

  • Add a section "Send feedback" to give the user the possibility to ask for a new feature or report some bug.

  • Ask your users to translate your app by providing the strings.xml somewhere on the web like Crowdin.

  • Try your app on each Android version with the emulator -> many bugs or design issues will be detected this way. For this, you can use the provided emulator, or use Genymotion instead (Genymotion has a lot of very useful features).

  • Think about the name of the app -> what keywords would you use to search for your app? These keywords should be the name of your app (Google will help you get discovered this way).

  • Consider including keywords in the app description, but in a descriptive way (make understandable sentences using your keywords). Never add a keyword list as is in the description.

  • Be the first to rate your app with 5 stars, and ask your family and friends to do the same -> this will likely influence the future users ratings.

  • Consider using Google to translate your app either for the description, either for the strings.xml or both.

  • Consider displaying ads in your apps and use mediation to improve your revenues AdMob.

  • Instead of providing a paid version, consider doing in-app billing -> users are more likely to pay in-app rather than paying for a paid version.

  • Add a change log in the app -> users usually like to know what changed since the last version.

  • Add a "Thanks" section for the users that helped you -> this will engage users to your product.

  • Add a "If you like this app, please rate it" link (to your Google Play description) in your app -> you will get more 5 stars (usually a popup on startup, or after a feature action).

  • Consider explaining your product via a "Tips" or "Instructions" section in your app.

  • Save your keystore and credentials information somewhere safe. You won't be able to publish an update for your app if you lose your keystore.

  • Make your icon really simple and clear. The icon is the first and also mainly the last thing that will make the user download your app.

  • Unless it's not possible, prefer external installation (android:installLocation="preferExternal" in the AndroidManifest.xml).

  • Read AppAnnie tips and blog posts, it will give you hints on how to improve ASO and help your better understand your users.

Jason Aller
  • 3,541
  • 28
  • 38
  • 38
Mathieu de Brito
  • 2,536
  • 2
  • 26
  • 30
  • 2
    if you have problem with test on different emulators in eclipse,you can get genymotion emulator,thats so faster.also to optimize png images www.tinypng.com is good choice – Arash May 05 '14 at 07:18
  • 2
    Really useful but keep in mind that, In order to provide a proper UX experience, you better have valid reasons to go full screen. Like if you want user to focus on one single element and remove all other distractions on the way. – whizzkid Nov 13 '14 at 20:45
  • 1
    `applicationId` could not be reset once you publish your app. Many times it contains words ( like your user name ) which you do not want to reveal. Set it in `build.gradle` file of your project in Android Studio. – gsinha Feb 08 '15 at 20:49
  • 9
    I come to StackOverflow for answers to questions. My question was "What should I do before publishing an android app? " This is one very useful answer and I imagine there could be many others so closing the question as "Not constructive" seems not very constructive. – user872985 Aug 07 '15 at 14:41
  • 2
    Thanks for the tips.. I want to know one more thing, If some one open my app in play store I want to display my apps as suggestion like "More from developer" is there any way to do that – Geethu Jan 21 '16 at 12:09
47

Really, don't bother removing code comments. Your source code doesn't make it to the user's phone - only the compiled code gets there, and that doesn't contain any reference to your comments whatsoever.

Android users tend to appreciate apps being as small as possible, so double-check you're only including resources (images, etc.) that are still being used in your app. Use OptiPNG/ PNGCrush on any .png images you have in your app - that can reduce the image file sizes by about 10%, which can be a significant part of your overall app size.

Also, use an audio editor such as Audacity to reduce the size of any audio as much as possible. Going for mono OGG Vorbis files is often best, and sounds plenty good enough on a phone.

teedyay
  • 23,293
  • 19
  • 66
  • 73
  • 1
    If my memory serves me correctly, I thought I read somewhere that when the .apk is packaged, the code is not compiled. I have been under the assumption that the .apk contains all of the source files, much like you would see if you went to the project workspace folder for Eclipse.....and the Dalvik compiles the code on the fly when it is run on the phone?? I hope I'm dead wrong, because even when I was reading the article, I was saying to myself, "well that's not safe." I am also a member on xda-developers.com, and they seem to be posting deodexed apk files for apps all the time. – dell116 Feb 25 '11 at 16:30
  • 16
    No, the raw source doesn't get shipped. The .apk file is just a .zip file in disguise, so rename it and take a look. Anything in /assets and /res/raw gets shipped unaltered, as do the drawables in /res. The xml files in /res are mangled in some way (maybe someone else here knows if they're encrypted or just compressed?). Your source code gets compiled into classes.dex. If you open that in Notepad you'll find it contains many strings from your source code (method and variable names, etc.) but none of your comments. – teedyay Feb 25 '11 at 16:42
  • 7
    xml files are compiled to optimize their parsing and navigation. there are tools to decompile them. – bigstones Feb 25 '11 at 17:52
  • @bigstones What sort of compilation programs are we talking about here? – Robert Massaioli May 20 '12 at 12:55
  • @RobertMassaioli Just AAPT, it's done automatically at build time. – bigstones May 20 '12 at 13:44
36

Don't worry about comments. If you are concerned about malicious dissection of your app, though, DO run it through an obfuscator like ProGuard.

Other tips I would offer:

  • Have all your graphics and promotional materials ready to go ahead of time.
  • Time your release strategically for when you don't have a lot else going on in your life (like right before a weekend) so that you'll have time to respond FAST if the first handful of users start having problems. Low ratings early on can kill you, but fast e-mail response and fixes can totally redeem a customer's opinion of your app.
  • I'll agree with earlier comments on reducing image sizes as much as possible.
  • Get your code into source control if it's not already. You're sure to need to issue updates and fixes at some point, and source control can play a big role in that.
Blumer
  • 5,005
  • 2
  • 33
  • 47
  • 4
    +1 for releasing when you've got time to fix things quickly! – teedyay Feb 25 '11 at 16:43
  • Thank you for your reply. I'm sure others will be grateful as well. I'm using Eclipse Galileo to make my app, and another thread on SO says that Subversive for Eclipse is one of the easiest source control tools to get used to. On that note, the Eclipse website has a version of Subversive to download, but I only see a link for a Helios release. Do you or anyone else know if this plugin with work with Galileo? – dell116 Feb 25 '11 at 17:08
  • I don't know, actually. I do my version control not integrated with Eclipse because I haven't bothered to set it up. I use TortoiseSVN when I'm in Windows and the Subversion command line tools when I'm on my Linux box. – Blumer Feb 25 '11 at 17:11
  • Speaking of updates, is it as simple as re-packaging the app with the updated files and replacing the older .apk on the market with a new one that has a different version number? I remember trying to re-install my app on top of a pre-existing installation (without uninstalling the app to try and simulate an "update"), but it failed, which got me to thinking that this might happen when I issue an update. But, for sake of argument, the "update" .apk that I installed on top of my old installation did not have a different version number in the manifest. Thanks again for any advice! – dell116 Feb 25 '11 at 18:03
  • 1
    When you go to upload your new .apk to the Market, it will check to make sure that the version number has increased since last time. When installing an update on a device, I believe it does NOT check version numbers, but rather installs what you tell it to. I know that installing an updated .apk will fail, though, if the keys that the old and new version were signed with are not the same. You'll have to uninstall the old one first and then install the update. – Blumer Feb 25 '11 at 18:12
  • can you help me with the source control thing? – Hammad Nasir Feb 28 '17 at 02:10
34

Not sure if you've seen this before, but you should excercise your UI with the monkey - my app has only had one crash, but it wouldn't have had any of those if I'd tested it with Monkey first.

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
RivieraKid
  • 5,923
  • 4
  • 38
  • 47
18

Some points that I tend to forget:

  • double check your minSdkVersion in the manifest
  • test your app on an emulator with your minSdkVersion
  • let your friends test your app to see if it is self-explanatory

If you are going to provide updates in your app:

  • you might want to add some kind of 'Whats new in this version'-dialog
  • backup your old version!
  • don't forget to increase versionCode and versionName in your manifest
Maaalte
  • 6,011
  • 3
  • 29
  • 27
  • 7
    Good points, and along the same line of thought, if your app uses an SQLite database, make certain your table creation and upgrade procedures are all in proper working order. – Blumer Feb 25 '11 at 17:16
18

I'll add an obvious, but important one: save your signing key somewhere safe, and make a backup. If you're letting Eclipse manage this for you, pay attention to where it creates your keystore, and save a backup copy of it. And don't forget the passwords for the keystore or individual signing keys.

Why: you need to sign updates to your app with the same certificate you used to sign the original. If you lose that certificate (or lose access to it), you cannot update your app. You'll have to create a new listing in the Android market.

zlovelady
  • 4,037
  • 4
  • 32
  • 33
13

Don't forget to make debuggable=false in your Manifest. That's caught me out a couple of times.

I'm not totally sure but I think this would then include a lot of information making a code hackers life a bit easier.

I remember years ago I accidentally deleted the source to a java project, in horror I realised I had no backup! I used a utility called jad to decompile the jar file on the production server, it had all the variables intact and was almost perfect. I can't remember if the comments were there or not, but then I didn't put a lot of comments back in them days anyway :) This is because I was including symbols when compiling.

Kevin
  • 1,200
  • 1
  • 11
  • 19
  • 2
    android:debuggable default value is false according to Google http://developer.android.com/guide/topics/manifest/application-element.html . Search on text "android:debuggable". – The Original Android Oct 07 '15 at 06:47
11

In addition to the great suggestions above, think about using Flurry for mobile analytics. I didn't know about that when I first started releasing my apps, but now that I've updated them to include it, I love seeing what users are actually doing with the app. This can provide valuable feedback and guidance for things that might be hard for users to find or not interesting/useful to the user.

Rich
  • 36,270
  • 31
  • 115
  • 154
8

As far as I know comments are not included in the app in any form.

The only "gotcha" for a developer that I found during app submission was the various graphics you can provide to the market. Be prepared to take several screenshots and create several app icon sizes as well as promotional graphics.

On the bright side, be prepared to have your app show up instantly in the store -- there is no approval process to go through for Android Market apps.

Matthew
  • 44,826
  • 10
  • 98
  • 87
7

I would also make sure you had some sort of error reporting so you know how many users are encountering error's. You may want to keep a copy of your old version when updating your app incase you need to roll back. Its also nice to compile a checklist specific for your app that you can go over everytime.

Also to add to this you may want to use a trimmer to take pieces of code out that are unused to cut down on the overall file size(as phone space is pretty limited). You also may want to obfuscate your code for extra protection.

ninjasense
  • 13,756
  • 19
  • 75
  • 92
4

To get a clear idea..go through this .. http://bewithandroid.blogspot.in/2012/05/publishing-android-application-on.html

Saritha
  • 1
  • 1
3

Declare an android:process and android:sharedUserId attribute!

See sharedUserId: safe to change when app is already in market? for why.

Community
  • 1
  • 1
mattlaabs
  • 486
  • 3
  • 14