Android 4.3 API

API 수준: 18

Android 4.3 (JELLY_BEAN_MR2) 는 사용자와 앱을 위한 새로운 기능을 제공하는 Jelly Bean 출시의 업데이트입니다. 있습니다. 이 문서에서는 가장 주목할 만한 새로운 API를 소개합니다.

앱 개발자는 Android 4.3 시스템 이미지를 다운로드해야 합니다. 및 SDK 플랫폼은 SDK Manager의 가능한 한 빨리. 앱을 테스트할 Android 4.3을 실행하는 기기가 없는 경우, Android 4.3 시스템 이미지를 사용하여 Android 에뮬레이터에서 앱을 테스트하세요. 그런 다음 최신 API를 사용할 수 있도록 Android 4.3 플랫폼을 대상으로 앱을 빌드하세요.

대상 API 레벨 업데이트

Android 4.3을 실행하는 기기에 대해 앱을 더 잘 최적화하려면, targetSdkVersion를 다음과 같이 설정해야 합니다. "18"를 Android 4.3 시스템 이미지에 설치합니다. 테스트한 후 이 변경사항이 적용된 업데이트를 게시해야 합니다.

minSdkVersion에서 지원하지 않는 API를 실행하기 전에 시스템 API 수준을 확인하는 코드에 조건을 추가하여 이전 버전을 지원하면서도 Android 4.3에서 API를 사용할 수 있습니다. 이전 버전과의 호환성을 유지하는 방법에 관한 자세한 내용은 다양한 플랫폼 버전 지원을 참고하세요.

Android 지원 라이브러리에서도 다양한 API를 사용하여 이전 버전의 플랫폼에 새 기능을 구현할 수 있습니다.

API 수준의 작동 방식에 대한 자세한 내용은 API란 무엇인가요? 레벨?

중요한 동작 변경 사항

이전에 Android용 앱을 게시한 적이 있는 경우 영향을 받는다고 가정해 보겠습니다.

앱이 암시적 인텐트를 사용하는 경우...

제한된 프로필 환경에서 앱이 오작동할 수 있습니다.

제한된 프로필 환경의 사용자는 모든 표준 Android 앱을 사용할 수 있습니다. 예를 들어 제한된 프로필에는 웹브라우저와 카메라 앱이 사용 중지되어 있을 수 있습니다. 따라서 앱에서 어떤 앱이 이는 startActivity()을 호출하지 않고 앱이 Intent를 처리할 수 있는지 확인 제한된 프로필에서 앱이 다운될 수 있습니다.

암시적 인텐트를 사용할 때는 resolveActivity() 또는 queryIntentActivities()를 호출하여 앱에서 인텐트를 처리할 수 있는지 항상 확인해야 합니다. 예를 들면 다음과 같습니다.

val intent = Intent(Intent.ACTION_SEND)
...
if (intent.resolveActivity(packageManager) != null) {
    startActivity(intent)
} else {
    Toast.makeText(context, R.string.app_not_available, Toast.LENGTH_LONG).show()
}

Intent intent = new Intent(Intent.ACTION_SEND);
...
if (intent.resolveActivity(getPackageManager()) != null) {
    startActivity(intent);
} else {
    Toast.makeText(context, R.string.app_not_available, Toast.LENGTH_LONG).show();
}

앱이 계정에 종속되는 경우

제한된 프로필 환경에서 앱이 오작동할 수 있습니다.

제한된 프로필 환경의 사용자는 기본적으로 사용자 계정에 액세스할 수 없습니다. 앱이 Account에 종속된 경우 제한된 프로필에서 사용하면 앱이 비정상 종료되거나 예기치 않게 동작할 수 있습니다.

사용자의 개인 정보가 제한되거나 제한되기 때문에 앱이 민감한 계정 정보에 의존하는 경우 매니페스트의 <application>에서 android:requiredAccountType 속성을 지정합니다. 요소가 포함됩니다.

제한된 프로필이 자체 계정을 만들 수 없더라도 앱을 계속 사용하도록 허용하려면 계정이 필요한 앱 기능을 사용 중지하거나 제한된 프로필이 기본 사용자가 만든 계정에 액세스하도록 허용하면 됩니다. 자세한 내용은 아래의 제한된 프로필에서 계정 지원 섹션을 참고하세요.

앱이 VideoView를 사용하는 경우...

Android 4.3에서는 동영상이 더 작게 표시될 수 있습니다.

이전 버전의 Android에서는 VideoView 위젯이 layout_height 및 layout_width의 "wrap_content" 값을 "match_parent"과 동일하게 잘못 계산했습니다. 따라서 높이 또는 너비에 "wrap_content"를 사용하는 동안 이전에 원하는 동영상 레이아웃을 제공했을 수 있습니다. 이렇게 하면 Android 4.3 이상에서 동영상이 훨씬 작아질 수 있습니다. 이 문제를 해결하려면 "wrap_content"를 "match_parent"로 대체하고 Android 4.3 및 이전 버전에서 동영상이 예상대로 표시되는지 확인합니다.

제한된 프로필

이제 Android 태블릿에서 사용자가 기본 사용자를 기반으로 제한된 프로필을 만들 수 있습니다. 사용자가 제한된 프로필을 만들 때 프로필에서 사용할 수 있는 앱과 같은 제한사항을 사용 설정할 수 있습니다. Android 4.3의 새로운 API를 사용하면 개발하는 앱에 세분화된 제한 설정을 빌드할 수도 있습니다. 예를 들어 새로운 API를 사용하면 사용자가 제한된 프로필 환경에서 실행할 때 앱 내에서 사용할 수 있는 콘텐츠 유형을 제어할 수 있습니다.

개발자가 구축한 제한사항을 사용자가 제어할 수 있는 UI는 시스템의 설정 애플리케이션 앱의 제한 설정을 사용자에게 표시하려면 ACTION_GET_RESTRICTION_ENTRIES 인텐트를 수신하는 BroadcastReceiver를 만들어 앱에서 제공하는 제한을 선언해야 합니다. 시스템은 이 인텐트를 호출하여 모든 앱에 사용 가능한 제한 사항을 적용하도록 한 다음 기본 사용자가 각각의 제한된 프로필에 대한 제한을 관리합니다.

