Target board에서 AAOS 소스 코드 확인? ADB를 써라!

 

 

  1.  AAOS 소스코드 확인하기

 

AAOS(Android Automotive OS) 16 타겟 기기(실제 차량용 IVI 하드웨어 또는 에뮬레이터) 내부에서 리눅스 커널 전체 소스 코드를 직접 보는 것은 일반적인 상황은 아닙니다. 보통 타겟에는 빌드된 결과물인 '바이너리'만 올라가기 때문이죠.

하지만 불가능한 것은 아니며, 시리얼 포트(Serial Port)와 ADB를 활용해 접근하는 현실적인 방법들을 정리해 드립니다.

 

 

  1.1  타겟 기기에 소스 코드가 들어있나?

 

 

기본적으로 AAOS 타겟 기기의 / (root)나 /system 파티션에는 소스 코드가 없습니다.

• 이유: 소스 코드는 수십 GB에 달하며, 임베디드 기기의 저장 공간은 한정되어 있기 때문입니다.
• 확인법: ADB로 접속해서 ls -R /을 해봐도 .c나 .h 파일은 찾기 힘들 것입니다.

 

 

  1.2  타겟에서 소스 / 상태를 확인하는 방법

 

A. ADB (Android Debug Bridge) 활용 (추천)

USB나 네트워크로 연결하여 타겟의 '상태'를 소스 코드 수준에서 유추할 때 가장 많이 씁니다.

• /proc/config.gz: 현재 돌아가는 커널이 어떤 옵션(예: CONFIG_PREEMPT)으로 빌드되었는지 확인 가능합니다.
• /proc/kallsyms: 커널 내 모든 함수의 주소값을 보여줍니다. 우리가 공부한 __schedule이나 dup_task_struct가 메모리 어디에 있는지 알 수 있습니다.

B. 시리얼 포트 (UART/Console) 활용

하드웨어 개발 단계라면 시리얼 포트 연결은 필수입니다.

• 커널 로그(dmesg) 실시간 모니터링: 부팅 과정이나 인터럽트 발생 시의 로그를 여과 없이 볼 수 있습니다.
• 쉘 접근: ADB가 뜨기 전 단계나 커널 패닉(Panic)이 발생한 직후의 상태를 점검할 때 시리얼 포트가 유일한 통로가 됩니다.

 

 

  1.3  진짜로 타겟 안에서 소스를 보고 싶다면? (Workaround)

 

 

만약 타겟 장치 내부에서 직접 소스를 검색하거나 빌드 환경을 구성하고 싶다면 다음과 같은 트릭을 씁니다.

1. SD카드/외장 스토리지: 전체 소스 코드를 SD카드에 담아 타겟 기기에 마운트(mount)합니다. 그 후 vim이나 grep으로 소스를 봅니다.
2. 네트워크 마운트 (NFS): 개발용 Host PC의 소스 폴더를 타겟 기기에서 네트워크로 공유받아 로컬 파일처럼 접근합니다. (커널 개발 시 흔히 쓰는 방식입니다.)

 

 

 

  1.4  AAOS 16 커널 학습을 위한 팁

 

AAOS 16은 GKI(Generic Kernel Image) 구조를 따릅니다. 즉, 구글이 제공하는 표준 커널과 제조사가 만든 모듈이 분리되어 있습니다.

• 소스 확인: Android Kernel Source (googlesource.com) 에서 AAOS 16에 해당하는 브랜치(예: android16-6.12등)를 웹으로 보는 것이 가장 빠르고 정확합니다.
• 런타임 분석: 소스 코드를 타겟에 넣기보다는, 소스 코드를 Host PC에 띄워두고 타겟에서는 ftrace나 kprobe를 사용하여 "지금 이 함수가 실행되고 있나?"를 확인하는 것이 고수의 방식입니다.

 

 

  💡 다음 단계 제안

 

 

혹시 타겟 기기에서 특정 함수(예: set_task_cpu)가 실제로 호출되는 순간의 파라미터 값을 보고 싶으신 건가요? 그렇다면 소스 코드를 기기에 넣는 것보다 ftrace를 사용하는 법을 익히는 게 10배는 더 빠릅니다.

 

 

 

  2.  ADB (Android Debug Bridge)란

 

