Android 4.0 API

API 수준: 14

Android 4.0 (ICE_CREAM_SANDWICH)은 사용자와 앱 개발자를 위한 다양한 새 기능이 추가된 주요 플랫폼 버전입니다. 아래에 설명된 모든 새로운 기능과 API 외에도 Android 4.0은 중요한 플랫폼 릴리스입니다. Android 3.x의 광범위한 API 및 홀로그램 테마 세트를 작은 화면으로 제공하기 때문입니다. 앱 개발자는 이제 동일한 Android 4.0 (API 수준 14) 이상을 실행할 때 핸드셋, 태블릿 등에 최적화된 사용자 환경을 제공하는 단일 APK로 애플리케이션을 개발하고 게시할 수 있는 단일 플랫폼과 통합 API 프레임워크를 갖게 됩니다.

개발자는 Android 4.0 플랫폼을 Android SDK의 다운로드 가능한 구성요소로 사용할 수 있습니다. 다운로드 가능한 플랫폼에는 Android 라이브러리, 시스템 이미지, 에뮬레이터 스킨 세트 등이 포함됩니다. Android 4.0 개발 또는 테스트를 시작하려면 Android SDK Manager를 사용하여 플랫폼을 SDK로 다운로드하세요.

API 개요

아래 섹션에서는 Android 4.0의 새로운 API에 대한 기술적 개요를 제공합니다.

연락처 제공자의 소셜 API

ContactsContract 제공자가 정의한 연락처 API는 기기 소유자의 개인 프로필 및 사용자가 기기에 설치된 소셜 네트워크에 개별 연락처를 초대할 수 있는 기능 등 새로운 소셜 지향 기능을 지원하도록 확장되었습니다.

사용자 프로필

이제 ContactsContract.Profile 테이블에 정의된 대로 기기 소유자를 나타내는 개인 프로필이 Android에 포함됩니다. 사용자 ID를 유지하는 소셜 애플리케이션은 ContactsContract.Profile 내에 새 ContactsContract.RawContacts 항목을 만들어 사용자의 프로필 데이터에 기여할 수 있습니다. 즉, 기기 사용자를 나타내는 원시 연락처는 ContactsContract.RawContacts URI에 의해 정의된 기존의 원시 연락처 테이블에 속하지 않습니다. 대신, CONTENT_RAW_CONTACTS_URI의 테이블에 프로필 원시 연락처를 추가해야 합니다. 그런 다음 이 테이블의 원시 연락처는 '나'라는 라벨이 지정된 사용자에게 표시되는 단일 프로필로 집계됩니다.

프로필의 새 원시 연락처를 추가하려면 android.Manifest.permission#WRITE_PROFILE 권한이 필요합니다. 마찬가지로 프로필 테이블에서 읽으려면 android.Manifest.permission#READ_PROFILE 권한을 요청해야 합니다. 하지만 대부분의 앱은 프로필에 데이터를 기여하는 경우에도 사용자 프로필을 읽을 필요가 없습니다. 사용자 프로필 읽기는 민감한 권한이므로 사용자는 이를 요청하는 앱에 회의적일 수 있습니다.

초대 의도

INVITE_CONTACT 인텐트 작업을 사용하면 사용자가 소셜 네트워크에 연락처를 추가하려고 함을 나타내는 작업을 앱에서 호출할 수 있습니다. 앱을 수신하는 앱은 이를 사용하여 지정된 연락처를 해당 소셜 네트워크에 초대합니다. 대부분의 앱은 이 작업의 수신 측에 있습니다. 예를 들어 내장 피플 앱이 사용자의 연락처 세부정보에 나열된 특정 소셜 앱에 대해 '연결 추가'를 선택하면 초대 인텐트를 호출합니다.

'연결 추가' 목록에 있는 것처럼 앱을 표시하려면 앱에서 소셜 네트워크의 연락처 정보를 동기화할 수 있는 동기화 어댑터를 제공해야 합니다. 그런 다음 초대 인텐트를 전송할 때 시스템에서 시작해야 하는 활동의 정규화된 이름과 함께 앱의 동기화 구성 파일에 inviteContactActivity 속성을 추가하여 앱이 INVITE_CONTACT 인텐트에 응답한다고 시스템에 나타내야 합니다. 그러면 시작된 활동은 인텐트의 데이터에서 문제가 되는 연락처의 URI를 검색하고 이 연락처를 네트워크에 초대하거나 사용자를 사용자의 연결에 추가하는 데 필요한 작업을 실행할 수 있습니다.

대용량 사진

이제 Android에서 연락처의 고해상도 사진을 지원합니다. 이제 연락처 기록에 사진을 푸시하면 시스템에서 사진을 96x96 썸네일 이미지(이전과 같음)와 새 파일 기반 사진 저장소에 저장된 256x256 '디스플레이 사진'으로 처리합니다. 시스템에서 선택하는 정확한 크기는 향후 변경될 수 있습니다. 데이터 행의 일반적인 PHOTO 열에 큰 사진을 배치하여 연락처에 큰 사진을 추가할 수 있습니다. 그러면 시스템에서 이 사진을 적절한 썸네일로 처리하고 사진 기록을 표시합니다.

연락처 사용 의견

ContactsContract.DataUsageFeedback API를 사용하면 사용자가 각 전화번호 또는 이메일 주소를 사용하는 빈도와 같이 사용자에게 연락하는 특정 방법을 사용하는 빈도를 추적할 수 있습니다. 이 정보는 각 사용자와 연관된 각 연락 방법의 순위를 높이고 각 연락 방법에 대한 더 나은 제안을 제공하는 데 도움이 됩니다.

캘린더 제공자

새 Calendar API를 사용하면 캘린더 제공자에 저장된 캘린더, 일정, 참석자, 리마인더, 알림을 읽고 추가하고 수정하고 삭제할 수 있습니다.

다양한 앱과 위젯에서 이러한 API를 사용하여 캘린더 일정을 읽고 수정할 수 있습니다. 그러나 가장 효과적인 사용 사례는 모든 사용자의 이벤트를 위한 통합 위치를 제공하기 위해 다른 캘린더 서비스의 사용자 캘린더를 캘린더 제공자와 동기화하는 동기화 어댑터입니다. 예를 들어 Google Calendar 이벤트는 Google Calendar 동기화 어댑터를 통해 캘린더 제공자와 동기화되므로 Android에 내장된 캘린더 앱으로 이러한 이벤트를 확인할 수 있습니다.

캘린더 제공자에 포함된 캘린더 및 이벤트 관련 정보의 데이터 모델은 CalendarContract에 의해 정의됩니다. 사용자의 모든 캘린더 데이터는 CalendarContract의 다양한 서브클래스로 정의된 여러 테이블에 저장됩니다.

  • CalendarContract.Calendars 테이블에는 캘린더별 정보가 포함되어 있습니다. 이 테이블의 각 행에는 이름, 색상, 동기화 정보 등 단일 캘린더의 세부정보가 포함됩니다.
  • CalendarContract.Events 테이블에는 이벤트별 정보가 포함됩니다. 이 테이블의 각 행에는 이벤트 제목, 위치, 시작 시간, 종료 시간 등 단일 이벤트에 관한 정보가 포함됩니다. 이 이벤트는 한 번 발생할 수도 있고 여러 번 반복될 수도 있습니다. 참석자, 리마인더 및 확장된 속성은 별도의 테이블에 저장되며 이벤트의 _ID를 사용하여 이벤트와 연결됩니다.
  • CalendarContract.Instances 테이블에는 이벤트 발생의 시작 시간과 종료 시간이 포함됩니다. 이 테이블의 각 행은 단일 일치하는 항목을 나타냅니다. 일회성 이벤트의 경우, 인스턴스와 이벤트의 일대일 매핑이 가능합니다. 반복되는 이벤트의 경우, 해당 이벤트가 여러 번 발생하는 것에 맞추어 여러 행이 자동으로 생성됩니다.
  • CalendarContract.Attendees 테이블에는 이벤트 참석자 또는 참석자 정보가 포함됩니다. 각 행은 주어진 이벤트의 게스트 한 사람을 나타냅니다. 그 사람의 게스트 유형과 이벤트에 대한 해당 사람의 응답을 지정합니다.
  • CalendarContract.Reminders 테이블에는 알림/알림 데이터가 있습니다. 각 행이 주어진 이벤트에 대한 경고 하나를 나타냅니다. 이벤트 하나에 여러 개의 알림이 있을 수 있습니다. 이벤트당 리마인더 수는 MAX_REMINDERS에서 지정되며, 이는 주어진 캘린더를 소유한 동기화 어댑터에서 설정합니다. 알림은 이벤트 예약 전의 시간(분)으로 지정되며 사용자에게 알림을 보내는 알림, 이메일 또는 SMS와 같은 알람 방법을 지정합니다.
  • CalendarContract.ExtendedProperties 테이블에는 동기화 어댑터에서 사용하는 불투명한 데이터 필드가 있습니다. 제공자는 관련 이벤트가 삭제될 때 항목을 삭제하는 경우를 제외하고 이 테이블의 항목에 아무런 작업도 하지 않습니다.

캘린더 제공자를 통해 사용자의 캘린더 데이터에 액세스하려면 애플리케이션에서 READ_CALENDAR 권한 (읽기 액세스용) 및 WRITE_CALENDAR (쓰기 액세스용)을 요청해야 합니다.

이벤트 인텐트

사용자의 캘린더에 이벤트를 추가하기만 하려면 해야 할 작업이 있다면 Events.CONTENT_URI로 정의된 데이터와 함께 ACTION_INSERT 인텐트를 사용하여 새 이벤트를 만드는 Calendar 앱에서 활동을 시작할 수 있습니다. 인텐트를 사용하는 데는 권한이 필요하지 않으며 다음과 같은 추가 기능으로 이벤트 세부정보를 지정할 수 있습니다.

음성사서함 제공업체

새 음성메시지 제공자를 사용하면 애플리케이션에서 사용자의 모든 음성메시지를 하나의 시각적 프레젠테이션으로 표시하기 위해 음성메시지를 기기에 추가할 수 있습니다. 예를 들어, 사용자에게 여러 음성사서함 소스가 있을 수 있습니다(예: 휴대전화 서비스 제공업체의 하나, VoIP 또는 기타 대체 음성 서비스의 다른 소스). 이러한 앱은 음성사서함 제공업체 API를 사용하여 기기에 음성메시지를 추가할 수 있습니다. 그러면 내장 전화 애플리케이션이 통합 프레젠테이션으로 모든 음성메시지를 사용자에게 표시합니다. 시스템의 전화 애플리케이션이 모든 음성메시지를 읽을 수 있는 유일한 애플리케이션이지만 음성메시지를 제공하는 각 애플리케이션은 시스템에 추가된 음성메시지를 읽을 수 있습니다 (다른 서비스의 음성메시지는 읽을 수 없음).