다음의 onReceive() 메서드에서 BroadcastReceiver에서는 앱에서 제공하는 각 제한사항에 대해 RestrictionEntry를 만들어야 합니다. 각 RestrictionEntry는 제한사항 제목, 설명, 다음 데이터 유형 중 하나를 정의합니다.

• 참 또는 거짓인 제약의 경우 TYPE_BOOLEAN
• TYPE_CHOICE: 선택할 수 있습니다 (라디오 버튼 선택).
• TYPE_MULTI_SELECT: 상호 배타적이지 않은 여러 선택 항목 (체크박스 선택)이 있는 경우

그런 다음 모든 RestrictionEntry 객체를 ArrayList에 넣고 broadcast receiver의 결과에 다음과 같은 값으로 넣습니다. 추가 항목 EXTRA_RESTRICTIONS_LIST개.

시스템은 설정 앱에서 앱 제한사항의 UI를 만들고 각 RestrictionEntry 객체에 제공한 고유한 키로 각 제한사항을 저장합니다. 사용자가 앱을 열면 getApplicationRestrictions()를 호출하여 현재 제한사항을 쿼리할 수 있습니다. 이렇게 하면 RestrictionEntry 객체로 정의한 각 제한의 키-값 쌍이 포함된 Bundle가 반환됩니다.

불리언, 단일 선택, 멀티 선택 값으로 처리할 수 없는 더 구체적인 제한사항을 제공하려면 사용자가 제한사항을 지정할 수 있는 활동을 만들고 사용자가 제한사항 설정에서 해당 활동을 열 수 있도록 허용하면 됩니다. broadcast receiver에서 결과 Bundle에 EXTRA_RESTRICTIONS_INTENT 추가 항목을 포함합니다. 이 추가 항목은 실행할 Activity 클래스를 나타내는 Intent를 지정해야 합니다(putParcelable() 메서드를 사용하여 인텐트와 함께 EXTRA_RESTRICTIONS_INTENT를 전달). 기본 사용자가 맞춤 제한을 설정하기 위해 활동을 시작하면 활동은 RestrictionEntry 객체 또는 키-값 쌍을 각각 지정했는지에 따라 EXTRA_RESTRICTIONS_LIST 또는 EXTRA_RESTRICTIONS_BUNDLE 키를 사용하여 제한 값이 포함된 결과를 추가로 반환해야 합니다.

제한된 프로필의 계정 지원

기본 사용자에 추가된 모든 계정은 제한된 프로필에서 사용할 수 있지만 기본적으로 AccountManager API에서는 이러한 계정에 액세스할 수 없습니다. 제한된 프로필에서 AccountManager로 계정을 추가하려고 하면 실패 결과가 표시됩니다. 이러한 제한으로 인해 다음과 같은 제한사항이 적용됩니다. 3가지 옵션이 있습니다

<application ...
    android:restrictedAccountType="com.example.account.type" >

val um = context.getSystemService(Context.USER_SERVICE) as UserManager
val restrictions: Bundle = um.userRestrictions
if (restrictions.getBoolean(UserManager.DISALLOW_MODIFY_ACCOUNTS, false)) {
    // cannot add accounts, disable some functionality
}

UserManager um = (UserManager) context.getSystemService(Context.USER_SERVICE);
Bundle restrictions = um.getUserRestrictions();
if (restrictions.getBoolean(UserManager.DISALLOW_MODIFY_ACCOUNTS, false)) {
    // cannot add accounts, disable some functionality
}

<application ...
    android:requiredAccountType="com.example.account.type" >

무선 및 연결

저전력 블루투스 (스마트 지원)

Android는 이제 android.bluetooth의 새 API를 사용하여 저전력 블루투스 (LE)를 지원합니다. 새 API를 사용하면 저전력 블루투스와 통신하는 Android 앱을 빌드할 수 있습니다. 심박수 모니터 및 만보계와 같은 주변기기.

블루투스 LE는 일부 Android 지원 기기에서만 사용할 수 있는 하드웨어 기능이므로 매니페스트 파일에서 "android.hardware.bluetooth_le"의 <uses-feature> 요소를 선언해야 합니다.

<uses-feature android:name="android.hardware.bluetooth_le" android:required="true" />

Android의 기존 블루투스 API에 이미 익숙하다면 블루투스 LE API를 사용할 때 몇 가지 차이점이 있음을 알아두세요. 가장 중요한 점은 이제 일부 상위 수준의 작업에 사용해야 하는 BluetoothManager 클래스가 있다는 것입니다. 예를 들어 BluetoothAdapter 가져오기, 연결된 기기 목록 가져오기, 기기 상태 확인 등이 포함됩니다. 예를 들어 이제 BluetoothAdapter를 가져오는 방법은 다음과 같습니다.

val bluetoothManager = getSystemService(Context.BLUETOOTH_SERVICE) as BluetoothManager
bluetoothAdapter = bluetoothManager.adapter

final BluetoothManager bluetoothManager =
        (BluetoothManager) getSystemService(Context.BLUETOOTH_SERVICE);
bluetoothAdapter = bluetoothManager.getAdapter();

블루투스 LE 주변기기를 검색하려면 BluetoothAdapter에서 startLeScan()을 호출하여 BluetoothAdapter.LeScanCallback 인터페이스의 구현을 전달합니다. 블루투스가 어댑터가 블루투스 LE 주변기기를 감지하면 BluetoothAdapter.LeScanCallback 구현이 블루투스 LE 주변기기를 onLeScan() 메서드를 사용하여 지도 가장자리에 패딩을 추가할 수 있습니다. 이 메서드는 개발자가 대상 객체를 나타내는 BluetoothDevice 객체를 제공합니다. RSSI 값, 기기의 RSSI 값을 포함하는 바이트 배열이 광고 기록

특정 유형의 주변기기만 스캔하려면 대신 startLeScan()를 호출하고 앱에서 지원하는 GATT 서비스를 지정하는 UUID 객체의 배열을 포함하면 됩니다.

참고: 블루투스 LE 기기만 검색할 수 있습니다. 또는 이전 API를 사용하여 기본 블루투스 기기를 검색합니다. LE와 클래식을 모두 스캔할 수는 없습니다. 블루투스 기기를 모두 지원합니다.

