1.안드로이드 7.0

2015년 가을 마시멜로 발표 직후부터 안드로이드 N으로 임시 명명되어 1년간 개발되어온 안드로이드 7.0이 누가(Nougat)라는 공식명으로 2016년 8월 22일 릴리즈되었다. 6.0 이후 11개월만의 정식 판올림인 셈인데 1년에 한번꼴로 메이저 업그레이드를 하겠다는 공약을 비교적 잘 지키고 있다.

구글은 간식 이름으로 각 버전에 대한 애칭을 붙이는데 누가는 견과류와 설탕을 버무린 과자의 일종이다. 일각에서는 마시멜로 다음 버전이 누룽지가 될 것이라는 예상이 있었는데 아쉽게도 빗나갔다. 매 버전마다 대규모의 업그레이드가 단행되었는데 7.0에서 어떤 기능이 추가되었는지 하나씩 알아 보자.

1-1.다중창 분할

7.0 버전의 가장 큰 변화는 한 화면에 두 개의 앱을 상하 또는 좌우로 나란히 실행하는 다중창 분할(Split Screen) 기능이다. 모바일 장비는 화면이 좁아 한번에 하나의 앱만 전체 화면에서 실행되는 것이 보통이다. 그러나 7.0부터는 동시에 여러 개의 앱을 띄워놓고 같이 실행할 수 있다. 테블릿은 최대 4개까지 화면을 분할할 수 있으며 더 큰 장비는 자유형식 모드도 지원한다.

다중창을 여는 방법은 간단하다. 하단 메뉴바에서 사각형 모양의 최근 실행 앱 버튼을 길게 누르면 화면이 반으로 분할되며 실행중인 앱 목록이 분할된 화면에 나타난다. 이 중 하나를 선택하면 새로 분할된 화면에 해당앱이 실행된다. 다음은 웹 브라우저를 띄워 놓은 상태에서 계산기를 호출하여 두 개를 동시에 실행하는 모습이다.

 

웹에서 문서를 보다가 계산이 필요할 때 브라우저를 열어 놓은 채로 계산기를 아래쪽에 띄울 수 있어 편리하다. 두 앱 사이의 가로바를 드래그하면 분할 비율을 조정할 수 있되 픽셀 단위로 자유롭게 조정되지는 않으며 일정한 비율이 정해져 있다. 더 넓은 면적이 필요한 앱을 크게 키워 놓고 사용하면 된다.

 

최근 실행앱 버튼을 다시 길게 누르면 분할이 해제된다. 또는 남겨두고 싶은 앱을 최대 크기로 확장해도 효과는 같다. 이 외에 최근 실행앱 버튼을 더블탭하면 이전 앱으로 빠르게 스위칭되는 기능이 추가되어 두 앱을 번갈아가며 쓸 때 편리하다. 두 앱을 왔다 갔다 하는 경우가 많아 굉장히 실용적이다.

다중창의 특별한 예로 PIP(Picture In Picture) 기능도 지원한다. 안드로이드 TV 장비에서 TV 시청중에 조그만 화면을 따로 열어 앱을 구동할 수 있어 영화 감상중에 배우에 대한 정보를 검색해 본다거나 영화의 평점을 남길 수 있다. 두 앱이 동시에 보이므로 앱끼리 드래그 & 드롭하여 데이터를 주고 받을 수도 있다. 앱간의 자료 교환이 더욱 직관적이고 편리해졌다.

다중창 분할 기능은 이전에도 제조사별로 커스텀 구현된 적이 있다. 삼성 갤럭시 시리즈는 이미 다중창 기능을 제공하며 일부앱을 창 모드로 실행할 수도 있다. 그러나 커스텀 기능은 특정 제조사의 기술에 의존하므로 일관적이지 못하고 범용성도 부족했으며 지원하는 앱도 드물었다. 안드로이드 7.0에서 공식적인 API에 포함되었으므로 이제부터 작성되는 모든 앱은 다중창 분할 기능을 지원할 것이다.

이전의 전체 화면 모드에 비해서는 진일보했지만 데스크탑 운영체제의 오버랩 방식과는 달리 앱끼리 공간을 공평하게 나누어 쓰는 타일 방식이라 실용성과 직관성은 떨어진다. 아직까지 데스크탑의 멀티 태스킹 수준을 따라 잡기는 역부족이다. 태생이 모바일 운영체제여서 당분간은 한계가 있지만 멀지 않은 미래에 완벽한 오버랩까지 지원하지 않을까 예상된다.

1-2.절약 모드

이동중에 사용하는 모바일 장비는 언제나 여러 가지 자원이 부족해서 항상 자원을 아껴 써야 한다. 배터리도 부족하고 네트워크 연결시 소모되는 데이터 요금도 비싸다. 안드로이드는 매 업데이트마다 제한된 자원을 아끼는 짠돌이 짓의 강도를 계속 높여 왔으며 이번 버전에서도 여러 가지 자원을 절약할 수 있는 기능을 도입했다.

데이터 절약(Data Saver) 모드는 네트워크 입출력양을 절약한다. 와이파이에 접속할 수 없는 여행중에는 데이터 소모가 많고 월말에는 남은 데이터가 부족하다. 예전에는 사용자가 알아서 과도한 데이터 사용을 줄여야 했으나 이제 시스템과 앱도 절약 모드에 동참한다. 시스템은 설정에 데이터 절약 모드라는 항목을 두고 사용자가 이 항목을 토글하여 선택한다.

