Android 4.4 

Host Card Emulation(HCE) 를 통한 NFC 기반의 거래(transaction) 를 위한 새로운 플랫폼 지원을 도입. 이를 통해 아래와 같은 것들이 가능하다.

HCE로 안드로이드의 앱들은 NFC 스마트 카드를 에뮬레이트 할 수 있다. 

그들이 선택한 앱에서의 거래를 초기화 하기 위해 터치(tap) 하도록 해준다.

앱들은 새로운 Reader Mode 를 사용할 수 있다. 이 reader mode 를 이용해 "HCE 카드 reader" 나 다른 NFC 기반의 거래들을 위한 reader 처럼 동작할 수 있도록 해준다. 

Android HCE 는 접촉하지 않는 ISO/IEC 1443-4(ISO-DEP) 전송 프로토콜을 이용하는 ISO/IEC 7816 기반의 스마트 카들들을 에뮬레이트 한다.

이 카드들은 현재, 기존의 EMVCO NFC 지불 인프라를 포함해서, 여러 시스템들에서 사용된다.

안드로이드는 Android Application Identifiers(AIDs) 라는 ID 를 사용한다. ISO/IEC 7816-4 에 정의된 것처럼 "정확한 안드로이드 application 들"에게 transaction들을 라우팅하기 위한 바탕(basis) 로 사용된다.

가능한 지원(support available, 예를 들면 payment) 의 타입을 가리키는 category id 와 함께  App 들은 manifest 파일에 AIDs 를 정의한다. 

여러개의 App 이 같은 AIDs 를 사용하는 경우, 안드로이드는 어떤 app 을 사용할 것인지 묻는 dialog 를 띄우게 된다.

유저가 무엇인가를 사려고 터치(tap)를 하면 시스템이 AID(preferred AID) 를 추출하고 그것을 알맞는 application 으로 전달(route)해 준다.

그러면, 그 application 이 매매 데이타(transaction data)를 읽고, transaction 을 확인하고, 완료하기 위해 local 또는 network 기반의 service 들을 이용할 수 있다. 

안드로이드 HCE는 기기에 NFC controller 가 있어야 한다. 대부분의 NFC controller 에서 HCE 를 지원한다. 그리고 NFC controller 는 HCE 와 SE transaction들에 대한 역동적인 지원을 제공한다.

NFC 를 지원하는 안드로이드 4.4 기기들은 HCE 를 이용한 쉬운지불(easy payment) 을 위한 "Tap&Pay" 를 포함한다.

프린트가 가능한 앱에서, 유저들은 가능한 프린터를 찾아낼 수 있다. 문서 사이즈들을 바꾸고, 프린트할 페이지를 설정하고 여러종류의 문서, 이미지, 파일등을 프린트할 수 있다.

안드로이드 4.4 는 프린트를 위한 native platform 을 도입했다. 그리고 이와 함께 프린팅을 관리하고 새로운 타입의 프린터 지원을 위한 API 들도 도입했다.

플랫폼은 프린트 매니저(print manager)를 제공한다. 이 프린트 매니저는 공유된 서비스들과 프린트를 위한 시스템 UI 를 제공한다. 이것들은 유저들에게 앱의 프린팅에 대한 꾸준한 제어를 준다.

프린트 매니저는 또한 앱으로부터 프린트 서비스로 프로세스들 사이를 지나갈 때 content 의 보안을 보장 해 준다. 

프린터 제조업자들은 특정 printer 와 통신하기 위해  판매자의 로직(logic)과 서비스들을 더해주는 "플러그를 꽂을 수 있는 구성요소들(pluggable components)" 같은 그들의 새로운 프리트 서비스들(print services)을 개발하는 데에 새로운 API 들을 사용할 수 있다.

그들은 google play 를 통해 print service 들을 만들고 배포할 수 있다. 

이렇게 Google Play 를 이용해서 유저들에게 찾고, 설치하는 것을 쉽게 해주고, 수시로 업데이트를 over-the-air 로 할 수 있게 해준다.

클라이언트 앱들은 조그마한 코드의 변화로 프린트 기능을 앱에 추가하기 위해 새로운 api 들을 사요할 수 있다.

대부분의 경우에, Action Bar 와 UI 에 print action 을 추가할 수 있다.

API 들을 구현할 수 있다.

프린트를 위해 

print manager 에 status 를 query 해보고 프린트를 취소할 수 있다.

local 이미지와 문서들부터 네트워크 데이터 또는 canvas 에 그려진 view 등에 이르기 까지

다양한 종류의 컨텐츠를 프린트 할 수 있다.

호환성을 위해서(broadest compatibility),

안드로이드는 PDF 를 사용한다.

프린트를 위한 주요한 file format(primary file format) 으로 사용한다.

프린트 전에 앱은 컨텐츠의 페이지 번호가 매겨진 PDF 버전을 만들어야 한다.