그런 다음 블루투스 LE 주변기기에 연결하려면 상응하는 BluetoothDevice 객체에서 connectGatt()를 호출하여 BluetoothGattCallback의 구현을 전달합니다. BluetoothGattCallback 구현은 연결과 관련된 콜백을 수신합니다. 상태를 기기 및 기타 이벤트와 연결합니다. onConnectionStateChange() 중 메서드가 새 상태로 STATE_CONNECTED를 전달하는 경우 기기와의 통신을 시작할 수 있는 콜백입니다.

기기에서 블루투스 기능에 액세스하려면 앱에서 블루투스 사용자 권한 자세한 내용은 저전력 블루투스 API 가이드를 참고하세요.

Wi-Fi 검색 전용 모드

Android는 사용자의 위치를 식별하려고 할 때 Wi-Fi를 사용하여 근처 액세스 포인트를 스캔하여 위치를 확인할 수 있습니다. 하지만 사용자는 배터리를 절약하기 위해 Wi-Fi를 사용 중지한 상태로 두는 경우가 많아 위치 데이터의 정확성이 떨어집니다. 이제 Android에는 기기 Wi-Fi가 액세스 포인트를 스캔하여 액세스 포인트에 연결하지 않고도 위치를 가져올 수 있는 검색 전용 모드가 포함되어 있어 배터리 사용량이 크게 줄어듭니다.

사용자 위치를 가져오고 싶지만 현재 Wi-Fi가 꺼져 있는 경우 사용자가 ACTION_REQUEST_SCAN_ALWAYS_AVAILABLE 작업으로 startActivity()를 호출하여 Wi-Fi 스캔 전용 모드를 사용 설정하도록 하세요.

Wi-Fi 구성

새로운 WifiEnterpriseConfig API를 사용하면 엔터프라이즈 중심 서비스에서 다음 작업을 할 수 있습니다. 관리 기기의 Wi-Fi 구성을 자동화합니다.

수신 전화에 대한 빠른 응답

Android 4.0부터 '빠른 응답'이라는 기능이 사용자가 수신된 메시지에 응답하도록 전화를 받거나 기기를 잠금 해제할 필요 없이 즉시 문자 메시지로 전화를 걸 수 있습니다. 지금까지는 빠른 메시지가 항상 기본 메시지 앱에서 처리되었습니다. 이제 모든 앱에서 Service를 만들어 이러한 메시지를 처리하는 기능을 선언할 수 있습니다. ACTION_RESPOND_VIA_MESSAGE의 인텐트 필터로 구성됩니다.

사용자가 빠른 응답으로 수신 전화에 응답하면 전화 앱은 URI가 있는 ACTION_RESPOND_VIA_MESSAGE 인텐트 수신자 (발신자) 및 EXTRA_TEXT 추가 항목 설명 메시지를 보낼 수 있습니다 서비스가 인텐트를 수신하면 즉시 중지됩니다 (앱이 활동을 표시하면 안 됨).

이 인텐트를 수신하려면 SEND_RESPOND_VIA_MESSAGE 권한을 선언해야 합니다.

멀티미디어

MediaExtractor 및 MediaCodec 개선사항

이제 Android에서 나만의 동적 적응형을 더 쉽게 작성할 수 있습니다 ISO/IEC 23009-1 표준에 따른 HTTP (DASH) 플레이어를 통한 스트리밍 MediaCodec 및 MediaExtractor의 기존 API 사용 이러한 API의 기반 프레임워크는 단편화된 MP4 파일의 파싱을 지원하도록 업데이트되었지만 앱은 여전히 MPD 메타데이터를 파싱하고 개별 스트림을 MediaExtractor에 전달해야 합니다.

암호화된 콘텐츠와 함께 DASH를 사용하려면 getSampleCryptoInfo() 메서드가 각 암호화된 미디어 샘플의 구조를 설명하는 MediaCodec.CryptoInfo 메타데이터를 반환한다는 점에 유의하세요. 또한 DASH 미디어의 PSSH 메타데이터에 액세스할 수 있도록 getPsshInfo() 메서드가 MediaExtractor에 추가되었습니다. 이 메서드는 UUID 객체를 바이트로 매핑하고 암호화 스키마를 지정하는 UUID 및 데이터 관련 바이트 추가할 수 있습니다.

미디어 DRM

새 MediaDrm 클래스는 DRM 문제를 미디어 재생과 분리하여 미디어 콘텐츠에 디지털 권한 관리(DRM)를 위한 모듈식 솔루션을 제공합니다. 대상 이러한 API 분리를 통해 별도의 작업 없이 Widevine으로 암호화된 콘텐츠를 Widevine 미디어 형식을 사용해야 합니다 또한 이 DRM 솔루션은 DASH 일반 암호화를 지원하므로 은 스트리밍 콘텐츠에 다양한 DRM 체계를 사용할 수 있습니다.

MediaDrm를 사용하여 불투명한 키-요청 메시지 및 프로세스를 가져올 수 있습니다. 라이선스 획득 및 프로비저닝을 위한 서버의 키-응답 메시지 앱은 서버와의 네트워크 통신을 처리해야 합니다. MediaDrm 클래스는 메시지를 생성하고 처리하는 기능만 제공합니다.

MediaDrm API는 콘텐츠 인코딩 및 디코딩을 위한 MediaCodec, 암호화된 콘텐츠 처리를 위한 MediaCrypto, 콘텐츠 추출 및 디뮤싱을 위한 MediaExtractor를 비롯하여 Android 4.1(API 수준 16)에 도입된 MediaCodec API와 함께 사용하도록 설계되었습니다.

먼저 MediaExtractor 및 MediaCodec 객체를 구성해야 합니다. 그런 다음 DRM 스키마 식별 기능에 액세스하여 UUID(일반적으로 콘텐츠의 메타데이터에서 가져옴)이며, 이를 사용하여 생성자가 있는 MediaDrm 객체의 인스턴스입니다.

노출 영역에서 동영상 인코딩