이 모드가 켜져 있으면 앱은 데이터를 최소한으로 사용한다. 방법은 여러 가지가 있는데 정말 꼭 필요한 입출력만 수행하는 작전을 쓴다. 당장 필요치 않은 동기화는 금지하고 스트리밍의 질을 떨어뜨리며 웹의 이미지는 영역만 표시한 후 클릭했을 때 확인하는 식이다. 운영체제는 물론이고 기본 앱도 이 모드를 인식한다. 웹 브라우저와 서버는 데이터를 압축해서 주고 받음으로써 패킷양을 최대한 줄인다. 데이터 절약 모드가 켜져 있더라도 기기가 와이파이 환경으로 들어오면 이 모드는 잠시 중단된다.

이 기능 자체가 데이터를 아껴 주지는 않으며 다만 사용자가 데이터를 아껴야 할 상황이라는 옵션만 제공할 뿐이다. 이런 식이면 사실 알아서 사용을 자제하는 것과 별반 차이가 없지만 앱까지 적극적으로 절약에 협조토록한다는 점이 다르다. 데이터가 넉넉한 곳에서는 별 필요가 없지만 인도나 동남아처럼 통신환경이 좋지 않은 나라에서는 이런 절약 도움 기능이 소비자에게 어필하는 면이 있어 판매에 큰 도움이 된다.

배터리도 아주 중요한 자원이다. 6.0에서 졸기 모드를 도입하여 장비를 더 깊은 잠에 빠지도록 함으로써 배터리를 절약했다. 7.0에서는 이 기능을 강화하여 이동중에도 졸기 모드로 들어가 배터리를 더욱 아낀다. 졸기 모드가 도입된지는 좀 오래 되었지만 실제 배터리 성능 향상에는 큰 기여를 하지 못한 것으로 판명되었다. 오히려 졸기 모드일 때는 알람이 오지 않는다거나 꼭 동작해야할 백그라운드 프로세스가 정지하여 프로그래밍이 더 어려워지는 부차적인 문제를 야기하였다. 그러나 장비를 자주 사용하지 않는 사람의 경우 대기 시간이 길어지는 긍정적인 효과는 있다.

Project Svelte 기능은 RAM 사용량을 줄이는 기술이다. 앱이 백그라운드에서 실행되는 방식을 최적화함으로써 배경에서 실행되는 프로세스의 반응성을 높인다. 이 외에도 잘 사용하지 않는 브로드캐스트를 제거하고 스케줄러를 개선하여 메모리 사용량을 지속적으로 감소시키고 있다. 이런 변화가 최종 사용자 눈에는 잘 보이지 않지만 전체적인 성능을 조금씩 향상시키는 효과가 있다.

1-3.알림창 기능 개선

상단바를 드래그하여 아래로 내리면 알림창과 빠른 설정창이 나타나는데 이 영역이 많이 개선되었다. 사용자와 가장 가까운 부분이다 보니 많은 신경을 쓰고 있으며 매번 안드로이드 업데이트때마다 수정 및 확장되고 있다. 이번에는 아예 전체적으로 재설계했다고 발표할 정도로 변화가 많다.

 

■ 묶음 알림 : 비슷한 알림을 묶어 그룹으로 표시하여 한꺼번에 관리한다. 댓글 알림 같은 경우 짧은 시간에 여러 건이 발생할 수 있는데 이런 알림을 묶어서 볼 수 있고 관리하기도 편리하다.

■ 직접 회신 가능 : 알림 상태에서 별도의 앱으로 전환하지 않고 바로 답장을 보낼 수 있다. 문자 메시지 도착시 바로 회신 가능하다. 이전 버전에 커스텀 구현되었던 적이 있는데 이제 공식적으로 도입되었다.

■ 디자인 개선 : 알림 템플릿을 업데이트했으며 사용자 지정 뷰를 사용할 때 알림 헤더나 액선을 활용하여 더 예쁜 장식을 할 수 있다. MessageStyle 클래스로 UI 레이블을 마음대로 지정할 수 있다.

■ 알림 중요도 설정 : 아주 긴급한 알림을 최우선으로 지정해 놓으면 무음 상태에서도 알림을 받을 수 있다.

알림창은 빠른 설정 기능을 제공하는데 이 기능도 대폭 보강되었다. 자주 사용하는 설정을 알림창에 직접 노출해 놓음으로써 설정창을 열지 않고도 바로 확인 및 변경할 수 있다. 더 넓은 공간을 할당하고 좌우로 스와이프하여 수많은 타일을 둘 수 있다. 빠른 설정 편집모드에서 타일을 드래그하여 원하는 위치로 옮길 수 있으며 추가, 삭제도 물론 가능하다.

빠른 설정을 위한 API를 추가하여 사용자도 빠른 설정용 앱을 정의할 수 있다. 이 기능은 설정을 위한 의도로 도입된 것이므로 프로그램 실행용으로 사용하는 것은 권하지 않는다.

1-4.3D 기능 강화

모바일 게임의 인기가 갈수록 높아짐으로 인해 3차원 그래픽 기능도 지속적으로 보강되고 있다. OpenGL ES는 3.1에서 3.2로 업그레이드되었으며 다음 기능을 추가 제공한다.

 

■ Android 확장팩(AEP) 중 EXT_texture_sRGB_decode를 제외한 모든 기능 지원

■ HDR, 지연 셰이딩을 위한 부동소수점 프레임 버퍼

■ BaseVertex 그리기 호출로 일괄처리 및 스트리밍 향상

■ WebGL의 오버헤더 감소를 위한 버퍼 액세스 제어

 

