Android 오픈소스 프로젝트 (AOSP)는 공개적으로 사용 가능하고 수정 가능한 Android 소스 코드입니다. 누구나 기기에 맞는 AOSP를 다운로드하여 수정할 수 있습니다. AOSP는 Android 모바일 플랫폼의 완전하고 모든 기능을 갖춘 구현을 제공합니다.
AOSP를 구현하는 기기에는 두 가지 호환성 수준, AOSP 호환성과 Android 호환성이 있습니다. AOSP 호환 기기는 호환성 정의 문서(CDD)의 요구사항 목록을 준수해야 합니다. Android 호환 기기는 CDD 및 공급업체 소프트웨어 요구사항(VSR)의 요구사항 목록을 준수하고 공급업체 테스트 모음(VTS) 및 호환성 테스트 모음(CTS)과 같은 테스트를 실행해야 합니다. Android 호환성에 관한 자세한 내용은 Android 호환성 프로그램을 참고하세요.
AOSP 아키텍처
AOSP용 소프트웨어 스택에는 다음과 같은 레이어가 포함됩니다.
그림 1. AOSP 소프트웨어 스택 아키텍처
다음은 그림 1에서 사용되는 용어의 정의 목록입니다.
Android 앱
Android API만 사용하여 만든 앱입니다. Google Play 스토어는 Android 앱을 찾고 다운로드하는 데 널리 사용되지만 다른 방법도 많이 있습니다. 기기 제조업체에서 기기의 핵심 기능을 지원하기 위해 Android 앱을 사전 설치해야 하는 경우도 있습니다. Android 앱 개발에 관심이 있다면 developers.android.com을 참고하세요.
권한이 있는 앱
Android와 시스템 API를 조합하여 만든 앱입니다. 이러한 앱은 기기에 권한이 있는 앱으로 사전 설치되어 있어야 합니다.
기기 제조업체 앱
Android API, 시스템 API, Android 프레임워크 구현에 관한 직접 액세스를 조합하여 만든 앱입니다. 기기 제조업체가 Android 프레임워크 내에서 불안정한 API에 직접 액세스할 수도 있으므로 이러한 앱은 기기에 사전 설치되어 있어야 하며 기기의 시스템 소프트웨어가 업데이트될 때만 업데이트할 수 있습니다.
시스템 API
시스템 API는 파트너 및 OEM이 번들 애플리케이션에 포함하기 위해서만 사용할 수 있는 Android API를 나타냅니다. 이러한 API는 소스 코드에서 @SystemApi로 표시합니다.
Android API
Android API는 서드 파티 Android 앱 개발자에게 공개적으로 제공되는 API입니다. Android API에 관한 자세한 내용은 Android API 참조를 확인하세요.
Android 프레임워크
앱이 기반하는 자바 클래스, 인터페이스, 기타 사전 컴파일된 코드 그룹입니다. 프레임워크의 일부는 Android API를 사용하여 공개적으로 액세스할 수 있습니다. 그 외의 프레임워크 부분은 시스템 API 사용을 통해 OEM에만 제공됩니다. Android 프레임워크 코드는 앱의 프로세스 내에서 실행됩니다.
시스템 서비스
시스템 서비스는 system_server, SurfaceFlinger, MediaService와 같은 집중된 모듈식 구성요소입니다. Android 프레임워크 API에 의해 노출된 기능은 시스템 서비스와 통신하여 기본 하드웨어에 액세스합니다.
Android 런타임(ART)
AOSP에서 제공하는 자바 런타임 환경입니다. ART는 앱의 바이트 코드를 기기의 런타임 환경에서 실행되는 프로세서별 명령으로 변환합니다.
하드웨어 추상화 계층(HAL)
HAL은 하드웨어 공급업체에서 구현할 표준 인터페이스가 포함된 추상화 계층입니다. HAL을 사용하면 Android가 하위 수준의 드라이버 구현을 고려하지 않아도 됩니다. HAL을 사용하면 상위 수준 시스템에 영향을 주거나 수정하지 않고도 기능을 구현할 수 있습니다. 자세한 내용은 HAL 개요를 참고하세요.
네이티브 데몬 및 라이브러리
이 레이어의 네이티브 데몬에는 init, healthd, logd, storaged가 포함됩니다. 이러한 데몬은 커널 또는 다른 인터페이스와 직접 상호작용하며 사용자 공간을 기반으로 하는 HAL 구현에 의존하지 않습니다.
이 레이어의 네이티브 라이브러리에는 libc, liblog, libutils, libbinder, libselinux가 있습니다. 이러한 네이티브 라이브러리는 커널 또는 다른 인터페이스와 직접 상호작용하며 사용자 공간을 기반으로 하는 HAL 구현에 의존하지 않습니다.
커널
커널은 모든 운영체제의 중심이며 기기의 기본 하드웨어와 통신합니다. 가능한 경우 AOSP 커널은 하드웨어 제약이 없는 모듈과 공급업체별 모듈로 분할됩니다. 정의를 비롯하여 AOSP 커널 구성요소에 관한 자세한 내용은 커널 개요를 참고하세요.
특정 AOSP 레이어에 관해 자세히 알아보려면 왼쪽 탐색 메뉴에서 섹션 이름을 클릭하여 해당 섹션의 개요부터 시작하세요.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-24(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-24(UTC)"],[],[],null,["# Architecture overview\n\nThe *Android Open Source Project (AOSP)* is publicly available and modifiable\nAndroid source code. Anyone can download and modify AOSP for their device. AOSP\nprovides a complete and fully functional implementation of the Android mobile\nplatform.\n| **Note:** AOSP can't provide support for apps that require backend services, such as a cloud messaging or advanced location services app. AOSP also doesn't include a full set of end-user apps that might be needed for particular types of devices.\n\nThere are two levels of compatibility for devices implementing AOSP: AOSP\ncompatibility and Android compatibility. An *AOSP-compatible device* must\nconform to the list of requirements in the\n[Compatibility Definition Document (CDD)](/docs/compatibility/cdd). An\n*Android-compatible device* must conform to the list of requirements in the CDD\nand Vendor Software Requirements (VSR) and tests such as those in the\n[Vendor Test Suite (VTS)](/docs/core/tests/vts) and\n[Compatibility Test Suite (CTS)](/docs/compatibility/cts). For further\ninformation on Android compatibility, refer to the\n[Android compatibility program](/docs/compatibility).\n\nAOSP architecture\n-----------------\n\nThe software stack for AOSP contains the following layers:\n\n**Figure 1.** AOSP software stack architecture.\n\nFollowing is a list of definitions for terms used in Figure 1:\n\n*Android app*\n: An app created solely using the Android API. Google\n Play Store is widely used to find and download Android apps, though there are\n many other alternatives. In some cases, a device manufacturer might want to\n preinstall an Android app to support the core functionality of the device. If\n you're interested in developing Android apps, refer to\n [developers.android.com](https://developer.android.com/).\n\n*Privileged app*\n: An app created using a combination of the Android and system APIs. These apps\n must be preinstalled as privileged apps on a device.\n\n*Device manufacturer app*\n: An app created using a combination of the Android API, system API, and direct\n access to the Android framework implementation. Because a device manufacturer\n might directly access unstable APIs within the Android framework, these apps\n must be preinstalled on the device and can be updated only when the device's\n system software is updated.\n\n*System API*\n: The System API represents Android APIs available only to partners and\n OEMs for inclusion in bundled applications. These APIs are marked as @SystemApi\n in the source code.\n\n*Android API*\n: The Android API is the publicly available API for third-party Android app\n developers. For information on the Android API, refer to\n [Android API reference](https://developer.android.com/reference).\n\n*Android framework*\n: A group of Java classes, interfaces, and other precompiled code upon which\n apps are built. Portions of the framework are publicly accessible through the\n use of the Android API. Other portions of the framework are\n available only to OEMs through the use of the system APIs. Android\n framework code runs inside an app's process.\n\n*System services*\n: System services are modular, focused components such as `system_server`,\n SurfaceFlinger, and MediaService. Functionality exposed by Android framework API\n communicates with system services to access the underlying hardware.\n\n*Android runtime (ART)*\n: A Java runtime environment provided by AOSP. ART performs the\n translation of the app's bytecode into processor-specific instructions\n that are executed by the device's runtime environment.\n\n*Hardware abstraction layer (HAL)*\n: A HAL is an abstraction layer with a standard interface for hardware vendors\n to implement. HALs allow Android to be agnostic about lower-level driver\n implementations. Using a HAL lets you implement functionality without\n affecting or modifying the higher level system. For further information,\n see the [HAL overview](/docs/core/architecture/hal).\n\n*Native daemons and libraries*\n\n: Native daemons in this layer include `init`, `healthd`, `logd`, and\n `storaged`. These daemons interact directly with the kernel or other interfaces\n and don't depend on a userspace-based HAL implementation.\n\n Native libraries in this layer include `libc`, `liblog`, `libutils`,\n `libbinder`, and `libselinux`. These Native libraries interact directly with\n the kernel or other interfaces and don't depend on a userspace-based HAL\n implementation.\n\n*Kernel*\n\n: The kernel is the central part of any operating system and talks to the\n underlying hardware on a device. Where possible, the AOSP kernel is split\n into hardware-agnostic modules and vendor-specific modules. For a description,\n including definitions, of AOSP kernel components, refer to the\n [Kernel overview](/docs/core/architecture/kernel).\n\nWhat's next?\n------------\n\n- If you're new to AOSP, and want to get started with development, refer to the [Get started section](/docs/setup).\n- If you want to learn more about a specific layer of AOSP, click the section's name in the left navigation and begin with the overview for that section."]]
