이 페이지는 Cloud Translation API를 통해 번역되었습니다.

Android 1.6 호환성 정의

Android 호환성 정의: Android 1.6
안드로이드 1.6 r2
구글 주식회사
compatible@android.com

1. 소개
이 문서는 휴대전화가 서비스를 받기 위해 충족되어야 하는 요구사항을 열거합니다.
안드로이드 1.6과 호환됩니다. 이 정의는 Android 호환성 프로그램에 익숙하다고 가정합니다.
[자료, 1].
"해야 한다", "하지 말아야 한다", "필수", "해야 한다", "하지 말아야 한다", "해야 한다", "하지 않아야 한다", "권장한다",
"할 수 있다" 및 "선택 사항"은 RFC2119 [ 참고 자료 , 2]에 정의된 IETF 표준에 따릅니다.
이 문서에서 사용된 "장치 구현자" 또는 "구현자"는 개발하는 개인 또는 조직입니다.
Android 1.6을 실행하는 하드웨어/소프트웨어 솔루션. "장치 구현" 또는 "구현"은
이렇게 개발된 하드웨어/소프트웨어 솔루션.
Android 1.6과 호환되는 것으로 간주되는 기기 구현:
1. 모든 문서를 포함하여 이 호환성 정의에 제시된 요구 사항을 충족해야 합니다.
참조를 통해 통합되었습니다.
2. Android Open의 일부로 제공되는 Android 호환성 테스트 모음(CTS)을 통과해야 합니다.
소스 프로젝트 [ 리소스 , 3]. CTS는 이 문서에 설명된 구성요소 를 전부는 아니지만 대부분 테스트합니다.
문서.
이 정의 또는 CTS가 조용하거나 모호하거나 불완전한 경우 기기의 책임입니다.
구현자는 기존 구현과의 호환성을 보장합니다. 이 때문에 안드로이드 오픈
소스 프로젝트 [ 리소스 , 4]는 Android의 참조 및 선호 구현입니다. 장치
구현자는 "업스트림" 소스 코드를 기반으로 구현하는 것이 좋습니다.
Android 오픈 소스 프로젝트에서 사용할 수 있습니다. 일부 구성 요소는 가설적으로 교체할 수 있지만
대체 구현을 사용하는 경우 CTS 테스트를 통과하면
실질적으로 더 어렵습니다. 와 완전한 동작 호환성을 보장하는 것은 구현자의 책임입니다.
Compatibility Test Suite를 포함한 표준 Android 구현.
2. 자원
이 호환성 정의는 여기에서 얻을 수 있는 여러 리소스를 참조합니다.
1. Android 호환성 프로그램 개요: https://sites.google.com/a/android.com/compatibility/
작동 방식
2. IETF RFC2119 요구 수준: http://www.ietf.org/rfc/rfc2119.txt
3. 호환성 테스트 모음: http://sites.google.com/a/android.com/compatibility/compatibility-test-
제품군--cts
4. Android 오픈 소스 프로젝트: http://source.android.com/
5. API 정의 및 문서: http://developer.android.com/reference/packages.html
6. 콘텐츠 제공자: http://code.google.com/android/reference/android/provider/package-
요약.html
7. 사용 가능한 리소스: http://code.google.com/android/reference/available-resources.html
8. 안드로이드 매니페스트 파일: http://code.google.com/android/devel/bblocks-manifest.html
9. Android 권한 참조: http://developer.android.com/reference/android/
Manifest.permission.html
10. 빌드 상수: http://developer.android.com/reference/android/os/Build.html
11. 웹뷰: http://developer.android.com/reference/android/webkit/WebView.html
12. Gears 브라우저 확장 프로그램: http://code.google.com/apis/gears/

13. 소스 코드의 dalvik/docs 디렉토리에 있는 Dalvik Virtual Machine 사양
점검; http://android.git.kernel.org/?p=platform/ 에서도 사용 가능
dalvik.git;a=tree;f=docs;h=3e2ddbcaf7f370246246f9f03620a7caccbfcb12;hb=HEAD
14. 앱 위젯: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
15. 알림: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
16. 상태 표시줄 아이콘 스타일 가이드: http://developer.android.com/guide/practices/ui_guideline
/icon_design.html#statusbarstructure
17. 검색 관리자: http://developer.android.com/reference/android/app/SearchManager.html
18. 토스트: http://developer.android.com/reference/android/widget/Toast.html
19. 안드로이드용 앱: http://code.google.com/p/apps-for-android
20. 안드로이드 apk 파일 설명: http://developer.android.com/guide/topics/fundamentals.html
21. Android 디버그 브리지(adb): http://code.google.com/android/reference/adb.html
22. Dalvik 디버그 모니터 서비스(ddms): http://code.google.com/android/reference/ddms.html
23. 원숭이: http://developer.android.com/guide/developing/tools/monkey.html
24. 디스플레이 독립 문서:
25. 구성 상수: http://developer.android.com/reference/android/content/res/
구성.html
26. 디스플레이 지표: http://developer.android.com/reference/android/util/DisplayMetrics.html
27. 카메라: http://developer.android.com/reference/android/hardware/Camera.html
28. 센서 좌표 공간: http://developer.android.com/reference/android/hardware/
SensorEvent.html
29. Android 보안 및 권한 참조: http://developer.android.com/guide/topics/security/
security.html
이러한 리소스 중 다수는 Android 1.6 SDK에서 직간접적으로 파생되며
해당 SDK 문서의 정보와 기능적으로 동일합니다. 이 어떤 경우에도
호환성 정의가 SDK 문서에 동의하지 않음, SDK 문서가 고려됨
권위 있는. 위에 포함된 참조에 제공된 모든 기술적 세부 사항은 포함으로 간주됩니다.
이 호환성 정의의 일부입니다.
3. 소프트웨어
Android 플랫폼에는 관리되는("하드") API 집합과 소위 "소프트" API 본문이 모두 포함됩니다.
인텐트 시스템, 네이티브 코드 API 및 웹 애플리케이션 API와 같은 이 섹션에서는 어렵고
호환성에 필수적인 소프트 API 및 기타 관련 기술 및 사용자 인터페이스
행동. 기기 구현은 이 섹션의 모든 요구사항을 준수해야 합니다(MUST).
3.1. 관리형 API 호환성
관리형(Dalvik 기반) 실행 환경은 Android 애플리케이션의 기본 수단입니다. 그만큼
Android 애플리케이션 프로그래밍 인터페이스(API)는 다음에 노출되는 Android 플랫폼 인터페이스 집합입니다.
관리되는 VM 환경에서 실행되는 애플리케이션. 기기 구현은 완전한
모든 문서화된 동작을 포함하여 Android에 의해 노출된 모든 문서화된 API의 구현
다음과 같은 1.6 SDK:
1. 핵심 Android Java 언어 API [리소스, 5].
2. 콘텐츠 제공자 [자료 , 6].
3. 자원 [자원, 7].
4. AndroidManifest.xml 속성 및 요소 [리소스, 8].