또한 이번 버전에서는 OpenGL을 대체하기 위한 새로운 3D 엔진인 벌컨(Vulkan)을 새로 지원한다. OpenGL은 25년간 오픈 소스 그래픽 라이브러리의 표준으로 군림해 왔으며 지금도 현역으로 활약하고 있다. 그러나 고수준 라이브러리여서 성능상의 약점이 있으며 모바일은 석권했지만 PC 환경에서는 아직 제 역할을 하지 못하고 있다.

이에 크로노스 그룹은 2014년 8월부터 차세대 표준 그래픽 라이브러리인 벌컨을 만들어 왔다. OpenGL과는 달리 저수준 라이브러리여서 CPU 오버헤더가 적으며 앱이 GPU를 직접 제어함으로써 OpenGL 대비 최대 10배까지 성능이 향상되었다. 저수준이다 보니 성능은 좋지만 배우기는 더 어렵고 사용하기도 까다롭다.

벌컨은 크로스플랫폼을 지향하며 현재 모든 하드웨어와 운영체제에 속속 안착하고 있다. 구글도 애초에 벌컨의 지원을 약속하여 그 첫 성과가 7.0에서 나타나기 시작했으며 알만한 회사는 모두 벌컨을 적극 지원하고 있다. 단, 애플만이 유독 자사의 그래픽 라이브러리인 메탈을 사용하고 있어 모든 플랫폼을 다 석권하기는 어려워 보인다.

앞으로도 OpenGL은 계속 사용되겠지만 극도의 성능을 필요로 하는 게임에는 어울리지 않아 앞으로는 벌컨이 사용될 전망이다. 최신 라이브러리인만큼 벌컨을 제대로 지원하기 위해서는 하드웨어부터 제대로 받쳐 줘야 하며 현재 시점에서 벌컨을 제대로 지원하는 장비는 갤럭시 S7, Nexus 6P 정도에 불과하다. 결국 벌컨은 아직까지는 현재형이 아니며 미래의 기술이라고 할 수 있다. 벌컨에 대한 더 많은 정보는 다음 사이트를 참조하자.

 

https://www.khronos.org/vulkan/

 

가상 현실(VR) 기능도 지속적으로 발전하고 있는 분야이다. 안드로이드 7.0은 더 향상된 가상 현실 플랫폼인 데이드림을 지원한다. 가상 현실은 소프트웨어만으로 구현할 수 없으므로 헤드셋과 컨트롤러 등의 최신 하드웨어가 필요하며 또한 USB C 단자와 고성능 API까지 받쳐 줘야 한다. 현재까지 발표된 폰 중에는 유일하게 넥서스 6P만 이 기능을 지원한다. 2016년 연말에 여러 제조사에서 데이드림 지원 스마트폰을 출시할 계획이며 관련 컨텐트 제작도 활발하다.

1-5.성능 향상

운영체제가 업그레이드될 때마다 성능 향상을 위해 많은 노력을 기울이고 있다. 주로 자바 언어의 컴파일 방식을 변경함으로써 성능을 개선시키는데 5.0에서 ART를 도입하여 네이티브 코드를 바로 실행함으로써 극적인 성능 향상을 이루었다.

7.0에서는 프로파일링 기능을 내장한 JIT 컴파일러를 도입하여 자주 사용되고 중요한 메서드를 판별, 미리 컴파일해 놓는 방식을 사용한다. 컴파일된 네이티브 코드를 캐시함으로써 호출 속도가 빨라지고 실행 속도도 개선되었다. 뿐만 아니라 당장 필요하지 않는 부분은 컴파일하지 않음으로써 메모리와 배터리도 절약한다.

컴파일 방식의 변경으로 인해 앱 설치 속도가 비약적으로 향상되었다. 설치할 때 한꺼번에 컴파일하는 것이 아니라 일단 복사만 해 두고 꼭 필요한 부분만 부분적으로 컴파일하기 때문에 순식간에 설치된다. 게임같은 대용량 앱은 분 단위의 시간이 소요되었는데 이제는 최악의 경우에도 10초내로 설치 완료된다.

시스템 업데이트시 변경된 라이브러리에 맞게 설치된 모든 앱을 완전히 다시 컴파일함으로써 최적화 시간이 10분을 넘기기도 했다. 업데이트 시간이 이렇게 오래 걸리다 보니 사용자들이 업데이트를 회피하고 미루는 경향이 있었다. 그러나 이제는 시스템을 업데이트해도 전체 앱을 일괄 컴파일하지 않으므로 신속하게 처리된다.

또한 운영체제 업데이트를 위해 두 개의 파티션을 번갈아 사용하는 정책을 채택했다. 파티션이 나누어져 있으면 사용자의 작업을 전혀 방해하지 않고 백그라운드에서 미사용 파티션에 업데이트를 설치한 후 다음 부팅할 때 파티션을 바꿈으로써 순식간에 업데이트할 수 있었다. 단, 이 기능이 가능하려면 두 개의 물리적인 파티션이 있어야 하므로 기존 스마트폰에는 사용할 수 없으며 새로 출시되는 폰부터 적용된다.

구글은 5.0 이후 지속적으로 성능 향상을 꾀하였으며 여러 가지 정책이 효과를 거두어 매 업데이트시마다 달라진 모습을 보이기는 했었다. 그러나 성능 향상폭이 두드러지지 않아 사용자가 실감하기는 어려운 측면이 있다. 또한 성능이 향상되는 부분이 있는 반면 기능이 추가됨으로 무거워지는 부분도 있어 향상도가 상쇄되기도 한다. 다행인 것은 하드웨어가 계속 발전하고 있어 확실히 성능 향상을 체감할 수 있다는 점이다.

