How To Design For Android Devices

> All the resolutions on Android are pretty confusing, i.e. we have xhdpi (2x), hdpi (1.5x) and mdpi (1x). They sound extremely technical. When I first started almost a year ago, the engineers couldn’t even explain to me what the ratio were for each of those. I had to figure it out by asking a lot of questions. The resolutions you should design in are 720×1280, 540×960 and 360×640. Make sure to include hardware buttons and the status bar on your design for high-fidelity mockups.

Uh, no. There is no standard resolution on Android. You shouldn't make any assumptions about it. Build layouts that scale themselves and adapt based on the screen width & height in density-independent pixels.

> Fonts are unfortunately device-specific so better expect crappiness on some devices.

Fortunately, starting with 4.0 you can force the stock Holo theme in your app. Unfortunately, the manufacturer apps are stuck somewhere in the 2.x era and have completely alien user interfaces in comparison.

> In 2x, the minimum pixel dimension should be 28px for text, 96px for menus & header and 116px for the footer.

It's a bad idea to talk pixels in Android at all. Instead, use density-independent pixels (and the sp unit for font sizes which also scales with the global font size) which are calculated based on the screen resolution and size/density. As two examples, the minimum size for a touch button should be 48x48dp to ensure it's big enough to touch, and a 7 inch tablet is at least 600dp wide.

There's a lot of shortcuts in this article. I appreciate him taking the time to put it together but a lot of important Android design practices were overlooked or misquoted.

There's 6 resolutions: ldpi, mdpi, tvdpi, hdpi, xhdpi, & xxhdpi. Of these, ldpi is often skipped, and tvdpi is optional (the Nexus 7 and Google TV use it). The new one, xxhdpi is important for new 1080p phones like the Droid DNA and upcoming Galaxy S4.

Resolutions are multiples. It's easiest to remember them as 48, 64, 72, 96, 144 (these are the sizes of your app icon). xhdpi is 2x mdpi. hdpi is 1.5x mdpi. tvdpi is 2/3 of xhdpi. xxhdpi is 3x mdpi & 1.5x xhdpi.

It's not pixels, it's usually dp (density-independent pixels) which are based on mdpi. As such, it's a good idea to design layouts at mdpi scale - it just makes it easier to match your dp values. I lay out for 320x480 and 1280x720.

I wrote a detailed blog post on 9-scale (http://radleymarx.com).

For most Nexus devices, the Action Bar is the only access to the Overflow Menu (aka the old Options Menu). So although it's only "recommend" to use it, there's no way to use the menu without it.

Fonts can be specified in the layout XML. You just need a custom TextView class. Note: widgets won't let you use custom class layouts. Fonts are added in the assets folder of the project. Some devices are picky about how you name fonts so it's best to name them as lowercase-name.TTF (uppercase file type).

Most often you'll want to match font sizes that other apps use. The minimum font size you can clearly get away with is 10sp on phones & 11sp on tablets. Users can change text scaling in their device so you should use sp instead of dp for text. If you don't want it to scale (i.e. a decorative layout) you can use dp instead.

The best way to design for devices is to buy one of each screen type. Some groups start a pool of devices to share for testing. For widgets I design for GS3 & GNexus simultaneously, along with a Nexus 7. When the layouts are complete, I start checking on other devices.

Speaking as a programmer that has worked on adapting Android designs from mockups to reality this is probably a very useful article for would-be Android designers.

The "up button" description is a bit oversimplified but probably sufficient for an intro to design post.

Also fonts aren't exactly "device specific" as stated in the post. You can embed your own TTF or OTF fonts into your app as a resource and use them. There are some annoyances to doing this (particularly when viewed from a designer's standpoint, so I'll let the article slide on this one) like the XML layouts won't recognize these fonts but you can programmatically assign the embedded fonts to Android's various text controls very easily.

Of course the hardest part as always when dealing with fonts is the licensing which is slowly getting better but remains years behind the licensing of other digital media formats.

Also on the issue of fonts, he mentions that Droid Sans is popular (since it was previously the default system font) but he should probably have mentioned Roboto, which is the newer and IMO much nicer default font, which is also freely downloadable, the entire set of Android fonts are available for use under the Apache license and can be used freely even in non-Android contexts.

He misses a lot of the intricacies of the Android design site ( http://developer.android.com/design/index.html ). You are actually recommended to make your content touchable rather than putting every action in the top right as an icon. If I made a weather app, for example, I may have little day or hour graphics that can be tapped for more about that item. Even for the action bar there is a split mode that puts actions on the bottom as well.

Similarly, he has the density classes wrong. There's XXHDPI, XHDPI, MDPI, and LDPI and they don't correspond to set resolutions. It's recommended by the Android Developer blog to actually change layouts based on a certain DP width (DP being a density independent pixel that normalizes measurements across density classes) rather than do x sizes of the same screen for each density. E.g. so screens with a lot of pixel real estate across get an extra list on the left, things like that.

I wish the designer in my company could be interested in these kind of articles. Is quite frustrating to receive time and again all the wireframes focused on an iPhone-like look, no matter what.

The resolutions seem off. The most common xhdpi resolution is correct (720x1280), however the hdpi one is 480x800 and mdpi is 320x480. Might be my mistake though, is there a clearer explanation why you chose those resolutions? Edit: This is in the case of phone sizes (tablets are another story). And even in the case of phones, you have varying resolutions inside those buckets. Yeah, explaining this to iPhone designers is always fun :).

Custom fonts are a problem, but there's a nice way to implement them (backwards compatible and all), and when you do it once, it will always be very easy. I don't have a code example nearby, shoot me an e-mail (in the profile) if you are interested, and I'll make sure to get a proper answer to you.

Awesome article! Twitter apps, please take note of this:

> Finally, if you respect their guidelines, all actions should be on the far top right. That includes functions like Refresh (because Pull to Refresh is extremely uncommon on Android)

Pull to Refresh feels really out of place in an Android app, don't use it! Most apps do not, but Twitter apps seem to be the exception, for obvious reasons.

Thank you for disseminating this information. It would be a great world if more designers really understood Android. The one's I've worked with haven't given much of a care about it, and just stiffed me with wrong size images, and I ended up having to sample them and make my own 9-patches.

I wish Adobe would make a 9-patch tool that works with their stuff. draw9patch isn't that good.

Very negative leaning.