기기 구현은 관리되는 API를 생략하거나 API 인터페이스 또는 서명을 변경하거나
이 호환성에 의해 특별히 허용된 경우를 제외하고 문서화된 동작에서 또는 no-ops를 포함합니다.
정의.
3.2. 소프트 API 호환성
섹션 3.1의 관리 API 외에도 Android에는 상당한 런타임 전용 "소프트"
의도, 권한 및 Android 애플리케이션의 유사한 측면과 같은 형태의 API
응용 프로그램 컴파일 시간에 적용할 수 없습니다. 이 섹션에서는 "소프트" API 및 시스템에 대해 자세히 설명합니다.
Android 1.6과의 호환성에 필요한 동작입니다. 기기 구현은 다음을 모두 충족해야 합니다.
이 섹션에 제시된 요구 사항.
3.2.1. 권한
기기 구현자는
권한 참조 페이지 [ 리소스 , 9]. 섹션 10에는 다음과 관련된 추가 요구 사항이 나열되어 있습니다.
안드로이드 보안 모델.
3.2.2. 빌드 매개변수
Android API에는 다음과 같은 android.os.Build 클래스 [Resources, 10] 의 여러 상수가 포함되어 있습니다.
현재 장치를 설명하기 위한 것입니다. 장치 전반에 걸쳐 일관되고 의미 있는 값을 제공하기 위해
아래 표에는 이러한 값의 형식에 대한 추가 제한 사항이 포함되어 있습니다.
기기 구현은 준수해야 합니다.
모수
코멘트
현재 실행 중인 Android 시스템의 버전
android.os.Build.VERSION.RELEASE
읽을 수 있는 형식. Android 1.6의 경우 이 필드에는 문자열 값이 있어야 합니다.
"1.6".
현재 실행 중인 Android 시스템의 버전 형식
android.os.Build.VERSION.SDK
타사 애플리케이션 코드에 액세스할 수 있습니다. Android 1.6의 경우 이 필드
정수 값 4를 가져야 합니다.
특정 빌드를 지정하는 기기 구현자가 선택한 값
사람이 읽을 수 있는 형식으로 현재 실행 중인 Android 시스템의
이 값은 끝까지 배송되는 다른 빌드에 재사용하면 안 됩니다(MUST NOT).
android.os.Build.VERSION.INCREMENTAL 사용자. 이 필드의 일반적인 용도는 빌드 번호 또는
빌드를 생성하는 데 소스 제어 변경 식별자가 사용되었습니다. 거기
이 필드의 특정 형식에 대한 요구 사항은 없습니다.
null 또는 빈 문자열("")이면 안 됩니다(MUST NOT).
특정 내부를 식별하는 장치 구현자가 선택한 값
사람이 읽을 수 있는 형식으로 장치에서 사용하는 하드웨어. 가능한 용도
android.os.Build.보드
이 필드는 보드에 전원을 공급하는 특정 버전을 나타냅니다.
장치. 이 필드의 특정 형식에 대한 요구 사항은 없습니다.
null 또는 빈 문자열("")이 아니어야 한다는 점을 제외하고.
이름을 식별하는 기기 구현자가 선택한 값
android.os.Build.BRAND
기기를 생산한 회사, 단체, 개인 등
사람이 읽을 수 있는 형식. 이 필드의 가능한 용도는 OEM을 나타내는 것입니다.