현재 이 API는 서드 파티 앱이 시스템의 모든 음성메시지를 읽도록 허용하지 않으므로 음성사서함 API를 사용해야 하는 서드 파티 앱은 사용자에게 전달할 음성메시지가 있는 앱뿐입니다.

VoicemailContract 클래스는 음성메시지 제공자의 콘텐츠 제공자를 정의합니다. 서브클래스 VoicemailContract.VoicemailsVoicemailContract.Status는 앱이 기기의 저장을 위해 음성메시지 데이터를 삽입할 수 있는 테이블을 제공합니다. 음성메시지 제공업체 앱의 예는 음성메시지 제공업체 데모를 참고하세요.

멀티미디어

Android 4.0에는 사진, 동영상, 음악과 같은 미디어와 상호작용하는 애플리케이션을 위한 여러 새로운 API가 추가되었습니다.

미디어 효과

새로운 미디어 효과 프레임워크를 사용하면 이미지와 동영상에 다양한 시각 효과를 적용할 수 있습니다. 예를 들어 이미지 효과를 사용하면 적목 현상을 쉽게 수정하고, 이미지를 그레이 스케일로 변환하고, 밝기를 조정하고, 채도를 조정하고, 이미지를 회전하고 어안 효과를 적용하는 등의 작업을 할 수 있습니다. 시스템은 GPU에서 모든 효과 처리를 실행하여 최대 성능을 얻습니다.

성능을 극대화하기 위해 효과가 OpenGL 텍스처에 직접 적용되므로 애플리케이션에 효과 API를 사용하려면 먼저 유효한 OpenGL 컨텍스트가 있어야 합니다. 효과를 적용하는 텍스처는 비트맵이나 동영상, 카메라일 수 있습니다. 하지만 텍스처가 충족해야 하는 특정 제한사항이 있습니다.

  1. GL_TEXTURE_2D 텍스처 이미지에 결합되어야 합니다.
  2. 밉맵 수준을 하나 이상 포함해야 합니다.

Effect 객체는 이미지 프레임에 적용할 수 있는 단일 미디어 효과를 정의합니다. Effect를 만드는 기본 워크플로는 다음과 같습니다.

  1. OpenGL ES 2.0 컨텍스트에서 EffectContext.createWithCurrentGlContext()를 호출합니다.
  2. 반환된 EffectContext를 사용하여 EffectContext.getFactory()를 호출합니다. 이 메서드는 EffectFactory의 인스턴스를 반환합니다.
  3. createEffect()를 호출하여 @link android.media.effect.EffectFactory}의 효과 이름(예: EFFECT_FISHEYE 또는 EFFECT_VIGNETTE)을 전달합니다.

setParameter()를 호출하고 매개변수 이름과 매개변수 값을 전달하여 효과의 매개변수를 조정할 수 있습니다. 각 효과 유형은 다양한 매개변수를 허용하며 이는 효과 이름과 함께 문서화됩니다. 예를 들어 EFFECT_FISHEYE에는 왜곡의 scale에 관한 매개변수가 하나 있습니다.

텍스처에 효과를 적용하려면 Effect에서 apply()를 호출하고 입력 텍스처, 너비와 높이, 출력 텍스처를 전달합니다. 입력 텍스처는 GL_TEXTURE_2D 텍스처 이미지에 결합되어야 합니다 (일반적으로 glTexImage2D() 함수를 호출하여 실행됨). 여러 밉맵 수준을 제공할 수 있습니다. 출력 텍스처가 텍스처 이미지에 결합되지 않은 경우 효과에 의해 GL_TEXTURE_2D로서 자동 바인딩되며 밉맵 수준 (0)은 입력과 크기가 같습니다.

EffectFactory에 나열된 모든 효과는 확실히 지원됩니다. 그러나 외부 라이브러리에서 사용할 수 있는 일부 추가 효과는 일부 기기에서 지원되지 않으므로 먼저 isEffectSupported()를 호출하여 외부 라이브러리에서 원하는 효과를 지원하는지 확인해야 합니다.

원격 제어 클라이언트

RemoteControlClient를 사용하면 미디어 플레이어가 기기 잠금 화면과 같은 원격 제어 클라이언트의 재생 컨트롤을 사용 설정할 수 있습니다. 미디어 플레이어는 현재 리모컨에 표시하기 위해 재생 중인 미디어에 관한 정보(예: 트랙 정보 및 앨범 아트)를 노출할 수도 있습니다.

미디어 플레이어에 원격 제어 클라이언트를 사용 설정하려면 생성자를 사용하여 RemoteControlClient를 인스턴스화하고 ACTION_MEDIA_BUTTON를 브로드캐스트하는 PendingIntent를 전달합니다. 인텐트는 앱에서 ACTION_MEDIA_BUTTON 이벤트를 처리하는 명시적 BroadcastReceiver 구성요소도 선언해야 합니다.

플레이어가 처리할 수 있는 미디어 컨트롤 입력을 선언하려면 RemoteControlClient에서 setTransportControlFlags()를 호출하여 FLAG_KEY_MEDIA_PREVIOUSFLAG_KEY_MEDIA_NEXT와 같은 FLAG_KEY_MEDIA_* 플래그 집합을 전달해야 합니다.

그런 다음 RemoteControlClientMediaManager.registerRemoteControlClient()에 전달하여 등록해야 합니다. 등록이 완료되면 RemoteControlClient를 인스턴스화할 때 선언한 broadcast receiver가 리모컨에서 버튼을 누를 때 ACTION_MEDIA_BUTTON 이벤트를 수신합니다. 수신하는 인텐트에는 눌린 미디어 키의 KeyEvent가 포함되며, 이는 getParcelableExtra(Intent.EXTRA_KEY_EVENT)를 사용하여 인텐트에서 검색할 수 있습니다.

재생 중인 미디어에 관한 정보를 리모컨에 표시하려면 editMetaData()를 호출하고 반환된 RemoteControlClient.MetadataEditor에 메타데이터를 추가합니다. 미디어 아트워크용 비트맵, 경과 시간과 같은 숫자 정보, 텍스트 정보(예: 트랙 제목)를 제공할 수 있습니다. 사용 가능한 키에 관한 자세한 내용은 MediaMetadataRetrieverMETADATA_KEY_* 플래그를 참조하세요.

샘플 구현은 Random Music Player를 참고하세요. 이 플레이어는 Android 2.1로 계속해서 기기를 지원하면서 Android 4.0 기기에서 원격 제어 클라이언트를 사용 설정하는 호환성 로직을 제공합니다.

미디어 플레이어

  • 이제 MediaPlayer에서 온라인 미디어를 스트리밍하려면 INTERNET 권한이 필요합니다. MediaPlayer를 사용하여 인터넷에서 콘텐츠를 재생하는 경우 매니페스트에 INTERNET 권한을 추가해야 합니다. 그러지 않으면 Android 4.0부터 미디어 재생이 작동하지 않습니다.
  • setSurface()를 사용하면 Surface가 동영상 싱크로 작동하도록 정의할 수 있습니다.
  • setDataSource()를 사용하면 요청과 함께 추가 HTTP 헤더를 전송할 수 있으므로 HTTP(S) 실시간 스트리밍에 유용합니다.
  • 이제 HTTP(S) 실시간 스트리밍에서 여러 요청에서 HTTP 쿠키를 준수함

미디어 유형

Android 4.0은 다음 지원을 추가합니다.

  • HTTP/HTTPS 실시간 스트리밍 프로토콜 버전 3
  • ADTS 원본 AAC 오디오 인코딩
  • WEBP 이미지
  • Matroska 동영상

자세한 내용은 지원되는 미디어 형식을 참고하세요.

카메라

이제 Camera 클래스에는 얼굴을 인식하고 초점과 측정 영역을 제어하는 API가 포함되어 있습니다.

얼굴 인식

이제 카메라 앱은 피사체의 얼굴뿐만 아니라 눈과 입과 같은 특정 얼굴 특징을 감지하는 Android의 얼굴 인식 API를 사용하여 기능을 향상시킬 수 있습니다.

카메라 애플리케이션에서 얼굴을 인식하려면 setFaceDetectionListener()를 호출하여 Camera.FaceDetectionListener를 등록해야 합니다. 그런 다음 startFaceDetection()를 호출하여 카메라 노출 영역을 시작하고 얼굴 감지를 시작할 수 있습니다.

시스템이 카메라 장면에서 얼굴을 하나 이상 감지하면 Camera.FaceDetectionListener의 구현에서 Camera.Face 객체의 배열을 포함하여 onFaceDetection() 콜백을 호출합니다.

Camera.Face 클래스의 인스턴스는 다음을 비롯하여 감지된 얼굴에 관한 다양한 정보를 제공합니다.

  • 카메라의 현재 시야를 기준으로 얼굴의 경계를 지정하는 Rect
  • 객체가 사람 얼굴이라는 것을 시스템에서 얼마나 확신하는지 나타내는 1에서 100 사이의 정수
  • 여러 얼굴을 추적할 수 있는 고유 ID
  • 눈과 입의 위치를 나타내는 여러 Point 객체

참고: 일부 기기에서는 얼굴 인식이 지원되지 않을 수 있으므로 getMaxNumDetectedFaces()를 호출하여 확인하고 반환 값이 0보다 큰지 확인해야 합니다. 또한 일부 기기는 눈과 입 식별을 지원하지 않을 수 있으며, 이 경우 Camera.Face 객체의 해당 필드는 null이 됩니다.

초점 및 측정 영역

이제 카메라 앱에서 초점과 화이트 밸런스 및 자동 노출 측정을 위해 카메라가 사용하는 영역을 제어할 수 있습니다. 두 기능 모두 새로운 Camera.Area 클래스를 사용하여 초점을 맞추거나 측정해야 하는 카메라의 현재 뷰 영역을 지정합니다. Camera.Area 클래스의 인스턴스는 Rect로 영역의 경계와 영역의 가중치(고려하는 다른 영역 대비 해당 영역의 중요도를 나타냄)를 정수로 정의합니다.

포커스 영역 또는 측정 영역을 설정하기 전에 먼저 getMaxNumFocusAreas() 또는 getMaxNumMeteringAreas()를 각각 호출해야 합니다. 0을 반환하면 기기는 상응하는 기능을 지원하지 않는 것입니다.

