Android screen adaptation

Android screen adaptation

Official address: http://developer.android.com/guide/practices/screens_support.html

I. Recommendations on layout adaptation

1, do not use absolute Layout 2, try to use match_parent instead of fill_parent. 3, can use the weight of the place as far as possible the use of weight (android:layout_weight) 4, if it is a solid color background, as far as possible using the shape of Android custom. 5. If you need to fit at a specific resolution, you can create a new Layout-hxw.xml folder on the Res directory. For example, to fit the 1080*1800 screen (Meizu MX3 with this resolution), create a new Layout-1800x1080.xml folder and define the layout below. The Android system will first look for layouts with the same resolution and, if they don't exist, use the default layout under layouts.

Ii. Terminology and concepts

Four Screen size categories:: Small, normal, large, and XLarge

Four density classifications: ldpi (Low), MDPI (Medium), hdpi (High), and xhdpi (extra high)

It is important to note that XHDPI is the only category that has been added since Android 2.2 (API level 8).

XLarge is the category that was added from Android 2.3 (API level 9).

DPI is the abbreviation for "dot per inch" and the number of pixels per inch.

General screen: LDPI is 120,mdpi is 160,hdpi is 240,xhdpi is 320.

Third, how to achieve adaptive screen size?

1) Interface layout aspect

It is necessary to prepare 5 sets of layouts according to the size of the physical size, layout (put some common layout XML files, such as the top and bottom layouts in the interface, will not change with the screen size, like the title bar of the WinDOS window), Layout-small ( Screen size less than 3 inches in layout), layout-normal (screen size less than 4.5 inches or so), Layout-large (4 inches-7 inches), Layout-xlarge (7-10 inches)

2) Picture Resources

5 sets of picture resources need to be prepared according to the DPI value, drawable,drawalbe-ldpi,drawable-mdpi,drawable-hdpi,drawable-xhdpi

Android has an automatic matching mechanism to select the corresponding layout and picture resources

Four, two ways to obtain screen resolution information:

Displaymetrics metrics = new Displaymetrics (); Display display = Activity.getwindowmanager (). Getdefaultdisplay (); Display.getmetrics (metrics); The pixel value obtained here is the device independent pixel DP

Displaymetrics metrics=activity.getresources (). Getdisplaymetrics (); The parameter information obtained is incorrect and should not be used in this way. You cannot use Android.content.res.Resources.getSystem (). Getdisplaymetrics (). This gets the width and height is empty.

V. About picture Making

1) about the design: Design plan first set a size to design, and as far as possible in the current most popular screen size (such as the current proportion of the screen is more than the 480 series, that is, 480*800 or 400*854, the following icon production on the basis of the proportion of the conversion) on the design. First look at the level of the screen:

Screen level	Screen density	Ratio (relative)		Physical Size (inches)	Pixel size	The usual resolution
ldpi	120	3	0.75	1	120
mdpi	160	4	1	1	160	320*480
hdpi	240	6	1.5	1	240	480*800
xhdpi	320	8	2	1	320	720*1280
xxhdpi	480	12	3	1	480	1080*1800