및/또는 장치를 판매한 이동통신사. 에 대한 요구 사항은 없습니다.
null이거나 비어 있으면 안 된다는 점을 제외하고는 이 필드의 특정 형식입니다.
끈 ("").
특정을 식별하는 기기 구현자가 선택한 값
본체의 구성 또는 개정(때때로 "산업용
android.os.Build.DEVICE
디자인"). 특정 형식에 대한 요구 사항은 없습니다.
단, null 또는 빈 문자열("")이면 안 됩니다.
이 빌드를 고유하게 식별하는 문자열입니다. 합리적이어야 합니다.
사람이 읽을 수 있습니다. 다음 템플릿을 따라야 합니다.
$(PRODUCT_BRAND)/$(PRODUCT_NAME)/$(PRODUCT_DEVICE)/
$(TARGET_BOOTLOADER_BOARD_NAME):$(PLATFORM_VERSION)/
$(BUILD_ID)/$(BUILD_NUMBER):$(TARGET_BUILD_VARIANT)/
android.os.Build.FINGERPRINT
$(BUILD_VERSION_TAGS)
예: acme/mydevicel/generic/generic:Donut/ERC77/
3359:userdebug/테스트 키
지문에는 공백이 포함되어서는 안 됩니다. 다른 필드가 포함된 경우
위의 템플릿에는 공백이 있습니다. ASCII로 교체해야 합니다.
지문의 밑줄("_") 문자.
빌드가 빌드된 호스트를 고유하게 식별하는 문자열
android.os.Build.HOST
읽을 수 있는 형식. 이 특정 형식에 대한 요구 사항은 없습니다.
단, null 또는 빈 문자열("")이면 안 됩니다.
특정 기기를 참조하기 위해 기기 구현자가 선택한 식별자
릴리스, 사람이 읽을 수 있는 형식으로. 이 필드는 다음과 같을 수 있습니다.
android.os.Build.VERSION.INCREMENTAL이지만 값이어야 합니다.
android.os.Build.ID
최종 사용자에게 다소 의미 있는 것으로 의도되었습니다. 없다
MUST NOT을 제외하고 이 필드의 특정 형식에 대한 요구 사항
null 또는 빈 문자열("")이어야 합니다.
이름을 포함하는 장치 구현자가 선택한 값
최종 사용자에게 알려진 장치. 이름이 같아야 합니다.
android.os.Build.모델
장치가 최종 사용자에게 판매되고 판매되는 것입니다. 없다
MUST NOT을 제외하고 이 필드의 특정 형식에 대한 요구 사항
null 또는 빈 문자열("")이어야 합니다.
개발을 포함하는 기기 구현자가 선택한 값
장치의 이름 또는 코드 이름. 사람이 읽을 수 있어야 하지만 그렇지 않습니다.
android.os.Build.PRODUCT
반드시 최종 사용자가 보기 위한 것입니다. 요구 사항이 없습니다
null이거나
빈 문자열("").
기기 구현자가 선택한 쉼표로 구분된 태그 목록입니다.
빌드를 더 구별하십시오. 예를 들어 "unsigned,debug"입니다. 이 필드
android.os.Build.TAGS
null 또는 빈 문자열("")이 아니라 단일 태그(예:
"릴리스") 괜찮습니다.
android.os.Build.TIME
빌드가 발생한 시점의 타임스탬프를 나타내는 값입니다.
런타임을 지정하는 기기 구현자가 선택한 값
빌드 구성. 이 필드에는 다음 값 중 하나가 있어야 합니다.
android.os.Build.TYPE
세 가지 일반적인 Android 런타임 구성인 "사용자",
"userdebug" 또는 "eng".
생성한 사용자(또는 자동화된 사용자)의 이름 또는 사용자 ID
android.os.Build.USER
짓다. 이 필드의 특정 형식에 대한 요구 사항은 없습니다.
null 또는 빈 문자열("")이 아니어야 한다는 점을 제외하고.

3.2.3. 의도 호환성
Android는 인텐트를 사용하여 애플리케이션 간에 느슨하게 결합된 통합을 달성합니다. 이 섹션에서는 다음을 설명합니다.
장치 구현에서 반드시 준수해야 하는 의도 패턴과 관련된 요구 사항. 에 의해
"명예"는 기기 구현자가 Android 활동, 서비스 또는 기타
일치하는 의도 필터를 지정하고 각각에 대한 올바른 동작을 바인딩하고 구현하는 구성 요소
의도 패턴을 지정했습니다.
3.2.3.1. 핵심 애플리케이션 의도
Android 업스트림 프로젝트는 전화 걸기, 캘린더,
연락처 책, 음악 플레이어 등. 기기 구현자는 이러한 애플리케이션을
대체 버전.
그러나 이러한 대체 버전은 업스트림에서 제공하는 동일한 의도 패턴을 준수해야 합니다.
프로젝트. (예를 들어 장치에 대체 음악 플레이어가 포함되어 있는 경우 여전히 의도 패턴을 준수해야 합니다.
노래를 선택하기 위해 타사 애플리케이션에서 발행합니다.) 기기 구현은 모든 인텐트 패턴을 지원해야 합니다(MUST).
부록 A에 나와 있습니다.
3.2.3.2. 의도 재정의
Android는 확장 가능한 플랫폼이므로 기기 구현자는 다음에 설명된 각 인텐트 패턴을 허용해야 합니다.
타사 응용 프로그램에 의해 재정의되는 부록 A. 업스트림 Android 오픈 소스 프로젝트
기본적으로 허용합니다. 장치 구현자는 시스템 응용 프로그램에 특별한 권한을 부여해서는 안 됩니다.
이러한 인텐트 패턴을 사용하거나 제3자 애플리케이션이
이러한 패턴. 이 금지 사항에는 특히 "선택자" 사용자 인터페이스 비활성화가 포함됩니다.
사용자는 모두 동일한 의도 패턴을 처리하는 여러 애플리케이션 중에서 선택할 수 있습니다.
3.2.3.3. 의도 네임스페이스
기기 구현자는 새로운 인텐트 또는
ACTION, CATEGORY 또는 android.* 네임스페이스의 기타 키 문자열을 사용하여 인텐트 패턴을 브로드캐스트합니다.
기기 구현자는 새로운 인텐트 또는
패키지 공간에서 ACTION, CATEGORY 또는 기타 키 문자열을 사용하여 브로드캐스트 의도 패턴
다른 조직에 속해 있습니다. 기기 구현자는 인텐트를 변경하거나 확장하면 안 됩니다(MUST NOT).
부록 A 또는 B에 나열된 패턴.
이 금지는 섹션 3.6에서 Java 언어 클래스에 대해 지정된 것과 유사합니다.

3.2.3.4. 브로드캐스트 의도
제3자 애플리케이션은 플랫폼에 의존하여 특정 인텐트를 브로드캐스트하여
하드웨어 또는 소프트웨어 환경. Android 호환 기기는 공개 방송을 방송해야 합니다.
적절한 시스템 이벤트에 대한 응답의 인텐트. 필수 브로드캐스트 의도 목록은 다음에서 제공됩니다.
부록 B; 그러나 SDK는 추가 브로드캐스트 의도를 정의할 수 있으며 이는 반드시
존경합니다.
3.3. 네이티브 API 호환성
Dalvik에서 실행되는 관리 코드는 애플리케이션 .apk 파일에 ELF로 제공된 네이티브 코드를 호출할 수 있습니다.
적절한 장치 하드웨어 아키텍처용으로 컴파일된 .so 파일. 기기 구현에는 다음이 포함되어야 합니다(MUST).
표준 Java를 사용하여 네이티브 코드를 호출하기 위해 관리 환경에서 실행되는 코드 지원
네이티브 인터페이스(JNI) 시맨틱. 네이티브 코드에서 다음 API를 사용할 수 있어야 합니다.
• libc(C 라이브러리)
• libm(수학 라이브러리)
• JNI 인터페이스
• libz(Zlib 압축)
• liblog(Android 로깅)
• C++에 대한 최소한의 지원
• OpenGL ES 1.1
이러한 라이브러리는 소스 호환(예: 헤더 호환) 및 바이너리 호환(주어진 경우)이어야 합니다.
프로세서 아키텍처)를 Android 오픈 소스 프로젝트에서 Bionic에서 제공하는 버전으로 사용합니다. 부터
Bionic 구현은 GNU C와 같은 다른 구현과 완전히 호환되지 않습니다.
라이브러리, 기기 구현자는 Android 구현을 사용해야 합니다(SHOULD). 장치 구현자가
이러한 라이브러리의 다른 구현은 헤더 및 바이너리 호환성을 보장해야 합니다.
네이티브 코드 호환성은 어렵습니다. 이러한 이유로 기기 구현자는
도움이 되도록 위에 나열된 라이브러리의 업스트림 구현을 사용할 것을 매우 강력히 권장합니다.
호환성을 보장합니다.
3.4. 웹 API 호환성
많은 개발자와 애플리케이션은 android.webkit.WebView 클래스 [ 리소스 ,
11] 사용자 인터페이스를 위해 WebView 구현이 Android 전체에서 호환되어야 합니다.
구현. Android 오픈 소스 구현은 WebKit 렌더링 엔진 버전을 사용하여
WebView를 구현합니다.
웹 브라우저에 대한 포괄적인 테스트 도구 모음을 개발하는 것은 실현 가능하지 않기 때문에 장치 구현자는
WebView 구현에서 WebKit의 특정 업스트림 빌드를 사용해야 합니다(MUST). 구체적으로:
• WebView는 업스트림 Android 오픈 소스 트리의 528.5+ WebKit 빌드를 사용해야 합니다.
안드로이드 1.6. 이 빌드에는 WebView에 대한 특정 기능 세트 및 보안 수정 사항이 포함되어 있습니다.
• WebView가 보고하는 사용자 에이전트 문자열은 다음 형식이어야 합니다.
Mozilla/5.0(Linux; U; Android 1.6; <언어>-<국가>; <장치
이름>; 빌드/<빌드 ID>) AppleWebKit/528.5+(Gecko와 같은 KHTML)
버전/3.1.2 모바일 사파리/525.20.1

◦ "<장치 이름>" 문자열은 다음 값과 동일해야 합니다.
android.os.Build.모델
◦ "<빌드 ID>" 문자열은 android.os.Build.ID의 값과 동일해야 합니다.
◦ "<언어>" 및 "<국가>" 문자열은 다음에 대한 일반적인 규칙을 따라야 합니다(SHOULD).
국가 코드 및 언어, 그리고 장치의 현재 로케일을 참조해야 합니다(SHOULD).
요청 시간.
구현은 독립 실행형 브라우저 애플리케이션에서 사용자 지정 사용자 에이전트 문자열을 배송할 수 있습니다(MAY). 뭐야
또한 독립형 브라우저는 대체 브라우저 기술(예: Firefox,
Opera 등) 단, 대체 브라우저 애플리케이션이 출고되더라도 WebView 컴포넌트는
타사 애플리케이션에 제공되는 애플리케이션은 위와 같이 WebKit을 기반으로 해야 합니다.
독립 실행형 브라우저 응용 프로그램은 Gears[ 참고자료, 12] 및 MAY에 대한 지원을 포함해야 합니다(SHOULD).
HTML5의 일부 또는 전체에 대한 지원을 포함합니다.
3.5. API 동작 호환성
각 API 유형(관리형, 소프트, 네이티브 및 웹)의 동작은 다음과 일치해야 합니다.
Android 오픈 소스 프로젝트에서 사용할 수 있는 Android의 기본 구현입니다.
일부 특정 호환성 영역은 다음과 같습니다.
• 장치는 표준 의도의 동작이나 의미를 변경하면 안 됩니다(MUST NOT).
• 장치는 특정 유형의 시스템의 수명 주기 또는 수명 주기 의미 체계를 변경하면 안 됩니다(MUST NOT).
구성 요소(예: Service, Activity, ContentProvider 등)
• 장치는 특정 권한의 의미 체계를 변경하면 안 됩니다(MUST NOT).
위의 목록은 포괄적이지 않으며 동작을 보장하는 책임은 장치 구현자에게 있습니다.
호환성. 이러한 이유로 기기 구현자는 다음을 통해 사용 가능한 소스 코드를 사용해야 합니다.
시스템의 중요한 부분을 다시 구현하는 대신 가능한 경우 Android 오픈 소스 프로젝트.
호환성 테스트 도구 모음(CTS)은 동작 호환성을 위해 플랫폼의 상당 부분을 테스트합니다.
하지만 전부는 아닙니다. Android와의 동작 호환성을 보장하는 것은 구현자의 책임입니다.
오픈 소스 프로젝트.
3.6. API 네임스페이스
Android는 Java 프로그래밍에서 정의한 패키지 및 클래스 네임스페이스 규칙을 따릅니다.
언어. 타사 애플리케이션과의 호환성을 보장하기 위해 기기 구현자는
이러한 패키지 네임스페이스에 대한 모든 금지된 수정(아래 참조):
• 자바.*
• javax.*
• 태양.*
• 안드로이드.*
• com.android.*
금지된 수정에는 다음이 포함됩니다.
• 기기 구현은 Android 플랫폼에서 공개적으로 노출된 API를 수정하면 안 됩니다(MUST NOT).
메서드 또는 클래스 서명을 변경하거나 클래스 또는 클래스 필드를 제거합니다.

