Develop Reference

The issue about android density buckets

I learned that we should use "dp" to give our applications the ability of supporting multiple screens. But I find in reality, this works far from well.
Let me show you an example: Assume we have two screens. Screen A has a resolution of 160 * 160 px and 1 inch length and width. Screen B has a resolution of 1600 * 1600 px and 10 inches length and width. According to the definition of Density Buckets, both of the two screens fall into mdpi(medium)~160dpi. So both of the phones using these screens will use the same layouts and drawables. However, we know that 1 dp could be converted to 1px in the case of 160dpi. So this means screen A is 160dp in width and screen B is 1600dp in width. And if we try to show an image which is set to 300 dp in width in the screen, the result is for sure very different. So I am wondering how come android rely on dp to support multiple screens or If I have some misunderstandings about this concept?

Get size of the Android Phone

I would like to get size of the Android Phone but size in mm and not in pixels.
I know how to get size in pixels, however I would like to do some RND and for that I want to get width of the screen in mm.
Like here Galaxy S4 size is Dimensions 136.6 x 69.8 x 7.9 mm (5.38 x 2.75 x 0.31 in)
136.6 x 69.8 x 7.9 mm (5.38 x 2.75 x 0.31 in)
^^^
Does any one knows what is this size for?
Though I am iPhone developer BUT I am beginner (1 day baby) for Android. Well below is what I want to do as RND.
Let's say designer gives me design for the app of size 1080*1920 and have title of size 30px (which covers 80% exactly) of the screen size.
That means 10% space on left side, 80% text and 10% space on right side.
I know in Android we have something called sp or android:textAppearance="#android:style/TextAppearance.Large", but that won't give the 10% spaces.
What I want to achieve is regardless of size, design should go same.
Considering design to fit with width, if height increases, I would have scrollview and I am okay with that.

"Pixel density" is the number of pixels per inch. So dpi gives you the scale factor you need so that the number of pixels is consistent across devices.
Another way of saying this is that if you have a 480 pixel screen with hdpi, then a 360 pixel screen at mdpi is about the same physical size. While the screen sizes may vary some, it generally is not that important. Even so, as mentioned, see this post about doing the actual calculation:
Is there a way to determine android physical screen height in cm or inches?
However, you are talking about percentages of screen size in your example. If you know the screen size in pixels, then the physical size doesn't matter, just do your calculations using pixels. If you have 480 pixels, 10% is 48.
You cannot do this in XML, which it sounds like you might be wanting to do. You can use "weighted linear layouts" for runtime calculations of the screen size. You can also use different res folders depending on screen size (like res/layout-hdpi).
You may want to read this from Google regarding supporting different screen sizes: http://developer.android.com/guide/practices/screens_support.html

Use DisplayMetrics. The API is: http://developer.android.com/reference/android/util/DisplayMetrics.html
You can perform a calculation on the given fields and obtain the height and width in inches, then convert that to mm.

Android DPI independence on devices with same the resolution

I Have a few general questions about Android screen / DPI / resolution indepence.
Basically, I am taking specifically about sprite-based apps, like ones based on Surfaceview for example.
Every guide I've read (including the official one) says that you should only work with the DPI and not the resolution.
However, what happens when two devices have different DPI's/screen size but the same resolution? Take the Galaxy tab 10.1 (1280 x 800 - DPI aprox 150) and the Galaxy Note (1280 x 800 aprox 285 DPI I think??)
When displaying a sprite of say 50 x 50 on each of these, it will appear to be the same size relative to the screen size. However, if Android grabs a difference size sprite because it detects a different DPI (ie, from LDPI, HDPI etc), then the sprite will appear to be bigger on the Note relative to the screen size than it would on the Tab.
Can anyone please set me straight on this as I just cannot work it out!! Thanks all.

A 50 x 50 sprite on a 150dpi screen will appear much larger than a 50 x 50 sprite on a 285dpi screen. Android's resource resolution algorithm is intended to allow you to define a larger (in pixels) image for use on higher density screens.
If you want the sprite to be the same size relative to the screen regardless of the pixel density, then you can put the images in the drawable-nodpi folder and they won't be scaled by the system. You can even decide which size image to use in code after querying the screen size. (As of 3.2, you can have resource folders that depend on screen pixel size, but I think they will still scale with dpi.)
Screen resolution refers to the screen dimension in pixels. Pixel density refers to how many pixels it takes to fill an inch of screen.

Android Tablet Dimensions

We have just started Android Tablet development. I need to prototype for 7in and 10in tablets.
Is there any wireframe stencil i can get hold of ?
What are the dimensions of the canvas i need to start designing on ?

