Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Building, Testing And Distributing Android Apps

When iOS started to gain momentum, soon after the first iPhone launched, many businesses started to pay attention to apps. The number of apps for iOS grew exponentially, and every company, big and small, rushed to create their own app to support their business.

For some time, iOS was the only platform you really had to care about. The audience was there. For a few years now, there has been another player in the market. Android’s marketshare growth has been phenomenal, and it simply cannot be ignored anymore. There are over 200 million Android users in the world—almost double the numer of iOS users. For businesses, reaching the Android crowds is potentially a very lucrative investment.

Further Reading on SmashingMag: Link

Android as a platform can appear intimidating to new players. Blogs and media are littered with articles about Android fragmentation and malware. The Android platform can feel complex, although it is very flexible. However, before getting started with an Android project, understanding the platform and ecosystem is imperative. Trying to apply the methods and tools that work on other platforms could lead to disaster.

In this article, we’ll explain parts of the application-building process and ecosystem for Android that could cause problems if misunderstood. We’ll talk about an approach to building a scalable app that looks and feels right at home on Android, and we’ll cover how to test it and your options for distributing it. The following topics would each need a full article to be explained fully, but this article should provide a good overview. After reading this article, you should have a good understanding of what kinds of decisions and challenges you will face when creating an Android app.

Make The App Scalable Link

Android devices come in many forms and sizes. The last official count is that 600 Android devices are available, and that number is growing every day. Building an app that runs on all of them is more difficult than building for just one or two screen sizes and one set of hardware. Fortunately, Android was built from the ground up with this in mind. The framework provides tools to help developers tackle the problem. But as with all tools, they only work if used correctly.

Large preview5.

An iOS app is designed and built by placing pixels at the proper coordinates until the UI looks just right. Not so on Android! Android designers must think about the scalability of each component and the relationships between components. The philosophy is much closer to Web app design than to iOS app design.

A Continuum Instead Of A Separate Tablet UI Link

About half a year ago, Google rushed out the Android version named Honeycomb (3.0). Honeycomb was aimed at tablets and was never meant for anything else. The source code of Honeycomb was never released, and it never officially appeared on any phones. At the time, Apple had already established a practice by which developers provided two separate versions of their app, one for iPhone and one for iPad. Because of Apple’s model and the separate Android version for tablets, everyone seemed to assume that two separate versions of an app are needed on Android, too. Soon, the Internet was full of blog posts complaining that Android didn’t have enough tablet apps and that there was no way to search for them on the Google Play store.

Now, as Android Ice Cream Sandwich (4.0) is unifying all Android devices to run the same version of the OS, it all makes sense. Android is a continuum, and drawing a clear line between tablets and phones is impossible. In fact, checking whether an app is running on a tablet or phone is technically impossible. Checking the screen size (and many other features) at runtime, however, is possible.

This is where Android design starts to remind us of Web design. New technologies have enabled us to build websites that adapt automatically to the user’s browser size by scaling and moving components around as needed. This approach is called responsive Web design. The very same principles can be used on Android. On Android, however, we are not bound by the limits of the browser. Responsive design can be taken even further.

Responsive Android Design Link

Android developers can define multiple layouts for every screen of their app, and the OS will pick the best-fitting one at runtime. The OS knows which one fits best by using definitions that developers add to their layout (and other) folders in the app’s project resource tree.

An example of the structure of layout folders, which distinguish between screen sizes and Android versions.

Starting from Android version 3.2 — and, therefore, also on Ice Cream Sandwich — a more fine-grained approach was introduced. Developers may now define layouts based on the screen’s pixel density, independent of size, instead of using only the few categories that were available before.

An example of the new layout specifications based on screen size. It is very similar to CSS’ media queries. Android’s documentation8 has more details.

Using Fragments to Implement Responsive Design Link

Fragments are the building blocks of Android UIs. They can be programmed either to be standalone screens or to be displayed with other fragments; but the most powerful ones are both, depending on the device that the app is running on. This enables us not only to rearrange the fragments but to move them deeper into the activity stack. Dan McKenzie has written9 about issues related to designing for big Android screens.

