오늘은 안드로이드 오픈소스 코드인 AOSP의 아키텍처 구조가 어떻게 되어있는지 정리해보겠다.
안드로이드 코드는 의외로 오픈소스이기때문에 누구나 코드를 통해 안드로이드 휴대폰을 만들수 있는데,
이때문에 안드로이드 개발 초기에 이를 지원하는 디바이스 제조사들이 생겨났다.
나도 그 회사 중 한 회사에 다니고 있는 것이고.
그래서 우리 회사는 안드로이드의 코드를 받아 포팅한 후,
회사의 납품 고객사 특성에 맞게 디바이스를 최적화하여 판매하는데
따라서 해당 코드가 어떤 플로우로 흘러가고, 또 각 기능을 하는 코드는 어떻게 layer가 나눠져 있는지를 파악하고 있어야 한다.
Android Architecture
안드로이드의 코드인 AOSP는 다음과 같이 추상적으로 Layer가 나눠져 있다.
사실 아직도 Runtime이 왜 저기 Layer로 들어가있는지도 잘 모르겠고,, 나머지는 대충 구조가 이해는 되는데
문제는 이 그림을 엄청나게 큰 프로젝트 소스에서 엄청나게 많은 폴더들을 저 Layer에 각각 대입해야 한다.
지금은 공부하며 파악을 거의 마쳤지만, 그 당시엔 저 그림 하나로 소스코드라는 미로를 헤매며 정처없이 떠돌기만 할 뿐이었다.
여하튼 저 그림은 매우 많은 Layer가 담겨있고, 그 중 많은 요소들이 대부분 사람들에겐 의미없는 요소일 것이다. (비록 앱개발자더라도)
내가 이해하고 나서 느끼는건 Layer를 좀더 단순하게 나누면 이해하기 쉬워진다.
1. Android Framework
안드로이드 프레임워크 안의 메소드들은 대부분 앱 개발자가 사용할 수 있게 딱 이쁘게 세팅해놓았다.
이곳까지도 앱개발자들은 나름 어떻게 해볼 수 있겠지만 그 밑의 service 코드를 건들지 않는 선에서 이다.
서비스를 건들게 되면 AOSP가 기본적으로 제공해주는 시스템을 변화시키겠다는건데
뭐 사연이 있다면 하겠지만 굳이 앱 개발자가? 라는 생각은 좀 든다.
이 Framework에서도 Settings와 같은 앱들이나 Wizard와 같은 앱들의 요청을 제외하고는 권한이 없다고 판단하여 사용할 수 없는 기능들도 간간히 있다. (Wi-Fi Scanning 방법 설정과 같은)
아무튼 이 Layer는 사용자와 앱 개발자가 사용하고 구현하는 공간이라고 생각되어 진다.
이 Framework의 매니저 클래스에서 시스템의 Service 메소드들을 API처럼 호출하여 사용할 뿐 서비스 자체를 제어할 순 없다.
2. Android Service
여기서부터는 Framework의 시스템 코드이다.
Manager와 Service 코드는 AIDL이라는 인터페이스 객체를 통해 바인더 통신으로 연결되어 있는데
시스템을 건들지 않고, 일반 유저가 접근하지 못하게 제어하는 권한 방어 장치같은 Layer 분기이다.
AOSP에서 제공하는 기능이 아니지만 Hardware를 탑재하여 기능을 추가하게된다면 여기에 코드를 구현하게 될 것이다.
3. Hal
hal이라는 걸 이 회사에서 처음 알게 되었다.
hal은 하드웨어 제조사와 소프트웨어 제조사 간의 규격을 정하는 메뉴판과 같다.
웹 개발 시에 UI 개발하는 프론트개발자와 api를 개발하는 웹 개발자가 API 명세서를 참고하여 개발을 하는 것처럼
다양한 하드웨어 제조사가 이 칩 뺐다가 저 칩 꼽아도 작동할 수 있도록 소프트웨어 인터페이스의 명세서 장치라고 난 이해했다.
이 hal 구현체 내부로 들어가게 되면 대부분 메모리의 유저영역 말단에서 커널 영역으로 시스템콜을 통해 원하는 행위를 요청하는 방식이다.
4. Driver & Kernel
여기서부터는 커널 메모리이다.
유저 영역에서 netlink나 file 시스템, sendmsg 등의 시스템 콜을 통해(소켓통신을 하기도 하더라) 이 Layer로 요청이 전달된다.
Framework에서 내려온 요청을 하드웨어가 처리해야 하는 일이라면 이 Layer까지 전달 될 것인데
Kernel은 scanner나 wifi칩같은 하드웨어 장치가 수행하는 일을 수행하지는 못하므로 해당 요청을 드라이버단에 전달한다.
이 드라이버는 만약 유저가 데이터를 제공한다면 해당 유저의 메모리에 직접 데이터를 복사해주기도 한다.
하지만 자주 읽고 쓰는 작업이 아니거나 요청과 수행이 비동기로 처리된다면 하드웨어 드라이버가 커널에 데이터를 쓰고
커널은 요청을 받았을 때 드라이버에 요청하지 않고 커널이 가지고 있는 데이터를 곧바로 제공하기도 한다.
'모바일' 카테고리의 다른 글
[AOSP] Framework Service와 HAL 바인드 과정 살펴보기 (1) | 2024.11.26 |
---|---|
[WLAN] Wi-Fi protocol (2) - Band Protocol (0) | 2024.11.21 |
[Wi-Fi Network] Wi-Fi 의 protocol들 (0) | 2024.11.14 |
[Wifi Network Study] 암호화 방식 별 특징 (1) | 2024.11.12 |
Wifi Network Authentication - 4-way Handshake process (0) | 2024.11.11 |