Designing For Android


For designers, Android is the elephant in the room when it comes to app design. As much as designers would like to think it’s an iOS1 world in which all anyones cares about are iPhones, iPads and the App Store, nobody can ignore that Android currently has the majority of smartphone market share2 and that it is being used on everything from tablets to e-readers3. In short, the Google Android platform is quickly becoming ubiquitous, and brands are starting to notice.

But let’s face it. Android’s multiple devices and form factors make it feel like designing for it is an uphill battle. And its cryptic documentation4 is hardly a starting point for designing and producing great apps. Surf the Web for resources on Android design and you’ll find little there to guide you.

If all this feels discouraging (and if it’s the reason you’re not designing apps for Android), you’re not alone. Fortunately, Android is beginning to address the issues with multiple devices and screen sizes, and device makers are slowly arriving at standards that will eventually reduce complexity.

This article will help designers become familiar with what they need to know to get started with Android and to deliver the right assets to the development team. The topics we’ll cover are:

  • Demystifying Android screen densities,
  • Learning the fundamentals of Android design via design patterns,
  • Design assets your developer needs,
  • How to get screenshots,
  • What Android 3 is about, and what’s on the horizon.

Android Smartphones And Display Sizes

When starting any digital design project, understanding the hardware first is a good idea. For iOS apps, that would be the iPhone and iPod Touch. Android, meanwhile, spans dozens of devices and makers. Where to begin?

The old baseline for screens supported for Android smartphone devices was the T-Mobile G1, the first commercially available Android-powered device which has an HVGA screen measuring 320 x 480 pixels.

HVGA5 stands for “half-size video graphics array” (or half-size VGA) and is the standard display size for today’s smartphones. The iPhone 3GS, 3G and 2G use the same configuration.

T-Mobile G1, the first commercially available Android device and the baseline for Android screen specifications.

To keep things simple, Android breaks down physical screen sizes (measured as the screen’s diagonal length from the top-left corner to bottom-right corner) into four general sizes: small, normal, large and xlarge.

Two common Android screen sizes. (Image from Google I/O 2010)

320 × 480 is considered a “normal” screen size by Android. As for “xlarge,” think tablets. However, the most popular Android smartphones8 today have WVGA (i.e. wide VGA) 800+ × 480-pixel HD displays. So, what’s “normal” is quickly changing. For now, we’ll say that most Android smartphones have large screens.

Diagram of various screen configurations available from emulator skins in the Android SDK. (Image: Android Developers website)

The variety of display sizes can be challenging for designers who are trying to create one-size-fits-all layouts. I’ve found the best approach is to design one set of layouts for 320 x 533 physical pixels and then introduce custom layouts for the other screen sizes.

While this creates more work for both the designer and developer, the larger physical screen size on bigger devices such as the Motorola Droid and HTC Evo might require changes to the baseline layouts that make better use of the extra real estate.

What You Need to Know About Screen Densities

Screen sizes are only half the picture! Developers don’t refer to a screen’s resolution, but rather its density. Here’s how Android defines the terms in its Developers Guide10:

  • Resolution
    The total number of physical pixels on a screen.
  • Screen density
    The quantity of pixels within a physical area of the screen, usually referred to as DPI (dots per inch).
  • Density-independent pixel (DP)
    This is a virtual pixel unit that you would use when defining a layout’s UI in order to express the layout’s dimensions or position in a density-independent way. The density-independent pixel is equivalent to one physical pixel on a 160 DPI screen, which is the baseline density assumed by the system of a “medium”-density screen. At runtime, the system transparently handles any scaling of the DP units as necessary, based on the actual density of the screen in use. The conversion of DP units to screen pixels is simple: pixels = DP * (DPI / 160). For example, on a 240 DPI screen, 1 DP equals 1.5 physical pixels. Always use DP units when defining your application’s UI to ensure that the UI displays properly on screens with different densities.

