안드로이드 하드웨어 서비스 03 Telephony Framework

Phone 앱과 텔레포니 프레임워크가 하나의 프로세스에서 같이 실행되도록 구현된 이유는 네트워크의 특성상 네트워크로부터 전달되는 응답이 올 시점을 예측하기 어려우므로 비동기 통신 방식을 사용하기 때문임. 

 

3.1.1 텔레포니 프레임워크의 기능

GSM 또는 CDMA 모뎀이 제공하는 모든 서비스를 PDK앱인 Phone앱 및 MMS 앱등에 제공하며 SDK앱에서는 TelephonyManager를 통해 한정적인 네트워크 정보를 제공함. 

- 텔레포니 프레임워크 내 객체 간의 통신 메커니즘 제공. 레이어와 레이어 간의 인터페이스를 정의하고 각 레이어 내의 객체 간 통신 메커니즘을 정의함. 

- 텔레포니 프레임워크와 RIL 데몬 간의 통신 : RIL 데몬과의 통신 메커니즘을 구현함. 유닉스 도메인 소켓을 통해 RIL 데몬과 통신하며 모뎀의 특정 동작을 정의한 RIL 명령을 이용하여 모뎀을 제어함. 여기에서 유닉스 도메인 소켓을 사용하는지, 바인더를 사용하는지 명확히 알 필요가 있음. 

- 모뎀을 제어하기 위한 공통 API 제공 : 모뎀을 제어하는 공통 API를 Phone 앱에 제공하고 Phone앱은 제공된 API를 이용하여 모뎀을 제어하여 네트워크와 통신함. 

- 모뎀의 안정성 보장 : 모뎀을 제어하기 위한 API를 유일하게 제공함. 안드로이드는 Phone 앱과 MMS 앱만이 텔레포니 프레임워크를 통해 모뎀에 직접 접근하는 것을 허용하고 나머지 앱은 SDK가 제공하는 API이외의 모뎀 제어를 허용하지 않음. 보통 모뎀은 모뎀 크래쉬가 발생하면 크래쉬의 원인을 규명하기 위해 크래쉬 직전의 레지스터와 스택 메모리의 덤프를 저장함. 안드로이드는 일반적인 SDK앱에 TelephonyManager를 통해 제한적으로 가입자 정보와 네트워크 정보를 제공함. 

 

 각각 널려있는 telephony 를 어디에서 어떻게 사용하고 있는지 파악하는 것이 주요점. 각 폴더에서 어떻게 사용하고 있는지 파악하기 먼저. 그리고 이것을 토대로 binder는 어디에서 사용되고 있는지 파악할 필요가 있음. 

telephony와 telecomm 간의 관계도 알아야겠구나.

 

/android12/frameworks/base/telephony/java/com/android/internal/telephony

내부에 있던 것들이 여기로 옮겨져옴. 옮겨진 이유는? base가 아닌 opt로 옮겨옴.

/android12/frameworks/opt/telephony/src/java/com/android/internal/telephony

그리고 이렇게 까지 총 3군데에 Telephony 관련 코드가 뿌려져 있음

/android12/packages/services/Telephony/src/com/android/phone

 

자바 시스템 서비스쪽을 분석하여 동일하게 표현하면 될듯. 현재 돌리고 있는 부분은 exynos-ril쪽 부분임

이것을 보고 여기에도 바인더가 쓰이는 부분이 있을테니 확인해보면 될듯. 지금은 TelephonyService쪽을 파악하고 그리기 시작할 것임. 

frameworks/native/libs/binder

 

IFooService.Stub.proxy가 

ITelephonyManager 로 가고 stub.asinterface 이렇게 변경된 것으로 보입니다.