본문 바로가기

나의 플랫폼/안드로이드

[Android] xml 소스 폴더 관리

336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

표 2. 구성 한정자 이름입니다.

구성한정자 값설명
MCC 및 MNC예:
mcc310
mcc310-mnc004
mcc208-mnc00
등.

이동통신 국가 코드(MCC)에 선택적으로 이동통신 네트워크 코드(MNC)가 이어지는 형태로, 기기의 SIM 카드에서 가져옵니다. 예를 들어, mcc310은 모든 이동통신사를 포함한 미국이고, mcc310-mnc004는 Verizon을 사용하는 미국, mcc208-mnc00은 Orange를 사용하는 프랑스입니다.

기기가 무선 연결(GSM 전화)을 사용할 경우, MCC와 MNC 값은 SIM 카드에서 가져옵니다.

MCC만 단독으로 사용할 수도 있습니다(예를 들어, 애플리케이션에 국가별 합법적 리소스를 포함하는 경우). 언어에 기초해서만 지정해야 할 경우, 언어 및 지역 한정자를 대신 사용합니다(아래에 설명). MCC와 MNC 한정자를 사용할 경우, 조심해서 사용하고 예상한 대로 작동하는지 테스트해야 합니다.

또한, 구성 필드 mcc와 mnc를 참조하십시오. 이 구성 필드는 각각 이동통신 국가 코드와 이동통신 네트워크 코드를 나타냅니다.

언어 및 지역예:
en
fr
en-rUS
fr-rFR
fr-rCA
등.

언어는 두 글자의 ISO 639-1 언어 코드로 정의되고, 뒤이어 두 글자의 ISO 3166-1-alpha-2 지역 코드가 선택적으로 따라옵니다(소문자 "r" 뒤에 붙음).

코드는 대소문자를 구별하지 않습니다r 접두사는 지역 부분을 구별하기 위해 사용합니다. 지역만 지정할 수는 없습니다.

사용자가 시스템 설정에서 언어를 변경할 경우 애플리케이션 수명 중에 변경될 수 있습니다. 런타임에서 애플리케이션에 어떤 영향을 미치는지 자세히 알아보려면 런타임 변경 처리를 참조하십시오.

다른 여러 언어에 맞게 애플리케이션을 지역화하기 위한 전체 지침은 지역화를 참조하십시오.

또한, 현재 로케일을 나타내는 locale 구성 필드도 참조하십시오.

레이아웃 방향ldrtl
ldltr

애플리케이션의 레이아웃 방향입니다. ldrtl는 "오른쪽에서 왼쪽 방향 레이아웃"을 나타냅니다. ldltr는 "왼쪽에서 오른쪽 방향 레이아웃"을 나타내고 기본 암시적 값입니다.

이는 레이아웃이나 드로어블, 값 등의 모든 리소스에 적용할 수 있습니다.

예를 들어, 아랍어에 대한 특정 레이아웃을 제공하고 다른 "오른쪽에서 왼쪽으로 쓰는" 언어(히브리어 또는 페르시아어)에 제네릭 레이아웃을 제공하고 싶다면 다음과 같이 해야 합니다.

res/
    layout/   
        main.xml  (Default layout)
    layout-ar/  
        main.xml  (Specific layout for Arabic)
    layout-ldrtl/  
        main.xml  (Any "right-to-left" language, except
                  for Arabic, because the "ar" language qualifier
                  has a higher precedence.)

참고: 앱에서 오른쪽에서 왼쪽 레이아웃 기능을 활성화하려면supportsRtl을 "true"로 설정하고 targetSdkVersion을 17 이상으로 설정해야 합니다.

API 레벨 17에서 추가되었습니다.

smallestWidthsw<N>dp

예:
sw320dp
sw600dp
sw720dp
등.

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

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

기기의 smallestWidth는 화면 장식과 시스템 UI를 감안합니다. 예를 들어, 화면 상에서 최소 너비의 축 주변 공간을 차지하는 영구 UI 요소가 있다면, 시스템은 smallestWidth를 실제 화면 크기보다 작게 선언합니다. 이것은 개발자의 UI가 사용할 수 없는 화면 픽셀이기 때문입니다. 따라서 개발자가 사용하는 값은 레이아웃에서 요구하는 실제 최소 치수여야 합니다(일반적으로 이 값은 화면의 현재 방향과 관계없이 레이아웃이 지원하는 "최소 너비"가 됩니다.).

