in Android Security, Android Studio

Top 5 Mobile App Development Mistakes on Android Studio

Here’s the thing with mobile app development: you can pretty much choose to work in any editor and the results will be the same. After all, development is all about lines of code and libraries and tests getting executed in correct order. In the Unix/Linux tradition, this was exemplified by the creation of editors like Vi and Emacs (and even the likes of Ed!), which still command fanatical devotion. However, after a point, general-purpose editors begin to feel clumsy. A good example is a refactoring support, which is the simplest thing in something like IntelliJ IDEA, but impossible in Vi.

Once your development needs become more specialized and more demanding, you don’t want to spend time fiddling with small things and having to set up everything yourself (and maybe even waste time going around in circles, trying to figure out why that library is throwing error while priming the editor).

For Android, the culmination of text editors is Android Studio, based on the highly respected IntelliJ IDEA. Now, Android development is very much possible without Android Studio (IDEA and Eclipse have smoothly-working plugins, for example), but if you do decide to use Android Studio, life will be much simpler and you will make fewer mistakes.

So, Android Studio means fewer mistakes?

Well, yes and no. Yes, because Android Studio was designed to offer unparalleled Android experience – you won’t have to, for example, tear your hair looking for JARs and setting them up. But this productivity doesn’t come without a cost, and that cost is obedience. You have to give up your own “smart” ideas about project development and stick to what Android Studio recommends. Sure, you’ll feel horrible working against your cherished settings, but rest assured you’ll get used to it in no time and the world of wisdom will open up for you.

With that said, let’s look at the top five mistakes people make when coding in Android Studio. Some of these mistakes are even related to security vulnerabilities and should be avoided at all costs.

Top Five Android Studio Mistakes and Vulnerabilities

#1 Replacing Gradle

Now, there’s no shortage of build tools for Java in the market, both open source, and proprietary. In fact, we can make a strong case that there are far more Maven users than Gradle or anything else. And some might even swear by the “simplicity” of Ant. But hey, please realize that Gradle wasn’t chosen because it was fancy or because it was Groovy-based. Out of the box, Gradle is simpler, easier to deploy (Gradle wrapper, anyone?) and of course is easier to decipher. But even beyond all this, Gradle in Android Studio comes with facilities that you’ll desperately struggle with otherwise. How about different build orders for paid and free apps? Sure you can spend half a day and get it working with other tools, but Gradle on Android Studio will work right out the box.

#2 Storing passwords in build.gradle

Because the Gradle configuration files get added to version control, it’s a horrible idea to add passwords directly to it. The right way to go about it is to create a gradle.properties file and mention the password there:

KEYSTORE_PASSWORD=password123

KEY_PASSWORD=password789

And then, your build.gradle can look more sensible:

signingConfigs {

   release {

       try {

           storeFile file(“myapp.keystore”)

           storePassword KEYSTORE_PASSWORD

           keyAlias “thekey”

           keyPassword KEY_PASSWORD

       }

       catch (ex) {

           throw new InvalidUserDataException(“You should define KEYSTORE_PASSWORD and KEY_PASSWORD in gradle.properties.”)

       }

   }

}

There you not only protect the password but also make the whole build process saner.

#3 Not using Android Studio Snippets

Java is a verbose language, no doubt. Writing getter and setters for, say, fifty classes with ten members on average is nobody’s idea of a having a good time. But Snippets are there to save the day. And just in case you don’t like how Android Studio generates snippets (adding “m” before static properties, for example) you can always customize it.

Why all the fuss about snippets? Aren’t these mere pawns in the grand scheme of things? Perhaps, but never underestimate the ability of little things to derail your thinking. It’s best to have as little friction in the development process as possible.

#4 Not using existing libraries

Actually, everyone does use a few external libraries and this point was better titled “not looking for better-existing libraries”. Android is evolving at a frightening speed, and so are the various libraries. What’s impossible in one is possible in another, and what’s possible in one is a breeze in another. So don’t think that you always know the best. Currently, the most-loved libraries are Dagger, Retrofit, Picasso, and Mockito. Are you using them? If yes, chances are by now something better is available!

And always remember the 65k method limit by Dalvik. If for no other reason, keep searching for new libraries that are more compact and productive.

#5 Not keeping an eye on performance

Yes, premature optimization is the root of all evil, but there’s an equally sinister error: waiting so long to optimize that now you just can’t. The point is that a typical Android application can grow to several classes (some even have 1000+). By the time you’ve finished it and noticed the performance bottlenecks, the cost of making the required changes might be too high.

A simpler and much more efficient practice is to keep checking execution times for methods as you code. No, we’re not suggestion you put clever traps for functions and produce details analyses and charts of performance. In the development stage, a simple metric of total execution time is enough and you can go by your gut feel. For instance, if a method that reads a 200 KB files is taking five seconds, something is wrong.

The good news is that profiling is easy, and tools like Hugo make it as simple as adding an annotation.


To conclude, Android Studio is a fantastic tool that has the official backing of Google. Benefiting from its power, though, requires some discipline and initiative from the developer. 

May your code be faster and with fewer vulnerabilities!

Try Devknox