2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main 대신 android-latest-release를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
AIDL 개요
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
Android 인터페이스 정의 언어(AIDL)는 사용자가 IPC를 추상화하는 데 사용하는 도구입니다. .aidl 파일에서 지정된 인터페이스의 경우 다양한 빌드 시스템에서 C++ 또는 자바 바인딩을 구성하는 데 aidl 바이너리를 사용하므로 런타임이나 비트율과 상관없이 프로세스 간에 인터페이스가 사용될 수 있습니다.
AIDL은 Android의 모든 프로세스, 즉 플랫폼 구성요소 간 또는 앱 간에 사용됩니다. 그러나 앱의 API로 사용되지는 않습니다. 예를 들어 AIDL은 플랫폼에서 SDK API를 구현하는 데 사용될 수 있지만 SDK API 노출 영역에는 AIDL API가 직접 포함되지 않습니다. 앱 간에 AIDL을 직접 사용하는 방법은 관련 Android 개발자 문서를 참고하세요.
AIDL이 개별적으로 업데이트되는 플랫폼 구성요소(예: Android 10부터는 APEX 또는 Android 11부터는 HAL) 간에 사용되면 안정적 AIDL이라는 버전 관리 시스템을 사용해야 합니다.
예
다음은 AIDL 인터페이스의 예입니다.
package my.package;
import my.package.Baz; // defined elsewhere
interface IFoo {
void doFoo(Baz baz);
}
서버 프로세스는 인터페이스를 등록하여 인터페이스 호출을 처리하며 클라이언트 프로세스는 이러한 인터페이스를 호출합니다. 대부분의 경우 프로세스는 여러 인터페이스를 참조할 수 있으므로 클라이언트와 서버 역할을 모두 합니다. AIDL 언어에 관한 자세한 내용은 AIDL 언어를 참고하세요. 인터페이스에서 사용할 수 있는 다양한 런타임에 관한 자세한 내용은 AIDL 백엔드를 참고하세요. 관련 유형 선언은 주어진 언어의 클래스 선언과 정확히 동일하지만 프로세스 간에 작동합니다.
작동 방식
AIDL은 호출 작업에 바인더 커널 드라이버를 사용합니다. 호출이 이루어지면 메서드 식별자와 모든 객체는 버퍼에 압축된 후 바인더 스레드가 데이터 읽기 작업을 대기 중인 원격 프로세스에 복사됩니다. 바인더 스레드가 트랜잭션 데이터를 수신하면 스레드는 로컬 프로세스에서 네이티브 스터브 객체를 찾으며, 클래스는 데이터를 압축해제한 후 로컬 인터페이스 객체를 호출합니다. 호출된 로컬 인터페이스 객체는 서버 프로세스에서 만들고 등록하는 객체입니다. 동일한 프로세스와 동일한 백엔드에서 호출이 이루어지는 경우 프록시 객체가 없으므로 압축 또는 압축해제 작업 없이 바로 호출이 발생합니다. 자세한 내용은 바인더 개요를 참고하세요.
기기 서비스와 상호작용
Android에서 제공하는 명령어를 사용하여 기기 서비스와 상호작용할 수 있습니다. 다음을 시도해 보세요.
adb shell dumpsys --help # listing and dumping services
adb shell service --help # sending commands to services for testing
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-30(UTC)
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-30(UTC)"],[],[],null,["# AIDL overview\n\nThe Android Interface Definition Language (AIDL) is a tool that lets users\nabstract away IPC. Given an interface (specified in a `.aidl`\nfile), various build systems use the `aidl` binary to construct C++ or Java\nbindings so that this interface can be used across processes, regardless of the\nruntime or bitness there.\n\nAIDL can be used between any process in Android: between platform components\nor between apps. However, it is never used as an API for apps. AIDL may be used\nto implement an SDK API in the platform, for example, but the SDK API surface\nnever contains AIDL APIs directly. For documentation about how to use AIDL\nbetween apps directly, see corresponding\n[Android developers\ndocumentation](https://developer.android.com/guide/components/aidl).\nWhen AIDL is used between platform components that are updated separately, such\nas APEXes (starting in Android 10) or HALs (starting in\nAndroid 11), the versioning system known as\n[Stable AIDL](/docs/core/architecture/aidl/stable-aidl) must be used.\n\nExample\n-------\n\nHere is an example AIDL interface: \n\n package my.package;\n\n import my.package.Baz; // defined elsewhere\n\n interface IFoo {\n void doFoo(Baz baz);\n }\n\nA *server* process registers an interface and serves calls to it, and a *client*\nprocess makes calls to those interfaces. In many cases, a process acts as both a\nclient and a server since it may be referencing multiple interfaces. For more\ndetails about the AIDL language, see\n[AIDL language](/docs/core/architecture/aidl/aidl-language). For more details\nabout the various runtimes available to use these interfaces, see\n[AIDL backends](/docs/core/architecture/aidl/aidl-backends). These type\ndeclarations are exactly like a class declaration in a given language, but they\nwork across processes.\n\nHow it works\n------------\n\nAIDL uses the binder kernel driver to make calls. When you make a call, a\nmethod identifier and all of the objects are packed onto a buffer and copied to\na remote process where a binder thread waits to read the data. Once a binder\nthread receives data for a transaction, the thread looks up a native stub object\nin the local process, and this class unpacks the data and makes a call on a\nlocal interface object. This local interface object is the one a server process\ncreates and registers. When calls are made in the same process and the same\nbackend, no proxy objects exist, and so calls are direct without any\npacking or unpacking. For further information, see the\n[Binder overview](/docs/core/architecture/ipc/binder-overview).\n\nInteract with services on the device\n------------------------------------\n\nAndroid comes with a few commands to allow interacting with services on the\ndevice. Try: \n\n adb shell dumpsys --help # listing and dumping services\n adb shell service --help # sending commands to services for testing"]]