• 장치 구현자는 API의 기본 구현을 수정할 수 있지만
수정 사항은 명시된 동작 및 Java 언어 서명에 영향을 주어서는 안 됩니다(MUST NOT).
공개적으로 노출된 API.
• 기기 구현자는 공개적으로 노출된 요소(예: 클래스 또는
인터페이스, 기존 클래스 또는 인터페이스에 대한 필드 또는 메서드)를 위의 API에 추가합니다.
"공개적으로 노출된 요소"는 "@hide" 마커로 장식되지 않은 구성입니다.
업스트림 Android 소스 코드. 즉, 기기 구현자는 새 API를 노출하거나
위에서 언급한 네임스페이스의 기존 API를 변경합니다. 기기 구현자는 내부 전용으로 만들 수 있습니다(MAY).
그러나 이러한 수정 사항은 광고되거나 달리 개발자에게 노출되어서는 안 됩니다(MUST NOT).
기기 구현자는 맞춤 API를 추가할 수 있지만 이러한 API는 소유한 네임스페이스에 있으면 안 됩니다.
다른 조직에 의해 또는 참조. 예를 들어 기기 구현자는 API를
com.google.* 또는 이와 유사한 네임스페이스 Google만이 그렇게 할 수 있습니다. 마찬가지로 Google은 다음에 API를 추가하면 안 됩니다(MUST NOT).
다른 회사의 네임스페이스.
기기 구현자가 위의 패키지 네임스페이스 중 하나를 개선할 것을 제안하는 경우(예:
유용한 새 기능을 기존 API에 추가하거나 새 API를 추가), 구현자는 다음을 방문해야 합니다.
source.android.com에 따라 변경 및 코드 기여 프로세스를 시작합니다.
해당 사이트에 대한 정보입니다.
위의 제한 사항은 Java에서 API 이름 지정에 대한 표준 규칙에 해당합니다.
프로그래밍 언어; 이 섹션은 단순히 이러한 규칙을 강화하고 구속력을 갖도록 하는 것을 목표로 합니다.
이 호환성 정의에 포함함으로써.
3.7. 가상 머신 호환성
호환되는 Android 기기는 전체 DEX(Dalvik Executable) 바이트코드 사양을 지원해야 하며
Dalvik 가상 머신 시맨틱[리소스, 13].
3.8. 사용자 인터페이스 호환성
Android 플랫폼에는 개발자가 시스템 사용자에 연결할 수 있는 일부 개발자 API가 포함되어 있습니다.
상호 작용. 기기 구현은 이러한 표준 UI API를 맞춤 사용자 인터페이스에 통합해야 합니다(MUST).
그들은 아래에 설명된 대로 발전합니다.
3.8.1. 위젯
Android는 구성요소 유형과 해당 API 및 애플리케이션이
최종 사용자에 대한 "AppWidget" [Resources , 14] . Android 오픈 소스 참조 릴리스에는
사용자가 추가, 보기 및 제거할 수 있는 사용자 인터페이스 요소를 포함하는 런처 애플리케이션
홈 화면의 AppWidgets.
기기 구현자는 참조 실행기(예: 홈 화면)의 대안으로 대체할 수 있습니다(MAY).
대체 런처는 AppWidgets에 대한 내장 지원을 포함하고 사용자 인터페이스를 노출해야 합니다(SHOULD).
런처 내에서 직접 AppWidgets를 추가, 보기 및 제거할 수 있는 요소입니다. 대체 발사기 MAY
이러한 사용자 인터페이스 요소를 생략합니다. 그러나 생략된 경우 기기 구현자는 다음을 제공해야 합니다.
런처에서 액세스할 수 있는 별도의 애플리케이션으로 사용자가 추가, 보기 및 제거할 수 있습니다.
AppWidgets.

3.8.2. 알림
Android에는 개발자가 사용자에게 주목할만한 이벤트를 알릴 수 있는 API가 포함되어 있습니다[리소스, 15]. 장치
구현자는 그렇게 정의된 각 알림 클래스에 대한 지원을 제공해야 합니다. 구체적으로: 소리,
진동, 표시등 및 상태 표시줄.
또한 구현 시 모든 리소스(아이콘, 사운드 파일 등)를 올바르게 렌더링해야 합니다.
API[리소스, 7] 또는 상태 표시줄 아이콘 스타일 가이드[리소스 , 16]에서 제공됩니다. 장치
구현자는 알림에 대한 대체 사용자 경험을 제공할 수 있습니다(MAY).
참조 Android 오픈 소스 구현; 그러나 이러한 대체 알림 시스템은 반드시
위와 같이 기존 알림 리소스를 지원합니다.
3.8.3. 찾다
Android에는 개발자가 애플리케이션에 검색을 통합할 수 있는 API[리소스, 17]가 포함되어 있습니다.
응용 프로그램의 데이터를 전역 시스템 검색에 노출합니다. 일반적으로 이 기능은
사용자가 쿼리를 입력하고 제안을 표시할 수 있는 단일 시스템 전체 사용자 인터페이스로 구성됩니다.
as users type, and displays results. The Android APIs allow developers to reuse this interface to provide
search within their own apps, and allow developers to supply results to the common global search user
interface.
Device implementations MUST include a single, shared, system-wide search user interface capable of
real-time suggestions in response to user input. Device implementations MUST implement the APIs that
allow developers to reuse this user interface to provide search within their own applications.
Device implementations MUST implement the APIs that allow third-party applications to add suggestions
to the search box when it is run in global search mode. If no third-party applications are installed that
make use of this functionality, the default behavior SHOULD be to display web search engine results and
suggestions.
Device implementations MAY ship alternate search user interfaces, but SHOULD include a hard or soft
dedicated search button, that can be used at any time within any app to invoke the search framework,
with the behavior provided for in the API documentation.
3.8.4. Toasts
Applications can use the "Toast" API (defined in [ Resources, 18]) to display short non-modal strings to the
end user, that disappear after a brief period of time. Device implementations MUST display Toasts from
applications to end users in some high-visibility manner.
4. Reference Software Compatibility
Device implementers MUST test implementation compatibility using the following open-source
applications:
• Calculator (included in SDK)
• Lunar Lander (included in SDK)
• ApiDemos (included in SDK)
• The "Apps for Android" applications [ Resources, 19]
Each app above MUST launch and behave correctly on the implementation, for the implementation to be