It’s a bit confusing, but this is what you need to know: Like screen sizes, Android divides screen densities into four basic densities: ldpi (low), mdpi (medium), hdpi (high), and xhdpi (extra high). This is important because you’ll need to deliver all graphical assets (bitmaps) in sets of different densities. At the very least, you’ll need to deliver mdpi and hdpi sets for any smartphone apps.

What this means is all bitmap graphics need to be scaled up or down from your baseline (320 x 533) screen layouts (note: there is also a way for parsing SVG files11 that provides a way to scale vector art on different screens sizes and densities without loss of image quality).

The bitmap requirement is similar to preparing graphics for print vs. the Web. If you have any experience with print production, you’ll know that a 72 PPI image will look very pixelated and blurry when scaled up and printed. Instead, you would need to redo the image as a vector image or use a high-resolution photo and then set the file’s resolution at around 300 PPI in order to print it without any loss of image quality. Screen density for Android works similar, except that we’re not changing the file’s resolution, only the image’s size (i.e. standard 72 PPI is fine).

Let’s say you took a bitmap icon measuring 100 × 100 pixels from one of the screens of your baseline designs (remember the “baseline” is a layout set at 320 × 480). Placing this same 100 × 100 icon on a device with an lDPI screen would make the icon appear big and blurry. Likewise, placing it on a device with an hDPI screen would make it appear too small (due to the device having more dots per inch than the mDPI screen).

An application without density support. (Image: Android Developers website)

To adjust for the different device screen densities, we need to follow a 3:4:6:8 scaling ratio between the four density sizes. (For the iPhone, it’s easy: it’s just a 2:1 ratio between the iPhone 4 and 3GS.) Using our ratios and some simple math, we can create four different versions of our bitmap to hand off to our developer for production:

  • 75 × 75 for low-density screens (i.e. ×0.75);
  • 100 × 100 for medium-density screens (our baseline);
  • 150 × 150 for high-density screens (×1.5);
  • 200 × 200 for extra high-density screens (×2.0). (We’re concerned with only lDPI, mDPI and hDPI for Android smartphone apps.)

The final graphic assets would appear like this using the four different screen densities.

After you’ve produced all of your graphics, you could organize your graphics library as follows:

The suggested organization and labeling of asset folders and files. In preparing our star graphic, all file prefixes could be preceded by the name ic_star, without changing the names of the respective densities.

You might be confused about what PPI (pixels per inch) to set your deliverables at. Just leave them at the standard 72 PPI, and scale the images accordingly.

Using Android Design Patterns

Clients often ask whether they can use their iPhone app design for Android. If you’re looking for shortcuts, building an app for mobile Web browsers using something like Webkit15 and HTML5 is perhaps a better choice. But to produce a native Android app, the answer is no. Why? Because Android’s UI conventions are different from iPhone’s.

The big difference is the “Back” key, for navigating to previous pages. The Back key on Android devices is fixed and always available to the user, regardless of the app. It’s either a physical part of the device or digitally fixed to the bottom of the screen, independent of any app, as in the recently released Android 3.0 for tablets (more on this later).

The hard “Back” key on a smartphone running Android 2.0.

The presence of a Back key outside of the app itself leaves space for other elements at the top of the screen, such as a logo, title or menu. While this navigational convention differs greatly from that of iOS, there are still other differentiators that Android calls “design patterns.” According to Android, a design pattern is a “general solution to a recurring problem.” Below are the main Android design patterns that were introduced with version 2.0.


This pattern solves the problem of having to navigate to several layers within an app. It provides a launch pad solution for rich apps such as Facebook, LinkedIn and Evernote.

The dashboard design pattern, as used by Facebook and LinkedIn.

Action Bar

The action bar is one of Android’s most important design patterns and differentiators. It works very similar to a conventional website’s banner, with the logo or title typically on the left and the navigation items on the right. The action bar’s design is flexible and allows for hovering menus and expanding search boxes. It’s generally used as a global feature rather than a contextual one.

The action bar design pattern as used by Twitter.