1-6.기타 개선 사항

다음은 자잘한 개선 사항이다. 굵직한 업그레이드 외에도 꽤 많은 기능이 새로 도입되어 시도되고 있다.

번호 차단 기능

번호 차단 기능은 원치 않은 사람, 예를 들어 사귀다 헤어진 스토커 등으로부터의 연락을 방지하는 기능이다. 원래 전화나 문자 등의 개별앱이 지원하거나 아니면 별도의 차단 앱을 사용했었는데 이제는 운영체제가 차단 목록을 통합적으로 관리한다. 중앙에서 목록을 관리하니 개별 앱이 목록을 유지할 필요가 없으며 일관된 관리가 가능하다. 또한 장비 교체 시 백업과 복원 기능에 의해 차단 목록이 영구적으로 저장된다는 이점이 있다. 한번 차단은 영원한 차단이다.

다중 언어 지원

모국어 뿐만 아니라 여러 개의 언어를 선택해 놓을 수 있다. 이렇게 되면 두 가지 언어로 동시에 표시하거나 불필요한 번역을 하지 않는다. 예를 들어 한국어와 독일어로 두 개의 언어를 선택해 놓으면 독일어 웹 페이지를 굳이 한국어로 번역할 필요가 없다. 다중 언어를 지원하게 됨으로써 언어 리소스를 확인하는 방법에 약간의 변화가 있다.

접근성 향상

안드로이드의 장애자 지원 기능도 점점 완성되어 가고 있으며 매 버전마다 많은 신경을 쓰고 있다. 7.0부터는 설치 단계에서부터 장애자를 지원하여 처음부터 접근성 조정을 할 수 있다. 시력이 나쁜 사람을 위해 화면 밀도를 조정할 수 있도록 하여 자신의 시력에 맞게 PPI를 맞춰 사용하면 된다. PPI를 높이면 작은 크기로 많은 양을 볼 수 있고 PPI를 낮추면 많이 볼 수는 없지만 글자 크기가 커진다. 노안 사용자는 PPI를 떨어뜨려 화면을 더 편하게 볼 수 있다. 설정창의 접근성 페이지를 보면 장애자를 위해 필요한 거의 모든 기능을 다 제공함을 알 수 있다.

 

TV 녹화 기능

녹화 API를 제공하여 안드로이드 TV의 컨텐트를 동영상으로 녹화하고 재생한다. 예약 녹화해 놓고 천천히 프로그램을 감상할 수 있다.

서명 방법 업그레이드

서명은 APK 파일의 무단 변경을 방지하기 위해 제작자를 명확하게 밝히는 기능이다. 7.0에서는 서명 방법을 v2로 업그레이드하여 설치 시간을 줄이고 보안을 더욱 강화하였다. 안드로이드 스튜디어 2.2 이상은 v2 방식으로도 서명할 수 있으며 기존의 서명 방법도 여전히 사용할 수 있다. v2가 아직 완전히 정립되지 않아 기존 서명 방식이 여전히 필요한데 build.gradle파일의 서명 구성에 v2SigningEnabled false 문을 삽입하면 기존 서명 방식을 계속 사용한다.

범위 제한 디렉토리 액세스

외부 저장 장치를 읽는 READ_EXTERNAL_STORAGE 퍼미션은 전체 SD 카드를 다 읽을 수 있어 보안상 위험하다. 이 퍼미션을 사용하는 대신 특정 위치만 액세스하는 새로운 API를 사용하면 보안이 향상되며 액세스 방식도 단순화된다.

나이트 비전

화면의 청색을 제한하여 시력을 보호하는 기능이다. 청색이 시력에 많은 자극을 주는데 이를 제한하면 물빠진 색감이 되지만 독서할 때 눈이 편안하다. 이와 유사하게 나이트 모드는 밝기와 색조를 바꾸어 어두운 곳에서 화면을 볼 때 눈부심을 방지한다.

이모티콘 추가

추가 이모티콘을 도입하였다. 사람의 얼굴의 피부 색조를 선택할 수 있으며 컬러나 흑백으로 변형할 수 있다.

자바 8 지원

이전 버전에는 자바 7 언어를 사용했으나 안드로이드 7.0부터는 자바 8을 지원한다. 복잡한 이벤트 핸들러 지정문을 람다식으로 간편하게 기술할 수 있어 편리하다. 그러나 자바 8 언어의 모든 문법을 사용하려면 빌드 스크립트를 수정해야 하는 번거로움이 있어 아직까지 대중화하기는 조금 이르다.

잠금 화면에 신상 표시

잠금 화면에 환자의 혈액형이나 주요 병력 등을 기록해 놓는 기능이 도입되었다. 실신이나 심장마비 등의 긴급한 상황에도 의료진이 이 정보를 보고 응급 조치를 취할 수 있다. 치매 노인아니 아동에도 이 기능이 유용하다.

 

이 외에도 가상 파일, 폴더 암호화 등의 여러 가지 기능이 도입되었으며 부분 부분 개선된 기능이 많다. 여러 가지 개선 사항이 있었지만 여전히 완성도는 떨어진다. 구글은 전통적으로 레퍼런스 기기를 발표하면서 새 운영체제를 같이 릴리즈했지만 이번에는 운영체제를 먼저 내 놓고 지원 장비인 구글 픽셀과 픽셀XL은 아직도 제작중이다. 차후 7.1로 릴리즈하겠다고 선언했는데 이는 7.0 버전이 공식적으로 베타 버전임을 자인한 셈이다.

