Shared publicly  - 
When we were designing Android, we knew we wanted the platform to be able to scale between different screen densities. This is why even in version 1.0 all layout dimensions needed to specify a unit and we introduced the concept of the "dp" unit (for "density-independent pixel") as the normal unit to use.

Much of the motivation for this came from experience at Palm / PalmSource. Palm device traditionally had a 160x160 screen. Later in their life, Sony introduced a 320x320 screen; this worked pretty well by just doubling the coordinates supplied by the application so (unless using new APIs) it still thought it was drawing on a 160x160 screen but the OS would convert those and take advantage of the higher-resolution screen to show sharper text and drawn shapes.

This strategy became problematic in PalmOS later however when they wanted to ship QVGA screens. These were cheaper to produce since they were used in many other devices; by putting the handwriting area at the bottom of the screen you could still have the expected square area for the app. However their density was half-way between 160x160 an 320x320, giving a scaling factor of 1.5, and here the problems appeared.

On PalmOS, applications built their interface by placing UI elements at absolute coordinates in the 160x160 screen space. When doubling to 320x320 this was not a problem, it just meant the UI layout could only be positioned on every other pixel. However at a 1.5x scaling, the original coordinates now alias to the screen resulting in visible artifacts.

Here is an example: if I have a UI with a row of four buttons going across the screen, with two pixels between each of them, the 1.5x scaling factor means the distance from one pixel to the next switches between 1 and 2 pixels on screen. So the consistent two pixel spacing of my buttons varies between 3 or 4 pixels on the actual screen just depending on where they happen to line up.

This was especially bad on PalmOS, where everything used integer coordinates and there was no anti-aliasing. Even if you have anti-aliasing everywhere it is a problem though -- your nice solid lines now get various gray smudges on them depending on how they align with the real screen pixels.

To solve this, in Android we have developers use dp units in layouts for specifying the spacing and widths of their UI elements, however we also have layout managers that are responsible for placing the final elements on screen. Once your layout is loaded, all "dp" units are converted to physical pixels, and the view hierarchy and layout managers run at whatever native density the screen is. So if you have a row of buttons with 2dp units between them, this spacing when scaled by 1.5 will always be 3 pixels on the screen. The layout manager will take care of doing the final fine-grained placement of UI elements so that they are consistent.

In theory then Android can scale to any density and show its UI to match the exact density of the screen. In practice we don't do this -- we have defined a handful of specific densities we support and require that compatible devices stick to them. Why is this?

The first reason is just to help our developers. UI designers tend to like to make nice clean graphics; these graphics are drawn as bitmaps, and giving designers a small set of target bitmap sizes to support instead of infinite variation makes things a lot simpler for them. Especially at lower densities, scaling the original bitmaps by a few percent up or down to exactly match the screen density is not going to bring much happiness. (You can argue here that the solution is to use vectors, but this brings a lot of its own problems and some significant overhead and limitations. Kirill has a great discussion on this topic at which I highly recommend.)

Beyond dealing with graphics, arbitrary density support has other issues -- it means that each phone's screen is slightly smaller or larger than another, making it imperative that developers completely embrace layout managers and let go of the control they are used to over placement on screen. This is something we have been pushing developers to do, and as Androids grows to support a wider variety of devices it becomes more important, however forcing this on developers 4 years ago because devices were varying by .1 inch screen diagonals would have been a waste and just gratuitously cruel.

Beyond that, it is not clear this is actually what you want. If I buy device A with a 3.5" 320x480 screen and device B with a 3.6" 320x480 screen do I really expect the UI on the second device to have a different layout? In fact I probably don't, and the chances of there being any useful difference between them (will text even be able to go up a point size?) is low. More than that -- maybe if I am getting a device with a somewhat different screen, I actually find it attractive because the UI is larger and easier to see or smaller in my hand but still with everything shown I expect.

So Android defines a few major buckets of density values that devices can used, called ldpi (approx 120dpi), mdpi (160 dpi), hdpi (240 dpi), and xhdpi (320 dpi). Manufacturers can select the density that is appropriate for their device, as long as it results in a screen that (after scaling for density) is within the minimum allowed screen size of the platform. Because there tend to be some standard display sizes (320x480, 480x800, 540x960, 1024x600, 1280x720/800, etc) the layout spaces apps encounter tend to congregate around a handful of specific buckets themselves, even though the actual physical dimensions of device screens are all over the map.