ADB(Android Debug Bridge)는 이름 그대로 당신의 개발용 PC(Host)와 안드로이드 기기(Target) 사이를 연결해 주는 '다리(Bridge)' 역할을 하는 다재다능한 명령줄 도구(CLI)입니다.

단순히 파일을 주고받는 수준을 넘어, 안드로이드 운영체제의 깊숙한 곳(커널, 쉘, 패키지 관리자 등)을 제어할 수 있게 해주는 개발자의 필수 도구죠.

 

 

  2.1  ADB의 3단계 핵심 구조 (Client-Server Architecture)

 

ADB는 눈에 보이지 않지만 내부적으로 세 가지 부분이 협력하여 동작합니다.

1. Client (PC에서 실행): 우리가 터미널에 입력하는 명령어 그 자체입니다. (예: adb shell, adb logcat)
2. Server (PC 백그라운드에서 실행): 클라이언트와 기기 사이의 통신을 관리합니다. 클라이언트의 명령을 받아서 기기로 전달하는 "관리자"입니다.
3. Daemon (adbd, 기기 내부에서 실행): 안드로이드 기기 안에서 백그라운드로 돌고 있는 프로세스입니다. 서버가 보낸 명령을 실제로 기기 안에서 실행합니다.

 

 

  2.2  ADB 주요 사용 용도

 

AAOS 환경에서 adb를 활용하면, 기기를 직접 만지거나 시리얼 포트를 연결하지 않고도 다음과 같은 작업이 가능합니다.

• 앱 관리: .apk 파일 설치(adb install), 앱 삭제, 실행 중인 앱 강제 종료 등.
• 로그 확인(adb logcat): adb logcat을 통해 시스템 로그를 실시간으로 확인하여 오류를 분석합니다.
• 파일 전송(adb push / pull): PC에서 기기로(push), 기기에서 PC로(pull) 파일을 자유롭게 복사합니다.
• 셸 접근(adb shell): 기기의 리눅스 터미널에 접속합니다. cat /proc/interrupts나 top 등 시스템 명령어를 직접 입력할 수 있습니다.
• adb bugreport: 시스템의 전체적인 상태(커널 로그, 덤프, 메모리 상태)를 하나의 거대한 파일로 출력합니다. 커널 패닉 분석 시 필수입니다.
• 고급 제어: 화면 녹화, 해상도 변경, 백업 및 복구, 재부팅(리커버리/부트로더 모드) 등을 수행합니다.

 

 

 

  2.3  기본 사용 방법 (준비 단계)

 

adb를 사용하기 위해서는 안드로이드 기기에서 '개발자 옵션'을 활성화하고 'USB 디버깅'을 켜야 합니다.

자주 쓰이는 명령어 예시

명령어	설명
adb devices	연결된 기기 목록을 확인합니다.
adb shell	기기의 시스템 명령 프롬프트로 들어갑니다.
adb shell dmesg	커널 로그를 출력하며, in_interrupt() 패닉 로그 등을 볼 때 사용
adb root	루트 권한을 획득하며, /proc이나 /sys 아래 커널 정보를 수정할 때 필수
adb logcat	기기의 실시간 로그를 출력합니다.
adb push <PC경로> <기기경로>	PC 파일을 기기로 전송합니다.
adb pull <기기경로> <PC경로>	기기 파일을 PC로 가져옵니다.
adb reboot	기기를 재부팅합니다.

 

 

  💡 팁: 시리얼 포트 vs ADB

 

• 시리얼 포트: 기기가 부팅되기 전(Bootloader 단계)이나, 커널이 완전히 뻗어서 네트워크/USB가 죽었을 때 최후의 보루로 사용합니다.
• ADB: 기기가 정상 부팅된 후, 편리하고 빠르게 대량의 데이터를 주고받으며 디버깅할 때 사용합니다.

최근에는 USB 케이블 없이도 무선(Wireless) adb를 지원하여 편리하게 디버깅할 수 있습니다. 안드로이드 11 이상 버전에서는 '무선 디버깅' 메뉴를 통해 페어링 코드로 쉽게 연결할 수 있어 임베디드 장비나 차량용 인포테인먼트(IVI) 개발 시 매우 유용하게 쓰입니다.

 

이제 ADB를 통해 AAOS 기기에 접속해서, 우리가 배웠던 preempt_count나 task_struct 정보를 /proc 파일 시스템을 통해 직접 확인해 볼까요? (예: adb shell cat /proc/sched_debug)