다음의 몇몇 값은 보편적인 화면 크기에 대하여 사용할 수 있습니다.

  • 화면 크기 320에 화면 구성이 아래와 같은 기기:
    • 240x320ldpi(QVGA 핸드셋)
    • 320x480mdpi(핸드셋)
    • 480x800hdpi(고화질 핸드셋)
  • 480x800mdpi(태블릿/핸드셋) 등의 화면에는 480을 사용합니다.
  • 600x1024mdpi (7인치 태블릿) 등의 화면에는 600을 사용합니다.
  • 720x1280mdpi (10인치 태블릿) 등의 화면에는 720을 사용합니다.

애플리케이션이 smallestWidth 한정자의 여러 값이 포함된 여러 리소스 디렉터리를 제공하면, 시스템은 기기의 smallestWidth에 가장 가까운(그러나 이를 초과하지 않는) 값을 사용합니다.

API 레벨 13에서 추가되었습니다.

이외에도 애플리케이션과 호환되는 최소한의 smallestWidth를 선언하는android:requiresSmallestWidthDp 속성과 기기의 smallestWidth 값을 보유한 smallestScreenWidthDp 구성 필드도 참조하십시오.

여러 가지 화면에 맞는 디자인과 한정자 사용에 관한 자세한 정보는 다중 화면 지원 개발자 가이드를 참조하십시오.

이용 가능한 너비w<N>dp

예:
w720dp
w1024dp
등.

리소스를 사용해야 하는 dp 단위에서 최소 이용 가능한 화면 너비를 지정합니다. 이는 <N> 값이 정의합니다. 이 구성 값은 현재 실제 너비에 맞추기 위해 화면 방향이 가로와 세로 사이를 오가며 바뀔 때 변경됩니다.

애플리케이션이 이 구성에 대해 서로 다른 값이 포함된 여러 개의 리소스 디렉터리를 제공하면, 시스템은 기기의 현재 화면 너비에 가장 가까운(그러나 이를 초과하지 않는) 값을 사용합니다. 이 값은 화면 장식을 감안한 것이므로, 기기의 왼쪽이나 오른쪽 가장자리에 영구 UI 요소가 있을 경우, 기기는 이러한 UI 요소를 감안하여 애플리케이션의 이용 가능한 공간을 줄여서 실제 화면 크기보다 작은 너비 값을 사용합니다.

API 레벨 13에서 추가되었습니다.

현재 화면 너비를 보유한 screenWidthDp 구성 필드도 참조하십시오.

여러 가지 화면에 맞는 디자인과 한정자 사용에 관한 자세한 정보는 다중 화면 지원 개발자 가이드를 참조하십시오.

이용 가능한 높이h<N>dp

예:
h720dp
h1024dp
등.

리소스가 사용되어야 하는 최소한의 사용 가능한 화면 높이를 "dp" 단위로 나타냅니다. 이는 <N> 값이 정의합니다. 이 구성 값은 현재 실제 높이에 맞추기 위해 화면 방향이 가로와 세로 사이를 오가며 바뀔 때 변경됩니다.

애플리케이션이 이 구성에 대해 서로 다른 값이 포함된 여러 개의 리소스 디렉터리를 제공하면, 시스템은 기기의 현재 화면 높이에 가장 가까운(그러나 이를 초과하지 않는) 값을 사용합니다. 이 값은 화면 장식을 감안한 것이므로, 기기의 상단이나 하단 가장자리에 영구 UI 요소가 있을 경우, 기기는 이러한 UI 요소를 감안하여 애플리케이션의 이용 가능한 공간을 줄여서 실제 화면 크기보다 작은 높이 값을 사용합니다. 상태 표시줄에 고정되지 않은 화면 장식(예를 들어 전화 상태 표시줄은 전체 화면에서 숨길 수 있음)은 여기에서 감안하지 않았고, 제목 표시줄이나 작업 모음 등의 창 장식도 감안되지 않았으므로, 애플리케이션 입장에서는 자신이 지정한 것보다 어느 정도 작은 공간을 받아들일 대비를 해야 합니다.

