Shared publicly  - 
Nexus 10 launcher icons

The gorgeous screen on the Nexus 10 falls into the XHDPI density bucket.  On tablets, Launcher uses icons from one density bucket up [0] to render them slightly larger.  To ensure that your launcher icon (arguably your apps most important asset) is crisp you need to add a 144*144px icon in the drawable-xxhdpi or drawable-480dpi folder.


[0] –
Andrea D'Alessandro's profile photoAdam Nybäck's profile photoJerome Lacoste's profile photoChhotelal Babu's profile photo
This makes Android such a beauty from tech point of view. If people have created xhdpi assets for Galaxy Nexus (etc) and they had nice 10" layouts for Xoom (etc) the OS will automatically combine those two and the app is already fully optimised for the new N10. <3
+Benjamin Weiss remember, the display itself isn't xxhdpi, it's just where the launcher/system will be looking for one-bucket-up icons.
omg, so what's the max heap size per app on it?
can't wait for all those "I have 800 apps installed apps and the launcher crashes" emails... :(
Guys, is this why we have those mipmap folders in some apps' resources? Can we use those instead? I don't recall which Googler told me that those were meant exactly for this use case, maybe it was JBQ, but I don't remember.
+Sebastiano Poggi AFAIK mipmap folders are primarily used so that our build tools for system apps can differentiate between density-specific resources that are safe to remove at compile time (e.g. MDPI assets for a system app compiled for an XHDPI device) and those that should not be removed (launcher icons, as discussed in this thread). At runtime there is no difference from a drawable directory.
This is where it would be nice if we could includes vector assets (eg svg) and have Android scale and cache them at install time. (Like with dalvik cache....)
+Ronald Ammann I think +Juhani Lehtimäki was referring to app UIs in general, not the launcher icons. Your 10" layouts and your XHDPI assets, blended together beautifully on a device for the very first time (assuming of course you follow our very basic best practices) :-)
Has anyone else noticed that Google has the whole double resolution thing with the Nexus 7 and Nexus 10 that Apple likes to do? Or is it just me? 
+Simon Marquis we'll make sure that the docs get updated but wanted to give you guys an early warning!!
+Sam Nalty that's just a coincidence, and that's pixel resolution. They have different dip resolutions (~960x600 dip and 1280x800 dip) and their densities are closer to 3:2.
You can't beat a good density bucket.
Fwiw, yes as Roman says the mipmap resource type is currently there just to let the platform build system know that it shouldn't strip those resources when building for a particular device.  At some point in the future though the plan is to use these as more real mipmaps -- allowing you to ask for a resources of a certain resolution and let the system select the correct mipmap item for you, etc.
Thanks. Btw, I think Android team needs to update the guidelines ( ).
Ed King
Can you guys speak English?!?!! LOL 
My vote is for 4k Tablets to have the drawable-porndpi requirement. 
Really looking forward to this along with the nexus 4 
Just did some research into why the nexus 10 is using a dual core processor, unlike the quad core being used by the N7 and the soon to be released phone...then I realised what processor has actually gone into the 10 and that erased all fears phew! That A15 chip does not f***k about :-)
+uchenna anokuru - Really looking forwards to this along with the Chromebook.

I'm going to skip the Nexus 4 because I have 1 year of VZW contract left. Hoping for a GSM+ LTE phone next October, after T-Mobile has finished deploying its LTE-A network.
With every new higher density device that comes out, it makes my life so much harder when I'm designing android apps. I have to pixel tweak every single drawable for ldpi, mdpi, hdpi, xhdpi, and possibly xxhdpi when the next greatest device is out. This is insanity.
+Eric Richardson that's nice, but the screen on the N10 is still xhdpi. Someone arbitrarily making the choice that icons should be larger doesn't change that. Using the icon from a higher density simply makes it 1.5 times bigger on screen. If they were using the system that they had actually set up to work with density dependent image assets, they would put the icon in the right place instead of using magic. 
Whenever I read about a product launch, I imagine people running around, throwing the product into the air and making rocket sounds...
+Victor Stuber I've dropped LDPI a long time ago,  a shitty screen is a shitty screen...

And I would love to drop MDPI as well.
+Jens Zalzala There are a number of things wrong with that approach:

- It isn't just xlarge screens where the larger icons are used.  For example, Nexus 7 also uses larger icons.

- In fact this is part of a general API to retrieve different size icons which this structure breaks:, int)

- If you structure your resources like this, then you are going to end up duplicating resources -- for example this icon you put in -xhdpi-xlarge can't be used in xxhdpi devices that will be showing up soon, you'd need to put a duplicate of it in -xxhdpi.

