안드로이드에서 시스템 서비스는 클라이언트와 서버의 구조를 가지고 있다.
시스템 서비스의 정의는 framework/framework.jar에서 찾을 수 있고, 실제 구현은 여러 곳에 흩어져있지만 주로 framework/services.jar에서 찾을 수 있다.
| 프록시 → 클라이언트 측
| 스텁 → 서버측
클라이언트 프로세스가 transact() 메서드를 호출하면 서버 프로세는 onTransact() 메서드를 통해 호출을 받는다.
transact는 (transaction_id, input, ouput)과 같은 형태이며 onTransact는 transaction_id에 따른 switch문으로 구성되는 것이 보통이다.
service manager
service manager = Android의 System Service를 관리하는 중요한 프로세스, 각 서비스마다 핸들을 부여하고 서비스의 추가 및 검색 기능을 수행함.
서비스는 실행 시 addService()함수를 통해 Service Manager에 서비스 핸들을 등록하며, application들은 Service Manager로부터 System Service에 대한 정보를 획득할 수 있다.
Binder
서로 다른 프로세스들을 연결 (링커의 다른 프로세스 간 버전이라고 생각하면 됨)
원래 IPC도구이지만, 다른 프로세스의 함수를 현재 프로세스에 존재하는 함수처럼 사용할 수 있게 해주는 RPC에 가장 많이 쓰인다.
binder는 프로세스간에 커널 공간은 공유가 가능하다는 점을 이용하여 커널공간에서 동작하는 binder driver라는 추상화된 드라이버를 이용한다. 이를 이용하면 프로세스간 통신이 가능해진다.
이는 /dev/binder에 위치하며 binder를 사용하고자 하는 프로세스는 이 디바이스를 open하면 된다. 여러 스레드가 동일한 fd를 공유해도 된다.
system service - daemon과의 관계 예시
installd의 isQuotaSupported를 예로 들자면, 아래 api는 서비스 클라이언트 단에서 수행되는 코드이며 아래 코드가 수행되면 서비스 서버인 Installd에서 요청을 받는다. 그리고 클라이언트는 Installd 데몬의 응답을 대기하다가 응답이 오면 이를 obtain2에서 받는다. 인자와 응답이 오고가는 obtain과 obtain2는 parcel이라는 자료형을 가지는데, 이는 안드로이드의 IPC에서 값을 주고받기 위한 일종의 박스라고 보면 된다.
클라이언트에서 rpc형태로 데몬의 메소드를 호출하는 형태인 듯. 그 과정에서 바인더가 작용한다. (요청 전달을 바인더가 하는 형태)
