Need to get the correct DPI value on Android

[grisevg]

Hey guys,

Looks like there is a number of different ways to measure DPI on Android
Lime uses DisplayMetrics.xdpi , but a number of devices have this value completely wrong

For example Lint marks usage of "mm", "in" and other android metrics that rely on xdpi and ydpi with warnings - http://stackoverflow.com/questions/20631221/why-lint-shows-warning-when-using-in-inch-or-mm-millimeter-units-as-dimensio/22707894#22707894

For example my Nexus 4 gives xdpi of 160 instead of expected 320, but densityDPI gives correct value of 320. It looks like it's a Cyanogen mod bug, since the latest stock Lolipop Nexus 4 gives correct 320 in xdpi and ydpi. But what's important is that I have never noticed wrong sizing of UI on my nexus 4 in years, all because of the fact that all android UI sizing logic always relies on DisplayMetrics.densityDPI instead of xdpi/ydpi and only when I used DPI in Lime I've noticed that the value is wrong.

Here Google http://developer.android.com/guide/practices/screens_support.html recommends using "dp" units which are based on .densityDPI and .density and also shows code examples using .density.

To clarify why there are 2 different ways to access dpi -

• xdpi/ydpi gives exact DPI value of a device.
• density and densityDPI give a value of a nearest dpi bucket android os assigns a device to (120, 160, 240, 320, 480 or 640).

So if a device has DPI of 330, densityDPI would return 320. I haven't done much Android development, but I think that is intended behaviour, though I'm not fully sure why.

I propose to change a way Lime calculates DPI to a most commonly and widely used approach -DisplayMetrics.densityDPI.

Of course it's wrong to change usage of API just because some phones/roms give a bugged value, but it's also important to use API in the most common way.

What do you guys think?

[ilwsm]

How maximum different percent can be from DisplayMetrics.densityDPI and right DisplayMetrics.xdpi ?

[grisevg]

@FreakMurderer in theory - half of the bucket. Not sure what's the biggest one in practice.

PS: There are very few valid reasons to use xdpi/ydpi, one of them is virtual reality, for stuff like google cardboard. Another example would be making a ruler for real-life objects...

[jgranick]

Even with newer SDL release versions, I believe this is still unimplemented. I think we'll have to use JNI and get this value ourselves

http://stackoverflow.com/questions/3166501/getting-the-screen-density-programmatically-in-android

[benmerckx]

I can confirm the (sdl) value is incorrect on android...

[jgranick]

Sorry for circling back on such an old issue.

We started using JNI to calculate DPI on Android ourselves.

https://github.com/openfl/lime/blob/develop/templates/android/template/app/src/main/java/org/haxe/lime/GameActivity.java#L36-L47

lime.system.Display should have a dpi property that represents our best estimate of the real DPI of the device, openfl.system.Capabilities.screenDPI works more like the density mentioned in the original issue, where it averages to a close "DPI level" to use for sizing UI. We hope that both give developers the tools they need.

If you think we should modify our behavior for calculating Android DPI, open a pull request with a proposal 😄

Thanks everyone