2

I am encounter more and more android devices with irregular layouts, especially in the HDPI section.

The problem is that my more complex layouts do not scale correctly even though I only use DIP values in my xml layouts. Animations are particularly problematic since I use float values within the TransformAnimation code.

For instance, I will have a 240dpi phone with a 3.7 inch screen, with android standard resolutions. I can make HDPI and large layouts for this device and have them fit all designs and aesthetics perfectly.

Then I have a phone with a 4.2inch, but its vertical resolution is still less than XHDPI or XLARGE. If you ask the device what its DPI is, it will report 240dpi as well. Unfortunately due to the actually different aspect ratio, actually different screen size and actually different resolution, my layouts do not scale correctly. There is also no way to make a separate layout folder because the device THINKS it is a layout-large and hdpi, because it simply reports it wrong. (Both EVOs, several other "long" phones) Reading the android documentation it seems like you could use layout-long-large and some other kind of combination, but the phone itself still thinks it is only layout large. the long qualifier does work in devices that report proper information about itself.

How do people deal with this with the Android framework, without doing it in code. That would be a very tedious work around for me, and I have questions about how dynamically I could do that if the hardware reports all information about itself incorrectly.

Insight appreciated.

CQM
  • 42,592
  • 75
  • 224
  • 366

3 Answers3

1

What is your target framework? The device won't report itself as xhdpi unless the API target is 9 or above, I think.

ShibbyUK
  • 1,501
  • 9
  • 12
  • 1
    I tried upping to API target 10 in the manifest, no effect in the reporting change. xlarge screens are at least 960dp x 720dp. This phone (both EVO 4g, Evo 3d, others) is 960 x 540 dp. It is a 4+ inch screen yet reports as 240dpi using the `getResources().getDisplayMetrics().densityDpi` function, therefore it responds to layout-large and drawable-hdpi, when it is clearly different. The Google T-Mobile G2 is a 3.7 inch 240dpi screen, 800x480 screen, which responds to layout-large and drawable-hdpi. Hardcoding resolutions is bad because it is likely that another nonstandard device will come out – CQM Oct 25 '11 at 17:26
0

One way to address this, is everytime the app starts it sends its useragent to server. The server then determines the correct image to use, and send that info to client that uses it to display the that image. This has been the case in other mobile platforms and though Android addresses it you seem to have problems with it. Ttry this out.

Also have you considered using 9-path images?

omermuhammed
  • 7,365
  • 4
  • 27
  • 40
0

My solution to this problem is to rely on RelativeLayout's positioning more and more.

CQM
  • 42,592
  • 75
  • 224
  • 366