구글의 운영체제는 과거부터 x.0은 항상 다량의 버그를 품고 있었으며 여러 가지 말썽을 일으켰다. 현재 발표된 SDK도 에뮬레이터가 수시로 기절하는 버그가 있으며 API 자체도 완벽하지 않다. 심지어 공식 도움말은 아직도 N Prieview라고 되어 있는데 이건 정말 무성의함의 극치를 보여주는 행태다. 조만간 안정화 버전인 7.1이 나올 것이며 그때나 되어야 쓸만해질 것이다.

2.설치

2-1.업그레이드

새로운 운영체제가 나왔으니 SDK도 당연히 업데이트해야 한다. 처음부터 새로 설치하는 것은 본서에 이미 상세하게 다루고 있으므로 여기서는 이미 설치된 상태에서 개발툴과 라이브러리를 업그레이드해 보자. 2016년 1월 초에 설치한 상태에서 업그레이드하는 예를 보이되 중간 중간에 업그레이드를 했다면 대상 버전이 다를 수도 있다. 그러나 전체적인 업그레이드 과정은 거의 유사하다.

먼저 주 개발툴인 안드로이드 스튜디오부터 업데이트한다. 본서 출판 시점에 버전 1.5였었는데 그간 꾸준히 업그레이드되었다. 스튜디오를 열고 Help/Check for update 항목을 선택하면 현재 버전과 최신 버전에 대한 정보를 보여 준다.

현재 설치된 버전은 1.5.1이고 최신 버전은 2.1.3이라는 뜻이다. 앞 자리 숫자가 바뀌었으니 당장 업그레이드하는 것이 좋다. Update and Restart 버튼을 누르면 변경된 부분에 대해 패치를 수행한다.

전체를 다 받는 것이 아니고 변경이 필요한 부분에 대해서만 업데이트를 수행하므로 속도는 빠른 편이다. 그러나 너무 오랜만에 하는 업그레이드라 약간의 시간이 걸렸다. 패치가 완료되면 스튜디오가 다시 시작된다.

이전 버전의 설정을 그대로 유지할 것인가를 물어 보는데 클린 설치하는 것이 아니므로 특별한 사유가 없는 한 가져오는 것이 편리하다. 스튜디오 실행 후 플러그인을 업데이트하라는 알림 메시지가 나타난다. 이 메시지의 링크를 누르거나 아니면 잠시 기다리면 그래들과 플러그인을 업데이트하라는 대화상자가 나타난다.

플러그인은 개발툴보다 업데이트 주기가 더 짧다. 스튜디오는 실행할 때마다 구성 요소의 버전을 점검하여 필요할 경우 업데이트 버전이 있음을 알려 준다. Update 버튼을 누르면 재시작없이 백그라운드에서 업데이트를 완료한다.

다음은 새 운영체제용의 SDK를 설치한다. 설정창에서 직접 업데이트할 수도 있지만 스튜디오가 실행중인 상태에서는 사용중인 파일을 업데이트하지 못하므로 독립형 SDK 관리자를 여는 것이 좋다. 메뉴의 Tools/Android/SDK Manager 항목을 선택하면 현재 설치 상황을 보여준다.

새로 발표된 7.0 API 전체와 6.0, 5.x SDK에 대한 업데이트가 있다. 권장 항목은 가급적 다시 설치하는 것이 좋으며 추가로 더 설치할 항목은 체크한다. Install 버튼을 누르면 설치가 시작된다. 꽤 오랜 시간이 걸리는데 일부 업데이트는 네트워크 사정으로 인해 실패할 수도 있다. 이럴 때는 다시 시도하면 되는데 구글 제품은 원래 안되던 것도 Retry하면 되는 경우가 종종 있다.

여기까지 업데이트하면 7.0 SDK를 사용할 수 있다. 아직 발표 초기이다 보니 안정화되지 않아 수일에 한번씩 패치가 발표되므로 주기적으로 업데이트를 관리해야 한다. 다음은 업데이트한 지 일주일 후의 상황이다. 그 짧은 기간에 또 새로운 개정판이 나왔다. 이럴 때마다 고민할 것 없이 그냥 업데이트 버튼을 눌러 주면 된다.

이런 잦은 업데이트가 구글 개발툴의 장점이자 단점이다. 업데이트가 신속하다는 점은 장점이지만 좀 귀찮은 면이 있다. 정밀하게 테스트하지 않고 너무 성급하게 릴리즈해 놓고 문제가 생기면 즉시 패치하는 방식이다. 수시로 점검해 보는 수밖에 없다.

2-2.에뮬레이터 등록

운영체제가 새로 발표되었어도 아직 실제 장비를 만져 볼 수는 없다. 이럴 때는 에뮬레이터로 새 장비를 만들어 살펴 보면 된다. Tools/Adnroid/AVD Manager 항목을 선택한다. 해상도가 낮은 Nexus S를 선택하고 SDK는 레벨 24로 선택한다. 나머지 옵션은 적당히 취향에 따라 고른다.

 

HAXM을 업데이트하라는 메시지가 뜨면 시키는대로 한다. 하드웨어 가속 처리를 위해 최신 버전으로 바꿔 주어야 한다. 에뮬레이터를 만든 후 실행 버튼을 누르면 누가 버전의 에뮬레이터가 실행된다.

