안드로이드 트레블이란 수 많은 vendor에서 안드로이드 OS를 사용함으로써 생기는 여러 파편화의 문제를 해결하고자 하는 구글의 방안이다.
결과적으로 트레블을 통해서 구글은 vendor와 Android Framework OS 부분을 나누고자 하였고 Android Framework 즉 Android OS의 업그레이드 진행 시 vendor사 코드의 수정 없이 APK형식으로 Android OS만 업그레이드가 가능하도록하여 안드로이드 시스템 업데이트 기한을 단축시키고 생태계를 빠르게 발전시키도록 하고자 한다.
1. Treble과 Android 구조
기본적으로 기존의 안드로이드 OS는 위와 같은 구조로 이루어져있습니다. 즉 Android OS upgrade를 진행하기 위해서는 의존성이 존재하는 vendort사의 코드도 이에 맞춰 수정을 진행해야하고 이 후 일련의 동작 테스트를 거침으로써 정상적으로 OS upgrade가 가능합니다.
구글은 위 문제를 해결하기 위해 vendor 구현사항을 의존성을 제거하고 따로 영역을 할당하도록 했는데 해당 구조가 바로 위 그림과 같습니다.
그리고 vendort 구현 코드의 검증을 위해 구글은 VTS 검증 과정을 추가했습니다.
VTS란 vendor 코드를 검증하기위한 테스트 과정으로 구글에서 제공하는 기본적인 기능인 Dalvik, HAL, AOSP, ADB 등이 vendor가 구현한 코드 위에서 정상적으로 돌아가는지 체크하는 과정입니다.
이 때 테스트의 진행방법으로는 구글에서 구글의 기본적인 기능만을 담은(순수 AOSP만 포함된) GSI 이미지(General System Image)를 이용하는데, vendor 코드가 구현된 vendor의 모바일 기기에 GSI 이미지를 다운로드하고 부팅, 동작 등의 테스트과정을 진행함으로써 안드로이드의 기본 AOSP가 정상적으로 동작하는지 vendor 사 구현 코드를 검증할 수 있습니다.
- GSI
여기서 GSI이미지에 대해 잠깐 알아보면…
기본적으로 모바일 기기에는 여러 이미지가 포함되고 있습니다. system.img, vendor.img 등 다양한 이미지가 기기의 동작을 진행하게 하는데 여기서 GSI란 구글에서 기본적으로 제공하는 순수 AOSP(즉 vendor사에서 추가 수정, 변형이 없는 구글 순수 AOSP function) 만을 담은 system.img이다.
즉 구글의 os update가 의미하는 것은 바로 이 GSI image가 업데이트 되는 것이라고 보면 된다.
즉 해당 GSI image를 이용해서 VTS 테스트를 진행한다는 것은 vendor.img를 제외하고 구글의 순수 코드가 vendor 구현부 위에 올려졌을 때 정상적으로 모바일이 동작하는지 체크를 하기 위함이고 VTS가 정상적이라는 말은 곧 구글에서 GSI만 update해서 vendor 구현부 위에 올려줄 수 있다는 말을 의미하고 이는 곧 Android Treble의 동작을 의미한다.
2. VNDK
Vendor native develop kit로 vendor사에서 구현한 라이브러리이다. 다시 말해 vendor사에서 순수 AOSP를 변형 및 추가하고 그외 vendor 고유의 코드들을 하나의 라이브러리로 만든 것이다. VNDK근 system.img에 포함되며 동작 시에 동적으로 vendor 구현 코드와 연결되서 vendor 코드를 사용할 수 있게 한다.
예를들어 순수 AOSP 코드 중 A라는 function이존재하는데 vendor에서 해당 A를 수정했다고하자.
이 경우 fucntion A가 호출되면 vendor 구현부에 존재하는 코드가 동작해야하는데 이를 위해 GSI 이미지인 기본 system.img안에 VNDK를 포함시켜준 것이다. 즉 function A호출 시 system.img에서는 VNDK를 호출하게되고 VNDK에 동적으로 연결된 vendor 코드가 동작하게 된다.
참고로 vendor코드와 안드로이드 순수 AOSP 코드를 분리함으로써 둘의 통신은 HIDL을 통해 지원한다.
3. ABI (Application Binary Interface)
ABI 안정성은 구글에서 vendor별로 순수 AOSP 변조를 진행할 때 그 정도를 제한한 것으로 생각하면 된다.
Android Treble의 목적은 vendor의 코드 변경없이 GSI update를 통해 안드로이드 순수 AOSP를 update하는 것이다.
즉 심한 파편화는 treble의 목적을 달성할 수 없기 때문에 구글에서는 이러한 파편화를 강제로 제한하는데 ABI 안정성이 바로 그것이다.
즉 vendor사에서는 ABI안정성을 지키는선에서 AOSP의 변형이 가능하고 구글은 이를 통해서 VTS로 검증된 vendor 코드에 대해서는 GSI update를 진행하고 Android treble정책을 실현할 수 있다.
4. CTS
추가적으로 CTS에 대해 잠깐 이야기하면 CTS는 APK동작에 대한 테스트 과정이다.
위 구조를 보면 가장 윗단에 APK가 존재하며 이러한 셀 수 없을 정도로 많은 APK가 존재하고 있습니다.
이러한 Andorid OS 생태계를 유지하기 위해 Android OS+Vendor 구현부 (즉 HAL, Linux Kernel, Native, Framework 등 APK 이하 안드로이드 영역)가 이루어진 단말을 바탕으로 APK들이 정상적으로 구동할 수 있는지 테스트하는 과정을 말한다.
ref : https://source.android.com/devices/architecture?hl=ko
Android Develop, 안드로이드 개발자 블로그