Description: Screen level: Note that the screen level is graded by density, not related to pixels. If density and pixels are not to be related, a frame of reference is required, and Android uses the MDPI level as the standard reference screen, which means that the cell at 320*480 resolution has a density that can hold one pixel. The other density levels are then compared on this basis. If ideally, the 480*800 screen can accommodate a density of 1.5 pixels. Physical size: in inches instead of pixels, it's said that an inch is the same size in any resolution, but the actual size of the pixels in a cell phone with different densities is not the same (which is why Android phones need to be adapted). And that's the point. Assuming that 1 pixels show 1 inches at 160 density, 1 pixels will show about 240 inches on a 0.67 density basis and 320 inches at 0.5 density. So there is a situation, a pixel on the computer, on different phones to see the actual size is not the same. So how do you make the "design effect" look like the area on a different phone? It is also assumed that a pixel at 160 density is displayed in a density, also assumed to be an inch. How many pixels will it take to display within an inch of the 240 density level? The answer is 1.5 pixels (based on the rate conversion). Knowing the relationship, the next step is the creation of the icon. 2) about transduction. There are a few suggestions about transduction: first, the length of the width is preferably a multiple of 3 (according to the Android recommended logo icon size is (MDPI), (hdpi), (xhdpi) the minimum number of conventions). Second, the length of the width is preferably even. Because odd numbers can be problematic when they are being compressed. Third, according to the above two, if the length of the width is a multiple of 6 ideal. Finally, if you can stretch without changing the design intent, such as a solid color background, use the Android 9path tool to create a. 9 image. 3) about the adaptation of the icon. And then everything is not related to the design manuscript. Based on a well-cut graph, it is based on the proportional relationship of screen density, pixel, and actual size. If the design division in the 480*800 resolution of the design, and cut the picture, if you need to fit the 720*1280 screen, how to do? Depending on the ratio, their relationship is 2:3, so you need to make icons in 1.5 times-fold proportions, such as when you cut a 20*20 pixel figure in 480*800 's design, then you need to create an icon that is equal to 30*30 pixels, so that the same icon is 480* The 800 screen is the same as the actual size shown on the 720*1280 screen. Similarly, if you need to adapt xxhdpi you need to create an icon that is equal to 40*40 pixels on a 20*20 basis. 4) about the directory of icons, 480*800 cut downFigure we placed in the DRAWABLE-HDPI directory, according to the 2:3 enlarged icon placed in the DRAWABLE-XHDPI directory, according to twice times the enlarged icon placed in the DRAWABLE-XXHDPI directory. Android will first find the corresponding directory according to the density of mobile phone resources, such as 408*800 resolution of the phone if the density is 160, then automatically load drawable-hdpi This directory icon, if 720* 1280 density is 240 of the mobile phone automatically loaded drawable-xhdpi the icon under this directory. If there is no this folder, then find and 240 the closest corresponding density folder. 5) Other next estimates will let you down, according to the above steps can not completely solve the problem of adaptation, can only be approximate adaptation, and even if the above steps are probably appropriate, the actual effect on the phone also has a discrepancy. For example Meizu MX3 resolution is 1080*1800, the standard case density is 480, but his density is about 524, and 480 close, that is, will find drawable-xxhdpi this resource file. In other words, you cut the image in 480*800 resolution and then press twice magnification icon on this phone to show the effect is still smaller than the actual. The other problem is 540*960 or 640*960, whose density is likely to be either close to 240 or maybe 320. The actual size shown on these phones may also be large or small, as a result of the drawings cut down on the 480*800 design and the adaptations made. To sum up, I just share my understanding and experience, but not perfect for the screen, just as a tip, if you pass by and see this advice, if you happen to have a better solution to fit, please advise.   get screen pixels, screen density in your codeDisplaymetrics metric = new Displaymetrics ();  Getwindowmanager (). Getdefaultdisplay (). Getmetrics (Metric); int width = metric.widthpixels; Screen width (pixels) int height = metric.heightpixels; Screen height (pixels) float density = metric.density; Screen density (0.75/1.0/1.5) int densitydpi = metric.densitydpi; Screen density dpi (120/160/240)

DPI is the abbreviation for "dot per inch" and the number of pixels per inch. General screen: LDPI is 120,mdpi is 160,hdpi is 240,xhdpi is 320. Reference: Http://developer.android.com/images/screens_support/screens-ranges.png

Attaching: Configuring Qualifier Names