Android 4.1(API 수준 16)에서는 미디어 콘텐츠의 하위 수준 인코딩 및 디코딩을 위한 MediaCodec 클래스를 추가했습니다. Android 4.1에서는 동영상을 인코딩할 때 미디어에 ByteBuffer 배열을 제공해야 했지만 이제 Android 4.3에서는 Surface를 인코더의 입력으로 사용할 수 있습니다. 예를 들어 이를 통해 인코더-디코더 아키텍처를 기존 동영상 파일에서 추출하거나 OpenGL ES에서 생성된 프레임을 사용할 수 있습니다.

Surface를 인코더의 입력으로 사용하려면 먼저 MediaCodec의 configure()를 호출합니다. 그런 다음 createInputSurface()를 호출하여 미디어를 스트리밍할 수 있는 Surface를 수신합니다.

예를 들어 지정된 Surface를 eglCreateWindowSurface()에 전달하여 OpenGL 컨텍스트의 창으로 사용할 수 있습니다. 그런 다음 노출 영역을 렌더링하는 동안 eglSwapBuffers()를 호출하여 프레임을 MediaCodec에 전달합니다.

인코딩을 시작하려면 MediaCodec에서 start()를 호출합니다. 완료되면 signalEndOfInputStream()를 호출합니다. 인코딩을 종료하고 release() Surface입니다.

미디어 다중화

새로운 MediaMuxer 클래스는 하나의 오디오 스트림 간 멀티플렉싱을 사용 설정합니다. 동영상 스트림이 1개 있습니다. 이 API는 미디어 디멀티플렉싱(디뮤싱)을 위해 Android 4.2에 추가된 MediaExtractor 클래스의 대응 API입니다.

지원되는 출력 형식은 MediaMuxer.OutputFormat에 정의되어 있습니다. 현재 지원되는 출력 형식은 MP4뿐이며 MediaMuxer는 현재 한 번에 하나의 오디오 스트림 또는 하나의 동영상 스트림만 지원합니다.

MediaMuxer는 주로 MediaCodec와 함께 작동하도록 설계되어 있으므로 MediaCodec를 통해 동영상 처리를 실행한 후 MediaMuxer를 통해 출력을 MP4 파일로 저장할 수 있습니다. MediaMuxer를 MediaExtractor와 함께 사용하여 인코딩이나 디코딩 없이 미디어 편집을 실행할 수도 있습니다.

RemoteControlClient의 재생 진행률 및 스크러빙

