본문 바로가기

프로그래밍/Android

Android Architecture Overview

https://source.android.com/devices/architecture?hl=ko

- Application

- Application Framework
: 개발자들이 가장 많이 쓰이는 기능

- Binder IPC Proxies
: IPC (Inter-Process Communication - 프로세스 간 통신) 매커니즘은 
Application Fragment 가 프로세스 경계를 넘을 수 있게 한다.
그리고 Android System service 를 호출 할 수 있게 한다.
이를 통해 상위 수준의 Framework API 가 System Service 와 상호작용한다.
Application Framework 수준에서는 이 통신이 가려지고, 
개발자들에게는 그저 잘 돌아가는 것으로 보인다.

- System Services
: System Service 는 WindowManager, SearchService, NotificationManager 와 같은 모듈식 컴포넌트이다. 
Application Framework API 에 의해 노출된 기능은 
System Service 와 통신하여 하위 하드웨어에 접근한다.
System Services 는 WindowManager, NotificationManager 와 관련된 System Service 와 Media 와 관련된 Media Service 로 나뉜다. 

- HAL (Hardware Abstraction Layout : 하드웨어 추상화 계층)
: 삼성전자같은 하드웨어 공급업체에서 구현해야하는 표준 인터페이스를 정의하며, Android 에서 하위수준의 드라이버를 구현하지 않아도 되게 하는 시스템이다. 
HAL 을 사용하면 시스템을 수정하지 않아도, 상위 수준의 시스템을 구현할 수 있다. 
HAL 구현체는 모듈로 묶여있고, Android System 에 의해 (알아서 적절한 시점에) 불러진다. 

- Linux Kernel
: 일반적인 Linux Kernel 드라이버 개발과 유사하다. 
안드로이드는 Linux Kernel 에서 몇가지 특화된 기능이 추가되어있다. 
1) Low Memory Killer (메모리 보존에 좀 더 적극적인 메모리 운영 시스템)
2) Wake Lock (PowerManager 와 같은)
3) Binder IPC Drive
4) 모바일 플랫폼을 위한 중요한 기능들
이런 기능들은 주로 시스템 기능과 관련이 있고, driver 개발애 영향을 미치지 않는다.
안드로이드 개발시 Binder Driver 같은 필수 기능이 추가된 커널 버전 이상이라면 
쓸 수 있지만, 항상 최신 버전의 Android Kernel 을 사용하는 것이 좋다. 


- HIDL : HAL interface definition language (AIDL/HIDL)
안드로이드는 Android 8.0 부터  제조사가 Android 기기를 좀 더 쉽고, 빠르게 
새 버전으로 업데이트 하도록 Android OS Framework 의 아키텍처(Treble)를 재설계했다.
새로운 아키텍처에서 HIDL 는 HAL 과 HAL 사용자 사이에 인터페이스를 지정하여 
다시 빌드하지 않고도 Android Framework 을 교체할 수 있게 했다.
Android 10 에서는 HIDL 이 AIDL 로 통합되었다. 

https://m.blog.naver.com/searphiel9/221217883927
https://android-developers.googleblog.com/2017/05/here-comes-treble-modular-base-for.html


안드로이드 OS 의 가장 큰 문제는 파편화이다. 이에 대한 대응으로 
기존 안드로이드 구조를 갈아엎어 파편화에 대응하기 위한 무기를 가지고 나왔다. 

8.0 이전 안드로이드 출시 및 업데이트 시
안드로이드에서 최신 안드로이드 버전 코드를 게시한다. 
칩셋 제조사가 새로운 안드로이드 버전에 맞춘 새로운 드라이버를 개발한다.
칩셋 제조사는 기기 제조사에게 새 드라이버를 전달한다. 
기기 제조사는 기기에 필요한 새 버전을 개발한다.
기기 제조사와 통신사는 새 버전을 테스트한다. 
기기 제조사는 새 버전을 사용자가 쓸 수 있도록 업데이트를 진행한다.

안드로이드 Treble 이란?
칩셋 제조사(퀄컴) -> 기기 제조사(삼성) -> 통신사(SKT) -> 사용자

기존 안드로이드의 문제는 새로운 안드로이드 OS 가 출시 될때마다 
칩셋, 기기, 통신사의 시간과 비용이 많다는 것이다.
이를 해결하기 위해 칩셋 제조사, 기기 제조사와 협력하여 문제를 개선했다.
안드로이드 자체를 모듈화시켜서 업데이트 과정을 축소하여 사용자가 보다 빠르게 새로운 OS 를 경험할 수 있게 했다. 

기존에는 칩셋 제조사에서 새로운 드라이버를 제공해야만 이후 작업이 가능했다.
Treble 이후 새로운 인터페이스를 통해 칩셋 제조사에서 했던 일이 Android OS Framework 에서 분리됐다.
즉 HAL 등 기기 제조사가 안드로이드 OS Framework 와 별개로 업데이트를 진행하게 되었다.
제조사는 안드로이드 OS Framework 와 표준화된 방식으로 HAL 과 통신할 수 있는 코드를 구현해야 하는데 이게 HIDL 이다. 이를 통해 제조사는 칩셋 제조사가 드라이버를 업데이트할때까지 기다리지 않고도 
언제든지 안드로이드를 업데이트 할 수 있게 됐다. 
고로 사용자의 안드로이드 새로운 OS 접근을 더 빠르게 했다. 


[나무위키]
기존에 안드로이드는 제조사가 하드웨어를 작동시키는 부분[1]과 안드로이드 프레임워크[2]가 명확하게 분리가 되어 있지 않았으며, 이 때문에 새로운 버전의 OS가 출시될 때마다 매번 제조사가 새로운 OS에 맞춰 자사의 하드웨어 작동 코드를 리메이크해야만 하는 문제점이 있었다. 이는 안드로이드 기기 OS 업데이트의 난이도를 높여 늦은 업데이트, 제조사 역량 부족으로 인한 업데이트 포기, 그리고 업데이트 지연 및 미실시로 인한 각종 호환성 및 보안 문제와 같은 문제점을 불러왔다.[3]

그러나 트레블이 도입된 후로는 제조사 하드웨어를 작동시키는 코드와 안드로이드 프레임워크가 분리되었기 때문에[4] 제조사의 하드웨어 구현을 그대로 두고 OS만을 업데이트하는 것이 가능해 졌다. 즉 제조사 입장에서는 자사의 하드웨어 구현 코드를 새 OS에 맞게 리워크할 필요 없이 새로운 OS에 최소한의 수정[5]만을 하면 바로 업데이트를 적용할 수 있게 되었다. 즉 기존 대비 업데이트 난이도가 대폭 낮아진 것인데, 이는 제조사들이 업데이트를 기존보다 적은 비용으로 보다 신속하게 제공할 수 있도록 하는 효과를 불러온다.

또한 기존에는 OS 업데이트 시 하드웨어 작동 부분의 리워크가 반드시 동반되었기 때문에 칩셋 제조업체가 비협조적일 경우 업데이트 구현 난이도가 매우 높아지거나 아예 불가능해지기도 했는데[6], 트레블이 도입된 이후로는 하드웨어 구현 부분의 수정이 불필요해지는 만큼 이와 같은 사례는 발생하지 않을 것이라고 기대할 수 있다.