This all came to my mind when Tim Bray recently posted about a cool web site (which unfortunately seems to be down right now) that lets you compare the actual sizes of different devices:

I was very happy with how things came together for the development of the Galaxy Nexus, where we had a new screen density we had seen coming but never shipped a product on, and a new screen size and resolution that we had never explicitly considered supporting. Besides creating assets for that density and some cleanup of layouts, Android and its applications were able to pretty much run on it as-is.
Michael Basil's profile photoVandré Brunazo's profile photoJoshua Wolfsohn's profile photoDianne Hackborn's profile photo
The Android APIs are so well designed, it makes me wonder why the apps that have come from Google use them so incompetently. Scoreboard, Listen, even the very new Currents. You'd think they would do a better job of supporting multiple screen resolutions, sizes, and device features.
The TRG 330 was the only PalmOS device packing a 240x320 display, wasn't it?
Actually, Android does such a good job scaling to non-standard dpi, that I wish more app devs would NOT specify DPI requirements, or that they would be able to specify RANGES in the market.. then advanced users can set the DPI as desired without losing access to a good portion of market apps.
I'm also left wishing Google would make better use of varying display sizes in their own apps.

Take the G+ app, for example. The UI used on tablets is pretty much the same UI on phones. There is a whole lot of white space left on the screen with nothing filling it, white space that could be put to much better use. Compare it to Friendcaster on tablets.. Friendcaster is beautifully laid out, with what looks to be multiple fragments all working seamlessly with one another to fill out what would otherwise be white space, and instead offering more details visible on screen along with better navigation options than what is offered on smaller displays
+Jason Hsu I don't know if any of those QVGA devices were released. Maybe one was, not sure.
+Skye Harris Yeah the G+ app doesn't have a layout yet for large screens. This doesn't all happen by magic -- no production platform I know of will magically adjust applications to take advantage of major increases in screen size. I would guess that for G+ the focus right now is on phones since on tablets the web-based UI is fairly usable.
+Dianne Hackborn Sorry,I would agree with that from a UI perspective, but, umm --- you can't use the Web-based UI for Google+ on an Android tablet without it CONSTANTLY crashing. I get that Google likes to make the "Web Based" argument a lot too, but you couldn't use Google Music on Google TV through the web UI (and the new native app is pretty horrible). I would be happy to use G+ on my Xoom with the web UI (actually, happier) but it is crashtastic.
Actually thinking back there may have been some devices targeted to Asia that had 1.5x scale displays. I do recall there was a bit of a mess with application developers having to add in support for 1.5x. Then again, it was the same situation with 2x scale and color (until they were supported in the official SDK).

It's definitely evident in the Android APIs that the designers took great pains to prevent locking the platform into rigid screen resolutions.
I still don't understand the dp - pixel thing. On Android Design, icons are recommended to be 48dpx48dp. Would that be the same as creating a 48x48 pixel image in Photoshop? Kinda confused.
I am reminded of the futility of locking a device to a specific screen resolution anytime I sit down to an iPad and try to use an iPhone app... it looks like vomit...

At least on Android, an app that's made for a phone screen will still scale up to a tablet without looking like vomit. It may not take advantage of the additional screen space, but it's not going to look blocky either in most cases.
+James Jun for icons, you should look at raw pixels and assume they get a little scaled (but not much). The "dp" spec is really only good for hard layouts in port vs landscape. I also like to think you should only use dp in one dimension at a time (left nav on a tablet sizing, up/down sizing for content panes and phone stuff) It works well to make stuff scale beyond design specs (It will make nice looking fonts, keep proportions, and upsize images), but ideally for icons, including you app icon, you should include replacements in the various asset folders (including even changing the icon a little for M an HDPIs if you are doing a complex vector icon rendered down).
+James Jun The idea is, a "dp" is basically the raw size of a pixel on a HVGA 3.5" (IIRC) screen.