Android 4.0 (API 수준 14)에서는 RemoteControlClient이 원격 제어 클라이언트의 미디어 재생 컨트롤(예: 잠금 화면을 탭합니다. 이제 Android 4.3에서는 이러한 컨트롤러가 재생 위치와 재생 스크러빙 컨트롤을 표시할 수 있는 기능을 제공합니다. 리모컨을 사용하도록 설정한 경우 RemoteControlClient API를 사용하여 미디어 앱에 연결된 경우 재생을 허용할 수 있음 두 가지 새로운 인터페이스를 구현하여 스크러빙을 할 수 있습니다

먼저 FLAG_KEY_MEDIA_POSITION_UPDATE 플래그를 setTransportControlsFlags()에 전달하여 사용 설정해야 합니다.

그런 다음 다음 두 가지 새 인터페이스를 구현합니다.

RemoteControlClient.OnGetPlaybackPositionListener

여기에는 현재 위치를 요청하는 onGetPlaybackPosition() 콜백이 포함됩니다. 리모컨의 UI에서 진행률을 업데이트해야 할 때 미디어의 재생 시간을 설정할 수 있습니다.

RemoteControlClient.OnPlaybackPositionUpdateListener

여기에는 콜백 onPlaybackPositionUpdate()이 포함됩니다. 사용자가 제어할 수 있습니다.

새 위치로 재생을 업데이트한 후에는 setPlaybackState()를 호출하여 새로운 재생 상태, 위치, 속도를 설정할 수 있습니다.

이러한 인터페이스를 정의하면 각각 setOnGetPlaybackPositionListener() 및 setPlaybackPositionUpdateListener()를 호출하여 RemoteControlClient에 설정할 수 있습니다.

그래픽

OpenGL ES 3.0 지원

Android 4.3은 Java 인터페이스와 OpenGL ES 3.0의 기본 지원을 추가합니다. OpenGL ES 3.0에서 제공되는 핵심적인 신기능은 다음과 같습니다.

• 고급 시각 효과 가속
• 표준 기능으로 제공되는 고품질 ETC2/EAC 텍스처 압축
• 정수 및 32비트 부동 소수점 지원이 포함된 GLSL ES 셰이딩 언어의 새 버전
• 고급 텍스처 렌더링
• 텍스처 크기 및 렌더링 버퍼 형식의 광범위한 표준화

Android의 OpenGL ES 3.0용 Java 인터페이스는 GLES30로 제공됩니다. OpenGL ES 3.0을 사용할 때는 <uses-feature> 태그와 android:glEsVersion 속성을 사용하여 매니페스트 파일에서 이를 선언해야 합니다. 예를 들면 다음과 같습니다.

<manifest>
    <uses-feature android:glEsVersion="0x00030000" />
    ...
</manifest>

setEGLContextClientVersion()를 호출하여 OpenGL ES 컨텍스트를 지정해야 합니다. 3을 버전으로 전달합니다.

기기의 지원 여부 확인 방법을 비롯하여 OpenGL ES 사용에 관한 자세한 내용은 런타임 시 OpenGL ES 버전에 관한 자세한 내용은 OpenGL ES API 가이드를 참고하세요.

드로어블 밉매핑

밉맵을 비트맵 또는 드로어블의 소스로 사용하는 것은 간단한 방법입니다. 품질 이미지와 다양한 이미지 척도가 제공되며 이는 애니메이션 도중 배율이 조정될 것입니다.

Android 4.2 (API 수준 17)는 Bitmap에서 밉맵 지원을 추가했습니다. 클래스 - 작업을 완료하면 Android가 Bitmap의 밉니다. 밉맵 소스를 제공하고 setHasMipMap()를 사용 설정했습니다. 이제 Android 4.3에서는 mipmap 애셋을 제공하고 비트맵 리소스 파일에서 android:mipMap 속성을 설정하거나 hasMipMap()를 호출하여 BitmapDrawable 객체에도 mipmap을 사용 설정할 수 있습니다.

사용자 인터페이스

뷰 오버레이

새 ViewOverlay 클래스는 View 위에 투명 레이어를 제공합니다. 이 레이어는 시각적 콘텐츠를 추가할 수 있으며 레이아웃 계층 구조에 영향을 미치지 않습니다. getOverlay()를 호출하여 모든 View의 ViewOverlay를 가져올 수 있습니다. 오버레이 항상 호스트 뷰 (생성된 뷰)와 크기 및 위치가 동일합니다. 이를 통해 호스트 뷰 앞에 나타나지만 확장할 수 없는 콘텐츠를 추가할 수 있습니다. 호스트 뷰의 경계에 있어야 합니다.

ViewOverlay를 사용하면 생성하려고 할 때 특히 유용합니다. 컨테이너 외부로 뷰를 슬라이드하거나 화면에서 항목을 이동하는 등의 애니메이션 뷰 계층 구조에 영향을 주지 않고 그러나 오버레이의 사용 가능한 영역이 호스트 뷰와 동일한 영역으로 제한(외부에서 이동하는 뷰를 애니메이션으로 표시하려는 경우) 원하는 경우 원하는 상위 뷰의 오버레이를 사용해야 합니다. 레이아웃 경계.

Button와 같은 위젯 뷰의 오버레이를 만들 때 add(Drawable)를 호출하여 오버레이에 Drawable 객체를 추가할 수 있습니다. RelativeLayout과 같은 레이아웃 뷰에 getOverlay()를 호출하면 반환되는 객체는 ViewGroupOverlay입니다. ViewGroupOverlay 클래스는 ViewOverlay의 서브클래스이며 add(View)를 호출하여 View 객체를 추가할 수도 있습니다.

참고: 오버레이에 추가하는 모든 드로어블과 뷰는 시각적입니다. 포커스 또는 입력 이벤트를 수신할 수 없습니다.

예를 들어 다음 코드는 뷰를 배치하여 오른쪽으로 슬라이드하는 애니메이션을 보여줍니다. 을 추가한 다음 해당 보기에서 변환 애니메이션을 실행합니다.

val view: View? = findViewById(R.id.view_to_remove)
val container: ViewGroup? = view?.parent as ViewGroup

container?.apply {
    overlay.add(view)
    ObjectAnimator.ofFloat(view, "translationX", right.toFloat())
            .start()
}

View view = findViewById(R.id.view_to_remove);
ViewGroup container = (ViewGroup) view.getParent();
container.getOverlay().add(view);
ObjectAnimator anim = ObjectAnimator.ofFloat(view, "translationX", container.getRight());
anim.start();

광학 경계 레이아웃

이제 9패치 배경 이미지가 포함된 뷰의 경우 뷰의 '클립' 경계가 아닌 배경 이미지의 '광학' 경계를 기반으로 뷰가 인접 뷰와 정렬되도록 지정할 수 있습니다.

예를 들어 그림 1과 그림 2는 각각 동일한 레이아웃을 보여주지만 그림 1의 버전은 클립 경계(기본 동작)를 사용하는 반면 그림 2는 광학 경계를 사용합니다. 버튼과 사진 프레임에 사용된 9패치 이미지에는 가장자리 주위에 패딩이 포함되어 있으므로 클립 경계를 사용하면 서로 또는 텍스트와 정렬되지 않는 것처럼 보입니다.

참고: 그림 1과 2의 스크린샷에는 '레이아웃 경계 표시' 개발자 설정이 사용 설정되어 있습니다. 각 뷰에서 빨간색 선은 광학 경계를, 파란색 선은 클립 경계를, 분홍색 선은 여백을 나타냅니다.

그림 1. 클립 경계를 사용하는 레이아웃(기본값)

그림 2. 광학 경계를 사용하는 레이아웃

광학 경계를 기반으로 뷰를 정렬하려면 상위 레이아웃 중 하나에서 android:layoutMode 속성을 "opticalBounds"로 설정합니다. 예를 들면 다음과 같습니다.

<LinearLayout android:layoutMode="opticalBounds" ... >

그림 3. 광학 경계가 있는 Holo 버튼 나인 패치의 확대된 뷰

이 기능이 작동하려면 뷰의 배경에 적용된 나인 패치 이미지가 나인 패치 파일의 하단과 오른쪽을 따라 빨간색 선을 사용하여 광학 경계( (그림 3 참조) 빨간색 선은 클립 경계에서 빼야 하는 영역을 나타내며 이미지의 광학 경계는 남겨 둡니다.

레이아웃에서 ViewGroup에 광학 경계를 사용 설정하면 하위 뷰는 android:layoutMode를 "clipBounds"로 설정합니다. 또한 모든 레이아웃 요소는 하위 뷰의 광학 경계, 의 광학 경계에 따라 자체 경계를 조정합니다. 확인할 수 있습니다. 그러나 레이아웃 요소 (ViewGroup의 서브클래스)는 는 현재 자체 배경에 적용된 나인 패치 이미지에 대한 광학 경계를 지원하지 않습니다.

View, ViewGroup 또는 그 서브클래스를 서브클래스로 분류하여 맞춤 뷰를 만들면 뷰는 이러한 광학 바인딩 동작을 상속합니다.

참고: Holo 테마에서 지원하는 모든 위젯이 업데이트되었습니다. Button, Spinner, EditText 외 다수 따라서 앱이 Holo 테마(Theme.Holo, Theme.Holo.Light 등)를 적용하는 경우 android:layoutMode 속성을 "opticalBounds"로 설정하여 즉시 이점을 누릴 수 있습니다.

9-패치 그리기 도구로 자체 나인 패치 이미지의 광학 경계를 지정하려면 클릭하면 됩니다.

Rect 값의 애니메이션

이제 새 RectEvaluator를 사용하여 두 Rect 값 간에 애니메이션할 수 있습니다. 이 새 클래스는 ValueAnimator.setEvaluator()에 전달할 수 있는 TypeEvaluator의 구현입니다.

창 연결 및 포커스 리스너

이전에는 뷰가 창에 연결/연결 해제될 때 또는 포커스가 변경될 때 리슨하려면 View 클래스를 재정의하여 각각 onAttachedToWindow() 및 onDetachedFromWindow() 또는 onWindowFocusChanged()를 구현해야 했습니다.

이제 연결 및 분리 이벤트를 수신하려면 대신 ViewTreeObserver.OnWindowAttachListener를 구현하고 다음을 사용하여 뷰에서 설정하면 됩니다. addOnWindowAttachListener() 포커스 이벤트를 수신하려면 ViewTreeObserver.OnWindowFocusChangeListener를 구현하고 다음을 사용하여 뷰에 설정하면 됩니다. addOnWindowFocusChangeListener()

TV 오버스캔 지원

이제 앱이 모든 TV에서 전체 화면을 채우도록 앱 레이아웃에 오버스캔을 사용 설정할 수 있습니다. 오버스캔 모드는 FLAG_LAYOUT_IN_OVERSCAN 플래그에 따라 결정되며, 이 플래그는 Theme_DeviceDefault_NoActionBar_Overscan와 같은 플랫폼 테마를 사용하거나 맞춤 테마에서 windowOverscan 스타일을 사용 설정하여 사용 설정할 수 있습니다.

화면 방향

이제 <activity> 태그의 screenOrientation 속성이 사용자의 자동 회전 환경설정을 따르는 추가 값을 지원합니다.

"userLandscape"

사용자가 자동 회전을 사용 중지하면 일반 가로 모드 방향으로 고정되고 전환되지 않는 점을 제외하고 "sensorLandscape"와 동일하게 작동합니다.

"userPortrait"

사용자가 자동 회전을 사용 중지한 후 다음 경우를 제외하고 "sensorPortrait"와 동일하게 동작합니다. 정상적인 세로 방향으로 고정되고 뒤집히지 않습니다.

"fullUser"

"fullSensor"와 동일하게 작동하며 네 방향 모두에서 회전을 허용합니다. 단, 사용자가 자동 회전을 사용 중지하면 사용자의 선호 방향으로 고정됩니다.

또한 이제 "locked"를 선언하여 앱의 방향을 화면의 현재 방향으로 고정할 수도 있습니다.

회전 애니메이션

WindowManager의 새 rotationAnimation 필드를 사용하면 시스템에서 화면 방향을 전환할 때 사용할 세 가지 애니메이션 중 하나를 선택할 수 있습니다. 세 가지 애니메이션은 다음과 같습니다.

• ROTATION_ANIMATION_CROSSFADE
• ROTATION_ANIMATION_JUMPCUT
• ROTATION_ANIMATION_ROTATE

참고: 이 애니메이션은 활동이 '전체 화면'을 사용하도록 설정한 경우에만 사용할 수 있습니다. 이 모드는 Theme.Holo.NoActionBar.Fullscreen와 같은 테마로 사용 설정할 수 있습니다.

예를 들어 '크로스페이드' 애니메이션을 사용 설정하는 방법은 다음과 같습니다.

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)

    val params: WindowManager.LayoutParams = window.attributes
    params.rotationAnimation = WindowManager.LayoutParams.ROTATION_ANIMATION_CROSSFADE
    window.attributes = params
    ...
}

protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    WindowManager.LayoutParams params = getWindow().getAttributes();
    params.rotationAnimation = WindowManager.LayoutParams.ROTATION_ANIMATION_CROSSFADE;
    getWindow().setAttributes(params);
    ...
}

사용자 입력

새 센서 유형

새로운 TYPE_GAME_ROTATION_VECTOR 센서를 사용하면 자기 간섭에 대한 우려 없이 기기의 회전을 감지할 수 있습니다. TYPE_ROTATION_VECTOR 센서와 달리 TYPE_GAME_ROTATION_VECTOR는 자북을 기반으로 하지 않습니다.

새로운 TYPE_GYROSCOPE_UNCALIBRATED 및 TYPE_MAGNETIC_FIELD_UNCALIBRATED 센서는 소스 코드 없이 원시 센서 데이터를 편향 추정을 위한 고려사항입니다. 즉, 기존 TYPE_GYROSCOPE 및 TYPE_MAGNETIC_FIELD 센서는 자이로 드리프트와 강철에서 추정된 편향을 고려한 센서 데이터를 제공합니다. 각각 기기에서 생성됩니다. 반면 이러한 센서의 새로운 '보정되지 않은' 버전은 대신 원시 센서 데이터를 제공하고 추정된 편향 값을 별도로 제공합니다. 이러한 센서를 통해 로 예측 편향을 향상함으로써 센서 데이터에 대한 외부 데이터에 액세스할 수 있습니다.

알림 리스너

Android 4.3에서는 앱이 시스템에서 게시하는 새 알림에 대한 정보를 수신할 수 있는 새로운 서비스 클래스 NotificationListenerService를 추가합니다.

앱에서 현재 접근성 서비스 API를 사용하여 시스템 알림에 액세스하는 경우 대신 이 API를 사용하도록 앱을 업데이트해야 합니다.

연락처 제공자

'contactables' 쿼리

새로운 연락처 제공업체 쿼리인 Contactables.CONTENT_URI는 지정된 쿼리와 일치하는 모든 연락처에 속한 모든 이메일 주소와 전화번호가 포함된 하나의 Cursor를 효율적으로 가져오는 방법을 제공합니다.

연락처 변경사항 쿼리

연락처 데이터의 최근 변경사항을 효율적으로 쿼리할 수 있는 새로운 API가 연락처 제공자에 추가되었습니다. 이전에는 연락처 데이터의 무언가가 변경되면 앱에 알림을 받을 수 있었지만 정확히 무엇이 변경되었는지는 알지 못하므로 모든 연락처를 검색한 다음 반복하여 변경사항을 발견해야 했습니다.

이제 삽입 및 업데이트의 변경사항을 추적하기 위해 선택 항목에 CONTACT_LAST_UPDATED_TIMESTAMP 매개변수를 포함하여 마지막으로 제공자를 쿼리한 후 변경된 연락처만 쿼리할 수 있습니다.

