기기 호환성(Device Compatibility)

저작권 표시 : 

Portions of this page are modifications based on work created and shared by the Android Open Source Project and used according to terms described in the Creative Commons 2.5 Attribution License.

현재 보시는 페이지는 안드로이드 오픈 소스 프로젝트에 의해 작성되고 공유된 작업물의 수정/번역본이며 크리에이티브 커먼즈 저작자 표시 2.5 라이센스에 기술된 조건의 사용 근거를 따른 것입니다.

본 문서의 원본은 http://developer.android.com/guide/practices/compatibility.html이며 안드로이드 4.4 Kitkat 기준으로 설명되었습니다.

기기 호환성(Device Compatibility)

안드로이드는 전화, 태블릿, TV에 이르기까지 매우 다양한 기기에서 동작하도록 디자인되었다. 이것은 개발자로써 수많은 잠재 고객을 갖고 있음을 의미한다. 여러분의 앱이 이러한 모든 기기에서 성공을 거두길 바란다면 사양이 가지각색인 기기들에서도 잘 동작하고 다양한 해상도의 기기들에 대해서 유연하게 대응할 수 있는 UI를 제공해야한다.

이러한 것을 쉽게 하기 위해서 개발자가 다양한 환경에 맞는 앱 리소스를 제공하면 안드로이드가 환경에 따라 적절한 앱 리소스를 사용하는 동적인 앱을 제공하는 구조로 되어 있다. 예를 들어, 앱에서 "안녕하세요."라는 문자열을 사용한다고 하면 영어를 사용하는 기기에서는 "Hello"라는 문자열을, 한국어를 사용하는 기기에서는 "안녕하세요."가 표시될 수 있도록 두 개의 문자열 리소스를 하나의 앱에 포함시키는 것이다. 그러면 안드로이드가 기기에서 사용되는 언어가 영어이면 "Hello"를, 한국어이면 "안녕하세요."를 표시하게 된다. 그래서 여러분이 여러 개의 디자인과 리소스를 준비하면 다양한 기기에 최적화된 UI를 갖는 단일 애플리케이션 패키지(APK)를 만들어 낼 수 있다.

그러나 필요하다면 여러분의 앱이 요구하는 기기의 사양을 지정하여 구글 플레이 스토어에서 여러분의 앱이 설치될 수 있는 기기들을 선별할 수 있다. 이 글에서는 어떻게 하면 여러분의 앱을 설치할 수 있는 기기를 제어할 수 있는지 그 방법을 설명한다. 여러분의 앱이 다양한 사양의 기기들에서 동작하도록 제어하는 방법에 대해 더 많은 정보를 얻고 싶다면 Supporting Different Devices를 읽어보기 바란다.

"호환성"이란 무엇을 의미하는가?
(What Does "Compatibility" Mean?)

---

안드로이드 개발에 대한 글을 읽다보면 여러 곳에서 "호환성(compatibility)"이라는 용어를 맞닥뜨리게 된다. 호환성이라는 것은 크게 기기의 호환성과 앱의 호환성으로 생각해 볼 수 있다.

안드로이드는 오픈 소스 프로젝트이기 때문에 어느 하드웨어 제조사에서 만들어진 기기라도 안드로이드 운영체제를 탑재시킬 수 있다. 그러나 안드로이드 실행 환경에 맞추어 개발된 앱이 올바르게 실행될 수 있어야 그 기기를 "안드로이드 호환"이라고 할 수 있다. 안드로이드 실행환경에 대한 자세한 내용은 Android compatibility program에 정의되어 있으며 각 기기는 호환성 테스트 슈트(CTS; Compatibility Test Suite)를 통과해야만 한다.

앱 개발자 입장에서는 대상 기기가 안드로이드 호환 기종인지 아닌지에 대해서는 고민할 필요가 없다. 왜냐하면 안드로이드 호환 기종만이 구글 플레이 스토어에 접속할 수 있기 때문이다. 따라서 구글 플레이 스토어를 통해 앱을 설치하였다면 그 기기는 안드로이드 호환 기기인 것이다.

