AOSP 개발 실무: SystemServer 서비스 아키텍처와 Android.bp 기반 커스텀 구현

안드로이드 앱 개발을 하다 보면 마법처럼 작동하는 다양한 인프라에 감탄하곤 합니다. 서로 다른 앱 프로세스끼리 데이터를 초고속으로 전송하고, 내 앱이 백그라운드에 가 있어도 OS가 시스템 리소스를 정교하게 통제하죠. 이러한 마법 같은 메커니즘의 이면에는 안드로이드 운영체제의 근본을 지탱하는 강력한 3대 아키텍처 축인 Binder, ServiceManager, 그리고 SystemServer가 견고하게 버티고 있습니다.

AOSP(안드로이드 오픈소스 프로젝트) 기반의 펌웨어를 개조하거나 독자적인 임베디드 단말을 양산할 때, 나만의 특권 기능을 이 시스템 생태계 안에 정식 구성원으로 입격시키는 작업은 프레임워크 엔지니어의 핵심 역량입니다. 단순히 자바 코드를 짜는 수준을 넘어, 프로세스 간 통신(IPC)의 장벽을 뚫어주는 AIDL의 실체를 이해하고 최신 소스 트리 빌드 체계인 Android.bp 규격에 맞춰 시스템 심장부에 코드를 주입하는 일련의 파이프라인을 실무 관점에서 아주 알기 쉽게 풀어드리겠습니다.

Generated by Gemini AI.

📌 핵심 요약 3줄

1. 안드로이드 IPC의 근간인 Binder 드라이버를 기반으로, 모든 시스템 서비스는 중앙 레지스트리인 ServiceManager에 문자열 네임태그로 등록되어 관리됩니다.
2. 커스텀 프레임워크 서비스는 부팅 시 SystemServer 프로세스의 컨텍스트 내에서 가동되므로 독립적인 init.rc 바이너리 가동 설정이 필요하지 않습니다.
3. 최신 AOSP 빌드 시스템 규격인 Android.bp에 소스 파일과 AIDL 인터페이스를 정확히 명시해야 시스템 자바 프레임워크 레이어에 정상 컴파일 반영됩니다.

---

1. 안드로이드 프레임워크 아키텍처 3대 축 비교

안드로이드 로우 레벨 시스템을 통제하는 핵심 컴포넌트들의 역할과 상호작용 메커니즘입니다.

핵심 컴포넌트 명칭	실행되는 아키텍처 레이어	핵심 런타임 미션 및 역할	실무 엔지니어 관점의 한 줄 요약
바인더 (Binder)	리눅스 커널 (Kernel Space)	프로세스 간 메모리 격리 장벽을 넘어 높은 성능과 UID 기반 보안으로 데이터 공유	프로세스 간 원격 함수 호출(IPC)의 통로를 열어주는 로우 레벨 드라이버
서비스매니저 (ServiceManager)	네이티브 시스템 데몬 (User Space)	단말 전역에 오픈된 시스템 서비스들의 주소록(레지스트리) 등록 및 검색 허브 제어	서비스들의 이름표를 관리하며 클라이언트에게 바인더 핸들을 토스하는 중개인
시스템서버 (SystemServer)	자바 시스템 프로세스 (User Space)	부팅 시 자바 레이어 코어 서비스인 AMS, PMS, WMS 등을 순차적으로 인스턴스화	안드로이드 핵심 자바 프레임워크 서비스를 품고 구동하는 특권 프로세스 컨테이너

---

2. 최신 빌드 시스템(Android.bp) 기반의 시스템 서비스 이식 실무

나만의 시스템 서비스를 프레임워크에 추가하려면 코드 작성과 동시에 최신 안드로이드 빌드 체계인 블루프린트(Android.bp) 환경 파일에 선언해 주어야 합니다.

2.1 AIDL 인터페이스 명세서 배치

클라이언트 프로세스와 시스템 서버가 소통할 IPC 규격을 정의합니다.

Java

 

// frameworks/base/core/java/com/example/mysystemservice/IMyService.aidl
package com.example.mysystemservice;

interface IMyService {
    String getMessage();
}

2.2 프레임워크 빌드 스크립트 수정 (Android.bp)

정의한 AIDL 파일이 안드로이드 빌드 타임에 정상적으로 자바 인터페이스 스텁 코드로 파싱되도록 빌드 파일에 등록합니다. 일반적으로 frameworks/base/Android.bp 내부의 소스 리스트 항목에 경로를 매핑합니다.

