/cc @crawshaw @hyangah

Are the actual device measurements you list the current drawable area? (That is, if you make the screen red, does the red area have those measurements?)

I don't know if it applies here, but there is a general problem with mobile devices that some scaling happens long after all of the drawing is done and the app is not informed (for example, the iPhone 6 Plus, with a 1.15 multiplier).

I'm not aware of that sort of scaling done on Android. The height reported is not the full pixel height of the device but that is normal on android as the system will subtract height of status bar and software device buttons (if they exist) before fulfilling a height request to an app.

The reported width on the other hand seemed enough to suggest there is an issue though. The device has precisely 720px width which is correct as reported but the pt value reported doesn't make sense.

I was going to dig into this eventually to implement density-independent-pixels and the first thing I'd like to check is pt value reported by the java api. At the very least, that result should match the gomobile result, even if incorrect.

I've also never worked with pt values outside of some graphic software so my expectations may simply be wrong as well.

For reference, there doesn't actually appear to be a java api to report screen dimensions in pt so I ran the following on device:

DisplayMetrics dm = new DisplayMetrics();
getWindowManager().getDefaultDisplay().getMetrics(dm);
Log.d("@@@", "width in px: " + dm.widthPixels);

for (float n = 162; n <= 180; n += 0.5) {
  float v = TypedValue.applyDimension(TypedValue.COMPLEX_UNIT_PT, n, dm);
  Log.d("@@@", n + "pt: " + v);
}

162pt is what's reported by gomobile. 180pt is what I'd expect for 72ppi. Here's the results of the for-loop:

width in px: 720
162.0pt: 663.6758
...
175.5pt: 718.9821
176.0pt: 721.0305
...
180.0pt: 737.41754

This only serves to confuse the matter as ppi appears not to be 72.

I created a layout as follows:

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="horizontal">

    <View
        android:layout_width="719px"
        android:layout_height="20dp"
        android:background="#ff0000" />
    <View
        android:layout_width="1px"
        android:layout_height="20dp"
        android:background="#0000ff" />

</LinearLayout>

This does what is expected, filling the entire width of the screen with a single pixel width blue line at the end. Here's a screenshot (I framed screenshot to make more apparent before cropping).

One other item of note, the "actual dimensions" I provided were derived from a tape measure. Using a ppi calculator suggests the actual dimensions are slightly smaller, 4.36" × 2.45" with a ppi of 293.72 PPI which matches the devices spec sheet of ~= 294 ppi.

Looked into this, issue is here: https://github.com/golang/mobile/blob/master/app/android.go#L220

Dividing the density by 72 isn't sufficient for determining PixelsPerPt, this would only give a very rough approximation that's not suitable for use.

There is a java api intended to provide this: http://developer.android.com/reference/android/util/DisplayMetrics.html#xdpi

I could not find anything in NDK for this. Regardless, at least five years ago the xdpi and ydpi were considered unreliable as hardware vendors shipped with incorrect values but no one notices since these values are not used anywhere in the system. So, while a jni binding to retrieve the value would fix this, it's not clear if its going to be reported correctly across all devices in use today.

The mobile/geom package sheds some light on the intention here but it looks to be impractical to provide actual typographical point values on android.

160dp is meant to equal sort-of-an-inch and should probably be the basis for what is provided in the size event on android (caveat emptor). This can be used to establish the PixelsPerPt in size.Event and the WidthPt and HeightPt can be filled appropriately.

The solution is not aggreable with being exact, but it doesn't appear exact is possible across all android devices unless positive evidence can be turned up regarding DisplayMetrics.xdpi and ydpi.

If this solution sounds ok, I can put something together.

/cc @nigeltao

every use of ppi in my last comment was meant to be PixelsPerPt (fixed), sorry for the confusion

Sounds OK, but I'd give @crawshaw the definitive say, since he wrote the original Go mobile code wrt Android DPI.

If you do put something together, please add a summary of your last (substantial) comment above as a comment in the code too. It might also help to link to whatever seems most definitive about "how to determine Android DPI in practice". A quick query to my favorite search engine turned up http://developer.android.com/guide/practices/screens_support.html#dips-pels but you might know of better resources.

It might also be nice to check in an example program, or modify the example/basic program, to draw a centered square that is 1 inch by 1 inch under the existing green triangle that follows touches. Maybe @crawshaw would have a better idea of a good DPI example.

The table here is a good example of how this works: https://www.google.com/design/spec/layout/units-measurements.html#units-measurements-density-independent-pixels-dp-

The footnote suggests a device with 1.5 inch width and doing the math for 160dp is an example of how you'd end up at exactly 1 inch. But, consider the same table for a device with 2 inch width and then you'd end up at 1.33 inches.

On my 2.45" width device I referenced in the original issue, a 1 inch square would be 1.225 inches as it falls into the 320 bucket density. A 2" width device with the same resolution would also fall into the 320 bucket density and a 1" square would actually be 1".

The density bucket is also apt to tampering by the hardware vendor.

So, for clarification, the gomobile example of drawing a 1" square wouldn't necessarily be 1" but it would look consistent across similar devices.

CL https://golang.org/cl/24865 mentions this issue.