티스토리 뷰
Android 5.0 Preview
Android Lollipop API 살펴보기
본 게시물은 SK플래닛 전슬마로 매니저님 (@marojuns)님의
허락을 받고 게시한 글 입니다.
Android 5.0 Lillipop의 정식 출시 이전에 개발자
프리뷰 버전인 Android L를 직접 설치해보시고, 다양한 이슈를 정리해주 전슬마로 매니저님께
정말 감사드립니다. -포드 드림.
이번 구글 I/O 2014에서 발표한 안드로이드 L Developer Preview API에 대해서 살펴보도록 하겠습니다. 이에 대한 전반적인 내용은 구글 코리아 블로그에 게시되어 있는
포스트를 읽어 보시면 쉽게 이해하실 수 있으실 것입니다. 여기에서는 API에 대한 설명을 포함한 좀 더 자세한 리뷰를 진행하도록 하겠습니다.
안드로이드 L이 아직 정식 버전이 아닌만큼 의미가 없다고 생각하실 수 도 있지만 정식버전이 preview 버전 대비 엄청난 변경이 있지 않을 것으로 예상되며(이미 support-v7 lib에 적용된것도 있으니) 구글이 앞으로 생각하는 안드로이드란 무엇인가? 라는 것을 미리 구현해 볼 수 있다는 것은 큰 메리트라고 생각됩니다.
그렇지만 아직 주력 OS로 사용하는 것은 무리일 듯합니다. (일부 앱 실행, 설치 안됨. MMS 내용 확인 안됨. 배경색 표현 안됨. 구글 Map 앱 반복적인 종료, 결제 안됨, 시스템 UI 종료 등 아직은 너무 많은 버그가 있네요.) 딱 테스트용으로 보시면 되겠습니다.
아직 L이 프리뷰 버전인 만큼 구현할 수 없는 기능들도 존재 하였습니다. 그런 부분에 대해서는 검증없이 번역만이 진행되어 이해하시는데 어려움이 있으실 수 있습니다. (제 번역 실력이 뛰어난 편이 아니라..) 이런부분들이 존재하는 만큼 오역이나 보충할 부분에 대해 댓글이나 @_marojun으로 멘션 주시면 업데이트 하도록 하겠습니다. 또한 아래 주제들에 대해서도 계속 추가, 보강해서 업데이트 할 예정이니 지속적인 관심 부탁드립니다.
항상 부족한 글 읽어주셔서 감사합니다.
Important Behavior Changes
New Android Runtime (ART)
첫번째는 가상머신이 Dalvik에서 ART로 변경된다는 것입니다. ART는 이미 4.4에서 소개되었으며 개발자 분들은 이미 사용하고 계신분들이 많아 새로우실 것도 없을것 같네요.
4.4 판올림에 따른 ART의 등장에 혼란스러워하는 개발자들
사실 ART의 표준화는 구글 I/O 발표 얼마전 아래와 같은 Davik is dead 라는 코멘트를 보고 예상했는데 역시나 였습니다.
>달빅 안녕 ㅜ
ART에 대해 간략하게 설명하자면 기존대비 아래와 같은 변화가 있습니다.
앱 실행 시마다 컴파일 하는게 아니라 앱 설치 시 미리 컴파일 해놓기 때문에 첫 구동 이후의 앱 실행속도가 증가 합니다.
- Improved garbage collection (GC) (GC 속도 향상)
큰 용량의 이미지가 있는 리스트 등의 스크롤시 좀 더 부드러워 집니다.
구글에선 위와같은 변경들로 인해 속도가 1.x~ 3.x배까지 좋아진하고 합니다. 사실 저는 게임처럼 무거운 앱을 사용하지 않아 그런지 ART로 변경해서 사용해도 체감은 잘 안느껴지더라구요.
참고로 아래와 같은 기술을 적용한 경우는 앱이 동작하지 않을수 있으니 미리미리 테스트해 보시는게 좋습니다. 제가 서비스하는 앱도 동작을 안해서 진땀을.. 물론 구글 측에서 지원되도록 한다고 하는데 사실 완벽지원에 대한 보장은 없으니 어쩔수 없는 경우가 아니라면 코드 수정을 하시는게 좋을 것 같습니다
1. C/C++ 코드가 돌아가기 위해 JNI을 사용한 경우
2. 표준코드를 사용하지 않은
경우( obfuscators 처럼)
3. compacting
garbage collection 사용불가
ART에 대해 자세한 사항은 Introducing ART 또는 아래 영상을 참조하세요.
Google I/O 2014 — The ART runtime
If your app implements notifications…
두번째 변화는 알림입니다.
크게는 알림의 배경색 변경 그리고
헤즈업 방식이 추가되었습니다.
4.4 VS Android L
알림은 보통 흰 배경에 검정색 글자로 나타내어 지는데 새로운 material design을 통해 배경색을 변경할 수 있게 되었습니다. 그러기 위해선 아래 사항들을 적용하도록 합니다.
- assets에 색상을 등록
- 기본적으로는 시스템이 노티의 액션 아이콘 색을 정하지만 android.app.Notification. Builder.setColor(을 통해 아이콘 이미지의 대표색을 사용
- 시스템은 메인 노티의 아이콘과 액션 아이콘이 불투명할 경우 무시. 즉, 배경이 투명한 아이콘들에 대해서만 사용해야 한다. (투명한 바탕에 그라데이션등이 적용되지 않은 순수한 흰색만을 사용한 아이콘을 사용) — 만약에 이러한 조건을 지키지 않을시에는 예상치 못한(?) 아이콘을 보게 되실겁니다.
만약 알림이 왔을때 진동이나 소리가 나게 했을 경우 그러니까 Ringtone, MediaPlayer, 또는 Vibrator classes을 통해 구현한 부분이 있다면 모두 제거하도록 합니다. 아이폰에서 이전에 선보인 기능와 같은 방해금지모드 (Do not Disturb mode) 가 정상적으로 작동하게 하기 위해서 입니다. 대신 Notification.Builder을 통해 해당 기능들을 구현하도록 합니다.
헤즈업 알림
헤즈업 알림을 통해 현재 앱에서 이동하지 않고 특정 액션을 수행하거나 취소할 수 있게 되었습니다. (만약 지금 사용하시고 있는 안드로이드 OS 에서는 위 그림과 같은 상황이 발생한다면 게임앱에서 전화가 오는 화면으로 전환되어 버렸겠죠? 전화를 무시하고 게임으로 전환하면 이미 게임오버 ㅜ)
헤즈업 알림은 다음과 같은 조건에서 사용할 수 있습니다.
Android Wear에서의 알림은 Android Wear 리뷰 글을 참조해 주세요.
If your app uses RemoteControlClient…
transport controls VS media playback control
L 프리뷰 버전에서는 RemoteControlClient를 통해 구현되었던 transport controls 을 사용할 수 없게 되었습니다. 대신 노티를 통한 media playback control 을 지원하여 개발자 입장에서 좀 더 쉽게 미디어 controler를 개발할 수 있도록 지원합니다. 사용자 입장에선 락 상태와 언락상태에서 동일한 노티 모양의 컨트롤러를 사용하기 때문에 seamless한 경험을 할 수 있게 되었습니다.
L은 위 기능을 수행하기 위해 android.app.Notification.MediaStyle 을 발표했는데
먼저 Notification.Builder.addAction() 을 통해 알림을 구현 한 후 MediaStyle 을 이용하여 위 이미지처럼 컴팩트한 버튼으로 보이도록 합니다.
이후 android.media.session.MediaSession Class 를 통해 시스템에서 미디어 기능을 컨트롤을 할 수 있도록 Notification.MediaStyle.setMediaToken() 메서드를 통하여 세션 토큰을 정의 합니다.
마지막으로 Notification.Builder.setVisibility (Notification.VISIBILITY_PUBLIC) 을 통해 락 스크린에 노출되도록 합니다.
알림에 관한 더 많은 정보는 Lockscreen Notifications 을 참조하시기 바랍니다.
If your app uses ActivityManager.getRecentTasks()…
앞으로 ActivityManager.getRecentTasks() 메서드는 사용자의 보안상 deprecated 될 예정 입니다. 그러나 하위 호완성을 위해 부분적인 정보는 지원될 예정 (해당 앱의 태스크들 또는 보안상 이슈가 없을 만한 태스크 — 예를 들어 홈화면 — 에 한해서) 이며 대신 android.app.ActivityManager.getAppTasks()를 사용하면 해당 앱의 태스크들에 대한 정보를 가져올 수 있습니다.
User Interface
Material design support
새로운 릴리즈에서 안드로이드의 새 디자인인 Material이 지원됩니다. 이 새로운 디자인은 시각적으로 다이나믹하며 자연스러운 화면 전환을 보여주는데 이러한 효과를 낼 수 있도록 해주는 특징은 다음과 같습니다.
시스템 위젯의 컬러를 팔레트를 통해 변경할 수 있게 되었으며 터치 피드백 애니메이션이 지원됩니다. 또한 액티비니 전환 애니메이션 효과를 통해서 본인이 커스터마이징한 애니메이션들을 진입 또는 종료 시 화면전환이나 액티비티 간에 공유되는 요소들에 대해 적용할 수 있게 되었습니다.
참고로 이전 테마와 L 테마를 같이 사용하기 위해서는 res/values/styles.xml에 이전 테마를 res/values-v21/styles.xml에 새로운 테마를 적용하시면 됩니다.
Z 축의 순서를 입력하면 이를 순차적으로 렌더링해 부드럽게 그림자 처리를 할 수 있게 되었습니다.
RecyclerView 그리고 CardView
구글에서는 리사이클러 뷰는 리스트 뷰의 향상된 버전으로 기존대비 퍼포먼스가 좋아졌고 다이나믹한 효과들을 적용하는 것이 쉬워졌다 라고 정의하고 있습니다. 그렇다면 구체적으로 기존의 리스트 뷰가 무엇이 부족해서 리사이클러 뷰가 등장하게 되었을까요?
카카오의 김기완님의 발표를 참조해서 말씀드리지면 기존의 경우 핀터레스트와 같은 모양의 뷰를 만드려 한다면
핀터레스트 UI
생김새가 그리드 뷰와 매우 흡사하므로 그리드뷰를 상속받거나 AbsListView 를 상속해서 그리드 뷰의 코드를 참조, 구현하면 쉬울것 같지만 실제로는 그렇지 못합니다. 또한 현재 리스트뷰의 소스코드를 통해 단순히 layoutChildren() 메서드를 오버라이드해서 구현하려하면 막상 코드를 해석하는데 어려움이 많고 접근조차 되지 않는 값들이 있어 결국은 포기하고 원점으로 돌아가게 됩니다. 즉, 뷰 그룹을 상속받아 일일이 구현하게 되는 것이죠. 예를들어 핀터레스트와 비슷하게 뷰를 구현해 주는 유명한 라이브러리인 StaggeredGridView 도 뷰 그룹을 상속 받아 구현되어 있습니다.
애니메이션은 또 어떻습니까? 간단한 아이템 추가나 제거 애니메이션도 라이브러리들이 있긴하지만 간단히 직접 만들려고하면 너무나도 복잡하게 구현해야합니다. 횡 방향의 리스트는요? 도대체 왜! 이렇게 된 걸까요?
원인은 뷰가 담당하는 일이 너무 많아 이런 일들이 발생하는 것 입니다. 이에 레이아웃 배치 , 애니메이션 등의 분리가 필요하게 되었고 리사이클 뷰는 이런 역할을 할 수 있도록 하기 위해 등장한 것입니다.
리사이클러 뷰로 표현 할 수 있는 다양한 형태의 리스트형 뷰, 아래 샘플링크를 통해 실행해 볼 수 있다.
자 이제 리사이클러 뷰를 적용해 볼까요? 먼저 최신 support-v7라이브러리를 다운받아 적용합니다.
이후 xml 에 아래와 같이 RecyclerView 를 선언하고
기존에 getView에서 작업했던 뷰의 생성과 컨텐츠 변경 부분을 2개로 나누어 놓은 것이 인상적이네요. 아마 데이터 변경에 따른 변화와 애니메이션 관련 작업들을 더 용이하게 할 수 있도록 변경한 것 같습니다.
좀 더 다양하고 구체적인 이해를 위해 샘플링크를 통해 구현해 보시면 많은 도움 되실 겁니다.
샘플 :
https://github.com/lucasr/twoway-view / https://github.com/antoniolg/RecyclerViewExtensions
참고로 리사이클 뷰, 카드 뷰, 팔레트 가 V7에 포함되어 있기는 하지면 정식버전이 아니라 그런지 약간의 설정이 필요합니다. 방법은 https://plus.google.com/110116991781365193991/posts/QpXNHKPp3c7 을 참조하세요.
구글 나우에서 사용하는 대표인 Card 모양의 뷰를 표현해 줍니다.
해당 뷰는 프레임 레이아웃을 상속받아 구현되기 때문에 해당 뷰를 사용하셨던것 처럼 사용하시면 됩니다.
레이아웃에서 사용하는 card_view:cardCornerRadius
레이아웃에서 배경색을 구현하는 card_view:cardBackgroundColor
이 있습니다. 해당 속성들의 이름만 봐도 명확하기에 별도의 설명도 필요 없을 것 같네요. 구현 방법은 아래와 같습니다. 참고로 코드상에서는 배경색 변경이 안되니 주의 하세요.
이미지나 카메라를 통해 색을 추출할 수 있는 기능입니다. 아래 영상을 보시면 더 이해가 빠르실 겁니다.
이를 위해 팔레트를 동기 또는 비동기 방식으로 생성하고
해당 앱은 https://github.com/flavienlaurent/livepalette 에서 확인하 실 수 있습니다.
Material에서는 사용자 액션에 따른 피드백에 대한 시각적 애니메이션들을 제공합니다. 이에 Material 테마를 적용했다면 기본적으로 버튼이 눌렸다거나 화면이 전환될때 애니메이션이 보여집니다. 만약에 이러한 효과를 커스터마이징 하고 싶다면 제공되는 API 를 통해 변경하면 됩니다.
액티비티 전환 효과는 크게 enter, exit, shared elements 3가지로 구분됩니다. 단어를 보면 아시겠지만 enter는 등장효과 exit는 퇴장효과 마지막으로 shared elements 는 전환되는 액티비티간의 동일한 컨텐츠가 있을시에 자연스럽게 이어져서 보이게 하는 역할을 합니다. 예를 들면 아래 이미지의 Activity 1의 로봇이 Acivity 2로 전환될때 이미지의 위치와 크기가 변경되면서 Activity 2 의 로봇 이미지로 보이게 되는것이죠.
뷰의 속성에 아래와 같이 셀렉터 속성을 정의하여 간단히 애니메이션을 적용할 수 있습니다.
Material 에서는 상태표시줄 등의 기존에 변경할 수 없는 화면의 컬러를 변경할 수 있게 되었습니다.
Audio playback
- floating-point 포맷을 android.media.AudioFormat.ENCODING_PCM_FLOAT을 통해 지원예정
- 오디오 데이터로 ByteBuffer 를 지원
- WRITE_NON_BLOCKING 옵션을 통해 버퍼링과 다른 앱들과 멀티스레딩이 간소화 됨
해당 기능에 대한 자세한 사항은 AudioTrack 을 참조해주세요.
Media playback control
새롭게 발표한 android.media.session.MediaControllerclass 를 통해 미디어 컨트롤러를 사용할 수 있습니다. 이는 기존의 RemoteControlClient를 대체하며 간단한 이동 컨트롤러 API들을 제공합니다. 이를 통해 쉽게 playback 서비스들을 개발할 수 있게 되었습니다.
이를 통해 플레이백 명령, 미디어 키 그리고 이벤트 등을android.media.session.MediaSession에 전달하는 멀티 컨트롤러를 만들 수 있습니다. 컨트롤러를 더 추가하고 싶다면 MediaSession.getSessionToken()를 통해 access token 를 얻어 앱과 연동하도록 합니다.
MediaController.TransportControls 를 통해 재생, 정지, 뛰어넘기, 별점주기 와 같은 명령을 수행할 수 있습니다. 세션과 연결된 컨트롤러에서 내부적인 미디어 전송 명령을 수행하기 위해 MediaSession.TransportControlsCallback 이 가지고 있는 콜백 메서드를 오버라이드하면 됩니다.
또한 android.app.Notification.MediaStyle 클래스를 통해 media session 에 연결된 플레이백 콘트롤러 알림을 만들 수 있습니다. 새로운 알림과 미디어 API들을 통해 시스템 UI 가 플래이 백에 대해 인지, 앨범아트에 대해 보여줄 수 있게 되었습니다.
Storage
Directory selection
L에서는 확장된 Storage Access Framework 을 통해서 유저가 전체 디렉토리 서브트리를 선택할 수 있게 되었습니다. 이것은 서브트리에 포함된 모든 문서에 대해 읽기 쓰기 권한을 주기 때문에 예전처럼 각각 아이템에 대한 유저의 확인이 필요없어 졌습니다. 즉, 하위까지 이에 대한 권한이 자동 적용되는 것이죠
디렉토리 서브트리를 선택하기 위해 android.intent.action.OPEN_DOCUMENT_TREE 인텐트를 선언한 후 전달합니다. 이를 통해 시스템은 서브트리 선택을 지원하는 DocumentsProvider 의 인스턴스를 보여주어 유저가 디렉토리를 선택하고 검색할 수 있도록 해줍니다. 이에 리턴되는 URI는 선택된 서브트리에 대한 권한을 보여줍니다. 그러면 DocumentsContract.buildChildDocumentsUriUsingTree() , DocumentsContract.buildDocumentUriUsingTree() 와 ContentResolver.query() 을 통해 서브트리를 탐색할 수 있습니다.
새로운 DocumentsContract.createDocument() 메서드는 문서 또는 디렉토리들을 서브트리에 생성할 수 있습니다. 기존에 생성된 문서들에 대해 이러한 사항들을 적용하고 싶다면 DocumentsContract.renameDocument() 와 DocumentsContract.deleteDocument() 을 사용하도록 합니다. DocumentsContract.Document.COLUMN_FLAGS 을 통해 이러한 사항들이 적용될지 확인이 가능합니다.
DocumentsProvider 를 구현하고 서브트리 선택을 지원하고 싶다면 DocumentsProvider.isChildDocument() 을 수행하고 Root.COLUMN_FLAGS에 Documents.Contract.FLAG_SUPPORTS_IS_CHILD 을 포함하도록 합니다.
android.content.Context.getExternalMediaDirs() 을 통해 디바이스의 모든 공유되어 있는 저장소의 경로값을 알아낼 수 있습니다. 또한 기존의 Context.getExternalFilesDir() 와 비슷하게 추가적인 수락 필요없이 리턴된 경로값에 접근할 수 있습니다.
플랫폼은 정기적으로 새로운 미디어에 대해 스캔합니다. 그러나 직접 해당 기능을 사용하고 싶다면 MediaScannerConnection 을 이용하면 됩니다.
Wireless & Connectivity
Multiple network connections
앱은 동적으로 사용가능한 네트워크를 검색하고 자동으로 연결하는 안드로이드 시스템과 함께 작업을 수행할 수 있습니다. 예를 들어 통신사 망과 같은 특정 네트워크에 연결되거나 핸드오프 되었을 경우를 직접 관리하고자 할 때 유용하게 사용할 수 있습니다.
멀티 네트워킹 API 를 지원합니다. 이를 통해 사용가능한 네트워크 중 특정기능을 가진 놈과 연결시킬 수 있습니다.
이런 방식은 특정한 네트워크를 사용할때 유용합니다.예를들어 SUPL 이나 MMS 또는 통신사의 빌링 네트워크나 특정프로토콜을 이용해서 데이터를 전송하고 싶은 경우죠.
- ConnectivityManager 를 생성
- android.net.NetworkRequest 를 생성해서 특정 네트워크 기능과 앱이 사용하고자하는 통신타입을 명시
- 사용가능한 네크워크를 스캔하기 위해 ConnectivityManager.requestNetwork() 또는 ConnectivityManager.registerNetworkCallback()을 호출하고 NetworkRequest 객체와 ConnectivityManager.NetworkCallbackListener 를 전달
이를 통해 네트워크가 연결가능한 네트워크가 검색되면 NetworkCallbackListener.onAvailable() 콜백이 수행되고 해당 네트워크에 연결되어질 것입니다. 이때 android.net.Network object을 통해 추가 정보를 얻거나 선택된 네트워크에 대한 통신이 가능해 집니다.
Bluetooth broadcasting
4.3에서 Bluetooth Low Energy (BLE) 가 소개된바가 있습니다. L에서는 BLE 주변기기 모드가 가능해 졌습니다. 안드로이드 디바이스는 이제 BLE 주변기기 모드(Bluetooth Low Energy peripheral mode)로 동작할 수 있습니다. 어플리케이션은 이 기능을 통해 자신의 존재를 주변으로 브로드캐스트 할 수 있습니다. 예를 들어, 여러분은 만보계나 건강관리 앱을 만들어 다른 BLE 장치로 관련 데이터를 전송할 수 있습니다.
이에 새로운 android.bluetooth.le API를 통해 앱에서 자신의 존재를 브로드캐스트 하고 반응을 스캔하며 주변 BLE 기기와 연결하는 것이 가능합니다. 이러한 기능을 사용하려면 메니페스트에 android.permission.BLUETOOTH_ADMIN 을 선언해야합니다.
BLE를 통해 다른 디바이스가 나를 찾을 수 있도록 하려면 android.bluetooth.le.BluetoothAdvertiser.startAdvisertising() 를 호출하고 android.bluetooth.le.AdvertiseCallback class를 implementation 한 것을 전달합니다. 콜백 객체는 광고 명령이 실패 혹은 성공했는지를 알려줄 것입니다.
L에서는 특정 타입의 디바이스에 대해서만 스캔을 하도록 하는 android.bluetooth.le.ScanFilter class 가 추가되었습니다. 이를통해 BLE 디바이스를 스캔하기 위해 android.bluetooth.le.BluetoothLeScanner.startScan() 을 실행하고 필터들의 리스트를 전달합니다. 메서드를 콜 할때 BLE가 찾아지면 이에 대한 정보를 전달받기 위해 android.bluetooth.le.ScanCallback 을 제공해야 합니다.
NFC enhancements
광범위하고 융통성있는 NFC를 사용할 수 있게 되었습니다.
- 쉐어 메뉴에서 안드로이드 빔을 사용할 수 있게 됨
- callingandroid.nfc.NfcAdapter.invokeBeam()을 통해서 데이터를 공유할 수 있으며 이를 통해 유저가 수동적으로 다른 NFC 기기를 탭해서 데이터 전송을 하는 수고를 덜게 해줌
- android.nfc.NdefRecord.createTextRecord()을 통해 UTF-8 text data를 포함하는 NDEF 기록을 생성할 수 있게 됨
- 결제앱을 개발중이라면
android.nfc.cardemulation.CardEmulation.registerAidsForService() 을
통해 다이나믹한 NFC application ID (AID)등록이 가능해졌으며
android.nfc.cardemulation.CardEmulation.setPreferredService() 를 통해
특정 액티비티가 포그라운드에 있을때 사용해야 하는 card emulation service 을 설정할 수 있음
Power Efficiency
앱이 전원을 적게 소모하며 효율적으로 동작할 수 있도록 새로운 도구와 API 가 제공됩니다. 배터리 사서(Battery historian)는 시간에 따라 전력 소모를 시각화하여 여러분이 앱이 어떻게 전력을 소비하고 있는지 이해할 수 있도록 도와줍니다. 잡 스케줄러(Job Scheduler) 을 통해 개발자 여러분은 어떤 상황에서 어떤 작업들이 수행되어야 하는지 설정할 수 있습니다. 예를 들어 전력 사용량을 최소화 할 수 있도록, 디바이스가 슬립 상태 혹은 무제한 인터넷에 연결된 상태에 따라 서로 다른 동작을 수행하도록 할 수 있습니다. 이러한 저전력 프로젝트의 이름을 볼타라고 부르더군요.
이에 얼마전에 안드로이드 폴리스라는 곳에서 L의 배터리 효율을 테스트했는데요. 그 결과는 기존대비 36% 정도의 향상이 있음을 알 수 있었습니다.
이런 배터리 효율은 구체적으로 어떻게 향상된 것일까요.
Scheduling jobs
안드로이드 L에는 개발자들을 위해서 잡스케줄러 API(JobScheduler API)라는 새로운 기능이 추가되었습니다. 개발자들이 특정 상황에 이루어져야 할 백그라운드 작업을 정의할 수 있죠. 예를 들어서 어떤 앱에 “휴대폰이 충전기에 연결될 때까지 동기화를 하지 말 것”이라거나, “와이파이에 연결되었을 때 매 시간마다 데이터를 수집하라”라고 명령을 내릴 수 있는 것입니다. 지금까지 개발자들은 고생해서 직접 이런 정의를 내릴 수 있었긴 했지만, 기본적으로 현재 상황을 알아내기 위해서 휴대폰을 깨워야만 했습니다.
잡스케줄러 API를 사용하면, 개발자들은 앱이 백그라운드에서 작동할 상황을 알려줘 - 안드로이드 시스템이 해당 상황이라고 판단을 하는 것이기 때문에 - 필요한 작업을 한번에 묶어 실행할 수 있습니다.
즉, L에서는 JobScheduler 라는 API를 통해 각각의 상황에 따라 작업들을 정의해 배터리 수명 최적화를 진행합니다. 다시말하자면 상황에 따라 어떤 작업들을 수행할지 지정할 수 있다는 것 입니다. 이는 다음같은 상황에 유용합니다.
- 사용자가 앱을 사용하고 있지 않을시에는 작업을 미루고 싶은 경우
- 장비가 연결되어 있을때 앱이 동작했으면 하는 경우
- 네트워크 연결이 필요한 작업이 있는 경우 (와이파이 연결 필요)
- 많은 작업을 스케쥴에 따라 순차적으로 실행하고 싶은 경우
android.app.job.JobInfo 객체를 통해 유닛에 대한 작업은 캡슐화되어 지고 스케쥴링의 조건에 의해 정확히 수행되어집니다.
android.app.job.JobInfo.Builder를 통한 스케쥴링 조건 설정에 의해 태스크는 특정 조건을 만족할 경우 수행될 수 있도록 합니다. 예를들어
예를들어 무제한 인터넷을 할 수 있는 상황에 작업을 수행하고 싶다면 다음과 같이 적용하면 됩니다. 저기 조건에 UNMETERED 플래그 부분이 조건입니다. 이외의 조건들도 명시해 놨으니 참조하시면 좋을것 같네요.
JobScheduler 관련해서는 샘플코드가 존재하니 구동해보시면 좋을 듯 합니다.
Developer tools for power measurement
배터리 사용 현황을 알 수 있게 해주는 새로운 개발툴과 API를 제공합니다.
dumpsys batterystats 명령을 통해서 UID를 기준으로 디바이스에서의 배터리 사용 통계데이터를 볼 수 있으며 해당툴은 다음과 같은 기능을 포함합니다.
이밖에도 —help 옵션을 통해서 다양한 옵션들이 어떤것이 있는지 알 수 있습니다. 마지막 충전 기준으로 앱 패키지별 배터리 사용 통계를 보고 싶다면 다음 명령어를 수행하면 됩니다.
$ adb shell dumpsys batterystats —charged <package-name>
안드로이드 L을 설계할 때 구글은 배터리 사서(Battery Historian)라고 부르는 툴을 만들었습니다. 개발자들이 휴대폰의 배터리를 정확히 무엇이 어느 정도로, 얼마나 오래 소모하고 있는지 시각화할 수 있게 해주는 툴입니다. 이 툴을 통해 구글에선 전반적인 배터리 소모를 줄이기 위해서 안드로이드 내부를 수정는데 많은 도움을 주었다고 하네요. 개발자들 입장에선 자신의 앱의 배터리 사용량을 알려주는데에도 도움이 될 것입니다.
배터리 히스토리안 툴은 안드로이드 버그 리포트를 통해서 관련된 이벤트들을 HTML 형식으로 결과를 보여줍니다. 이 툴을 통해 전력 소비 데이터를 시각화 하여 볼 수 있는데 이 툴은 <sdk>/tools 에 존재합니다.
실제론 없…. ㅜ 그래서 historian 구글 프로젝트를 가보았더니 historian.py 파일이 대신 존재하더군요.
툴을 돌리면 이렇게 HTML 파일 형식으로 결과를 볼 수 있습니다.
최적의 결과를 얻기 위해선 먼저 enable full wake lock 으로 설정하고 방해받지 않은 상태에서 Battery Historian 툴을 통해 모니터링 합니다.
해당 툴을 구동하기 위해서는 아래와 같이 명령어를 수행하시면 됩니다.
Printing Framework
Render PDF as bitmap
android.graphics.pdf.PdfRenderer class를 통해서 PDF 문서를
비트맵으로 렌더링 할 수 있게 되었습니다.
이를 위해선 시스템이 출력 가능한 컨텐츠를 작성하도록 검색가능한 ParcelFileDescriptor
을 명시해줘야합니다.
openPage() 을 통해서 렌더링 할 페이지를 얻고 이렇게 얻어진
PdfRenderer.Page 는 render() 을 통해 비트맵으로 변환할 수 있게 되는 것입니다.
또한 추가 파라미터를 통해서 문서의 일부만 비트맵 이미지로 변환할 수 있습니다. (예를들면 줌인 을 하기위한 tiled rendering 을 수행한다.)
Testing & Accessibility
Testing and accessibility improvements
- android.app.UiAutomation.getWindowAnimationFrameStats() andandroid.app.UiAutomation.getWindowContentFrameStats() 을 통해 애니메이션과 컨텐츠에 대한 프레임 정보를 수집 할 수 있게되어 실질적으로 랜더링이 충분히 그리고 자주 그려지고 있는지를 평가할 수 있게되어 유저들에게 자연스러운 화면을 제공.
- 테스트 과정에서 새롭게 발표된 android.app.UiAutomation.executeShellCommand() 을 사용할 수 있게 되었음. 이를 통해 쉘 커멘드를 사용할 수 있게 되었는데 예를들어 디바이스와 연결된 host에서 adb를 실행하는 것과 같은 작업을 수행할 수 있음.
- 접근성 API를 사용하는 서비스와 테스트 툴 ( uiautomator 와 같은 ) 을 통해 정상인 (신체 건강한) 사용자들이 사용하는 화면의 속성에 대한 상세 정보를 가져올 수 있다. 화면의 속성을 가지고 있는android.view.accessibility.AccessibilityWindowInfo 객체 리스트를 얻기 위해서는 android.accessibilityservice.AccessibilityService.getWindows() 을 사용 한다.
- AccessibilityNodeInfo 에서 실행되는 디폴트 혹은 커스터마이징된 액션을 정의하기 위해 android.view.accessibility.AccessibilityNodeInfo.AccessibilityAction 을 사용한다. 이때 AccessibilityNodeInfo 에 있던 기존의 API들을 AccessibilityAction class가 대체한다.
IME
Easier switching between input languages
지구본 아이콘 (언어 전환키) 을 누르면 모든 IME에 대해 쉽게 변경할 수 있습니다. 이러한 기능 InputMethodManager.shouldOfferSwitchingToNextInputMethod() 을 통해 구현합니다.
그러나 IME에 전환 매커니즘이 구현되어 있지 않다면 사용자가 지구본 아이콘을 눌러 다음 IME로 변경하려해도 IME는 선택되지 않습니다. 이러한 매커니즘은 InputMethodManager.switchToNextInputMethod 을 통해 이루어 집니다.
Manifest Declarations
Declarable required features
<uses-feature>의 속성인 ”android.software.leanback”을 통해 TV 기능에 제한이 있는 디바이스와 “android.software.webview” 를 통해 android.webkit.* API을 완전히 지원하지 않는 디바이스에서는 설치되지 않도록 제약을 걸 수 있습니다.
<uses-feature android:name=”android.software.leanback”
android:required=”true” />
FEATURE_WEBVIEW.
android:required=”true” />
'개발자 이야기' 카테고리의 다른 글
| T스토어 인앱SDK, Android 5.0 개발 관련 중요내용 정리 (0) | 2014.11.13 |
|---|---|
| 2014 카드대전 FOR LAUNCHER PLANET (0) | 2014.11.04 |
| Android 5.0에서 T스토어 인앱결제 Custom Permission 문제 해결 (0) | 2014.10.30 |
| Android 5.0 롤리팝에서의 이슈 및 해결 (2) | 2014.10.30 |
| 2014년 12월부터 구버전 In-app 라이브러리의 지원이 종료됩니다. (0) | 2014.09.24 |