배경이 분홍색으로 바뀌어 전 버전과 확연하게 구분된다. 에뮬레이터지만 하드웨어 가속 기능을 사용하여 속도가 빠르고 동작이 부드럽다. 화면이 너무 넓으면 개발 모니터를 많이 차지하여 부담스러우니 800 * 480 정도의 해상도가 개발 실습용으로 적합하다. 그러나 예전 장비는 최근실행앱 버튼이 없어 다중창 분할을 테스트하기 어렵다. 이런 목적으로 최신 레퍼런스폰인 Nexus 6P 용의 에뮬레이터를 하나 더 만들었다.

에뮬레이터는 공짜이므로 필요할 때마다 수시로 만들어 사용하면 된다.

2-3.새 프로젝트 생성

모든 개발툴이 제대로 설치되었는지 새 SDK로 프로젝트를 만들어 보자. File/New Project 항목을 선택하고 프로젝트 이름은 NougatFirst로 입력한다.

API 레벨은 최신인 24로 선택한다. 실제 프로젝트에서는 5.0 정도가 적합하지만 지금은 새 SDK를 구경해 보는 중이므로 최고 높은 레벨을 선택했다.

액티비티는 Empty Activity로 선택하고 나머지 옵션은 디폴트를 받아들인다. MainActivity의 프로젝트 템플릿은 거의 변화가 없다.

 

<?xml version="1.0" encoding="utf-8"?>

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"

    xmlns:tools="http://schemas.android.com/tools"

    android:layout_width="match_parent"

    android:layout_height="match_parent"

    android:paddingBottom="@dimen/activity_vertical_margin"

    android:paddingLeft="@dimen/activity_horizontal_margin"

    android:paddingRight="@dimen/activity_horizontal_margin"

    android:paddingTop="@dimen/activity_vertical_margin"

    tools:context="kr.soen.nougatfirst.MainActivity">

 

    <TextView

        android:layout_width="wrap_content"

        android:layout_height="wrap_content"

        android:text="Hello World!" />

</RelativeLayout>

==========

package kr.soen.nougatfirst;

 

import android.support.v7.app.AppCompatActivity;

import android.os.Bundle;

 

public class MainActivity extends AppCompatActivity {

 

    @Override

    protected void onCreate(Bundle savedInstanceState) {

        super.onCreate(savedInstanceState);

        setContentView(R.layout.activity_main);

    }

}

 

렐러티브 레이아웃 안에 텍스트 뷰 하나가 있고 여기에 짧은 문자열이 출력되어 있다. 실행해 보자.

마법사가 만든 기본 프로젝트이니 별다른 에러 없이 잘 컴파일되고 잘 실행된다.

2-4.AndExam 프로젝트

전판의 예제인 AndExam을 불러와 실행해 보자. 배포 파일인 AndExam6-151222.zip을 다운로드받아 적당한 곳에 압축을 풀어둔다. 그리고 File/Open 명령으로 AndExam6 폴더를 선택한다.

프로젝트의 덩치가 워낙 커 읽어 들이는데 다소 시간이 걸리지만 단 하나의 에러도 없이 잘 컴파일되며 새 에뮬레이터에 실행도 잘된다.

SDK가 새로 바뀌면 이전의 API가 폐기되는 경우도 종종 있는데 이번 버전에는 하위 호환성을 철저하게 잘 유지하고 있어 예제를 실행하는데 아무런 문제가 없다.

3.SDK 7.0 API

3-1.다중창 지원

다중창 분할 기능은 굉장한 혁신이지만 다행히 프로그래밍 방법은 변화가 많지 않다. 7.0 이전에 작성된 앱도 다중창 모드에서 실행하도록 시스템은 앱의 크기를 강제로 조정하여 분할 상태에서 실행 가능하다. 그러나 앱이 고정 방향을 사용하는 경우, 크기 조정에 적절하게 반응하지 않는 경우는 비정상적인 동작을 할 수도 있다. 가급적이면 이전 앱도 7.0을 타겟으로 다시 빌드하고 다중창 분할에 대비하도록 업데이트하는 것이 좋다.

한번에 하나의 앱이 실행되던 환경에 비해 액티비티의 라이프사이클에 약간의 변화가 생겼다. 전에는 배경으로 숨으면 액티비티가 가려지며 앱이 정지되었지만 이제는 이중으로 분할되면 비활설 상태로 사용자에게 보이는 상태가 된다. 이때 앱은 일시 정지된 상태의 최상위로 간주되며 당장 사용자를 대면하지 않더라도 화면에 보이므로 배경의 다른 액티비티보다 더 높은 우선순위를 가진다.

구형 앱의 라이프 사이클을 특별히 수정할 필요는 거의 없다. 그러나 비활성 상태에서도 계속 동작하는 앱은 약간의 수정이 필요하다. 예를 들어 동영상 플레이어는 비활성중에도 계속 동영상을 재생해야 한다. 이전에는 onPause에서 재생을 정지하는 것이 적합했지만 이제는 일시 정지 상태에서도 사용자 눈에 보일 수 있으므로 onStop에서 정지하는 것이 더 적합하다.

다중창 지원 여부는 앱의 메니페스트에 지정한다. 루트 액티비티에 관련 속성을 적용하면 하위의 모든 액티비티에 일괄적으로 적용된다. 관련 속성은 다음과 같다.

 

resizeableActivity

activity 노드나 applictaion 노드에 true 또는 false로 지정한다. 이 값이 true이면 화면 분할 모드, 자유형식 모드로 시작할 수 있으며 false이면 항상 전체 화면을 차지한다. 디폴트는 true이다.

 