편리함을 위해, 프린팅 API 는 표준 안드로이드 drwaing API들을 사용해서 PDF 들을 만들수 있게 해주는 native 와 WebView helper class 들을 제공한다. 앱이 어떻게 content 를 그릴 수 있는지 안다면, 이것을 이용해서 빠르게 프린트를 위한 PDF 를 만들 수 있다.

Android 4.4 가 동작하는 대부분의 기기들은 print 서비스로 Google Cloud Print 를 포함하게 될 것이다. 또한 여러 크롬(chrome), Drive, Gallery 그리고 Quick Office 들을 포함한 여러 google app 들이 printing 을 지원할 것이다.

새로운 저장장치 접근 프레임워크(Stroage access framework)은 유저들에게 문서, 이미지, 그리고 모든 선호되는 "문서 저장 providers"의 다른 파일들을 browse 하고 열어보는 것을 쉽게 해준다.

표준 사용하기 쉬운 UI 는 유저들이 일정한 방법으로, 앱이나 provider 들에 상관없이, 파일들을 browse 하고, 최근에 접근한 파일에 접근하게 해준다.

클라우드 또는 local 저장 서비스들은 자신들의 service 들을 캡슐화하는 새로운 provider class 를 구현해서 이 에코시스템(ecosystem) 에 참여할 수 있다.

provider class 는 시스템과 함께 provider 를 등록하고 provider 에서 문서를 browsing, 읽고, 쓰기를 관리하기 위해 필요한 모든 API들을 포함한다.

문서 provider(document provider) 유저들에게 텍스트, 사진, 월페이퍼로 부터 비디오, 오디오 등등의 file 로 표현되는 원격 또는 local 데이터에 대한 접근을 제공 할 수 있다.

클라우드 또는 local 서비스를 위한 document provider 를 만든다면 , 너는 그것을 user 들에게 기존의 android app 에 포함 시켜서 전달 하면 된다.

다운로드 후에 그리고 앱이 인스톨한 후에  framework 에 참여한 앱으로 부터 서비스에 대한 접근이 가능하게 된다.

이것은 유저들이 좀 더 쉽게 서비스들을 찾을 수 있기 때문에, 앱을 좀 더 많이 노출하고 유저노출을 얻게 되고, 유저의 관심을 받을 수 있게 해준다.

파일이나 문서등을 들을 관리하는 클라이언트 앱을 개발한다면

파일을 열고, 만들 때 

새로운 

CREATE_DOCUMENT 또는 OPEN_DOCUMENT intent 

를 이용하는 것으로 storage access framework 에 통합될 수 있다.

시스템이 자동으로 모든 가능한 document provider 들을 포함해서 문서들을 browsing 하기 위한 표준 UI 를 보여준다.

모든 provider 들을 위해, 제조사의 code(vendor-specific code) 없이, client app 을 통합할 수 있다.

유저들이 provider 들을 더하고 뺄 때, code 의 변경이나 update 없이, app 에서 perferred service 들에 대한 접근을 계속 해서 가져갈 것이다.

storage access framework 는 기존의 GET_CONTENT intent 에 통합된다. 그래서 사용자들은 또한 browsing 을 위한 새로운 시스템 UI 로부터 이전의 content 와 data source 들에 대해서도 접근할 수 있다.

android 4.4 가 동작하는 대부분의 기기들은 document providers 로서 미리 통합된(pre-integraged) Google Drive 와 local 저장장치들을 포함할 것이다.

그리고 file 작업들을 하는 Google app 들은 새로운 framework 를 사용할 것이다.

sensor batching

안드로이드 4.4 에서는 hardware sensor batching 에 대한 지원을 시작했다. 이 haraware sensor batching 은 계속켜져 있는 센서 활동(ongoing sensor activities)에 의해서 드라마틱하게 전력소모를 줄여줄 수 있는 새로운 최적화이다.

sensor batching 과 함께, 안드로이드는 효율적으로 "sensor 이벤트들"을 모으기 위해, 그리고 여러개를 한 번에 묶음으로 전송하기 위해(감지할 때마다 보내는 대신에)기기의 하드웨어와 함께 동작한다.

이것은 기기의 application processor(AP) 가 이 이벤트 묶음이 전송되기 전까지 저전력(low-power idle) 으로 쉬고 있는 상태로 있게 해준다.

당신은 표준 이벤트 리스터(standard event listener) 를 이용해서 모든 센서로 부터 batched events (이벤트 묶음) 들을 요청할 수 있다. 당신은 또한 batch cycle 사이에 event 들을 즉시 전달해 달라고 요청할 수도 있다.

Sensor batching 은 웨이트(fitness), 위치 추적(location tracking), 모니터링, 등등 같은 저전력으로 오랜시간 사용하는 상황에 이상적이다.