For icons, you can include multiple resolutions. 48x48 is "MDPI", or the default. If you have a higher DPI screen (say VGA at 3.5") it will use the "HDPI" image (72x72). So it is best to create your icons in a vector format, then export several size of them into your projects /res/(x)dpi folders. If you need a guide, I like You design your icons at 512x512 vector, then you can cleanup the smaller sizes so they look good.

But if you lay out an app in DPs, especially spacing in 1 axis and dealing with margins and gutters, even if you don't have higher res images, it will up upscale the images, anti-alias the fonts, and make the app generally look good when they release superduperhighdpi as a screen size.
+Dianne Hackborn I'm aware it doesn't happen by magic (I'm an app developer myself.. albeit hobbyist not professional), however I still find it poor form that it has been neglected.

Where a native app is available for a service, people will tend to want to use that rather than a web site. While yes, Android tablets (and by this I refer to those running Honeycomb onwards) are still a relatively small scene, if Google wants it to succeed then they should be showing it more support themselves with their own apps.

As you are likely well aware, the stock Honeycomb browser isn't the most stable piece of software, and the typing lag present in the browser on a number of popular Honeycomb tablets is also not pleasant to deal with when typing longish posts/comments. Even given the lack of tablet support that has been paid to the G+ app, I prefer it over using the G+ web site on my tablet, but how far can Google expect others to offer up layouts for larger displays if Google themselves aren't being proactive in doing so?

(I am aware that both the typing lag and browser stability are addressed in ICS, however this is not yet available on the majority of tablets)

One of the main criticisms I hear from others regarding Android on larger displays is that apps are not being written to take advantage of it. While not purely the fault of Google.. after all you have made available the resources for developers to do it.. if Google cannot lead by example then many are not going to follow. One cannot be blamed for expecting Google to support their own platform better than they currently do
1) Excellent discussions re: svg, information density, pixel tweaking, hinting. I still think there's a place for svg on android, though. The simple gray shapes all over newer google apps seem like great candidates.

2) UI scale is presently a function of screen size and density. I'd like to see one more input to this: user preference!
+John Ruble User preference (ish) was added with 3.2. If you use a drastically upscaled app, it gives you the option to click a + (with 4 arrows) icon on the nav/notification bar to globally upscale the app as though it were an MDPI app on your device.
But soon we would have 1920x1200 resolution, ASUS TF700 for example. Another higher dp? Will Android support this? Or need another newer version?
+Agustinus Upojo The Android rendering engine will scale arbitrarily. In my app, for example, I do all my own pixel drawing, but I use the Android "DisplayMetrics" to decide what I am drawing and draw with vector "float" values. You can even design your own "low level" widgets and support screens of arbitrary size and density.
The only problem is that some short-sighted developers specify in the market compatibility details that their app will only run at specific DPI levels, when in reality it will run just fine at arbitrary levels... the result of this is that the app becomes invisible on the market to any device not operating at the pre-specified DPI levels. Developers need to stop DOING this...
+Robert Cooper I mean like make-everything-n%-smaller-or-larger kind of scaling. You can kind of get this today with root-requiring system-wide density hack apps from market, but it makes for a clearly hacky/untested experience.
+Agustinus Upojo I can't wait for that thing! Text will be so clear!
+John Ruble Yeah, that is what Google added to 3.2 though. It is stupid that you need it (even for apps FROM GOOGLE). It also doesn't seem to work on phones (My Galaxy Nexus won't let me scale the idiotic Hasbro Scrabble app, for instance, but my ICS XOOM will).
+John Ruble This was added just recently in Android 4.0, there is a new preference setting for the global font scale. Developers do need to opt in to this by using the "sp" unit instead of dp where appropriate.