Each component is itself stretchable and scales to screens with similar sizes.

When a screen’s size is drastically different, the components need to be rearranged. They can be rearranged on the same level or moved deeper into the activity stack.

Make The App Look And Feel Android-Like Link

Consistency with other apps on the same platform is more important for an app’s look and feel than consistency with the same developer’s apps on other platforms. Having the look and feel of apps from a different platform will make the app feel foreign and make users unhappy.

(Remember to read Google’s Android Design3612 guidelines.)

Tabs Link

In Android apps, tabs should always be on top. This convention was established and is driven by Google’s design of its apps and by guidelines from advocates of Android development. Putting the tabs on top makes scaling an app to larger screen sizes easier. Putting tabs at the bottom of a tablet-sized UI wouldn’t make sense.

Large preview15.

Navigating between top-positioned tabs on a phone with a large screen can be difficult, especially when the person is using only one hand. The solution is to enable the user to swipe between tabs. This interaction model is not new, but in its latest release, Google has made it commonplace in Android apps. All bundled apps now support this interaction on tabbed UIs, and users will expect it to work in your app’s tabbed screens, too.

Android UI Patterns Can Put Users at Ease Link

Some UI patterns have become popular on Android — so much so that they are starting to define the look of Android apps. The action bar, one of the most popular patterns, is now part of Android’s core libraries and can be used in any app running on Android 3.0 and up.

Good third-party libraries are available to bring the action bar to apps that run on older versions of Android. ActionBarSherlock4016 is very stable and supports multiple versions and even automatically uses the native action bar when it detects a supported version of Android.

Another popular UI pattern is the dashboard. Many apps with a lot of functionality use the dashboard as their landing screen to give users a clear overview of and easy access to the app’s most important functionality.

Large preview19.

Google Play (left) and Evernote (right) both put an action bar at the top of their screens to provide quick access to contextually relevant actions. Evernote’s landing screen clearly tells the user what they can do with the app, while providing easy access to those actions every time the app launches.

See Dan McKenzie’s article “Designing for Android20” for more on the look and feel of Android apps.

Integrate The App With Other Apps Link

The Android platform provides a powerful mechanism for apps to extend each other’s functionality. This mechanism is called “intents.” Apps can register to receive and launch intents. When an app registers to receive intents, it must tell the system what kind of intents it can handle. Your app could, for example, tell the system that it can show pictures or open Web page URLs. Now, whenever another app launches an intent to view an image or a Web page, the user has the option to choose your app to complete the action.

Large preview22.

Social Network Integration Link

On other mobile platforms, if an app wants to share something to Twitter, Facebook or another social network, it implements the sharing mechanisms internally in the app. Sharing requires a separate operation for each social network. On Android, this can be achieved more easily using intents. An app may launch an intent telling the system that it wants to share an image or text. Depending on which apps the user has installed, the user will be provided with a list of apps that can handle the operation. If the user chooses a Twitter or Facebook client, the client will open to its sharing screen with the text or image prefilled.

Large preview25.

There are many benefits to integrating with social networks using intents rather than implementing sharing directly from your app:

  1. Close to zero effort is required to build the functionality.
  2. Users don’t have to log into a separate application. The social network’s app takes care of logging in.
  3. You don’t have to limit the social networks that users may use to share from your app. All apps installed on the user’s device are available to be used.
  4. If a social network’s sharing protocol changes, you don’t have to worry about it. That service’s app will be updated to reflect the changes.
  5. Users might be using an unofficial app for a social network. Using intents, they may continue using their app of choice with the interface they are familiar with.
  6. The intents mechanism offers only options that the user actually uses (i.e. the apps that they have installed). No need to offer Facebook sharing to someone who doesn’t have a Facebook account.

Think of Other Opportunities Link

Extending the functionality of other apps via the intents system will benefit your app, too. Perhaps your app wouldn’t get used every day and would get buried under apps that are used more often. But if your app extends the functionality of other apps and keeps popping up as an option every time the user wants to perform an action that your app can handle, then it will be thought of more by users.