사용할 초점 또는 측정 영역을 지정하려면 setFocusAreas() 또는 setMeteringAreas()를 호출하면 됩니다. 각각 초점 또는 측정에 고려할 영역을 나타내는 Camera.Area 객체의 List를 사용합니다. 예를 들어 사용자가 미리보기의 영역을 터치하여 포커스 영역을 설정할 수 있는 기능을 구현할 수 있습니다. 그런 다음 이 영역을 Camera.Area 객체로 변환하고 장면의 해당 영역에 카메라 포커스를 설정하도록 요청할 수 있습니다. 해당 영역의 초점이나 노출이 해당 영역의 장면이 변경됨에 따라 계속 업데이트됩니다.

사진에 대한 연속 자동 초점

이제 사진을 찍을 때 연속 자동 초점 (CAF)을 사용 설정할 수 있습니다. 카메라 앱에서 CAF를 사용 설정하려면 FOCUS_MODE_CONTINUOUS_PICTUREsetFocusMode()에 전달합니다. 사진을 캡처할 준비가 되면 autoFocus()를 호출합니다. Camera.AutoFocusCallback는 포커스가 맞춰졌는지 나타내는 콜백을 즉시 수신합니다. 콜백을 수신한 후 CAF를 재개하려면 cancelAutoFocus()를 호출해야 합니다.

참고: API 수준 9에 추가된 FOCUS_MODE_CONTINUOUS_VIDEO를 사용하여 동영상을 캡처할 때도 연속 자동 초점도 지원됩니다.

기타 카메라 기능

  • 이제 동영상을 녹화하는 동안 takePicture()를 호출하여 동영상 세션을 중단하지 않고도 사진을 저장할 수 있습니다. 그 전에 isVideoSnapshotSupported()를 호출하여 하드웨어에서 이를 지원하는지 확인해야 합니다.
  • 이제 setAutoExposureLock()setAutoWhiteBalanceLock()로 자동 노출과 화이트 밸런스를 잠가 이러한 속성이 변경되지 않도록 할 수 있습니다.
  • 이제 카메라 미리보기가 실행되는 동안 setDisplayOrientation()를 호출할 수 있습니다. 이전에는, 미리보기를 시작하기 전에만 이 메서드를 호출할 수 있었지만 이제는 언제든지 방향을 변경할 수 있습니다.

카메라 브로드캐스트 인텐트

  • Camera.ACTION_NEW_PICTURE: 사용자가 새 사진을 캡처했음을 나타냅니다. 내장 카메라 앱은 사진이 캡처된 후 이 브로드캐스트를 호출하고 서드 파티 카메라 앱도 사진을 캡처한 후 이 인텐트를 브로드캐스트해야 합니다.
  • Camera.ACTION_NEW_VIDEO: 사용자가 새 동영상을 캡처했음을 나타냅니다. 내장 카메라 앱은 동영상이 녹화된 후 이 브로드캐스트를 호출하고 서드 파티 카메라 앱도 동영상을 캡처한 후 이 인텐트를 브로드캐스트해야 합니다.

Android Beam (NFC를 사용한 NDEF 푸시)

Android Beam은 새로운 NFC 기능으로, 한 기기에서 다른 기기로 NDEF 메시지를 보낼 수 있도록 지원합니다('NDEF 푸시' 프로세스라고도 함). 데이터 전송은 Android Beam을 지원하는 두 대의 Android 지원 기기가 약 4cm 거리 (일반적으로 뒷면에 닿을 때)에 있을 때 시작됩니다. NDEF 메시지 내 데이터에는 기기 간에 공유하려는 모든 데이터가 포함될 수 있습니다. 예를 들어 피플 앱은 연락처를 공유하고, YouTube는 동영상을 공유하며, 브라우저는 Android Beam을 사용하여 URL을 공유합니다.

Android Beam을 사용하여 기기 간에 데이터를 전송하려면 활동이 포그라운드에 있는 동안 공유하려는 정보가 포함된 NdefMessage를 만들어야 합니다. 그런 다음, 다음 두 가지 방법 중 하나로 NdefMessage를 시스템에 전달해야 합니다.

시스템에서 NDEF 메시지를 다른 기기에 성공적으로 전송한 후 특정 코드를 실행하려면 NfcAdapter.OnNdefPushCompleteCallback를 구현하고 setNdefPushCompleteCallback()로 설정하면 됩니다. 메시지가 전송되면 시스템은 onNdefPushComplete()를 호출합니다.

수신 기기에서 시스템은 일반 NFC 태그와 비슷한 방식으로 NDEF 푸시 메시지를 전달합니다. 시스템은 NdefMessage의 첫 번째 NdefRecord에 따라 설정된 URL 또는 MIME 유형으로 활동을 시작하기 위해 ACTION_NDEF_DISCOVERED 작업으로 인텐트를 호출합니다. 응답하려는 활동의 경우 앱이 관심을 두는 URL 또는 MIME 유형에 관한 인텐트 필터를 선언할 수 있습니다. 태그 디스패치에 관한 자세한 내용은 NFC 개발자 가이드를 참고하세요.

NdefMessage에 URI가 포함되도록 하려면 이제 편의 메서드 createUri를 사용하여 문자열 또는 Uri 객체를 기반으로 새 NdefRecord를 구성하면 됩니다. URI가 Android Beam 이벤트 중에도 애플리케이션에서 수신하기를 원하는 특수한 형식인 경우 수신되는 NDEF 메시지를 수신할 수 있도록 동일한 URI 스키마를 사용하여 활동의 인텐트 필터를 만들어야 합니다.

또한 다른 애플리케이션이 동일한 인텐트 작업을 필터링하는 경우에도 애플리케이션이 수신되는 NDEF 메시지를 처리하도록 하려면 NdefMessage와 함께 'Android 애플리케이션 레코드'를 전달해야 합니다. createApplicationRecord()를 호출하고 애플리케이션의 패키지 이름을 전달하여 Android 애플리케이션 레코드를 만들 수 있습니다. 다른 기기가 애플리케이션 레코드가 포함된 NDEF 메시지를 수신하고 여러 애플리케이션에 지정된 인텐트를 처리하는 활동이 포함된 경우 시스템은 항상 일치하는 애플리케이션 레코드에 따라 애플리케이션의 활동에 메시지를 전달합니다. 현재 대상 기기에 애플리케이션이 설치되어 있지 않은 경우 시스템은 Android 애플리케이션 레코드를 사용하여 Google Play를 실행하고 사용자를 애플리케이션으로 안내합니다.

애플리케이션이 NFC API를 사용하여 NDEF 푸시 메시지를 실행하지 않는 경우 Android는 기본 동작을 제공합니다. 애플리케이션이 한 기기에서 포그라운드에 있고 다른 Android 지원 기기에서 Android Beam을 호출하면 다른 기기는 애플리케이션을 식별하는 Android 애플리케이션 레코드와 함께 NDEF 메시지를 수신합니다. 수신 기기에 애플리케이션이 설치되어 있으면 시스템에서 이를 실행하고, 설치되지 않은 경우 Google Play가 열리고 사용자를 애플리케이션으로 안내합니다.

Android Beam 및 기타 NFC 기능에 대한 자세한 내용은 NFC 기본사항 개발자 가이드를 참조하세요. Android Beam을 사용하는 코드 예는 Android Beam 데모를 참고하세요.

Wi-Fi P2P

Android는 이제 핫스팟이나 인터넷 연결 없이도 (Wi-Fi Alliance의 Wi-Fi DirectTM 인증 프로그램에 따라) Android 지원 기기와 다른 기기 유형 간의 Wi-Fi P2P (Wi-Fi P2P) 연결을 지원합니다. Android 프레임워크는 각 기기가 Wi-Fi P2P를 지원할 때 다른 기기를 검색하고 연결한 다음 블루투스 연결보다 훨씬 긴 거리의 빠른 연결을 통해 통신할 수 있는 Wi-Fi P2P API 집합을 제공합니다.

새 패키지 android.net.wifi.p2p에는 Wi-Fi를 사용하여 P2P 연결을 실행하기 위한 모든 API가 포함되어 있습니다. 사용해야 하는 기본 클래스는 WifiP2pManager이며 getSystemService(WIFI_P2P_SERVICE)를 호출하여 가져올 수 있습니다. WifiP2pManager에는 다음을 실행할 수 있는 API가 포함되어 있습니다.

  • initialize()를 호출하여 P2P 연결을 위해 애플리케이션을 초기화합니다.
  • discoverPeers()를 호출하여 근처 기기를 찾아보세요.
  • connect()를 호출하여 P2P 연결 시작
  • 기타

다음과 같은 몇 가지 다른 인터페이스와 클래스도 필요합니다.

  • WifiP2pManager.ActionListener 인터페이스를 사용하면 피어 검색 또는 피어 연결과 같은 작업이 성공하거나 실패할 때 콜백을 수신할 수 있습니다.
  • WifiP2pManager.PeerListListener 인터페이스를 사용하면 발견된 피어에 대한 정보를 수신할 수 있습니다. 이 콜백은 WifiP2pDeviceList를 제공합니다. 이 객체에서 범위 내의 각 기기에 관한 WifiP2pDevice 객체를 가져와 기기 이름, 주소, 기기 유형, 기기에서 지원하는 WPS 구성 등의 정보를 가져올 수 있습니다.
  • WifiP2pManager.GroupInfoListener 인터페이스를 사용하면 P2P 그룹에 관한 정보를 수신할 수 있습니다. 이 콜백은 소유자, 네트워크 이름, 암호와 같은 그룹 정보를 제공하는 WifiP2pGroup 객체를 제공합니다.
  • WifiP2pManager.ConnectionInfoListener 인터페이스를 사용하여 현재 연결에 관한 정보를 수신할 수 있습니다. 이 콜백은 그룹이 만들어졌는지, 누가 그룹 소유자인지와 같은 정보가 포함된 WifiP2pInfo 객체를 제공합니다.

Wi-Fi P2P API를 사용하려면 앱에서 다음 사용자 권한을 요청해야 합니다.

  • ACCESS_WIFI_STATE
  • CHANGE_WIFI_STATE
  • INTERNET (앱이 기술적으로 인터넷에 연결되지는 않지만 표준 자바 소켓을 사용하여 Wi-Fi P2P 피어와 통신하려면 인터넷 권한이 필요합니다).

