The Nexus 7 has an interesting screen:

- 7 inches.
- 800x1280.
- "tvdpi" density (numerically that is 213).
- 600 x 961 in dp units.

Let's start with the screen size first.  Ignore the raw resolution, this is a 7" tablet like many other existing 7" tablets.  There are a number of existing 7" tablets with 600x1024 screens; they are just a different density (mdpi) vs. our tvdpi here.  Adjusting for density we still have the same screen space for layout -- 600x961 or 600x1024 is just the difference between a 16:10 or 16:9 screen, respectively.

Most significantly, in terms of the "smallest screen width" definition for how modern Android classifies screens, these are both -sw600dp.

Some people have commented that the UI on the Nexus 7 isn't a scaled down version of the 10" UI.  This is somewhat true.  It is also not just the phone UI shown on a larger display.  Various parts of the system and applications will use one or the other UI (or even a mix) depending on what works best.  For example parts of the system UI (status bar and navigation bar, settings) use the phone layout since they too compact in 600dp of width.  Other apps use the tablet UI or even a mix -- for example Gmail uses the tablet UI in the conversation list, but the message screen is either a single pane like a phone or dual-pane like a tablet depending on whether the screen is currently portrait or landscape.

For developers, when designing your app to scale up from its phone UI, this mostly means you should pick the break point at which any major change in your layout should occur and let the layout managers take care of all of the sizes in-between.  If your UI can fit down to 600dp wide, use -sw600dp; if it needs more or less space, use another width that matches what it needs.  You can switch more dynamically based on the current real width (allowing changes during rotation) for bonus points; fragments help a lot in implementing such things.

Now, the screen density.  I suspect a lot of developers' reaction to "tvdpi" was "wtf?!?" :)  This density was introduced last year for TV display support: http://developer.android.com/reference/android/util/DisplayMetrics.html#DENSITY_TV

For TVs, xhdpi is the density used for 1080p output (it gives the expected UI size given the typical distance one sits from a TV), and tvdpi was added to provide the same UI size for a 720p display.  As it turns out, this density is the same one needed for a 800x1280 7" display: if 600x1024 is mdpi (160dp), then 160 * (800/600) = about 213dpi.

For app developers, the next reaction here is probably "what, you mean I have to support another density??".  Fortunately you should not.  We consider tvdpi to be a "secondary" density -- one that counts as a compatible device, but which we discourage developers from creating assets for.  This can be done because Android's density scaling was designed to be able to support arbitrary densities, by including the concept of density in all of the UI specifications of the application (bitmaps, measurements, etc) and using layout managers for final pixel-accurate placement of UI elements.

You don't need to supply bitmaps for every possible density, Android will scale your bitmaps (typically when they are loaded) to match the current density.  All layout measurements are provided in "dp" units so these are likewise scaled, with the layout managers taking all of these measurements in pixels (after they have been scaled by the density) for final placement on the screen.  Font sizes are of course simply scaled, so they will be drawn at full resolution; since layout is done in pixels, measurement of text can be done based on the final pixel size, to avoid errors due to hinting.

Even so, when bitmaps are scaled to a density there isn't a design for, you may get artifacts such as softening of the edges.  There are a number of things Android does that mitigate this issue:

- Device screens like the Nexus 7 are now fairly high density, so scaling artifacts are often not noticeable.

- When selecting the original bitmap to scale from, Android will generally prefer a higher-density bitmap.  So on our tvdpi screen here, we will generally scale down the hdpi asset, which is included by most applications due to the dominance of hdpi phone screens.

- Android's tablet UI uses larger than normal application icons.  This is done by switching to a higher density version of the icon: http://developer.android.com/reference/android/app/ActivityManager.html#getLauncherLargeIconDensity() returns the density to use.  Application icons are some of the most critical for crisp display, so the density here is generally one step up from the current screen density (mdpi->hdpi, hdpi->xhdpi, etc) to ensure a designed icon is used without scaling.  The tvdpi screen maps to the hdpi density so that Launcher and other places these icons appear still use a designed size.

The Nexus 7 was a big test of how well Android's density scaling can work, and I am really happy with the result.  In fact, there was one tvdpi asset created for the open source platform in Jelly Bean, which is is the background of the notification tray.  And that asset also has different versions for different screen sizes, so it is not representative of a regular approach that applications will use.  Nearly everything else you see on the screen is done without a specific tvdpi asset, either scaling or using as-is the existing hdpi asset.
Shared publiclyView activity