Application과 Framework의 관계

Application과 Framework의 관계

Android 프레임워크는 애플리케이션이 운영 체제와 상호작용할 수 있도록 제공되는 중요한 계층입니다. Android 애플리케이션(Application)은 직접 커널이나 하드웨어를 다루지 않고, Android 프레임워크를 통해 시스템 리소스에 접근하게 됩니다. 즉, Android 프레임워크는 애플리케이션과 시스템의 중간 계층 역할을 수행하며, 애플리케이션이 운영 체제의 내부 구조를 몰라도 다양한 기능을 활용할 수 있도록 추상화된 API를 제공합니다.

Android 시스템의 계층 구조

Android 시스템은 여러 계층으로 구성되어 있으며, 일반적으로 다음과 같은 구조를 가집니다.

1. 애플리케이션(Application Layer): 사용자가 직접 실행하는 애플리케이션으로, Java 또는 Kotlin 언어로 개발됩니다.
2. 애플리케이션 프레임워크(Application Framework Layer): 애플리케이션이 활용할 수 있는 다양한 시스템 서비스 및 API를 제공하는 계층입니다.
3. 네이티브 라이브러리(Native Libraries & Runtime Layer): C/C++로 작성된 네이티브 라이브러리 및 Android Runtime(ART, 이전의 Dalvik VM 포함)이 포함됩니다.
4. 하드웨어 추상화 계층(HAL, Hardware Abstraction Layer): 하드웨어를 제어하기 위한 인터페이스를 제공하여, 상위 계층에서 하드웨어를 직접 다루지 않도록 합니다.
5. 커널(Linux Kernel): 장치 드라이버 및 프로세스 관리, 메모리 관리, 네트워크 등의 핵심 기능을 담당합니다.

애플리케이션은 직접 커널과 상호작용하지 않으며, 항상 Android 프레임워크를 통해 시스템 리소스를 요청하고 사용합니다.

앱과 시스템 서비스의 상호작용 방식

Android 애플리케이션이 시스템 기능을 활용하기 위해서는 Android 프레임워크에서 제공하는 시스템 서비스를 사용해야 합니다. 이러한 서비스는 Context 객체를 통해 접근할 수 있으며, 대표적인 예로 LocationManager, WindowManager, AudioManager 등이 있습니다.

Binder IPC를 통한 애플리케이션과 시스템 서비스 간의 통신

Android에서는 Binder라는 IPC(Inter-Process Communication) 메커니즘을 사용하여 애플리케이션과 시스템 서비스 간의 통신을 수행합니다. Binder는 클라이언트-서버 모델을 기반으로 하며, 애플리케이션은 시스템 서비스의 클라이언트 역할을 합니다.

1. 애플리케이션이 Context.getSystemService()를 호출하여 시스템 서비스에 접근 요청을 보냅니다.
2. 해당 요청은 ServiceManager를 통해 적절한 서비스에 전달됩니다.
3. 서비스는 요청을 처리한 후 결과를 클라이언트(애플리케이션)에게 반환합니다.

이를 AOSP 코드에서 확인하면 다음과 같습니다.

예제: getSystemService()의 내부 동작

// 애플리케이션 코드에서 LocationManager 가져오기
LocationManager locationManager = (LocationManager) getSystemService(Context.LOCATION_SERVICE);

getSystemService()는 내부적으로 ServiceManager를 통해 해당 서비스의 Binder 인터페이스를 가져옵니다.

@UnsupportedAppUsage
public Object getSystemService(String name) {
    return SystemServiceRegistry.getSystemService(this, name);
}

SystemServiceRegistry 내부에서는 Binder를 통해 실제 시스템 서비스 객체를 가져옵니다.

public static Object getSystemService(ContextImpl ctx, String name) {
    ServiceFetcher<?> fetcher = SYSTEM_SERVICE_FETCHERS.get(name);
    return fetcher.getService(ctx);
}

이렇게 호출된 시스템 서비스는 Binder IPC를 통해 실제 서비스 프로세스에서 실행됩니다.

Context와 System Service

Android에서 Context는 애플리케이션 환경에 대한 정보를 제공하고 시스템 서비스에 접근할 수 있도록 해주는 중요한 역할을 합니다. 모든 애플리케이션 컴포넌트(액티비티, 서비스 등)는 Context를 상속받으며, 이를 통해 다양한 시스템 서비스를 호출할 수 있습니다.

Context의 주요 역할

1. 리소스 및 환경 정보 제공: 애플리케이션 리소스, 데이터베이스, 파일 시스템 등에 접근할 수 있도록 합니다.
2. 시스템 서비스 관리: getSystemService()를 통해 시스템 서비스를 제공받습니다.
3. 애플리케이션 생명주기 관리: Context를 이용하여 애플리케이션 생명주기 관련 작업을 수행합니다.
4. 브로드캐스트 및 인텐트 관리: 브로드캐스트 리시버를 등록하고 인텐트를 전송하는 역할을 합니다.

Application Context vs Activity Context

Android에서는 Context의 종류가 여러 가지가 있으며, 대표적으로 Application Context와 Activity Context가 있습니다.

• Application Context: 애플리케이션 전체에서 사용되는 Context로, 애플리케이션이 실행되는 동안 유지됩니다. 주로 서비스나 장기 실행 작업에서 사용됩니다.
• Activity Context: 특정 액티비티에 종속된 Context로, 액티비티가 종료되면 해당 Context도 사라집니다. UI 관련 작업에서는 Activity Context를 사용하는 것이 적절합니다.

// Application Context 사용 예
Context appContext = getApplicationContext();

// Activity Context 사용 예
Context activityContext = this;

시스템 서비스 활용 예제

// WindowManager 서비스 사용 예
WindowManager windowManager = (WindowManager) getSystemService(Context.WINDOW_SERVICE);
Display display = windowManager.getDefaultDisplay();

// AudioManager 서비스 사용 예
AudioManager audioManager = (AudioManager) getSystemService(Context.AUDIO_SERVICE);
audioManager.setStreamVolume(AudioManager.STREAM_MUSIC, 5, 0);

결론

Android 프레임워크는 애플리케이션이 직접 운영 체제와 상호작용하지 않고도 다양한 기능을 활용할 수 있도록 돕는 중요한 계층입니다. 애플리케이션은 Android 프레임워크에서 제공하는 API를 활용하여 시스템 서비스와 상호작용하며, 이를 통해 화면 출력, 오디오 제어, 위치 정보 제공 등의 기능을 사용할 수 있습니다. 이러한 시스템 서비스는 Context를 통해 접근할 수 있으며, 내부적으로는 Binder IPC를 이용하여 애플리케이션과 시스템 서비스 간의 통신이 이루어집니다.

이를 통해 Android 애플리케이션은 안정적이고 효율적으로 시스템 리소스를 사용할 수 있으며, 개발자는 복잡한 운영 체제의 내부 동작을 몰라도 쉽게 기능을 구현할 수 있습니다.