다중 화면 지원

Android는 다양한 기기에서 실행되며, 이들 기기의 화면 크기와 밀도는 다양합니다. 애플리케이션을 위해, Android 시스템은 다양한 기기에서 일관된 개발 환경을 제공하며, 또한 애플리케이션이 표시되는 화면에 맞게 사용자 인터페이스를 조정하는 작업의 대부분을 수행합니다. 이 시스템은 또한 여러분이 특정 화면 크기와 밀도에 맞게 애플리케이션 UI를 제어할 수 있는 API를 제공하며, 이를 통해 다양한 화면 구성에 맞게 UI 디자인을 최적화할 수 있습니다. 예를 들어, 핸드셋용 UI와는 다르게 태블릿용 UI를 디자인할 수도 있습니다.

다양한 화면에서 앱이 작동하기 위한 확대/축소와 크기 조정은 시스템이 해주지만, 다양한 화면 크기와 밀도에 맞게 애플리케이션을 최적화하는 노력은 여러분이 해야 합니다. 그렇게 해야만 여러분이 모든 기기에서 사용자 환경을 최적화하고, 사용자 기기의 화면에 맞게 애플리케이션이 단순히 확장되는 것이 아니라 사용자의 기기에 맞게 애플리케이션이 디자인되었다는 믿음을 사용자에게 줄 수 있습니다.

이 문서에 설명된 사례를 따라하면, 지원되는 모든 화면 구성에서 올바로 표시되고 최적화된 사용자 환경을 제공하는 애플리케이션을 단일 .apk 파일만으로 만들 수 있을 것입니다.

참고: 이 문서에서는 Android 1.6(API 레벨 4) 이상을 위해 애플리케이션이 디자인되었다고 가정합니다. 애플리케이션이 Android 1.5 이하를 지원하는 경우에는, 먼저 Android 1.5 전략을 읽어보세요.

또한, 다양한 화면 크기에 맞게 애플리케이션에 사용되는 레이아웃 리소스를 더욱 정밀하게 제어할 수 있는 새로운 API가 Android 3.2에서 도입되었습니다. 이 새로운 기능들은 여러분이 태블릿용으로 최적화된 애플리케이션을 개발 중인 경우에 특히 중요합니다. 자세한 내용은 Android 3.2용 태블릿 레이아웃 선언에 관한 섹션을 참조하세요.

화면 지원 개요

이 섹션에서는 Android의 다중 화면 지원에 대해 간략히 설명합니다. 여기에서는 이 문서와 API에 사용되는 용어와 개념을 소개하고, 시스템이 지원하는 화면 구성을 요약하고, API 및 기본적인 화면 호환성 기능을 간략히 설명합니다.

용어 및 개념

화면 크기
실제의 물리적 크기이며, 화면의 대각선 크기로 측정됩니다.

단순화하기 위해 Android에서는 모든 실제 화면 크기를 네 가지 일반화된 크기 그룹으로 분류합니다(소형, 보통, 대형 및 초대형).

화면 밀도
물리적 화면 공간 안에 있는 픽셀 개수이며, 일반적으로 dpi(dots per inch)라고 부릅니다. 예를 들어, "저밀도" 화면은 "중간 밀도" 또는 "고밀도" 화면에 비해 물리적 공간 안의 픽셀 수가 더 적습니다.

단순화하기 위해 Android에서는 모든 실제 화면 밀도를 여섯 가지 일반화된 밀도 그룹으로 분류합니다(저밀도, 중간 밀도, 고밀도, 초고밀도, 초초고밀도, 초초초고밀도).

방향
사용자 시점에서 바라본 화면의 방향입니다. 가로 모드 또는 세로 모드 중 하나이며, 화면비가 가로 방향이거나 세로 방향입니다. 기본적으로, 서로 다른 기기마다 서로 다른 방향으로 작동하지만 사용자가 런타임에 기기를 회전시키면 방향이 변할 수 있습니다.
해상도
화면에 있는 물리적 픽셀의 총 개수입니다. 다중 화면 지원을 추가하는 경우, 애플리케이션은 해상도에 직접 관여하지 않으며, 화면 크기와 밀도에만 관여합니다(일반화된 크기와 밀도 그룹으로 지정).
밀도 독립적 픽셀(dp)
UI 레이아웃을 정의할 때 레이아웃 치수나 위치를 밀도 독립적 방식으로 표현하기 위해 여러분이 사용해야 하는 가상 픽셀 단위입니다.

밀도 독립적 픽셀이란 160 dpi 화면의 물리적 픽셀 하나를 말하며, 이것은 시스템에서 "보통" 밀도 화면에 해당하는 기준 밀도입니다. 사용 중인 화면의 실제 밀도에 따라, 시스템이 런타임에 dp 단위의 모든 확대/축소를 투명하게 처리합니다. dp 단위를 화면 픽셀로 변환하는 것은 간단합니다. px = dp * (dpi / 160) 예를 들어, 240 dpi 화면에서 1 dp는 1.5 물리적 픽셀과 같습니다. 다른 밀도의 화면에 UI가 적절히 표시되도록 하려면, 애플리케이션 UI를 정의할 때 항상 dp 단위를 사용해야 합니다.

지원되는 화면의 범위

Android 1.6(API 레벨 4)부터 Android는 다중 화면 크기와 밀도를 지원하며, 한 기기에 여러 가지 다양한 화면 구성을 적용합니다. Android 시스템의 여러 기능을 사용하여 각 화면 구성에 맞게 애플리케이션 사용자 인터페이스를 최적화할 수 있으며, 각 화면에서 애플리케이션이 올바로 렌더링되고 또한 최적의 사용자 환경을 제공하도록 보장할 수 있습니다.

다중 화면에 맞게 사용자 인터페이스를 디자인하는 방식을 단순화하기 위해 Android에서는 실제 화면 크기와 밀도의 범위를 다음과 같이 구분합니다.

  • 네 가지 일반화된 크기: 소형, 보통, 대형초대형

    참고: 가용 화면 너비에 따라 화면 크기를 관리하는 새로운 기술로 인해, Android 3.2(API 레벨 13)부터는 이러한 크기 그룹에 대한 지원이 중단됩니다. Android 3.2 이상을 위한 앱을 개발 중인 경우, Android 3.2용 태블릿 레이아웃 선언에서 자세한 내용을 참조하세요.

  • 여섯 가지 일반화된 밀도:
    • ldpi (저밀도) ~120dpi
    • mdpi (중간 밀도) ~160dpi
    • hdpi (고밀도) ~240dpi
    • xhdpi (초고밀도) ~320dpi
    • xxhdpi (초초고밀도) ~480dpi
    • xxxhdpi (초초초고밀도) ~640dpi

이러한 일반화된 크기와 밀도는 기준 구성, 즉 normal 크기와 mdpi(중간) 밀도를 기준으로 배열됩니다. 이 기준은 최초의 Android 구동 기기인 T-Mobile G1의 화면 구성을 기반으로 하며, 이 기기에는 HVGA 화면이 있습니다. (Android 1.6까지는 이것이 Android가 지원했던 유일한 화면 구성입니다.)

일반화된 각 크기와 밀도는 실제로 다양한 화면 크기와 밀도에 걸쳐있습니다. 예를 들어, 화면 크기가 normal인 두 기기의 화면 크기를 손으로 측정할 경우, 실제 화면 크기와 화면비가 서로 약간 다를 수도 있습니다. 마찬가지로, 화면 밀도가 hdpi인 두 기기의 실제 픽셀 밀도가 약간 다를 수도 있습니다. Android는 이러한 차이를 애플리케이션에 맞게 추상화시키기 때문에, 여러분은 일반화된 크기와 밀도에 맞게 디자인된 UI를 제공할 수 있고, 필요한 경우 시스템이 최종적인 조정을 수행하도록 만들 수 있습니다. 그림 1은 서로 다른 크기와 밀도가 서로 다른 크기와 밀도 그룹으로 대략적으로 분류되는 방식을 보여줍니다.

그림 1. Android에서 실제 크기와 밀도가 일반화된 크기와 밀도로 대략적으로 매핑되는 방식을 보여주는 그림).

다른 화면 크기에 맞게 UI를 디자인하다 보면, 각 디자인에 최소한의 공간 크기가 필요함을 알게 될 것입니다. 따라서, 위에 나타난 각 일반화된 화면 크기는 시스템이 정의하는 연관된 최소 해상도를 가집니다. 이 최소 크기는 "dp" 단위이며(레이아웃을 정의할 때 사용해야 하는 동일한 단위), 이 경우 시스템이 화면 밀도의 변화를 걱정할 필요가 없습니다.

  • 초대형 화면은 최소 960dp x 720dp
  • 대형 화면은 최소 640dp x 480dp
  • 보통 화면은 최소 470dp x 320dp
  • 소형 화면은 최소 426dp x 320dp

참고: Android 3.0 이전에는 이 최소 화면 크기가 잘 정의되지 않았기 때문에, 일부 기기에서는 보통과 대형의 구분이 부정확할 수도 있습니다. 이들 크기도 또한 물리적 화면 해상도를 기반으로 하므로, 기기마다 크기가 다를 수 있습니다. (예를 들어, 시스템 바가 있는 1024x720 태블릿의 경우 시스템 바에 사용되는 공간 때문에 실제로 애플리케이션에 사용 가능한 공간이 약간 줄어듭니다.)

다른 화면 크기와 밀도에 맞게 애플리케이션 UI를 최적화하려면, 일반화된 모든 크기와 밀도에 대해 대체 리소스를 제공할 수 있습니다. 일반적으로, 서로 다른 화면 크기에는 대체 레이아웃을 제공해야 하고, 서로 다른 화면 밀도에는 대체 비트맵을 제공해야 합니다. 현재 기기 화면의 일반화된 크기나 밀도에 따라, 시스템이 런타임에 여러분의 애플리케이션에 적합한 리소스를 사용합니다.

