DisplayMetrics

Intermediate density for screens that sit somewhere between DENSITY_XHIGH (320 dpi) and DENSITY_XXHIGH (480 dpi). This is not a density that applications should target, instead relying on the system to scale their DENSITY_XXHIGH assets for them.

Intermediate density for screens that sit somewhere between DENSITY_XXHIGH (480 dpi) and DENSITY_XXXHIGH (640 dpi). This is not a density that applications should target, instead relying on the system to scale their DENSITY_XXXHIGH assets for them.

The reference density used throughout the system.

Standard quantized DPI for high-density screens.

Standard quantized DPI for low-density screens.

Standard quantized DPI for medium-density screens.

This is a secondary density, added for some common screen configurations. It is recommended that applications not generally target this as a first class density -- that is, don't supply specific graphics for this density, instead allow the platform to scale from other densities (typically DENSITY_HIGH) as appropriate. In most cases (such as using bitmaps in Drawable) the platform can perform this scaling at load time, so the only cost is some slight startup runtime overhead.

This density was original introduced to correspond with a 720p TV screen: the density for 1080p televisions is DENSITY_XHIGH, and the value here provides the same UI size for a TV running at 720p. It has also found use in 7" tablets, when these devices have 1280x720 displays.

Standard quantized DPI for extra-high-density screens.

Standard quantized DPI for extra-extra-high-density screens.

Standard quantized DPI for extra-extra-extra-high-density screens. Applications should not generally worry about this density; relying on XHIGH graphics being scaled up to it should be sufficient for almost all cases. A typical use of this density would be 4K television screens -- 3840x2160, which is 2x a traditional HD 1920x1080 screen which runs at DENSITY_XHIGH.

The logical density of the display. This is a scaling factor for the Density Independent Pixel unit, where one DIP is one pixel on an approximately 160 dpi screen (for example a 240x320, 1.5"x2" screen), providing the baseline of the system's display. Thus on a 160dpi screen this density value will be 1; on a 120 dpi screen it would be .75; etc.

This value does not exactly follow the real screen size (as given by xdpi and ydpi, but rather is used to scale the size of the overall UI in steps based on gross changes in the display dpi. For example, a 240x320 screen will have a density of 1 even if its width is 1.8", 1.3", etc. However, if the screen resolution is increased to 320x480 but the screen size remained 1.5"x2" then the density would be increased (probably to 1.5).

The screen density expressed as dots-per-inch. May be either DENSITY_LOW, DENSITY_MEDIUM, or DENSITY_HIGH.

The absolute height of the display in pixels.

A scaling factor for fonts displayed on the display. This is the same as density, except that it may be adjusted in smaller increments at runtime based on a user preference for the font size.

The absolute width of the display in pixels.

The exact physical pixels per inch of the screen in the X dimension.

The exact physical pixels per inch of the screen in the Y dimension.

Compares this instance with the specified object and indicates if they are equal. In order to be equal, o must represent the same object as this instance using a class-specific comparison. The general contract is that this comparison should be reflexive, symmetric, and transitive. Also, no object reference other than null is equal to null.

The default implementation returns true only if this == o. See Writing a correct equals method if you intend implementing your own equals method.

The general contract for the equals and hashCode() methods is that if equals returns true for any two objects, then hashCode() must return the same value for these objects. This means that subclasses of Object usually override either both methods or neither of them.

Returns true if these display metrics equal the other display metrics.

Returns an integer hash code for this object. By contract, any two objects for which equals(Object) returns true must return the same hash code value. This means that subclasses of Object usually override both methods or neither method.

Note that hash values must not change over time unless information used in equals comparisons also changes.

See Writing a correct hashCode method if you intend implementing your own hashCode method.

Returns a string containing a concise, human-readable description of this object. Subclasses are encouraged to override this method and provide an implementation that takes into account the object's type and data. The default implementation is equivalent to the following expression:

   getClass().getName() + '@' + Integer.toHexString(hashCode())

See Writing a useful toString method if you intend implementing your own toString method.