considered compatible.
5. Application Packaging Compatibility
Device implementations MUST install and run Android ".apk" files as generated by the "aapt" tool
included in the official Android SDK [ Resources , 20].
Devices implementations MUST NOT extend either the .apk, Android Manifest, or Dalvik bytecode
formats in such a way that would prevent those files from installing and running correctly on other
compatible devices. Device implementers SHOULD use the reference upstream implementation of Dalvik,
and the reference implementation's package management system.
6. Multimedia Compatibility
A compatible Android device must support the following multimedia codecs. All of these codecs are
provided as software implementations in the preferred Android implementation from the Android Open
Source Project [ Resources , 4].
Please note that neither Google nor the Open Handset Alliance make any representation that these
codecs are unencumbered by third-party patents. Those intending to use this source code in hardware or
software products are advised that implementations of this code, including in open source software or
shareware, may require patent licenses from the relevant patent holders.
Audio
Name
Encoder Decoder Details
Files Supported
Mono/Stereo content in any
3GPP (.3gp) and
combination of standard bit rates
MPEG-4 (.mp4, .m4a)
AAC LC/LTP
X
up to 160 kbps and sampling rates files. No support for raw
between 8 to 48kHz
AAC (.aac)
Mono/Stereo content in any
3GPP (.3gp) and
HE-AACv1
combination of standard bit rates
MPEG-4 (.mp4, .m4a)
X
(AAC+)
up to 96 kbps and sampling rates files. No support for raw
between 8 to 48kHz
AAC (.aac)
Mono/Stereo content in any
HE-AACv2
3GPP (.3gp) and
combination of standard bit rates
(enhanced
MPEG-4 (.mp4, .m4a)
X
up to 96 kbps and sampling rates
AAC+)
files. No support for raw
between 8 to 48kHz
AAC (.aac)
AMR-NB
4.75 to 12.2 kbps sampled @
3GPP (.3gp) files
X
X
8kHz
AMR-WB
9 rates from 6.60 kbit/s to 23.85
-3GPP (.3gp) files
X
kbit/s sampled @ 16kHz
MP3
Mono/Stereo 8-320Kbps constant MP3 (.mp3) files
X
(CBR) or variable bit-rate (VBR)
Type 0 and 1 (.mid, .xmf,
MIDI Type 0 and 1. DLS Version 1
MIDI
X
.mxmf). Also RTTTL/RTX
and 2. XMF and Mobile XMF.
(.rtttl, .rtx), OTA (.ota),

Support for ringtone formats
and iMelody (.imy)
RTTTL/RTX, OTA, and iMelody
Ogg Vorbis
.ogg
X
8- and 16-bit linear PCM (rates up
PCM
X
WAVE
to limit of hardware)
Image
Files
Name
Encoder Decoder Details
Supported
JPEG
X
X
base+progressive
GIF
X
PNG
X
X
BMP
X
Video
Files
Name
Encoder Decoder Details
Supported
3GPP (.3gp)
H.263
X
X
files
3GPP (.3gp)
H.264
X
and MPEG-4
(.mp4) files
MPEG4
X
3GPP (.3gp) file
SP
7. Developer Tool Compatibility
Device implementations MUST support the Android Developer Tools provided in the Android SDK.
Specifically, Android-compatible devices MUST be compatible with:
• Android Debug Bridge or adb [Resources , 21]
Device implementations MUST support all adb functions as documented in the Android
SDK. The device-side adb daemon SHOULD be inactive by default, but there MUST be a user-
accessible mechanism to turn on the Android Debug Bridge.
• Dalvik Debug Monitor Service or ddms [Resources , 22]
Device implementations MUST support all ddms features as documented in the Android SDK.
As ddms uses adb, support for ddms SHOULD be inactive by default, but MUST be supported
whenever the user has activated the Android Debug Bridge, as above.

• Monkey [Resources, 23]
Device implementations MUST include the Monkey framework, and make it available for
applications to use.
8. Hardware Compatibility
Android is intended to support device implementers creating innovative form factors and configurations.
At the same time Android developers expect certain hardware, sensors and APIs across all Android
device. This section lists the hardware features that all Android 1.6 compatible devices must support. In
Android 1.6, the majority of hardware features (such as WiFi, compass, and accelerometer) are required.
If a device includes a particular hardware component that has a corresponding API for third-party
developers, the device implementation MUST implement that API as defined in the Android SDK
documentation.
8.1. Display
Android 1.6 includes facilities that perform certain automatic scaling and transformation operations under
some circumstances, to ensure that third-party applications run reasonably well on hardware
configurations for which they were not necessarily explicitly designed [Resources, 24] . Devices MUST
properly implement these behaviors, as detailed in this section.
8.1.1. Standard Display Configurations
This table lists the standard screen configurations considered compatible with Android:
Diagonal
Screen Size
Screen Density
Screen Type
Width (Pixels)
Height (Pixels)
Length Range
Group
Group
(inches)
QVGA
240
320
2.6 - 3.0
Small
Low
WQVGA
240
400
3.2 - 3.5
Normal
Low
FWQVGA
240
432
3.5 - 3.8
Normal
Low
HVGA
320
480
3.0 - 3.5
Normal
Medium
WVGA
480
800
3.3 - 4.0
Normal
High
FWVGA
480
854
3.5 - 4.0
Normal
High
WVGA
480
800
4.8 - 5.5
Large
Medium
FWVGA
480
854
5.0 - 5.8
Large
Medium
Device implementations corresponding to one of the standard configurations above MUST be configured
to report the indicated screen size to applications via the android.content.res.Configuration [ Resources,
25] class.
Some .apk packages have manifests that do not identify them as supporting a specific density range.
When running such applications, the following constraints apply:

• Device implementations MUST interpret any resources that are present as defaulting to
"medium" (known as "mdpi" in the SDK documentation.)
• When operating on a "low" density screen, device implementations MUST scale down medium/
mdpi assets by a factor of 0.75.
• When operating on a "high" density screen, device implementations MUST scale up medium/
mdpi assets by a factor of 1.5.
• Device implementations MUST NOT scale assets within a density range, and MUST scale
assets by exactly these factors between density ranges.
8.1.2. Non-Standard Display Configurations
Display configurations that do not match one of the standard configurations listed in Section 8.2.1 require
additional consideration and work to be compatible. Device implementers MUST contact Android
Compatibility Team as provided for in Section 12 to obtain classifications for screen-size bucket, density,
and scaling factor. When provided with this information, device implementations MUST implement them
as specified.
Note that some display configurations (such as very large or very small screens, and some aspect ratios)
are fundamentally incompatible with Android 1.6; therefore device implementers are encouraged to
contact Android Compatibility Team as early as possible in the development process.
8.1.3. Display Metrics
Device implementations MUST report correct values for all display metrics defined in
android.util.DisplayMetrics [Resources , 26].
8.2. Keyboard
Device implementations:
• MUST include support for the Input Management Framework (which allows third party
developers to create Input Management Engines -- ie soft keyboard) as detailed at
developer.android.com
• MUST provide at least one soft keyboard implementation (regardless of whether a hard
keyboard is present)
• MAY include additional soft keyboard implementations
• MAY include a hardware keyboard
• MUST NOT include a hardware keyboard that does not match one of the formats specified
in android.content.res.Configuration [ Resources, 25] (that is, QWERTY, or 12-key)
8.3. Non-touch Navigation
Device implementations:
• MAY omit non-touch navigation options (that is, may omit a trackball, 5-way directional pad, or
wheel)
• MUST report via android.content.res.Configuration [Resources , 25] the correct value for the
device's hardware