Just like phones, tablets have all sorts of dimensions and sizes.
Here is a quick list of different models with their respective sizes and dimensions:
Samsung Galaxy Tab 10.1 3G - 10.1 inches, 1280 x 800 pixels
Samsung P1000 Galaxy Tab - 7.0 inches, 600 x 1024 pixels
Dell Streak 7 - 7-inch 800×480
Motorola Xoom - 10.1-inch, 1280×800
Viewsonic G - 10.1-inchs 1024×600
These are the dimensions you'll find most often.

Rather than considering actual pixel dimensions (which can vary in size depending on pixel density), it might be easier to think in density independent pixels (dp). This is the smallest device width as given in the configuration examples from the docs:
7” tablet: 600dp
10” tablet: 720dp
Notes
For actual pixels size, multiply by 1 to get mdpi, multiple by 2 to get xhdpi, by 3 to get xxhdpi, etc. See here for more.
To provide different resources for the various screen sizes, see this answer.

Old topic but i think i've got a good way to resolve your probleme. If it can help some..
First of all, if you do right, All your activities should be composed ONLY with fragments.
You may know that when a screenSize is defined as exemple by 384* 640, that means your maxWidth is 384dp and your maxHeight is 640dp.
And so, it's easy to determine how height you should use without trying on emulator.
Still using my screenSize exemple : 384 (Widht) * 640 (Height) :
640dp
292dp
264dp '
<dimen name="max_height">640dp</dimen> <!-- screen maxHeight -->
<dimen name="half_height">292dp</dimen> <!-- ScreenMaxHeight with actionBar -->
<dimen name="half_height_bigactionbar">264dp</dimen> <!-- height without actionBar and its subActionBar -->
Down here, this is my fragment size :
<fragment
android:layout_width="match_parent"
android:layout_height="#dimen/half_height_bigactionbar"
Both of my fragmennts should now fill all the sreen
My action bar height is 56dp . If you do the map if i want he half of my screen i do ((maxScreenHeight) - (ToolBarSize) ) / 2.
I got ((640) - (56)) / 2 = 292dp !
Do the same for All of resolution you might know with all the window part you may use:
And you will have THE perfect match in every phone you know.
You can do the same math for width if you use tablet.
But remember, use as much as possible wrap_content + marginLeft and MarginRight to place your components !
When you wana create an activity. Draw it in a sheetwith small-paned . And think only with percent. Then do the math, and use ONLY fragments.
You should be fine then :). Ask if i wasn't clear enought !

Understanding Samsung Galaxy Tab screen density

One would say that if the Galaxy Tab screen resolution (in portrait mode) is 600px and the screen width is 3.55inch, the screen density would be 600/3.55 = 169 dpi. Knowing that and keeping in mind the way the device independent pixels (dp) is computed (http://developer.android.com/guide/practices/screens_support.html):
px = dp * (dpi / 160);
600 = dp * (169 / 160);
dip = 568
So drawing a horizontal line of 568dp (device independent pixels) width starting at position 0 must exactly match the width of the screen. But if you try this on device you will find that the screen width is 400dp. I will use the same formula again but for getting dpi:
600 = 400 * (dpi / 160);
dpi = 240
So having the 240dpi, 3.55inch screen width and 600pixels, does it mean that one physical pixel is composed of more ‘dots’ otherwise the parameters corresponds to the width of 852pixel (3.55*240).
I thought that dpi means dots per inch, which is pixels per inch. But this seems to not be true...
Added later:
This (http://developer.android.com/guide/topics/resources/more-resources.html#Dimension) says:
160dp is always one inch regardless of the screen density
Which is not true. Just check the measurement source from this:
Difference between android dimension: pt and dp
Added even later:
The reason I am asking is that violating the rule that 160dp = 1inch leads to the fact that when specifying the control width to e.g. 320dp it will cover on Galaxy Tab much bigger portion that that really necessary and much bigger then what you would expect from 600x1024px screen...
Thanks for clarification
BR
STeN

Galaxy Tab (7") doesn't report its real density. To understand this issue, read the following article:
http://realmike.org/blog/2010/12/21/multiple-screen-sizes-with-processing-for-android/
Apparently, that’s also what Samsung found when they made the Galaxy
Tab. The Galaxy Tab has a 7″, 1024×600 screen with 170 dpi. Yet, the
Tab does not report its density as “mdpi” but as “hdpi”, so the layout
looks exactly as in the second screenshot. If they used “mdpi”, the
icons would be .28″ wide, with “hdpi”, they are .42″ wide—not a big
deal, and I must admit, the layout does look prettier this way.
The article contains some images that will make you understand the problem.