개발자 도도

앱 개발 중 Trouble shooting

냥냥냥냥냥냥 — Sat, 8 Feb 2025 23:14:56 +0900

Compose를 이용해서 앱 짜보면서 발생한 trouble shooting 정리해보는 건입니다

build.gradle.kts에 implementation 안 되는 사항

// build.gradle.kts

// Top-level build file where you can add configuration options common to all sub-projects/modules.
plugins {
    alias(libs.plugins.android.application) apply false
    alias(libs.plugins.kotlin.android) apply false
}

dependencies {
    implementation("androidx.navigation:navigation-compose:2.8.6")
}

Unresolved reference: implementation 과 같은 상황이 발생 시,

// build.gradle.kts

plugins {
    alias(libs.plugins.android.application)
    alias(libs.plugins.kotlin.android)
}

apply false 삭제 하면 됩니다

Cause: compileSdkVersion is not specified. Please add it to build.gradle

// build.gradle.kts (:app)

android {
  // 여기에 compileSdk 설정 안 되어 있어서 발생

여기서 compileSdk가 빠져있어서 발생

// build.gradle.kts (:app)

android {

  compileSdk = 34 // 이렇게 추가

Data Science | numpy, pandas

냥냥냥냥냥냥 — Wed, 5 Feb 2025 09:27:37 +0900

사내 데이터 싸이언스 시험을 위해 정리하기 위한 용도로 남겨 둡니다

다른 분들께도 유용할 수 있다면 좋겠네요

주피터 노트북을 설치하고 로컬로 사용을 하셔도 되지만 저의 개발 환경은 코랩을 사용하고 있습니다

https://colab.research.google.com/

Google Colab

colab.research.google.com

Python 라이브러리 중 데이터 분석을 유용하게 하기 위한 라이브러리로 numpy, pandas 가 있습니다

numpy

numpy는 아래처럼 import를 합니다

(as np는 안써도 상관 없는데 이렇게들 많이 쓰더라구요)

numpy로는 array만 사용해보긴 했습니다

아래처럼 1차원 배열을 만들 수 있습니다

2차원 배열 뿐만 아니라 그 이상의 차원의 배열도 만들 수 있습니다

array 첫 대괄호 [ 의 개수가 몇 개인지 보면 몇 차원 배열인 지 알 수 있습니다

학창 시절 배웠던 통계를 기억해보면,

"합(sum), 최대값(max), 최소값(min), 평균(mean), 분산(var), 표준편차(std)" 등등을 확인을 했던 거 같네요

1차원 배열 1 , 2, 3이 들어 있는 array에서 쭈욱 한 번 구해봤습니다

pandas

pandas는 아래와 같이 import 합니다

pandas에도 array가 존재하지만 여기선 좀 더 이쁜 Series 라는 애가 있습니다

Series

series는 1차원 배열과 같은 자료 구조입니다

array를 출력했을 때와 달리 레이블로 이쁘게 보여집니다

Series 출력 시	Array 출력시

numpy의 array에서 구해본 것 처럼 여기서도 통계에서 기초적으로 쓰이는 값들을 구해봤습니다

DataFrame

dataFrame은 2차원 배열과 같은 자료 구조입니다

사실 dataFrame을 많이 사용 합니다

torchrun을 실행 했을 때 일어나는 동작들

냥냥냥냥냥냥 — Sun, 29 Dec 2024 15:29:17 +0900

딥러닝이 한창 열풍인 요즘, 딥러닝 관련 프레임워크로는

파이토치, 텐서플로, 케라스 등등이 많이 쓰이고 있는 것으로 보입니다

최근 ai 관련 교육을 들으며 파이토치 library 사용하는 것을 배웠는데, 그 때부터 파이토치에 대해 호기심이 생기더라구요

따라서 이번에는 파이토치에서 근간이 되는 torchrun을 실행할 때 어떤 일이 일어나는 지 한 번 알아보고자 합니다

torchrun (Elastic Launch) — PyTorch 2.5 documentation

torchrun (Elastic Launch) Superset of torch.distributed.launch. torchrun provides a superset of the functionality as torch.distributed.launch with the following additional functionalities: Worker failures are handled gracefully by restarting all workers. W

pytorch.org

위의 pytorch 사이트에서 보면 torchrun api에 대한 설명이 있습니다

Note

torchrun is a python console script to the main module torch.distributed.run declared in the entry_points configuration in setup.py. It is equivalent to invoking python -m torch.distributed.run.

이 부분을 실제 코드에서 어떻게 연결되는지 한 번 보려고 합니다

torchrun의 위치

pytorch/setup.py at main · pytorch/pytorch

Tensors and Dynamic neural networks in Python with strong GPU acceleration - pytorch/pytorch

github.com

    entry_points = {
        "console_scripts": [
            "torchrun = torch.distributed.run:main",
        ],

torchrun은 결국 torch.distributed.run의 main함수와 연결 됩니다

torch.distributed.run의 main함수는 아래와 같이 구성 되어 있습니다

def run(args):
    torch.multiprocessing._set_thread_name("pt_elastic")

    if args.standalone:
        args.rdzv_backend = "c10d"
        args.rdzv_endpoint = "localhost:0"
        args.rdzv_id = str(uuid.uuid4())
        logger.info(
            "\n**************************************\n"
            "Rendezvous info:\n"
            "--rdzv-backend=%s "
            "--rdzv-endpoint=%s "
            "--rdzv-id=%s\n"
            "**************************************\n",
            args.rdzv_backend,
            args.rdzv_endpoint,
            args.rdzv_id,
        )

    config, cmd, cmd_args = config_from_args(args)
    elastic_launch(
        config=config,
        entrypoint=cmd,
    )(*cmd_args)


@record
def main(args=None):
    args = parse_args(args)
    run(args)


if __name__ == "__main__":
    main()

‎config_from_args 내부에서 --nnode = 1 --nproc-per-node=$NUM_TRAINERS 등과 같은 arg로 넘겨준 값들을

parsing을 하고 elastic_launch에 인자로 넘겨줍니다

class elastic_launch:
...

    def __init__(
        self,
        config: LaunchConfig,
        entrypoint: Union[Callable, str, None],
    ):
        self._config = config
        self._entrypoint = entrypoint

    def __call__(self, *args):
        return launch_agent(self._config, self._entrypoint, list(args))

elastic_launch 객체를 실제 call 해줄 때, launch_agent가 실행되며 코드는 아래와 같습니다

def launch_agent(
    config: LaunchConfig,
    entrypoint: Union[Callable, str, None],
    args: List[Any],
) -> Dict[int, Any]:
...

    agent = LocalElasticAgent(
        spec=spec,
        logs_specs=config.logs_specs,  # type: ignore[arg-type]
        start_method=config.start_method,
        log_line_prefix_template=config.log_line_prefix_template,
    )

    shutdown_rdzv = True
    try:
        metrics.initialize_metrics(metrics.MetricsConfig(config.metrics_cfg))

        result = agent.run()
        # records that agent.run() has succeeded NOT that workers have succeeded
        events.record(agent.get_event_succeeded())

launch_agent에서는 LocalElasticAgent를 run을 해줍니다

class LocalElasticAgent(SimpleElasticAgent):

LocalElasticAgent는 simpleElasticAgent를 상속받고 있고 거기에 run 메서드가 있습니다

    @prof
    def run(self, role: str = DEFAULT_ROLE) -> RunResult:
        start_time = time.monotonic()
        shutdown_called: bool = False
        try:
            result = self._invoke_run(role)
            self._total_execution_time = int(time.monotonic() - start_time)
            self._record_metrics(result)
            self._record_worker_events(result)
            return result

run 안에서는 _invoke_run을 실행해주는게 핵심인데,

    def _invoke_run(self, role: str = DEFAULT_ROLE) -> RunResult:
        # NOTE: currently only works for a single role

        spec = self._worker_group.spec
        role = spec.role

        logger.info(
            "[%s] starting workers for entrypoint: %s", role, spec.get_entrypoint_name()
        )

        self._initialize_workers(self._worker_group)
        monitor_interval = spec.monitor_interval
        rdzv_handler = spec.rdzv_handler

        while True:
            assert self._worker_group.state != WorkerState.INIT
            time.sleep(monitor_interval)
            run_result = self._monitor_workers(self._worker_group)
            state = run_result.state
            self._worker_group.state = state

            put_metric(f"workers.{role}.remaining_restarts", self._remaining_restarts)
            put_metric(f"workers.{role}.{state.name.lower()}", 1)

            if state == WorkerState.SUCCEEDED:
                logger.info(
                    "[%s] worker group successfully finished."
                    " Waiting %s seconds for other agents to finish.",
                    role,
                    self._exit_barrier_timeout,
                )
                self._exit_barrier()
                return run_result
            elif state in {WorkerState.UNHEALTHY, WorkerState.FAILED}:
                if self._remaining_restarts > 0:
                    logger.info(
                        "[%s] Worker group %s. "
                        "%s/%s attempts left;"
                        " will restart worker group",
                        role,
                        state.name,
                        self._remaining_restarts,
                        spec.max_restarts,
                    )
                    self._remaining_restarts -= 1
                    self._restart_workers(self._worker_group)
                else:
                    self._stop_workers(self._worker_group)
                    self._worker_group.state = WorkerState.FAILED
                    return run_result
            elif state == WorkerState.HEALTHY:
                # membership changes do not count as retries
                num_nodes_waiting = rdzv_handler.num_nodes_waiting()
                group_rank = self._worker_group.group_rank
                if num_nodes_waiting > 0:
                    logger.info(
                        "[%s] Detected %s "
                        "new nodes from group_rank=%s; "
                        "will restart worker group",
                        role,
                        num_nodes_waiting,
                        group_rank,
                    )
                    self._restart_workers(self._worker_group)
            else:
                raise Exception(  # noqa: TRY002
                    f"[{role}] Worker group in {state.name} state"
                )

_monitor_workers를 실행하고 그로 부터 받은 state에 따라 처리를 해주는 식이네요

_monitor_workers는 abstractmethod 입니다 구현부가 따로 어딘가에 있겠죠 ㅎㅎ

결국, 아래와 같이 명령어를 입력해주면

tochrun뒤에 붙은 argument 들은 config_from_args을 통해 parsing 되어

Elastic_Launch 객체를 실행하고, 내부적인 동작은 LocalElasticAgent의 _invoke_run을 실행하는 것입니다

torchrun
    --standalone
    --nnodes=1
    --nproc-per-node=$NUM_TRAINERS
    YOUR_TRAINING_SCRIPT.py (--arg1 ... train script args...)

읽어 주셔서 감사합니다

다음 번엔, llama에서 torchrun을 통해 example script 파이썬 파일을 실행 했을 때 어떤 동작이 일어나는지 한 번 알아보도록 하겠습니다

안드로이드 인풋 프레임워크 학습(InputManager) 1

냥냥냥냥냥냥 — Thu, 7 Nov 2024 23:27:08 +0900

이번에는 안드로이드의 input (터치, 제스처 등)을 관리하는 inputManager에 대해서 알아보려고 합니다

inputflinger의 시작은 init.rc가 시작 되는 시점에 inputflinger.rc가 시작 됩니다

// inputflinger.rc
service inputflinger /system/bin/inputflinger
    class main
    user system
    group input wakelock
#    onrestart restart zygote

InputFlinger로 빌드 되어 있는 main.cpp가 시작되고 아래의 코드 순서대로 호출이 됩니다
여기서 봐야할 부분은InputDriver에서 input_open을 호출해주는 부분입니다

// main.cpp
int main(int, char**) {
    ProcessState::self()->setThreadPoolMaxThreadCount(4);
    BinderService<InputFlinger>::publishAndJoinThreadPool(true);  // inputflinger 생성 및 service에 추가
    return 0;
}

// inputflinger.cpp
InputFlinger::InputFlinger() :
        BnInputFlinger() {
    ALOGI("InputFlinger is starting");
    mHost = new InputHost();
    mHost->registerInputDriver(new InputDriver(INPUT_INSTANCE_EVDEV));
}

// inputDriver.cpp
InputDriver::InputDriver(const char* name) : mName(String8(name)) {
    const hw_module_t* module;
    int err = input_open(&module, name);
    LOG_ALWAYS_FATAL_IF(err != 0, "Input module %s not found", name);
    mHal = reinterpret_cast<const input_module_t*>(module);
}

// input.h
static inline int input_open(const struct hw_module_t** module, const char* type) {
    return hw_get_module_by_class(INPUT_HARDWARE_MODULE_ID, type, module);
}


// hardware.c  
int hw_get_module_by_class(const char *class_id, const char *inst,
                           const struct hw_module_t **module)
                           
                           ...
                           
    snprintf(prop_name, sizeof(prop_name), "ro.hardware.%s", name);
    if (property_get(prop_name, prop, NULL) > 0) {
        if (hw_module_exists(path, sizeof(path), name, prop) == 0) {
            goto found;
        }
    }
    /* Loop through the configuration variants looking for a module */
    for (i=0 ; i<HAL_VARIANT_KEYS_COUNT; i++) {
        if (property_get(variant_keys[i], prop, NULL) == 0) {
            continue;
        }
        if (hw_module_exists(path, sizeof(path), name, prop) == 0) {
            goto found;
        }
    }
    /* Nothing found, try the default */
    if (hw_module_exists(path, sizeof(path), name, "default") == 0) {
        goto found;
    }
    return -ENOENT;
found:
    /* load the module, if this fails, we're doomed, and we should not try
     * to load a different variant. */
    return load(class_id, path, module);
}

input_open을 호출해주면 hw_get_module_by_class를 통해서 "input" 이라는 이름의 module을 찾는데
/system/lib/hw, /vendor/lib/hw (64비트면 lib64) path에 라이브러리가 있으면 동적으로 로딩을 해주는 식입니다

// hardware/libhardware/hardware.c
#if defined(__LP64__)
#define HAL_LIBRARY_PATH1 "/system/lib64/hw"
#define HAL_LIBRARY_PATH2 "/vendor/lib64/hw"
#else
#define HAL_LIBRARY_PATH1 "/system/lib/hw"
#define HAL_LIBRARY_PATH2 "/vendor/lib/hw"
#endif

static int hw_module_exists(char *path, size_t path_len, const char *name,
                            const char *subname)
{
    snprintf(path, path_len, "%s/%s.%s.so",
             HAL_LIBRARY_PATH2, name, subname);
    if (access(path, R_OK) == 0)
        return 0;
    snprintf(path, path_len, "%s/%s.%s.so",
             HAL_LIBRARY_PATH1, name, subname);
    if (access(path, R_OK) == 0)
        return 0;
    return -ENOENT;
}

// hardware/libhardware/hardware.c
static int load(const char *id,
        const char *path,
        const struct hw_module_t **pHmi) 
{      
        ...
        
    handle = dlopen(path, RTLD_NOW);
    
    const char *sym = HAL_MODULE_INFO_SYM_AS_STR;
    hmi = (struct hw_module_t *)dlsym(handle, sym);

...

    hmi->dso = handle;
    /* success */
    status = 0;
    
    
...

    *pHmi = hmi;

결국 동적으로 붙은 module을 전달하며, 그 모듈을 mHal로 저장해둡니다 (Hardware Abstract Layer)
inputDriver는 결국 lib단에서 inputFlinger host 단으로 호출될 수 있도록 kCallback을 넘겨줍니다

여느 service들과 마찬가지로 InputManagerService 또한 SystemServer 내에서 시작됩니다

// SystemServer.java
   private void startOtherServices(@NonNull TimingsTraceAndSlog t) {
   
   ...

        InputManagerService inputManager = null;
        
        ...
        
            t.traceBegin("StartInputManagerService");
            inputManager = new InputManagerService(context);
            t.traceEnd();
            
        ...

            t.traceBegin("StartInputManager");
            inputManager.setWindowManagerCallbacks(wm.getInputManagerCallback());
            inputManager.start();

InputManagerService의 시작 process

안드로이드 앱 프레임워크 학습(ActivityManager) 3

냥냥냥냥냥냥 — Sun, 10 Mar 2024 19:22:48 +0900

안드로이드 앱 프레임워크 학습(ActivityManager) 2 (tistory.com)

안드로이드 앱 프레임워크 학습(ActivityManager) 2

안드로이드 앱 프레임워크 학습(ActivityManager) 1 (tistory.com) 안드로이드 앱 프레임워크 학습(ActivityManager) 1 이전에 StartActivity 호출 순서를 블로그로 써본적이 있었는데 (자세한 건 아래 참조 부탁드

nyaang.tistory.com

지난 시간엔 안드로이드 프레임워크에서 process 관리 부분에 대해 간단히 알아 봤습니다

이번에는 안드로이드에서 lmkd (Low Memory Killer Demon)이 뭔지 어떤 동작을 하는지 알아보려고 합니다

android docs를 보면 lmkd의 설명을 아래와 같이 해놓았습니다

Android 로우 메모리 킬러 데몬(lmkd) 프로세스는 실행 중인 Android 시스템의 메모리 상태를 모니터링하고, 시스템 성능을 만족할 만한 수준으로 유지하기 위해 가장 필요성이 적은 프로세스를 종료하여 높은 메모리 압력에 반응합니다.

필요성을 나타내는 값이 OOM_SCORE이고 MIN, MAX값은 아래와 같습니다

// lmkd.cpp
/* OOM score values used by both kernel and framework */
#define OOM_SCORE_ADJ_MIN       (-1000)
#define OOM_SCORE_ADJ_MAX       1000

java 단에서는 lmkdConnection 내에서 LocalSocket을 이용하여 lmkd의 fd을 만들어서 연결하고

// ProcessList.java
    void init(ActivityManagerService service, ActiveUids activeUids,
            PlatformCompat platformCompat) {
            
            ...
            
        if (sKillHandler == null) {
            sKillThread = new ServiceThread(TAG + ":kill",
                    THREAD_PRIORITY_BACKGROUND, true /* allowIo */);
            sKillThread.start();
            sKillHandler = new KillHandler(sKillThread.getLooper());
            sLmkdConnection = new LmkdConnection(sKillThread.getLooper().getQueue(),
                    new LmkdConnection.LmkdConnectionListener() {

native 단에서는 lmkd.rc를 통해서 부팅 후 lmkd의 demon이 시작되며 init에서 lmkd의 fd socket을 연결합니다

// lmkd::init
    ctrl_sock.sock = android_get_control_socket("lmkd");
    if (ctrl_sock.sock < 0) {
        ALOGE("get lmkd control socket failed");
        return -1;
    }

    ret = listen(ctrl_sock.sock, MAX_DATA_CONN);
    if (ret < 0) {
        ALOGE("lmkd control socket listen failed (errno=%d)", errno);
        return -1;
    }

먼저 그럼 java단 부터 sequence를 한 번 보겠습니다

lmkdConnection

native 단의 sequence는 아래와 같습니다

lmkd sequence

사실 lmkd 에서의 init에서 봐야할 사항이 조금 더 있습니다

use_inkernel_interface 값에 따라 분기가 되기 때문입니다

// lmkd::init
    has_inkernel_module = !access(INKERNEL_MINFREE_PATH, W_OK);
    use_inkernel_interface = has_inkernel_module;

    if (use_inkernel_interface) {
        ALOGI("Using in-kernel low memory killer interface");
        if (init_poll_kernel()) {
            epev.events = EPOLLIN;
            epev.data.ptr = (void*)&kernel_poll_hinfo;
            if (epoll_ctl(epollfd, EPOLL_CTL_ADD, kpoll_fd, &epev) != 0) {
                ALOGE("epoll_ctl for lmk events failed (errno=%d)", errno);
                close(kpoll_fd);
                kpoll_fd = -1;
            } else {
                maxevents++;
                /* let the others know it does support reporting kills */
                property_set("sys.lmk.reportkills", "1");
            }
        }
    } else {
        if (!init_monitors()) {
            return -1;
        }
        /* let the others know it does support reporting kills */
        property_set("sys.lmk.reportkills", "1");
    }
    
    
// lmkd::init_monitor
static bool init_monitors() {
    /* Try to use psi monitor first if kernel has it */
    use_psi_monitors = GET_LMK_PROPERTY(bool, "use_psi", true) &&
        init_psi_monitors();
    /* Fall back to vmpressure */
    if (!use_psi_monitors &&
        (!init_mp_common(VMPRESS_LEVEL_LOW) ||
        !init_mp_common(VMPRESS_LEVEL_MEDIUM) ||
        !init_mp_common(VMPRESS_LEVEL_CRITICAL))) {
        ALOGE("Kernel does not support memory pressure events or in-kernel low memory killer");
        return false;
    }
    if (use_psi_monitors) {
        ALOGI("Using psi monitors for memory pressure detection");
    } else {
        ALOGI("Using vmpressure for memory pressure detection");
    }
    return true;
}

또한 psi monitor에서도 use_new_strategy 유무에 따라 달라집니다

init_psi_monitors는 init_monitors가 불릴 때 불려지는 함수이고, use_new_strategy boolean 값에 따라

init_mp_psi 내부에서 handler가 mp_event_psi , mp_event_common으로 나누어집니다

// lmkd::init_psi_monitors
static bool init_psi_monitors() {
    /*
     * When PSI is used on low-ram devices or on high-end devices without memfree levels
     * use new kill strategy based on zone watermarks, free swap and thrashing stats.
     * Also use the new strategy if memcg has not been mounted in the v1 cgroups hiearchy since
     * the old strategy relies on memcg attributes that are available only in the v1 cgroups
     * hiearchy.
     */
    bool use_new_strategy =
        GET_LMK_PROPERTY(bool, "use_new_strategy", low_ram_device || !use_minfree_levels);
        
        ...
        
    if (!init_mp_psi(VMPRESS_LEVEL_LOW, use_new_strategy)) {
        return false;
    }
    if (!init_mp_psi(VMPRESS_LEVEL_MEDIUM, use_new_strategy)) {
        destroy_mp_psi(VMPRESS_LEVEL_LOW);
        return false;
    }
    if (!init_mp_psi(VMPRESS_LEVEL_CRITICAL, use_new_strategy)) {
        destroy_mp_psi(VMPRESS_LEVEL_MEDIUM);
        destroy_mp_psi(VMPRESS_LEVEL_LOW);
        return false;
    }
    
 // lmkd::init_mp_psi   
    vmpressure_hinfo[level].handler = use_new_strategy ? mp_event_psi : mp_event_common;

안에서 좀 로직이 좀 다르긴 한데 handler가 mp_event_psi , mp_event_common 든 상관없이 결국은 find_and_kill_process를 타게 됩니다

find_and_kill_process로직을 보면 OOM_SCORE_ADJ_MAX 부터 내려오면서 체크하고, kill_one_process를 호출합니다

// lmkd::find_and_kill_process
static int find_and_kill_process(int min_score_adj, struct kill_info *ki, union meminfo *mi,
                                 struct wakeup_info *wi, struct timespec *tm,
                                 struct psi_data *pd) {
    int i;
    int killed_size = 0;
    bool lmk_state_change_start = false;
    bool choose_heaviest_task = kill_heaviest_task;

    for (i = OOM_SCORE_ADJ_MAX; i >= min_score_adj; i--) { // MAX 부터 
        struct proc *procp;

        if (!choose_heaviest_task && i <= PERCEPTIBLE_APP_ADJ) {
            /*
             * If we have to choose a perceptible process, choose the heaviest one to
             * hopefully minimize the number of victims.
             */
            choose_heaviest_task = true;
        }

        while (true) {
            procp = choose_heaviest_task ?
                proc_get_heaviest(i) : proc_adj_tail(i);

            if (!procp)
                break;

            killed_size = kill_one_process(procp, min_score_adj, ki, mi, wi, tm, pd); // kill

// lmkd::kill_one_process
static int kill_one_process(struct proc* procp, int min_oom_score, struct kill_info *ki,
                            union meminfo *mi, struct wakeup_info *wi, struct timespec *tm,
                            struct psi_data *pd) {     
                            
                            ...
                            
    kill_result = reaper.kill({ pidfd, pid, uid }, false);

    trace_kill_end();

    if (kill_result) {
        stop_wait_for_proc_kill(false);
        ALOGE("kill(%d): errno=%d", pid, errno);
        /* Delete process record even when we fail to kill so that we don't get stuck on it */
        goto out;
    }
    
    ...
    
out:
    /*
     * WARNING: After pid_remove() procp is freed and can't be used!
     * Therefore placed at the end of the function.
     */
    pid_remove(pid);
    return result;
}

kill_one_process를 보면 reaper.kill 을 호출해주고 이 부분이 실질적인 process kill 부분으로 보입니다

// reaper.cpp
int Reaper::kill(const struct target_proc& target, bool synchronous) {
    /* CAP_KILL required */
    if (target.pidfd < 0) {
        return ::kill(target.pid, SIGKILL);
    }

    if (!synchronous && async_kill(target)) {
        // we assume the kill will be successful and if it fails we will be notified
        return 0;
    }

    int result = pidfd_send_signal(target.pidfd, SIGKILL, NULL, 0);
    if (result) {
        return result;
    }

    return is_reaping_supported() ? process_mrelease(target.pidfd, 0) : 0;
}

감사합니다

안드로이드 앱 프레임워크 학습(ActivityManager) 2

냥냥냥냥냥냥 — Sun, 3 Mar 2024 00:01:06 +0900

안드로이드 앱 프레임워크 학습(ActivityManager) 1 (tistory.com)

안드로이드 앱 프레임워크 학습(ActivityManager) 1

이전에 StartActivity 호출 순서를 블로그로 써본적이 있었는데 (자세한 건 아래 참조 부탁드립니다) Android framework StartActivity 호출 순서 (tistory.com) Android framework StartActivity 호출 순서 안녕하세요, 개

nyaang.tistory.com

여기서는 앱이 실행 될 때, RemoteAnimation, Leash 부분에 대해서 좀 알아봤는데

이번 글에서는 animation 쪽이 아닌 activity, process관리 부분을 한 번 알아보려고 합니다

startProcessLocked sequence

ProcessList 관련 sequence

// ProcessList::startProcessLocked
            // Start the process.  It will either succeed and return a result containing
            // the PID of the new process, or else throw a RuntimeException.
            final String entryPoint = "android.app.ActivityThread";

            return startProcessLocked(hostingRecord, entryPoint, app, uid, gids,
                    runtimeFlags, zygotePolicyFlags, mountExternal, seInfo, requiredAbi,
                    instructionSet, invokeWith, startTime);

ProcessList에서 메서드를 불러주기 전에 entryPoint를 ActivityThread로 설정해서 넘겨줍니다

그렇기에 Zygote의 socket 통신을 통해 넘겨서 실행시켜주는 포인트는 ActivityThread의 main을 실행시켜주게 합니다

아래는 ZygoteProcess에서의 Socket 관련 정보들입니다

// ZygoteProcess.java
    public ZygoteProcess() {
        mZygoteSocketAddress =
                new LocalSocketAddress(Zygote.PRIMARY_SOCKET_NAME,
                                       LocalSocketAddress.Namespace.RESERVED);
        mZygoteSecondarySocketAddress =
                new LocalSocketAddress(Zygote.SECONDARY_SOCKET_NAME,
                                       LocalSocketAddress.Namespace.RESERVED);

        mUsapPoolSocketAddress =
                new LocalSocketAddress(Zygote.USAP_POOL_PRIMARY_SOCKET_NAME,
                                       LocalSocketAddress.Namespace.RESERVED);
        mUsapPoolSecondarySocketAddress =
                new LocalSocketAddress(Zygote.USAP_POOL_SECONDARY_SOCKET_NAME,
                                       LocalSocketAddress.Namespace.RESERVED);

        // This constructor is used to create the primary and secondary Zygotes, which can support
        // Unspecialized App Process Pools.
        mUsapPoolSupported = true;
    }

application이 onCreate 될 때 까지 sequence

ActivityManagerService에서 attachApplicationLocked를 호출해 줄 때, ProcessList에 process관련된 정보를 넘기고

ActivityManagerService내의 mPidSelfLocked에도 pid와 app 관련 해서 저장을 해둡니다

아래는, ActivityThread 관련해서 seq를 저장해두는 부분 코드입니다

// ActivityThread::main
        // Find the value for {@link #PROC_START_SEQ_IDENT} if provided on the command line.
        // It will be in the format "seq=114"
        long startSeq = 0;
        if (args != null) {
            for (int i = args.length - 1; i >= 0; --i) {
                if (args[i] != null && args[i].startsWith(PROC_START_SEQ_IDENT)) {
                    startSeq = Long.parseLong(
                            args[i].substring(PROC_START_SEQ_IDENT.length()));
                }
            }
        }

결국, 안드로이드에서는 Process를 실행할 떄 Zygote를 통한다는 것을 코드 부분을 통해 봤고

실행할 process 관련된 정보는 ActivityThread를 통해서 attach, bind를 통해서 그 정보들을 넘겨주고 주고 받은 후

그 과정이 끝나면 Application의 onCreate를 호출시켜주는 것을 보았습니다

감사합니다!

안드로이드 앱 프레임워크 학습(ActivityManager) 1

냥냥냥냥냥냥 — Fri, 1 Mar 2024 23:45:30 +0900

이전에 StartActivity 호출 순서를 블로그로 써본적이 있었는데 (자세한 건 아래 참조 부탁드립니다)

Android framework StartActivity 호출 순서 (tistory.com)

Android framework StartActivity 호출 순서

안녕하세요, 개발자 도도 입니다 먼저, 저는 현재 안드로이드 프레임워크 개발자로 재직 중 입니다 사실 안드로이드 앱 개발자 입장으로선 프레임워크 코드들은 당연히 되어야 하는 부분이기

nyaang.tistory.com

안드로이드에서 Activity는 4대 컴포넌트 중 하나입니다

화면에 띄우는 방식이 반드시 Activity를 사용해야만 화면에 띄울 수 있는 것은 아니지만

Activity를 사용하면 Framework 단에서 LifeCycle (Resume, Pause, Stop 등과 같은) 관리가 용이하다는 점이 있습니다

이번에는 그 Activity의 LifeCycle등을 관리 해주는 ActivityManager에 대해서 한 번 알아보려고 합니다

// SystemServer::startBootstrapServices

// Activity manager runs the show.
t.traceBegin("StartActivityManager");
// TODO: Might need to move after migration to WM.
ActivityTaskManagerService atm = mSystemServiceManager.startService(
        ActivityTaskManagerService.Lifecycle.class).getService();
mActivityManagerService = ActivityManagerService.Lifecycle.startService(
        mSystemServiceManager, atm);

WindowManagerService 처럼 ActivityManagerService도 SystemServer에서 시작이 됩니다

Activity관련 자료구조

이전 글들에서 WindowManager는 WindowState단위로 관리를 한다고 말씀을 드렸는데 ActivityManager는 ActivityRecord 기준으로 관리를 하게 됩니다 그리고 그 ActivityRecord는 WindowState안에 멤버변수로가지고 있습니다

WindowManager 분석에서는 SurfaceFlinger 부분과의 연결되는 관점 위주로 봤기에 ActivityManager 관련 된 얘기를 안했지만, 사실 Activity가 전환 시 wm 측의 transition 과정이 필요하기 때문에 AM과 WM은 어울려서 동작합니다

예를 들어, 새 activity가 실행 될 때도, multiwindow 상황이 아니라면 하나의 activity 화면을 보여주기 위해, 보이던 앱의 state를 pause -> stop 으로 내려야할 것이고 실행되는 액티비티는 create -> start -> resume으로 바뀌어야할 것입니다

LifeCycle의 변환을 알기 전에 근본적으로 Activity의 전환(transition) 간에 일어나는 상황을 보면

아래와 같습니다

transition sequence

(RootWindowContainer의 openSurfaceTransaction 부분은 WindowManager 분석 때 SurfaceFlinger 관련 연결 부분과 한 번 본적있으니 이전 블로그 글 참고 부탁드립니다)

여기서 좀 봐야할 부분은 AppTransitionController 부분입니다

여기선 RemoteAnimation과 Leash라는 개념이 있는데 Leash는 사전적 의미를 보니 속박 이란 의미로 사용되는 것 같고

RemoteAnimation은 원격 애니메이션이라는 개념일듯 한데, 그걸 생각해보면

SurfaceControl의 layer 전환에 따른 animation => RemoteAnimation

그리고 그 SurfaceControl에 속박된 effectLayer로 사용되는 layer => Leash 로 추정이 됩니다

// SurfaceAnimator::startAnimation
        if (mLeash == null) {
            mLeash = createAnimationLeash(mAnimatable, surface, t, type,
                    mAnimatable.getSurfaceWidth(), mAnimatable.getSurfaceHeight(), 0 /* x */,
                    0 /* y */, hidden, mService.mTransactionFactory);
            mAnimatable.onAnimationLeashCreated(t, mLeash);
        }
        mAnimatable.onLeashAnimationStarting(t, mLeash);
    
...

        mAnimation.startAnimation(mLeash, t, type, mInnerAnimationFinishedCallback);

여기서 받는 mAnimation은 animationAdapter로 WindowContainer에서의 adapter (RemoteAnimationConroller.RemoteAnimationRecord) 입니다

// SurfaceAnimator::startAnimator
    void startAnimation(Transaction t, AnimationAdapter anim, boolean hidden,
            @AnimationType int type,
            @Nullable OnAnimationFinishedCallback animationFinishedCallback,
            @Nullable Runnable animationCancelledCallback,
            @Nullable AnimationAdapter snapshotAnim, @Nullable SurfaceFreezer freezer) {
        mAnimation = anim;
        

// WindowContainer::applyanimationUnchecked
        final Pair<AnimationAdapter, AnimationAdapter> adapters = getAnimationAdapter(lp,
                transit, enter, isVoiceInteraction);
        AnimationAdapter adapter = adapters.first;
        
        ...
        
             animationRunnerBuilder.build()
                    .startAnimation(getPendingTransaction(), adapter, !isVisible(),
                            ANIMATION_TYPE_APP_TRANSITION, thumbnailAdapter);

그 이후 AppTransitionController에서

// AppTransitionController::handleAppTransitionReady

        try {
            applyAnimations(mDisplayContent.mOpeningApps, mDisplayContent.mClosingApps, transit,
                    animLp, voiceInteraction);
            handleClosingApps();
            handleOpeningApps();
            handleChangingApps(transit);

            appTransition.setLastAppTransition(transit, topOpeningApp,
                    topClosingApp, topChangingApp);

            final int flags = appTransition.getTransitFlags();
            layoutRedo = appTransition.goodToGo(transit, topOpeningApp);
            handleNonAppWindowsInTransition(transit, flags);
            appTransition.postAnimationCallback();
            appTransition.clear();
        } finally {
            mService.mSurfaceAnimationRunner.continueStartingAnimations();
        }

        mService.mTaskSnapshotController.onTransitionStarting(mDisplayContent);

handleClosingApps 에서는 일단 떠 있는 앱의 Visibility를 내리고

handleOpeningApps에서는 실행시킬 앱의 Visibility를 올리고, 실제로 보여줘야할 Window에 style, animationAttr이 설정되어 있는 경우 WindowStateAnimator를 실행시킵니다

// AppTransitionController::handleOpeningApps
            if (SHOW_LIGHT_TRANSACTIONS) Slog.i(TAG,
                    ">>> OPEN TRANSACTION handleAppTransitionReady()");
            mService.openSurfaceTransaction();
            try {
                app.showAllWindowsLocked();
            } finally {
                mService.closeSurfaceTransaction("handleAppTransitionReady");
                if (SHOW_LIGHT_TRANSACTIONS) Slog.i(TAG,
                        "<<< CLOSE TRANSACTION handleAppTransitionReady()");
            }

그 이후 appTransition.goodToGo를 실행시키고, 마무리로 displayContent에 pendingLayoutChanges를 업데이트 시킵니다

사실 봐야하는 내용이 Leash 말고도 InsetsController를 통해 (앱 마다 상,하단바 설정에 따라 보여주고 말고를 결정할 수 있어서) 그 부분의 animation도 봐야하는데 내용이 너무 길어져서 일단 여기서 한 번 자르도록 하겠습니다

감사합니다!

안드로이드 앱 프레임워크 학습(WindowManager) 3

냥냥냥냥냥냥 — Fri, 1 Mar 2024 01:25:43 +0900

안드로이드 앱 프레임워크 학습(WindowManager) 2 (tistory.com)

안드로이드 앱 프레임워크 학습(WindowManager) 2

안드로이드 앱 프레임워크 학습(WindowManager) 1 (tistory.com) 안드로이드 앱 프레임워크 학습(WindowManager) 1 안드로이드 그래픽스 프레임워크 학습 2 (tistory.com) 안드로이드 그래픽스 프레임워크 학습 2

nyaang.tistory.com

지난 번에 이어 이번엔 relayoutWindow 과정에 대해 알아보도록 하겠습니다

relayout

사실 WindowSurfacePlacer 이후 부분의 코드는 이미 한 번 봤던 코드라..

여기서 중점으로 봐야할 것은 아래 코드 부분입니다

SurfaceControl

// ViewRootImpl::relayoutWindow
int relayoutResult = mWindowSession.relayout(mWindow, params,
        (int) (mView.getMeasuredWidth() * appScale + 0.5f),
        (int) (mView.getMeasuredHeight() * appScale + 0.5f), viewVisibility,
        insetsPending ? WindowManagerGlobal.RELAYOUT_INSETS_PENDING : 0, frameNumber,
        mTmpFrames, mPendingMergedConfiguration, mSurfaceControl, mTempInsets, // mSurfaceControl
        mTempControls, mSurfaceSize);
        
        
...

        if (mSurfaceControl.isValid()) {
            if (!useBLAST()) {
                mSurface.copyFrom(mSurfaceControl);
            } else {
                final Surface blastSurface = getOrCreateBLASTSurface();
                // If blastSurface == null that means it hasn't changed since the last time we
                // called. In this situation, avoid calling transferFrom as we would then
                // inc the generation ID and cause EGL resources to be recreated.
                if (blastSurface != null) {
                    mSurface.transferFrom(blastSurface);
                }
            }
            if (mAttachInfo.mThreadedRenderer != null) {
                if (HardwareRenderer.isWebViewOverlaysEnabled()) {
                    addPrepareSurfaceControlForWebviewCallback();
                    addASurfaceTransactionCallback();
                }
                mAttachInfo.mThreadedRenderer.setSurfaceControl(mSurfaceControl);
            }

mSurfaceControl을 넘겨줘서 결국 WindowSurfaceController의 mSurfaceControl을 복사 받습니다

// WindowSurfaceController
void getSurfaceControl(SurfaceControl outSurfaceControl) {
    outSurfaceControl.copyFrom(mSurfaceControl, "WindowSurfaceController.getSurfaceControl");
}

그 이후 valid한지 체크 한 후 useBlast라면 (현재 true로 설정 아래 참고)

HardwareRenderer에 surfaceControl을 set 해줍니다

// ViewRootImpl
boolean useBLAST() {
    return mUseBLASTAdapter && !mForceDisableBLAST;
}

// ViewRootImpl::setView
    public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView,
            int userId) {
...
                if ((res & WindowManagerGlobal.ADD_FLAG_USE_BLAST) != 0) {
                    mUseBLASTAdapter = true;
                }



// WindowManagerService
        mUseBLAST = Settings.Global.getInt(resolver,
            Settings.Global.DEVELOPMENT_USE_BLAST_ADAPTER_VR, 1) == 1;

// WindowManagerService::addWindow
    public int addWindow(Session session, IWindow client, LayoutParams attrs, int viewVisibility,
            int displayId, int requestUserId, InsetsVisibilities requestedVisibilities,
            InputChannel outInputChannel, InsetsState outInsetsState,
            InsetsSourceControl[] outActiveControls) {
            
        ...
        
            if (mUseBLAST) {
                res |= WindowManagerGlobal.ADD_FLAG_USE_BLAST;
            }

WindowManagerService에서 addWindow 시점에 ADD_FLAG_USE_BLAST set 해주고,

ViewRootImpl 의 setView 시점에 해당 flag 있으면 true

정리하자면,

// WindowManager

1) WindowManager에 addView를 하면 WindowManagerGlobal에서 addView할 때 넘겨준 View와, 그 View의 ViewRootImpl을 생성해서 저장한다

2) relayout 시점에 ViewRootImpl이 가지고 있던 surfaceControl에 WindowSurfaceController가 가지고 있는 surfaceControl의 값을 복사해준다

3) 그 이후 LayoutPolicy 적용 (statusbar, navigationbar 등의 inset 처리 등등)

4) 적용한 사항을 WindowContainer의 getPendingTransaction을 통해서 merge 시킨후 apply(closeSurfaceTransaction)

----------------------------------- WindowManager <-> SurfaceFlinger 경계점

// SurfaceFlinger

5) 그러면 SurfaceComposerClient::Transaction::apply에서 surfaceFlinger로 setTransactionState

6) SurfaceFlinger의 queueTransaction 호출 후 mTransactionQueue에 저장

7) SurfaceFlinger의 flushTransactionQueues 호출 시점에 applyTransactionState

8) output present 호출 시점에 관련된 transaction 정보들 composer로 전달 하고 compose

사실 WindowManager는 window 관점 뿐만 아니라 activity의 state 변환에 따른 처리가 매우 많은데

이 다음부터는 ActivityManager 관련 된 부분을 정리를 진행해보려고 합니다

감사합니다!

안드로이드 앱 프레임워크 학습(WindowManager) 2

냥냥냥냥냥냥 — Thu, 29 Feb 2024 22:24:03 +0900

안드로이드 앱 프레임워크 학습(WindowManager) 1 (tistory.com)

안드로이드 앱 프레임워크 학습(WindowManager) 1

안드로이드 그래픽스 프레임워크 학습 2 (tistory.com) 안드로이드 그래픽스 프레임워크 학습 2 안드로이드 그래픽스 프레임워크 학습 1 (tistory.com) 안드로이드 그래픽스 프레임워크 학습 1 이번에

nyaang.tistory.com

지난 블로그에서는 CreateLayer를 어떻게 불러주는 지에 대해서 확인을 했었습니다

이번에는 WindowManager에 관해서 좀 제대로 알아보려고 합니다

WindowManagerService 생성

// SystemServer::startOtherServices
            wm = WindowManagerService.main(context, inputManager, !mFirstBoot, mOnlyCore,
                    new PhoneWindowManager(), mActivityManagerService.mActivityTaskManager);
            ServiceManager.addService(Context.WINDOW_SERVICE, wm, /* allowIsolated= */ false,
                    DUMP_FLAG_PRIORITY_CRITICAL | DUMP_FLAG_PROTO);
                    
// WindowManagerService::main
    public static WindowManagerService main(final Context context, final InputManagerService im,
            final boolean showBootMsgs, final boolean onlyCore, WindowManagerPolicy policy,
            ActivityTaskManagerService atm, DisplayWindowSettingsProvider
            displayWindowSettingsProvider, Supplier<SurfaceControl.Transaction> transactionFactory,
            Supplier<Surface> surfaceFactory,
            Function<SurfaceSession, SurfaceControl.Builder> surfaceControlFactory) {
        DisplayThread.getHandler().runWithScissors(() ->
                sInstance = new WindowManagerService(context, im, showBootMsgs, onlyCore, policy,
                        atm, displayWindowSettingsProvider, transactionFactory, surfaceFactory,
                        surfaceControlFactory), 0);
        return sInstance;
    }

먼저 WindowManager가 시작되는 위치는 SystemServer의 startOtherServies가 불릴 때 이며,

그 때 ServiceManager에도 등록이 되어 아래 처럼 받아 쓸 수 있습니다

context.getSystemService(Context.WINDOW_SERVICE) as WindowManager

단 WindowManager의 실제 구현은 WindowManagerImpl에 코드가 있으며, WindowManagerService를 wrapping 해놓은 식입니다

// WindowManager
@SystemService(Context.WINDOW_SERVICE)
public interface WindowManager extends ViewManager {
...

// WindowManagerImpl
public final class WindowManagerImpl implements WindowManager {
    @UnsupportedAppUsage
    private final WindowManagerGlobal mGlobal = WindowManagerGlobal.getInstance();
    
    
    ...
    
    @Override
    public void setShouldShowWithInsecureKeyguard(int displayId, boolean shouldShow) {
        try {
            WindowManagerGlobal.getWindowManagerService()   // windowManagerService
                    .setShouldShowWithInsecureKeyguard(displayId, shouldShow);
        } catch (RemoteException e) {
        }
    }    


// WindowManagerGlobal::getWindowManagerService
    @UnsupportedAppUsage
    public static IWindowManager getWindowManagerService() {
        synchronized (WindowManagerGlobal.class) {
            if (sWindowManagerService == null) {
                sWindowManagerService = IWindowManager.Stub.asInterface(
                        ServiceManager.getService("window"));
                try {
                    if (sWindowManagerService != null) {
                        ValueAnimator.setDurationScale(
                                sWindowManagerService.getCurrentAnimatorScale());
                        sUseBLASTAdapter = sWindowManagerService.useBLAST();
                    }
                } catch (RemoteException e) {
                    throw e.rethrowFromSystemServer();
                }
            }
            return sWindowManagerService;
        }
    }

Window 관련 ClassDiagram

classDiargram

실제로는 이것보다 훨씬 복잡하지만 일단 이렇게만 먼저 보겠습니다

지난 번 안드로이드 앱 프레임워크 학습(WindowManager) 1에서 WindowManager는 window 단위로 관리를 한다고 했지만 사실 엄밀히 말하면 WindowState단위로 관리가 됩니다

PhoneWindow의 경우 여러 경우가 있지만, 간단히 생각하면 Activity에서 getWindow 할 때 불리는 Window이며,

Activity에서 setContentView를 호출해줄 때 사용되는 View가 PhoneWindow입니다

이건 다음에 다시 한 번 정리를 하겠습니다

아무튼 Activity를 사용하지 않고, 화면에 띄우기 위해 WindowManager에 addView를 호출해주는 상황의 sequence을 보면

// WindowManagerGlobal::addView
root = new ViewRootImpl(view.getContext(), display);

// ViewRootImpl 생성자
    public ViewRootImpl(Context context, Display display) {
        this(context, display, WindowManagerGlobal.getWindowSession(),
                false /* useSfChoreographer */);
    }

WindowManagerGlobal에 받은 View를 저장하고, ViewRootImpl을 만들어 받은 View와 Session을 set해줍니다

// ViewRootImpl::setView
res = mWindowSession.addToDisplayAsUser(mWindow, mWindowAttributes,
        getHostVisibility(), mDisplay.getDisplayId(), userId,
        mInsetsController.getRequestedVisibilities(), inputChannel, mTempInsets,
        mTempControls);
        
// Session::addToDisplayAsUser
    @Override
    public int addToDisplayAsUser(IWindow window, WindowManager.LayoutParams attrs,
            int viewVisibility, int displayId, int userId, InsetsVisibilities requestedVisibilities,
            InputChannel outInputChannel, InsetsState outInsetsState,
            InsetsSourceControl[] outActiveControls) {
        return mService.addWindow(this, window, attrs, viewVisibility, displayId, userId,
                requestedVisibilities, outInputChannel, outInsetsState, outActiveControls);
    }

ViewRootImpl에서는 받은 session에 addToDisplayAsUser를 호출해주고,

결국 이것은 WindowManagerService의 addWindow를 호출을 해줍니다

// WindowManagerService::addWindow
            final DisplayContent displayContent = getDisplayContentOrCreate(displayId, attrs.token);
            
			...

            WindowToken token = displayContent.getWindowToken(
                    hasParent ? parentWindow.mAttrs.token : attrs.token);
                    
            // token이 없으면 만들어줍니다
            
            final WindowState win = new WindowState(this, session, client, token, parentWindow,
                    appOp[0], attrs, viewVisibility, session.mUid, userId,
                    session.mCanAddInternalSystemWindow);
                    
                    
  ...
  
            win.attach();
            mWindowMap.put(client.asBinder(), win);
            
            
          ...
          
            final WindowStateAnimator winAnimator = win.mWinAnimator;
            winAnimator.mEnterAnimationPending = true;
            winAnimator.mEnteringAnimation = true;

이것을 sequence diagram으로 표현한 것이 아래입니다

addView sequence

사실 위의 diagram에서 ViewRootImpl내의 requestLayout시점에 performTraversal을 통해

// ViewRootImpl::performTraversal
    private void performTraversals() {
    ...
    
                relayoutResult = relayoutWindow(params, viewVisibility, insetsPending);
                
    ...

relayoutWindow를 호출해주고 타고 타고 가면, windowManager의 relayoutWindow를 호출 해줍니다

// WindowMangerService::relayoutWindow
// Create surfaceControl before surface placement otherwise layout will be skipped
// (because WS.isGoneForLayout() is true when there is no surface.
if (shouldRelayout) {
    try {
        result = createSurfaceControl(outSurfaceControl, result, win, winAnimator);
    } catch (Exception e) {
        displayContent.getInputMonitor().updateInputWindowsLw(true /*force*/);

        ProtoLog.w(WM_ERROR,
                "Exception thrown when creating surface for client %s (%s). %s",
                client, win.mAttrs.getTitle(), e);
        Binder.restoreCallingIdentity(origId);
        return 0;
    }
}

// We may be deferring layout passes at the moment, but since the client is interested
// in the new out values right now we need to force a layout.
mWindowPlacerLocked.performSurfacePlacement(true /* force */);

사실 이 과정도 꽤 복잡하고, 이 과정들로 인해서 SurfaceFlinger에서 사용되는 layer를 SurfaceControl transaction을 통해 업데이트를 해주는 과정이 일어나게 되는데, 이건 relayout 과정으로 3편에서 따로 분리하여 좀 더 보도록 하겠습니다

감사합니다!

안드로이드 앱 프레임워크 학습(WindowManager) 1

냥냥냥냥냥냥 — Wed, 28 Feb 2024 21:00:29 +0900

안드로이드 그래픽스 프레임워크 학습 2 (tistory.com)

안드로이드 그래픽스 프레임워크 학습 2

안드로이드 그래픽스 프레임워크 학습 1 (tistory.com) 안드로이드 그래픽스 프레임워크 학습 1 이번에 이 글을 작성하게 되는 이유는 위의 Android 공식 홈페이지의 기술되어 있는 부분들에 대해 코

nyaang.tistory.com

위의 분석에서 SurfaceFlinger의 createLayer를 통해 SurfaceFlinger에 layer가 추가 되는 과정을 알아 봤었습니다

이번에는 그럼, createLayer를 해주는 부분이 어디인지를 한 번 알아보는 것이 핵심입니다

먼저, createLayer 시작점을 보기 전에 WindowManager라는 개념을 먼저 알아야 합니다

native 단의(여기서 native는 c, c++) SurfaceFlinger는 layer 단위로 관리를 하고 있고

java 단의 WindowManager는 window 단위로 관리를 합니다

둘 사이는 SurfaceControl.Transaction 이라는 것을 통해 통신을 하고, 그 Transaction을 가지고 있는 것은 DisplayContent입니다

안드로이드에서는 display별로 DisplayContent를 가지게 되고, 그 displayContent는 RootWindowContainer의 child들로 관리가 됩니다

// 1. WindowManagerService의 RootWindowContainer
    // The root of the device window hierarchy.
    RootWindowContainer mRoot;
    
 // 2. RootWindowContainer 상속 관계
 class RootWindowContainer extends WindowContainer<DisplayContent>
 
 // 3. RootWindowContainer::SetWindowManager
     void setWindowManager(WindowManagerService wm) {
        mWindowManager = wm;
        ...


        final Display[] displays = mDisplayManager.getDisplays();
        for (int displayNdx = 0; displayNdx < displays.length; ++displayNdx) {
            final Display display = displays[displayNdx];
            final DisplayContent displayContent = new DisplayContent(display, this);
            addChild(displayContent, POSITION_BOTTOM);  // addChild
            if (displayContent.mDisplayId == DEFAULT_DISPLAY) {
                mDefaultDisplay = displayContent;
            }
        }
        
 // 4. WindowContainer::addChild
     /** Adds the input window container has a child of this container at the input index. */
    @CallSuper
    void addChild(E child, int index) {
        if (!child.mReparenting && child.getParent() != null) {
            throw new IllegalArgumentException("addChild: container=" + child.getName()
                    + " is already a child of container=" + child.getParent().getName()
                    + " can't add to container=" + getName()
                    + "\n callers=" + Debug.getCallers(15, "\n"));
        }

        if ((index < 0 && index != POSITION_BOTTOM)
                || (index > mChildren.size() && index != POSITION_TOP)) {
            throw new IllegalArgumentException("addChild: invalid position=" + index
                    + ", children number=" + mChildren.size());
        }

        if (index == POSITION_TOP) {
            index = mChildren.size();
        } else if (index == POSITION_BOTTOM) {
            index = 0;
        }

        mChildren.add(index, child);

        // Set the parent after we've actually added a child in case a subclass depends on this.
        child.setParent(this);
    }

2번을 보시면 RootWindowContainer는 WindowContainer를 상속받는데 제네릭으로 DisplayContent 형식을 받는 것을 볼 수 있습니다

3번을 보시면 setWindowManager 호출 시에, addChild를 호출 해주는 것을 볼 수있고

4번을 보시면 addChild의 구현부분 입니다

처음 궁금했던, createLayer가 불리기까지의 sequence는 아래와 같습니다

createLayer 불리기 까지 과정

위에서, SurfaceFlinger <-> WindowManager 간의 통신은 Transaction을 통해서 이루어 진다고 얘기를 했는데, 그 부분에 대해서 좀 알아보려고 합니다

SetTransactionState까지의 sequence

// 1. RootWindowContainer::performSurfacePlacementNoTrace
    void performSurfacePlacementNoTrace() {
    ...
        mWmService.openSurfaceTransaction();
        try {
            applySurfaceChangesTransaction();
        } catch (RuntimeException e) {
            Slog.wtf(TAG, "Unhandled exception in Window Manager", e);
        } finally {
            mWmService.closeSurfaceTransaction("performLayoutAndPlaceSurfaces");
            ...
        }
        
// 2. WindowManagerService::opensurfaceTranaction, closeSurfaceTransaction
    void openSurfaceTransaction() {
        try {
            Trace.traceBegin(TRACE_TAG_WINDOW_MANAGER, "openSurfaceTransaction");
            SurfaceControl.openTransaction();
        } finally {
            Trace.traceEnd(TRACE_TAG_WINDOW_MANAGER);
        }
    }

    /**
     * Closes a surface transaction.
     * @param where debug string indicating where the transaction originated
     */
    void closeSurfaceTransaction(String where) {
        try {
            Trace.traceBegin(TRACE_TAG_WINDOW_MANAGER, "closeSurfaceTransaction");
            SurfaceControl.closeTransaction();
            mWindowTracing.logState(where);
        } finally {
            Trace.traceEnd(TRACE_TAG_WINDOW_MANAGER);
        }
    }


  // 3. SurfaceComposerClient::Transaction::merge
SurfaceComposerClient::Transaction& SurfaceComposerClient::Transaction::merge(Transaction&& other) {
    for (auto const& [handle, composerState] : other.mComposerStates) {
        if (mComposerStates.count(handle) == 0) {
            mComposerStates[handle] = composerState;
        } else {
            mComposerStates[handle].state.merge(composerState.state);
        }
    }

    for (auto const& state : other.mDisplayStates) {
        ssize_t index = mDisplayStates.indexOf(state);
        if (index < 0) {
            mDisplayStates.add(state);
        } else {
            mDisplayStates.editItemAt(static_cast<size_t>(index)).merge(state);
        }
    }  
  
  // 4. SurfaceComposerClient::Transaction::apply
  status_t SurfaceComposerClient::Transaction::apply(bool synchronous) {
  ...
  
    Vector<ComposerState> composerStates;
    Vector<DisplayState> displayStates;

   ...

    for (auto const& kv : mComposerStates){
        composerStates.add(kv.second);
    }
    
    ...
    
    sf->setTransactionState(mFrameTimelineInfo, composerStates, displayStates, flags, applyToken,
                            mInputWindowCommands, mDesiredPresentTime, mIsAutoTimestamp,
                            {} /*uncacheBuffer - only set in doUncacheBufferTransaction*/,
                            hasListenerCallbacks, listenerCallbacks, mId);

1번을 보시면 performSurfacePlacement 함수 내부의 performSurfacePlacementNoTrace 부분에 대한 설명입니다

performSurfacePlacement는 activity 전환 등 많은 경우에 불릴 수 있습니다

2번은 openSurfaceTransaction, closeSurfaceTransaction 부분의 코드 입니다

3번과 4번은 각각 openSurfaceTransaction, closeSurfaceTransaction시의 주요 사항 부분에 대한 코드 입니다

openSurfaceTransaction 일 때, SurfaceComposerClient::Transaction::merge가 불려서 mComposerStates와 mDisplayStates를 업데이트 시켜주고,

closeSurfaceTransaction이 불릴 때 SurfaceComposerClient::Transaction::apply가 불려서 SurfaceFlinger의 setTransactionState가 불리어 TransactionState를 넘겨줍니다

그 이후 SurfaceFlinger에서 queueTransaction를 통해 transaction을 저장했던 것을 flushTransactionQueues 시점에 업데이트 해줍니다 자세한 사항은 지난 번에 썼던 아래 부분과 연계가 되니 궁금하신 분은 확인 부탁드리겠습니다

안드로이드 그래픽스 프레임워크 학습 2 (tistory.com)

안드로이드 그래픽스 프레임워크 학습 2

nyaang.tistory.com

이렇게 해서 SurfaceFlinger <-> WindowManger간의 통신은 어떻게 이루어 지는지, SurfaceFlinger의 createLayer는 누가 해주는 지를 분석해보았습니다

다음 번엔 WindowManager에 대해서 좀 더 자세하게 분석 해보도록 하겠습니다

감사합니다