supportsPictureInPicture

PIP 모드를 지원할 것인가 아닌가를 지정한다. PIP 모드는 화면 분할의 특수한 예이므로 resizeableActivity 속성이 true일 때만 적용된다.

 

화면 분할 방식의 좀 더 상세한 속성은 activity의 서브 엘리먼트인 layout의 다음 속성으로 지정한다.

 

속성

설명

defaultWidth

자유형식 모드에서의 기본 너비

defaultHeight

자유형식 모드에서의 기본 높이

gravity

자유형식 모드에서 창의 최초 배치 위치

minimalHeight

액티비티의 최소 높이

minimalWidth

액티비티의 최소 너비. 이 크기 이하가 되면 최소 크기로 맞춘다.

 

앞서 만들었던 NougatFirst 예제의 메니페스트를 보면 화면 분할에 대한 별다른 지정이 없다.

 

<application

    android:allowBackup="true"

    android:icon="@mipmap/ic_launcher"

    android:label="@string/app_name"

    android:supportsRtl="true"

    android:theme="@style/AppTheme">

    <activity android:name=".MainActivity">

        <intent-filter>

            <action android:name="android.intent.action.MAIN" />

 

            <category android:name="android.intent.category.LAUNCHER" />

        </intent-filter>

    </activity>

</application>

 

이 경우 resizeableActivity 속성의 디폴트값인 true가 적용되어 다중 분할이 가능하다. 즉, 안드로이드 7.0을 타겟으로 만든 앱은 별다른 조치를 취하지 않더라도 기본적으로 다중 분할이 가능한 셈이다.

마법사로 만든 예제가 웹브라우저와 함께 아래 위로 잘 열린다. 만약 반드시 전체 화면을 독차지해야 하는 앱이라면 메니페스트에 다음 속성을 지정한다. 예를 들어 게임은 전체 화면이 꼭 필요하며 다중창과는 어울리지 않는다.

 

<application

    android:resizeableActivity="false"

    android:allowBackup="true"

 

이 속성을 지정해 두면 최근 실행앱 버튼을 길게 눌러도 화면이 분할되지 않으며 다음 토스트가 나타난다. 이런 앱은 전체 화면으로만 실행된다.

다중창 모드로 들어가거나 나올 때 시스템은 앱에게 신호를 보내 주는데 화면의 방향이 바뀐 경우와 유사하다. 분할에 의해 액티비티의 크기가 바뀌므로 이 변화에 맞게 반응하면 된다. 앱은 자신의 크기가 바뀌면 적합한 리소스를 로드하고 액티비티를 다시 생성함으로써 변화된 크기에 자신을 맞추는데 이 전략대로만 동작하면 된다.

분할창 드래그에 의해 액티비티의 크기가 변경될 때도 비슷한 절차로 액티비티에게 신호를 보낸다. 새로 드러나는 부분은 windowBackground 속성이 지정한 색으로 임시적으로 채워지며 이후 액티비티가 내용물을 그린다. 크기 변경 외에 좀 더 분명한 신호를 받고 싶다면 콜백 메서드를 처리한다. 액티비티가 다중창 모드나 PIP 모드로 전환할 때 다음 콜백 메서드가 호출된다.

 

void onMultiWindowModeChanged (boolean isInMultiWindowMode)

void onPictureInPictureModeChanged (boolean isInPictureInPictureMode)

 

다중창 모드로 들어갈 때 인수로 true가 전달되며 모드가 해제될 때 false가 전달된다. 다중창 상태에서 완전히 다르게 동작하고 싶다면 이 콜백에서 관련 처리를 수행한다. PIP 모드가 true라면 다중창 모드는 자동으로 true이다. PIP 모드로 전환하려면 다음 메서드를 호출한다.

 

void enterPictureInPictureMode ()

 

현재 상태를 알고 싶을 때는 다음 두 메서드를 호출한다. 현재 상태를 조사하여 true 또는 false를 리턴한다.

 

boolean isInMultiWindowMode ()

boolean isInPictureInPictureMode ()

 

이상의 콜백과 메서드는 프레그먼트에도 동일한 버전이 제공된다. 새로운 액티비티를 띄울 때 옆에 인접한 상태로 띄우려면 인텐트에 FLAG_ACTIVITY_LAUNCH_TO_ADJACENT 플래그를 지정한다. 상황에 따라 달라지지만 시스템은 가급적이면 주 액티비티 근처에 새로운 액티비티를 띄우려고 노력한다. 단, 화면 분할 상태가 아니면 이 플래그는 아무런 영향을 미치지 않는다.

두 개의 액티비티가 동시에 보이는 상황이 되다 보니 액티비티끼리 드래그 앤 드롭을 통해 데이터를 주고 받을 수 있다. 이 기능을 위해 View 클래스의 기능이 약간 확장되었는데 다음과 같은 속성과 메서드가 추가되었다.

 

메서드

설명

startDragAndDrop()

드래그를 시작하며 View.DRAG_FLAG_GLOBAL 플래그를 전달하면 액티비티간에 드래그가 시작된다.

cancelDragAndDrop()

드래그를 시작한 앱에서 작업을 취소한다.

updateDragShadow()

드래그 중의 그림자를 업데이트한다.

requestDropPermissions()

드래그되는 컨텐트의 URI 권한을 요청한다.

DragAndDropPermissions

드롭받을 앱의 권한 지정을 위한 토큰 객체

 

