AOSP 입문: Custom System Service 개념부터 AIDL 바인더 등록까지 완벽 정리

안드로이드 플랫폼 엔지니어링이나 커스텀 펌웨어(AOSP) 개발 세계에 발을 들여놓게 되면 가장 먼저, 그리고 가장 깊숙이 마주하게 되는 핵심 인프라가 바로 '시스템 서비스(System Service)'입니다. 우리가 일상적으로 앱을 만들 때 사용하는 알림창 띄우기, 와이파이 상태 변경, 하드웨어 센서 값 읽기 같은 고수준 기능들은 사실 앱 스스로 처리하는 게 아닙니다. 안드로이드 운영체제 깊은 곳에서 특권 권한을 쥐고 묵묵히 돌아가는 거대한 백그라운드 관리자들의 손을 빌려 수행되는 것이죠.

안드로이드의 핵심 심장부인 SystemServer 프로세스가 켜지면서 로드되는 이 시스템 서비스들은 일반 애플리케이션이 보안상 직접 건드릴 수 없는 리눅스 커널 드라이버와 시스템 자원을 안전하게 중계하는 브리지 역할을 수행합니다. 이번 포스팅에서는 안드로이드 시스템 서비스의 코어 아키텍처 메커니즘을 낱낱이 해부해 보고, 현업에서 흔히 헷갈려하는 시스템 서비스와 매니저 API의 구조적 차이점, 그리고 나만의 기능을 임베디드 단말에 이식하기 위한 커스텀 시스템 서비스 빌드 파이프라인을 실전 예제 코드를 통해 완전하게 마스터해 보겠습니다.

Generated by Gemini AI.

📌 핵심 요약 3줄

1. 안드로이드 시스템 서비스는 SystemServer 프로세스 내부 스레드로 상주하며 OS 특권 자원과 하드웨어 레이어를 통제하는 핵심 백그라운드 인프라입니다.
2. Context.getSystemService()로 가져오는 매니저 객체들은 서비스 자체가 아니라, 내부 바인더 통신을 대행해 주는 앱 진입점 레벨의 래퍼(Wrapper) API입니다.
3. 나만의 하드웨어나 보안 정책을 OS에 심으려면 AIDL로 인터페이스를 설계한 뒤, 시스템 서비스를 구현하고 ServiceManager 바인더 허브에 정식 등록해야 합니다.

---

1. 안드로이드 시스템 서비스 아키텍처 완벽 분해

안드로이드 프레임워크 내부에서 실제 동작하는 '코어 시스템 서비스'와 우리가 앱 단에서 호출하는 '매니저 API 래퍼'의 명확한 구조적 대조표입니다.

비교 아키텍처 항목	코어 시스템 서비스 (Core System Service)	API 매니저 래퍼 (Framework Manager API)
개념적 정의	OS 핵심 비즈니스 로직과 하드웨어를 통제하는 진짜 주체	시스템 서비스와 안전하게 통신할 수 있도록 도와주는 클라이언트 창구
실행 가동 위치	SystemServer 단일 특권 프로세스 내부 독립 스레드	API를 호출한 개별 애플리케이션 프로세스 메모리 내부
실제 소스 예시	ActivityManagerService, PackageManagerService	ActivityManager, PackageManager, NotificationManager
주요 런타임 역할	전체 단말 자원 관리, SELinux 보안 체크, 실질적 하드웨어 제어	인텐트나 데이터를 바인더 규격 패키지(Parcel)로 패킹 및 에러 핸들링
개발자 접근 방식	ServiceManager.getService("이름")를 통한 하부 바인더 획득	Context.getSystemService(Context.NOTIFICATION_SERVICE)

---

2. 사용자 정의 System Service가 필요한 실무적 순간

AOSP 기반 양산 프로젝트를 진행할 때, 기본 순정 OS 서비스 외에 엔지니어가 직접 커스텀 서비스를 파고들어야 하는 대표적인 시나리오입니다.