Search Bar

This gives the user a simple way to search by category, and it provides search suggestions.

The search bar design pattern as used in the Google Search app.

Quick Actions

This design pattern is similar to iOS’ pop-up behavior that gives the user additional contextual actions. For example, tapping a photo in an app might trigger a quick action bar that allows the user to share the photo.

The quick action design pattern as used by Twitter.

Companion Widget

Widgets21 allow an app to display notifications on the user’s launch screen. Unlike push notifications in iOS, which behave as temporary modal dialogs, companion widgets remain on the launch screen. (Tip: to select a widget for your Android device, simply tap and hold any empty space on one of the launch screens.)

Companion widgets by Engadget, New York Times and Pandora.

Using established design patterns is important for keeping the experience intuitive and familiar for your users. Users don’t want an iPhone experience on their Android device any more than a Mac user wants a Microsoft experience in their Mac OS environment. Understanding design patterns is the first step to learning to speak Android and designing an optimal experience for its users. Your developers will also thank you!

Android Design Deliverables

OK, so you’ve designed your Android app and are ready to make it a reality. What do you need to hand off to the developer? Here’s a quick list of deliverables:

  1. Annotated wireframes of the user experience based on the baseline large screen size of 320 x 533 physical pixels. Include any additional screens for instances where a larger or smaller (320 x 480) screen size requires a modified layout or a landscape version is required.
  2. Visual design mockups of key screens for WVGA large size (320 x 533) screens (based on a WVGA 800 x 480 hdpi physical pixel screen size) in addition to any custom layouts needed for other screen sizes.
  3. Specifications for spacing, font23 sizes and colors, and an indication of any bitmaps.
  4. A graphics library with lDPI, mDPI and hDPI versions of all bitmaps saved as transparent PNG files.
  5. Density-specific app icons, including the app’s launch icon, as transparent PNG files. Android already provides excellent tips for designers24 on this topic, along with some downloads, including graphic PSD templates and other goodies25.

How To Take Screenshots

Your product manager has just asked for screenshots of the developer’s build. The developer is busy and can’t get them to you until tomorrow. What do you do?! As of this writing, Android has no built-in way to take screenshots (bummer, I know). The only way is to just deal with it, and that means pretending to be a developer for a while and downloading some really scary software. Let’s get started!

The following software must be downloaded:

  1. All USB drivers for your Android device,
  2. Android software development kit26 (SDK),
  3. Java SE SDK27

Then, on your computer:

  1. Extract the USB drivers to a folder on your desktop,
  2. Extract the Android SDK to a folder on your desktop,
  3. Install the Java SE SDK.

On your Android device:

  1. Open “Settings” (you’ll find it in the apps menu),
  2. Tap on “Applications,”
  3. Tap on “Development,”
  4. Check the box for “USB debugging.”


Now, for the fun part:

  1. Connect your Android device to your computer via USB. Windows users: allow Windows to install all drivers. One of the drivers may not be found and will require you to go to the Window’s Device Manager under the Control Panel. There, you can locate the device (having a yellow warning icon next to it) and right-click on it.
  2. Choose to “update/install” the driver for your device.
  3. Go to your desktop. Open the Android SDK folder and select SDK Setup.exe.
  4. Allow it to automatically refresh its list of the operating system SDKs that are available, and select to install all packages.
  5. Once finished, exit the application.
  6. Go back to the opened Android SDK folder on your desktop, and open the “Tools” folder.
  7. Click on the file ddms to open the Dalvik Debug Monitor.
  8. Select your device from the “Name” pane.
  9. In the application’s top menu, open the “Device” menu, and choose “Screen capture…” A Device Screen Capture window will open, and you should see the launch screen of your Android device.

The Dalvik Debut Monitor.

To navigate:

  1. Grab your Android device and navigate to any page. Go back to your computer and select “Refresh” in the Device Screen Capture window. The current screen from your Android device should appear.
  2. If you’re on a Mac, you can just do the old Shift + Command + 4 trick to take a screenshot. In Windows, you can copy and paste it into one of the Windows media applications.