앱이 다중창 모드에서 실행될 때는 화면을 독점적으로 사용하는 것이 아니므로 일부 기능을 사용할 수 없다. 예를 들어 상태 표시줄을 숨길 수 없으며 screenOrientation 속성의 변경은 무시된다.

3-2.데이터 절약 모드

데이터 절약 모드를 위해 시스템이 직접 처리해 주는 것은 많지 않다. 다만 중앙 설정에 옵션을 두고 이 옵션이 선택되었을 때 앱이 자발적으로 데이터를 아끼도록 유도하는 정도이다. 앱은 ConnectivityManager 시스템 서비스의 getRestrictBackgroundStatus() 메서드로 현재 데이터 절약 상태를 조사하며 다음 중 하나의 값이 리턴된다.

 

리턴값

설명

RESTRICT_BACKGROUND_STATUS_DISABLED

절약 모드 비활성화 상태이다.

RESTRICT_BACKGROUND_STATUS_ENABLED

이 앱이 절약 모드로 설정되었다.

RESTRICT_BACKGROUND_STATUS_WHITELISTED

절약 모드로 설정되었이지만 이 앱은 허용 목록에 추가되어 있다.

 

네트워크 상태를 조사하려면 ACCESS_NETWORK_STATE 퍼미션이 필요하다. 절약 모드에서도 데이터 사용이 꼭 필요하다면 앱의 패키지 이름 URI를 포함하여 다음 인텐트를 보낸다.

 

Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS

 

그러면 설정앱이 열리고 사용자가 예외를 허용해 줄 것인가를 결정한다. 앱은 이 값을 읽어 보고 자신의 데이터 사용량을 결정하며 설사 예외에 포함되었더라도 최대한 데이터를 아껴야 한다.

데이터를 어떻게 절약할 것인가에 대해서는 정해진 규칙이 없다. 앱 스스로 판단하여 과도한 데이터 사용을 자재하면 된다. 다음 예제는 네트워크에서 이미지 파일을 받아 보여주는 흉내를 낸다.

 

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"

    android:orientation="vertical"

    android:layout_width="match_parent"

    android:layout_height="match_parent"

    >

    <Button

        android:id="@+id/btn"

        android:layout_width="wrap_content"

        android:layout_height="wrap_content"

        android:onClick="mOnClick"

        android:text="사진보기"

        />

    <TextView

        android:id="@+id/result"

        android:layout_width="wrap_content"

        android:layout_height="wrap_content"

        android:text="결과 보기"

        />

</LinearLayout>

==========

public class MainActivity extends Activity {

 

    @Override

    protected void onCreate(Bundle savedInstanceState) {

        super.onCreate(savedInstanceState);

        setContentView(R.layout.activity_main);

    }

 

    public void mOnClick(View v) {

        TextView result=(TextView)findViewById(R.id.result);

        ConnectivityManager cm = (ConnectivityManager)getSystemService(Context.CONNECTIVITY_SERVICE);

        int backgroundStatus = cm.getRestrictBackgroundStatus();

 

        switch (backgroundStatus) {

            case ConnectivityManager.RESTRICT_BACKGROUND_STATUS_WHITELISTED:

            case ConnectivityManager.RESTRICT_BACKGROUND_STATUS_DISABLED:

                result.setText("고해상도의 멋진 사진을 보여 줍니다.");

                break;

            case ConnectivityManager.RESTRICT_BACKGROUND_STATUS_ENABLED:

                result.setText("저해상도 사진을 대충 보여 줍니다.");

                break;

        }

    }

}

 

버튼을 누르면 원격지의 이미지를 읽어와 화면에 표시한다고 하자. 아무런 제약이 없다면 이미지를 다운로드받아 화면에 뿌리기만 하면 된다. 그러나 데이터 절약 모드라면 대용량의 이미지를 받는 대신 화질이 떨어지는 저용량의 이미지를 받는 방식으로 통신량을 줄일 수 있다.

버튼 클릭 이벤트 핸들러에서 현재 데이터 절약 모드를 읽는다. 그리고 이 상태에 따라 어떤 이미지를 받을 것인지 결정하여 그 결과를 아래쪽의 텍스트 뷰에 출력했다. 어떤 선택을 했는지 결과만 출력해 봤는데 실제로 다운로드를 받는다면 이미지의 URL이 달라질 것이다.

그냥 실행하면 고해상도의 사진을 다운로드받는 것으로 나타난다. 그러나 설정에서 데이터 절약 모드를 변경하면 앱의 동작이 달라진다.

Data saver 옵션의 디폴트는 Off인데 이 값을 On으로 변경해 보자. 그리고 앱을 다시 실행하여 사진보기 버튼을 누르면 저해상도의 이미지를 대신 보여 준다.

실제 프로젝트의 네트워크 입출력 코드는 데이터 절약 모드에 따라 데이터 사용량을 결정해야 한다. 아예 사진 대신 텍스트로 보여줄 수도 있고 데이터 절약 모드여서 보여 줄 수 없다는 메시지를 띄울 수도 있다.

 

이상으로 안드로이드 7.0 누가에 대한 업그레이드와 새로 추가된 주요 API에 대해 알아 보았다. 더 많은 기능이 추가되었지만 아직까지는 안정성이 떨어져 원활한 탐구가 어려운 면이 있었다. 특히 에뮬레이터가 너무 자주 다운되는데 다음 버전에서는 많이 개선될 것이다. SDK가 7.1이나 7.2로 안정화되면 추가된 API에 대한 강좌를 더 제공할 예정이다.