삭제된 연락처를 추적하기 위해 새 테이블인 ContactsContract.DeletedContacts에서는 삭제된 연락처의 로그를 제공합니다 (하지만 삭제된 각 연락처는 이 표에 제한된 시간 동안 보관됨). CONTACT_LAST_UPDATED_TIMESTAMP와 마찬가지로 새로운 선택 매개변수인 CONTACT_DELETED_TIMESTAMP를 사용하여 마지막으로 제공업체를 쿼리한 후 삭제된 연락처를 확인할 수 있습니다. 이 표에는 로그가 보관될 일수 (밀리초)가 포함된 상수 DAYS_KEPT_MILLISECONDS도 포함되어 있습니다.

또한 이제 연락처 제공자는 사용자가 시스템 설정 메뉴를 통해 연락처 저장소를 지우면 CONTACTS_DATABASE_CREATED 작업을 브로드캐스트하여 연락처 제공자 데이터베이스를 효과적으로 다시 만듭니다. 모든 연락을 중단해야 한다고 앱에 알리기 위한 것입니다. 새로운 검색어로 다시 로드할 수 있습니다.

이러한 API를 사용하여 연락처 변경사항을 확인하는 샘플 코드는 SDK 샘플 다운로드에서 제공되는 ApiDemos 샘플을 참고하세요.

현지화

양방향 텍스트 지원 개선

이전 버전의 Android는 오른쪽에서 왼쪽 방향(RTL) 언어와 레이아웃을 지원하지만 혼합 방향 텍스트를 올바르게 처리하지 않는 경우가 있습니다. 따라서 Android 4.3에서는 텍스트의 일부를 왜곡하지 않고 반대 방향 콘텐츠로 텍스트 형식을 올바르게 지정하는 데 도움이 되는 BidiFormatter API를 추가합니다.

예를 들어 '15 Bay Street, Laurel, CA?'와 같은 문자열 변수가 포함된 문장을 만들려면 일반적으로 현지화된 문자열 리소스와 변수를 String.format()에 전달합니다.

val suggestion = String.format(resources.getString(R.string.did_you_mean), address)

Resources res = getResources();
String suggestion = String.format(res.getString(R.string.did_you_mean), address);

그러나 언어가 히브리어인 경우 형식이 지정된 문자열은 다음과 같이 표시됩니다.

האם התכוונת ל 15 Bay Street, Laurel, CA?

'15'는 '베이 스트리트' 왼쪽에 있어야 합니다. 해결 방법은 BidiFormatter 및 unicodeWrap() 메서드를 사용하는 것입니다. 예를 들어 위의 코드는 다음과 같이 변경됩니다.

val bidiFormatter = BidiFormatter.getInstance()
val suggestion = String.format(
        resources.getString(R.string.did_you_mean),
        bidiFormatter.unicodeWrap(address)
)

Resources res = getResources();
BidiFormatter bidiFormatter = BidiFormatter.getInstance();
String suggestion = String.format(res.getString(R.string.did_you_mean),
        bidiFormatter.unicodeWrap(address));

기본적으로 unicodeWrap()는 첫 번째 강한 방향성 추정 휴리스틱을 사용합니다. 이 휴리스틱은 텍스트 방향의 첫 번째 신호가 콘텐츠 전체에 적절한 방향을 나타내지 않는 경우 잘못된 결과를 얻을 수 있습니다. 필요한 경우 TextDirectionHeuristics에서 unicodeWrap()로 TextDirectionHeuristic 상수 중 하나를 전달하여 다른 휴리스틱을 지정할 수 있습니다.

참고: 이러한 새 API는 Android 지원 라이브러리를 통해 BidiFormatter 클래스 및 관련 API와 함께 이전 버전의 Android에서도 사용할 수 있습니다.

접근성 서비스

키 이벤트 처리

이제 AccessibilityService는 onKeyEvent() 콜백 메서드를 사용하여 키 입력 이벤트에 관한 콜백을 수신할 수 있습니다. 이렇게 하면 접근성 서비스가 키보드와 같은 키 기반 입력 장치의 입력을 처리하고 이러한 이벤트를 이전에는 터치 입력이나 기기의 방향 패드로만 가능했던 특수 작업으로 변환할 수 있습니다.

텍스트 선택 및 복사/붙여넣기

이제 AccessibilityNodeInfo는 다음을 허용하는 API를 제공합니다. 선택, 잘라내기, 복사, 붙여넣기를 위한 AccessibilityService 읽을 수 있습니다

접근성 서비스에서 잘라내거나 복사할 텍스트 선택을 지정하려면 새 작업, ACTION_SET_SELECTION, 전달 선택 시작 및 종료 위치가 ACTION_ARGUMENT_SELECTION_START_INT 및 ACTION_ARGUMENT_SELECTION_END_INT로 지정되어 있습니다. 또는 기존 작업 ACTION_NEXT_AT_MOVEMENT_GRANULARITY(이전에는 커서 위치 이동만 가능)을 사용하여 커서 위치를 조작하고 ACTION_ARGUMENT_EXTEND_SELECTION_BOOLEAN 인수를 추가하여 텍스트를 선택할 수 있습니다.

그런 다음 ACTION_CUT, ACTION_COPY로 자르거나 복사한 후 나중에 ACTION_PASTE로 붙여넣을 수 있습니다.

참고: 이러한 새 API는 Android 지원 라이브러리를 통해 AccessibilityNodeInfoCompat 클래스와 함께 이전 버전의 Android에서도 사용할 수 있습니다.

접근성 기능 선언

Android 4.3부터 접근성 서비스는 특정 접근성 기능을 사용하려면 메타데이터 파일에서 접근성 기능을 선언해야 합니다. 메타데이터 파일에서 기능이 요청되지 않으면 기능이 무작위로 실행됩니다. 서비스의 접근성 기능을 선언하려면 AccessibilityServiceInfo 클래스의 다양한 '기능' 상수에 해당하는 XML 속성을 사용해야 합니다.

예를 들어 서비스가 flagRequestFilterKeyEvents 기능을 요청하지 않으면 키 이벤트를 수신하지 못합니다.

테스트 및 디버깅

자동화된 UI 테스트

새로운 UiAutomation 클래스는 테스트 자동화를 위해 사용자 작업을 시뮬레이션할 수 있는 API를 제공합니다. 플랫폼의 AccessibilityService API를 사용하면 UiAutomation가 API를 사용하면 화면 콘텐츠를 검사하고 임의의 키보드와 터치 이벤트를 삽입할 수 있습니다.