그러나 모든 기기의 구성에 대해서 여러분의 앱이 호환성을 가지고 있는지 확실히 할 필요가 있다. 왜냐하면 안드로이드는 매우 다양한 기기에 탑재되어 있으며 모든 기기의 사양이 다 같지는 않기 때문이다. 예를 들어, 어떤 기기는 나침반 센서가 없을 수 도 있다. 만일 여러분이 만든 앱의 핵심기능이 나침반 센서를 반드시 필요로 한다면 그 앱은 나침반 센서가 있는 기기에서만 호환이 되는 것이다.

기기에 대한 앱의 가용성 제어하기
(Controlling Your App's Availability to Devices)

---

안드로이드는 플랫폼 API를 통해 앱이 활용할 수 있는 다양한 기능을 제공한다. 일부 기능은 하드웨어를 기반(나침반 센서 같은)으로 한 것이고 일부 기능은 소프트웨어를 기반(앱 위젯 같은)으로 한 것이며 또 일부는 플랫폼 버전에 기반한 것이다. 모든 기기가 모든 기능을 지원하는 것은 아니다. 그래서 여러분의 앱이 필요로하는 기능에 따라 기기에 대한 앱의 가용성을 제어해야 할 수도 있다.

여러분의 앱을 최대한 많은 사람들이 사용할 수 있게 하려면 하나의 APK로 최대한 많은 종류의 기기에서 동작할 수 있도록 노력해야 한다. 대부분의 경우에는 실행 중에 특정 기능이 사용되지 않도록 하거나 다양한 기기의 환경에 맞춰 다른 앱 리소스를 제공함으로써 보다 많은 기기에서 동작하도록 할 수 있다. 다양한 기기의 환경이라하면 스크린의 해상도가 다르다거나 사용언어가 다르다거나 하는 것을 말한다. 하지만 필요하다면 다음의 조건들을 제약사항으로 하여 여러분이 작성한 앱이 설치될 기기를 제한할 수도 있다.

• 기기의 지원 기능(Device feature)
• 플랫폼 버전(Platform version)
• 스크린 구성(Screen configuration)

기기의 지원 기능(Device features)

기기의 지원 기능에 따라 앱의 가용성을 결정할 수 있도록 하기 위해서 안드로이드는 특정한 기능마다 고유의 기능 코드를 부여하고 있다. 예를 들어, 나침반 센서의 기능 코드는 FEATURE_SENSOR_COMPASS이며 앱 위젯을 위한 기능 코드는 FEATURE_APP_WIDGETS이다.

필요하다면 매니페스트 파일에 <uses-feature>엘리먼트를 선언하여 지정된 기능을 지원하지 않는 기기는 앱이 설치되지 않도록 할 수 있다.

예를 들어, 여러분의 앱이 나침반 센서 없이는 동작할 수 없는 구조라면 다음과 같이 매니페스트에 필수 요구사항으로 나침반 센서를 선언할 수도 있다.

Colored By Color Scripter™

1 2 3 4 5

<manifest ... >     <uses-feature android:name="android.hardware.sensor.compass"                   android:required="true" />     ... </manifest>

 

구글 플레이 스토어는 여러분의 앱에서 요청하는 기능과 사용자의 기기가 지원하는 기능들을 비교하여 앱이 기기에서 올바르게 동작할 수 있는지를 판단한다. 여러분의 앱이 요구하는 여러 기능을 하나라도 지원하지 않는 기기가 있다면 그 기기는 여러분이 만든 앱을 설치할 수 없다.

그러나 기기에 없는 기능이 여러분의 앱이 동작하는데 꼭 필요한 기능이 아니라면 required 속성을 "false"로 설정하고 실행 중에(runtime) 기기의 기능을 체크할 수도 있다. 앱의 특정 기능이 해당 기기에서 동작할 수 없는 상태라면 그 기기에서만 특정 기능이 동작하지 않도록 하면 된다. 이것은 hasSystemFeature()를 호출하여 기기가 해당 기능을 지원하는지 여부를 확인함으로써 구현이 가능하다.

Colored By Color Scripter™

1 2 3 4 5

PackageManager pm = getPackageManager(); if (!pm.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS)) {     // This device does not have a compass, turn off the compass feature     disableCompassFeature(); }

구글 플레이 스토어에서 특정 기능이 없는 기기를 필터링하는 방법에 대해 더 알고 싶다면 Filters on Google Play 문서를 읽어보기 바란다.

Note : 일부 시스템 퍼미션은 암시적으로 기기의 특정 기능을 요구하기도 한다. 예를 들어 여러분의 앱이 블루투스의 사용 권한을 요청하게 되면 이는 묵시적으로 기기의 FEATURE_BLUETOOTH를 필요로 하게 된다. 이런 경우 <uses-feature>태그의 required속성을 "false"로 설정하여 필터링에 걸리지 않도록 할 수 있다. 암시적으로 기기의 특정 기능을 요구하는 상황에 대해 좀 더 많은 정보가 필요하다면 Permissions that Imply Feature Requirements를 읽어보기 바란다.

플랫폼 버전(Platform version)

어떤 기기는 안드로이드 4.0이 설치되어 있고 또 어떤 기기는 안드로이드 4.4가 설치되어 있을 수 있다. 안드로이드 플랫폼 버전이 올라가면서 이전 버전에서는 존재하지 않아서 사용할 수 없는 새로운 API가 추가되기도 한다. 각 플랫폼 버전은 어떤 API 세트가 사용되는지 알기 쉽도록 하기 위해 API 레벨이라는 것을 갖고 있다. 안드로이드 1.0의 API 레벨은 1이고 안드로이드 4.4의 API 레벨은 19로 하는 것처럼 말이다.

매니페스트에 <uses-sdk>태그에 minSdkVersion 속성을 이용해 여러분의 앱이 호환되는 최소 API 레벨을 지정할 수 있다.

예를 들어, Calendar Provider API는 안드로이드 4.0(API 레벨 14)에서 추가됐다. 만일 여러분의 앱이 이 API가 없이는 동작할 수 없다면 다음과 같이 앱이 요구하는 최소 플랫폼 버전을 API 레벨 14라고 선언해야 한다.

Colored By Color Scripter™

1 2 3 4

<manifest ... >     <uses-sdk android:minSdkVersion="14" android:targetSdkVersion="19" />     ... </manifest>

minSdkVersion 속성을 앱이 호환되는 최소 버전을 선언하는 데 쓰이며 targetSdkVersion 속성을 앱이 최적화 되어 있는 최상위 버전을 선언하는 데 쓰인다.

새로운 안드로이드 버전은 이전 버전의 API를 사용한 앱에 대해 호환성을 갖도록 만들어진다. 그렇기 때문에 도큐먼트가 제공되는 안드로이드 API는 미래에 출시될 새로운 안드로이드 버전에서도 항상 호환성을 갖게 될 것이다.

Note : targetSdkVersion속성은 지정된 값 보다 더 높은 플랫폼 버전이 설치되어 있더라도 여러분의 앱을 설치하는 데는 문제가 없다. 하지만 이 속성은 중요하다. 왜냐하면 새로운 플랫폼 버전에서 변경된 내용을 적용할 지 말지를 결정하기 때문이다. 만일 여러분이 targetSdkVersion를 최신 버전으로 업데이트 하지 않았다면 최신 버전의 플랫폼이 동작하고 있더라도 여러분이 앱을 만들었던 이전 버전의 API가 하던 동작방식대로 실행되기 때문이다. 예를 들어, 안드로이드 4.4의 변경된 내용 중의 한 가지를 살펴보자. 안드로이드 4.4에서는 AlarmManager API로 생성된 알람은 기본적으로 정확하지 않다. 그래서 시스템에 등록된 앱의 알람들을 일괄적으로 처리하고 전력소비를 낮춘다. 하지만 여러분이 지정한 타겟 API 레벨이 19보다 낮다면 알람으로 인해 전력소비를 낮추는 잇점은 활용할 수 없게 된다.

하지만 여러분이 만든 앱의 주요 기능이 아닌 일부가 최신 버전의 API를 사용한다고 하자. 그렇다면 실행 중에 기기에 설치된 API 레벨을 확인하고 특정 기능을 구현하는데 요구되는 API 레벨보다 레벨이 낮다면 적절히 기능을 낮춰 줘야한다. 이런 경우 minSdkVersion은 주요 기능이 동작할 수 있는 최소한으로 지정하고 SDK_INT(시스템 버전)을 코드네임 상수인 Build.VERSION_CODES와 비교하여 여러분이 원하는 API 레벨인지 확인해야 한다. 아래는 그 예제다.

Colored By Color Scripter™

1 2 3 4 5

if (Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) {     // Running on something older than API level 11, so disable     // the drag/drop features that use ClipboardManager APIs     disableDragAndDrop(); }

스크린 구성(Screen configuration)

안드로이드는 전화기에서 태블릿, TV까지 다양한 크기의 기기에서 동작한다. 기기들을 스크린 종류에 따라 분류하기 위해 안드로이드는 각 기기들마다 두 가지 특징으로 한정짓는다. - 스크린의 사이즈(스크린의 물리적인 크기)와 스크린의 해상도(흔히 DPI라고 불리는 스크린에 있는 픽셀의 해상도.) 기기마다 서로 다은 이런 특징들을 단순히 하기 위해 안드로이드는 이러한 변수들을 쉽게 그룹화하기 위하여 다음과 같은 분류 기준을 사용한다.

• 4종류 사이즈 : small, normal, large, xlarge
• 몇몇 종류의 해상도 : mdpi(medium), hdpi(hdpi), xhdpi(extra high), xxhdpi(extra-extra high) 그리고 기타 종류들.

기본적으로 여러분의 앱은 모든 스크린 사이즈와 해상도에 대해 호환이 된다. 왜냐하면 시스템이 UI 레이아웃과 이미지 리소스를 각 스크린에 맞춰 적절히 조절해주기 때문이다. 하지만 사용자에게 보다 나은 환경을 제공하기 위해 다양한 스크린 사이즈에 특화된 레이아웃과 다양한 스크린 해상도에 최적화된 비트맵 이미지를 제공해야 한다.

다양한 스크린의 종류에 맞게 대체 리소스를 생성하는 법과 특정 사이즈의 스크린을 가진 기기에서 앱 설치가 제한되도록 하는 법에 대해 더 알고 싶다면 Supporting Different Screens를 읽어라.

업무적인 이유에 의한 앱의 가용성 제어
(Controlling Your App's Availability for Business Reasons)

---

기기의 특성 때문에 여러분이 만든 앱의 가용성을 제한하는 것 외에 업무적인 또는 법적인 문제로 앱의 가용성을 제한해야 할 때가 있다. 예를 들어 런던의 지하철 시간표를 제공하는 어떤 앱이 있다고 하자. 그렇다면 이 앱은 영국에 있는 사람이 아니라면 그다지 필요가 없다. 이런 경우 구글 플레이 스토어는 개발자 콘솔을 통해 기술적인 이유가 아닌 사용자의 로케일이나 무선통신의 상태에 따라 앱의 가용성을 제한하는 옵션을 제공한다.

하드웨어의 기능을 필요로하는 기술적인 호환성에 기인한 필터링은 앱의 APK 파일에 있는 정보에 의해 적용된다. 하지만 지리적 위치와 같은 비기술적인 문제로 인한 필터링은 구글 플레이의 개발자 콘솔을 통해 적용된다.

번역이 생각보다 쉬운 일이 아니네요.

원문을 읽을 때는 사전 찾아가며 떠듬떠듬 읽어도 무슨 뜻인지는 대충 알겠는데 우리말로 자연스럽게 만들기란 참 쉽지 않은 작업이네요.

앞으로 더 열심히 해야겠네요. 영어공부를...

다음 글 >> 시스템 퍼미션(System Permissions)

이전 글 >> 응용프로그램의 기초(Application Fundamentals)