코드 스니펫

 

// frameworks/base/Android.bp 내부 src 파일 리스트 섹션 예시
java_defaults {
    name: "framework-minus-apex-defaults",
    srcs: [
        // ... 기존 순정 소스 경로들 ...
        "core/java/com/example/mysystemservice/IMyService.aidl",
    ],
}

2.3 커스텀 시스템 서비스 소스 클래스 구현

SystemService 코어 클래스를 상속받아 실제 비즈니스 로직과 바인더 엔드포인트를 결합합니다.

Java

 

// frameworks/base/services/core/java/com/android/server/custom/MySystemService.java
package com.android.server.custom;

import android.content.Context;
import android.os.IMyService; // Android.bp에 의해 자동 생성된 인터페이스 파싱
import android.os.RemoteException;
import android.util.Slog;
import com.android.server.SystemService;

public class MySystemService extends SystemService {
    private static final String TAG = "MySystemServiceCore";

    // AIDL 인터페이스의 실질적 구현체 스텁 구성
    private final IMyService.Stub mBinder = new IMyService.Stub() {
        @Override
        public String getMessage() throws RemoteException {
            Slog.d(TAG, "클라이언트 앱으로부터 IPC 바인더 메시지 요청 수신 완료");
            return "Hello from MySystemService! 최적화 완료된 시스템 응답입니다.";
        }
    };

    public MySystemService(Context context) {
        super(context);
    }

    @Override
    public void onStart() {
        Slog.i(TAG, "MySystemService 가동 - 전역 ServiceManager 링킹 수행");
        // [필수 마일스톤] ServiceManager 허브에 내 서비스의 공식 이름표를 달아 등록합니다.
        publishBinderService("myservice_custom", mBinder);
    }
}

2.4 SystemServer.java에 초기화 시퀀스 주입

안드로이드가 콜드 부팅을 수행할 때 프레임워크 컨테이너가 내 서비스를 로드하도록 초기화 시퀀스에 빌트인합니다.

Java

 

// frameworks/base/services/java/com/android/server/SystemServer.java
import com.android.server.custom.MySystemService;

private void startOtherServices(@NonNull TimingsTraceAndSlog t) {
    // ... 순정 기본 서비스 구동 흐름 ...
    
    t.traceBegin("StartMyCustomSystemService");
    try {
        // [주의] 여기서 인스턴스화된 서비스는 SystemServer 프로세스의 스레드로 귀속됩니다.
        mSystemServiceManager.startService(MySystemService.class);
    } catch (Throwable e) {
        Slog.e(TAG, "커스텀 시스템 서비스 가동 중 치명적 실패", e);
    }
    t.traceEnd();
}

---

3. 클라이언트 앱단에서의 바인더 링크 검색 및 IPC 호출

프레임워크 개조가 완료되었다면 일반 애플리케이션 단말 앱에서 하부 코어 서비스를 당겨와 원격 메서드를 가동해 봅니다.

Java

 

import android.os.IBinder;
import android.os.ServiceManager; // 일반 앱 빌드 시 스텁 라이브러리 가동 필요
import com.example.mysystemservice.IMyService;
import android.util.Log;

public void callSystemCoreFeatures() {
    try {
        // 1. 중앙 서비스매니저 주소록에서 내 서비스 문자열 키값으로 로우 바인더 객체를 인출합니다.
        IBinder binder = ServiceManager.getService("myservice_custom");
        
        if (binder != null) {
            // 2. 획득한 커널 바인더 객체를 자바 AIDL 인터페이스 프록시 형태로 캐스팅합니다.
            IMyService myService = IMyService.Stub.asInterface(binder);
            
            // 3. 프로세스 경계를 넘어 SystemServer 내부 스레드로 원격 연산을 동기식 요청합니다.
            String response = myService.getMessage();
            Log.i("AppClient", "성공적으로 수신된 커널 안전 메시지: " + response);
        } else {
            Log.e("AppClient", "시스템 내부에 등록된 커스텀 서비스를 찾을 수 없습니다.");
        }
    } catch (Exception e) {
        Log.e("AppClient", "바인더 IPC 통신 트랜잭션 에러 발생", e);
    }
}

---

🛠️ 개발을 위한 팁 (Tips)