화면 크기와 밀도의 모든 조합에 대해 대체 리소스를 제공할 필요는 없습니다. 시스템은 뛰어난 호환성 기능을 제공하며, 이 기능에서는 모든 기기 화면에서 여러분의 애플리케이션을 렌더링하는 작업의 대부분을 처리할 수 있습니다. 단, 이 경우 여러분이 매끄러운 크기 조정을 허용하는 기술을 사용하여 UI를 구현해야 합니다(아래의 모범 사례에 설명).

참고: 기기의 일반화된 화면 크기와 밀도를 정의하는 특성들은 상호 간에 독립적입니다. 예를 들어, WVGA 고밀도 화면은 물리적 크기가 T-Mobile G1(Android 최초의 기기 및 기준 화면 구성)과 거의 동일하기 때문에 보통 화면 크기로 간주됩니다. 반대로, WVGA 중간 밀도 화면은 대형 크기 화면으로 간주됩니다. WVGA 중간 밀도 화면은 동일한 해상도(동일한 픽셀 수)를 제공하더라도 화면 밀도는 더 낮습니다. 즉, 각 픽셀이 물리적으로 더 크며 전체 화면이 기준(보통 크기) 화면보다 더 큽니다.

밀도 독립성

다른 밀도의 화면에 표시될 때, 사용자 인터페이스 요소의 물리적 크기가 보존되는 경우(사용자 관점에서), 애플리케이션이 "밀도 독립성"을 실현하는 것입니다.

밀도 독립성을 유지하는 것은 중요합니다. 밀도 독립성이 없는 경우 저밀도 화면에서는 UI 요소(예: 버튼)가 물리적으로 더 크게 나타나고 고밀도 화면에서는 더 작게 나타납니다. 이와 같은 밀도 관련 크기 변화는 여러분의 애플리케이션 레이아웃과 사용성에서 문제를 일으킬 수 있습니다. 그림 2와 그림 3은 밀도 독립성이 유지되는 애플리케이션과 유지되지 않는 애플리케이션의 차이점을 각각 보여줍니다.

그림 2. 다양한 밀도(저밀도, 중간 밀도 및 고밀도 화면)를 지원하지 않는 예시 애플리케이션.

그림 3. 다양한 밀도(저밀도, 중간 밀도 및 고밀도 화면)를 올바로 지원하는 예시 애플리케이션(밀도에 독립적).

Android 시스템에서는 다음과 같은 두 가지 방식으로 애플리케이션이 밀도 독립성을 실현합니다.

  • 현재 화면 밀도에 맞게 시스템이 dp 단위를 적절히 확대/축소합니다.
  • 필요한 경우 현재 화면 밀도에 따라 시스템이 드로어블 리소스를 적절한 크기로 확대/축소합니다.

그림 2에서 텍스트 뷰와 비트맵 드로어블의 치수는 픽셀(px) 단위로 지정되므로, 저밀도 화면에서는 뷰가 물리적으로 더 크고 고밀도 화면에서는 더 작습니다. 그 이유는 실제의 화면 크기가 동일하더라도 고밀도 화면에서는 인치당 픽셀 수가 더 많기 때문입니다(더 좁은 공간에 동일한 수의 픽셀). 그림 3에서 레이아웃 치수는 밀도 독립적 픽셀(dp) 단위로 지정됩니다. 밀도 독립적 픽셀의 기준은 중간 밀도 화면이기 때문에, 중간 밀도 화면을 가진 기기는 그림 2에서와 동일하게 보입니다. 그러나 저밀도와 고밀도 화면의 경우에는 시스템이 밀도 독립적 픽셀 값을 각각 아래와 위로 확대/축소하여 화면을 적절하게 맞춥니다.

대부분의 경우에는, 모든 레이아웃 치수 값을 밀도 독립적 픽셀(dp) 단위나 "wrap_content"로 적절하게 지정하여 여러분의 애플리케이션에서 밀도 독립성을 보장할 수 있습니다. 그런 다음, 시스템이 비트맵 드로어블을 적절하게 확대/축소하여 알맞은 크기로 표시합니다(현재 화면의 밀도에 맞는 적절한 배율 사용).

그러나, 비트맵 확대/축소를 수행하면 위의 스크린샷에 나타난 것처럼, 비트맵이 흐려지거나 모자이크 형태로 나타날 수 있습니다. 이러한 아티팩트를 피하려면, 다른 밀도에 대해 대체 비트맵 리소스를 제공해야 합니다. 예를 들어, 고밀도 화면에는 더 높은 해상도의 비트맵을 제공해야 하며, 이 경우 시스템은 중간 밀도 화면용으로 디자인된 비트맵을 조정하는 대신, 더 높은 해상도의 비트맵을 사용합니다. 다음 섹션에서는 다른 화면 구성에 대해 대체 리소스를 제공하는 방법에 대해 설명합니다.

다중 화면 지원 방법

다중 화면 지원을 위해 Android는 현재 화면 구성에 적절한 방식으로, 애플리케이션 레이아웃과 비트맵 드로어블의 렌더링을 관리합니다. 시스템은 각 화면 구성에서 애플리케이션을 렌더링하는 작업의 대부분을 처리하며, 이를 위해 화면 크기/밀도에 맞게 레이아웃을 확대/축소하고 화면 밀도에 맞게 비트맵 드로어블을 적절히 확대/축소합니다. 그러나 다른 화면 구성을 더 매끄럽게 처리하려면 또한 다음 작업을 수행해야 합니다.

  • 어떤 화면 크기를 여러분의 애플리케이션이 지원하는지 명시적으로 매니페스트에 선언

    어떤 화면 크기를 여러분의 애플리케이션이 지원하는지 선언하면, 여러분이 지원하는 화면이 장착된 기기에서만 애플리케이션을 다운로드하도록 보장할 수 있습니다. 또한 다른 화면 크기를 지원한다고 선언하면, 더 큰 화면에서 시스템이 애플리케이션을 그리는 방식에 영향을 미칠 수 있습니다(구체적으로, 애플리케이션이 화면 호환 모드에서 실행되는지 여부).

    여러분의 애플리케이션이 지원하는 화면 크기를 선언하려면, <supports-screens> 요소를 매니페스트 파일에 포함해야 합니다.

  • 다른 화면 크기에 다른 레이아웃을 제공

    기본적으로 Android에서는 현재 기기 화면에 맞게 애플리케이션 레이아웃의 크기를 조정합니다. 대부분의 경우에는 이 작업이 제대로 수행됩니다. 다른 경우에는 UI가 이상하게 보일 수도 있으며, 다른 화면 크기에 맞게 조정이 필요할 수도 있습니다. 예를 들어, 더 큰 화면에서는 일부 요소의 위치와 크기를 조정하여 화면 공간을 더 활용할 수도 있으며, 더 작은 화면에서는 모든 것이 화면 안에 들어가도록 크기를 조정할 수도 있습니다.

    크기별 리소스를 제공하기 위해 사용할 수 있는 구성 한정자는 small, normal, largexlarge입니다. 예를 들어, 초대형 화면은 layout-xlarge/에 들어가야 합니다.

    Android 3.2(API 레벨 13)부터는 위의 크기 그룹에 대한 지원이 중단되며, 그 대신 sw<N>dp 구성 한정자를 사용하여, 레이아웃 리소스에 요구되는 최소 가용 너비를 정의해야 합니다. 예를 들어, 여러분의 다중 창 태블릿 레이아웃에 최소 600dp의 화면 너비가 필요한 경우에는 이 레이아웃을 layout-sw600dp/에 넣어야 합니다. 레이아웃 리소스를 선언하기 위한 새로운 기술 사용에 대해서는 Android 3.2용 태블릿 레이아웃 선언에서 자세히 설명합니다.

  • 다른 화면 밀도에 다른 비트맵 드로어블을 제공

    기본적으로, Android에서는 비트맵 드로어블(.png, .jpg.gif 파일)과 나인 패치 드로어블(.9.png 파일)을 확대/축소하므로, 각 기기에서 적절한 물리적 크기로 렌더링이 수행됩니다. 예를 들어, 애플리케이션이 기준 중간 밀도(mdpi) 화면에 대해서만 비트맵 드로어블을 제공하는 경우, 시스템은 고밀도 화면에서 이 드로어블을 확대하고 저밀도 화면에서 드로어블을 축소합니다. 이러한 확대/축소는 비트맵에 아티팩트를 유발할 수 있습니다. 비트맵이 가장 좋게 보이도록 하려면, 다른 화면 밀도에 대해 다른 해상도의 대체 버전을 포함시켜야 합니다.

    밀도별 리소스에 사용할 수 있는 구성 한정자(아래에 자세히 설명)는 ldpi(저밀도), mdpi(중간 밀도), hdpi(고밀도), xhdpi(초고밀도), xxhdpi(초초고밀도) 및 xxxhdpi(초초초고밀도)입니다. 예를 들어, 고밀도 화면의 비트맵은 drawable-hdpi/에 들어가야 합니다.

    참고: mipmap-xxxhdpi 한정자는 xxhdpi 기기에서 보통보다 더 크게 나타날 수 있는 런처 아이콘을 제공하는 경우에만 필요합니다. 모든 앱 이미지에 대해 xxxhdpi 자산을 제공할 필요는 없습니다.

    일부 기기에서는 런처 아이콘을 최대 25%까지 확대합니다. 예를 들어, 밀도가 최고인 런처 아이콘 이미지가 이미 초초고밀도인 경우, 확대/축소 프로세스는 이 이미지를 덜 선명하게 만듭니다. 따라서 더 높은 밀도의 런처 아이콘을 mipmap-xxxhdpi 디렉터리에 제공해야 하며, 시스템은 더 적은 아이콘을 확대하는 대신 이 아이콘을 사용합니다.

    자세한 내용은 xxxhdpi 밀도 런처 아이콘 제공을 참조하세요. 런처 아이콘이 아닌 UI 요소에는 xxxhdpi 한정자를 사용해서는 안 됩니다.

