New screen dimension & pixel APIs reporting wrong values on Droid Razr

Solar2D Android
#21

I did a quick stackoverflow search and discovered that other native Android developers are running into this issue too.  It’s too bad that you can’t always rely on this API.

The only possible work-around that I can think of on our end is to validate the received DPI by comparing it against its assigned mdpi, hdpi, or xhdpi density, which are hardcoded in Android to about ~160dpi, ~240dpi, and ~320dpi respectively.  If the manufacturer assigned DPI is too far off, then I’ll have to use the mdpi, hdpi, or xhdpi values instead.  It would be less accurate, but hopefully closer to the actual screen DPI.

Our main intent with providing the app window’s physical size in inches was so that you can determine at runtime if the display was big enough to show a tablet-sized or phone-sized user interface.  Like what iOS developers do between iPhone and iPad.  Hopefully these values are close enough to the physical size that you can still achieve this.

Anyways, that’s my 2 cents.  I hope this helps.

#22

Hi Joshua, 

Thanks for looking into this. Did you see any other devices mentioned with similar errors? I would search myself but I don’t know the native api name you use on the native Android code side.

Anyways, your validation approach sounds like a good idea. Do we currently have a way to read the assigned mdpi, hdpi, or xhdpi densities, which are hardcoded in Android that you mention above?

I understand that the thinking behind this new API was to detect device type more than anything else but they are invaluable to us in building standard sized interfaces across devices. I am developing a business app where I want to be able to control the size of interface elements. 

Look at App Store or the iTunes apps on your iPhone 4 , iPhone 5 and iPad side by side for example. The tab bar is the same height. So is the Title bar. The buttons, everything about same size. This then creates so much usable space in the middle for content. This is what I am able to achieve once I can detect the physical size and pixel count. 

I will post my device detection library in due course once its perfected. In the meanwhile, please don’t give up on these new and wonderful API calls for Android screen size and resolution detection. Thank you very much!!! 

Regards,

Kerem

#23

Hi Joshua, 

Just woke up and read my regular dose of “Daily Builds Release Notes”… If my eyes are not deceiving me, it appears that you have done something to help me… in record time… 

1127 Release Notes say : 

Android: Added property system.getInfo(“androidDisplayDensityName”) which returns a density name such as “xhdpi”, “hdpi”, “mdpi”, etc.

Android: Added property system.getInfo(“androidDisplayApproximateDpi”) which fetches the DPI based on the density name such as “mdpi”, “hdpi”, or “xhdpi”.

This is AMAZING!!! Thank you very much! I will now incorporate these new API calls into my little devicedetection app to see if I can spot bad manufacturer data on a regular basis. 

Have a great weekend.

#24

Yeah, I had a little extra time yesterday, so I snuck these changes in.   :slight_smile:

You can find documentation for these new system properties here…

   http://docs.coronalabs.com/daily/api/library/system/getInfo.html#androiddisplayapproximatedpi

The “androidDisplayApproximateDpi” is taken from Android’s “DisplayMetrics.densityDpi” field, which every Android device has to get right or else there would be obvious display/scaling problems.  So, it should be a very reliable API, with the disadvantage being it is less accurate.

   http://developer.android.com/reference/android/util/DisplayMetrics.html#densityDpi

I have another tip that might help you out.  If you call display.newText() with zero as the font size, then Corona will use the operating system’s default font size.  Now what’s interesting about this is that the default font size is radically different between different Android devices, but they’re physical size (in inches) on screen is about the same between all devices.  This includes tablets and phones.  So, this may prove useful to you since you don’t want your UI to look scaled.  There are only 2 caveats with this approach:

  1. Using a font size of zero will cause Corona to log a warning, but you can safely ignore it.

  2. You should only use the system’s default font size if you are *not* using Corona dynamic content scaling feature.  Otherwise you text will scale randomly between different devices.

That said, I’m glad I could help you out!

#25

Joshua, thank you very much for this quick turnaround and additional information. I had already discovered the new API documentation but what you share above is priceless!!! Thank you so much. 