Intents have limitless possibilities. You can build your own intents hierarchy to extend certain functionality to other apps, in effect providing an API that is easy to use and maintain. You are essentially recommending to users other apps that complement yours and, in turn, extending your app’s features without having to write or maintain any code. The intents system is one of the most powerful features of the Android platform.

Quality Control Link

With the massive number of devices, testing an Android app is much more difficult than testing an iOS app. This is where the fragmentation causes the most problems. Testing on one or two devices is not enough; rather, you have to test on a variety of screen sizes, densities and Android versions.

In addition to what you would normally test on any other platform, you should the following:

  • Test your app thoroughly on the lowest Android version that it runs on. Accidentally using an API that isn’t actually available at runtime on some devices is easy.
  • Test that the search button works on all relevant screens.
  • Make sure that the D-pad and trackball navigation work on all screens.
  • Test all supported screen densities, or at least extra-high, high and medium. Low-density devices can be difficult to find.
  • Test on at least one tablet device. But try to test on as many screen sizes as possible.

Testing in the Cloud Link

New services are popping up to ease the pain of testing on multiple devices. Services such as Testdroid26 enable developers to test their apps on multiple real devices through a Web interface. Simply upload your app’s package and automated testing script, and the service executes your scripts on dozens of devices. Results can be viewed in a Web browser. Examining screenshots from different devices is even possible, to ensure pixel-perfect UIs.

Testdroid cloud screenshot27
Testdroid is a cloud service for testing Android apps on multiple devices. Large preview28.

Distribute The App Link

Once your app is tested and ready, you need to get it to users. You’ll have to choose how to do it. Very few Android devices are restricted to one app store. The overwhelming majority of Android devices ship with Google Play, which is the most important route to reaching users on the platform.

Google Play Link

The Google Play store doesn’t have a formal process for approving apps. Any application package uploaded to Play will appear in the store’s listings to users. App guidelines do exist, but they are enforced only if there are complaints, and even then pretty randomly. This means that your app will be swamped by hundreds of other apps of varying quality.

So, how to rise above the masses and get the attention of users?

The first 30 days are important! Your app will appear in the listing for new paid or free apps during that time. Ranking relatively high in this listing during this time is much easier than ranking high in the overall top lists. Make sure that your app’s website links to Google Play from the start, and use all social networks to tell people about your app’s launch.

Getting recognized as a trusted brand is difficult. Google Play contains many apps that use registered trademarks without permission. Users have come to learn that a logo is no indication that an app was actually produced by that logo’s company. To increase trust, make sure the “Visit Developer’s Website” link points to the official website, and if possible link back to your app from there.

Top new apps on Google Play. Large preview30.

Making an app work on all devices is sometimes impossible. Some devices lack the required hardware or simply run an old version of Android for which the required APIs don’t exist. You can list all of the requirements in the app’s manifest file, telling Google Play which devices the app is meant for and, thus, hiding it from listings that are being viewed on incompatible devices. But sometimes even that isn’t enough. In these cases, Google Play allows developers to prevent certain devices from downloading their app. While this option should be used only as a last resort, it is still better than allowing users to download something that you know does not work on their device.

Alternative App Stores Link

Google Play is not the only place to distribute your app. Amazon’s Appstore has lately gained attention due to the launch of Amazon’s Android-based Kindle Fire tablet. Amazon’s approach is fairly similar to Apple’s in that it has a formal review process. The Appstore is also accessible to non-Amazon devices, but currently only in the US.

Multiplatform app store GetJar31 also distributes Android apps. GetJar has a lot of users and is a well-known and trusted source, especially among people with not-so-smart phones.

Barnes & Noble’s app store is a US-only eBook-based app store. Unlike Amazon’s, it is accessible only to B&N’s Android hardware.

Multiple App Stores, Just One, or None? Link