1. 커스텀 하드웨어 및 칩셋 연동: 보드 업체에서 독자적으로 설계한 환경 센서, 생체 인식 하드웨어 모듈, 디바이스 통신용 내장 MCU를 안드로이드 HAL(Hardware Abstraction Layer) 레이어와 연결하고, 이 데이터의 생명 주기를 프레임워크 전역에서 실시간으로 스캔·관리해야 할 때 활용합니다.
2. OS 레벨의 강제 보안 정책 수립: 일반 앱 레벨에서는 권한 제한이나 샌드박스 장벽 때문에 절대 개입할 수 없는 전역 프로세스 킬 정책, 특정 패키지 실행 차단, 엔터프라이즈용 키스토어(Keystore) 암호화 모듈 강제 연동 등 시스템 최상위 권한의 가드가 필요할 때 구현합니다.
3. 독립형 전역 데이터 수집 엔진 구축: 사용자 애플리케이션 가동 상태나 화면 상태와 완전히 무관하게, 부팅 시점(BOOT_COMPLETED)부터 전원이 꺼질 때까지 메모리 누수 없이 시스템 가동 로그 및 단말 환경 데이터를 백그라운드에서 상시 모니터링하고 분석하는 파이프라인을 구축할 때 필수적입니다.

---

3. 실전: 사용자 정의 System Service 구현 파이프라인

나만의 커스텀 서비스를 프레임워크 소스 트리에 심고 바인더 인터페이스로 호출하는 4단계 표준 설계 공정입니다.

3.1 인터페이스 명세서 정의 (AIDL)

프로세스 간 통신(IPC) 시 데이터를 주고받을 수 있도록 나만의 원격 메서드 규칙을 정의합니다.

Java

 

// frameworks/base/core/java/com/example/customservice/ICustomService.aidl
package com.example.customservice;

interface ICustomService {
    void setValue(int value);
    int getValue();
}

3.2 코어 시스템 서비스 비즈니스 로직 구현

SystemServer 런타임에 의해 라이프사이클이 통제될 수 있도록 순정 SystemService 클래스를 상속받아 바인더 기능을 구체화합니다.

Java

 

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

import android.content.Context;
import android.os.ICustomService; // AIDL 빌드 후 자동 생성되는 스텁 인터페이스
import android.os.RemoteException;
import android.util.Slog;
import com.android.server.SystemService;

public class CustomService extends SystemService {
    private static final String TAG = "CustomServiceCore";
    private int mStoredValue = 0;

    // 바인더 IPC 요청을 처리하는 핵심 Stub 객체 구현
    private final ICustomService.Stub mBinder = new ICustomService.Stub() {
        @Override
        public void setValue(int value) throws RemoteException {
            mStoredValue = value;
            Slog.d(TAG, "원격 프로세스로부터 데이터 수신 및 내부 메모리 갱신: " + mStoredValue);
        }

        @Override
        public int getValue() throws RemoteException {
            return mStoredValue;
        }
    };

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

    @Override
    public void onStart() {
        Slog.i(TAG, "CustomService 런타임 가동 - 전역 바인더 허브에 서비스 등록 진행");
        // [핵심] ServiceManager에 내 서비스를 문자열 고유 네임태그로 바인딩하여 등록합니다.
        publishBinderService("custom_hardware_service", mBinder);
    }
}

3.3 SystemServer 부팅 시퀀스에 등록 및 이미지 빌드

안드로이드가 켜질 때 내 커스텀 서비스가 함께 메모리에 적재되도록 시스템 서버 초기화 루틴에 한 줄 추가합니다.

Java

 

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

private void startOtherServices(@NonNull TimingsTraceAndSlog t) {
    // ... 기존 순정 서비스 구동 로직들 ...
    
    t.traceBegin("StartCustomHardwareService");
    // 시스템 서비스 매니저를 통해 내 커스텀 서비스를 가동 시퀀스에 포함시킵니다.
    mSystemServiceManager.startService(CustomService.class);
    t.traceEnd();
}

3.4 클라이언트(앱 또는 프레임워크 다른 컴포넌트)에서의 원격 호출

이제 전역 바인더 레지스트리에서 내 서비스 이름표를 찾아 원격 함수를 다이렉트로 가동해 봅니다.

Java

 

import android.os.IBinder;
import android.os.ServiceManager; // 숨겨진 API이므로 AOSP 내부 빌드 또는 컴파일 스텁 환경 필요
import com.example.customservice.ICustomService;

// 1. ServiceManager에 등록된 하부 원격 바인더 객체 핸들을 가져옵니다.
IBinder binder = ServiceManager.getService("custom_hardware_service");

if (binder != null) {
    // 2. 가져온 로우 바인더 객체를 AIDL 인터페이스 형태로 변환(디시리얼라이즈)합니다.
    ICustomService customService = ICustomService.Stub.asInterface(binder);
    
    // 3. 마치 내 프로세스 내부 함수를 쓰듯 원격 프로세스의 기능을 원격 제어합니다.
    customService.setValue(99);
    int savedData = customService.getValue();
    android.util.Log.d("ClientApp", "시스템 서비스로부터 안전하게 복원된 값: " + savedData);
}