API 레벨 13에서 추가되었습니다.

현재 화면 너비를 보유한 screenHeightDp 구성 필드도 참조하십시오.

여러 가지 화면에 맞는 디자인과 한정자 사용에 관한 자세한 정보는 다중 화면 지원 개발자 가이드를 참조하십시오.

화면 크기small
normal
large
xlarge
  • small: 저밀도 QVGA 화면과 비슷한 크기의 화면입니다. 작은 화면의 최소 레이아웃 크기는 약 320x426 dp단위입니다. 이 화면의 예시로는 QVGA 저밀도 및 VGA 고밀도가 있습니다.
  • normal: 중밀도 HVGA 화면과 비슷한 크기의 화면입니다. 정상 화면의 최소 레이아웃 크기는 약 320x470 dp 단위입니다. 이 화면의 예로는 WQVGA 저밀도, HVGA 중밀도, WVGA 고밀도 등이 있습니다.
  • large: 중밀도 VGA 화면과 비슷한 크기의 화면입니다. 큰 화면의 최소 레이아웃 크기는 약 480x640 dp 단위입니다. 이 화면의 예시로는 VGA 및 WVGA 중밀도 화면이 있습니다.
  • xlarge: 일반적인 중밀도 HVGA 화면보다 상당히 큰 화면을 말합니다. 초대형 화면의 최소 레이아웃 크기는 약 720x960 dp 단위입니다. 대부분의 경우, 초대형 화면 기기는 주머니에 넣어 다니기에 너무 큽니다. 따라서 태블릿 스타일의 기기일 가능성이 높습니다. API 레벨 9에서 추가되었습니다.

참고: 크기 한정자를 사용하더라도 해당 리소스가 그 크기의 화면 전용이라는 뜻은 아닙니다. 현재 기기 구성과 더욱 잘 맞는 한정자가 포함된 대체 리소스를 제공하지 않으면, 시스템이 가장 잘 일치하는 리소스를 사용합니다.

주의: 모든 리소스가 현재 화면보다  크기 한정자를 사용하는 경우, 시스템은 리소스를 사용하지 않으며 애플리케이션은 런타임에 작동이 중단됩니다(예를 들어, 모든 레이아웃 리소스에 xlarge 한정자가 태그되어 있지만 기기는 일반 크기 화면일 경우 ).

API 레벨 4에서 추가되었습니다.

자세한 정보는 다중 화면 지원을 참조하십시오.

screenLayout 구성 필드도 참조하십시오. 이것은 화면이 소형, 일반 크기 또는 대형인지를 나타냅니다.

화면 비율long
notlong
  • long: WQVGA, WVGA, FWVGA 등의 긴 화면
  • notlong: QVGA, HVGA 및 VGA 등의 길지 않은 화면

API 레벨 4에서 추가되었습니다.

이것은 순전히 화면 비율에만 기초합니다("긴" 화면이 더 넓습니다). 이는 화면 방향과 관계가 없습니다.

screenLayout도 참조하십시오. 이것은 화면이 긴 화면인지 여부를 나타냅니다.

화면 방향port
land
  • port: 기기가 세로 방향(수직)입니다.
  • land: 기기가 가로 방향(수평)입니다.

이것은 사용자가 화면을 돌리는 경우 애플리케이션 수명 중에 변경될 수 있습니다. 이것이 런타임에 애플리케이션에 어떤 영향을 미치는지 알아보려면 런타임 변경 처리를 참조하십시오.

orientation 구성 필드도 참조하십시오. 이는 현재 기기 방향을 나타냅니다.

UI 모드car
desk
television
appliancewatch
  • car: 기기가 차량용 도크에서 표시되고 있습니다.
  • desk: 기기가 데스크용 도크에서 표시되고 있습니다.
  • television: 기기가 텔레비전에서 표시되고 있으며, UI가 큰 화면에 있고 사용자가 여기에서 멀리 떨어져 있는 "텐 풋(ten foot)" 환경을 제공하고 있습니다. 이는 주로 DPAD 또는 기타 비-포인터 상호 작용 주변을 가리킵니다.
  • appliance: 기기가 가전 제품 역할을 하고 있으며, 디스플레이 화면이 없습니다.
  • watch: 기기에 디스플레이 화면이 있고 손목에 착용됩니다.