You know exactly where I have been struggling. Scaling interface elements which we draw isn’t that hard but scaling the fonts to go along with them is proving quite hard. The issue is that when I change the fontSize in a proportional manner it does not necessarily mean displayed font size change will be proportional. I will try the fontSize = 0 option and see how this works out. 

Once again, many thanks. I am sure all this will help a lot of us who are looking to get consistent interface element sizing across devices.

#26

Another device with wrong values embedded in by the manufacturer… 

Model : SGH-T989

Display Width (Inches) : 2.9921260142101

Display Height (Inches) : 5

Display Diagonal (Inches) : 5.8269046744316

X DPI : 160.42105102539

Y DPI : 160

I didn’t have a chance to incorporate the new dpi validation API into my little utility app but this Samsung Galaxy SII seems to be reporting 160 DPI anyways so this would probably slide through the validation. 

Seems like the  system.getInfo( “androidDisplayWidthInInches” ) and system.getInfo( “androidDisplayHeightInInches” ) API calls will be highly unreliable due to wrong data embedded into the device by its manufacturer… Too bad. 

#27

Hmm… this is really disappointing.  We might have to document a warning about the returned DPI if this continues.  Thank you for posting your findings.

Now, I’m positive that the values returned by display.pixelWidth and display.pixelHeight are correct.  So, you can use those properties in conjunction with our new “androidDisplayApproximateDpi” to calculate the width and height of the app in inches if you want.  One thing to watch out for though is that display.pixelWidth and display.pixelHeight are relative to a portrait orientation.  That is, the width and height do not swap when your app is landscape.

#28

Hi Joshua, 

I agree its disappointing. However, all is not lost.

As long as there is a value in there I think we can work with it. If we have a simple app like the one that emails results to a person who keeps a simple db of reported values vs actual dimensions, accurate ppi etc then we could build in simple correction factors into our apps. I know this is a long reach but there are only so many Android devices and I’d like to think this issue can’t be affecting them all. We are a huge body of developers using the Corona SDK so if we all work together I see no reason why we can’t collect this data. Anyways, thats the idealistic thought. 

The more realistic thought is this… We use all info we have and yet if somehow the screen dimensions are not looking right to the user we can put in a small routine in there asking the user to measure the screen height & width using a simple ruler and enter it into the app. The app then calculates the correction factor between what it gets from Android and what the user entered in. Then we should be able to display objects at the size they need to be displayed. I think I can pull this off. 

Hope I’m making some sense here. Thanks for all your support. 

Regards,

Kerem

#29

Hmmm… I was doing some more investigation on the Android device display specs and half hoping someone might have done what I was thinking of… Indeed someone has… See below : 

http://opensignal.com/reports/fragmentation.php

I think I’m going to give up on this pipe dream of consistent sized objects on Android screens. I’ll leave you with the image from link above : 

device-model.jpg

#30

And this is why developing for Android is so challenging.  :)

I still think there is some hope though.  Most native Android apps size their GUI based on the density, such as “hdpi” and “xhdpi”. This includes the operating system’s main UI and image resources.  Google defines standard sizes for app icons, notification icons, toolbar icons, etc… and if you follow their guidelines and load images based on the density, then at least your UI size would be consistent with every other app on the same Android device, and that is what matters most.

What might help you is to have a look at Android’s images that it uses for its GUI.  These images are included with the Android SDK and you’ll notice that they have different sized images for different densities.  So, you can try to size your UI images to match their sizes.  You can find the Android SDK’s images in the following location…

   ./android-sdk/platforms/android-<version>/data/res/drawable-*

Hopefully this helps you out.

#31

Hi Joshua,

Thanks for your continued support. I am working on some additional features on IOS side so the Android issue is somewhat academic for me for now but will dive into this almost full time next week. I should be able to make use of all the info you gave me and find a workable solution. Whatever the outcome, I will share here. 

Meanwhile, here’s an interesting idea for you to consider and possibly float with the CL decision makers. Unless its turned off, Corona Analytics collect info from each device where a Corona SDK App is running. This currently includes device type, model, OS version etc. How about adding the screen related data to the list of stuff collected on Android devices? Over time CL would build a massive collection of data on screen sizes, densities etc much like the example above from opensignal. We could then all make use of this data in our apps. Just a thought. 

Regards,