참고: 모든 런처 아이콘은 res/drawable-[density]/ 폴더가 아닌 res/mipmap-[density]/ 폴더에 넣으세요. 앱이 설치된 기기의 화면 해상도에 상관없이, Android 시스템은 리소스를 밀도별 폴더(예: mipmap-xxxhdpi)에 유지합니다. 이러한 동작을 사용하면, 앱이 홈 화면에 표시되기 위한 최적 해상도의 아이콘을 런처 앱이 선택할 수 있습니다. Mipmap 폴더를 사용하는 자세한 방법은 프로젝트 관리 개요를 참조하세요.

크기 및 밀도 구성 한정자는 위의 지원되는 화면의 범위에서 설명한 일반화된 크기 및 밀도와 일치합니다.

참고: 구성 한정자(시스템이 구성 한정자를 사용하여 리소스를 적용하는 방법)에 대해 익숙치 않은 경우, 대체 리소스 제공에서 자세한 내용을 참조하세요.

런타임에 시스템은 다음과 같은 절차를 사용하여 현재 화면에서 최적의 디스플레이를 보장합니다.

  1. 시스템이 적절한 대체 리소스를 사용합니다.

    현재 화면의 크기와 밀도에 따라 시스템은 애플리케이션에 제공되는 모든 크기별 및 밀도별 리소스를 사용합니다. 예를 들어, 기기에 고밀도 화면이 있고 애플리케이션이 드로어블 리소스를 요청하는 경우, 시스템은 해당 기기 구성에 최적으로 일치하는 드로어블 리소스 디렉터리를 찾습니다. 사용 가능한 다른 대체 리소스에 따라서는, hdpi 한정자(예: drawable-hdpi/)가 있는 리소스 디렉터리가 최적의 일치일 수 있으며, 시스템은 이 디렉터리에 있는 드로어블 리소스를 사용합니다.

  2. 사용 가능한 일치 리소스가 없는 경우 시스템은 기본 리소스를 사용하며, 현재 화면 크기 및 밀도에 맞게 리소스를 확대하거나 축소합니다.

    "기본" 리소스란 구성 한정자로 태깅되지 않은 리소스를 말합니다. 예를 들어, drawable/의 리소스는 기본 드로어블 리소스입니다. 이 경우 시스템에서는 기본 리소스가 기준 화면 크기 및 밀도(이 경우 보통 화면 크기 및 중간 밀도)용으로 디자인된다고 가정합니다. 이처럼 시스템은 고밀도 화면에 대해서는 기본 밀도 리소스를 확대하고 저밀도 화면에 대해서는 이 리소스를 축소합니다.

    그러나, 시스템이 밀도별 리소스를 밀도별 디렉터리에서 찾지 못한 경우, 시스템이 항상 기본 리소스를 사용하는 것은 아닙니다. 그 대신 시스템이 다른 밀도별 리소스 중 하나를 사용하여 확대/축소 시에 더 나은 결과를 얻을 수도 있습니다 . 예를 들어, 저밀도 리소스를 찾을 수 없는 경우, 시스템은 고밀도 리소스를 저밀도로 확대/축소하는 것을 선호합니다. 왜냐하면 시스템이 고밀도 리소스를 0.5 배율의 저밀도로 축소하는 것이 중간 밀도 리소스를 0.75 배율의 리소스로 축소하는 것보다 더 쉽기 때문입니다.

Android에서 구성 한정자를 기기 구성과 비교하여 대체 리소스를 선택하는 방법에 대한 자세한 내용은, Android가 가장 잘 일치하는 리소스를 찾는 방법을 참조하세요.

구성 한정자 사용

Android에서는 현재 기기 화면의 특성에 따라 시스템이 대체 리소스를 선택하는 방법을 여러분이 제어할 수 있도록 여러 가지 구성 한정자를 지원합니다. 구성 한정자란 Android 프로젝트에서 리소스 디렉터리에 추가될 수 있는 문자열이며, 내부 리소스가 디자인되는 구성을 지정합니다.

구성 한정자를 사용하려면:

  1. 새 디렉터리를 프로젝트의 res/ 디렉터리에 만들고 다음 형식을 사용하여 이름을 지정합니다. <resources_name>-<qualifier>
    • <resources_name>은 표준 리소스 이름입니다(예: drawable 또는 layout).
    • <qualifier>는 아래 표 1의 구성 한정자이며, 이들 리소스를 사용할 화면 구성을 지정합니다(예: hdpi 또는 xlarge).

    한 번에 둘 이상의 <qualifier>를 사용할 수 있으며, 각 한정자를 대시(-)로 구분하면 됩니다.

  2. 이 새 디렉터리에 적절한 구성별 리소스를 저장합니다. 이 리소스 파일은 기본 리소스 파일과 똑같은 이름을 지정해야 합니다.

예를 들어, xlarge는 초대형 화면의 구성 한정자입니다. 이 문자열을 리소스 디렉터리 이름에 추가하는 경우(예: layout-xlarge), 이것은 초대형 화면이 달린 기기에서 리소스가 사용될 것임을 시스템에 알려주는 것입니다.

표 1. 다른 화면 구성에 특정 리소스를 제공하도록 하는 구성 한정자.

화면 특성 한정자 설명
크기 small 소형 크기 화면의 리소스.
normal 보통 크기 화면의 리소스. (이것이 기준 크기입니다.)
large 대형 크기 화면의 리소스.
xlarge 초대형 크기 화면의 리소스.
밀도 ldpi 저밀도(ldpi) 화면(~120dpi)의 리소스.
mdpi 중간 밀도(mdpi) 화면(~160dpi)의 리소스. (이것이 기준 밀도입니다.)
hdpi 고밀도(hdpi) 화면(~240dpi)의 리소스.
xhdpi 초고밀도(xhdpi) 화면(~320dpi)의 리소스.
xxhdpi 초초고밀도(xxhdpi) 화면(~480dpi)의 리소스.
xxxhdpi 초초초고밀도 (xxxhdpi) 화면(~640dpi)의 리소스. 이것은 런처 아이콘에만 사용하세요(위의 참고 참조).
nodpi 모든 밀도의 리소스. 이들은 밀도 독립적 리소스입니다. 현재 화면 밀도에 상관없이, 시스템은 이 한정자로 태깅된 리소스를 확대/축소하지 않습니다.
tvdpi mdpi와 hdpi 사이에 있는 화면의 리소스, 약 213dpi. 이것은 "기본" 밀도 그룹으로 간주되지 않습니다. 이는 대체로 텔레비전용으로 만들어진 것이며 대부분의 앱에는 필요하지 않습니다. 대부분의 앱에는 mdpi 및 hdpi 리소스 제공만으로 충분하며, 시스템이 필요에 따라 리소스를 확대/축소합니다. tvdpi 리소스를 제공할 필요가 있는 경우에는 1.33*mdpi의 배율로 크기를 조정해야 합니다. 예를 들어, mdpi 화면의 100px x 100px 이미지는 tvdpi에서 133px x 133px가 되어야 합니다.
방향 land 가로 모드 방향(가로 방향의 화면비) 화면의 리소스.
port 세로 모드 방향(세로 방향의 화면비) 화면의 리소스.
화면비 long 세로 모드 방향(또는 가로 모드 방향)에서 기준 화면 구성보다 세로 방향(또는 가로 방향)이 훨씬 더 긴 화면의 리소스.
notlong 기준 화면 구성과 화면비가 유사한 화면의 리소스.

참고: Android 3.2 이상을 위한 앱을 개발 중인 경우, 특정 화면 크기에 맞게 레이아웃 리소스를 선언할 때 (표 1의 크기 한정자를 사용하는 대신) 여러분이 사용해야 하는 새로운 구성 한정자에 대한 자세한 내용은 Android 3.2용 태블릿 레이아웃 선언을 참조하세요.

이러한 한정자가 실제 화면 크기 및 밀도에 대략적으로 매핑되는 방식에 대한 자세한 내용은, 이 문서 앞부분의 지원되는 화면의 범위를 참조하세요.

예를 들어, 다음과 같은 애플리케이션 리소스 디렉터리는 다른 화면 크기와 다른 드로어블에 대해 다른 레이아웃 디자인을 제공합니다. 런처 아이콘에는 mipmap/ 폴더를 사용합니다.

res/layout/my_layout.xml              // layout for normal screen size ("default")
res/layout-large/my_layout.xml        // layout for large screen size
res/layout-xlarge/my_layout.xml       // layout for extra-large screen size
res/layout-xlarge-land/my_layout.xml  // layout for extra-large in landscape orientation

res/drawable-mdpi/graphic.png         // bitmap for medium-density
res/drawable-hdpi/graphic.png         // bitmap for high-density
res/drawable-xhdpi/graphic.png        // bitmap for extra-high-density
res/drawable-xxhdpi/graphic.png       // bitmap for extra-extra-high-density

