0

Short version: Is there a method whereby Android Studio will correctly preview a 1.33 density display? Choosing the virtual device I have defined from the preview window's dropdown menu, a device which renders properly as 1.33 in the emulator, does not work.

I have a virtual device defined with a 1.33 density (by editing the device's config file since I have not found any other method) which works fine in the emulator. However, the xml preview window continues to render the screen as mdpi, meaning that a 100px wide and a 100dp wide object render at the same size which is wrong for 1.33 density and unhelpful for layouts.

The hardware profile in AVD reports mdpi rather than 213dpi for this device even though the emulator works properly.

Cloning any of the virtual Nexus/Pixel hardware with a density specified in dpi results in the cloned hardware having a density specified as mdpi, hdpi etc. rather than the expected dpi from the parent. The parents will render px and dp in preview properly so evidently Android Studio is capable of displaying resolutions in preview outside of the standard 0.75, 1.0, 1.5,... bins. However, a cloned 5X does not keep its parent's 420dpi density.

I found some old information that apparently worked several years ago but android studio no longer has the interface described and that I had to use a text editor to change the VM's density rather than the AVD manager does not bode well.

Smartybartfast
  • 161
  • 1
  • 6
  • Hi, I'm trying to do something very similar, but am getting no joy. When I try and run an emulator with a diff dpi, it actually runs at 160dpi, because it can only run at one of the enum/pre-set dpis. Are you sure you're managing to get it at different densities? – Russ Wheeler Nov 11 '17 at 22:33
  • @RussWheeler Absolutely sure or I wouldn't have said so. I use a simple layout of pairs of rectangles. In any art program I draw a 100 pixel wide rect, fill it blue and save it in res/drawable, then fill it red and save a renamed copy in res/drawable-nodpi, colour just for contrast. In Studio preview they are the same width *always*, hence my question. In emulator and hardware, the blue one is scaled by density. So, for mdpi with scale factor 1 blue and red are the same width but on the 213dpi scale the blue rectangle is 133 pixels wide, ie, 1.33 times wider. – Smartybartfast Nov 14 '17 at 02:55
  • For a 480px wide, 1.33 density display, 480 / 1.33 = 360. So a 360px wide bitmap will just fill the display (allowing 1 pixel for rounding) when scaled while the nodpi version is only 3/4 (ie, reciprocal of 1.33) as wide as the screen. I've never tried linking to an answer but hopefully this link to [my answer about choosing emulator dpi](https://stackoverflow.com/questions/43710392/how-to-create-an-avd-with-android-studio-to-preview-a-real-device/46871047#46871047) will work without editing. – Smartybartfast Nov 14 '17 at 03:02
  • Ok, I think I got the wrong idea of what you were trying to do. I was trying to create emulators with different DPI densities, not images with diff ones. Thanks for your answer – Russ Wheeler Nov 15 '17 at 11:41
  • @RussWheeler What I could do was make the emulator run at specific densities other that ldpi, mdpi etc. What I wanted was Studio to preview the screen at the correct density to match the emulator. My discussion about images was to illustrate that preview wasn't working as it should. – Smartybartfast Feb 02 '18 at 09:11
  • How did you get the emulator to run at specific densities? Because when I tried and logged out the values (from commands that I can't remember right now) they said it was always 160dpi if I hadn't chosen one of the bucket sizes. – Russ Wheeler Feb 02 '18 at 22:17
  • @RussWheeler To run emulator at specific densities please see my comment from November 14 2017 which has a link to my answer on how to do that. – Smartybartfast Feb 17 '18 at 03:24
  • I have read your answer but it sounds like you couldn't get it to work either. For example, can you get an emulator running at, say, 345dpi? – Russ Wheeler Feb 18 '18 at 10:37
  • @RussWheeler I've answered your question in a comment under the answer previously referenced because this discussion has drifted away from my question's topic. – Smartybartfast Feb 18 '18 at 14:23

0 Answers0