당신의 app 을 좀 더 효율적으로 만들어 줄 수 있다. 그리고 sensor event들을 지속적으로 추적할 수 있게 해준다. 심지어 screen 이 꺼져 있는 동안에 system 이 sleep 모드 일때도 말이다.

sensor batching 은 현재 Nexus 5 에서 가능하다. 우리는 우리의 chipset 파트너들에게, 가능한 빨리, 좀 더 많은 device 에 적용하도록 하고 있다.

Step detector 와 Step counter

안드로이드 4.4 는 또한 2개의 새로운 composite sensor 들을 위해 플랫폼 지원을 추가했다.  -- "step 감지기"와 만보기(step counter) -- 이것들은 사용자가 걷고, 뛰고, 계단을 오를때 앱들이 step 을 추적하게 해준다.

step detector 는 언제 사용자가 step 을 하는지를 인식하기 위해 accelerometer(가속도계) 에서 들어오는 입력을 분석한다. 그리고나서 각각의 step 에 이벤트를 발생시킨다.

step counter(만보기) 는 기기가 reboot 한 이후의 총 step 의 횟수를 추적한다. 그리고 step 개수가 변할 때마다 이벤트를 발생시킨다.
로직(logic)과 센서운영(sensor management)은 platform 과 그 아래 하드웨어 안에 만어져 있다. 앱에서는 감지 알고리즘(detection algorithms)을 유지 할 필요가 없다.

step detector 와 counter sensor 들은 Nexus 5 에서 가능하다, 그리고 우리는 chipset partners 들에게 이것들을 새로운 기기에 가능한 빨리 도입하게 하고 있다.

SMS 나 MMS 를 사용하는 메시징 어플를 개발한다면, 이제, 공유된 SMS provider(shared SMS provider) 와 새로운 API 들을 앱의 메시지를 저장하는 것과 불러오는 것을 관리하는데 사용할 수 있다. 새로운 SMS provider 와 API 들은 SMS 또는 MMS 메시지들을 다루는 모든 앱을 위한 표준화된 상호작동 모델(standardized interaction model)을 정의한다. 

새로운 provider 와 API 들과 함께, 안드로이드 4.4 는 메시지를 받고 provider 에게 쓰는(write) 새로운 의미들(semantics)을 도입한다. 메시지를 수신할 때 시스템은 새로운 SMS_DELIVER intent 를 사용해서 그것을 사용자의 기본 메시지 앱으로 보낸다. 

또한, 다른 앱들이 아무 때나 읽을 수 있지만(read), 이제 시스템은 default 앱만 provider 에 메시지 데이터를 쓸 수 있게 한다. (write)

사용자의 default 가 아닌 앱들은 여전히 메시지들을 전송할 수 있다.

시스템은 앱의 관점에서 provider 에 그 메시지들을 쓰는 것(write)만 다룬다. 사용자들은 default 앱에서 그 메시지들을 볼 수 있다.

새로운 provider 과 semantics 는 여러 메시지 앱들이 설치되었을 때 유저의 경험을 향상시켜 주고, 그것들은 당신이 완전히 지원되고(fully-supported), 앞으로도 호환이 되는(forward-compatible) 새로운 메시징 요소들을 만드는 것을 도와줄 것이다.

전체화면을 애워싸는 모드

당신은 이제 당신의 컨텐츠를 보여줄 때 그리고 터치 이벤트를 잡을 때 화면위의 모든 픽셀을 사용할 수 있다.
안드로이드 4.4 는 새로운 전체화면을 애워싸는 모드(Full-screen immersive mode)를 추가했다. 이 모드는 당신이 폰과 태블릿 화면의 끝에서 끝까지 테두리 없이 꽉채우는 UI 들(Full-bleed UIs)을 만들 수 있게 하기 위해 status bar 와 navigation bar 같은 모든 시스템 UI 를 숨긴다. 이 모드는 사진, 비디오, 지도, 책, 게임등의 풍부한 시각적인 컨텐츠에 적합하다.

새로운 모드에서는 시스템 UI 는 사용자가 앱또는 게임과 교류(interacting) 하고 있을 때 조차 숨겨진 채로 머무른다. 화면 어느곳에서도, 심지어 시스템 바에 의해 점유되었던 영역에서도,  터치 이벤트를 캡쳐할 수 있다.
이것은 당신이 좀 더 크고, 좀 더 풍부하고, 좀 더 화면을 애워싸는 UI 를 만들수 있는 최선의 길을 제공해 준다. 그리고 또한 시각적인 산만함을 감소시켜 준다.

사용자들이 full-screen immersive mode 에서도 시스템 UI 에 대해 항상 쉽고 일관된 접근을 보장하기 위해 안드로드 4.4 는 immersive mode 에서 새로운 제스쳐(gesture)를 제공한다. 화면의 위나 아래 경계에서 부터 swipe을 하면 system UI 를 보여준다.

