Here is for convenience: https://gyazo.com/695dea42c3667aea2cbba9ee8ced928f
There is an emulator with a screen resolution of 1080x1920, 5.5 inches, which means a pixel density of 400. I added an image 1080 pixels wide to the folder and an android when loading an image into a bitmap reduced the width to 900 pixels.
Here are the parameters of the screen that are issued at runtime:

DisplayMetrics metrics = getResources().getDisplayMetrics(); System.out.println("РаЗМЕР" + metrics);

Options

  DisplayMetrics{density=2.5, width=1080, height=1800, scaledDensity=2.5, xdpi=400.0, ydpi=400.0}

Why is density 2.5 instead of 3 for xxhdpi (density from 400 to 560 pixels per inch) We take 1080 divided by 3, and we get an image size of Mdpi 1080/3 = 360. The scaling factor is 2.5 (for some reason). Multiply: 2.5 * 360 = 900. It becomes clear why the image shrank. Although the Phone screen has a resolution of 1920x1080 and a diagonal of 5.5 instead of a scaling factor of 3, android uses 2.5. Question: Why?
Announced and initialized

 Bitmap field; field = BitmapFactory.decodeResource(getResources(),R.drawable.gamefield); System.out.println("ширина "+field.getWidth());

image size becomes smaller than what is in the drawble-xxhdpi folder

  • one
    Not exactly the topic, but height=1800 is due to the fact that you get the height of the screen without taking into account the status bar, and, like, without taking into account the action bar. - post_zeew
  • Honestly, I read it three times, and I didn’t understand how this “Android decided to increase the width”? And in which folder is the image added? How is it displayed? - Eugene Krivenja
  • I made a mistake, twice, in the first night I saw 1080 in the figure of 1800, so I would understand that it is possible for the status of bars to be. And secondly, I added to the drawble folder, without the -xxhdpi add-on, but the default drawble folder is read as mdpi by default, which is why it stretched my image two and a half times. Now, when the problem was sorted out, it was formulated differently, I amended the question - Turalllb

1 answer 1

For the value of density = 1, the screen size is 160dpi. Your screen size is 400dpi. Accordingly, we obtain: 400/160 = 2.5 . At the same time, this parameter is calculated from the value of the current pixel density of the device and is in no way connected with such concepts as the XXHDPI screen.

By itself, loading an image into a Bitmap should not result in a resized image in pixels, so the following should be considered:

The / drawable folder is not readable by default, like -mdpi - the resources of this folder are taken "by default" when there is no more exact match of the current screen with any qualifier.

Further, on your screenshot, the coefficients of the proportional increase in the size of the image by the programmer are indicated, for the most acceptable display on screens with a certain density, and not the coefficients of magnification by the device. That is, if the image for the MDPI screen has a size of 100x100 pixels, then in order for it to look the same (approximately) on the XXHDPI screen, then a similar image should be placed in the / drawable-xxhdpi folder, but 300x300 pixels in size. This is what this table means.

The images in the resource folders do not scale to the density assigned by the qualifier. That is, the image from the folder with the -xxhdpi qualifier does not increase by 3 times, but on the contrary, the image in such a folder should be three times larger than in the -mdpi folder initially (when preparing resources) - this work is done by the programmer, not the system .

In any case, no matter what size your images are, they will not scale from the placement of qualifiers in folders and will be displayed "as is". The only function of the qualifier is to indicate to the system that if the density is, for example, 400dpi, then take a picture from the folder with the qualifier -xxhdpi , if it exists (and not increase it 2.5, 3 or how many times). If there is no suitable qualifier, then from the / drawable folder. At the same time, if you put identical images into folders (by size in pixels), then they will look the same on the same screen.

Problems of non-compliance are related to the markup, which scales the original image to the size of the widget on the screen, the scaling parameters set for this widget and the actual size of the working screen (which does not take into account the space occupied by the navigation bar for phones without mechanical buttons, status bar and action bar) but in no way with qualifiers.

Dimensional problems - the result of fitting the image to the current screen so that it enters the entire space allocated to the widget while maintaining the proportions of this widget (since the height of the widget is less than the height of the entire screen and the image has a height equal to the height of the screen, decreasing the height also leads to a reduction in width to maintain the proportions). That is, you are trying to place a 1080x1920 image in a widget with a size of 1080x1800 (minus the status bar, navigation bar and action bar). Further actions of the system on placing this image will depend on the scale parameter in the widget (fit, center, crop, etc.) - by default the image will be tailored to the smaller side to enter the widget as a whole and proportions will decrease and the larger side will result in a final image 1012x1800 pixels. Using other parameters of the scale attribute, you can get other ways to "fit" the image into the widget.

PS: If you expect to somehow get an exact match for the pixels of the image with screens of various devices, then this is a hopeless task and you will definitely fail, for a maximum of one specific device with a certain set of parameters. On the other device, with minor differences in the parameters of the screen, nothing will fit.

More information about the work of qualifiers, see this answer

  • Ooh, smart answer. The problem was that I seemed to understand everything correctly, working with folders for graphics and that I had to scale myself, not the system. As a result, my image is compressed and I have sinned not correctly working with these folders, although the fact is that the markup somehow affects. Why markup affects I have not yet understood. Since there is a free black space on the screen where the image could have been contained, if not compression. - Turalllb
  • Yes, interesting is the fact that the images are scaled with such regularity. If deinsity = 2.5. And an image with a width of 1080 lies in the xxhdpi folder, then when loading into a bitmap, you get 1080 * 2.5 / 3 = 900. As if 1080 is reduced to 3, adjusted to the size, which should be in mdpi and increase 2.5 times and get 900. Coincidence is possible. And maybe I do not understand the difference between density and scaledDensity, do not tell me what? - Turalllb
  • What exactly and how you do with the image, add the code to the question - pavlofff
  • Added code, like markup nothing to do with. In the markup there is match_parent and on some devices where deinsty = 3, the markup does not limit, and on the device with deinsty 2.5 there are black unfinished edges in the markup - Turalllb
  • Maybe you are mistaken and the images are still scaled? Just select the closest density folder and scale. - Turalllb