Android 4.0 API

API 수준: 14

Android 4.0 (ICE_CREAM_SANDWICH)은 사용자와 앱 개발자를 위한 다양한 새 기능이 추가된 주요 플랫폼 버전입니다. 아래에서 설명하는 모든 새로운 기능과 API 외에도 Android 4.0은 중요한 플랫폼 출시입니다. Android 3.x의 광범위한 API 및 홀로그램 테마 모음을 작은 화면에 제공하기 때문입니다. 앱 개발자는 이제 동일한 버전의 Android(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는 기기 소유자의 개인 프로필 및 기기에 설치된 소셜 네트워크에 개별 연락처를 초대할 수 있는 기능 등 새로운 소셜 지향 기능을 지원하도록 확장되었습니다.

사용자 프로필

이제 Android에는 ContactsContract.Profile 테이블에 정의된 대로 기기 소유자를 나타내는 개인 프로필이 포함됩니다. 사용자 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 캘린더 이벤트는 Google 캘린더 동기화 어댑터를 통해 캘린더 제공자와 동기화되므로 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 인텐트를 사용하면 캘린더 앱에서 새 이벤트를 만드는 활동을 시작할 수 있습니다. 인텐트를 사용할 때는 권한이 필요하지 않으며 다음 추가 항목을 사용하여 이벤트 세부정보를 지정할 수 있습니다.

음성사서함 제공업체

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

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

VoicemailContract 클래스는 음성사서함 제공자의 콘텐츠 제공자를 정의합니다. 서브클래스 VoicemailContract.Voicemails와 VoicemailContract.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를 사용하여 EffectFactory 인스턴스를 반환하는 EffectContext.getFactory()를 호출합니다.
  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_PREVIOUS 및 FLAG_KEY_MEDIA_NEXT와 같은 FLAG_KEY_MEDIA_* 플래그 집합을 전달해야 합니다.

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

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

샘플 구현은 랜덤 음악 플레이어를 참조하세요. 이 플레이어는 Android 4.0 기기에서 원격 제어 클라이언트를 사용 설정하는 동시에 Android 2.1까지 기기를 계속 지원하는 호환성 로직을 제공합니다.

미디어 플레이어

  • 이제 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_PICTURE를 setFocusMode()에 전달합니다. 사진을 캡처할 준비가 되면 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 푸시 메시지를 전송합니다. 시스템은 ACTION_NDEF_DISCOVERED 작업으로 인텐트를 호출하여 NdefMessage의 첫 번째 NdefRecord에 따라 설정된 URL 또는 MIME 유형으로 활동을 시작합니다. 응답하려는 활동의 경우 앱에서 관심을 갖는 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를 사용하려면 앱에서 다음 사용자 권한을 요청해야 합니다.

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

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

블루투스 의료 기기

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

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

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

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

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

접근성

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

터치하여 탐색 모드

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

뷰 접근성

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

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

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

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

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

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

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

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

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

접근성 서비스

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

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

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

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

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

애플리케이션이 자체적으로 시스템에 접근성 서비스로 게시하려면 AccessibilityServiceInfo에 상응하는 XML 구성 파일을 선언해야 합니다. 접근성 서비스 만들기에 관한 자세한 내용은 AccessibilityService 및 SERVICE_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 서비스를 사용하려면 사용자가 시스템 설정에서 수동으로 이를 사용 설정해야 합니다.

기기 정책

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

인증서 관리

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

기기 센서

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

기기에 TYPE_AMBIENT_TEMPERATURE 및 TYPE_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)도 호출합니다. 기본 작업 모음이 남아 있는 것은 사라지며, 상단의 탐색 탭과 화면 하단의 작업 항목만 남습니다.

작업 모음 스타일

작업 모음에 맞춤 스타일을 적용하려면 새로운 스타일 속성 backgroundStacked와 backgroundSplit를 사용하여 각각 누적 막대와 분할 막대에 배경 드로어블 또는 색상을 적용하면 됩니다. 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()를 호출하여 MenuItem.OnActionExpandListener 인스턴스를 각각의 MenuItem에 등록합니다. 일반적으로 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 위젯은 사용자가 한쪽 또는 다른 쪽으로 드래그 (또는 간단히 탭)하여 두 상태 간에 옵션을 전환할 수 있는 두 가지 상태 전환 버튼입니다.

사용/사용 중지 설정에서 android:textOn 및 android:textOff 속성을 사용하여 스위치에 표시할 텍스트를 지정할 수 있습니다. android:text 속성을 사용하면 스위치와 함께 라벨을 배치할 수도 있습니다.

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

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

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

환경설정

새로운 TwoStatePreference 추상 클래스는 두 상태 선택 옵션을 제공하는 환경설정의 기반이 됩니다. 새 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()를 호출하여 시스템 메뉴 및 탐색 메뉴에 각 플래그를 설정할 수 있습니다. 창에 입력 포커스가 있는 한 창 관리자는 창에 있는 모든 뷰의 모든 플래그를 결합 (OR 함께)하여 시스템 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_STYLUS 및 TOOL_TYPE_ERASER입니다. 애플리케이션은 도구 유형을 쿼리하여 손가락 또는 마우스 입력과는 다른 방식으로 스타일러스 입력을 처리하도록 선택할 수 있습니다.

또한 애플리케이션에서 getButtonState()를 사용하여 MotionEvent의 '버튼 상태'를 쿼리하여 눌린 마우스 또는 스타일러스 버튼을 쿼리할 수 있습니다. 현재 정의된 버튼 상태는 BUTTON_PRIMARY, BUTTON_SECONDARY, BUTTON_TERTIARY, BUTTON_BACK, BUTTON_FORWARD입니다. 편의를 위해 마우스 뒤로 및 앞으로 버튼은 자동으로 KEYCODE_BACK 및 KEYCODE_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 클래스의 Property 객체 BAR를 선언하여 Foo 클래스의 foo 인스턴스에 다음과 같이 필드를 설정할 수 있습니다.

Kotlin

BAR.set(foo, value)

Java

BAR.set(foo, value);

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

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

하드웨어 가속

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가 개선되었습니다. JNI 참조의 일반적인 오류와 해결 방법을 알아보려면 Android 개발자 블로그를 시청하세요.

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 중 현재 핸드셋에서도 사용할 수 있는 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 수준이란 무엇인가요?를 참고하세요.