immersive mode 로 돌아가려면, bar 경계 밖의 화면을 터치하면 된다. 또는 잠시 기다리면 자동으로 bar 들이 사라진다. 일관적인 사용자 경험을 위해서 새로운 제스쳐와 함께, status bar 를 숨기는 이전의 방법도 같이 사용할 수 있다.

Transitions framework for animating scenes, 장면에 애니메이션 효과를 주기 위한 변환 프레임워크(Transitions framework for animating scenes)

대부분의 앱들은 그들의 흐름들(flows)을 여러개의 핵심 UI states 주위에서 구조화한다. 이 핵심 UI states(상태) 는 각각 다른 동작들(actions) 을 드러낸다. 또한, 많은 앱들은 사용자가 앱의 progress (진척사항)(states 와 각각에서 가능한 actions 을 통해 이루어지는 진척사항)를 이해하는 것을 도와주기 위해 애니메이션을 이용한다.

앱에서 고품질의 애니메이션들을 쉽게 만들게 하기 위해서, 안드로이드 4.4 는 새로운 transitions framework 을 도입했다.

transitions framework 는 당신이 장면들(일반적으로 view hierarchy 들, 그리고 변환(transitions))을 정의하게 해준다. 그리고 그것은 사용자가 그 장면들을 들어가거나 빠져나갈때, 그 장면들이 어떻게 움직이고(animate) 변형되어야 하는지를 설명한다.

당신은 레이아웃 경계나 visibility 같은 특정 속성(properties)을 이용해서 당신의 화면들을 움직이기 위해서, 다양한 "미리정의된 변환 타입들"을 사용할 수 있다. 장면이 변환하는 동안에 자동으로 희미해지고, 움직이고, view 를 resize 하는 자동변환 타입(auto-transition type) 도 있다.

게다가, 앱에서 가장 문제가 되는 속성을 움직이는(animate the properties) 커스텀 변환(custom transitions) 을 정의할 수 있다. 그리고, 필요하다면, 당신의 애니메이션 스타일에 연결할 수도 있다.(plug in).

transitions framework 를 이용해서 당신은, 장면들을 정의할 필요없이, UI 변화들을 애니메이션으로 만들수도 있다. 예를 들면, 당신은 view hierarchy 에 대한 변화들(changes)의 시리즈를 만들고, 그 다음에 TransitionManager 에게, 자동으로, 그 변화들(changes)에 대해서 지연된 변환(delayed transition)을 수행시킬 수 있다.

transitions 들을 set up 할 때, 그것은 당신의 앱으로 부터 transitions 을 호출하는 것은 단순하다. 예를 들면, transition 을 실행하기 위해서, view hierarchy 안 에서 다양한 changes 를 만들기 위해서, 그리고 지정해 놓은 changes를 애니메이션시키는 다음 프레임을 자동으로 시작하게 하기 위해 단지 하나의 method 를 호출하면 된다.

translucent system UI, 반투명한 시스템 UI

앱들은 반투명한 시스템 바(bar)를 요청하기 위해 새로운 window 스타일들을 사용할 수 있다.

어플리케이션 flow 의 특정 scene 사이에서 동작하는 전환(transitions) 에 대한 맞춤 제어(custom control) 을 위해, TransitionManager 를 사용할 수 있다. TransitionManager 는 당신이 scene 들과 특정 scene 의 변경을 위해 실행되는 transition 들 사이의 관계를 정의할 수 있게 해 줄 것이다.

Translucent system UI styling, 반투명 시스템 UI 스타일링

당신의 컨텐츠중 최고의 효과를 얻기위해, 당신은 반투명 시스템 UI(status bar 와 navigation bar 를 포함해서)를 사용하기 위해 새로운 윈도우 스타일들과 테마들을 사용할 수 있다.

navigation bar 버튼과 status bar 의 정보를 알아보기 쉽게 하기위해서, 미미한 그라디에이션이 시스템바뒤에서 보여진다. 그리고 전형적인 use-case 는 배경화면까지 보이도록 화면이 비치는 앱이 될 것이다.(A typical use-case would be an app that needs to show through to a wallpaper.)

Enhanced notification access, 향상된 알림 접근

Notification listener 서비스들은 이제 notification builder API들을 이용해서 만들어진 incoming notification 들에 대한 좀 더 많은 정보들을 볼 수 있다. Listener 서비스들은 notification 에 대한 좀 더 명확한 정보를 추출하기 위해서 그리고 다른 방법으로 정보를 보여주기 위해서, 새로운 extra fields(텍스트, 아이콘, 그림, progress, chronometer, 기타 등등) 와 notification 의 actions 에 접근할 수 있다.

안드로이드 4.4 는 Chromium 을 기본으로 완전히 새로운 WebView 를 구현했다.
새로운 Chromium WebView 는 당신에게 최신 표준 지원과 성능, 그리고 당신의 웹기반 콘텐츠를 만들고, 표시하는 것과 관련한 이전버전과의 호환성을 제공한다.