8.4. Screen Orientation
Compatible devices MUST support dynamic orientation by applications to either portrait or landscape
screen orientation. That is, the device must respect the application's request for a specific screen
orientation. Device implementations MAY select either portrait or landscape orientation as the default.
Devices MUST report the correct value for the device's current orientation, whenever queried via the
android.content.res.Configuration.orientation, android.view.Display.getOrientation(), or other APIs.
8.5. Touchscreen input
Device implementations:
• MUST have a touchscreen
• MAY have either capacative or resistive touchscreen
• MUST report the value of android.content.res.Configuration [ Resources, 25] reflecting
corresponding to the type of the specific touchscreen on the device
8.6. USB
Device implementations:
• MUST implement a USB client, connectable to a USB host with a standard USB-A port
• MUST implement the Android Debug Bridge over USB (as described in Section 7)
• MUST implement a USB mass storage client for the removable/media storage is present in the
device
• SHOULD use the micro USB form factor on the device side
• SHOULD implement support for the USB Mass Storage specification (so that either removable
or fixed storage on the device can be accessed from a host PC)
• MAY include a non-standard port on the device side, but if so MUST ship with a cable capable of
connecting the custom pinout to standard USB-A port
8.7. Navigation keys
The Home, Menu and Back functions are essential to the Android navigation paradigm. Device
implementations MUST make these functions available to the user at all times, regardless of application
state. These functions SHOULD be implemented via dedicated buttons. They MAY be implemented
using software, gestures, touch panel, etc., but if so they MUST be always accessible and not obscure or
interfere with the available application display area.
Device implementers SHOULD also provide a dedicated search key. Device implementers MAY also
provide send and end keys for phone calls.
8.8. WiFi
Device implementations MUST support 802.11b and 802.11g, and MAY support 802.11a.

8.9. Camera
Device implementations MUST include a camera. The included camera:
• MUST have a resolution of at least 2 megapixels
• SHOULD have either hardware auto-focus, or software auto-focus implemented in the camera
driver (transparent to application software)
• MAY have fixed-focus or EDOF (extended depth of field) hardware
• MAY include a flash. If the Camera includes a flash, the flash lamp MUST NOT be lit while an
android.hardware.Camera.PreviewCallback instance has been registered on a Camera preview
surface.
Device implementations MUST implement the following behaviors for the camera-related APIs
[Resources, 27] :
1. If an application has never called android.hardware.Camera.Parameters.setPreviewFormat(int),
then the device MUST use android.hardware.PixelFormat.YCbCr_420_SP for preview data
provided to application callbacks.
2. If an application registers an android.hardware.Camera.PreviewCallback instance and the
system calls the onPreviewFrame() method when the preview format is YCbCr_420_SP, the
data in the byte[] passed into onPreviewFrame() must further be in the NV21 encoding format.
(This is the format used natively by the 7k hardware family.) That is, NV21 MUST be the default.
8.9.1. Non-Autofocus Cameras
If a device lacks an autofocus camera, the device implementer MUST meet the additional requirements in
this section. Device implementations MUST implement the full Camera API included in the Android 1.6
SDK documentation in some reasonable way, regardless of actual camera hardware's capabilities.
For Android 1.6, if the camera lacks auto-focus, the device implementation MUST adhere to the following:
1. The system MUST include a read-only system property named "ro.workaround.noautofocus"
with the value of "1". This value is intended to be used by applications such as Android Market to
selectively identify device capabilities, and will be replaced in a future version of Android with a
robust API.
2. If an application calls android.hardware.Camera.autoFocus(), the system MUST call the
onAutoFocus() callback method on any registered
android.hardware.Camera.AutoFocusCallback instances, even though no focusing actually
happened. This is to avoid having existing applications break by waiting forever for an autofocus
callback that will never come.
3. The call to the AutoFocusCallback.onAutoFocus() method MUST be triggered by the driver or
framework in a new event on the main framework Looper thread. That is, Camera.autoFocus()
MUST NOT directly call AutoFocusCallback.onAutoFocus() since this violates the Android
framework threading model and will break apps.
8.10. Accelerometer
Device implementations MUST include a 3-axis accelerometer and MUST be able to deliver events at at
least 50 Hz. The coordinate system used by the accelerometer MUST comply with the Android sensor
coordinate system as detailed in the Android API s [Resources , 28].

8.11. Compass
Device implementations MUST include a 3-axis compass and MUST be able to deliver events at at least
10 Hz. The coordinate system used by the compass MUST comply with the Android sensor coordinate
system as defined in the Android API [Resources , 28].
8.12. GPS
Device implementations MUST include a GPS, and SHOULD include some form of "assisted GPS"
technique to minimize GPS lock-on time.
8.13. Telephony
Device implementations:
• MUST include either GSM or CDMA telephony
• MUST implement the appropriate APIs as detailed in the Android SDK documentation at
developer.android.com
Note that this requirement implies that non-phone devices are not compatible with Android 1.6; Android
1.6 devices MUST include telephony hardware. Please see Appendix C for information on non-phone
devices.
8.14. Volume controls
Android-compatible devices MUST include a mechanism to allow the user to increase and decrease the
audio volume. Device implementations MUST make these functions available to the user at all times,
regardless of application state. These functions MAY be implemented using physical hardware keys,
software, gestures, touch panel, etc., but they MUST be always accessible and not obscure or interfere
with the available application display area (see Display above).
When these buttons are used, the corresponding key events MUST be generated and sent to the
foreground application. If the event is not intercepted and sunk by the application then device
implementation MUST handle the event as a system volume control.
9. Performance Compatibility
One of the goals of the Android Compatibility Program is to ensure a consistent application experience for
consumers. Compatible implementations must ensure not only that applications simply run correctly on
the device, but that they do so with reasonable performance and overall good user experience.
Device implementations MUST meet the key performance metrics of an Android 1.6 compatible device,
as in the table below:
Metric
Performance Threshold
Comments