+Robert Cooper What you are talking about is not the same thing, it is the compatibility mode for old applications. It's not any more stupid than iOS's option for how to deal with non-tablet apps, except Android does give us the extra flexibility of having an option to give the app the full screen size to do its own layout in.
I owned a HandEra 330. It was the only PalmOS device I knew of with the oddball (for a Palm device) QVGA display. Apps specifically coded for the display look very crisp. Most other Palm apps had a coarse look due to the scaling artifacts Dianne just described.
Using vector graphics for icons can work, but not with SVG as SVG was never made with specific use cases like icons in mind. One of the things which SVG is missing is official support for level of detail, to be able to have details dynamically appear when scaling larger, and disappear when they become too small. Haiku OS has been using vector graphics icons for 6 years already, and it works quite good Though I agree it depends on the style you want to achieve, since some styles are OK when for example line thickness scales, while others need it to remain constant. Some art can only be obtained with hand tuned bitmaps.
So how are your efforts at resolution-independent layouts different from rasterizing outline fonts? It seems like you'd face the same set of problems.
Clearly +Dianne Hackborn and friends had some experience at Palm then. There are stories about a clutch of engineers who worked at Be, ended up at Palm/PalmSource, and are now some of the driving forces behind Android. Is this true? I wonder how many of you guys come from Palm, and perhaps Be before that?
Nice post. This is exactly the problem that apple will have soon. Everything is absolutely laid out, and they could only double the pixels with the iPhone 4 to maintain backwards compatibility.
+Leo L. Schwab Actually you could make analogies to them, with the view hierarchy doing layout in pixels being similar to the idea of hinting in fonts.
Thank you, Diane. Tell me, why not plan for tomorrow today? Doesn't Google want Android apps to run on large surfaces with UX similar or superior to, say, And what about the potentially wall-sized surfaces which will be enabled by NHK's 33 MP video/display technology in the future? And, sorry, I'm not quite clear on Android's strategy for multiple side-by-side apps/windows when abundant screen real estate is available? Is there a URL describing how to create multiple floating concurrently-visible windows? Thanks again, I enjoy many of your posts.
+Richard Creamer Sorry, I'm not sure what you are specifically getting at. There is no limit in the platform or compatibility requirements on the size of display. As far as side-by-side apps, that is a feature that we don't currently support just because it is a lower priority than all of the numerous other things to be done... there is no need for a strategy, the platform can easily evolve in that direction as needed. The fact is though that if you want to build devices like that today, this is not the type of thing we want to support in Android today, so Android right now may not be your best choice. It is important to have focus on the things you think are most important now rather than trying to do everything anyone could want all immediately. We did some further-looking thinking for density and screen sizes because these are things you want to have in your platform at the start so that your app paradigm will support it; allowing multiple apps on the screen is not something that has as much impact on the apps themselves, it is mostly just an OS feature.
Diane, sorry for not being clear... Small keypads reduce how much I write... What I was getting at was using subtended human visual angle for sizing GUI elements instead of various types of pixels along with a way to specify the maximum angular dimension a GUI element needs to achieve to be easily visible to human eye. The latter could be used to place an upper limit on how large to grow an aggregation of GUI widgets/assembly. This capability would be useful in multi-window displays. Thanks again.
I would generally say we are already doing that. This is one of the reasons for density not being directly correlated to physical dpi. For example Google TV when outputting 1080p is running as an xhdpi device. This is actually a lot higher than the real dpi of the display (which can vary all over the place depending on what tv you hook up to it), but is a good density to generate a reasonable UI for the expected TV experience when sitting the typical distance away from the screen.
Thank you, Dianne.

Btw, my first 2D-graphics-intensive Android app "Cool Clock" draws itself in < 20 ms on my Android phone (Android 2.3.4):

I am very impressed with the rendering speed and quality - kudos to your team! Btw, the phone's rendering speed is substantially faster than on my Kindle Fire. I also found porting the graphics from Swing to Android very straightforward. Again, nice job on your API!

It also resizes itself nicely for any resolution. (You see, I originally wrote it in Java/Swing about 2 years ago and designed it so that it did a nice job of scaling everything in real time as I continuously resized a JFrame from 1024x1024 down to like 32x32.) Of course, it's easier to scale a 2D graphics component because there are no GUI buttons etc. It only took around 50 lines of code to get the smooth scaling not counting the drawing parameter definitions.