크로니엄 WebView 는 HTML5, CSS3, Javascript 에 대한 광범위한 지원을 제공한다. 안드로이드 30 의 크롬에서 가능한 대부분의 HTML5 feature 들을 지원한다. 엄청나게 향상된 자바스크립트 성능을 제공하는 자바스크립트 엔진(V8) 의 업데이트된 버전을 제공한다.

게다가, 새루운 크로니엄 WebView 는 크롬 DevTools 을 이용한 원격 디버깅을 제공한다. 예를 들면, 모바일 기기에서 동작하는 WebView 콘텐츠 를 감시, 디버그, 분석하기 위해 개발기기(development machine) 에서 Chrome DevTools 을 이용할 수 있다.

새로운 Chromium WebView 는 안드로이드 4.4 이상이 동작하는 모든 호환 기기들에서 제공된다.
이용할 수 있다. 새로운 WebView 의 이점을 바로 이용할 수 있고 , 또는 기존의 앱과 컨텐츠를 아주 조금 수정하는 것으로 WebView 의 이점을 활용할 수 있다. 대부분의 경우 컨텐츠는 자연스럽게 이 새로운 구현(the new implementation)으로 넘어갈 것이다.

이제 당신의 안드로이드 기기를 이용해서 당신의 앱에 대한 고품질의 비디오를 쉽게 만들 수 있다. 안드로이드 4.4는 화면녹화 기능을 추가했다. 당신이 USB 를 통해서 안드로이드 SDK 환경에 접속된 기기에서 녹화를 시작하고 멈추게 할 수 있는 화면 녹화 도구를 제공한다.
이것은 새로운 방법이다. 작동방법을 알려주는 동영상(walkthrough)이나 튜토리얼, 테스트방법이나, 마케팅 비디오등 을 만드는 정말 좋은 새로운 방법이다.

화면녹화 도구를 이용해서, 당신의 기기 화면 콘텐츠의 비디오를 캡쳐할 수 있고, MP4 파일형식으로 기기에 저장할 수 있다. 당신은 기기가 지원하는 해상도와 당신이 원하는 bitrate 로 녹화할 수 있다. 그리고  출력은 화면의 화면 비율(aspect ratio) 유지한다. 녹화가 끝났을때, 바로 기기에서 비디오를 공유하거나 MP4 파일등의 후처리(post-production)를 위해 호스트 컴퓨터로 옮길 수 있다.

만약, 당신의 앱이 화면 녹화 프로그램을 통해 저장하고 싶지 않은 비디오나 다른 보호된 콘텐츠를 플레이한다면, 당신은 SurfaceView.setSecure() 를 이용해서 콘텐츠를 secure 로 표시할 수 있다.

당신은 Android SDK 에 포함되어 있는 adb tool 을 이용해서 화면 녹화에 접근할 수 있다. adb command 는 아래와 같다.

• adb shell screenrecord

또한, Android Studio 의 DDMS 패널을 통해서 그것을 실행할 수 있다.

Resolution switching through adaptive playback

Android 4.4 brings formal support for adaptive playback into the Android media framework. Adaptive playback is an optional feature of video decoders for MPEG-DASH and other formats that enables seamless change in resolution during playback. The client can start to feed the decoder input video frames of a new resolution and the resolution of the output buffers change automatically, and without a significant gap.

Resolution switching in Android 4.4 lets media apps offer a significantly better streaming video experience. Apps can check for adaptive playback support at runtime using existing APIs and implement resolution-switching using new APIs introduced in Android 4.4.

Common Encryption for DASH

Android now supports the Common Encryption (CENC) for MPEG-DASH, providing a standard, multiplatform DRM scheme for managing protecting content. Apps can take advantage of CENC through Android's modular DRM framework and platform APIs for supporting DASH.

HTTP Live Streaming

Android 4.4 updates the platform's HTTP Live Streaming (HLS) support to a superset of version 7 of the HLS specification (version 4 of the protocol). See the IETF draft for details.

Audio Tunneling to DSP

For high-performance, lower-power audio playback, Android 4.4 adds platform support for audio tunneling to a digital signal processor (DSP) in the device chipset. With tunneling, audio decoding and output effects are off-loaded to the DSP, waking the application processor less often and using less battery.

Audio tunneling can dramatically improve battery life for use-cases such as listening to music over a headset with the screen off. For example, with audio tunneling, Nexus 5 offers a total off-network audio playback time of up to 60 hours, an increase of over 50% over non-tunneled audio.

Media applications can take advantage of audio tunneling on supported devices without needing to modify code. The system applies tunneling to optimize audio playback whenever it's available on the device.

Visualizer showing loudness enhancer audio effect
Visualization of how the LoudnessEnhancer effect can make speech content more audible.

Audio tunneling requires support in the device hardware. Currently audio tunneling is available on Nexus 5 and we're working with our chipset partners to make it available on more devices as soon as possible.