At this point we really do consider app icons to be mipmaps, and the various sizes you provide to be just different sizes that the UI can select for its desired purpose.  By providing them all in one consistent resource, you let your same icons be used both for density and size variations.
+Victor Stuber You really don't need to create every density of all your assets.  For example, pretty much nobody (including the platform and its apps) has specific assets for the tvdpi density of the Nexus 7.  Have you seen people complain about this?  Pretty much never.

By far the most important asset for your application is its app icon, and you definitely should have all the different sizes for that -- it is the central branding for your app, appearing in the launcher, action bar, share menus, etc, etc.  Spend the time on that one...  though even there you don't need to worry about a tvdpi density, since a device like the Nexus 7 uses larger than normal app icons so conveniently ends up using an hdpi asset for them. :)

For your other icons, though...  you probably can do a lot less than you think.  There are even a number of assets in Android itself that don't have xhdpi versions or what-not.  As the screen density gets higher, the importance of having an asset for that density becomes less.  In addition, directly scaling an asset down from a larger size to a smaller size can often give very good results.  Unless you actually want to rework your art (simplify it when scaling down), it is well worth starting out with a sparse set of assets and fixing things only where needed.
+Dianne Hackborn Letting android scale my drawables is simply unacceptable when I'm striving for pixel perfection. I'm forced to create every single density version of my image and push pixels around in photoshop until edges are sharp etc. It's unbelievably annoying
+Victor Stuber Why do you have that goal?  If not even the platform considers that to be an important goal, why is it more important for you?  As I said, there are basically no tvdpi assets in Android, so most of the assets on the Nexus 7 and other similar tablets are scaled from hdpi.  People seem generally fine with that, and that is actually a pretty low density screen compared to most other things -- hdpi, xhdpi, xxhdpi.

Or put another way -- do you really think it matters at all to make a custom image for an xxhdpi screen so that it has sharp edges?  As the density goes up, there is clearly a point of diminishing returns.  You do need to decide where that point is.
+Jim Avila xxhdpi was added a while ago, addressing both the beyond xhdpi density screens that manufacturers have been talking about and larger app icons on xhdpi tablets like the Nexus 10.  (And believe it or not, we've had a few people ask about even higher densities!)
+Dianne Hackborn I wouldn't say there's anything 'wrong' with that approach, in fact I would say it's the right approach based on how android resources are set up (of course, I have a lot less say on the matter than y'all, but from a developer point of view, this is how we see the system). For the N7 it would of course go into tvdpi-large. 
You do of course end up with duplication that way, but I think that just exposes an issue with the current setup. Using assets from a higher density only works if you want things to be 1.5 times larger, which is completely arbitrary. 
+Dianne Hackborn I get what you're saying, but that doesn't mean I should create less than perfect apps simply because people at Android don't consider it important.
+Victor Stuber I'm not a graphic designer but I think that's one of the compromises we have to make when developing/designing for Android. With the convenience/flexibility to reach so many different devices of different form factors, I think the Android team did a decent job of easing the burden of making the different assets that you're talking about. Even in iOS you have to design assets for all their differing densities, and they don't even automatically scale for you! Can't speak for Winmo8 though.
Btw +Nick Butcher thanks for posting this. It definitely deserves prominent placement in the Android Docs.
Well Google better launch project eyes we are going to need them to see these higher resolutions :)
Turns out I don't know what you guys art talking about.
Side question: instead of using folders drawable-ldpi, drawable-mdpi etc we can use drawable-120dpi, drawable-160dpi, drawable-240dpi, drawable-320dpi, drawable-480dpi ?

Would make drawable folder ordering better in eclipse!
+Roman Nurik would it be an error (or useless) to have something like drawable-400dpi? If so, then is there a lint check?

Also is drawable-480dpi supported at all API levels?  For example, drawable-hdpi is not supported before API level 4 I believe.
+Mark Carter I don't think 400dpi is an error, but I also don't know what the framework does with odd dpi's like that. #dpi is supported pretty far back, don't remember when, but likely after API 4.
+Roman Nurik is there any emulator available for nexus 10 or can u give the specf for nexus 10 emulator?
+Mark Carter: It only orders better until drawable-1000dpi comes out. You should be lobbying for drawable-0120dpi. :)
Kris B
Does anyone know if there is a new size for notification icons?
+Dianne Hackborn I'm quite confused at your argument against "pixel perfection". When you tell people not to create assets for specific densities, you're essentially telling them to not care as much, or not put as much time/attention to detail into their work simply because the system has a decent way of cheating. Isn't that strange? Or am I completely missing something?