About Android Tablets

At CES 2011, companies rained down Android tablets30, with an array of screen sizes. However, after a quick review of the most popular ones31, we can conclude that the two important screen sizes to focus on in terms of physical pixels are 1280 × 800 and 800 × 480.

With the Android 3.0 Honeycomb release, Google provided device makers with an Android UI made for tablets. Gone is the hard “Back” button, replaced by an anchored software-generated navigation and system status bar at the bottom of the screen.

The anchored navigation and system bar in Android 3.0.

Android 3.0 got a visual refresh, while incorporating all of the design patterns introduced in Android 2.0. One of the major differences with 3.0 is the Action Bar which has been updated to include tabs, drop-down menus or breadcrumbs. The action bar can also change its appearance to show contextual actions when the user selects single or multiple elements on a screen.

The new action bar with tabs, introduced in Android 3.0.

Another new feature added to the Android framework with 3.0 is a mechanism called “fragments34.” A fragment is a self-contained component in a layout that can change size and position depending on the screen’s orientation and size. This further addresses the problem of designing for multiple form factors by giving designers and developers a way to make their screen layout components elastic and stackable, depending on the screen limitations of the app. Screen components can be stretched, stacked, expanded and collapsed, and revealed and hidden.

Diagram showing examples of how fragments can be used.

The next Android release, scrumptiously dubbed Ice Cream Sandwich36, promises to bring this functionality to Android smartphones as well, giving designers and developers the option to build an app using a one-size-fits-all strategy. This could be a paradigm shift for designers and developers, who will need to learn to think of app design in terms of puzzle pieces that can be stretched, stacked, expanded or hidden to fit the form factor. In short, this will allow one Android OS to run anywhere (with infinite possibilities!).

A Word of Advice

Do get your hands on an Android phone and tablet, and spend some time downloading apps and exploring their interfaces. In order to design for Android, you have to immerse yourself in the environment and know it intimately. This might sound obvious, but it’s always surprising to hear when even the product manager doesn’t have an Android device.


Online Resources

Here are some links to online resources I’ve found especially useful:





Product Reviews

Android Developers


(al) (il) (kw)


  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
  43. 43
  44. 44
  45. 45
  46. 46
  47. 47
  48. 48
  49. 49
  50. 50
  51. 51

↑ Back to topShare on Twitter

Born and raised in Silicon Valley, Daniel McKenzie is a digital product designer helping startups and companies strategize and design products that matter. He also likes to write and tweet (@danielmckenzie) on various design and innovation topics.