Many people’s first instinct is to try to get their app into all stores. This decision should not be made lightly, though. Distributing through multiple stores might make the app reach more potential users. However, being spread across multiple app stores could prevent the app from ranking as high as it could in the listings for downloads and ratings. Having a thousand installations across three app stores might sound better than having two thousand installations in one store, but maybe those two thousand would push the app into a more visible spot in the store and help it rocket to tens of thousands of installations later.

An app doesn’t have to be in a store at all in order to be installed on devices. Android apps can be installed directly from websites or by transferring them from computer to phone. While you wouldn’t reach the same audience and wouldn’t benefit from the update mechanisms in app stores, there is definitely a place for direct distribution. Using forums and websites, developers can distribute their apps to alpha and beta communities without having to risk their reputation or low ratings in an app store. Distributing a major update or an unstable build to a limited number of dedicated testers and fans might be worth the extra effort.

Conclusion Link

Building a scalable and functional Android app is not impossible, but it requires careful planning and an understanding of the target platform. A blind approach or simply borrowing a design from another platform would likely end in failure. Achieving a successful end requires that you use Android’s tools correctly and follow the right design approach. Writing an Android app takes effort, but if done right, the app could reach a massive numbers of users.

Further Resources Link


  • OpenIntents: Registry of Intents Protocol

Supporting multiple screen sizes:

Android design:

Useful libraries:


Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42

↑ Back to top Tweet itShare on Facebook