res/mipmap-mdpi/my_icon.png         // launcher icon for medium-density
res/mipmap-hdpi/my_icon.png         // launcher icon for high-density
res/mipmap-xhdpi/my_icon.png        // launcher icon for extra-high-density
res/mipmap-xxhdpi/my_icon.png       // launcher icon for extra-extra-high-density
res/mipmap-xxxhdpi/my_icon.png      // launcher icon for extra-extra-extra-high-density

대체 리소스 사용 방법과 구성 한정자의 전체 목록에 대한 자세한 내용은 대체 리소스 제공을 참조하세요.

런타임에 어떤 리소스를 사용할지를 선택할 때, Android 시스템은 특정한 로직을 사용하여 "가장 잘 일치하는" 리소스를 결정합니다. 즉, 여러분이 사용하는 한정자가 모든 경우에 현재 화면 구성과 정확히 일치하지 않아도 시스템에서 사용이 가능합니다. 구체적으로, 크기 한정자에 따라 리소스를 선택할 때 더 잘 일치하는 리소스가 없는 경우, 시스템은 현재 화면보다 더 작은 화면용으로 디자인된 리소스를 사용합니다. (예를 들어, 필요에 따라 대형 크기 화면은 보통 크기 화면 리소스를 사용합니다.) 그러나 사용 가능한 리소스가 현재 화면보다 더 크다면, 시스템은 이를 사용하지 않으며, 기기 구성과 일치하는 다른 리소스가 없는 경우 애플리케이션이 작동 중단됩니다 (예를 들어, 모든 레이아웃 리소스가 xlarge 한정자로 태깅되어 있지만, 기기가 보통 크기 화면인 경우). 시스템이 리소스를 선택하는 방법에 대한 자세한 내용은, Android가 가장 잘 일치하는 리소스를 찾는 방법을 참조하세요.

팁: (아마도 여러분 자신이 런타임에 일부 이미지 조정을 수행하기 때문에) 시스템이 절대로 확대/축소를 수행해서는 안되는 드로어블 리소스가 있는 경우, 이 드로어블 리소스는 nodpi 구성 한정자가 있는 디렉터리에 넣어야 합니다. 이 한정자가 있는 리소스는 밀도에 종속되지 않는 것으로 간주되며, 시스템이 리소스를 확대/축소하지 않습니다.

대체 레이아웃 및 드로어블 디자인

여러분이 만들어야 하는 대체 리소스의 유형은 애플리케이션의 필요에 따라 다릅니다. 일반적으로, 대체 레이아웃 리소스를 제공하려면 크기 및 방향 한정자를 사용해야 하고, 대체 비트맵 드로어블 리소스를 제공하려면 밀도 한정자를 사용해야 합니다.

다음 섹션에서는 크기 및 밀도 한정자를 사용하여 각각 대체 레이아웃 및 드로어블을 제공하는 방법을 요약합니다.

대체 레이아웃

일반적으로, 여러분이 다른 화면 구성에서 자신의 애플리케이션을 테스트했다면 다른 화면 크기에 맞는 대체 레이아웃이 필요한지 여부를 알 수 있습니다. 예:

  • 소형 화면을 테스트할 경우 레이아웃이 화면에 잘 안맞을 경우가 있습니다. 예를 들어, 소형 화면 기기에서는 일련의 버튼들이 화면 너비 안에 안 들어갈 수가 있습니다. 이 경우 버튼의 크기나 위치를 조정하는 대체 레이아웃을 소형 화면에 제공해야 합니다.
  • 초대형 화면에서 테스트를 수행할 경우, 레이아웃에서 큰 화면이 효율적으로 사용되지 않을 수 있으며 이 화면을 채우기 위해 레이아웃을 눈에 띄게 확장해야 하는 경우도 있습니다. 이 경우, 더 큰 화면(예: 태블릿)에 맞게 최적화되고 재구성된 UI를 제공하는 대체 레이아웃을 제공해야 합니다.

    대체 레이아웃이 없이도 큰 화면에서 여러분의 애플리케이션이 잘 작동하기는 하겠지만, 사용자 기기 전용으로 애플리케이션이 디자인되었다는 느낌을 사용자에게 주는 것이 매우 중요합니다. UI가 눈에 띄게 확장된다면 애플리케이션 환경에 대한 사용자의 만족도가 떨어질 것입니다.

  • 또한, 세로 모드 방향과 비교하여 가로 모드 방향에서 테스트를 수행할 경우, 세로 모드 방향에서 화면 하단에 배치되던 UI 요소들이 가로 모드 방향에서는 화면 오른쪽에 나타나야 한다는 것을 알 수 있습니다.

요약하면, 애플리케이션 레이아웃에 관해 다음 사항을 확인해야 합니다.

  • 소형 화면에 맞아야 합니다(그래야 사용자들이 애플리케이션을 실제로 사용할 수 있습니다).
  • 화면 공간을 더 활용하기 위해 더 큰 화면에 최적화되어야 합니다.
  • 가로 모드 및 세로 모드 방향에 모두 최적화되어야 합니다.

시스템이 레이아웃을 확대/축소한 후에도 뷰 크기에 맞춰야 하는 비트맵을 UI에 사용하는 경우(예: 버튼의 배경 이미지), 나인 패치 비트맵 파일을 사용해야 합니다. 나인 패치 파일은 기본적으로 PNG 파일이며, 이 파일에는 확장 가능한 2차원 영역을 지정합니다. 비트맵이 사용된 뷰를 확대/축소해야 하는 경우, 시스템은 나인 패치 비트맵을 확장하지만 이 경우 지정된 영역만을 확장합니다. 이처럼, 나인 패치 비트맵은 모든 크기에 맞게 조정이 가능하므로, 다른 화면 크기에 대해 다른 드로어블을 제공할 필요가 없습니다. 그러나 다른 화면 밀도에 대해서는 대체 버전의 나인 패치 파일을 제공해야 합니다.

대체 드로어블

그림 4. 각 밀도를 지원하는 비트맵 드로어블의 상대적 크기.

거의 모든 애플리케이션에는 런처 아이콘이 있고 이 아이콘은 모든 화면 밀도에서 제대로 표시되어야 하기 때문에, 거의 모든 애플리케이션에는 서로 다른 화면 밀도에 대한 대체 드로어블 리소스가 있어야 합니다. 마찬가지로, 다른 비트맵 드로어블을 여러분의 애플리케이션에 포함시키는 경우(예: 애플리케이션의 메뉴 아이콘 또는 기타 그래픽), 다른 밀도에 대해 대체 버전을 제공해야 합니다.

참고: 비트맵 파일(.png, .jpg 또는 .gif) 및 나인 패치 파일(.9.png)에는 밀도별 드로어블만을 제공해야 합니다. 모양, 색상 또는 기타 드로어블 리소스을 정의하기 위해 XML 파일을 사용하는 경우, 하나의 복사본을 기본 드로어블 디렉터리(drawable/)에 넣어야 합니다.

다른 밀도에 대해 대체 비트맵 드로어블을 만들려면, 여섯 가지 일반화된 밀도 간에 3:4:6:8:12:16 확대/축소 비율을 따라야 합니다. 예를 들어, 중간 밀도 화면에서 48x48 픽셀인 비트맵 드로어블이 있는 경우, 다른 모든 크기는 다음과 같아야 합니다.

  • 저밀도의 경우 36x36 (0.75x)
  • 중간 밀도의 경우 48x48 (1.0x 기준)
  • 고밀도의 경우 72x72 (1.5x)
  • 초고밀도의 경우 96x96 (2.0x)
  • 초초고밀도의 경우 144x144 (3.0x)
  • 초초초고밀도의 경우 192x192 (4.0x) (런처 아이콘에만 해당, 위의 참고 참조)

아이콘 디자인에 대한 자세한 내용은 아이콘 디자인 가이드라인을 참조하세요. 이 가이드라인에는 다양한 비트맵 드로어블(예: 런처 아이콘, 메뉴 아이콘, 상태 표시줄 아이콘, 탭 아이콘 등)에 대한 크기 정보가 포함됩니다.

Android 3.2용 태블릿 레이아웃 선언