API 레벨 8에서 추가되었고, 텔레비전은 API 13에서, 시계는 API 20에서 추가되었습니다.

기기가 도크에 삽입되거나 제거될 때 앱이 응답하는 방식에 관한 정보는 도킹 상태 및 유형 판별과 모니터링을 읽어보십시오.

이것은 사용자가 기기를 도크에 놓는 경우 애플리케이션 수명 중에 변경될 수 있습니다. 이러한 모드 중 몇 가지는 UiModeManager를 사용하여 활성화 또는 비활성화할 수 있습니다. 이것이 런타임에 애플리케이션에 어떤 영향을 미치는지 알아보려면 런타임 변경 처리를 참조하십시오.

야간 모드night
notnight
  • night: 야간
  • notnight: 주간

API 레벨 8에서 추가되었습니다.

이것은 야간 모드가 자동 모드인 상태(기본)에서 애플리케이션의 수명 중에 변경될 수 있습니다. 이 경우 모드는 하루 중 시간대를 기반으로 변경됩니다. 이 모드는 UiModeManager를 사용하여 활성화 또는 비활성화할 수 있습니다. 이것이 런타임 중 애플리케이션에 어떤 영향을 미치는지 알아보려면런타임 변경 처리를 참조하십시오.

화면 픽셀 밀도(dpi)ldpi
mdpi
hdpi
xhdpi
xxhdpi
xxxhdpi
nodpi
tvdpi
  • ldpi: 저밀도 화면, 약 120dpi.
  • mdpi: 중밀도(일반적인 HVGA에서) 화면, 약 160dpi.
  • hdpi: 고밀도 화면, 약 240dpi.
  • xhdpi: 초고밀도 화면, 약 320dpi. API 레벨 8에서 추가되었습니다.
  • xxhdpi: 슈퍼 초고밀도 화면, 약 480dpi. API 레벨 16에서 추가되었습니다.
  • xxxhdpi: 울트라 슈퍼 초고밀도 화면 사용(시작 관리자 아이콘만 해당, 다중 화면 지원의 참고를 참조하십시오), 약 640dpi. API 레벨 18에서 추가되었습니다.
  • nodpi: 이것은 기기 밀도에 일치하도록 크기를 조정하고자 하지 않는 비트맵 리소스에 사용할 수 있습니다.
  • tvdpi: Mdpi와 hdpi 사이 어딘가에 해당되는 화면, 약 213dpi. 이것은 "기본" 밀도 그룹으로 간주되지 않습니다. 이는 대체로 텔레비전용으로 만들어진 것이며 대부분의 앱에는 필요하지 않는 것이 정상입니다. mdpi 및 hdpi만 제공하면 대부분의 앱에는 충분하고 시스템이 필요에 따라 크기를 조정해줍니다. 이 한정자는 API 레벨 13과 함께 도입되었습니다.

여섯 가지 기본 밀도간에 3:4:6:8:12:16 비율 척도가 있습니다(tvdpi 밀도는 무시). 그러므로 ldpi의 9x9 비트맵은 mdpi에서 12x12이고, hdpi에서 18x18, xhdpi에서 24x24 등, 이런 식으로 적용됩니다.

이미지 리소스가 텔레비전이나 특정 기기에서 제대로 보이지 않는다고 결정하고 tvdpi 리소스를 사용하려 할 경우, 배율은 1.33*mdpi입니다. 예를 들어, mdpi 화면의 100px x 100px 이미지는 tvdpi에서 133px x 133px가 되어야 합니다.

참고: 밀도 한정자를 사용하더라도 해당 리소스가 그 밀도의 화면 전용이라는 뜻은 아닙니다. 현재 기기 구성과 더욱 잘 맞는 한정자가 포함된 대체 리소스를 제공하지 않으면, 시스템이 가장 잘 일치하는 리소스를 사용합니다.

다양한 화질을 처리하는 방법과 Android가 현재 화질에 맞춰 비트맵을 축소하는 방법에 관한 자세한 정보는 다중 화면 지원을 참조하십시오.