Audio monitoring

Apps can use new monitoring tools in the Visualizer effect to get updates on the peak and RMS levels of any currently playing audio on the device. For example, you could use this creatively in music visualizers or to implement playback metering in a media player.

Loudness enhancer

Media playback applications can increase the loudness of spoken content by using the new LoudnessEnhancer effect, which acts as compressor with time constants that are specifically tuned for speech.

Audio timestamps for improved AV sync

The audio framework can now report presentation timestamps from the audio output HAL to applications, for better audio-video synchronization. Audio timestamps let your app determine when a specific audio frame will be (or was) presented off-device to the user; you can use the timestamp information to more accurately synchronize audio with video frames.

Wi-Fi CERTIFIED Miracast™

Android 4.4 devices can now be certified to the Wi-Fi Alliance Wi-Fi Display Specification as Miracast compatible. To help with testing, a new Wireless Display developer option exposes advanced configuration controls and settings for Wireless Display certification. You can access the option at Settings > Developer options > Wireless display certification. Nexus 5 is a Miracast certified wireless display device.

당신의 app 이 RenderScript 를 사용한다면, 다시 compile 하지 않아도, RenderScript runtime 의 계속되는 성능 조절로 이득을 볼 것이다.

RenderScript 가 지원되는 곳에서 RenderScript 를 사용하는 모든 앱들은 재컴파일(recompiling)이나 코드변경없이, GPU 가속의 이득을 받는다. 

다음 Nexus 10 에서 처음으로 RenderScript GPU acceleration 이 등장한 이후에 여러 다른 하드웨어 파트너들이 지원하고 있다.

안드로이 4.4 에서 GPU 가속은 Nexus 5, Nexus 4, Nexus 7(2013), Nexus 10 에서 가능하다.

native code 에서도 직접 RenderScript 로 이용할 수 있다.

Android Native Development Kit(NDK) 에 있는 새로운 c++ API 는 script intrinsic 들, custom kernel 들등을 포함한 똑같은 RenderScript 기능에 접근할 수 있게 해준다. 이 기능들은 framework API 들을 통해 사용할 수 있다.

큰, performance-intensive 일(tasks) 를 native code 에서 처리해야 한다면, 

이 task 들을 처리할 수 있다. RenderScript 를 이용해서

그리고 이것들을 당신의 code 통합할 수 있다.

RenderScript 는 넓은 device의 범위에서 멀티 코어 cpu 들, GPUs, 다른 processors 들에 대해 자동지원과 great performance 를 제공한다.

NDK 를 통해서 RenderScript 를 사용하는 app 을 build 할 때, framework APIs 들이 사용할 수 있는 RenderScript support library 와 함께 배포하는 것처럼, 그 app을 Android 2.2 이상을 사용하는 어떤 기기에도 배포할 수 있다. 

Android 4.4 는 SurfaceFligner 를 OpernGL ES 1.0 에서 OpenGL ES 2.0 으로 업그레이드 했다.

최신 버전 안드로이드 하드웨어 작성자(Android Hardware Composer, HWComposer 1.3)는 기본 디스플레이, 외부의 디스플레이(즉, HDMI) 에 더해서 가상 디스플레이의 하드웨어 작성을 지원한다.  OpenGL ES interoperability 를 향상했다.

IR Blasters, 적외선 송출기

안드로이드 4.4 는 내장된(built-in) IR blasters 를 이용할 수 있게 해주는 새로운 API 와 시스템 서비스 와 함께 그것들을 지원하는 플랫폼을 도입했다.

새로운 API를 이용해서, 당신은 사용자들이 근처 TV, 튜너, 스위치, 기타 다른 전자기기를 원거리에서 조정을 할 수 있게 해주는 앱을 만들 수 있다.
API 는 앱이 폰 또는 태블릿이 적외선 방출기를 가지고 있는지 체크할 수 있게 해주고, 그것의 캐리어 주파수를 물어보고 적외선 신호를 전송할 수 있도록 해준다.

API 는 안드로이드 4.4 이상이 동작하는 안드로이드 기기 전반에 걸친 표준이기 때문에, 앱은 자체적인 통합 코드(custom integration code)없이 가능한 가장 넓은 범위의 제조사들(possible range of vendors) 지원할 수 있다.

Closed captioning settings

닫힌 자막을 위한 시스템 범위의 세팅, system-wide settings for closed captioning

안드로이드 4.4는 closed captioning 을 위한 시스템범위의 설정(preferences) 에 의해 이제 좀 더 나은 앱에 대한 접근 경험을 제공한다. 사용자들은
Settings > Accessibility > Captions
로 가서,  자막을 보이는 거나 사용할 언어, 자막 사이즈 그리고  글자 스타일 같은 global captioning preferences(글로벌한 자막 설정) 을 설정할 수 있다.

