Android resolution support

For Android resolution support, please refer to the official documents for free time during the World Cup and translate the official documents. Resolution issues are of great interest to everyone (720 × 480 will be a tragedy), and the official android documentation is undoubtedly the most convincing. Since not all people are willing to read English, they have to translate some games before they start.

Address: http://developer.android.com/guide/practices/screens_support.html

-------- Below is the translation --------- I am the splitting line ---------

Multi-Resolution Support

At the beginning of the design, the Android system was designed as an operating system that can run on a variety of devices with different resolutions. For applications, the system platform provides them with a stable and cross-platform running environment, most of the technical details about how to correctly display a program to the platform on which it runs are handled by the system without the intervention of the program. Of course, the system itself also provides a series of APIS for the program, so when the resolution of the target platform can be completely determined, the program can also precisely control its interface display mode on the target platform.

This document describes the resolution support features provided by the system platform and how they are used in the program. If you follow the methods listed in the document, it is easy for your program to be perfectly displayed at all supported resolutions. In this case, you can use a single. APK file to publish your program to all platforms.

If you have released a program for Android 1.5 or earlier, read this document carefully and consider how to make your old program have different resolutions, android 1.6 or the update platform is displayed normally. In most cases, you only need to make small changes to the program to achieve the goal, but you still need to test on platforms with various resolutions as much as possible.
Specifically, if you have a completed program and want it to run correctly on ultra-low resolution devices (such as 320x240, you need to read the "update policy of the old program" and the document will tell you how to do it.

Terms and concepts
Screen Size
The physical size of the screen, based on the diagonal length of the screen (such as 2.8, 3.5 ).
In short, Android simplifies all screen sizes into three categories: Large, normal, and small.
The program can provide three different layout schemes for these three screens, and then the system will be responsible for rendering your layout scheme to the corresponding screen in an appropriate way, this process does not require code intervention by programmers.

Screen Aspect Ratio
The ratio of the physical length of the screen to the physical width. The program can provide materials for the screen with a aspect ratio. You only need to use the resource categories provided by the system, long and notlong.

Resolution
Total number of pixels on the screen. Note that although the resolution is expressed as "width x length" in most cases, the resolution does not mean the aspect ratio of the screen. In Android systems, the program generally does not directly process the resolution.

Density
Pixels arranged along the length and width of the Screen Based on the screen resolution.
Low-density screens have only a small number of pixels in the long and wide directions, while high-density screens usually have many-or even very many-pixels arranged in the same area. The screen density is very important. For example, the interface elements (such as a button) defined in pixels with the length and width are very large on low-density screens, but on a high-density screen, it will appear very small.

Density-independent pixels (DIP)
A pixel in an abstract sense. A program uses it to define interface elements. As a unit unrelated to the actual density, it helps programmers build a layout scheme (width, height, and position of the interface element ).
A density-independent pixel is logically consistent with a pixel on a screen with a pixel density of DPI. This is also the default display device assumed by the Android platform. When running, the platform uses the density of the target screen as the benchmark to "transparently" all required DIP scaling operations. To convert density-independent pixels to screen pixels, use the following simple formula: pixels = dips * (density/160 ). For example, on a screen with DPI 240, one DIP equals 1.5 physical pixels. We strongly recommend that you use DIP to define the interface layout of your program, because this ensures that your UI can be normally displayed on the screen of various resolutions.

Supported Screen Resolution Range
In Android 1.5 and earlier versions, it is assumed that the system will only run on a device with a resolution-HVGA (320x480) Resolution. The size is 3.2. Since the system can only work on one screen, developers can write their own programs for that screen, without having to consider the display of programs on other screens.
However, since Android 1.6, the system has introduced support for screens of various sizes and resolutions to meet the running requirements of new platforms with various configurations. This means that when developers develop programs for Android 1.6 or later versions, they need to make additional designs for their programs to display on screens with multiple resolutions.
To simplify the programmer's troubles in various resolutions, and to enable platforms with various resolutions to run these programs directly, the Android platform classifies all screens by density and resolution, they are divided into three types:
· Three major dimensions: Large, normal, and small;
· Three different density types: high (hdpi), medium (mdpi), and low (ldpi ).
If needed, the program can provide different resources (mainly layout) for screens of various sizes, or provide different resources (mainly Bitmap) for screens of various density ). In addition, the program does not need to deal with the size or density of the screen. During execution, the platform automatically loads the corresponding resources based on the size and density characteristics of the screen and extracts them from the logical pixels (DIP, used to define the interface layout) convert to physical pixels on the screen.
The following table lists some commonly used models on the screen supported by the Android platform, and shows how the system classifies them into different screen configurations. Some screen resolutions are not listed in the following list, but they are still classified into one of the following types.

	Low Density (120), ldpi	Medium Density (160), mdpi	High density (240), hdpi
SmallScreen	· QVGA (240x320), 2.6 ~ 3.0 inch
NormalScreen	· WQVGA (240x400), 3.2 ~ 3.5 inch · FWQVGA (240x432), 3.5 ~ 3.8 inch	· HVGA (320x480), 3.0 ~ 3.5 inch	· WVGA (480x800), 3.3 ~ 4.0 inch · FWVGA (480X854), 3.5 ~ 4.0 inch
LargeScreen		· WVGA (480x800), 4.8 ~ 5.5 inch · FWVGA (480X854), 5.0 ~ 5.8 inch

As shown in the table above, all the screens of resolution are centered aroundBaseline ScreenSurrounding, while the baseline screen in classification is "normal" size, with "medium" density. The HVGA screen is used as the benchmark screen because all programs for Android 1.5 or earlier are written for this screen (because only this screen is supported), such as T-Mobile G1.
Although the system supports the above nine screens with different configurations, you do not have to provide different resources for them. The system has provided compatibility features that are robust enough (that is, to work normally in a variety of harsh environments and are not sensitive to environmental changes) to display your programs on a variety of screens. This is described in detail in the following document. If you need more information, see "Best Practices unrelated to the screen ".