Android 시스템은 특정 Wi-Fi P2P 이벤트 중에 여러 다른 작업을 브로드캐스트합니다.

자세한 내용은 WifiP2pManager 문서를 참고하세요. Wi-Fi P2P 데모 샘플 애플리케이션도 살펴보세요.

Bluetooth 건강 기기

이제 Android에서 블루투스 건강 프로필 기기를 지원하므로 블루투스를 사용하여 블루투스를 지원하는 건강 기기(예: 심박수 모니터, 혈압계, 체온계, 체중계)와 통신하는 애플리케이션을 만들 수 있습니다.

일반 헤드셋 및 A2DP 프로필 기기와 마찬가지로 프로필 프록시 객체와의 연결을 설정하려면 BluetoothProfile.ServiceListenerHEALTH 프로필 유형과 함께 getProfileProxy()를 호출해야 합니다.

건강 프로필 프록시 (BluetoothHealth 객체)를 획득하면 페어링된 건강 기기에 연결하고 기기와 통신하려면 다음과 같은 새로운 블루투스 클래스가 포함됩니다.

  • BluetoothHealthCallback: 이 클래스를 확장하고 콜백 메서드를 구현하여 애플리케이션 등록 상태 및 블루투스 채널 상태의 변경사항에 관한 업데이트를 수신해야 합니다.
  • BluetoothHealthAppConfiguration: BluetoothHealthCallback에 콜백하는 동안 이 객체의 인스턴스를 받습니다. 이 인스턴스는 사용 가능한 블루투스 의료 기기에 관한 구성 정보를 제공하며, BluetoothHealth API와의 연결을 시작하고 종료하는 등 다양한 작업을 실행하는 데 이 인스턴스를 사용해야 합니다.

블루투스 건강 프로필 사용에 관한 자세한 내용은 BluetoothHealth 문서를 참고하세요.

접근성

Android 4.0은 새로운 터치하여 탐색 모드와 뷰 콘텐츠에 관한 자세한 정보를 제공하거나 고급 접근성 서비스를 개발할 수 있는 확장 API를 사용하여 시각장애인 사용자의 접근성을 개선합니다.

터치하여 탐색 모드

이제 시각 장애가 있는 사용자는 손가락을 터치한 후 화면에서 드래그하여 콘텐츠의 음성 설명을 들을 수 있습니다. 터치하여 탐색 모드는 가상 커서처럼 작동하므로 스크린 리더가 사용자가 D패드나 트랙볼로 탐색할 때와 동일한 방식으로 시뮬레이션된 '마우스 오버' 이벤트 발생 시 android:contentDescriptionsetContentDescription()에서 제공하는 정보를 읽어 설명 텍스트를 식별할 수 있습니다. 따라서 애플리케이션의 뷰, 특히 ImageButton, EditText, ImageView 및 설명 텍스트가 자연스럽게 포함되지 않을 수 있는 기타 위젯에 관한 설명 텍스트를 제공해야 한다는 점을 상기시켜 주세요.

뷰 접근성

스크린 리더와 같은 접근성 서비스에 제공되는 정보를 개선하려면 맞춤 View 구성요소에서 접근성 이벤트의 새 콜백 메서드를 구현하면 됩니다.

먼저 Android 4.0에서 sendAccessibilityEvent() 메서드의 동작이 변경되었다는 점에 유의해야 합니다. 이전 버전의 Android와 마찬가지로 사용자가 기기에서 접근성 서비스를 사용 설정하고 클릭 또는 마우스 오버와 같은 입력 이벤트가 발생하면 각 뷰에 sendAccessibilityEvent() 호출로 알림이 전송됩니다. 이전에는 sendAccessibilityEvent()를 구현하면 AccessibilityEvent가 초기화되어 AccessibilityManager로 전송되었습니다. 새 동작에는 뷰와 그 상위 요소에서 이벤트에 더 많은 문맥 정보를 추가할 수 있는 몇 가지 추가 콜백 메서드가 포함됩니다.

  1. 호출될 때 sendAccessibilityEvent()sendAccessibilityEventUnchecked() 메서드는 onInitializeAccessibilityEvent()를 따릅니다.

    View의 맞춤 구현은 onInitializeAccessibilityEvent()를 구현하여 추가 접근성 정보를 AccessibilityEvent에 연결할 수도 있지만 슈퍼 구현을 호출하여 표준 콘텐츠 설명, 항목 색인 등의 기본 정보를 제공해야 합니다. 그러나 이 콜백에 텍스트 콘텐츠를 추가해서는 안 됩니다. 추가는 다음에 발생합니다.

  2. 초기화된 후 이벤트가 텍스트 정보로 채워야 하는 여러 유형 중 하나인 경우 뷰는 dispatchPopulateAccessibilityEvent() 호출을 수신하며 이는 onPopulateAccessibilityEvent() 콜백을 따릅니다.

    일반적으로 View의 맞춤 구현은 android:contentDescription 텍스트가 없거나 충분하지 않은 경우 onPopulateAccessibilityEvent()를 구현하여 AccessibilityEvent에 텍스트 콘텐츠를 추가해야 합니다. AccessibilityEvent에 텍스트 설명을 더 추가하려면 getText().add()를 호출합니다.

  3. 이 시점에서 View는 상위 뷰에서 requestSendAccessibilityEvent()를 호출하여 이벤트를 뷰 계층 구조 위로 전달합니다. 그러면 각 상위 뷰는 최종적으로 루트 뷰에 도달할 때까지 AccessibilityRecord를 추가하여 접근성 정보를 보강할 수 있습니다. 루트 뷰는 궁극적으로 sendAccessibilityEvent()를 사용하여 이벤트를 AccessibilityManager로 전송합니다.

View 클래스를 확장할 때 유용한 위의 새 메서드 외에도 AccessibilityDelegate를 확장하고 setAccessibilityDelegate()를 사용하여 뷰에서 설정하여 View에서 이러한 이벤트 콜백을 가로챌 수도 있습니다. 이렇게 하면 뷰의 각 접근성 메서드가 대리자의 상응하는 메서드 호출을 지연합니다. 예를 들어 뷰가 onPopulateAccessibilityEvent() 호출을 수신하면 View.AccessibilityDelegate의 동일한 메서드에 전달합니다. 대리자가 처리하지 않은 모든 메서드는 기본 동작을 위해 뷰로 바로 다시 돌아갑니다. 이렇게 하면 View 클래스를 확장하지 않고 특정 뷰에 필요한 메서드만 재정의할 수 있습니다.

Android 4.0 이전 버전과의 호환성을 유지하면서 새로운 접근성 API도 지원하려는 경우 이전 버전과 호환되는 디자인에서 새로운 접근성 API를 제공하는 유틸리티 클래스 세트를 사용하여 최신 버전의 v4 지원 라이브러리 (호환성 패키지, r4)를 사용하면 됩니다.

접근성 서비스

접근성 서비스를 개발하는 경우 사용자를 위한 고급 접근성 의견을 제공할 수 있도록 다양한 접근성 이벤트에 관한 정보가 크게 확장되었습니다. 특히 이벤트가 뷰 구성을 기반으로 생성되어 더 나은 컨텍스트 정보를 제공하고 접근성 서비스가 뷰 계층 구조를 순회하여 추가 뷰 정보를 얻고 특별한 사례를 처리할 수 있도록 합니다.

접근성 서비스 (예: 스크린 리더)를 개발하는 경우 다음 절차에 따라 추가 콘텐츠 정보에 액세스하고 뷰 계층 구조를 순회할 수 있습니다.

  1. 애플리케이션에서 AccessibilityEvent를 수신하면 AccessibilityEvent.getRecord()를 호출하여 특정 AccessibilityRecord를 검색합니다 (이벤트에 여러 레코드가 연결될 수 있음).
  2. AccessibilityEvent 또는 개별 AccessibilityRecord에서 getSource()를 호출하여 AccessibilityNodeInfo 객체를 가져올 수 있습니다.

    AccessibilityNodeInfo은 창 콘텐츠의 단일 노드를 해당 노드에 대한 접근성 정보를 쿼리할 수 있는 형식으로 나타냅니다. AccessibilityEvent에서 반환된 AccessibilityNodeInfo 객체는 이벤트 소스를 설명하는 반면, AccessibilityRecord의 소스는 이벤트 소스의 이전 버전을 설명합니다.

  3. AccessibilityNodeInfo를 사용하면 관련 정보를 쿼리하고 getParent() 또는 getChild()를 호출하여 뷰 계층 구조를 순회하고 노드에 하위 뷰를 추가할 수도 있습니다.

애플리케이션이 시스템에 접근성 서비스로 자신을 게시하려면 AccessibilityServiceInfo에 해당하는 XML 구성 파일을 선언해야 합니다. 접근성 서비스 만들기에 관한 자세한 내용은 AccessibilityServiceSERVICE_META_DATA에서 XML 구성에 관한 정보를 참고하세요.

기타 접근성 API

기기의 접근성 상태에 관심이 있다면 AccessibilityManager에 다음과 같은 새로운 API가 있습니다.

맞춤법 검사기 서비스

새로운 맞춤법 검사기 프레임워크를 사용하면 앱에서 입력 방법 프레임워크 (IME용)와 유사한 방식으로 맞춤법 검사기를 만들 수 있습니다. 새 맞춤법 검사기를 만들려면 SpellCheckerService를 확장하고 SpellCheckerService.Session 클래스를 확장하여 인터페이스의 콜백 메서드에서 제공하는 텍스트를 기반으로 맞춤법 추천을 제공하는 서비스를 구현해야 합니다. SpellCheckerService.Session 콜백 메서드에서 맞춤법 추천을 SuggestionsInfo 객체로 반환해야 합니다.

맞춤법 검사기 서비스를 사용하는 애플리케이션은 서비스에 필요한 BIND_TEXT_SERVICE 권한을 선언해야 합니다. 또한 서비스는 <action android:name="android.service.textservice.SpellCheckerService" />를 인텐트의 작업으로 사용하여 인텐트 필터를 선언해야 하며 맞춤법 검사기의 구성 정보를 선언하는 <meta-data> 요소를 포함해야 합니다.

코드 예는 샘플 맞춤법 검사기 서비스 앱과 샘플 맞춤법 검사기 클라이언트 앱을 참고하세요.

텍스트 음성 변환 엔진

Android의 텍스트 음성 변환 (TTS) API는 애플리케이션이 맞춤 TTS 엔진을 더 쉽게 구현할 수 있도록 크게 확장되었으며, TTS 엔진을 사용하려는 애플리케이션에는 엔진을 선택할 수 있는 몇 가지 새로운 API가 있습니다.