Kerem

#32

I think the only problem with this is that we can’t actually retrieve the screen size.  Only the app window’s size in pixels.  This might lead to some confusion or others challenging our collected data.

Perhaps a more useful feature would be to let Corona developers post whatever data that they want.  As much as I’d like you to keep using Corona’s analytics system, I know that Flurry is capable of doing this now via the analytics.logEvent() function.

   http://docs.coronalabs.com/api/library/analytics/logEvent.html

#33

Yup. I am able to collect the data via your new API calls :) and pipe them into my app’s Flurry db so over time I can collect data and make sense of it for myself. If each CL developer does this individually it will take so long for each individual to collect enough data to make a difference.

If CL does it centrally then I think we would get the critical mass of data collected sooner. That was my thinking behind suggesting perhaps CL consider adding these data points to the analytics. Perhaps you could offer it as a best effort, no assurance data. Anyways, I realize how tough it is to make such changes on the fly. Perhaps something to consider for future. Thanks.

#34

Joshua,

OpenSignal updated their amazing report with this years data. See it at http://opensignal.com/reports/fragmentation-2013/

Good news is that this year they have chosen to share their source data. I can’t help but wonder how we can benefit from having access to this impressive database of devices and their screen specifications. There has to be a way to make this work for us. Thoughts?

Thanks & best regards,

Kerem

#35

I think the most valuable information here is recognizing what are the most popular Android device models in use.  These are the devices that should be bought for testing and to ensure that our software (your app) works well on them.  If you can support the majority, then you’re in good shape.  From an app developer standpoint, if you run into some obscure/unpopular device that your app doesn’t work correctly on, then it may be more economical to just drop support for such a device by unchecking it in Google Play.  It’s about valuing your time and putting time/resources into things that can serve the vast majority of your customers.  In any case, that’s my 2 cents.

From a native development standpoint, this information is helpful in knowing what percentage of OS versions are out there and what is the oldest version that we should pour time and resources into.  Corona still supports Android 2.2 and we’ll likely continue to do so.  While this information shows that 2.2 is a small 1 digit percentage, I was told verbally by Barnes & Noble that their 2.2 Nook Color was still a very popular device.  Just an interesting perspective if Nook development ever interests you.

#36

A very valid and balanced viewpoint. I truly don’t think I need to support all 11000+ different screen sizes/resolutions. I think targeting the majority is a sensible approach. 

Nook… If they are still around in 6 months… wait thats another thread so lets not go off-topic…  :wink:

Keep well.

#37

Actually, I’m interested to know how many xxhdpi devices are in active use.  There’s actually very little information about that resolution.  We’ll likely have to add support for it in the near future.

#38

Joshua,

OpenSignal updated their amazing report with this years data. See it at http://opensignal.com/reports/fragmentation-2013/

Good news is that this year they have chosen to share their source data. I can’t help but wonder how we can benefit from having access to this impressive database of devices and their screen specifications. There has to be a way to make this work for us. Thoughts?

Thanks & best regards,

Kerem

#39

I think the most valuable information here is recognizing what are the most popular Android device models in use.  These are the devices that should be bought for testing and to ensure that our software (your app) works well on them.  If you can support the majority, then you’re in good shape.  From an app developer standpoint, if you run into some obscure/unpopular device that your app doesn’t work correctly on, then it may be more economical to just drop support for such a device by unchecking it in Google Play.  It’s about valuing your time and putting time/resources into things that can serve the vast majority of your customers.  In any case, that’s my 2 cents.

From a native development standpoint, this information is helpful in knowing what percentage of OS versions are out there and what is the oldest version that we should pour time and resources into.  Corona still supports Android 2.2 and we’ll likely continue to do so.  While this information shows that 2.2 is a small 1 digit percentage, I was told verbally by Barnes & Noble that their 2.2 Nook Color was still a very popular device.  Just an interesting perspective if Nook development ever interests you.

#40

A very valid and balanced viewpoint. I truly don’t think I need to support all 11000+ different screen sizes/resolutions. I think targeting the majority is a sensible approach. 

Nook… If they are still around in 6 months… wait thats another thread so lets not go off-topic…  :wink:

Keep well.