Juhani is an Android developer with more than ten years of experience in Java development in different business domains. He has always been a keen supporter of good design. He writes a blog about Android UI Design Patterns at and tweets with focus on Android and Android design.

  1. 1


    June 1, 2012 4:40 am

    As usual, you are writing good articles with useful information with necessary image depiction.

    Thanx and Regards!

  2. 2

    A well written article for those who wanted to develop for Android. I totally agree about the design part: Stop copying stuff from iOS and develop an Android flavor app.

  3. 3

    Sonali Agrawal

    June 1, 2012 7:33 am

    Awesome article. Android apps should feel like android apps, no doubt. With the 4.0 version, things have changed so much, and I feel a lot can be done!

  4. 4

    An Article about Android by Juhani Lehtimaki from Android UI Design Patterns on Smashing Magazine?

    The world is a (bit) better place, today!

    Let it even better with more articles like this!!!! :


  5. 5

    Great article. Which frameworks would you reccomend for us working more with the design than Java. in fact, i do not know Java, I am pro in HTML, CSS, I know some JavaScript and PHP. What should I use?

    • 6

      Juhani Lehtimaki

      June 1, 2012 12:30 pm

      Hey Ivica, thanks!

      My recommendation is to take the time to learn Java if you want to create Android app. There are frameworks that do turn HTML code into Android apps but I haven’t seen a single app that is up to par with design standards of app’s written with Android SDK (or NDK). I actually wrote a post about this some time ago into my blog:

      If you don’t want to learn Java I recommend that you approach the platform from web app point of view. The Android browser is getting better all the time and people do use web apps on Android.

      • 7

        Thanks for your article and your write-up about phonegap/Titanium. I’m currently experimenting with Titanium and have loved it so far, but like you said, only for not having to dive into objective C for a simple app. When it comes to building great experiences for both ios and android, things do get tricky indeed.

  6. 8


    June 2, 2012 7:19 am

    While its true that 200 million users are on Android, only 7.1 percent of their devices have 4.0 ICS ( Most Android devices are sold with version 2.1, 2.2, or 2.3. Is designing for only 7.1 percent of those 200 million users a wise investment? I guess it depends in the adoption rates of ICS which so far hasn’t been going too well (

    My main problem with Android is that it’s not profitable ( You’d think it would be, with all the users, but most users of Android are upgrading from a feature phone just to have a “smart phone”, getting on prepaid plans and have no idea how to use its features. Even MikaMobile, a huge mobile game developer, quit Android because of all the work with no payoff:

    With Android, you’re not designing for 200 million consumers; you’re designing for bits and pieces of them. Either for some with certain devices or OS versions or both. It’s a headache that won’t end anytime soon.

    • 9

      Juhani Lehtimaki

      June 2, 2012 2:15 pm

      I’m afraid that you’re not very well informed on the matter of developing for Android.
      To your first point, Android versions isn’t a big problem to tackle in the development. In the current environment you should support all versions from Froyo (2.2) up. The update curve on Android is slower than on tightly controlled platforms but devices are pushed up to newer versions all the time. That is the nature of the development process. The current model is that Google opens up the new version to manufacturers the same time it goes open to developers. New features can easily be brought to apps without breaking backwards compatibility in most cases. This could be a good topic for another article.

      As for you claims for Android not being profitable I need to call BS. For the Mika mobile’s decision you should really read the update at the end of the post. If you’ve followed the platform development in the last year you’d seen almost all of the big name iOS developers jump to Android: Instagram, Readability, turntable, flipboard etc. Also, big time developers like EA and Rockstar are both releasing Android versions of their games on the same schedule they do on iOS. Do you think that they would be doing that if the platform would not be profitable?

      So to your point. Writing apps on Android you will target the overwhelming majority of the devices if you know what you are doing. Your claim is factually wrong.

  7. 11

    Android is a nice platform for distribution application.Thanks for sharing.

  8. 12

    android 5 would be coming soon

  9. 13

    Daniel McCormack

    June 2, 2012 1:00 pm

    I would like to know why the Android Platform will not use the Adobe flash program. Is it because it could develop a virus?

    • 14

      Juhani Lehtimaki

      June 2, 2012 2:18 pm

      Hey Daniel,
      You can build apps using Flash on Android. The problem is that Flash just isn’t a very good platform for mobile apps. A flash app will not feel right on Android. It will not follow the design guidelines. Another problem is also that Adobe discontinued Flash on mobile which means that it won’t get any updates anymore.

  10. 15

    Daniel McCormack

    June 2, 2012 1:12 pm

    I just wanted to know why Android or Apple do not allow any program like Adobe Flash

  11. 16

    Daniel McCormack

    June 2, 2012 1:17 pm

    I submitted a question about the reason for not using Adobe flash in the Android system and the Apple IPads. what is the answer to this question?

  12. 17

    Daniel McCormack

    June 2, 2012 1:35 pm

    I have wondered why we cannot load Adobe Flash program into our IPads or other Android products. I have it on my computer and it is a great program. Please help me to understand why it cannot be used on my IPad 2.?

    • 18

      Juhani Lehtimaki

      June 2, 2012 2:32 pm

      iOS does not support Flash. On Android you can install Adobe Flash from the Google Play Store.

  13. 19


    June 2, 2012 5:52 pm

    But the point about no profitability on Android has been made time and time again whether by the aformentioned Mika Mobile (“Android amounts to only 5% of mobile profits”) or by studies like this one:

    They’re about to release Jelly Bean Android 5.0 while only 7.1 % of devices have the 7 month old ICS. Also, while major app developers are releasing apps for android on the same schedule, most are released only for certain devices HANDPICKED for compatability (see flipboard, gta 3). Here’s what one developer has to go through:

    If you want to develop for Android, then do it. It may be a learning experience. You may enjoy it. But it may be alot of work with no payoff. That’s all I’m saying but to dismiss my comment with all the evidence coming out? That’s blind.

    • 20

      Juhani Lehtimaki

      June 3, 2012 5:18 am

      You have chosen to look for evidence supporting your opinion and ignore all of the other evidence. You also have misunderstood many of the articles you quote. I’m not dismissing the evidence, instead I’m looking it with more wide view. Do you know that both, flipboard is currently in beta testing for all devices? The S III launch was a marketing tool for Samsung which Samsung paid for. GTA is compatible with all modern phones. Surely it’s not a surprise that games don’t run on devices that don’t have enough power to run them. You say ” most are released only for certain devices HANDPICKED” which is simply not true.

      I’ve worked for a company building some of the most downloaded Android apps in Europe. The apps run on ALL Android devices and have millions of users. The QA process does take time but is nowhere near the quoted tech crunch article. You need to have 6-10 devices which you test with to ensure compatibility. That number is very close to the number of devices required on iOS for example (4-7).

      • 21


        June 3, 2012 5:52 am

        Touché. You seem to really know your stuff and thanks for the reply. I’m still not sold, but I’ll keep my eye on the platform. You made me think.

      • 22

        6-10 Android devices vs 4-7 iOS devices : I say “bullshit”.
        iOS : one screen size, 3GS as base, iPad 1 or 2 as tablet base.
        Android : 3″, 4.2″, 7″, 10″ screen sizes, big OS fragmentation, very different RAM amouts, processing power, graphic power, space available… do you really think you can have the same level of confidence with just 3 more Android devices ?
        The fact is : when you use 7 iOS devices, you’re testing what 95% of iOS users have. With 10 Android devices, you test a fraction of what users have and cross fingers hoping that everything will turn out ok. Which won’t be the case, cf Mikamobile’s blog.
        You can deny this, but that’s what small developers have to face. it’s easier to manage for bigger companies because the developers time isn’t sucked up by all the bad sides of Android.

        compare this to the web : iOS is Chrome plus Safari on a fixed monitor size, Android is Webkit plus Firefox plus IE9 plus Opera on different monitor size forcing to be “responsive”. Not really the same amount of work.

        • 23

          Various screen sizes and multiple use patterns are no fragmentation. It’s a feature!

        • 24


          You clearly know little about Android development. No development studio needs more than a handful of devices to ensure their app works on most others.

          “…different RAM amouts, processing power, graphic power, space available… do you really think you can have the same level of confidence with just 3 more Android devices ?”

          Yes, you can. Android is designed to be flexible. Please read up on it before voicing incorrect statements.

  14. 25

    Very well thought out article. At the end of the day, it is the developer’s responsibility to make the app look good. The tools are provided by all the platforms.

    Lazy developers are the ones that give Android a bad name sometimes.

  15. 26

    Hellow You can build iOs or Android app with flash as Adobe air mobile app. It’s just flash app but publish as Mobile air .

    It’s perform like native , and with native ext. You can build everythink.

  16. 27

    Joseph Jaramillo

    June 5, 2012 10:54 am

    Pretty good stuff. I recently wrote an overview of Android from the perspective of dying technology, and how it can take quite a while for users to move to new Android releases. Check it out:

  17. 28

    If android 4.0 is unifying tablet and mobile based on screen scalability then the tablet will look like mobile only which i think its not natural resulting to bad experience unlike with ipad they know that they need to seperate the UI of ios iphone compare to ios ipad. This seperates the experience between tablet to mobile. So what is the use of unifying if it fails to meet the goal in presenting apps in tablet form which for me is kinda awkward

    • 29

      Juhani Lehtimaki

      June 7, 2012 1:26 am

      ICS did unify the underlying operating system version on tablets and phones. The all now run exactly same Android 4.0 (the new ones do). While the OS is the same it doesn’t mean that the apps look the same or that the user interface is the same. On Android, the apps mus adapt to screen sizes. Look for example the Tasks app (there are thousands more but it is a very good example) in this post I posted some time ago
      The app UI utilises the phone screen perfectly but when it has a larger screen available it expands its UI to utilise that screen. That is the principle Android app design. It is the same app (ie. no separate app for tablets and phones) but the app UI is responsive. The design approach on Android is different from iOS but the results are the same. Android apps just have a capability to adapt their UI to more than just two screen sizes.

  18. 30

    Wow. This is very informational. Good to know! Most of my apps don’t register well with my Android device. Hopefully I can apply most of these info to my device so my kid can better enjoy this educational kid app called Maddie and Matt’s Happy Earth which sends a very good “Go Green” message to kids. Thanks for this! It’s a nice Android app. Here:

  19. 31

    Android has definitely changed the software development practices of organization and companies. Where initially the functionality of the app was considered a major keynote for its success, iOS and Android has introduced the non-functional elements in the applications as well.
    Now it’s about the look, user-friendliness and visuals of the app as well along with the functionality of the application. Ignoring these parameters is just unavoidable for a software development organization to build itself as a brand.


↑ Back to top