텍스트 음성 변환 엔진 사용

이전 버전의 Android에서는 TextToSpeech 클래스를 사용하여 시스템에서 제공하는 TTS 엔진을 사용하여 텍스트 음성 변환 (TTS) 작업을 실행하거나 setEngineByPackageName()를 사용하여 맞춤 엔진을 설정할 수 있었습니다. Android 4.0에서 setEngineByPackageName() 메서드는 지원 중단되었으며 이제 TTS 엔진의 패키지 이름을 허용하는 새로운 TextToSpeech 생성자와 함께 사용할 엔진을 지정할 수 있습니다.

getEngines()로 사용 가능한 TTS 엔진을 쿼리할 수도 있습니다. 이 메서드는 엔진 아이콘, 라벨, 패키지 이름과 같은 메타데이터가 포함된 TextToSpeech.EngineInfo 객체의 목록을 반환합니다.

텍스트 음성 변환 엔진 빌드

이전에는 커스텀 엔진에서 문서화되지 않은 네이티브 헤더 파일을 사용하여 엔진을 빌드해야 했습니다. Android 4.0에는 TTS 엔진 빌드를 위한 완전한 프레임워크 API 세트가 있습니다.

기본 설정에는 INTENT_ACTION_TTS_SERVICE 인텐트에 응답하는 TextToSpeechService의 구현이 필요합니다. TTS 엔진의 기본 작업은 TextToSpeechService를 확장하는 서비스의 onSynthesizeText() 콜백 중에 발생합니다. 시스템은 이 메서드에 다음 두 객체를 제공합니다.

  • SynthesisRequest: 합성할 텍스트, 언어, 말하기 속도, 음성 높낮이 등 다양한 데이터를 포함합니다.
  • SynthesisCallback: TTS 엔진이 결과 음성 데이터를 스트리밍 오디오로 제공하는 인터페이스입니다. 먼저 엔진은 start()를 호출하여 오디오를 전달할 준비가 되었음을 나타내야 합니다. 그런 다음 audioAvailable()를 호출하여 오디오 데이터를 바이트 버퍼에 전달해야 합니다. 엔진이 모든 오디오가 버퍼를 통해 전달되면 done()를 호출합니다.

이제 프레임워크가 TTS 엔진을 만드는 데 실제 API를 지원하므로 네이티브 코드 구현 지원을 삭제했습니다. 이전 TTS 엔진을 새 프레임워크로 변환하는 데 사용할 수 있는 호환성 레이어에 관한 블로그 게시물을 찾습니다.

새로운 API를 사용하는 TTS 엔진 예는 TTS(텍스트 음성 변환) 샘플 앱을 참고하세요.

네트워크 사용량

Android 4.0은 사용자에게 애플리케이션이 사용하는 네트워크 데이터의 양을 정밀하게 보여줍니다. 설정 앱은 사용자가 네트워크 데이터 사용량에 설정된 한도를 관리하고 개별 앱의 백그라운드 데이터 사용을 중지할 수 있는 컨트롤을 제공합니다. 사용자가 백그라운드에서 앱의 데이터 액세스를 사용 중지하지 않도록 하려면 데이터 연결을 효율적으로 사용하기 위한 전략을 개발하고 사용 가능한 연결 유형에 따라 사용량을 조정해야 합니다.

애플리케이션에서 다수의 네트워크 트랜잭션을 실행하는 경우 앱의 데이터 사용 습관을 사용자가 제어할 수 있도록 하는 사용자 설정을 제공해야 합니다. 예를 들어 앱의 데이터 동기화 빈도, Wi-Fi에서만 업로드/다운로드를 실행할지 여부, 로밍 중에 데이터를 사용할지 여부 등입니다. 이러한 제어 기능을 사용할 수 있게 되면 사용자가 앱의 데이터 사용량 한도에 가까워질 때 앱의 데이터 액세스를 사용 중지할 가능성이 크게 줄어듭니다. 이러한 설정이 포함된 환경설정 활동을 제공하는 경우 매니페스트 선언에 ACTION_MANAGE_NETWORK_USAGE 작업의 인텐트 필터를 포함해야 합니다. 예:

<activity android:name="DataPreferences" android:label="@string/title_preferences">
    <intent-filter>
       <action android:name="android.intent.action.MANAGE_NETWORK_USAGE" />
       <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</activity>

이 인텐트 필터는 이것이 애플리케이션의 데이터 사용량을 제어하는 활동임을 시스템에 나타냅니다. 따라서 사용자가 설정 앱에서 앱이 사용 중인 데이터의 양을 검사할 때 환경설정 활동을 시작하는 '애플리케이션 설정 보기' 버튼을 사용할 수 있으므로 사용자는 앱에서 사용하는 데이터의 양을 미세 조정할 수 있습니다.

또한 getBackgroundDataSetting()가 이제 지원 중단되었으며 항상 true를 반환합니다. 대신 getActiveNetworkInfo()를 사용하세요. 네트워크 트랜잭션을 시도하기 전에 항상 getActiveNetworkInfo()를 호출하여 현재 네트워크를 나타내는 NetworkInfo를 가져오고 isConnected()를 쿼리하여 기기가 연결되어 있는지 확인해야 합니다. 그런 다음 기기가 로밍 중인지 또는 Wi-Fi에 연결되어 있는지와 같은 다른 연결 속성을 확인할 수 있습니다.

엔터프라이즈

Android 4.0은 다음 기능으로 엔터프라이즈 애플리케이션의 기능을 확장합니다.

VPN 서비스

새로운 VpnService를 사용하면 애플리케이션이 Service로 실행되는 자체 VPN (가상 사설망)을 구축할 수 있습니다. VPN 서비스는 자체 주소와 라우팅 규칙을 사용하여 가상 네트워크의 인터페이스를 만들고 파일 설명자를 사용하여 모든 읽기 및 쓰기를 수행합니다.

VPN 서비스를 만들려면 네트워크 주소, DNS 서버, 네트워크 경로 등을 지정할 수 있는 VpnService.Builder를 사용합니다. 완료되면 ParcelFileDescriptor를 반환하는 establish()를 호출하여 인터페이스를 설정할 수 있습니다.

VPN 서비스는 패킷을 가로챌 수 있기 때문에 보안에 영향을 미칠 수 있습니다. 따라서 VpnService를 구현하는 경우 서비스에서 BIND_VPN_SERVICE를 요구하여 시스템만 서비스에 바인딩할 수 있도록 해야 합니다 (시스템에만 이 권한이 부여되며 앱에서는 요청할 수 없음). VPN 서비스를 사용하려면 사용자가 시스템 설정에서 수동으로 VPN 서비스를 사용 설정해야 합니다.

기기 정책

기기 제한을 관리하는 애플리케이션은 이제 setCameraDisabled()USES_POLICY_DISABLE_CAMERA 속성 (정책 구성 파일에서 <disable-camera /> 요소로 적용됨)을 사용하여 카메라를 사용 중지할 수 있습니다.

인증서 관리

KeyChain 클래스는 시스템 키 저장소의 인증서를 가져오고 액세스할 수 있는 API를 제공합니다. 인증서는 클라이언트 인증서 (사용자의 ID 확인)와 인증 기관 인증서 (서버 ID 확인)의 설치를 간소화합니다. 웹브라우저 또는 이메일 클라이언트와 같은 애플리케이션은 설치된 인증서에 액세스하여 서버에 사용자를 인증할 수 있습니다. 자세한 내용은 KeyChain 문서를 참조하세요.

기기 센서

Android 4.0에는 두 가지 새로운 센서 유형이 추가되었습니다.

기기에 TYPE_AMBIENT_TEMPERATURETYPE_RELATIVE_HUMIDITY 센서가 모두 있는 경우 이 센서를 사용하여 이슬점과 절대 습도를 계산할 수 있습니다.

이전의 온도 센서인 TYPE_TEMPERATURE가 지원 중단되었습니다. 대신 TYPE_AMBIENT_TEMPERATURE 센서를 사용해야 합니다.

또한 Android의 세 가지 합성 센서가 크게 개선되어 이제 지연 시간이 짧고 출력이 더 부드러워졌습니다. 이러한 센서에는 중력 센서 (TYPE_GRAVITY), 회전 벡터 센서 (TYPE_ROTATION_VECTOR), 선형 가속 센서 (TYPE_LINEAR_ACCELERATION)가 포함됩니다. 개선된 센서는 자이로스코프 센서를 사용하여 출력을 개선하므로 자이로스코프가 있는 기기에만 센서가 표시됩니다.

작업 모음

ActionBar가 몇 가지 새로운 동작을 지원하도록 업데이트되었습니다. 무엇보다도 시스템은 작은 화면에서 실행될 때 모든 화면 크기에서 최적의 사용자 환경을 제공하기 위해 작업 모음의 크기와 구성을 적절하게 관리합니다. 예를 들어 화면이 좁은 경우 (예: 핸드셋이 세로 모드 방향인 경우) 작업 모음의 탐색 탭은 기본 작업 모음 바로 아래에 표시되는 '누적 막대'에 표시됩니다. 화면이 좁을 때 모든 작업 항목을 화면 하단에 있는 별도의 막대에 배치하는 '분할 작업 모음'을 선택할 수도 있습니다.

작업 모음 분할

작업 모음에 여러 작업 항목이 포함되어 있다면 작업 모음 중 일부가 좁은 화면의 작업 모음에 맞지 않으므로 시스템에서 더 많은 작업 항목을 더보기 메뉴에 배치합니다. 하지만 Android 4.0에서는 '분할 작업 모음'을 사용 설정할 수 있으므로 더 많은 작업 항목이 화면 하단의 별도의 막대에 표시될 수 있습니다. 분할 작업 모음을 사용 설정하려면 "splitActionBarWhenNarrow"가 포함된 android:uiOptions<application> 태그 또는 매니페스트 파일의 개별 <activity> 태그에 추가합니다. 사용 설정하면 화면이 좁을 때 시스템에서 모든 작업 항목을 위한 추가 표시줄을 화면 하단에 추가합니다 (기본 작업 모음에는 작업 항목이 표시되지 않음).

ActionBar.Tab API에서 제공하는 탐색 탭을 사용하지만 상단에 기본 작업 모음이 필요하지 않은 경우 (탭만 상단에 표시하려면) 위에서 설명한 대로 분할 작업 모음을 사용 설정하고 setDisplayShowHomeEnabled(false)를 호출하여 작업 모음의 애플리케이션 아이콘을 사용 중지합니다. 기본 작업 모음은 사라지고 상단의 탐색 탭과 화면 하단의 작업 항목만 남습니다.

