기기 호환성 개요

Android는 스마트폰에서 태블릿, TV에 이르기까지 다양한 기기에서 실행되도록 설계되었습니다. 개발자로서 다양한 기기를 지원하면 앱의 잠재고객을 늘릴 수 있습니다. 이 모든 기기에서 앱이 성공하려면 기기에 따라 기능을 차별화해야 하며 다양한 화면 구성에 맞게 조정되는 유연한 사용자 인터페이스를 제공해야 합니다.

이 목표 달성을 돕기 위해 Android에는 다양한 화면 크기에 맞는 다양한 XML 레이아웃과 같은 구성별 앱 리소스를 정적 파일에서 제공할 수 있는 동적 앱 프레임워크가 있습니다. 그런 다음 Android에서는 현재 기기 설정에 따라 적절한 리소스를 로드합니다. 따라서 앱 디자인과 추가 앱 리소스를 고려하여 다양한 기기에서 최적화된 사용자 환경을 제공하는 단일 애플리케이션 패키지(APK)를 게시할 수 있습니다.

그러나 필요하면 앱의 기능 필수사항을 지정하고 Google Play 스토어에서 앱을 설치할 수 있는 기기 유형을 제어할 수 있습니다. 이 페이지에서는 앱에 액세스할 수 있는 기기와 적절한 잠재고객에게 도달할 수 있도록 앱을 준비하는 방법을 설명합니다. 앱을 다양한 기기에 맞게 조정하는 방법에 관한 자세한 내용은 다양한 기기 지원을 참조하세요.

'호환성' 정의

Android 개발에 관해 자세히 살펴볼 때 다양한 상황에서 '호환성'이라는 용어를 접할 수 있습니다. 기기 호환성 및 앱 호환성이라는 두 가지 유형의 호환성이 있습니다.

Android는 오픈소스 프로젝트이므로 모든 하드웨어 제조업체에서 Android 운영체제를 실행하는 기기를 빌드할 수 있습니다. 그러나 Android 실행 환경용으로 작성된 앱을 제대로 실행할 수 있을 때만 'Android 호환' 기기가 됩니다. Android 실행 환경의 정확한 세부정보는 Android 호환성 프로그램에서 정의하며, 각 기기가 호환되는 것으로 간주되려면 CTS(Compatibility Test Suite)를 통과해야 합니다.

Android 호환 기기만 Google Play 스토어를 포함하므로 앱 개발자는 기기가 Android 호환 기기인지 걱정할 필요가 없습니다. Google Play 스토어에서 앱을 설치하는 사용자는 Android 호환 기기를 사용하므로 안심해도 됩니다.

그러나 잠재적인 모든 기기 설정에서 앱 호환 가능 여부를 고려해야 합니다. Android는 다양한 기기 설정에서 실행되기 때문에 일부 기기에서는 일부 기능을 사용할 수 없습니다. 예를 들어 일부 기기에는 나침반 센서가 포함되어 있지 않을 수 있습니다. 앱의 핵심 기능에 나침반 센서가 필요하면 앱은 나침반 센서가 있는 기기와만 호환됩니다.

기기에서 앱의 사용 가능 여부 제어

Android에서는 플랫폼 API를 통해 앱에서 활용할 수 있는 다양한 기능을 지원합니다. 일부 기능은 하드웨어 기반(예: 나침반 센서)이며, 일부는 소프트웨어 기반(예: 앱 위젯)이고, 일부는 플랫폼 버전에 따라 다릅니다. 일부 기기에서는 일부 기능을 지원하지 않으므로 앱의 필수 기능에 기반하여 기기에 따른 앱 사용 가능 여부를 제어해야 합니다.

앱의 가장 큰 사용자층을 확보하려면 단일 APK를 사용하여 최대한 많은 기기 설정을 지원해야 합니다. 대부분의 경우 런타임 시 선택적 기능을 사용 중지하고 다양한 구성에 맞는 기능(예: 여러 다른 화면 크기에 맞는 여러 레이아웃)을 앱 리소스에 제공합니다. 그러나 필요하면 다음 기기 특성에 따라 Google Play 스토어를 통해 기기에서 앱의 사용 가능 여부를 제한할 수 있습니다.

기기 기능

기기 기능에 따라 앱의 사용 가능 여부를 관리하기 위해 Android에서는 일부 기기에서 사용할 수 없는 하드웨어 또는 소프트웨어 기능의 기능 ID를 정의합니다. 예를 들어 나침반 센서의 기능 ID는 FEATURE_SENSOR_COMPASS이고 앱 위젯의 기능 ID는 FEATURE_APP_WIDGETS입니다.