비디오를 이용한 앱들은 이제 사용자의 자막 세팅에 접근할 수 있고 화면을 사용자의 설정에 맞게 조정할 수 있다. 새로운 자막 매니저 API 는 당신이 사용자의 자막 설정을 검사하고 모니터하게 해 줄 것이다. 자막 매니저는 당신에게 사용자가 선호하는 자막 상태, 선호하는 locale, 크기(scaling factor), 그리고 글자 스타일을 제공한다. 글자 스타일은 글자색(foreground color) 와 배경색(background color), edge 속성과 typeface 를 포함한다.

http://developer.android.com/about/versions/kitkat.html#44-closed-captioning

앱들은 유저의 시스템전반의 자막설정을 참고할 수 있다. 위의 그림은 자막 설정 화면의 예이다.

추가로, 앱들은 VideoView 를 이요하는 앱들은 새로운 API 를 이용해서 렌더링할 비디오 스트림과 함께 자막 스트림을 전달하는 데 사용할 수 있다. 시스템은 유저의 system-wide 설정에 따라서 자동으로 비디오 프레임위에 있는 자막을 처리한다. 최근에는, VideoView 가 WebVTT format 에 한해서 자막의 자동표시를 지원한다.

자막을 보여주는 모든 앱들은 사용자의 systemwide 자막 설정을 검사하는 것을 보장해 줘야 한다. 그리고 캡션을 설정에 가능한 가깝도록 렌더링하는 것을 보장해야 한다.

얼마나 구체적인 세팅의 조합이 어떻게 보이는지에 대한 좀 더 나은 통찰을 위해 당신은 Settings(Settings app) 에서 다른 언어, 사이즈, 스타일의 자막을 미리 볼 수 있다.

향상된 접근하기 쉬운 API 들, Enhanced Accessibility APIs

안드로이드 4.4 는 좀 더 정확한 구조적이고 의미론적(semantic)인 설명과 화면위의 요소들에 대한 관찰(observation)을 지원하기 위해서 accessibility API 들을 확장한다.

새로운 API들을 이용해서, 개발자들은 화면위의 요소들(on-screen elements)에 대한 좀 더 많은 정보와 함께 accessibility 서비스들을 제공하므로써, 접근가능한 피드백(accessible feedback)의 품질을 향상시킬 수 있다.

accessibility 노드(node)들에서, 개발자들은 이제 노드가 팝업인지를 정할 수 있고, input type 을 얻는 등의 일을 할 수 있다. 당신은 새로운 API 를 이용해서 grid 모양의 정보(리스트나 테이블 같은)를 가지고 있는 nodes 를 처리할 수 있다. 예를 들면, 새로운 동작, collection 정보, live region mode 등을 정의할 수 있다.

새로운 accessiblity 이벤트들은 개발자들에게 윈도우 콘텐츠에서 일어나는 변경사항을 빠르게 따라가게 해준다. 그리고 그들은 기계가 터치 탐사 모드(touch exploration mode) 일때 변경사항을 듣는다.

RTL features

RTL(right to left) 로케일(locales) 을 위한 drawable 의 미러링(mirroring)

당신의 앱이 RTL 스크립트를 사용하는 사용자를 타겟으로 한다면, 당신은 새로운 API 를 사용할 수 있는데, 이 새로운 API 는 사용자들의 locale 세팅이 RTL 언어를 포함할 때 drawable 이 자동으로 반사되도록(auto-mirrored) 정의해준다.

drawable 을 auto-mirrored 로 정의하는 것은 당신이 앱에서 asset 들을 중복해서 만드는 것을 막아주고 APK 의 사이즈를 줄여줄 것이다.
당신이 LTR(left-to-right) 과 RTL, 두 표현을 위해 모두 사용해야 하는 drawable 들을 가지고 있을 때, 당신은 default 버전들을 auto-mirrored 로 정의하고, 당신의 RTL resources 에 있는 drawables 들을 제거해(omit) 버릴 수 있다.