Configuration	Qualifier value	Description
MCC and MNC	Example: mcc310 mcc310-mnc004 mcc208-mnc00, etc.	The MCC is the English acronym for the Mobile Country Code, which optionally follows the mobile network code from the SIM card in the device (mnc:mobile. Country). As on any carrier, mcc310 represents the United States, mcc310-mnc004 represents the Venizon company of the United States, and MCC208-MNC00 represents the orange company of France. If the device uses an audio connection (GSM phone), then the values of the MCC and MNC are from the SIM card. MCC can also be used separately (for example, in applications that contain legitimate resources from a particular country). If you only need to specify a locale, you can use the language and region qualifiers instead (discussed later). If you decide to use MCC and MNC qualifiers, you should test carefully to make it work as you expect. You can also view the configuration domain MCC and MNC, which indicate the current mobile country code and the mobile network code, respectively. MCC:HTTP://DEVELOPER.ANDROID.COM/REFERENCE/ANDROID/CONTENT/RES/CONFIGURATION.HTML#MCC mnc:http:// Developer.android.com/reference/android/content/res/configuration.html#mnc
Languages and regions	For example: En fr en-rus fr-rfr Fr-rca	The language is defined by the two-letter ISO 639-1 language code, followed by an optional two iso-3166-1-appha-2 region code letter (preceded by the lowercase "r"). This encoding is case-insensitive, the R prefix is used to differentiate between regions and cannot be specified separately. If the user changes the language setting in the system, it can be changed to the corresponding language during the application's operation.
Minimum width	sw<n>dp For example: SW320DP SW600DP SW720DP, etc.	the basic size of the screen, refers to the shortest available screen area. In particular, the minimum width of the device is the shortest possible width and height of the screen (it can also be seen as the minimum width of the screen). This allows you to use this qualifier to ensure that the application has at least <N>DP width available for the UI interface, regardless of the current orientation of the screen. For example, if the layout requires at least 600DP minimum screen size at any time, you can use this qualifier to create a layout resource in the res/layout-sw600dp/directory. These resources are only used when the size of the available screen is at least 600DP, regardless of whether the 600DP is a user-perceived height or width. The minimum width is the fixed screen size feature of the device, and the minimum width of the device does not change when the orientation of the screen changes. The minimum width of the device requires consideration of screen decorations and system UI occupancy. For example, if the device has some fixed UI elements that take up a certain amount of screen space along the minimum width of the axis, the minimum width of the system declaration is smaller than the actual screen size, because the portion of the pixel that is occupied by the system is not valid for the UI of the user application. Therefore, this value should be the minimum actual size required for the application layout (typically, this value is the minimum width supported by the layout, regardless of the current orientation of the screen). Here are some values for the common screen size that you can use: 1.320, devices configured for the following screen:   240X320LDPI (QVGA handheld device)   320X480MDPI (handheld device)   480X800HDPI (High-resolution handheld device) 2.480, for 480x800mdpi screen (flatbed or handheld) 3.600, for 600x1024mdip screen (7-inch tablet) 4.720, for 720x1280mdip screen (10 inch tablet) when the application provides multiple minimum width qualifier resource catalogs with different values, the system uses the resource that is closest (not exceeding) the minimum width of the device. This qualifier is added to API level 13. Also look at the ANDROID:REQUIRESSMALLESTWIDTHDP property, which declares the smallest minimum width compatible with your application, and the SMALLESTSCREENWIDTHDP configuration field holds the value of the device's minimum width.
Available widths	W<N>DP Example: W720DP W1024DP, etc.	Specifies the minimum available screen width, in which the value of <N> should be defined in the resource's DP unit. When the direction changes between landscape and portrait, this configuration value matches the current actual width. When an application gives this configuration a resource directory with several different values, the system uses the configuration that is closest to (not exceeding) the current screen width of the device. This value takes into account the space occupied by the screen decorations, so if the device has some fixed UI elements on the left or right side of the display, the width value used will be smaller than the actual screen size, because the use of these fixed UI elements reduces the available space for the application. This feature is added in API level 13 and depends on the SCREENWIDTHDP configuration field, which holds the current screen width.
Available height	H<N>DP Example: H720DP H1024DP, etc.	Specifies the minimum available screen height, in which the value of <N> should be defined in the resource, and the configuration value should match the current actual height when the direction changes directly in both landscape and portrait orientation. When an application provides multiple resource catalogs with different values for this configuration, the system uses the configuration that is closest to (not exceeding) the current screen height of the device. This takes into account the occupancy of the screen decorations, so if the device has some fixed UI elements above or below the display, the height value to use is smaller than the actual screen size, as these fixed UI elements are occupied, allowing the application to reduce the available space. Non-fixed screen decorations (such as the status bar of a phone can be hidden in full screen) are not considered, such as the title bar or the action bar such as window decoration is not considered, so the application must be prepared to deal with less than the space specified by the case. This qualifier is added to API level 13. Also look at the SCREENHEIGHTDP configuration field, which holds the height of the current screen.
Screen size	Small normal Large XLarge	Small: This screen is similar to a low-resolution QVGA screen. The minimum layout size for a small screen is approximately 320X426DP. For example QVGA low resolution and VGA high resolution. Normal: This kind of screen is similar to the medium resolution HVGA screen. The minimum layout size for a normal screen is approximately 320x470dp. For example, WQVGA low resolution screen, HVGA medium resolution screen, WVGA high resolution screen. Large: This kind of screen is similar to the medium resolution VGA screen, the smallest layout size for large screen is about 480X640DP. For example, VGA and WVGA medium resolution screen. XLarge: This screen is considered larger than the traditional medium-resolution HVGA screen. The minimum layout size for the XLarge screen is approximately 720x960dp. In most cases, this large-screen device is too large to carry in a backpack, and most likely a flat-style device. Note: Using a dimension qualifier does not imply that the resource is used only for this size screen. If you do not provide a qualifier with an optional resource that matches the current device configuration, the system uses the resource closest to the configuration. Warning: If all resources using the dimension qualifier are larger than the current screen, then the system will not use them, and the application will crash at run time (for example, if all layouts are marked with the XLarge qualifier and the device is a normal-sized screen). This qualifier is added in the version after API level 4.
Screen appearance	Long Notlong	Long: Longer screen, such as WQVGA, WVGA, FWVGA Notlong: Non-long screen, such as QVGA, HVGA, VGA This qualifier is added in the version after API Level 4 This qualifier is completely based on the screen appearance ratio, not relative to the direction of the screen. Also see the Screenlayout configuration field, which indicates whether the screen is a long screen.
Screen orientation	Port Land	Port: Longitudinal device (vertical) Land: Horizontal device (horizontal) If the user rotates the screen, this limit can be changed while the application is running. The Orientation configuration field indicates the direction of the current device.
Berth mode	Car Desk	Car: Device docked in car desk: device docked in the desk this qualifier is added in the version after API level 8 if the user changes the docking location of the device, the limit can be changed during the run of the application. You can use the Uimodemanager object to enable or disable this mode.
Night mode	Night Notnight	Night: Night Notnight: Added during the day after the API level 8 if the night mode is kept in automatic mode (default), the pattern changes during the time of the application run based on daylight. You can use the Uimodemanager object to enable or disable this mode.
Screen pixel density (dpi)	ldpi mdpi hdpi xhdpi nodpi tvdpi	LDPI: Low resolution screen for approximately 120dpi, MDPI: Medium resolution screen for approximately 160dpi (on traditional HVGA), hdpi: High resolution screen for approximately 240dpi, xhdpi: Ultra-high resolution screen for about 320DPI, is added in the version after API basic 8; NODPI: This limit is used for bitmap resources that do not want to be scaled based on the matching device resolution. TVDPI: The screen between MDPI and hdpi is about 213dpi. This grouping is not the primary resolution, most of it is for TV, and most applications do not need it---provide mdpi and hdpi resources to meet the needs of most applications, and the system scales them appropriately. This qualifier is introduced after API level 13. The scaling ratios between the four main resolutions are: 3:4:6:8 (ignoring the tvdpi resolution), so a 9x9 ldpi bitmap, mdpi in 12x12, hdpi in 18x18, xhdpi in 24x24. If you feel that the picture resources on your TV or some other device are not looking good, and you want to try tvdpi resources, then the scaling factor is 1.33*mdpi. For example, a picture of a 100px x 100px mdpi image should be enlarged to a 133px x 133px tvdpi image. Note: Using the resolution qualifier does not imply that the resource is applicable only to the screen with the corresponding resolution. If you do not provide an optional resource that matches the current device configuration, the system uses the closest resource.
Touch screen Type	Notouch Stylus Finger	Notouch: Non-touchscreen device stylus: A resistive screen device for the stylus finger: The touchscreen device touchscreen the configuration field, indicating the type of touchscreen on the device.
Availability of keyboard	keysexposed Keyshidden Keyssoft	Keysexposed: The device has a keyboard available. If the device has a soft keyboard enabled, this qualifier can be used even when the hard keyboard is not exposed to the user. If you do not provide a soft keyboard or a soft keyboard is disabled, you will only be able to use this qualifier if the hard keyboard is exposed to the user. Keyshidden: The device has a hard keyboard available, but it is hidden, and the device does not have a soft keyboard available. Keyssoft: The device has a soft keyboard available, regardless of whether it is visible or not. If a keysexposed resource is provided, but there is no keyssoft resource, the system uses keysexposed resources regardless of whether the keyboard is visible, as long as the system has a soft keyboard available. If the user has a hard keyboard open, you can change this qualification while the application is running. The Hardkeyboardhidden and Keyboardhidden configuration fields indicate the visibility of the hard keyboard and the visible keyboard type (including the soft keyboard), respectively.
Main text Input Method	Nokeys qwerty L2key	Nokeys: The device does not have a hard keyboard for text input; QWERTY: The device has a standard hard keyboard, regardless of whether the user is visible or not, 12key: The device has a 12-key hard keyboard, regardless of whether the user is visible or not. The Keyboard configuration field indicates the primary text input method that is available.
Validity of navigation keys	Navexposed Navhidden	navexposed: The navigation key is available to the user; Navhidden: The Navigation key is unavailable. If the user is able to see the navigation key, the limit can be changed while the application is running. Navigationhidden the configuration field to indicate whether the navigation key is hidden.
The main non-touchscreen navigation method	Nonav Dpad trackball Wheel	Nonav: In addition to using the touchscreen, the device has no other navigational facilities. Dpad: The device has a directional plate (d-pad) for navigation. Trackball: The device has a trackball for navigation. Wheel: The device has a directional wheel for navigation (uncommon). The Navigation configuration field indicates the type of navigation method available.
Platform version (API level)	Example: V3 v4 V7, etc.	The API level supported by the device. If V1 represents API Level 1 (Devices with Android1.0 or higher), V4 represents API level 4 (Devices with Android1.6 or later) Warning: Android1.5 and 1.6 Only match resources if the qualifier matches the platform version exactly

Android screen adaptation