필요한 경우, 사용자의 기기에서 지정된 기능을 제공하지 않으면 앱의 manifest 파일에 <uses-feature> 요소를 선언하여 앱을 설치하지 못하게 할 수 있습니다.

예를 들어 나침반 센서가 없는 기기에 앱이 적합하지 않으면 다음 manifest 태그를 사용하여 나침반 센서를 필수사항으로 선언할 수 있습니다.

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

Google Play 스토어에서는 앱이 각 기기와 호환되는지 확인하기 위해 앱에 필요한 기능과 각 사용자 기기에서 사용 가능한 기능을 비교합니다. 기기에서 앱에 필요한 기능을 모두 제공하지 않으면 사용자가 앱을 설치할 수 없습니다.

하지만 앱의 기본 기능을 실행하는 데 기기 기능이 필요하지 않으면 required 속성을 "false"로 설정하고 런타임 시 기기 기능을 확인합니다. 현재 기기에서 앱 기능을 사용할 수 없으면 앱 기능의 성능을 단계적으로 저하시킵니다. 예를 들어, 다음과 같이 hasSystemFeature()를 호출하여 기능이 사용 가능한지 쿼리할 수 있습니다.

Kotlin

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

자바

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

Google Play 스토어를 통해 사용자의 앱 사용 가능 여부를 제어하는 데 사용할 수 있는 모든 필터에 관한 자세한 내용은 Google Play의 필터 문서를 참조하세요.

참고: 일부 시스템 권한을 사용하려면 암시적으로 기기 기능이 사용 가능해야 합니다. 예를 들어 앱에서 BLUETOOTH 액세스 권한을 요청하면 암시적으로 FEATURE_BLUETOOTH 기기 기능이 필요한 것입니다. 이 기능을 기반으로 필터링을 사용 중지하고 <uses-feature> 태그에서 required 속성을 "false"로 설정하여 블루투스가 없는 기기에서 앱을 사용하게 설정할 수 있습니다. 암시적으로 필요한 기기 기능에 관한 자세한 내용은 기능 필수사항을 암시하는 권한을 참조하세요.

플랫폼 버전

기기마다 Android 4.0 또는 Android 4.4와 같은 다양한 버전의 Android 플랫폼을 실행할 수 있습니다. 각 연속 플랫폼 버전에서는 이전 버전에서 사용할 수 없는 새 API를 추가하는 경우가 많습니다. 사용 가능한 API 조합을 표시하기 위해 각 플랫폼 버전에서 API 수준을 지정합니다. 예를 들어 Android 1.0은 API 수준 1이고 Android 4.4는 API 수준 19입니다.

API 수준을 사용하면 <uses-sdk> manifest 태그와 minSdkVersion 속성을 사용하여 앱이 호환되는 최소 버전을 선언할 수 있습니다. 예를 들어 Calendar Provider API는 Android 4.0(API 수준 14)에 추가되었습니다. 이 API가 없으면 앱이 작동하지 않는 경우 API 수준 14를 앱의 최소 지원 버전으로 선언해야 합니다.

minSdkVersion 속성을 통해서는 앱이 호환되는 최소 버전을 선언하고 targetSdkVersion 속성을 통해서는 앱을 최적화한 최상위 버전을 선언합니다.

그러나 <uses-sdk> 요소에 있는 속성은 build.gradle 파일의 대응하는 속성으로 재정의됩니다. Android 스튜디오를 사용하면 minSdkVersion 및 targetSdkVersion 값을 대신 지정해야 합니다.

    android {
      defaultConfig {
        applicationId 'com.example.myapp'

        // Defines the minimum API level required to run the app.
        minSdkVersion 15

        // Specifies the API level used to test the app.
        targetSdkVersion 28

        ...
      }
    }

build.gradle 파일에 관한 자세한 내용은 빌드 구성 방법을 참조하세요.

연속된 각 Android 버전은 이전 플랫폼 버전의 API를 사용하여 빌드된 앱과 호환되므로 문서화된 Android API를 사용하는 동안 앱은 항상 향후 버전의 Android와 호환되어야 합니다.