UiAutomation의 인스턴스를 가져오려면 Instrumentation.getUiAutomation()를 호출합니다. 순서 이 작업을 수행하려면 instrument 명령어와 함께 -w 옵션을 제공해야 합니다. adb shell에서 InstrumentationTestCase 실행 시

UiAutomation 인스턴스를 사용하면 executeAndWaitForEvent()을 호출하고 실행할 Runnable, 작업의 제한 시간, UiAutomation.AccessibilityEventFilter 인터페이스의 구현을 전달하여 임의의 이벤트를 실행하여 앱을 테스트할 수 있습니다. UiAutomation.AccessibilityEventFilter 구현 내에서 전화를 받습니다. 관심 있는 이벤트를 필터링하고, '실패'에 포함됩니다

테스트 중에 모든 이벤트를 관찰하려면 UiAutomation.OnAccessibilityEventListener 구현을 만들어 setOnAccessibilityEventListener()에 전달합니다. 그러면 리스너 인터페이스에서 onAccessibilityEvent() 호출을 수신합니다. 이벤트가 발생할 때마다 AccessibilityEvent 객체를 수신합니다. 이벤트를 설명합니다.

UiAutomation API가 노출하는 다른 다양한 작업이 있습니다. uiautomator와 같은 UI 테스트 도구의 개발을 장려하기 위해 매우 낮은 수준에서 구현했습니다. 예를 들면 다음과 같습니다. UiAutomation에서 다음 작업도 할 수 있습니다.

• 입력 이벤트 삽입
• 화면 방향 변경
• 스크린샷 찍기

그리고 가장 중요한 점은 UI 테스트 도구의 경우 UiAutomation API가 작동한다는 점입니다. 애플리케이션 경계를 넘어 Instrumentation

앱의 Systrace 이벤트

Android 4.3에서는 systrace 보고서에 포함할 코드 블록을 정의할 수 있는 두 개의 정적 메서드인 beginSection() 및 endSection()가 있는 Trace 클래스를 추가합니다. 생성 추적 가능한 코드 섹션을 확인하려 할 때 systrace 로그는 앱 내에서 속도 저하가 발생하는 지점 분석

Systrace 도구 사용에 관한 자세한 내용은 Systrace로 디스플레이 및 성능 분석을 참고하세요.

보안

앱 비공개 키용 Android 키 저장소

이제 Android는 KeyStore 시설에 Android 키 저장소라는 맞춤 Java 보안 제공자를 제공합니다. 이를 통해 앱에서만 보고 사용할 수 있는 비공개 키를 생성하고 저장할 수 있습니다. Android 키 저장소를 로드하려면 "AndroidKeyStore"를 KeyStore.getInstance()에 전달합니다.

Android 키 저장소에서 앱의 비공개 사용자 인증 정보를 관리하려면 KeyPairGenerator와 KeyPairGeneratorSpec를 사용하여 새 키를 생성합니다. 첫 페이지 getInstance()를 호출하여 KeyPairGenerator의 인스턴스를 가져옵니다. 그런 다음 KeyPairGeneratorSpec.Builder를 사용하여 가져올 수 있는 KeyPairGeneratorSpec의 인스턴스를 전달하여 initialize()를 호출합니다. 마지막으로 generateKeyPair()를 호출하여 KeyPair를 가져옵니다.

하드웨어 사용자 인증 정보 저장소

이제 Android에서 KeyChain의 하드웨어 지원 저장소도 지원합니다. 키를 추출할 수 없게 하여 보안을 강화합니다. 즉, 한 번 키는 하드웨어 지원 키 저장소 (Secure Element, TPM 또는 TrustZone)에 저장되며 암호화 작업을 수행하지만 비공개 키 자료는 내보낼 수 없습니다. OS 커널조차 이 키 자료에 액세스할 수 없습니다. 일부 Android 기기는 하드웨어의 저장소를 지원하지 않지만 KeyChain.IsBoundKeyAlgorithm()를 호출하여 런타임 시 하드웨어 지원 저장소를 사용할 수 있는지 확인할 수 있습니다.

매니페스트 선언

선언이 필요한 기능

이제 <uses-feature>에서 다음 값이 지원됩니다. 요소를 사용하여 해당 기능을 제공하는 기기에만 앱이 설치되도록 할 수 있습니다. 확인할 수 있습니다

FEATURE_APP_WIDGETS

앱이 앱 위젯을 제공하고 다음과 같은 기기에만 설치되어야 한다고 선언합니다. 홈 화면 또는 사용자가 앱 위젯을 삽입할 수 있는 유사한 위치를 포함해야 합니다. 예:

<uses-feature android:name="android.software.app_widgets" android:required="true" />

FEATURE_HOME_SCREEN

앱이 홈 화면 대체 기능으로 작동하며 다음 기기에만 설치되어야 한다고 선언합니다. 서드 파티 홈 화면 앱을 지원하는 기기 예:

<uses-feature android:name="android.software.home_screen" android:required="true" />

FEATURE_INPUT_METHODS

앱이 맞춤 입력 방법 (InputMethodService로 빌드된 키보드)을 제공하며 다음 조건을 충족하는 기기에만 설치되어야 한다고 선언합니다. 서드 파티 입력 방법 지원 예:

<uses-feature android:name="android.software.input_methods" android:required="true" />

FEATURE_BLUETOOTH_LE

앱이 저전력 블루투스 API를 사용하며 기기에만 설치해야 한다고 선언합니다. 블루투스 저전력 블루투스를 통해 다른 장치와 통신할 수 있는 장치입니다. 예:

<uses-feature android:name="android.software.bluetooth_le" android:required="true" />

사용자 권한

이제 <uses-permission>에서 다음 값이 지원됩니다. kubectl run 명령어를 사용하여 권한을 부여할 수 있습니다.

BIND_NOTIFICATION_LISTENER_SERVICE

새 NotificationListenerService API를 사용하려면 필요합니다.

SEND_RESPOND_VIA_MESSAGE

ACTION_RESPOND_VIA_MESSAGE을(를) 받는 데 필요합니다. 인텐트를 지정할 수 있습니다.

Android 4.3의 모든 API 변경사항을 자세히 보려면 다음을 참조하세요. API 차이점 보고서를 참고하세요.