안드로이드 CTS 이야기

안드로이드 새 버전 Nougat를 다뤄보면서 만난 CTS관련 에피소드를 이야기해볼까 한다.

CTS(The Compatibility Test Suite)는 안드로이드 장치가 반드시 지켜야하는 규약이나 양식에 대한 테스트케이스(이하 TC) 집합 프로그램이다. 그래서 안드로이드 장치 제조사는 필연적으로 CTS를 통과해야만 한다. 이 역시 AOSP에서 오픈 소스 형태로 운영/개발되고 있지만 TC를 수정하려면 구글 개발자의 리뷰를 반드시 거쳐야 하므로 구글의 강제사항이라고 봐도 무방하다.

CTS는 안드로이드가 추구하는 방향의 길잡이 역할을 한다고 생각해도 좋다.  예를 들어, 특정 API를 강제하거나 제한하고 싶은 경우 구글은 그것을 CTS TC로 추가해버리면 그만이다. 안드로이드를 탑재하여 제품을 만들고싶은 사람 입장에서는 반드시 이 모든 TC를 통과할 수 있도록 소프트웨어를 구현해야 구글이 제품 출시를 허용해준다. 만약 이를 통과하지 못한다면 해당 OS버전이 제공하는 Google Reference phone 수준의 호환성이나 안정성이 보장되지 않는다는 의미이다. 더 간단히는 Google Mobile Service(GMS / Maps, Play Store 등)를 탑재할 수 있는 자격이 박탈된다.

Android Nougat로 버전 업데이트가 되면서 CTS도 (당연히) 함께 버전 업이 되었다. 관련 프로그램은 공식 홈에서 배포한다.

그런데 이번 업데이트에서 문제점 한 가지를 발견했다. testFormatSameDayTime라는 테스트는 의도한 Date Format으로 시간 표기가 되는지를 시험하는 항목이다. 그런데 시스템 설정상 24-hour format을 사용하는 경우가 고려되지 않아 Fail이 될 수 밖에 없는 상황이었다. 우리나라는 자연스럽게 12-hour format, 그러니까 "09:10:56 PM"의 형태를 기본으로 사용한다. 하지만 군대처럼(?) '21:00:56' 표기를 기본으로 하는 국가에 출시되는 제품도 있기 때문에 이 TC는 문제가 있어보였다.

https://android.googlesource.com/platform/cts/+/nougat-cts-dev/tests/tests/text/src/android/text/format/cts/DateUtilsTest.java#143

public void testFormatSameDayTime() { Date date = new Date(109, 0, 19, 3, 30, 15); long fixedTime = date.getTime(); (중략) final long HOUR_DURATION = 2 * 60 * 60 * 1000; assertEquals("5:30:15 AM GMT+00:00", DateUtils.formatSameDayTime(fixedTime + HOUR_DURATION, fixedTime, java.text.DateFormat.FULL, java.text.DateFormat.FULL)); assertEquals("5:30:15 AM", DateUtils.formatSameDayTime(fixedTime + HOUR_DURATION, fixedTime, java.text.DateFormat.FULL, java.text.DateFormat.DEFAULT)); assertEquals("5:30:15 AM GMT+00:00", DateUtils.formatSameDayTime(fixedTime + HOUR_DURATION, fixedTime, java.text.DateFormat.FULL, java.text.DateFormat.LONG)); assertEquals("5:30:15 AM", DateUtils.formatSameDayTime(fixedTime + HOUR_DURATION, fixedTime, java.text.DateFormat.FULL, java.text.DateFormat.MEDIUM)); assertEquals("5:30 AM", DateUtils.formatSameDayTime(fixedTime + HOUR_DURATION, fixedTime, java.text.DateFormat.FULL, java.text.DateFormat.SHORT)); }

이 문제를 해결하기 위한 방법으로 2가지가 떠올랐다.

(1) 시스템 설정이 12시간이든 24시간이든 상관없이 이 TC만 12-hour format으로 강제 변환시켜 Pass 시킨 뒤 원래대로 되돌려 놓기

(2) 24-hour format인 경우의 TC를 추가하고, 시스템 설정별로 다른 TC를 수행하도록 바꾸기

방법(1)은 우회적 발상이다. 테스트의 목적을 완전히 소화하지는 못하지만 테스트를 Pass하는데는 부족함이 없어 보였다. 왠지는 모르겠지만 실제로 이런 방향을 구글이 좋아할 수도(?) 있을 것 같은 느낌이 들기도 했다. 방법(2)는 정석이다. 테스트를 더 합당하게 만들고 그 목적도 100% 달성할 수 있는 수정 방향이었다.

두 번째 방법으로 결정한 뒤로 24시간 표기 방법을 확인하기 위해 코드를 살펴보던 중 또 하나의 암초를 발견했다.

formatSameDayTime() 메서드의 마지막 매개변수로 넘어가는 것은 timeStyle에 해당하는데 결국 이것에 따라 시간 표기 문자열(CharSeqeunce)의 형태가 결정된다. 그런데 DateFormat.FULL과 DateFormat.LONG에 대한 24시간 표기 스타일을 libcore에서 지원하지 않았다. 그래서 24시간 TC를 추가한들 이 두가지 포맷에 대해서는 항상 12시간 표기가 반환될 것이기 때문에 의도한 결과를 얻을 수 없었다.

(CLDR : http://cldr.unicode.org/)

http://androidxref.com/7.0.0_r1/xref/libcore/luni/src/main/java/libcore/icu/LocaleData.java?h=#178

public String getTimeFormat(int style) { switch (style) { case DateFormat.SHORT: if (DateFormat.is24Hour == null) { return shortTimeFormat; } else { return DateFormat.is24Hour ? timeFormat_Hm : timeFormat_hm; } case DateFormat.MEDIUM: if (DateFormat.is24Hour == null) { return mediumTimeFormat; } else { return DateFormat.is24Hour ? timeFormat_Hms : timeFormat_hms; } case DateFormat.LONG: // CLDR doesn't really have anything we can use to obey the 12-/24-hour preference. return longTimeFormat; case DateFormat.FULL: // CLDR doesn't really have anything we can use to obey the 12-/24-hour preference. return fullTimeFormat; } throw new AssertionError(); }

이 사실을 구글도 인지하였는지 구글에서 수정코드를 올렸다.

역시 DateFormat.FULL / LONG에 대한 것은 제한사항으로 보는 것 같다. 나머지 시간표기에 대해서는 12시간 혹은 24시간 표기방법 어느 하나를 만족하면 테스트를 통과할 수 있도록 변경했다. 시스템 설정에 따라 의도치 않은 테스트 실패는 회피했지만 목적을 모두 달성했다고는 보기 어려웠다.

CTS가 안드로이드의 단편화를 방지하고 올바른 API 사용유도, 보안 강화 등의 여러가지 순작용을 하고 있는 것은 긍정적이다. 하지만 '단순히 테스트를 통과하기 위한 코드'를 작성하는 것에는 반감이 있다. TC의 설계나 구현이 잘못되어 있다면 AOSP를 통해 올바른 방향으로 고쳐나가야 하는 것이 마땅하다. 하지만 문제의 원인이 제3자 라이브러리 때문인 경우와 같은, 당장 수정이 힘든 것들은 이렇게 하면서까지 TC 자체를 유지시켜야만 하는지 의문이다.