당신은 당신의 어플리케이션 코드에 "여러타입의 drawable 들"을(bitmap, nine-patch, layer, state list, 기타 다른 drawables  auto-mirrored 로 정의할 수 있다.
당신은 새로운 attribute 를 이용해서 당신의 resource file 에 drawable 을 auto-mirrored 로 정의할 수 있다.

강제로 RTL 레이아웃 만들기

RTL 언어로 변경하지 않은 상태로, 레이아웃의 미러링 이슈들에 대한 테스트와 디버그를 쉽게 해주기 위해서, 안드로이드는 모든 앱들을 강제로 RTL layout 방향으로 바꿔주는 새로운 개발자 옵션을 도입했다.

Force RTL direction layout 옵션은 기기를 모든 locale 들에 대해서 RTL layout 으로 바꿔주고, 현재 사용하고 있는 언어로 표시 해 준다. 이것은 앱을 RTL 언어로 바꾸지 않고 layout 이슈들을 찾는데 도움을 줄 수 있다.

• Settings > Developer options > Force RTL layout direction.

로 이 옵션에 접근할 수 있다.

안드로이드는 2개의 추가적인 암호화 알고리즘을 지원함으로써 보안이 좀 더 향상된 상태다. 

Elliptic Curve Digital Signature Algorithm(ECDSA) 의 지원은 keystore provider 에 추가된 상태다. 이것은 디지털 서명(digital signing) 의 보안을 향상시키고, 이 디지털 서명은application 의 서명(application signing) 또는 데이터 접속(data connection) 같은 시나리오에 적용될 수 있다.

Script key 변형 함수(derivation function) 는 full-disk 암호화에 사용되는 암호 키(cryptographic keys)들을 보호하기 위해 구현되었다. 

이제, 여러 사용자가 사용하는 기기들에서 VPN 들은 사용자 개개인에 적용된다. 이것은 사용자가 기기의 다른 사용자들에게 영향을 주지 않고, VPN 을 통해 모든 network traffic 을 route 할 수 있게 해준다.

또한, 안드로이드는 이제 FORTIFY_SOURCE level 2 를 지원한다. 그리고 모든 코드는 FORTIFY_SOURCE level 2 의 보호방법(protections)들과 함께 컴파일 된다.(참고로, FORTIFY_SOURCE 는 compile 옵션이다.) FORTIFY_SOURCE 는 clang(static analyzer) 에서 잘 동작하게 향상되었다.

(역자 : FORTIFY_SOURCE 관련정보 )

Tools for analyzing memory use

Procstats

새로운 도구다
자신의 app 이 사용하는 memory 자원(memory resources) 들을 분석해 준다.
또한, 다른 앱들이 사용하는 resource 들과 시스템에서 동작하고 있는 서비스들도 분석 해 준다.

Procstats 는 app 이 어떻게 시간에 따라 어떻게 동작하는지 추적한다. 얼마나 효과적으로 동작하는지를 알아내는것을 도와주기 위해  실행 시간과 메모리 사용 같은 데이터를 제공한다.
이것은 매우 중요하다. background 로 동작하는 service 를 시작하는 앱에게 매우 중요하다. 왜냐하면 이것은 얼마나 오래 동작했고, 동작하는 동안 얼마나 많은 RAM 을 사용하는지 알려주기 때문이다.

Procstats 는 또한 app 의 전체적은 메모리 프로파일을 알아내기 위해 메모리 사용에 대한 foreground app 의 data 를 모을 것이다.

당신의 app 에 의해 동작하는 background 서비스들을 구분하는 것을 도와줄 수 있고,
Procstats 는 도울수 있다.
당신의 app 에 의해 동작하는 background 서비스들을 구분하는 것을 도와줄 수 있고, 추적할 수 있다. 얼마나 오랫동안 service 들이 동작하는 지와 RAM 을 얼마나 사용하는지 Procstats 는 당신이 당신의 app 이 foreground 에 있는 동안 profile 할 수 있도록 해줄 것이다.
Procstats 는 그 app 의  전체적인 메모리 profile 을 알아내기 위해 시간에 따른 메모리 사용을 이용해서 이것을 할 것이다.

기기에서 profiling 을 위해서는 Process Stats 개발자 옵션을 보자.

안드로이드 4.4 는 앱의 메모리 사용내용(profile)을 쉽게 분석해주는 새로운 개발자 옵션을 가지고 있다.

적은 RAM 을 가진 기기에서 당신의 앱이 어떻게 동작하고, 어떻게 메모리를 사용하는지를 아는데를 아는데에 매우 유용하다.

를 통해서 접근할 수 있다.

Process Stats 옵션은 새로운 procstats service 를 이용해서 모은 데이터를 기반으로 해서 당신의 앱의 메모리 사용에 대한 다양한 high-level 메트릭스를 보여준다.

메인화면에서 시스템 메모리 상태에 대한 요약(summary)을 볼 수 있다. 

을 나타낸다.

요약(summary) 밑에있는 것은 각 앱들의 시스템에서의 memory load 이다. 파란색 바는 그 프로세스의 상대적으로 계산된 memory load(runtime x avg_pss) 를 가리킨다.

그리고 퍼센트 값은 background 에 소요된 상대적인 시간을 이야기 한다.

필터도 제공해서

앱을 선택하면, 앱의 메모리 사용내용을 좀 더 자세하게 볼 수 있다. 

Process Stats 내의 데이터를 분석하는 것은 issue 를 만들고, 앱에 대한 최적화를 제안한다. 예를 들면, 특히, 적은 RAM 을 가지고 있는 기기에서 동작할 때, 앱이 동작해야 하는 시간보다 더욱 오래 동작하고나, 동작하는 동안에 너무 많은 memory 를 사용한다면, 코드에, 수정하면 앱의 성능을 향상시킬 버그가 있을 수 있다.