터치 스크린 유형notouch
finger
  • notouch: 기기에 터치 스크린이 없습니다.
  • finger: 기기에 터치 스크린이 있으며 이를 사용자의 손가락을 사용한 방향 지시 상호 작용을 통해 쓰도록 되어 있습니다.

touchscreen 구성 필드도 참조하십시오. 이는 기기에서 사용되는 터치 스크린의 유형을 나타냅니다.

키보드 가용성keysexposed
keyshidden
keyssoft
  • keysexposed: 기기에서 키보드를 사용할 수 있습니다. 키보드에 소프트웨어 키보드가 활성화되어 있으면(이럴 가능성이 큽니다), 하드웨어 키보드가 사용자에게 노출되어 있지 않거나 기기에 하드웨어 키보드가 없더라도 이 리소스를 사용할 수 있습니다. 소프트웨어 키보드가 제공되어 있지 않거나 비활성화되어 있는 경우 이것은 하드웨어 키보드가 노출되어 있을 때에만 사용할 수 있습니다.
  • keyshidden: 기기에서 하드웨어 키보드를 사용할 수 있지만 숨겨져 있고이에 더하여 기기에 소프트웨어 키보드가 활성화되어 있지 않습니다.
  • keyssoft: 기기에 활성화된 소프트웨어 키보드가 있습니다(표시 여부는 무관).

keysexposed 리소스를 제공하지만 keyssoft 리소스는 제공하지 않는다면, 시스템은 소프트웨어 키보드가 활성화되어 있는 동안은 키보드가 보이는지 여부와 관계없이 keysexposed 리소스를 사용합니다.

이것은 사용자가 하드웨어 키보드를 여는 경우 애플리케이션 수명 중에 변경될 수 있습니다. 이것이 런타임에 애플리케이션에 어떤 영향을 미치는지 알아보려면 런타임 변경 처리를 참조하십시오.

또한, 구성 필드 hardKeyboardHidden과 keyboardHidden을 참조하십시오. 이 필드는 각각 하드웨어 키보드의 가시성과 모든 종류의 키보드(소프트웨어 포함)의 가시성을 나타냅니다.

기본 텍스트 입력 메서드nokeys
qwerty
12key
  • nokeys: 기기에 텍스트 입력을 위한 하드웨어 키가 없습니다.
  • qwerty: 기기에 하드웨어 쿼티 키보드가 있습니다(이것이 사용자 에게 표시되는지 여부는 무관).
  • 12key: 기기에 하드웨어 12-키 키보드가 있습니다(이것이 사용자에게 표시되는지 여부는 무관).

keyboard 구성 필드도 참조하십시오. 이는 기본 텍스트 입력 메서드를 사용할 수 있는지 여부를 나타냅니다.

플랫폼 버전(API 레벨)예:
v3
v4
v7
등.

기기에서 지원하는 API 레벨입니다. 예를 들어, v1는 API 레벨 1용이고(Android 1.0 이상 기기), v4는 API 레벨 4용(Android 1.6 이상 기기)입니다. 이러한 값에 관한 자세한 정보는 Android API 레벨 문서를 참조하십시오.

출처 : http://developer.android.com/intl/ko/guide/topics/resources/providing-resources.html


이걸 블로그에 공유하는 이유는 플랫폼 버전 별로도 구분이 가능 하다는 거다.

저 같은 경우, 작은 회사에서만 일했기 때문에 AndroidManifest에 minSDK를 주어 제한을 두고 앱 개발을 진행 했었다.


가능하면 위 보이는 것과 같의 버전별로 레이아웃과 클래스에 함수를 따로 두어 만들면

전체적으로 지원이 가능 하지 않을까 생각 된다.


중요한 부분은 빨간색으로 해놓았지만,


res/layout-v4 로 지정 해놓으면 1.6 이상 기기는 모든 해당 폴더의 레이아웃을 사용하게 된다는 것이다.

이부분을 잊으면 안될듯 하다.


참고로 java소스에 annotation 다는 법

@TargetApi(Build.VERSION_CODES.JELLY_BEAN)



## 이블로그는 어디까지는 찾았던 부분을 잊지 않기 위해 올려놓은 것 입니다.

    내용이 부실해도 이해해 주시길 바랍니다.