---

🛠️ 개발을 위한 팁 (Tips)

1. 내 시스템 서비스에 간편한 dumpsys 인터페이스 심어두기: 시스템 서비스를 만들 때 바인더 Stub 내부 객체 안에 protected void dump(FileDescriptor fd, PrintWriter pw, String[] args) 메서드를 오버라이딩해 두세요. 개발 도중 터미널 창에 adb shell dumpsys custom_hardware_service를 치는 순간 해당 디버그 함수가 트리거되어 런타임 멤버 변수 상태를 실시간 텍스트로 깔끔하게 덤프해 볼 수 있어 트러블슈팅 속도가 몰라보게 빨라집니다.
2. Context 하부 getSystemService() 호출 구조로 래핑하여 SDK 배포하기: 외부 앱 개발자나 협력사에게 프레임워크 가이드라인을 제공할 때, ServiceManager.getService(...) 같은 로우 레벨 바인더 접근 코드를 날로 노출하는 것은 아키텍처 은닉성 측면에서 좋지 않습니다. Context.java와 SystemServiceRegistry.java 소스코드에 내 커스텀 매니저 객체를 등록해 두면, 클라이언트 앱단에서 구글 순정 기능들처럼 CustomManager manager = context.getSystemService(Context.CUSTOM_HARDWARE_SERVICE); 포맷으로 깔끔하게 한 줄 호출할 수 있는 명품 SDK 환경을 구축할 수 있습니다.

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

1. 매니저 API(Wrapper) 내부에서 무거운 상태값 관리: NotificationManager 같은 매니저 클래스 내부에 전역 멤버 변수를 선언하고 공유 데이터를 저장하려고 시도하는 실수입니다. 거듭 강조하지만 매니저 객체는 해당 API를 호출한 각 앱 프로세스의 로컬 메모리(Heap)에 독립적으로 생성되는 일회성 비상주 객체입니다. 앱이 꺼지면 매니저 내부 데이터도 한 줌의 재로 사라지므로, 시스템 전역에서 영구히 유지되어야 하는 핵심 마스터 데이터는 무조건 SystemServer 프로세스 영역에서 도는 진짜 시스템 서비스 클래스 내부에 선언해 두어야 안전합니다.
2. SystemServer 내부 바인더 스레드에서의 동기식 파일 I/O 수행: 내가 만든 커스텀 서비스 바인더 함수 내부에서 대용량 텍스트 설정을 파싱하거나 동기식 디스크 I/O 루프를 무방비하게 돌리는 행위입니다. 바인더 요청이 들어왔을 때 이 로직을 동기식으로 처리하느라 시스템 서버의 핵심 스레드가 길게 붙잡히면, 단말기 전체 시스템의 다른 바인더 요청들까지 줄줄이 락(Lock) 경합에 빠져 단말이 수 초간 얼어버리는 시스템 전체 ANR 대폭발 현상을 조우하게 됩니다. 무거운 연산이나 파일 I/O는 무조건 시스템 전역 워커 스레드나 내부 큐로 비동기 이격 처리해야 배포 품질을 만족할 수 있습니다.

---

5. 결론

안드로이드 시스템 서비스를 직접 설계하고 이식할 수 있다는 것은, 단순히 구글이 만들어 놓은 샌드박스 정원 안에서 노는 앱 개발자를 넘어 운영체제 인프라 전체의 가동 규칙을 내 입맛대로 주무를 수 있는 강력한 마스터 키를 쥐게 됨을 의미합니다.

처음에는 AIDL 인터페이스 정의와 바인더 마샬링 규격이 조금 낯설고 복잡하게 느껴질 수 있지만, SystemServer 내부에서 스레드가 상주하는 방식과 이를 앱단 매니저 프록시가 어떻게 중계해 주는지 그 핵심 원리만 꿰뚫고 있다면 플랫폼 최적화와 커스텀 디바이스 양산 제어는 생각보다 명쾌하게 풀립니다. 내가 만든 커스텀 서비스를 SystemServer.java에 넣고 빌드하는 도중 컴파일 예외가 터지거나, 클라이언트 앱에서 바인더 링크를 땡겨올 때 NullPointerException 거부 에러가 발생해 헤매고 계신다면 혼자 끙끙 앓지 마시고 하단 댓글 창에 소스 구조를 공유해 주세요. 로우 레벨 레이어에서 어떤 고리가 꼬였는지 함께 시원하게 풀어봅시다!