1. ServiceManager.checkService()로 안전한 널 프리 예방: 클라이언트 앱 단에서 시스템 서비스를 획득할 때 사용하는 getService() 메서드는 해당 서비스가 초기화 중이거나 알 수 없는 크래시로 내려간 상태라면 바인더 스레드를 잠시 블로킹(대기) 상태로 빠뜨릴 수 있습니다. 서비스가 현재 메모리에 확실히 상주해 있는지 즉각적인 확인만 필요하다면 논블로킹(Non-blocking) 메서드인 ServiceManager.checkService("이름")을 호출하세요. 서비스가 없으면 즉시 null을 뱉으므로 클라이언트 앱의 무한 대기 락 현상을 깔끔하게 방지해 줍니다.
2. Android.bp 반영 후 make api-stubs-docs 갱신: 프레임워크 소스 트리에 새로운 AIDL 파일을 컴파일 경로에 밀어 넣은 뒤 전체 빌드를 돌리면 가끔 빌드 시스템이 새로운 시스템 API 노출을 감지하고 스텁 규칙 위반 에러를 뱉을 때가 있습니다. 이때 당황하지 마시고 셸 창에 m update-api 명령어를 가동하여 안드로이드 프레임워크 전역 API 시그니처 텍스트 파일(current.txt)을 현행화해 주면 빌드가 깔끔하게 성공합니다.

⚠️ 흔히 하는 실수 (Common Mistakes)

1. SystemServer 자바 서비스 등록과 init.rc 데몬 등록의 혼용: 프레임워크 소스 분석 초기 단계에서 가장 많이 저지르는 대표적인 아키텍처 대참사입니다. SystemServer.java 소스 내부에 자바 코드로 인스턴스를 빌드해 놓고, 리눅스 네이티브 가동 스크립트인 init.rc 파일에다가 /system/bin/my_service 형태로 서비스를 중복 기재하는 경우입니다. SystemServer 내부 컴포넌트들은 자바 가상머신(Art VM) 환경 내에서 함께 숨 쉬는 자바 스레드 집합체입니다. init.rc는 C/C++로 짜인 네이티브 바이너리 데몬(예: vold, surfaceflinger)을 커널 단에서 끄집어 올릴 때만 쓰는 통로이므로, 자바 시스템 서비스를 구현할 때는 init.rc 파일에 절대 손을 대면 안 됩니다.
2. 바인더 스레드 가용 개수 초과로 인한 전역 서비스 먹통: 시스템 서비스 AIDL 구현부 내부에서 시간이 오래 걸리는 동기식 루프나 소켓 통신을 다량 처리하는 실수가 잦습니다. 안드로이드 SystemServer 프로세스가 처리할 수 있는 동시 바인더 오픈 스레드 개수는 하드웨어 스펙별로 엄격하게 상한선이 정의되어 있습니다. 여러 앱이 동시에 내 커스텀 서비스를 난타하여 바인더 워커 스레드 풀을 동기식 락으로 가득 채워버리면, 순정 안드로이드 서비스(WindowManagerService 등)로 가야 할 바인더 통로까지 연쇄 마비되어 스마트폰 화면 터치조차 먹히지 않고 단말 전체가 크래시 브레이크를 밟게 됩니다. 무거운 로직은 반드시 비동기 윈도우 핸들러 패턴으로 가공해 빼주어야 합니다.

---

4. 결론

안드로이드의 심장부인 SystemServer 위에 나만의 영혼을 불어넣은 시스템 서비스를 올바르게 안착시키는 일은 프레임워크의 저수준 자원 순환 체계를 관통하는 멋진 경험입니다.

단순히 소스코드를 컴파일하는 것보다 Binder 드라이버가 커널 레벨에서 어떻게 프로세스 가드레일을 쳐주는지, 그리고 ServiceManager가 어떤 메커니즘으로 메모리 핸들을 공유하는지 아키텍처 흐름을 파악하는 것이 탄탄한 양산형 펌웨어를 만드는 비결입니다. 최신 안드로이드 소스 컴파일 도중 블루프린트(Android.bp) 구문 오류가 터졌거나, 클라이언트 앱 컴파일 시 커스텀 AIDL 패키지 참조 레이아웃이 깨져 빌드 실패 문구를 마주하셨다면 아래 댓글 창에 빌드 로그를 편하게 던져주세요. 로우 레벨 단에서 깔끔하게 빌드 장벽을 넘을 수 있도록 디버깅 코드를 함께 조율해 보겠습니다!