This is tested by CTS.
The following applications
The launch time is measured as the total time to
should launch within the
complete loading the default activity for the
Application
specified time.
application, including the time it takes to start the
Launch Time
Browser: less than 1300ms
Linux process, load the Android package into the
MMS/SMS: less than 700ms
Dalvik VM, and call onCreate.
AlarmClock: less than 650ms
Multiple applications will be
This is tested by CTS.
launched. Re-launching the
Simultaneous first application should
Applications
complete taking less than the
original launch time.
10. Security Model Compatibility
Device implementations MUST implement a security model consistent with the Android platform security
model as defined in Security and Permissions reference document in the APIs [Resources, 29] in the
Android developer documentation. Device implementations MUST support installation of self-signed
applications without requiring any additional permissions/certificates from any third parties/authorities.
Specifically, compatible devices MUST support the following security mechanisms:
10.1. Permissions
Device implementations MUST support the Android permissions model as defined in the Android
developer documentation [ Resources , 9]. Specifically, implementations MUST enforce each permission
defined as described in the SDK documentation; no permissions may be omitted, altered, or ignored.
Implementations MAY add additional permissions, provided the new permission ID strings are not in the
android.* namespace.
10.2. User and Process Isolation
Device implementations MUST support the Android application sandbox model, in which each application
runs as a unique Unix-style UID and in a separate process.
Device implementations MUST support running multiple applications as the same Linux user ID, provided
that the applications are properly signed and constructed, as defined in the Security and Permissions
reference [ Resources , 29].

10.3. Filesystem Permissions
Device implementations MUST support the Android file access permissions model as defined in as
defined in the Security and Permissions reference [Resources , 29].
11. Compatibility Test Suite
Device implementations MUST pass the Android Compatibility Test Suite (CTS) [ Resources, 3] available
from the Android Open Source Project, using the final shipping software on the device. Additionally,
device implementers SHOULD use the reference implementation in the Android Open Source tree as
much as possible, and MUST ensure compatibility in cases of ambiguity in CTS and for any
reimplementations of parts of the reference source code.
The CTS is designed to be run on an actual device. Like any software, the CTS may itself contain bugs.
The CTS will be versioned independently of this Compatibility Definition, and multiple revisions of the
CTS may be released for Android 1.6. However, such releases will only fix behavioral bugs in the CTS
tests and will not impose any new tests, behaviors or APIs for a given platform release.
12. Contact Us
You can contact the Android Compatibility Team at compatibility@android.com for clarifications related to
this Compatibiltiy Definition and to provide feedback on this Definition.