작업 모음 스타일

작업 모음에 맞춤 스타일을 적용하려면 새 스타일 속성 backgroundStackedbackgroundSplit를 사용하여 누적 막대와 분할 막대에 배경 드로어블 또는 색상을 각각 적용하면 됩니다. setStackedBackgroundDrawable()setSplitBackgroundDrawable()를 사용하여 런타임에 이러한 스타일을 설정할 수도 있습니다.

작업 제공자

ActionProvider 클래스를 사용하면 작업 항목의 특수 핸들러를 만들 수 있습니다. 작업 제공자는 작업 뷰, 기본 작업 동작, 연결된 각 작업 항목의 하위 메뉴를 정의할 수 있습니다. 동적 동작 (예: 가변적인 작업 뷰, 기본 작업 또는 하위 메뉴)이 있는 작업 항목을 만들려면 프래그먼트나 활동에서 다양한 작업 항목 변환을 처리하는 것보다 재사용 가능한 구성요소를 만들려면 ActionProvider 확장을 사용하는 것이 좋습니다.

예를 들어 ShareActionProvider는 작업 모음의 '공유' 작업을 용이하게 하는 ActionProvider의 확장 프로그램입니다. ACTION_SEND 인텐트를 호출하는 기존 작업 항목을 사용하는 대신 이 작업 제공자를 사용하여 ACTION_SEND 인텐트를 처리하는 애플리케이션의 드롭다운 목록과 함께 작업 뷰를 표시할 수 있습니다. 사용자가 작업에 사용할 애플리케이션을 선택하면 ShareActionProvider은 이 선택을 기억하여 해당 앱과의 공유에 더 빠르게 액세스할 수 있도록 작업 뷰에 이 선택 항목을 제공합니다.

작업 항목의 작업 제공자를 선언하려면 활동 옵션 메뉴의 <item> 요소에 android:actionProviderClass 속성을 포함하고 작업 제공자의 클래스 이름을 값으로 지정합니다. 예:

<item android:id="@+id/menu_share"
      android:title="Share"
      android:showAsAction="ifRoom"
      android:actionProviderClass="android.widget.ShareActionProvider" />

활동의 onCreateOptionsMenu() 콜백 메서드에서 메뉴 항목에서 작업 제공자의 인스턴스를 검색하고 인텐트를 설정합니다.

Kotlin

override fun onCreateOptionsMenu(menu: Menu): Boolean {
    menuInflater.inflate(R.menu.options, menu)
    val shareActionProvider = menu.findItem(R.id.menu_share)?.actionProvider as? ShareActionProvider
    // Set the share intent of the share action provider.
    shareActionProvider?.setShareIntent(createShareIntent())
    ...
    return super.onCreateOptionsMenu(menu)
}

Java

public boolean onCreateOptionsMenu(Menu menu) {
    getMenuInflater().inflate(R.menu.options, menu);
    ShareActionProvider shareActionProvider =
          (ShareActionProvider) menu.findItem(R.id.menu_share).getActionProvider();
    // Set the share intent of the share action provider.
    shareActionProvider.setShareIntent(createShareIntent());
    ...
    return super.onCreateOptionsMenu(menu);
}

ShareActionProvider 사용 예는 ApiDemos의 ActionBarShareActionProviderActivity를 참고하세요.

접을 수 있는 작업 뷰

작업 뷰를 제공하는 작업 항목이 이제 작업 뷰 상태와 기존 작업 항목 상태 간에 전환할 수 있습니다. 이전에는 SearchView만 작업 뷰로 사용할 때 축소를 지원했지만 이제 모든 작업 항목에 작업 뷰를 추가하고 펼쳐진 상태 (작업 뷰 표시됨)와 축소 상태 (작업 항목 표시됨) 간에 전환할 수 있습니다.

작업 뷰가 포함된 작업 항목을 접을 수 있다고 선언하려면 메뉴의 XML 파일에서 <item> 요소의 android:showAsAction 속성에 “collapseActionView" 플래그를 포함합니다.

작업 뷰가 펼쳐짐과 접힘 간에 전환될 때 콜백을 수신하려면 setOnActionExpandListener()를 호출하여 각 MenuItemMenuItem.OnActionExpandListener의 인스턴스를 등록하세요. 일반적으로 onCreateOptionsMenu() 콜백 중에 이 작업을 실행해야 합니다.

접을 수 있는 작업 뷰를 제어하려면 각 MenuItem에서 collapseActionView()expandActionView()를 호출하면 됩니다.

맞춤 작업 뷰를 만들 때 뷰를 펼치고 접을 때 콜백을 수신하도록 새로운 CollapsibleActionView 인터페이스를 구현할 수도 있습니다.

작업 모음의 기타 API

  • setHomeButtonEnabled()를 사용하면 아이콘/로고가 홈으로 이동하는 버튼으로 동작하거나 '위로' (버튼처럼 작동하도록 하려면 'true'를 전달) 지정할 수 있습니다.
  • setIcon()setLogo()를 사용하면 런타임에 작업 모음 아이콘이나 로고를 정의할 수 있습니다.
  • Fragment.setMenuVisibility()를 사용하면 프래그먼트에서 선언한 옵션 메뉴 항목의 공개 상태를 사용 설정하거나 중지할 수 있습니다. 이는 프래그먼트가 활동에 추가되었지만 표시되지 않는 경우에 유용하므로 메뉴 항목을 숨겨야 합니다.
  • FragmentManager.invalidateOptionsMenu()를 사용하면 Activity에서 상응하는 메서드를 사용할 수 없는 프래그먼트 수명 주기의 다양한 상태에서 활동 옵션 메뉴를 무효화할 수 있습니다.

사용자 인터페이스 및 뷰

Android 4.0에는 다양한 새로운 뷰와 기타 UI 구성요소가 도입되었습니다.

GridLayout

GridLayout는 직사각형 그리드에 하위 뷰를 배치하는 새로운 뷰 그룹입니다. TableLayout와 달리 GridLayout는 평면 계층 구조를 사용하며 구조를 제공하기 위해 테이블 행과 같은 중간 뷰를 사용하지 않습니다. 대신 하위 요소는 자신이 차지해야 하는 행과 열을 지정하며(셀은 여러 행 또는 열에 걸쳐 있을 수 있음) 기본적으로 그리드의 행과 열에 순차적으로 배치됩니다. GridLayout 방향은 순차 하위 요소를 기본적으로 가로 또는 세로로 배치할지 결정합니다. 하위 요소 사이의 간격은 새 Space 뷰의 인스턴스를 사용하거나 하위 요소에 관련 여백 매개변수를 설정하여 지정할 수 있습니다.

GridLayout를 사용하는 샘플은 ApiDemos를 참고하세요.

TextureView

TextureView는 동영상이나 OpenGL 장면과 같은 콘텐츠 스트림을 표시할 수 있는 새로운 뷰입니다. SurfaceView와 유사하지만 TextureView는 별도의 창을 만드는 대신 일반 뷰처럼 동작하므로 다른 View 객체처럼 취급할 수 있다는 점에서 고유합니다. 예를 들어 변환을 적용하거나 ViewPropertyAnimator을 사용하여 애니메이션을 적용하거나 setAlpha()로 불투명도를 조정할 수 있습니다.

TextureView는 하드웨어 가속 창에서만 작동합니다.

자세한 내용은 TextureView 문서를 참조하세요.

위젯 전환

Switch 위젯은 사용자가 한쪽 또는 다른 쪽으로 드래그하거나 간단히 탭하여 두 상태 간에 옵션을 전환할 수 있는 2가지 상태의 전환 버튼입니다.

켜기 및 끄기 설정에서 android:textOnandroid:textOff 속성을 사용하여 스위치에 표시할 텍스트를 지정할 수 있습니다. android:text 속성을 사용하면 스위치 옆에 라벨을 배치할 수 있습니다.

스위치를 사용하는 샘플은 switches.xml 레이아웃 파일 및 각 스위치 활동을 참고하세요.

Android 3.0에는 개발자가 지정하는 앵커 포인트 (일반적으로 선택한 항목의 지점)에 팝업되는 짧은 컨텍스트 메뉴를 만들기 위한 PopupMenu가 도입되었습니다. Android 4.0은 PopupMenu를 다음과 같은 유용한 기능으로 확장합니다.

  • 이제 inflate()를 사용하여 XML 메뉴 리소스에서 팝업 메뉴의 콘텐츠를 쉽게 확장하여 메뉴 리소스 ID에 전달할 수 있습니다.
  • 이제 메뉴를 닫을 때 콜백을 수신하는 PopupMenu.OnDismissListener를 만들 수도 있습니다.

환경설정

새로운 TwoStatePreference 추상 클래스는 2가지 상태 선택 옵션을 제공하는 환경설정의 기반이 됩니다. 새 SwitchPreference는 사용자가 추가 환경설정 화면이나 대화상자를 열지 않고도 설정을 사용 또는 사용 중지할 수 있도록 환경설정 뷰에서 Switch 위젯을 제공하는 TwoStatePreference의 확장 프로그램입니다. 예를 들어 설정 애플리케이션은 Wi-Fi 및 블루투스 설정에 SwitchPreference를 사용합니다.

시스템 테마