Android 3.0을 실행하는 1세대 태블릿의 경우, 태블릿 레이아웃을 선언하는 적절한 방법은 xlarge 구성 한정자가 있는 디렉터리(예: res/layout-xlarge/)에 이 레이아웃을 넣는 것입니다. 다른 유형의 태블릿과 화면 크기(특히, 7" 태블릿)를 수용하기 위해 Android 3.2에서는 보다 다양한 화면 크기에 리소스를 지정할 수 있는 새로운 기법이 도입됩니다. 이 새로운 기법에서는 일반화된 크기 그룹(예: 대형 또는 초대형)에 레이아웃을 맞추려고 시도하는 대신, 레이아웃에 필요한 공간 크기를 기초로 사용합니다(예: 600dp 너비).

7" 태블릿용 디자인이 까다로운 이유는, 일반화된 크기 그룹을 사용할 경우 7" 태블릿과 5" 핸드셋(대형 그룹)이 기술적으로 동일한 그룹에 속하기 때문입니다. 이 두 기기는 보기에는 크기가 서로 비슷해 보이지만, 애플리케이션 UI의 공간 크기가 상당히 다르며 그만큼 사용자 상호작용 스타일도 다릅니다. 따라서 7" 및 5" 화면이 항상 동일한 레이아웃을 사용해야 하는 것은 아닙니다. 이러한 두 종류의 화면에 대해 다른 레이아웃을 제공할 수 있도록, 이제 Android에서는 애플리케이션 레이아웃에 실제로 사용 가능한 너비 및/또는 높이(dp 단위로 지정)에 따라 여러분이 레이아웃 리소스를 지정할 수 있습니다.

예를 들어, 태블릿 스타일의 기기에 사용하려고 레이아웃을 디자인한 경우, 화면 너비가 600dp 미만이 되면 레이아웃이 정상적인 작동을 멈춘다고 지정할 수도 있습니다. 따라서 이 임계값은 태블릿 레이아웃에 필요한 최소 크기가 됩니다. 이처럼, 애플리케이션 UI에 사용 가능한 너비가 최소 600dp 이상인 경우에만 이들 레이아웃 리소스를 사용하도록 지정할 수 있습니다.

여러분은 최소 크기로 사용할 너비를 선택하고 그에 맞게 디자인하거나 또는 여러분의 레이아웃이 지원하는 최소 너비가 무엇인지를 완료 후에 테스트해야 합니다.

참고: 명심할 점은, 이 새로운 크기의 API에 사용되는 모든 그림은 밀도 독립적 픽셀(dp) 값이며 레이아웃 치수는 항상 dp 단위를 사용하여 정의되어야 합니다. 왜냐하면 여러분이 신경 써야 하는 것은 시스템이 화면 밀도를 고려한 후에 사용 가능한 화면 공간의 크기이기 때문입니다(원시 픽셀 해상도를 사용하는 것과 반대). 밀도 독립적 픽셀에 대한 자세한 내용은, 이 문서 앞부분의 용어 및 개념을 참조하세요.

새로운 크기의 한정자 사용

표 2에는 레이아웃에 사용 가능한 공간에 따라 여러분이 지정할 수 있는 다른 리소스 구성이 요약되어 있습니다. 기존의 화면 크기 그룹(소형, 보통, 대형 및 초대형)과 비교할 때, 이 새로운 한정자를 사용하면 여러분의 애플리케이션이 지원하는 특정 화면 크기를 더 정밀하게 제어할 수 있습니다.

참고: 이들 한정자를 사용하여 여러분이 지정하는 크기는 실제 화면 크기가 아닙니다. 오히려 이 크기는 여러분의 액티비티 창에 나타나는 dp 단위의 너비 또는 높이입니다. Android 시스템은 일부 화면을 시스템 UI(예: 화면 하단의 시스템 바 또는 상단의 상태 표시줄)에 사용할 수도 있으므로, 이 일부 화면을 여러분의 레이아웃에 사용하지 못할 수도 있습니다. 여러분이 선언하는 크기는 액티비티에 필요한 크기와 거의 같아야 합니다. 시스템은 레이아웃에 제공되는 공간 크기를 선언할 때 시스템 UI에 사용되는 공간을 고려합니다. 또한 (레이아웃에서 선언하지 않더라도) 작업 모음은 애플리케이션 창 공간의 일부로 간주되며 레이아웃에 사용 가능한 공간을 감소시키므로 디자인 시에 이 점을 고려해야 합니다.

표 2. 화면 크기에 대한 새로운 구성 한정자 (Android 3.2에서 소개).

화면 구성한정자 값설명
smallestWidth sw<N>dp

예:
sw600dp
sw720dp

화면의 기본 크기로, 사용 가능한 화면 영역의 가장 짧은 치수로 나타냅니다. 구체적으로 기기의 smallestWidth는 해당 화면의 이용 가능한 높이와 너비의 가장 짧은 치수를 말합니다(이것을 화면에 대한 "가능한 한 가장 좁은 너비"로 생각해도 됩니다). 이 한정자를 사용하면, 화면의 현재 방향에 관계 없이, 해당 UI에 사용 가능한 너비 중 최소 <N> dp를 애플리케이션에 확보할 수 있습니다.

예를 들어, 언제나 최소 600dp에서 최소 치수의 화면 공간이 레이아웃에 필요한 경우, 이 한정자를 사용하여 레이아웃 리소스, res/layout-sw600dp/를 만들 수 있습니다. 시스템이 이러한 리소스를 사용하는 것은 사용 가능한 화면의 최소 치수가 적어도 600dp가 되는 경우뿐이며, 이때 600 dp라는 크기가 사용자 쪽에서 보기에 높이이든 너비이든 관계 없습니다. 이 smallestWidth는 기기의 고정된 화면 크기 특성입니다. 기기의 smallestWidth는 화면 방향이 변경되어도 바뀌지 않습니다.

기기의 smallestWidth는 화면 장식과 시스템 UI를 감안합니다. 예를 들어, 화면 상에서 최소 너비의 축 주변 공간을 차지하는 영구 UI 요소가 있다면, 시스템은 smallestWidth를 실제 화면 크기보다 작게 선언합니다. 이것은 개발자의 UI가 사용할 수 없는 화면 픽셀이기 때문입니다.

이것은 일반화된 화면 크기 한정자(small, normal, large, xlarge)를 대체하는 것이며, 이를 통해 여러분의 UI에 사용 가능한 유효 크기를 정의할 수 있습니다. 레이아웃 디자인에 있어 흔히 너비가 구동 인자로 사용되므로, smallestWidth를 사용하여 일반 화면 크기를 결정하는 방법이 유용합니다. 대개 UI는 세로로 스크롤되지만, 가로로 스크롤될 경우 최소 공간에 대한 제약이 상당합니다. 핸드셋용 단일 창 레이아웃을 사용할지 아니면 태블릿용 다중 창 레이아웃을 사용할지 여부를 결정하는 데 있어 '사용 가능한 너비'가 또한 중요한 요소입니다. 따라서, 여러분이 아마도 가장 신경 쓰는 것은 각 기기에서 가능한 최소 너비일 것입니다.

사용 가능한 화면 너비 w<N>dp

예:
w720dp
w1024dp

리소스가 사용되어야 하는 최소 사용 가능 너비를 dp 단위로 지정하며, 이는 <N> 값으로 정의됩니다. UI에 사용 가능한 현재의 실제 너비를 반영하기 위해, 가로 모드와 세로 모드 간에 화면 방향이 전환될 때 그 너비에 해당하는 시스템 값이 변경됩니다.

흔히 이 방법은 다중 창 레이아웃의 사용 여부를 결정할 때 유용합니다. 아무리 태블릿 기기라고 해도 여러분이 가로 모드와 세로 모드 방향에 동일한 다중 창 레이아웃을 원하지는 않을 것입니다. 따라서, 이 방법을 사용하면 화면 크기와 방향 한정자를 함께 사용하는 대신, 레이아웃에 필요한 최소 너비를 지정할 수 있습니다.

사용 가능한 화면 높이 h<N>dp

예:
h720dp
h1024dp

리소스가 사용되어야 하는 최소 화면 높이를 dp 단위로 지정하며, 이는 <N> 값으로 정의됩니다. UI에 사용 가능한 현재의 실제 높이를 반영하기 위해, 가로 모드와 세로 모드 간에 화면 방향이 전환될 때 그 높이에 해당하는 시스템 값이 변경됩니다.

이 방법을 사용하여 레이아웃에 필요한 높이를 정의하는 것은 화면 크기와 방향 한정자를 함께 사용하는 대신 w<N>dp를 사용하여 필요한 너비를 정의하는 것과 마찬가지로 유용한 방법입니다. 그러나, 대개 UI는 세로로 스크롤된다는 점을 고려할 때 대부분의 앱에는 이 한정자가 필요 없습니다.

이 한정자를 사용하는 것이 화면 크기 그룹을 사용하는 것보다 더 복잡해 보일 수 있지만, UI의 요구사항을 결정하기만 한다면 실제로는 더 간단합니다. UI를 디자인할 때 여러분이 아마도 제일 신경 쓰는 부분은 핸드셋 스타일 UI와 다중 창을 사용하는 태블릿 스타일 UI 간에 애플리케이션이 전환되는 실제 크기일 것입니다. 이러한 전환의 정확한 지점은 특정한 디자인마다 다릅니다. 아마도 태블릿 레이아웃에는 720dp 너비가 필요할 것이고, 아마도 600dp라면 충분할 것이며, 480dp이나 그 사이의 특정 값일 수도 있습니다. 표 2에 있는 한정자를 사용하면, 레이아웃이 변경되는 정확한 크기를 여러분이 제어할 수 있습니다.

이러한 크기 구성 한정자에 대한 자세한 내용은, 리소스 제공 문서를 참조하세요.

구성 예시

다른 유형의 기기에 맞게 여러분의 디자인을 타겟팅할 수 있도록, 다음과 같은 일반적인 화면 너비의 수치가 제공됩니다.

  • 320dp: 일반적인 전화 화면(240x320 ldpi, 320x480 mdpi, 480x800 hdpi 등).
  • 480dp: Streak과 같은 트위너 태블릿(480x800 mdpi).
  • 600dp: 7” 태블릿(600x1024 mdpi).
  • 720dp: 10” 태블릿(720x1280 mdpi, 800x1280 mdpi 등).

표 2의 크기 한정자를 사용하면, 여러분이 원하는 숫자의 너비 및/또는 높이를 사용하여 여러분의 애플리케이션이 핸드셋 및 태블릿에 맞게 다른 레이아웃 리소스를 전환할 수 있습니다. 예를 들어, 여러분의 태블릿 레이아웃이 지원하는 사용 가능한 최소 너비가 600dp인 경우, 다음과 같은 두 세트의 레이아웃을 제공할 수 있습니다.

res/layout/main_activity.xml           # For handsets
res/layout-sw600dp/main_activity.xml   # For tablets

이 경우, 태블릿 레이아웃이 적용되기 위해서는 사용 가능한 화면 공간의 최소 너비가 600dp가 되어야 합니다.

7” 및 10” 태블릿과 같은 다양한 크기를 구분하기 위해 UI를 사용자 지정하려면, 다음과 같은 최소 너비 레이아웃을 추가로 정의할 수 있습니다.

res/layout/main_activity.xml           # For handsets (smaller than 600dp available width)
res/layout-sw600dp/main_activity.xml   # For 7” tablets (600dp wide and bigger)
res/layout-sw720dp/main_activity.xml   # For 10” tablets (720dp wide and bigger)

참고로, 위의 두 세트의 예시 리소스에서는 "최소 너비" 한정자인 sw<N>dp를 사용하며, 이 한정자는 기기의 현재 방향에 상관없이 화면 양쪽 중 최소값을 지정합니다. 따라서, sw<N>dp 사용하면, 화면 방향을 무시하고서도 레이아웃에 사용 가능한 전체 화면 크기를 간단하게 지정할 수 있습니다.

그러나 일부 경우에는 현재 사용 가능한 너비나 높이가 얼마인지를 정확히 아는 것이 레이아웃에 중요할 수도 있습니다. 예를 들어, 두 프래그먼트가 나란히 있는 창 두 개 레이아웃이 있는 경우, 기기가 가로 모드 방향에 있든 세로 모드 방향에 있든 간에, 화면의 너비가 최소 600dp가 될 때마다 이 창을 사용하려고 할 수 있습니다. 이 경우, 여러분의 리소스는 다음과 같을 수 있습니다.

res/layout/main_activity.xml         # For handsets (smaller than 600dp available width)
res/layout-w600dp/main_activity.xml  # Multi-pane (any screen with 600dp available width or more)

참고로, 두 번째 세트에서는 "사용 가능한 너비" 한정자인 w<N>dp를 사용합니다. 이런 방식으로 화면 방향에 따라 한 기기에서 실제로 양쪽 레이아웃을 사용할 수도 있습니다(사용 가능한 너비가 한 방향에서 최소 600dp이고 다른 방향에서 600dp 미만인 경우).

사용 가능한 높이가 여러분의 관심사인 경우에는 h<N>dp 한정자를 동일하게 사용할 수 있습니다. 또는, 정말로 구체적인 것을 원한다면 w<N>dph<N>dp 한정자를 조합해도 됩니다.

화면 크기 지원 선언

다른 화면 크기에 대해 레이아웃을 구현한 경우, 애플리케이션이 지원하는 화면을 매니페스트 파일에 선언하는 것도 중요합니다.

화면 크기에 대한 새로운 구성 한정자와 함께 Android 3.2에서는 <supports-screens> 매니페스트 요소에 대한 새로운 특성을 소개합니다.

android:requiresSmallestWidthDp
필요한 최소 smallestWidth를 지정합니다. smallestWidth는 애플리케이션 UI에 제공되어야 하는 화면 공간의 가장 짧은 치수이며(즉, 사용 가능한 화면의 두 치수 중에 가장 짧은 치수), 그 단위는 dp입니다. 기기가 애플리케이션과 호환되는 것으로 간주되려면, 기기의 smallestWidth가 이 값보다 크거나 같아야 합니다. (일반적으로, 여러분이 여기에 제공하는 값은 여러분의 레이아웃이 지원하는 "최소 너비"이며, 이것은 기기의 현재 방향과는 상관이 없습니다.)

예를 들어, 애플리케이션에서 최소 사용 가능 너비가 600dp인 태블릿 스타일 기기만을 지원하는 경우:

<manifest ... >
    <supports-screens android:requiresSmallestWidthDp="600" />
    ...
</manifest>

그러나, Android가 지원하는 모든 화면 크기(최소 426dp x 320dp)를 여러분의 애플리케이션이 지원하는 경우에는 이 특성을 선언할 필요가 없습니다. 왜냐하면 애플리케이션에 요구되는 최소 너비는 곧 모든 기기에서 가능한 최소 너비가 되기 때문입니다.

주의: Android 시스템은 이 특성에 신경을 쓰지 않으므로, 이 특성은 런타임에 애플리케이션의 동작 방식에 영향을 미치지 않습니다. 그 대신, Google Play와 같은 서비스에서 애플리케이션에 필터링을 활성화하기 위해 이 특성이 사용됩니다. 그러나 현재 Google Play에서는 필터링에 이 특성을 지원하지 않으므로(Android 3.2의 경우), 애플리케이션이 소형 화면을 지원하지 않는다면 여러분이 다른 크기 특성을 사용해야 합니다.

android:compatibleWidthLimitDp
이 특성을 사용하시면, 애플리케이션이 지원하는 최대 "최소 너비"를 지정하여 화면 호환성 모드를 사용자 옵션 기능으로 활성화할 수 있습니다. 사용 가능한 기기 화면의 최소 너비 쪽이 여기의 값보다 더 큰 경우, 사용자가 여전히 애플리케이션을 설치할 수 있지만, 화면 호환성 모드에서 애플리케이션을 실행하는 것이 좋습니다. 기본적으로 화면 호환성 모드는 비활성화되며 레이아웃은 일반적인 화면에 맞게 조정되지만, 사용자가 화면 호환성 모드를 켜거나 끌 수 있는 버튼이 시스템 바에 나타납니다.

참고: 대형 화면에 맞게 애플리케이션의 레이아웃이 적절히 조정된다면, 이 특성을 사용할 필요가 없습니다. 이 특성은 사용을 피하는 것이 좋으며, 그 대신 이 문서의 권장 사항에 따라 더 큰 화면에 맞게 레이아웃을 조정하는 것이 좋습니다.

android:largestWidthLimitDp
이 특성을 사용하면, 애플리케이션이 지원하는 최대 "최소 너비"를 지정하여 화면 호환성 모드를 강제로 활성화할 수 있습니다. 사용 가능한 기기 화면의 최소 너비 쪽이 여기의 값보다 더 큰 경우, 애플리케이션은 화면 호환성 모드에서 실행되며 사용자가 이것을 비활성화할 수 없습니다.

참고: 대형 화면에 맞게 애플리케이션의 레이아웃이 적절히 조정된다면, 이 특성을 사용할 필요가 없습니다. 이 특성은 사용을 피하는 것이 좋으며, 그 대신 이 문서의 권장 사항에 따라 더 큰 화면에 맞게 레이아웃을 조정하는 것이 좋습니다.

주의: Android 3.2 이상을 위한 앱을 개발 중인 경우, 위에 나열된 특성과 이전의 화면 크기 특성을 조합하여 사용해서는 안 됩니다. 새 특성과 이전의 크기 특성을 함께 사용할 경우 예상치 못한 동작이 발생할 수도 있습니다.

이러한 각 특성에 대한 자세한 내용은 위의 개별 링크를 누르세요.

모범 사례

다중 화면 지원의 목표는 Android가 지원하는 일반화된 모든 화면 구성에서 올바로 작동하고 적절히 표시되는 애플리케이션을 만드는 것입니다. 이 문서의 이전 섹션들에서는 Android가 화면 구성에 맞게 여러분의 애플리케이션을 적응시키는 방법과 여러분이 다른 여러 화면 구성에서 애플리케이션의 모양을 사용자 지정하는 방법에 대해 설명합니다. 이 섹션에서는 다른 여러 화면 구성에서 애플리케이션이 적절히 확대/축소되도록 보장하는 추가적인 팁과 기술에 대해 설명합니다.

다음은 다른 여러 화면에서 애플리케이션이 적절히 표시되도록 보장할 수 있는 간단한 검사 목록입니다.

  1. XML 레이아웃 파일에서 치수를 지정할 때 wrap_content, match_parent 또는 dp 단위를 사용합니다.
  2. 하드코딩된 픽셀 값을 애플리케이션 코드에 사용하지 않습니다.
  3. AbsoluteLayout을 사용하지 않습니다(지원 중단됨).
  4. 다른 화면 밀도에 대체 비트맵 드로어블을 제공합니다.

다음 섹션에서는 더 자세히 설명합니다.

1. 레이아웃 치수에는 wrap_content, match_parent 또는 dp를 사용합니다.

XML 레이아웃 파일에서 뷰를 위해 android:layout_widthandroid:layout_height를 정의할 경우, "wrap_content", "match_parent" 또는 dp 단위를 사용하면 현재 기기 화면에서 이 뷰에 적절한 크기가 부여되도록 보장할 수 있습니다.

예를 들어, layout_width="100dp"인 뷰는 중간 밀도 화면에서 100 픽셀 너비로 측정되고 고밀도 화면에서는 시스템이 이것을 최대 150 픽셀로 확대하므로, 이 뷰는 화면에서 물리적으로 거의 동일한 공간을 차지합니다.

마찬가지로, 텍스트 크기를 정의하는 경우 여러분은 sp(배율 독립적 픽셀)를 선호해야 합니다. sp 배율은 사용자 설정에 따라 다르며, 시스템은 dp의 경우와 동일하게 크기를 확대/축소합니다.

2. 하드코딩된 픽셀 값을 애플리케이션 코드에 사용하지 않습니다.

성능상의 이유로 그리고 코드를 단순화하기 위해 Android 시스템에서는 치수 또는 좌표값을 표현하기 위한 표준 단위로 픽셀을 사용합니다. 즉, 뷰의 치수는 항상 픽셀을 사용하여 코드에 표현되지만, 언제나 현재 화면 밀도를 기준으로 합니다. 예를 들어, myView.getWidth()가 10을 반환하는 경우 현재 화면에서 뷰는 10 픽셀 너비가 되지만, 밀도가 더 높은 화면 기기에서는 15 값이 반환될 수도 있습니다. 현재 화면 밀도에 맞게 사전에 확대/축소되지 않은 비트맵에서 작동하도록 여러분의 애플리케이션 코드에 픽셀 값을 사용하는 경우, 확대/축소되지 않은 비트맵 소스와 일치하도록 자신의 코드에서 픽셀 값을 확대/축소해야 할 수 있습니다.

여러분의 애플리케이션이 비트맵을 조작하거나 런타임에 픽셀 값을 처리하는 경우, 추가적인 밀도 고려 사항에 관한 아래 섹션을 참조하세요.

3. AbsoluteLayout을 사용하지 않습니다.

다른 레이아웃 위젯과 달리 AbsoluteLayout에서는 하위 뷰를 배치하기 위해 고정 위치를 강제로 사용합니다. 이 경우 다른 디스플레이에서는 사용자 인터페이스가 잘 작동하지 않을 수 있습니다. 이 때문에 Android 1.5(API 레벨 3)에서는 AbsoluteLayout에 대한 지원이 중단되었습니다.

그 대신, 하위 뷰를 배치하기 위해 상대적 배치를 사용하는 RelativeLayout을 사용해야 합니다. 예를 들어, 텍스트 위젯의 "오른쪽에" 버튼 위젯이 나타나도록 지정할 수 있습니다.

4. 크기 및 밀도별 리소스를 사용합니다.

시스템은 현재 화면 구성에 따라 레이아웃과 드로어블 리소스를 확대/축소하지만, 여러분이 다른 화면 크기에서 UI를 조정할 수도 있고 다른 밀도에 맞게 최적화된 비트맵 드로어블을 제공할 수도 있습니다. 이 경우 이 문서 앞부분의 정보가 기본적으로 반복됩니다.

다양한 화면 구성에서 애플리케이션이 어떻게 보이는지를 정확히 제어하려면, 구성별 리소스 디렉터리에서 여러분의 레이아웃과 비트맵 드로어블을 조정합니다. 예를 들어, 중간 밀도 및 고밀도 화면에서 표시하려는 아이콘을 가정해 봅시다. 아이콘을 두 가지 다른 크기(예: 중간 밀도에서 100x100, 고밀도에서 150x150)로 만들고, 알맞은 한정자를 사용하여 두 변형 아이콘을 적절한 디렉터리에 넣습니다.

res/drawable-mdpi/icon.png   //for medium-density screens
res/drawable-hdpi/icon.png   //for high-density screens

참고: 밀도 한정자가 디렉터리 이름에 정의되지 않은 경우, 시스템은 다음과 같이 가정합니다. 즉, 이 디렉터리의 리소스는 기준 중간 밀도에 맞게 디자인되며, 다른 밀도에 대해서는 리소스가 적절히 확대/축소됩니다.

유효한 구성 한정자에 대한 자세한 내용은, 이 문서 앞부분의 구성 한정자 사용을 참조하세요.

추가적인 밀도 고려 사항

이 섹션에서는 다른 화면 밀도에서 Android가 비트맵 드로어블을 확대/축소하는 방법과 다른 밀도에서 비트맵이 그려지는 방식을 여러분이 제어할 수 있는 방법에 대해 자세히 설명합니다. 애플리케이션이 다른 화면 밀도에서 실행되거나 또는 애플리케이션에서 그래픽을 조작할 때 문제가 발생한 경우가 아니라면, 이 섹션의 정보는 대부분의 애플리케이션에서 중요치 않습니다.

런타임에 그래픽을 조작할 때 어떻게 해야 다중 밀도를 지원할 수 있는지를 잘 이해하려면, 시스템이 비트맵의 적절한 확대/축소를 보장하는 방식을 이해해야 합니다.

  1. 리소스의 사전 확대/축소(예: 비트맵 드로어블)

    현재 화면 밀도에 따라 시스템은 여러분의 애플리케이션에서 크기별 또는 밀도별 리소스를 사용하고 이 리소스를 확대/축소 없이 그대로 표시합니다. 올바른 밀도로 리소스를 사용할 수 없는 경우, 시스템은 기본 리소스를 로드하고 이 리소스를 현재 화면 밀도에 맞게 확대하거나 축소합니다. 시스템은 다음과 같이 가정합니다. 즉, 리소스가 밀도별 리소스 디렉터리로부터 로드된 것이 아니라면, 기본 리소스(구성 한정자가 없는 디렉터리의 리소스)는 기준 화면 밀도(mdpi)에 맞게 디자인됩니다. 따라서 현재 화면 밀도에 맞는 적절한 크기로 비트맵을 조정할 경우에 시스템이 사전 확대/축소를 사용합니다.

    사전 확대/축소된 리소스의 치수를 요청하면, 시스템은 확대/축소된 후에 치수를 나타내는 값을 반환합니다. 예를 들어, mdpi 화면에서 50x50 픽셀로 디자인된 비트맵은 hdpi 화면에서 75x75 픽셀로 조정되며(hdpi의 대체 리소스가 없는 경우) 시스템이 이와 같이 크기를 보고합니다.

    Android에서 리소스를 사전 확대/축소해서는 안되는 몇몇 경우가 있습니다. 사전 확대/축소를 피하는 가장 쉬운 방법은 nodpi 구성 한정자가 있는 리소스 디렉터리에 리소스를 넣는 것입니다. 예:

    res/drawable-nodpi/icon.png

    시스템이 이 폴더의 icon.png 비트맵을 사용하는 경우에는 현재 기기 밀도에 따라 비트맵을 확대/축소하지 않습니다.

  2. 픽셀 치수 및 좌표의 자동 확대/축소

    매니페스트에서 android:anyDensity"false"로 설정하거나 프로그래밍 방식으로 Bitmap에 대해 inScaled"false"로 설정하여, 애플리케이션에서 사전 확대/축소를 비활성화할 수 있습니다. 이 경우 시스템은 그리기 시에 절대 픽셀 좌표와 픽셀 치수 값을 자동으로 확대/축소합니다. 이렇게 하면 픽셀로 정의된 화면 요소들이 기준 화면 밀도(mdpi)에서 표시되는 것과 거의 동일한 물리적 크기로 표시되게 줍니다. 시스템은 이러한 확대/축소 동작을 애플리케이션에 투명하게 처리하며, 물리적 픽셀 치수가 아니라 확대/축소된 픽셀 치수를 애플리케이션에 보고합니다.

    예를 들어, 480x800인 WVGA 고밀도 화면(기존의 HVGA 화면과 거의 동일한 크기)이 달린 기기가 있고, 사전 확대/축소가 비활성화된 애플리케이션에서 이 기기가 실행된다고 가정해 봅시다. 이 경우 시스템은 화면 치수를 쿼리할 때 애플리케이션을 "속이고" 320x533(화면 밀도의 근사적 mdpi 변환값)을 보고합니다. 그리고 애플리케이션이 그리기 작업을 수행할 때(예: 사각형을 (10,10)에서 (100, 100)으로 무효화할 때), 시스템은 해당 좌표를 적절한 크기로 확대/축소하고 실제로는 영역 (15,15)를 (150, 150)으로 무효화하여 좌표를 변환합니다. 확대/축소된 비트맵을 애플리케이션이 직접 조작하는 경우, 이러한 불일치는 예상치 못한 동작을 유발할 수 있습니다. 그러나 이것은 애플리케이션의 성능을 최대한으로 유지하기 위한 적절한 타협으로 간주됩니다. 이러한 상황이 발생하는 경우 dp 단위를 픽셀 단위로 변환에 관한 다음 섹션을 참조하세요.

    일반적으로 사전 확대/축소를 비활성화해서는 안 됩니다. 다중 화면을 지원하는 최선의 방법은 위의 다중 화면 지원 방법에 설명된 기본적인 기술을 따르는 것입니다.

여러분의 애플리케이션이 비트맵을 조작하거나 약간 다른 방식으로 화면의 픽셀과 직접 상호작용하는 경우, 다른 화면 밀도를 지원하기 위한 추가적인 조치가 필요할 수 있습니다. 예를 들어, 손가락이 지나가는 픽셀 수를 카운트하여 터치 제스처에 반응하려는 경우에는, 실제 픽셀을 사용하는 대신 적절한 밀도 독립적 픽셀 값을 사용해야 합니다.

런타임에 생성된 비트맵 객체를 확대/축소

그림 5. 사전 확대/축소된 비트맵과 자동 확대/축소된 비트맵의 비교.

여러분의 애플리케이션이 메모리 내 비트맵(Bitmap 객체)을 만드는 경우 시스템은 다음과 같이 가정합니다. 즉, 기본적으로 이 비트맵은 기준 중간 밀도 화면에 맞게 디자인되고, 그리기 시에 비트맵이 자동으로 확대/축소됩니다. 미지정된 밀도 속성이 비트맵에 있는 경우, 시스템은 "자동 확대/축소"를 Bitmap에 적용합니다. 현재 기기의 화면 밀도를 적절히 고려하지 않고 비트맵의 밀도 속성을 지정하지 않은 경우, 대체 리소스를 제공하지 않을 때와 동일한 아티팩트가 자동 확대/축소로 인해 발생할 수 있습니다.

런타임에 생성된 Bitmap의 확대/축소 여부를 제어하려면, setDensity()로 비트맵의 밀도를 지정할 수 있으며, DisplayMetrics(예: DENSITY_HIGH 또는 DENSITY_LOW)로부터 밀도 상수를 전달할 수 있습니다.

BitmapFactory를 사용하여 Bitmap을 만드는 중에(예: 파일 또는 스트림에서), BitmapFactory.Options를 사용하여 비트맵의 속성을 정의할 수 있습니다. 이 속성은 시스템에서 비트맵의 확대/축소 여부나 그 방법을 결정하는 것입니다. 예를 들어, inDensity 필드를 사용하면 비트맵이 디자인되는 밀도를 정의할 수 있고, inScaled 필드를 사용하면 현재 기기의 화면 밀도와 일치하도록 비트맵의 확대/축소 여부를 지정할 수 있습니다.

inScaled 필드를 false로 설정한 경우, 시스템이 비트맵에 적용하는 모든 사전 확대/축소를 비활성화하세요. 그러면 그리기 시에 시스템이 비트맵을 자동 확대/축소합니다. 사전 확대/축소 대신 자동 확대/축소를 사용하면 더 많은 CPU가 사용될 수 있지만 메모리는 더 적게 사용됩니다.

그림 5는 고밀도 화면에서 저밀도(120), 중간 밀도(160) 및 고밀도(240) 비트맵을 로드할 때 사전 확대/축소 및 자동 확대/축소 메커니즘의 결과를 보여줍니다. 모든 비트맵은 현재 화면 밀도와 일치하도록 확대/축소 중이기 때문에 그 차이점은 미세하지만, 그리기 시에 비트맵이 사전 확대/축소되거나 자동 확대/축소되는지 여부에 따라서는 확대/축소된 비트맵의 모양이 약간 다릅니다.

참고: Android 3.0 이상에서는 그래픽 프레임워크가 개선되었기 때문에, 사전 확대/축소된 비트맵과 자동 확대/축소된 비트맵 사이에 눈에 띄는 차이점이 없어야 합니다.

dp 단위를 픽셀 단위로 변환

일부 경우에는 dp 단위로 치수를 표현한 다음 이것을 픽셀 단위로 변환할 필요가 있습니다. 사용자가 손가락을 최소 16픽셀 만큼 움직였을 때 스크롤 또는 플링(fling) 제스처가 인식되는 애플리케이션을 가정해 보겠습니다. 기준 화면에서는 이 제스처가 인식되려면, 10분의 1인치(또는 2.5 mm)에 해당하는 16 pixels / 160 dpi만큼 사용자가 손가락을 움직여야 합니다. 고밀도 화면(240dpi)이 달린 기기에서는 15분의 1인치(또는 1.7 mm)에 해당하는 16 pixels / 240 dpi만큼 사용자가 손가락을 움직여야 합니다. 거리가 훨씬 더 짧아지므로 애플리케이션이 더 민감하게 사용자에게 표시됩니다.

이 문제를 해결하려면 제스처 임계값을 dp 단위의 코드로 표현한 다음, 이것을 실제 픽셀로 변환해야 합니다. 예:

// The gesture threshold expressed in dp
private static final float GESTURE_THRESHOLD_DP = 16.0f;

// Get the screen's density scale
final float scale = getResources().getDisplayMetrics().density;
// Convert the dps to pixels, based on density scale
mGestureThreshold = (int) (GESTURE_THRESHOLD_DP * scale + 0.5f);

// Use mGestureThreshold as a distance in pixels...

DisplayMetrics.density 필드는 dp 단위를 픽셀 단위로 변환하는 데 사용할 배율을 지정하며, 이 경우 현재 화면 밀도를 따릅니다. 중간 밀도 화면에서 DisplayMetrics.density는 1.0에 해당하고, 고밀도 화면에서는 1.5, 초고밀도 화면에서는 2.0, 저밀도 화면에서는 0.75에 해당합니다. 이 수치는 현재 화면의 실제 픽셀 카운트를 얻기 위해 dp 단위를 배가시키는 데 사용되는 배율입니다. (그런 다음, 정수로 변환할 때 수치를 반올림하려면 0.5f를 추가합니다.) 자세한 내용은 DisplayMetrics 클래스를 참조하세요.

그러나, 이러한 종류의 이벤트에 대해 임의 임계값을 정의하는 대신, ViewConfiguration에서 제공되는 사전 확대/축소된 구성 값을 사용해야 합니다.

사전 확대/축소된 구성 값 사용

ViewConfiguration 클래스를 사용하여 Android 시스템에 사용되는 일반 거리, 속도 및 시간에 액세스할 수 있습니다. 예를 들어, 프레임워크에 의해 스크롤 임계값으로 사용되는 픽셀 단위의 거리는 getScaledTouchSlop()으로 구할 수 있습니다.

private static final int GESTURE_THRESHOLD_DP = ViewConfiguration.get(myContext).getScaledTouchSlop();

getScaled 접두사로 시작하는 ViewConfiguration의 메서드들은 현재 화면 밀도에 상관없이 적절히 표시되도록 픽셀 단위의 값을 반환합니다.

다중 화면에서 애플리케이션 테스트 방법

그림 6. 화면 지원을 테스트하기 위한 AVD 세트.

애플리케이션을 게시하기 전에, 지원되는 모든 화면 크기 및 밀도에서 애플리케이션을 철저히 테스트해야 합니다. Android SDK에는 사용 가능한 에뮬레이터 스킨이 포함되며, 이 스킨은 애플리케이션이 실행될 가능성이 있는 일반적인 화면 구성의 크기와 밀도를 복제합니다. 또한 에뮬레이터 스킨의 기본 크기, 밀도 및 해상도를 수정하여 특정 화면의 특성을 복제할 수도 있습니다. 에뮬레이터 스킨과 추가적인 사용자 지정 구성을 사용하면 가능한 모든 화면 구성을 테스트할 수 있으므로, 단지 여러분이 애플리케이션의 화면 지원을 테스트할 목적으로 다양한 기기를 구입할 필요는 없습니다.

애플리케이션의 화면 지원을 테스트하기 위한 환경을 설정하려면, 일련의 AVD(Android Virtual Devices)를 만들어야 하며, 이를 위해 애플리케이션이 지원하려는 화면 크기와 밀도를 에뮬레이션하는 에뮬레이터 스킨과 화면 구성을 사용해야 합니다. 그러기 위해 AVD Manager를 사용하여 AVD를 만들고 이것을 그래픽 인터페이스로 시작할 수 있습니다.

Android SDK Manager를 시작하려면, Android SDK 디렉터리에서 SDK Manager.exe를 실행하거나(Windows에만 해당) 또는 <sdk>/tools/ 디렉터리에서 android를 실행합니다(모든 플랫폼에 해당). 그림 6은 다양한 화면 구성을 테스트하기 위해 AVD가 선택된 AVD Manager를 나타냅니다.

표 3은 Android SDK에서 사용 가능한 다양한 에뮬레이터 스킨을 나타내며, 이들 스킨을 사용하여 가장 일반적인 화면 구성을 에뮬레이트할 수 있습니다.

애플리케이션을 테스트하기 위해 AVD를 만들고 사용하는 방법에 대한 자세한 내용은, AVD Manager를 사용하는 AVD 관리를 참조하세요.

표 3. Android SDK의 에뮬레이터 스킨에서 사용 가능한 다양한 화면 구성(굵은 글꼴로 표시)과 기타 대표 해상도.

저밀도(120), ldpi 중간 밀도(160), mdpi 고밀도(240), hdpi 초고밀도(320), xhdpi
소형 화면 QVGA (240x320) 480x640
보통 화면 WQVGA400 (240x400)
WQVGA432 (240x432)
HVGA (320x480) WVGA800 (480x800)
WVGA854 (480x854)
600x1024
640x960
대형 화면 WVGA800** (480x800)
WVGA854** (480x854)
WVGA800* (480x800)
WVGA854* (480x854)
600x1024
초대형 화면 1024x600 WXGA (1280x800)
1024x768
1280x768
1536x1152
1920x1152
1920x1200
2048x1536
2560x1536
2560x1600
* 이 구성을 에뮬레이트하려면, WVGA800 또는 WVGA854 스킨을 사용하는 AVD를 만들 때 160의 사용자 지정 밀도를 지정합니다.
* 이 구성을 에뮬레이트하려면, WVGA800 또는 WVGA854 스킨을 사용하는 AVD를 만들 때 120의 사용자 지정 밀도를 지정합니다.
† 이 스킨은 Android 3.0 플랫폼에서 사용이 가능합니다.

지정된 모든 화면 구성을 지원하는 활성 기기의 개수를 보려면, 화면 크기와 밀도 대시보드를 참조하세요.

그림 7. AVD Manager에서 AVD를 시작할 때 설정할 수 있는 크기와 밀도 옵션.

또한 실제 기기와 거의 비슷한 물리적 크기에서 에뮬레이터가 실행되도록 설정하고, 애플리케이션을 테스트하는 것이 좋습니다. 이렇게 하면 다양한 크기와 밀도에서 훨씬 더 쉽게 결과를 비교할 수 있습니다. 그러기 위해서는 컴퓨터 모니터의 근사적 밀도(dpi 단위)를 알아야 합니다(예: 30" Dell 모니터는 밀도가 약 96 dpi입니다). AVD Manager에서 AVD를 시작할 때, 그림 7에 나타난 것처럼 시작 옵션(Launch Options)에서 에뮬레이터의 화면 크기와 모니터 dpi를 지정할 수 있습니다.

기본 제공 스킨에 의해 지원되지 않는 해상도나 밀도가 사용되는 화면에서 애플리케이션을 테스트하려면, 사용자 지정 해상도나 밀도를 사용하는 AVD를 만들면 됩니다. AVD Manager에서 AVD를 만드는 경우에는 '기본 제공 스킨'을 선택하는 대신 '해상도'를 지정합니다.

명령줄에서 AVD를 시작하는 경우에는 -scale 옵션으로 에뮬레이터의 배율을 지정할 수 있습니다. 예:

emulator -avd <avd_name> -scale 96dpi

에뮬레이터의 크기를 상세 지정하려면, 원하는 배율을 나타내는 0.1 ~ 3 사이의 숫자를 -scale 옵션에 전달하면 됩니다.

명령줄에서 AVD를 만드는 방법에 대한 자세한 내용은, 명령줄에서 AVD 관리를 참조하세요.