Also, I understand the whole "you don't need to make tvdpi" assets, thing, but why not? Why tell people to not create assets (and in turn layouts) for an Android product (Google TV)? That's very confusing to me, coming from an Android team engineer.
As far as I can understand, +Dianne Hackborn is saying that there is a limit in how far you should attempt to go at pixel perfect images. While Android currently allows ldpi, mdpi, hdpi, tvdpi, xhdpi, xxhdpi - this list is going to keep getting bigger. When the list has 50 different DPI options, will you create 50 different pixel perfect images for every resource? At some point you need to draw the line, and that line has been drawn at tvdpi - tvdpi just uses hdpi.

Long term solution to this is to allow for device cached SVG images, pronto! Get on it Android guys!

Edit: Device cached SVG images should basically be in a drawables-svg or similar folder, and should be used only if there is not a .png image exactly matching an existing dpi. ie. If there is a hdpi image and a svg, it should use the hdpi image on hdpi screens, and scale the svg for any other screen. Fully backwards compatible (we can keep our current images), but for new devices with strange new DPI, it will automatically scale our SVG and solve all issues in future.
+Ryan Chazen I like the SVG suggestion. I wonder how plausible it would be to use that as a solution, though. I'm sure it becomes more plausible and practical with each new SoC being released, making more power/muscle/performance available at lower prices (and cheaper markets).
No, it's entirely plausible even on the oldest phones. The SVG conversion only has to run once at install time, and generate the drawable images and place them into the correct folders.

ie. When the app is installed to a XHDPI portait and XXHDPI landscape device, but only has HDPI and SVG drawables, it could automatically create XHDPI and XXHDPI png images from the svg and store them in the app's data folder.

So zero impact at all on speed when running the app, and maybe 3 seconds longer when installing a big app.

App downloads for major XXXXXHDPI screens with 10mb images gets cut down to a nice 100 byte svg, too. ;)
It is 100% needed to future proof Android for major screen resolutions that seem to be coming our way fast (finally, can't wait!)
help.  dropping in a new drawable-xxhdpi folder breaks my project.  I presume this is because the currently release SDK doesn't yet support it?  Bummer because I was about to put out a new release of my app and wanted to have it ready before the Nexus 10 hits the market.
This is why I love the resource framework on Android. So powerful!
+Paul Lawbaugh If you really want to build against an SDK before xxhdpi was introduced, you can use drawable-480dpi.  xxhdpi is just a synonym for that (like xhdpi is a synonym for 320dpi).

+Ryan Chazen SVG is really not such a clear benefit.  Unless you have some kind of significant hinting in the image, rendering a vector graphic at say 240dpi is not going to give you much (if at all) of a different result than scaling down a higher density bitmap.  The SVG rendering is still going to have many of the artifacts that people often think they avoid with vectors, such as grays along edges due to lines not being positioned on pixel boundaries.

I get a lot of pressure from people to have vector image support in Android resources, and my general feeling about this is that a prerequisite for that is to first have a build-side asset flow based entirely on vectors that real UI designers use as part of the bulk of their asset production, never touching bitmaps.  And shows some significant advantage over simply generating the original assets as very high resolution bitmaps.

Also we are clearly reaching an upper limit on the density that we care about for bitmaps.  If nothing else, I can't imagine most developers really caring about providing assets for any higher resolutions, and even xxhdpi I would say is only really of use for application icons just because of the pattern of those being used to provider larger icons for xhdpi devices.

(Btw allowing you to scale up images arbitrarily on the same density screen is much more likely to be a place where vector graphics would have some utility, rather than handling different screen densities.)
+Dianne Hackborn I'm not so sure about that - from my use of vector graphics they always appear very crisp regardless of size. It makes sense too - since the renderer has knowledge of exactly what is desired, it can optimize the image to fit.

See the special rendering hint called "crisp-edges" and others for shape rendering on this page :

From what I've seen, it really does scale better than raster images.
crisp-edges - Indicates that the user agent should attempt to emphasize the contrast between clean edges of artwork over rendering speed and geometric precision. To achieve crisp edges, the user agent might turn off anti-aliasing for all lines or possibly just for straight lines which are close to vertical or horizontal. Also, the user agent might adjust line positions and line widths to align edges with device pixels.
It's not that easy with automatic vector rasterization. It wouldn't look good on low density devices. That's why even vector icons have pixel drawn counterparts for low resolutions.

And i don't think there would be a higher density devices than xxhdpi, even that is more than can be distinguished by our eyes. And for bigger assets there should be different approach then this hack with higher dpi buckets.
Hi there, but this seems not completely correct... I tried to put a 144x144px launcher icon in drawable-xxhdpi and that doesn't work, so after some digging around, had to put in mipmap folder and change the Manifest as well with "@mipmap/icon".
+Nick Butcher it looks like the drawable-480dpi isn't supported anymore. At least not by the Android Play Review team.
I have learned each and every things from your tutorial and I like you very much to you because you are very nice teacher for me and my carrier.
Add a comment...