Android 4.0을 타겟팅하는 모든 애플리케이션의 기본 테마 (targetSdkVersion 또는 minSdkVersion“14" 이상으로 설정)가 이제 '기기 기본' 테마인 Theme.DeviceDefault입니다. 이는 어두운 홀로 테마일 수도 있고 특정 기기에서 정의한 다른 어두운 테마일 수도 있습니다.

Theme.Holo 테마 계열은 동일한 버전의 Android를 실행할 때 기기 간에 변경되지 않습니다. Theme.Holo 테마를 활동에 명시적으로 적용하면 이러한 테마는 동일한 플랫폼 버전 내의 다른 기기에서 문자를 변경하지 않으므로 안심할 수 있습니다.

앱이 전반적인 기기 테마와 어우러지도록 하려면 (예: 여러 OEM이 시스템에 서로 다른 기본 테마를 제공하는 경우) Theme.DeviceDefault 계열의 테마를 명시적으로 적용해야 합니다.

옵션 메뉴 버튼

Android 4.0부터는 핸드셋에 더 이상 메뉴 하드웨어 버튼이 필요하지 않습니다. 그러나 기존 애플리케이션에서 옵션 메뉴를 제공하고 메뉴 버튼이 있을 것으로 예상하는 경우에는 이 작업을 걱정하지 않아도 됩니다. 기존 앱이 계속 정상적으로 작동하도록 하기 위해 시스템에서는 이전 버전의 Android용으로 설계된 앱에 화면 메뉴 버튼을 제공합니다.

최상의 사용자 환경을 제공하려면 신규 앱 및 업데이트된 앱에서 ActionBar를 사용하여 메뉴 항목에 대한 액세스 권한을 제공하고 targetSdkVersion"14"로 설정하여 최신 프레임워크 기본 동작을 활용해야 합니다.

시스템 UI 공개 상태 컨트롤

Android 초기부터 시스템은 핸드셋 기기 상단에 위치하여 이동통신사 신호, 시간, 알림 등의 정보를 전달하는 상태 표시줄이라는 UI 구성요소를 관리해 왔습니다. Android 3.0에는 태블릿 기기용 시스템 표시줄이 추가되었습니다. 이 시스템 표시줄은 화면 하단에 위치하여 시스템 탐색 컨트롤 (홈, 뒤로 등)을 제공하고 상태 표시줄에서 기존에 제공되던 요소의 인터페이스도 제공합니다. Android 4.0에서 시스템은 탐색 메뉴라는 새로운 유형의 시스템 UI를 제공합니다. 탐색 메뉴는 핸드셋용으로 설계된 시스템 표시줄의 재조정된 버전이라고 생각할 수 있습니다. 탐색 메뉴는 시스템 탐색을 위한 하드웨어가 없는 기기에 탐색 컨트롤을 제공하지만 시스템 표시줄의 알림 UI와 설정 컨트롤은 제외됩니다. 따라서 탐색 메뉴를 제공하는 기기의 상단에도 상태 표시줄이 있습니다.

지금까지 FLAG_FULLSCREEN 플래그를 사용하여 핸드셋에서 상태 표시줄을 숨길 수 있습니다. Android 4.0에서는 시스템 표시줄의 공개 상태를 제어하는 API가 시스템 표시줄과 탐색 메뉴의 동작을 더 잘 반영하도록 업데이트되었습니다.

  • SYSTEM_UI_FLAG_LOW_PROFILE 플래그는 STATUS_BAR_HIDDEN 플래그를 대체합니다. 이 플래그를 설정하면 시스템 표시줄 또는 탐색 메뉴에 '로우 프로필' 모드가 사용 설정됩니다. 탐색 버튼이 어두워지고 시스템 표시줄의 다른 요소도 숨겨집니다. 이 기능을 사용 설정하면 시스템 탐색 버튼을 방해하지 않으면서 몰입도 높은 게임을 만드는 데 유용합니다.
  • SYSTEM_UI_FLAG_VISIBLE 플래그는 STATUS_BAR_VISIBLE 플래그를 대체하여 시스템 표시줄 또는 탐색 메뉴가 표시되도록 요청합니다.
  • SYSTEM_UI_FLAG_HIDE_NAVIGATION는 탐색 메뉴를 완전히 숨기도록 요청하는 새 플래그입니다. 이는 일부 핸드셋에서 사용하는 탐색 메뉴에서만 작동합니다 (태블릿의 시스템 표시줄을 숨기지는 않습니다). 시스템에서 사용자 입력을 수신하는 즉시 탐색 메뉴가 뷰로 돌아갑니다. 따라서 이 모드는 주로 동영상 재생 또는 전체 화면이 필요하지만 사용자 입력이 필요하지 않은 다른 경우에 유용합니다.

활동의 뷰에서 setSystemUiVisibility()를 호출하여 시스템 메뉴와 탐색 메뉴에 이러한 각 플래그를 설정할 수 있습니다. 창 관리자는 창에 입력 포커스가 있는 한 모든 뷰의 모든 플래그를 조합 (또는 함께)하여 시스템 UI에 적용합니다. 창에서 입력 포커스가 손실 (사용자가 앱에서 벗어나거나 대화상자가 표시됨)하면 플래그가 더 이상 적용되지 않습니다. 마찬가지로 뷰 계층 구조에서 이러한 뷰를 삭제하면 플래그가 더 이상 적용되지 않습니다.

활동의 다른 이벤트를 시스템 UI의 공개 상태 변경사항과 동기화하려면 (예: 시스템 UI가 숨겨질 때 작업 모음 또는 다른 UI 컨트롤 숨김) View.OnSystemUiVisibilityChangeListener를 등록하여 시스템 메뉴 또는 탐색 메뉴의 공개 상태가 변경될 때 알림을 받아야 합니다.

다양한 시스템 UI 옵션의 데모는 OverscanActivity 클래스를 참고하세요.

입력 프레임워크

Android 4.0은 커서 마우스 오버 이벤트와 새로운 스타일러스 및 마우스 버튼 이벤트에 대한 지원을 추가합니다.

마우스 오버 이벤트

이제 View 클래스가 포인터 기기 (예: 마우스 또는 화면 커서를 구동하는 기타 기기)를 사용하여 더 풍부한 상호작용을 할 수 있도록 '마우스 오버' 이벤트를 지원합니다.

뷰에서 마우스 오버 이벤트를 수신하려면 View.OnHoverListener를 구현하고 setOnHoverListener()를 사용하여 등록합니다. 뷰에서 마우스 오버 이벤트가 발생하면 리스너는 onHover() 호출을 수신하여 이벤트를 수신한 View와 발생한 마우스 오버 이벤트의 유형을 설명하는 MotionEvent를 제공합니다. 마우스 오버 이벤트는 다음 중 하나일 수 있습니다.

View.OnHoverListener는 마우스 오버 이벤트를 처리하는 경우 onHover()에서 true를 반환해야 합니다. 리스너가 false를 반환하면 마우스 오버 이벤트가 평상시처럼 상위 뷰에 전달됩니다.

애플리케이션에서 현재 상태에 따라 모양이 변경되는 버튼이나 다른 위젯을 사용하는 경우 이제 상태 목록 드로어블에서 android:state_hovered 속성을 사용하여 커서를 뷰 위로 가져가면 다른 배경 드로어블을 제공할 수 있습니다.

새로운 마우스 오버 이벤트의 데모는 ApiDemos의 Hover 클래스를 참고하세요.

스타일러스 및 마우스 버튼 이벤트

Android는 이제 디지타이저 태블릿 주변기기 또는 스타일러스 지원 터치스크린과 같은 스타일러스 입력 장치에서 입력을 수신하는 API를 제공합니다.

스타일러스 입력은 터치 또는 마우스 입력과 유사한 방식으로 작동합니다. 스타일러스가 디지타이저에 닿으면 애플리케이션은 손가락으로 디스플레이를 터치할 때와 마찬가지로 터치 이벤트를 수신합니다. 스타일러스가 디지타이저 위로 마우스를 가져가면 애플리케이션은 버튼을 누르지 않았을 때 디스플레이에서 마우스 포인터가 이동할 때와 마찬가지로 마우스 오버 이벤트를 수신합니다.

애플리케이션은 getToolType()를 사용하여 MotionEvent의 각 포인터와 연결된 '도구 유형'을 쿼리하여 손가락, 마우스, 스타일러스, 지우개 입력을 구분할 수 있습니다. 현재 정의된 도구 유형은 TOOL_TYPE_UNKNOWN, TOOL_TYPE_FINGER, TOOL_TYPE_MOUSE, TOOL_TYPE_STYLUSTOOL_TYPE_ERASER입니다. 도구 유형을 쿼리하면 애플리케이션에서 손가락 또는 마우스 입력과 다른 방식으로 스타일러스 입력을 처리하도록 선택할 수 있습니다.

또한 애플리케이션은 getButtonState()MotionEvent의 '버튼 상태'를 쿼리하여 어떤 마우스나 스타일러스 버튼을 눌렀는지 쿼리할 수 있습니다. 현재 정의된 버튼 상태는 BUTTON_PRIMARY, BUTTON_SECONDARY, BUTTON_TERTIARY, BUTTON_BACK, BUTTON_FORWARD입니다. 편의를 위해 마우스 뒤로 및 앞으로 버튼은 KEYCODE_BACKKEYCODE_FORWARD 키에 자동으로 매핑됩니다. 애플리케이션은 이러한 키를 처리하여 뒤로 및 앞으로 탐색을 기반으로 하는 마우스 버튼을 지원할 수 있습니다.

일부 스타일러스 입력 장치는 접촉의 위치와 압력을 정확하게 측정하는 것 외에도 스타일러스 팁과 디지타이저, 스타일러스 기울기 각도, 스타일러스 방향 각도 사이의 거리도 보고합니다. 애플리케이션은 축 코드 AXIS_DISTANCE, AXIS_TILT, AXIS_ORIENTATION와 함께 getAxisValue()를 사용하여 이 정보를 쿼리할 수 있습니다.

도구 유형, 버튼 상태, 새 축 코드의 데모는 ApiDemos의 TouchPaint 클래스를 참조하세요.

속성

새로운 Property 클래스는 호출자가 타겟 객체에서 값을 일반적으로 설정/가져올 수 있도록 모든 객체에 속성을 지정하는 빠르고 효율적이며 쉬운 방법을 제공합니다. 또한 필드/메서드 참조를 전달하는 기능을 허용하며 코드가 필드/메서드의 세부정보를 모르더라도 속성 값을 설정하거나 가져올 수 있습니다.

예를 들어 foo 객체의 bar 필드 값을 설정하려면 다음을 수행해야 합니다.

Kotlin

foo.bar = value

Java

foo.bar = value;

기본 비공개 필드 bar의 setter를 호출하려면 이전에는 다음을 실행했습니다.

Kotlin

foo.setBar(value)

Java

foo.setBar(value);

그러나 foo 인스턴스를 전달하고 다른 코드에서 bar 값을 설정하도록 하려는 경우 Android 4.0 이전에는 그렇게 할 수 있는 방법이 없습니다.

Property 클래스를 사용하면 다음과 같이 Foo 클래스의 인스턴스 foo에 필드를 설정할 수 있도록 Foo 클래스에 Property 객체 BAR를 선언할 수 있습니다.

Kotlin

BAR.set(foo, value)

Java

BAR.set(foo, value);

이제 View 클래스에서 Property 클래스를 활용하여 Android 3.0에 추가된 변환 속성 (ROTATION, ROTATION_X, TRANSLATION_X 등)과 같은 다양한 필드를 설정할 수 있습니다.

ObjectAnimator 클래스도 Property 클래스를 사용하므로 PropertyObjectAnimator을 만들 수 있습니다. 이 방법은 문자열 기반 접근 방식보다 빠르고 효율적이며 유형 안전성이 높습니다.

하드웨어 가속

Android 4.0부터는 애플리케이션에서 targetSdkVersion 또는 minSdkVersion“14" 이상으로 설정한 경우 모든 창의 하드웨어 가속이 기본적으로 사용 설정됩니다. 하드웨어 가속을 사용하면 일반적으로 애니메이션이 더 매끄럽고 스크롤이 더 매끄러워지고 전반적으로 성능과 사용자 상호작용에 대한 응답이 개선됩니다.

필요한 경우 개별 <activity> 요소 또는 <application> 요소의 hardwareAccelerated 속성을 사용하여 하드웨어 가속을 수동으로 사용 중지할 수 있습니다. 또는 setLayerType(LAYER_TYPE_SOFTWARE)를 호출하여 개별 뷰의 하드웨어 가속을 사용 중지할 수 있습니다.

지원되지 않는 그리기 작업 목록을 포함하여 하드웨어 가속에 관한 자세한 내용은 하드웨어 가속 문서를 참고하세요.

JNI 변경사항

이전 버전의 Android에서는 JNI 로컬 참조가 간접 핸들이 아니었습니다. Android는 직접 포인터를 사용했습니다. 가비지 컬렉터가 객체를 이동하지 않는 한 문제가 되지 않았지만 버그가 있는 코드를 작성할 수 있으므로 작동하는 것처럼 보였습니다. Android 4.0에서는 이제 시스템에서 이러한 버그를 감지하기 위해 간접 참조를 사용합니다.

JNI 로컬 참조에 관한 자세한 내용은 JNI 도움말의 '로컬 및 전역 참조'에 설명되어 있습니다. Android 4.0에서는 이러한 오류를 감지하도록 CheckJNI가 개선되었습니다. Android 개발자 블로그에서 JNI 참조의 일반적인 오류와 해결 방법에 관한 향후 게시물을 확인하세요.

JNI 구현의 이러한 변경사항은 targetSdkVersion 또는 minSdkVersion“14" 이상으로 설정하여 Android 4.0을 타겟팅하는 앱에만 영향을 미칩니다. 이러한 속성을 더 낮은 값으로 설정하면 JNI 로컬 참조가 이전 버전과 동일하게 작동합니다.

WebKit

  • WebKit이 버전 534.30으로 업데이트되었습니다.
  • WebView 및 기본 브라우저에서 인도어 글꼴 (데바나가리 문자, 벵골어, 타밀어, 글리프 결합에 필요한 복잡한 문자 지원 포함) 지원
  • WebView 및 내장 브라우저에서 에티오피아어, 조지아어, 아르메니아어 글꼴 지원
  • WebDriver가 지원되므로 WebView를 사용하는 앱을 더 쉽게 테스트할 수 있습니다.

Android 브라우저

브라우저 애플리케이션은 웹 애플리케이션을 지원하기 위해 다음 기능을 추가합니다.

권한

새로운 권한은 다음과 같습니다.

기기 기능

새로운 기기 기능은 다음과 같습니다.

  • FEATURE_WIFI_DIRECT: 애플리케이션이 P2P 통신에 Wi-Fi를 사용한다고 선언합니다.

Android 4.0 (API 수준 14)의 모든 API 변경사항에 관한 자세한 내용은 API 차이점 보고서를 참고하세요.

이전 API

위의 모든 사항 외에도, Android 4.0은 이전 릴리스의 모든 API를 자연스럽게 지원합니다. Android 3.x 플랫폼은 대형 화면 기기에서만 사용할 수 있으므로 주로 핸드셋용으로 개발하고 있다면 최근 출시에서 Android에 추가된 모든 API를 모를 수도 있습니다.

다음은 핸드셋에서도 사용할 수 있으며 놓쳤을 수 있는 가장 주목할 만한 API입니다.

Android 3.0
  • Fragment: 활동의 고유한 요소를 자체 UI와 수명 주기를 정의하는 자체 포함 모듈로 분리할 수 있게 해 주는 프레임워크 구성요소입니다. 프래그먼트 개발자 가이드를 참고하세요.
  • ActionBar: 활동 창 상단에 있는 기존 제목 표시줄을 대체합니다. 왼쪽 모서리에 애플리케이션 로고가 포함되며 메뉴 항목에 새로운 인터페이스를 제공합니다. 작업 모음 개발자 가이드를 참고하세요.
  • Loader: 기본 스레드를 차단하지 않고 데이터를 동적으로 로드하기 위해 UI 구성요소와 함께 데이터의 비동기 로드를 용이하게 하는 프레임워크 구성요소입니다. 로더 개발자 가이드를 참고하세요.
  • 시스템 클립보드: 애플리케이션은 단순한 텍스트 외에 시스템 전체 클립보드에 데이터를 복사하여 붙여넣을 수 있습니다. 잘린 데이터는 일반 텍스트, URI 또는 인텐트일 수 있습니다. 복사하여 붙여넣기 개발자 가이드를 참고하세요.
  • 드래그 앤 드롭: 뷰 프레임워크에 빌드된 API 세트로, 드래그 앤 드롭 작업을 용이하게 합니다. 드래그 앤 드롭 개발자 가이드를 참고하세요.
  • 새롭고 유연한 애니메이션 프레임워크를 사용하면 모든 객체 (View, Drawable, Fragment, Object 등)의 임의 속성에 애니메이션을 적용하고 재생 시간, 보간 유형, 반복 등의 애니메이션 측면을 정의할 수 있습니다. 새로운 프레임워크를 통해 Android의 애니메이션이 그 어느 때보다 단순해졌습니다. 속성 애니메이션 개발자 가이드를 참고하세요.
  • RenderScript 그래픽 및 컴퓨팅 엔진: RenderScript는 C (C99 표준)로 작성하는 네이티브 수준에서 고성능 3D 그래픽 렌더링 및 컴퓨팅 API를 제공하여 다양한 CPU 및 GPU에서 이동하면서도 네이티브 환경에서 기대되는 성능 유형을 제공합니다. RenderScript 개발자 가이드를 참고하세요.
  • 하드웨어 가속 2D 그래픽: 이제 매니페스트 요소의 <application> 요소 또는 개별 <activity> 요소에 {android:hardwareAccelerated="true"}를 설정하여 애플리케이션에 OpenGL 렌더기를 사용 설정할 수 있습니다. 이렇게 하면 애니메이션과 스크롤이 더 매끄러워지고 전반적으로 성능과 사용자 상호작용에 대한 응답이 개선됩니다.

    참고: 애플리케이션의 minSdkVersion 또는 targetSdkVersion"14" 이상으로 설정하면 하드웨어 가속이 기본적으로 사용 설정됩니다.

  • 이 외에도 다양한 기능이 있습니다. 자세한 내용은 Android 3.0 플랫폼 노트를 참고하세요.
Android 3.1
  • USB API: 연결된 주변기기를 Android 애플리케이션과 통합하기 위한 강력한 새 API입니다. API는 USB 호스트 및 기기 상호작용 지원을 포함하여 플랫폼에 내장된 USB 스택 및 서비스를 기반으로 합니다. USB 호스트 및 액세서리 개발자 가이드를 참고하세요.
  • MTP/PTP API: 애플리케이션은 연결된 카메라 및 다른 PTP 기기와 직접 상호작용하여 기기가 연결되거나 삭제될 때 알림을 받고 기기의 파일과 저장소를 관리하며 파일과 메타데이터를 서로 전송할 수 있습니다. MTP API는 MTP(미디어 전송 프로토콜) 사양의 PTP (사진 전송 프로토콜) 하위 집합을 구현합니다. android.mtp 문서를 참고하세요.
  • RTP API: Android는 애플리케이션이 주문형 또는 대화형 데이터 스트리밍을 관리하는 데 사용할 수 있는 내장 RTP (실시간 전송 프로토콜) 스택에 API를 노출합니다. 특히 VOIP, 눌러서 말하기, 회의 및 오디오 스트리밍을 제공하는 앱은 API를 사용하여 세션을 시작하고 사용 가능한 모든 네트워크를 통해 데이터 스트림을 송수신할 수 있습니다. android.net.rtp 문서를 참고하세요.
  • 조이스틱 및 기타 일반 모션 입력을 지원합니다.
  • 더 많은 새로운 API는 Android 3.1 플랫폼 노트를 참고하세요.
Android 3.2
  • 새로운 화면은 다양한 화면 크기에서 애플리케이션이 표시되는 방식을 더 세밀하게 제어할 수 있는 API를 지원합니다. 이 API는 일반화된 화면 크기 (예: 대형 또는 특대형)가 아닌 밀도 독립형 픽셀 단위 (예: 너비 600dp 또는 너비 720dp)로 측정된 크기별로 특정 화면 크기 범위를 정확하게 타겟팅하는 기능을 통해 기존 화면 지원 모델을 확장합니다. 예를 들어 이는 일반적으로 5인치 기기와 7인치 기기를 구별하는 데 중요합니다. 두 기기 모두 일반적으로 '대형' 화면으로 버케팅됩니다. 화면 크기 관리를 위한 새로운 도구 블로그 게시물을 참고하세요.
  • <uses-feature>의 새로운 상수로 가로 모드 또는 세로 모드 화면 방향 요구사항을 선언합니다.
  • 이제 화면 방향이 변경되는 동안 기기 '화면 크기' 구성이 변경됩니다. 앱이 API 수준 13 이상을 타겟팅하는 경우 "orientation" 구성 변경도 처리하려면 "screenSize" 구성 변경을 처리해야 합니다. 자세한 내용은 android:configChanges를 참고하세요.
  • 다른 새로운 API는 Android 3.2 플랫폼 노트를 참고하세요.

API 수준

Android 4.0 API에는 시스템 자체에 저장되는 정수 식별자(14)가 할당됩니다. 'API 수준'이라고 하는 이 식별자를 사용하면 시스템에서 애플리케이션을 설치하기 전에 애플리케이션이 시스템과 호환되는지 여부를 올바르게 판단할 수 있습니다.

Android 4.0에 도입된 API를 애플리케이션에서 사용하려면 API 수준 14 이상을 지원하는 Android 플랫폼을 대상으로 애플리케이션을 컴파일해야 합니다. 필요에 따라 android:minSdkVersion="14" 속성을 <uses-sdk> 요소에 추가해야 할 수도 있습니다.

자세한 내용은 API 수준이란 무엇인가요?를 읽어보세요.