참고: targetSdkVersion 속성을 지정해도 앱이 지정된 값보다 높은 플랫폼 버전에 계속 설치되지만 앱이 최신 버전에서 동작 변경사항을 상속해야 하는지를 시스템에 알려주기 때문에 중요합니다. targetSdkVersion을 최신 버전으로 업데이트하지 않으면 시스템에서는 앱이 최신 버전에서 실행될 때 이전 버전과의 호환성 동작이 필요하다고 가정합니다. 예를 들어 Android 4.4의 동작 변경사항 중에서 AlarmManager API로 만든 알람은 이제 기본적으로 부정확하므로 시스템에서 앱 알람을 일괄 처리하고 시스템 전원을 유지할 수 있으며 타겟 API 수준이 '19' 미만이면 시스템에서 이전 API 동작을 유지합니다.

그러나 앱에서 최신 플랫폼 버전에 추가된 API를 사용하지만 기본 기능에 이 API가 필요하지 않은 경우, 런타임 시 API 버전을 확인하고 API 수준이 너무 낮으면 기능의 성능을 단계적으로 저하시켜야 합니다. 이 경우 minSdkVersion을 앱의 기본 기능에서 가능한 가장 낮은 값으로 설정한 다음 현재 시스템 버전, SDK_INT를 확인할 API 수준에 해당하는 Build.VERSION_CODES의 코드명 상수와 비교합니다. 예:

Kotlin

    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 <code><a href="/reference/android/content/ClipboardManager.html">ClipboardManager</a></code> APIs
        disableDragAndDrop()
    }

자바

    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 <code><a href="/reference/android/content/ClipboardManager.html">ClipboardManager</a></code> APIs
        disableDragAndDrop();
    }

화면 구성

Android는 스마트폰, 태블릿 및 TV 등 다양한 크기의 기기에서 실행됩니다. Android에서는 화면 유형별로 기기를 분류하기 위해 각 화면의 두 가지 특성, 즉 화면 크기(실제 화면 크기) 및 화면 밀도(DPI라고 하는 실제 화면의 픽셀 밀도)를 정의합니다. 다양한 구성을 간소화하기 위해 Android에서는 더 쉽게 타겟팅할 수 있는 그룹으로 일반화합니다.

  • 일반화된 네 가지 크기: 소형, 중형, 대형, 초대형
  • 일반화된 여러 밀도: mdpi(중밀도), hdpi(고밀도), xhdpi(초고밀도), xxhdpi(초초고밀도) 등

기본적으로 시스템에서는 각 화면에 필요한 대로 UI 레이아웃과 이미지 리소스를 적절하게 조정하므로 앱은 모든 화면 크기 및 밀도와 호환됩니다. 그러나 다양한 화면 크기에 따라 특수화된 레이아웃과 일반 화면 밀도에 맞게 최적화된 비트맵 이미지를 추가하여 각 화면 구성에 맞게 사용자 환경을 최적화해야 합니다.

다양한 화면의 대체 리소스를 만드는 방법과 필요할 때 앱을 특정 화면 크기로 제한하는 방법에 관한 자세한 내용은 다양한 화면 지원을 참조하세요.

비즈니스 관련 이유로 앱 사용 가능 여부 제어

기기 특성에 따라 앱의 사용 가능 여부를 제한하는 것 외에도 비즈니스 또는 법적 이유로 앱의 사용 가능 여부를 제한할 수도 있습니다. 예를 들어 런던 지하철의 열차 시간표를 표시하는 앱은 영국 이외 지역의 사용자에게 유용하지 않을 수 있습니다. 이러한 상황에서 Google Play 스토어는 Play Console에서 사용자의 언어 또는 무선 이동통신사와 같은 비기술적인 이유로 앱의 사용 가능 여부를 제어할 수 있는 필터링 옵션을 제공합니다.

필수 하드웨어 구성요소와 같은 기술 호환성 필터링은 항상 APK 파일에 포함된 정보를 기반으로 합니다. 그러나 지리적 위치와 같은 비기술적인 이유로 필터링하는 것은 항상 Google Play Console에서 처리합니다.

계속 읽기:

리소스 제공
특정 기기 설정에 사용하는 대체 리소스를 제공하는 방법을 포함하여 앱 코드와 앱 리소스를 구분하도록 Android 앱을 구성하는 방법에 관한 정보입니다.
Google Play 필터
Google Play 스토어에서 다른 기기에 앱을 설치하지 못하게 하는 다양한 방법에 관한 정보입니다.

관련 항목:

시스템 권한
API를 사용하려면 사용자의 동의를 구하도록 앱에 요구하는 권한 시스템을 통해 Android에서 특정 API에 대한 앱 액세스를 제한하는 방법입니다.
다음
화면 호환성 정보