Finally in case you're interested, I wrote a 54-slide PowerPoint describing my first Android project entitled "An introduction to developing custom 2D graphics Android applications" URL= A link to this product's page has more information: (The PowerPoint was targeted for an audience, many of whom were unfamiliar with Java, hence the Java/Android intro sections.) The app was targeted at elementary grade children. Still need to remove the Exit button though:-(

PS: I apologize for misspelling your name in my earlier posts!
Thank you Google, for allowing me, a 16+, to access this rich space of Google+, with almost the same amount of freedom as everyone else (18+) out there.
What when adding soft keys to the bottom of a droid 3 how high would the status bar have to be BC it getting bigger when u enable shownavagation bar.

We're finding that sometimes manufacturers fail to properly set up the densities in parts of their OS builds. The Attic was one we saw that in, related to font sizes. There have been a few others as well. Note that this never happens with the reference Android build, so we assume its only the customized roms that actually have the problem.
That should read "Atrix", can't edit a post in G+ mobile :(
Great discussion topic Dianne!
I'd love to see some pictures as examples to show others (un)interested in UX / UI what the real deal is on 'pixelperfect' interface design, along with correct font rendering.

Would you have such pictures to include, because this is educational textbook material!

Keep up the good work!
Too many screen resolutions for Android device
+YI SUN In the future all of our computers will only have 3.5" and 10" screens and nothing else?
I have the same incompatibility issue with the market. Very annoying. It would be very nice to be able to disable the check or to ignore the warning and install anyways, risking a app that does not look 100% ok.
+Toni P and +Bas Rieter this is something for you to talk with the app developer about. We try very hard to have a good contract with apps so that they can control which devices their app is delivered to, where they know it works. To do otherwise causes them to get punished by users (with bad reviews that directly impact the profitability of their app) for things that have no responsibility to have to deal with.

As far as I am concerned, it is very much a feature that Market doesn't allow you to install an app on a device that has been configured in some non-standard way.
"As far as I am concerned, it is very much a feature that Market doesn't allow you to install an app on a device that has been configured in some non-standard way."

And THAT attitude is the problem. The one-size-fits-all approach is one of the things that's holding back Android the most - it just doesn't work, because of the multitude of devices (remember what happened when the first QVGA devices came out? Same problem - they couldn't find half the available apps in the Market) and different screen resolutions. Unfortunately, the text size on Android seems to be designed for half-blind mole people - for people with good eyesight, this is simply a waste of screen space.

And as a long time user of non-standard screen-densities, I can safely say that there are very few apps that don't look perfect anywhere between 180 and 240 DPI on a WXGA device...

A toggle (possibly hidden in build.prop, and therefore only accessible by experienced users) would be a good way to take care of this issue. If need be, not allowing non-standard LCD Density devices to rate apps in the Market would be another measure that could be taken...
Well you know, if you go ask a lot of our developers, they will say we don't do enough to help them control where their apps are run. So I do wonder what you mean by a "one-size-fits-all" approach? I think that from the perspective of most third party developers, they would laugh (possibly pain) at the description of Android as being that way. Ultimately all we are doing is giving developers APIs to have some control over where their apps are run, if they want to, and respecting those wishes.

Android has defined a specific set of densities that are supported, for the reasons I have mentioned, and to help developers have a simpler world to deal with. Hacking the platform to make it run as a non-supported density is turning your build into a non-compatible device as far as the CDD and CTS is concerned. Technically Market shouldn't allow you to run it at all.

As far as being able to make the UI smaller, Android 4.0 as a setting to control the text size. Also the text size can vary significantly depending on the screen size -- on a screen like the G1 or Nexus One the size is relatively small, but the manufacturers who have been creating these significantly larger screen sizes with the same resolution have also been giving you devices with much larger text. You do have alternatives though -- for example devices with qHD screen are generally hdpi and this results in smaller text for the larger displays (basically the same as the Galaxy Nexus though at a lower density).

Also, when QVGA devices came out, yes existing apps had to be updated, but this had nothing to do with density. The problem there was screen size, in particular that QVGA has less space than the original HVGA screens. So many, many apps running on those devices would have the bottom of their UI cut off or other significant problems. We very much did not want to have those devices ship with limited apps available in the Market, but when confronted with a question about whether we do that or leave our app developers hanging as they find their app running in an environment they didn't expect and get hit with a bunch of negative reviews because of this, I feel strongly that the app developer is more important. Getting hit with bad reviews can be devastating to developers; it is never something to take lightly.
Hi Dianne,

Thank you for the extensive reply.

The "One Size Fits All" approach I referred to actually turns out to be an "X sizes fit all" approach - the screen density/resolution buckets. Essentially, we've got the worst of both worlds - restriction to certain densities and resolutions, as well as incompatibilities with older, no longer updated apps when devices with new screen sizes or resolutions appear.

Why do you think the large WVGA devices (Galaxy S family and Desire HD, for instance) which appeared during the Froyo/Gingerbread era ran on an LCD Density of 240 instead of, say, a much more appropriate 200? I'm quite sure it wasn't in order to have gigantic text, but rather in order to preserve compatibility with a large part of the Android Market. This led to a sub-par user experience and a waste of that nice big screen - what's the point of carrying around such a big slab of a phone if the screen isn't capable of showing more information?

It's too late to switch to a fully scalable (a la maximized desktop windows on PC) system now, but in the current iteration, the only thing stopping users from enjoying text and UI elements scaled to the size of their choice is an artificial limitation. Android already scales nearly all apps to pretty much all human-readable LCD densities more or less perfectly.

Now if, on the other hand, you were to tell us that many negative ratings on the Market stem from users who are using the app on incompatible devices, that would be rather more understandable - Right now, though, it seems more like the threat this measure is protecting developers from is next to non-existent.

As it stands, it's something that most of us will just have to tolerate, what with the complete lack of an alternative. Font scaling in ICS is a step in the right direction, and I'm hoping we'll see more on that front (scalable everything :p) some time in the future.

For those of us that live on the edge, LCD Density wise, it's just very unfortunate.

Thanks again for taking the time to reply!
Simon ... your wrong, go buy a WP7 :-p
Ky Go
I'm a bit upset about the whole thing..
i have a 4.3" display, and i should run it at 240? not only does that look very ugly, it isn't even useful.
i'm running it now at 167, and its just beatiful. and i see so much more than i used to at 240.
why should this be restricted?

srsly, i cant even download the facebook app. or root explorer, or astrid tasks. i'm so lucky that i have backups of those apks!

would be nice if you change that back..

i thought android was free and open, but slowly i get the feeling that more and more restrictions like this are coming.
i don't like that.
+Kyrill Gobber +Simon Broenner A suggestion, just change back to 240, download your apps and then change back again. Problem solved. Right? If you want to live on the edge (and I do to by running a rooted devivce with an Alpha build of CM9) then some things might be a tad more work. Maybe we all win by letting the Android team concentrate on those things that are most important right now...
+Kyrill Gobber I have absolutely NO patience with this attitude of "i thought android was free and open." Get real -- you are running a build you made from the Android source code that somebody freely downloaded, modified, and put together to run on your device. You are running it with changes that are not officially supported by the base platform, modifying its behavior in way that are not intended, but you are free to do so. Not free and open? How can you say that? I am fed up with this attitude, that if people can't get every single thing they want exactly how they want it from everything they run on Android, which they have been given FOR FREE and have the complete platform code to modify HOWEVER THEY WANT, that Android has become this big closed restricted evil that somehow doesn't quality as an open platform.

And "more and more restrictions like this are coming?" Are you SERIOUS? The original 1.0 platform didn't allow ANY other densities, or ANY other screen sizes. If you look at the history of the CDD over the last few years, the range of device configurations that are officially supported has grown radically by orders of magnitude. So you don't think there should be any restrictions, that it should be a complete free-for-all where you and every manufacturer in the world can modify the platform however they want and let what happens to apps fall as it may? This is a terrible attitude. This is one of the reasons Linux has had significant trouble becoming mainstream.

And honestly, all you do with this selfish attitude is make me have no interest in helping you.

+Toni P I don't really know what you are getting at with your request for a "root-only" option -- the other people here have been talking about the change, if you have root you can hack the platform configuration yourself to make the change. If you are looking for a way to change the density at run-time, you are asking for significant work (the density is read by zygote at boot into a static variable and assumed a constant currently across much of the system, down to zygote itself where this determines what resources are pre-loaded by it) for a feature that is not only not available to developers, but would seen by many of our developers as a negative.

Yes it is true that Market is owned and controlled by Google, so Google does get to say how it works. As far as I am concerned this is essential for the health of the platform -- there needs to be some control and order to the ecosystem that our developers rely on, and Market is the mechanism for that. It is the only way to make guarantees to them about the environment they will run in, to simplify their life in appropriate ways. There is already a lot of stress from developers on dealing with different screen sizes. It would be extremely inconsiderate to cause them more trouble in this area when there is no significant advantage for the overall ecosystem. The disregard seen here is a good reason why it is good for Android that Google does maintain this kind of control over Market.
To give some perspective: the ability for apps to specify the exact screen configurations they support was not in the platform. The preferred design is for them to not worry about density, but only have restrictions on the screen sizes they support (since there are really physical limits to the sizes a UI can do layout in). The finer-grained restrictions is not something I would like to have, our documentation recommends against it, but were added due to significant demand from developers. It would be entirely inappropriate to turn around and ignore the requirements these apps have explicitly requested, and they are doing them entirely because the app developer feels a need (however misguided anyone may think it is) to do so.

Finally, as far as people buying some large screen devices and then being unhappy with how large the UI is -- there is nothing tricking anyone here. The manufacturers knew up-front which densities are supported, and went into that knowing what the result would be. You saw what it was like when you bought it. The manufacturer could have use a qHD screen to have a smaller UI with more content on it, and you could have bought a device with a qHD screen if that was what you preferred. I understand you want to after-the-fact hack the platform to run at a different configuration because you have decided the UI on your device is too large, however I don't think it is reasonable for you to have an expectation that this will be a "fully supported everything can run and run fine" configuration of your device when that is not what you bought in the first place.
+Dianne Hackborn , so the android docs are wrong when it says "160dp is always one inch regardless of the screen density"? This sentence implies dp values are always adjusted on any screen size and resolution. But you're saying dp only gets converted to the closest "bucket". Is this why 160dp actually shows up differently from 1in on my Nexus S?
+Vandré Brunazo Where does it say that? Yes that is very wrong. (In theory if you want "real" dimensions you use in, cm... in practice many many devices don't report the real correct screen dpi so these don't work.)
@Dianne Hackborn
Thx that you reply here actively!!
What i dont understand from a "just testing" aspect:
hdpi and mdpi are so far from each other but at least for the most phones available this means hdpi very big and mdpi very small.
With a step as big as from ldpi to mdpi it would have been a compromise for many users.
=> I guess the problem affects most 4"+ and 480 x 800 Pixel devices and so maby in a few generations its gone from alone..

But a general question:
For me it seems that nearly all apps support most dpi values and this shows that generally the whole system could work without a few standart values.
I respect your point in saving the developers from negative comments BUT i had contact with a few devs so far about dpi problems and they fixed it very fast. (example robo defense)

Wouldnt it be better not to restrict non standart dpi devices but to encourage app dev´s to support this?

If everyone (not only experienced users) could use his personal preference without restrictions that woul be a great benefit for the Android UI..
+Alexander Tasch Honestly... I don't know how more I can respond to this. At a basic level: have you participated in the developer forums and discussions or just looked at all what people are saying about Android in this area? Rightly or wrongly, dealing with a large number of screen configurations is a huge concern for developers. It just is not worth creating more trouble for them here, let alone the corresponding PR impact for us.

And there have been, and are, an increasing number of larger screen devices with higher resolution screens. If this is an issue for you, frankly, this should be an element in your decision of what device to purchase.
Hope its not annoying for you. From the comments i can tell there is a huge amount of users from a specific device / board :D

I personally havent had a look in the dev boards but your post here is some kind of statement that made it through.

With your arguments you totally have a point and with my little app dev skills i wont say anything against your perspective.

I think most people dont like the restriction and there should be an official way to enable all apps maby with consequences in rating apps (like disabling rating for non-allowed dpi).

But thats just my opinion from the users point of view. I will stopp bugging with this now ;D
It was nice to have your point of view on this.
+Vandré Brunazo I reported that incorrect documentation (where it says "160dp is always one inch regardless of the screen density") at It's so fundamentally wrong for how Android deals with dip that I'm surprised it hasn't been fixed before now. It has been accepted as a defect but if you star the bug report, it may get fixed quicker and help reduce confusion.

Here's an example on Stack Overflow where this is causing great confusion even when proof is shown that it is incorrect:
+Michael Basil oh I already starred that issue and already posted on that stack overflow question (added 2 pics to the answer) a long time ago. :)
Are you the Dianne in /system/framework/framework-res.apk/res/values/bools.xml ? In the file bools.xml, there is a line stating something like AnnoyDianne and its value is 'true'. I searched it (with Google, of course) and I got to this page..So are you that person? 
+Joshua Wolfsohn Yeah, that was a certain person's clever idea after seeing me rant a few times about people not following the naming convention in the file (to the point where it is hard to figure out what the naming convention should be). :)
Add a comment...