Appendix A: Required Application Intents
NOTE: this list is provisional, and will be updated in the future.
Application Actions
Schemes MIME Types
(none)
text/plain
http
text/html
Browser
android.intent.action.VIEW
https
application/xhtml+xml
application/
vnd.wap.xhtml+xml
(none)
android.intent.action.WEB_SEARCH
http
(none)
https
android.media.action.IMAGE_CAPTURE
android.media.action.STILL_IMAGE_CAMERA
Camera
android.media.action.VIDEO_CAMERA
android.media.action.VIDEO_CAPTURE
vnd.android.cursor.dir/
android.intent.action.VIEW
image
android.intent.action.GET_CONTENT
vnd.android.cursor.dir/
android.intent.action.PICK
video
android.intent.action.ATTACH_DATA
image/*
video/*
android.intent.action.VIEW
rtsp
video/mp4
video/3gp
android.intent.action.VIEW
http
video/3gpp
video/3gpp2
android.intent.action.DIAL
Phone /
android.intent.action.VIEW
tel
Contacts
android.intent.action.CALL
android.intent.action.DIAL
vnd.android.cursor.dir/
android.intent.action.VIEW
person

vnd.android.cursor.dir/
person
vnd.android.cursor.dir/
android.intent.action.PICK
phone
vnd.android.cursor.dir/
postal-address
vnd.android.cursor.item/
person
vnd.android.cursor.item/
android.intent.action.GET_CONTENT
phone
vnd.android.cursor.item/
postal-address
text/plain
Email
android.intent.action.SEND
image/*
video/*
android.intent.action.VIEW
mailto
android.intent.action.SENDTO
sms
android.intent.action.VIEW
smsto
SMS / MMS android.intent.action.SENDTO
mms
mmsto
audio/*
application/ogg
Music
android.intent.action.VIEW
file
application/x-ogg
application/itunes
audio/mp3
audio/x-mp3
android.intent.action.VIEW
http
audio/mpeg
audio/mp4
audio/mp4a-latm
vnd.android.cursor.dir/
artistalbum
vnd.android.cursor.dir/
album
vnd.android.cursor.dir/
android.intent.action.PICK
nowplaying
vnd.android.cursor.dir/
track
nd.android.cursor.dir/
playlist
vnd.android.cursor.dir/
video
media/*
audio/*
android.intent.action.GET_CONTENT
application/ogg
application/x-ogg
video/*

content
Package
android.intent.action.VIEW
file
Installer
package
file
android.intent.action.PACKAGE_INSTALL
http
https
android.intent.action.ALL_APPS
android.settings.SETTINGS
android.settings.WIRELESS_SETTINGS
android.settings.AIRPLANE_MODE_SETTINGS
android.settings.WIFI_SETTINGS
android.settings.APN_SETTINGS
android.settings.BLUETOOTH_SETTINGS
android.settings.DATE_SETTINGS
android.settings.LOCALE_SETTINGS
Settings
android.settings.INPUT_METHOD_SETTINGS
com.android.settings.SOUND_SETTINGS
com.android.settings.DISPLAY_SETTINGS
android.settings.SECURITY_SETTING
android.settings.LOCATION_SOURCE_SETTINGS
android.settings.INTERNAL_STORAGE_SETTINGS
android.settings.MEMORY_CARD_SETTINGS
android.intent.action.SET_WALLPAPER
Search
android.intent.action.SEARCH
query
android.intent.action.SEARCH_LONG_PRESS
Voice
android.intent.action.VOICE_COMMAND
Contacts Management
Intent Action
Description
Starts an Activity that lets the user pick
ATTACH_IMAGE
a contact to attach an image to.
Used
EXTRA_CREATE_DESCRIPTION
with SHOW_OR_CREATE_CONTACT to
specify an exact description to be

shown when prompting user about
creating a new contact.
Used
with SHOW_OR_CREATE_CONTACT to
EXTRA_FORCE_CREATE
force creating a new contact if no
matching contact found.
This is the intent that is fired when a
SEARCH_SUGGESTION_CLICKED
search suggestion is clicked on.
This is the intent that is fired when a
SEARCH_SUGGESTION_CREATE_CONTACT_CLICKED search suggestion for creating a
contact is clicked on.
This is the intent that is fired when a
SEARCH_SUGGESTION_DIAL_NUMBER_CLICKED
search suggestion for dialing a number
is clicked on.
Takes as input a data URI with a mailto:
SHOW_OR_CREATE_CONTACT
or tel: scheme.

Appendix B: Required Broadcast Intents NOTE: this list is provisional, and will be
updated in the future.
Intent Action
Description
Broadcast Action: This is broadcast once, after the
ACTION_BOOT_COMPLETED
system has finished booting.
Broadcast Action: This is broadcast once, when a
ACTION_CALL_BUTTON
call is received.
Broadcast Action: The "Camera Button" was
ACTION_CAMERA_BUTTON
pressed.
Broadcast Action: The current
ACTION_CONFIGURATION_CHANGED
device Configuration (orientation, locale, etc) has
changed.
ACTION_DATE_CHANGED
Broadcast Action: The date has changed.
Broadcast Action: Indicates low memory condition
ACTION_DEVICE_STORAGE_LOW
on the device
Broadcast Action: Indicates low memory condition
ACTION_DEVICE_STORAGE_OK
on the device no longer exists
Broadcast Action: Wired Headset plugged in or
ACTION_HEADSET_PLUG
unplugged.
Broadcast Action: An input method has been
ACTION_INPUT_METHOD_CHANGED
changed.
Broadcast Action: External media was removed
ACTION_MEDIA_BAD_REMOVAL
from SD card slot, but mount point was not
unmounted.
Broadcast Action: The "Media Button" was
ACTION_MEDIA_BUTTON
pressed.
Broadcast Action: External media is present, and
being disk-checked The path to the mount point for
ACTION_MEDIA_CHECKING
the checking media is contained in the
Intent.mData field.
Broadcast Action: User has expressed the desire to
ACTION_MEDIA_EJECT
remove the external storage media.
Broadcast Action: External media is present and
ACTION_MEDIA_MOUNTED
mounted at its mount point.
Broadcast Action: External media is present, but is
using an incompatible fs (or is blank) The path to
ACTION_MEDIA_NOFS
the mount point for the checking media is
contained in the Intent.mData field.
Broadcast Action: External media has been
ACTION_MEDIA_REMOVED
removed.
Broadcast Action: The media scanner has finished
ACTION_MEDIA_SCANNER_FINISHED
scanning a directory.
Broadcast Action: Request the media scanner to
ACTION_MEDIA_SCANNER_SCAN_FILE
scan a file and add it to the media database.

Broadcast Action: The media scanner has started
ACTION_MEDIA_SCANNER_STARTED
scanning a directory.
Broadcast Action: External media is unmounted
ACTION_MEDIA_SHARED
because it is being shared via USB mass storage.
Broadcast Action: External media is present but
ACTION_MEDIA_UNMOUNTABLE
cannot be mounted.
Broadcast Action: External media is present, but
ACTION_MEDIA_UNMOUNTED
not mounted at its mount point.
Broadcast Action: An outgoing call is about to be
ACTION_NEW_OUTGOING_CALL
placed.
Broadcast Action: A new application package has
ACTION_PACKAGE_ADDED
been installed on the device.
Broadcast Action: An existing application package
ACTION_PACKAGE_CHANGED
has been changed (eg a component has been
enabled or disabled.
Broadcast Action: The user has cleared the data of
a package. This should be preceded
by ACTION_PACKAGE_RESTARTED, after which
ACTION_PACKAGE_DATA_CLEARED
all of its persistent data is erased and this
broadcast sent. Note that the cleared package
does not receive this broadcast. The data contains
the name of the package.
Broadcast Action: An existing application package
has been removed from the device. The data
ACTION_PACKAGE_REMOVED
contains the name of the package. The package
that is being installed does not receive this Intent.
Broadcast Action: A new version of an application
ACTION_PACKAGE_REPLACED
package has been installed, replacing an existing
version that was previously installed.
Broadcast Action: The user has restarted a
package, and all of its processes have been killed.
All runtime state associated with it (processes,
ACTION_PACKAGE_RESTARTED
alarms, notifications, etc) should be removed. Note
that the restarted package does not receive this
broadcast. The data contains the name of the
package.
Broadcast Action: Some content providers have
parts of their namespace where they publish new
ACTION_PROVIDER_CHANGED
events or items that the user may be especially
interested in.
ACTION_SCREEN_OFF
Broadcast Action: Sent after the screen turns off.
ACTION_SCREEN_ON
Broadcast Action: Sent after the screen turns on.
Broadcast Action: A user ID has been removed
ACTION_UID_REMOVED
from the system.
Broadcast Action: The device has entered USB
ACTION_UMS_CONNECTED
Mass Storage mode.

Broadcast Action: The device has exited USB
ACTION_UMS_DISCONNECTED
Mass Storage mode.
Broadcast Action: Sent when the user is present
ACTION_USER_PRESENT
after device wakes up (eg when the keyguard is
gone).
Broadcast Action: The current system wallpaper
ACTION_WALLPAPER_CHANGED
has changed.
ACTION_TIME_CHANGED
Broadcast Action: The time was set.
ACTION_TIME_TICK
Broadcast Action: The current time has changed.
ACTION_TIMEZONE_CHANGED
Broadcast Action: The timezone has changed.
Broadcast Action: The charging state, or charge
ACTION_BATTERY_CHANGED
level of the battery has changed.
Broadcast Action: Indicates low battery condition
ACTION_BATTERY_LOW
on the device. This broadcast corresponds to the
"Low battery warning" system dialog.
Broadcast Action: Indicates the battery is now okay
after being low. This will be sent
ACTION_BATTERY_OKAY
after ACTION_BATTERY_LOW once the battery
has gone back up to an okay state.
Network State
Intent Action
Description
Broadcast intent action indicating that the
NETWORK_STATE_CHANGED_ACTION
state of Wi-Fi connectivity has changed.
Broadcast intent action indicating that the
RSSI_CHANGED_ACTION
RSSI (signal strength) has changed.
Broadcast intent action indicating that a
SUPPLICANT_STATE_CHANGED_ACTION
connection to the supplicant has been
established or lost.
Broadcast intent action indicating that Wi-Fi
WIFI_STATE_CHANGED_ACTION
has been enabled, disabled, enabling,
disabling, or unknown.
The network IDs of the configured networks
NETWORK_IDS_CHANGED_ACTION
could have changed.
Broadcast intent action indicating that the
ACTION_BACKGROUND_DATA_SETTING_CHANGED setting for background data usage has
changed values.
Broadcast intent indicating that a change in
CONNECTIVITY_ACTION
network connectivity has occurred.
Broadcast Action: The user has switched the
ACTION_AIRPLANE_MODE_CHANGED
phone into or out of Airplane Mode.

Appendix C: Future Considerations This appendix clarifies certain portions of this Android
1.6 Compatibility Definition, and in some cases discusses anticipated or planned changes intended for a
future version of the Android platform. This appendix is for informational and planning purposes only, and
is not part of the Compatibility Definition for Android 1.6.
1. Non-telephone Devices
Android 1.6 is intended exclusively for telephones; telephony functionality is not optional. Future versions
of the Android platform are expected to make telephony optional (and thus allow for non-phone Android
devices), but only phones are compatible with Android 1.6.
2. Bluetooth Compatibility
The Android 1.6 release of Android does not support Bluetooth APIs, so from a compatibility perspective
Bluetooth does not impose any considerations for this version of the platform. However, a future version
of Android will introduce Bluetooth APIs. At that point, supporting Bluetooth will become mandatory for
compatibility.
Consequently, we strongly recommend that Android 1.6 devices include Bluetooth, so that they will be
compatible with future versions of Android that require Bluetooth.
3. Required Hardware Components
All hardware components in Section 8 (including WiFi, magnetometer/compass, accelerometer, etc.) are
required and may not be omitted. Future versions of Android are expected to make some (but not all) of
these components optional, in tandem with corresponding tools for third-party developers to handle these
changes.
4. Sample Applications
The Compatibility Definition Document for a future version of Android will include a more extensive and
representative list of applications than the ones listed in Section 4, above. For Android 1.6, the
applications listed in Section 4 must be tested.
5. Touch Screens
Future versions of the Compatibility Definition may or may not allow for devices to omit touchscreens.
However, currently much of the Android framework implementation assumes the existence of a
touchscreen; omitting a touchscreen would break substantially all current third-party Android applications,
so in Android 1.6 a touchscreen is required for compatibility.

6. Performance
Future versions of CTS will also measure the CPU utilization and performance of the following
components of an implementation:
• 2D graphics
• 3D graphics
• Video playback
• Audio playback
• Bluetooth A2DP playback

Android 1.6 호환성 정의

Document Outline