Note: Our rating-system has caused errors, so it's disabled at the moment. It will be back the moment the problem has been resolved. We're very sorry. Happy Holidays!

  1. 1

    Not everyone is willing to void their warranty to just take a screenshot.

  2. 2

    jenni has her head in the clouds

    June 30, 2011 7:52 am

    The hardest thing I’ve been having problems with is finding current Android GUIs. Most of the ones out there are 1-2 years old. Anyone have any leads?

  3. 3

    Your method is not the only way to take a screenshot.

    You can easily root your device and download one of many apps from the Market that capture screenshots.

    Much simpler.

  4. 4

    Great article. One pointer: the `ddms` program will run fine on OS X with Java installed–there’s no need to have a Windows virtual machine.

  5. 5

    “nobody can ignore that Android currently has the majority of smartphone market share and that it is being used on everything from tablets to e-readers.”

    Not really. You have to check the network traffic to have a good overview about the OS Market share. And iOS devices are still ahead today.

    Android is used on a LOT of low end devices that can not even support applications, especially in emerging country.

    Google is not showing any numbers about smartphone / tablet usage and speaks only about activations because they know this.

    Well we know about tablet usage: it’s ridiculous.

  6. 6

    But Great article anyway !

  7. 7

    Samsung Android models have internal, much easier, screenshotting facilities:

    No need to install SDK.

  8. 8

    Good point. The only reason I specified Windows is because most Android devices only have drivers for Windows :(

  9. 9

    Wow, wrong on so many fundamental levels.

    1. There never was an Android device incapable of running apps, same as iOS.
    2. Why would network traffic be an indicator of market share? Market share is the only indicator for market share. And network traffic is no indicator of how well your app would sell either.
    3. You will never get real numbers from anyone about usage. With the Android Market, we as developers/designers at least see how well competing applications sell, which you can’t on iOS.

    You’re right on tablet usage, it is miniscule at the moment. It might be a market to get into; then again, it might be a dead end.

  10. 10

    Dan, I develop solely on a mac with a host of 10+ Android devices for testing. You don’t need drivers on the Mac (or Linux for that part), it uses the built-in standard serial port driver. It should work with every device.
    With Windows, you need drivers.

  11. 11

    Valid point. I’d wish Google would add screenshot capability to the platform. On another note, a lot of newer devices can create screenshots (LG, Samsung) by pressing Volume Down + Menu at the same time, so no need to root them.

    Oh and btw: great article, thanks.

  12. 12

    Great. Thanks for the tip!

  13. 13

    Rooting your device doesn’t make you void your warranty: you can unroot your device with one click-tap. Unlock the bootloader is another story.

  14. 14

    Great article! If you are new to Android i ld recommend to use ACRA or to uncaught exceptions

  15. 15

    We’re in the same boat jenni. I always end having to recreate my own components.

  16. 16

    Feel free to share them and maybe the next person won’t be in the same boat :)

  17. 17

    To take a screenshot fom an Android device, just press the home button and the devices on/off button simultaneously, and the screen will be saved to your gallery. Then for example mail that to yourself.

  18. 18

    Great.. now if someone could just figure out how to actually make money… wishing Android owners were as willing to spend money as iOS ones. I don’t know that it’s ever going to improve.

  19. 19

    Unfortunately, I have yet to find a screenshot app that doesnt involve either shaking the device or pulling down the notifcation tray. 10 points to anyone that either makes one or finds one.

  20. 20

    I would love to spend money on apps, but nothing I actually want is available on Android :( It always says “Android version coming soon”. I don’t look for things very often as a result, only when I have a specific need. Just my experience.

  21. 21

    If only people in developing countries can pay for the application. Right now Android phones there are marketed as only having free applications, which is kinda true, since only those are what they can access.

    The unfortunate long tail effect of this is that this will start the bootleg mentality early on that even if people there can already buy Android applications there and the market has finally boomed, it will be too late.

    I know that there are people pirating in iOS as well, but even in those developing countries with jailbreak and all, there are a lot of them paying for applications, because they can. Which is unfortunately, not the same thing you can say about Android.

  22. 22

    Yes, Android developing in Mac/Linux its even easier than on Windows. The irony :-P

  23. 23

    Douglas Bonneville

    July 1, 2011 7:45 am

    My head has slightly exploded. So what if I want to target JUST the standard 320 x 480 crowd? Can I do that?

    I have an app (Font Combinations) written in Titanium that just went live at the App Store. The main feature of the app is graphic-driven, which required 90 graphics, x2 for Retina Display, plus the custom UI icons and a few other assets. Does that mean I’d have to make literally hundreds of graphics and test all these layouts? Yikes.

    If I could target just 2.2 devices running 320 x 480, I’d try a port. Maybe.

  24. 24

    Nobody is as willing to spend money as iOS users since they spent extra money on an iPhone just so they can be iPhone users and buy apps.

  25. 25

    Yes, it’s confusing…let me try to help. 320 x 480 physical pixels for screen size is your baseline, so that’s correct. And yes, you’ll need to make versions of all your graphics for at least mdpi (which you should already have from your baseline) and hdpi screen depths. In other words, take the set of graphics you already have and scale them x1.5 for hdpi screens. Regarding layouts, you should examine each screen type and decide whether or not it will scale well to the different screen sizes. Hope that helps!

  26. 26

    Douglas Bonneville

    July 2, 2011 11:10 am

    Not sure I get it yet. What do you mean by “examine each screen”? The screens of all the Android devices in the wild? Or just the ones I want to target? What if I want to JUST target 320 x 480 screens and forget the rest? Why couldn’t I just do that?

  27. 27

    This article really excite me to design the Android app UI. Very easy to understand and read. You made it sound so easy. :)

    Great post.

  28. 28

    I’d be willing to bet pirating in android is about as low as in iOS.

    People are used to free apps, that’s why more than often there’s a free app as well as a premium featured app, which is a great model.

  29. 29

    There is a simple way to take a screenshot. On my Galaxy S, i just hold the “back”-Key and press “Home”. Android will take a screenshot and put it to the Galery (works in 2.2 and 2.3). The HTC Desire have a similar keystroke combo, something with “Volume Up” button (not tested yet, a fiend told me that).

  30. 30

    My advice is to check your manufacturer’s documentation.

    Samsung Galaxy Tab, for instance, allow a simple screenshot by holding back + power button, similar gesture as in home + power button on iOS.

  31. 31

    You don’t target pixels, you target DPI.

  32. 32

    Ridiculous. Don’t develop for the Android platform. Please. There are enough shoddy iPhone ports already.

  33. 33

    Luciano Evaristo Guerche

    July 5, 2011 6:26 am

    I especially liked the section “How To Take Screenshots”, but I am wondering what the content of “How To Record Screencasts” would be, in case it was later added to this or another post…

  34. 34

    Yes you can target specific screen sizes, and/or different versions of android and/or different capabilities of the device.

    Look here for all the filtering you can do to make your app available only by the devices you do support:

  35. 35

    Wouldn’t a simple way to export out multiple images for the screens would be to size down the image in photoshop? So starting with a 200x200x72dpi image you would export for extra high density, reduce image by 25% and export for high density, reduce by 33.33333% and export for medium density, and finally reduce again by 25% for low density.

  36. 36

    Andriod Resource

  37. 37

    Take the Sony Ericsson Xperia Mini into account, with only 240 x 320 pixels screen resolution.

  38. 38

    Viviane Delvequio

    July 14, 2011 1:01 pm

    About taking screenshots: There is a development tool that can make it easier, the MOTODEV Studio for Android ( It is free, it is for any android device and runs on MAC OS X, Windows and Linux.

    The steps:
    1 – Download and install the Studio
    2 – Plug your device by USB
    3 – Check if the device appears on the Device Managment tab (selected tab on this image:
    4 – If the device doesn’t appear, change it USB mode, wait some seconds and check. Do it until you find the correct USB mode for your device.
    5 – Once you find the device on the Device Managment tab, right click it and select the Take Screenshot option (5th option on this image: )

    Save the image and it is done. : )

  39. 39

    Entering in the android world now, thank you for all the nice tips… Just wondering where is the facebook like button

  40. 40

    Im confused.

    Surely you would design for HDPI then reduce, designing for MDPI then enlarging to HDPI or XHDPI would blur the image if it was created in Photoshop?

    Or is the general rule of thumb to create in a vector graphics app.

    I work for a digital design agency very used to the simple normal and @2x graphics for iPhone but need to create a document for a client so they can provide us with Android graphics.

    It all seems very convoluted!

  41. 41

    Great article.

    I would just like to add that you can now use fragments on phones already using the“Android Compatibility package”:

  42. 42

    Many thanks Bull for the link for the filtering i am learning as a developer ,
    “Yes you can target specific screen sizes, and/or different versions of android and/or different capabilities of the device.

    Look here for all the filtering you can do to make your app available only by the devices you do support:

  43. 43

    “Ridiculous. Don’t develop for the Android platform. Please. There are enough shoddy iPhone ports already.”

    Dont know what Tom is talking about above?Not very detailed.

  44. 44

    tremendous work man! what a precise work

  45. 45

    More examples of android design patterns and UX can be seen here

  46. 46

    Great article, thanks.

    I follow it mostly, but am a little confused by why you set your baseline layout at 320 x 533 physical pixels? That doesn’t seem to match any screen size…

    And, as mentioned in a few previous comments, I also would have thought the simplest way would be to start with your largest required image size then reduce, rather than scale up (I also work predominantly in Photoshop using mostly photos for my app – very few graphics)


  47. 47

    Hi! Great article. It is January 11, 2012 and there is no longer any need to root your Android Phone anymore just to make a few screenshots. Go to the Android Market, pay a few dollars for “No Root Screenshot It” by Edward Kim, then download and install it on your Android Phone. You will also need to download and install the correct Android Phone drivers on your Windows computer. Next, you should complete the installation instructions for “No Root” which include installing a tiny helper program on your Windows Computer and making a few minor changes to the Settings on your Android Phone.

    I have created and stored at least 425 screenshots on my Droid Incredible from Verizon using “No Root.” (I have also “shared” these screenshots with my desktop email so that I can easily use them in my new marketing program.) Sometimes it takes a little trial and error to get all the moving parts of “No Root” to cooperate and work together as a team, but you should be able to get it to work for you, as long as you have a little patience. Stop by for a virtual cup of coffee at my virtual office and let me know how my “No Root” suggestion works for you. I will be launching the site in a week or so, just as soon as I can finish writing my main articles. Hope to see you then.

  48. 48

    Hi Jon,
    think about the most size diffused, 480 x 800.
    Now consider the scaling ratio between the four main density sizes:
    3 – low density, 4 – medium density, 6 – high density and 8 – extra high density
    Google says that we have to work in medium density as baseline. So if we want to convert our size, 480 x 800, following the previous scaling ratio ( from 6 to 4 ) we have to scale 480 – 480/3 = 320, and 800 – 800/3 = 533.
    And that’s it!

  49. 49

    I have some graphics that are so simple that its just not worth recreating 20 graphics, into 80 different sizes and densities.

    How would tell the device “just use this 1 graphic and resize/redensity it as you need”?

    Should just “putting it inside res/drawable” always do it automatically? What size and density should I make it?

  50. 50

    Is author retarded? DPI is used only in printers.

  51. 51

    Hey Stefano, where does the denumeration 3 (800/3 and 480/3) came from ? can you show me how to convert from 6 (HDPI) to 3(LDPI) ?


  52. 52

    this is a very good articles. I always have a problem to design on Android due to different resolutions. Its easier to design on iOS. :)

  53. 53

    QR code is a great invention people made. I’m making mobile apps currently and find it really cool to implement QR codes into them. I’m amazed at QR code coupons Snappii app builder allows to create. They are really helpful for small businesses.

  54. 54

    Great article! Had so much confusion…

  55. 55

    By the comments left here or just the hideous interfaces I’ve seen… the real problem seems to be the Android SDK. It doesn’t have to be this difficult. Since when are raster on-screen graphics referred to in DPI? This means I can’t do pixel level graphics because they may be interpolated to the nearest resolution… very odd. Could you imagine if web design was like this? And web pages (usually) have to accommodate for every possible size (resolution.) I would have rather seen supported resolution asset folders (i.e. 640×480) instead of using the ldpi, mdpi, hdpi, etc asset folders. At least then you’d have concrete numbers to work with (like iOS.) I appreciate the article though (very informative.) I just wish it wasn’t necessary.

  56. 56

    About screen density and size : I just finished a tool to help me (and could help other people too) to generate their images easily
    Feedback is always appreciated ! (Resizes xhdpi .png or .9.png to other densities)

  57. 57

    Web design already *is* like this. Mobile Safari and the Android Browser employ the very same mechanism that is in place in Android (and actually in iOS too, for that matter. The only difference between iOS and Android is that iOS has two target densities (MDPI and XHDPI) while Android has four. Really not that complicated).

    The reason is that you do not want the same behavior websites and applications used to have on the desktop: That the higher your screen density gets (which should be a good thing), the smaller your UI becomes (which is a bad thing). This would be disastrous on a touch screen device. Your fingers don’t automatically get smaller just because your pixels did.

    Instead, you define elements to have an actual, physical size. A button that is 2cm on one Android device is also going to be 2cm on any other device, no matter its screen properties. And this is a very, very good thing. Usability > Pixel perfect graphics.

  58. 58

    There’s a problem with this article i think
    Originally the baseline talked about is at 320×533 which makes sense to me as proportionally its the same as 480×800

    However later on the article says
    “(remember the “baseline” is a layout set at 320 × 480)”

    Which is it???

    And if it is 320×533…. how does one scale their stuff for a 320×480 screen? We’re losing height there…. hence losing space on the screen for our elements, meaning on a screen where the user doesnt scroll down… wehave less space to play with

    Want to get htis perfect but due to conflicting advice around different tech forums — its v tough. This article is great – until i spotted the conflicting advice within the article itself

    Whats the baseline 320×480 or 320×533?

  59. 59

    Research what you are talking about before making an asinine comment like that.

  60. 60

    Can’t I just design my graphics large and high quality, and have Android scale them down as needed.

    For example, if different devices require an icon to be 32×32, and 48×48, and 96×96, then why can’t I just create ONE nice transparent png icon that is 200×200 and set the relative size of it in the code, and be done?

    Or am I missing something?

  61. 61

    We’ve taken a close look at Android vs. iPhone on our site. Android is now well ahead of the iPhone in the mobile OS wars. Please review our take on the subject of Android vs. iOS.

  62. 62

    You could do that but its likely that your scaled images will look blurry or pixelated. Similarly, you could design solely for mdpi and Android will automatically scale up/down for hdpi/ldpi. You can usually get away with this without the image quality being affected too much. The result is obviously going to be less desirable the more scaling that is involved. The same degradation of quality will still occur if you manually scale your images with Photoshop but I think their algorithm is better.

    I think the “best solution” for having “perfect” images regardless of the DPI is to design your graphics using a format like SVG and then to export to the size you need.

    Personally I think all of this is more trouble than its worth. I use a combination of the two approaches. I design my graphics using SVG and export to mdpi and allow Android to do the scaling itself. If the result looks poor then I can always export to the size I need and drop it into correct res/drawable folder.

  63. 63

    Please give me tips I am new in android . Please see this and share suggestions .

  64. 64

    this site may help you for the other custome development.

  65. 65

    thanks for sharing, may be useful.

  66. 66

    Love it..

  67. 67


    I must say the article is much neat that the android’s design guidelines. I was strolling on android’s site and though things are placed in tidy way, the concepts messed up.

    And you cleared up that mess in my mind

    Thanks much.

  68. 68

    Hi, I am developing a website optimized for mobile devices (web browsers), I am developing clickable interface (i.e. images used as buttons) I need to know, what size in pixels (width and height) should I adopt so that it is easy to tap using finger.

    My website that I need to be optimized is

    Waiting for your guidance.

    Thanks in advance

  69. 69

    That’s a cool writing on designing for android and how to do it in detailed process . i am also a Android geek and i have my own blog at AndroidShouters.Com
    here i also share news and trends on Android .

    Thanks for sharing your awesome guideline on designing for android again..

  70. 70

    My family members all the time say that I am wasting my time here at net, however I know I am getting familiarity all the time by reading thes good posts.

  71. 71

    The negative with all these tools is that they don’t integrate with the operating system. One of the biggest temptations for a new Spanish student is the desire to jump straight into conversation. Just pick what you want to send, then position the phones closely and gently bump hands with another Bump user.

  72. 72

    Asking questions are genuinely nice thing if you are not understanding anything completely, except this post provides nice understanding yet.

↑ Back to top