DroidDeck 딥다이브
— Android와 PC 게임 사이에 다리를 놓는 법

1프로젝트 한줄 요약

DroidDeck은 지원되는 Android 기기 안에 Linux 사용자 공간을 준비하고, Steam 클라이언트와 게임 실행에 필요한 부품들을 연결하는 게임 런처입니다. README의 표현인 “SteamOS 경험을 Android로”는 제품 방향을 뜻합니다. 소스에서 확인되는 구현은 Android 앱이 Linux 세션과 화면·입력·오디오를 조율하여 PC 게임 실행 경로를 만드는 구조입니다.

대표 흐름은 APK 설치, Linux 런타임 준비, Play 선택, Steam 최초 다운로드와 로그인 순서입니다. Windows 게임의 운영체제 호출은 Wine 기반 Proton이 담당하고, x86 계열 명령어를 Arm64에서 실행하는 일에는 FEX가 관여합니다. Android 화면과 Linux 창 사이에는 별도의 Wayland 합성기가 있습니다. 게임마다 필요한 경로가 다르므로 모든 프로그램이 같은 변환 단계를 거치는 것은 아닙니다.

첫 번째 소스 읽기: 이름보다 등록 관계를 보자

app/src/main/AndroidManifest.xml의 .MainActivity는 실제 클래스가 아니라 activity-alias입니다. 연결 대상은 .FrontEndActivity이며, 실제 Kotlin 파일은 app/src/main/java/com/droiddeck/launcher/FrontEndActivity.kt입니다. 파일 이름만 추측해서 찾기보다 선언에서 진입점을 추적하는 습관을 배울 수 있습니다. 소스: 앱 진입점 등록.

// Manifest 등록 관계를 읽기 쉽게 줄인 도식
.MainActivity  →  .FrontEndActivity
                         │
                         ├─ Compose 화면과 설정
                         ├─ Linux 런타임 설치 상태 확인
                         └─ SessionService로 실행 요청

2왜 주목받는가

2-1. 순위가 말해 주는 것과 말해 주지 않는 것

선정 근거는 TrendShift Monthly #19입니다. 2026-10-23 GitHub 기준 저장소는 2026-09-24 생성, 분석일은 2026-10-23이며 스타는 12,910개입니다. 약 한 달 사이에 관심을 모은 신생 저장소라는 점은 확인됩니다. 이 순위와 스타 수만으로 일별 증가 추이나 게임 호환성을 판단할 수는 없습니다.

관심의 배경은 기능을 바탕으로 해석할 수 있습니다. Android 휴대용 기기에서 익숙한 Steam UI를 사용하고, 게임 라이브러리·컨트롤러·데스크톱 앱을 연결하려는 목표를 보여 줍니다. 주목할 학습 가치는 부품 하나를 새로 만드는 일보다 서로 다른 시스템의 경계를 맞추는 과정에 있습니다. 이것은 코드와 README에서 읽어 낸 해석이며, 이용자를 대상으로 검증한 인기 원인 분석은 아닙니다.

2-2. 비슷해 보이는 도구와 역할 비교

비교 근거는 Winlator 공식 저장소, Valve Remote Play 안내, Proton, FEX 공식 저장소입니다. 실행 방식의 비교이며 FPS·호환 게임 수·배터리 수명 순위를 측정한 표는 아닙니다.

2-3. 장점은 사용자 경험을 한곳에 모으는 데 있다

README는 Steam Big Picture, Desktop & apps, Flathub 기반 Store, GOG·Epic Games·Amazon Games 연동을 설명합니다. 소스에서도 app/src/main/java/com/droiddeck/launcher/frontend/Library.kt의 SteamGame에 source·storeId·protonPrefix가 함께 들어 있습니다. 게임을 단순한 실행 파일 경로가 아니라 출처·실행 환경·그림을 가진 항목으로 모델링한 것입니다.

2-4. 빠른 개발은 학습 기회이자 읽기 조건이다

2026-10-23 GitHub 기준 최신 릴리스는 0.6.0, 2026-10-22입니다. 2026-10-23 커밋에는 Wine의 ARM64 문맥 전환 최적화가 들어왔습니다. 따라서 “0.6.0에서 검증된 동작”과 “분석 커밋의 구현”을 같은 말로 쓰면 안 됩니다. 릴리스 기준점과 분석 커밋을 구분해서 보세요.

3기술 스택 전체 지도

웹 프로젝트의 프론트엔드·백엔드 구분을 그대로 대입하면 헷갈립니다. 이 저장소의 프론트엔드는 Android 화면이고, 백엔드에 해당하는 일은 서비스·네이티브 라이브러리·Linux 도구가 나눠 맡습니다. 이 앱의 내부 처리는 원격 API 서버 한 대가 아니라 기기 안의 여러 프로세스와 라이브러리로 구성됩니다. 외부 스토어 인증·게임 다운로드에는 네트워크가 필요합니다.

3-1. 프론트엔드: Kotlin과 Jetpack Compose

버전 출처는 루트 build.gradle과 app/build.gradle입니다. BOM 번호는 Material 3 자체의 버전 번호가 아닙니다. app/src/main/java/com/droiddeck/launcher/FrontEndActivity.kt의 mutableStateOf와 app/src/main/java/com/droiddeck/launcher/ui/FrontEndScreen.kt를 함께 읽으면 데이터가 바뀔 때 화면 구성이 바뀌는 선언형 UI를 배울 수 있습니다.

3-2. 내부 처리: Android 서비스·JNI·Rust

Rust 표의 숫자는 Cargo.lock에 기록된 고정 버전입니다. Cargo.toml의 reqwest = "0.12" 같은 선언은 허용 범위를 나타냅니다. 이 크레이트의 이름은 droiddeckstores, 버전은 0.1.0, 에디션은 2021, 결과물 형태는 cdylib입니다. 앱 버전 0.6.0과 별개입니다.

3-3. 그래픽·오디오·선택 기능

Gamescope는 tools/gamescope/release.env, PRoot는 tools/proot/source.env, 추적 라이브러리는 tools/packs/tracking/release.env에 고정되어 있습니다. Proton·FEX는 런타임과 구성요소 관리 경로가 있으므로 이 글에서는 모든 실행에 적용되는 단일 버전을 임의로 붙이지 않습니다.

3-4. 인프라·빌드: APK 바깥 부품까지 관리한다

.github/workflows/build.yml에는 ARM64 Xbox 백엔드 작업과 APK 컴파일·테스트 작업이 나뉘어 있습니다. Xbox 작업은 Rust 1.99.0을 지정하지만 Android 스토어 엔진의 Gradle 작업은 stable을 사용합니다. 하나의 Rust 버전으로 전체 빌드를 설명하면 틀립니다. 로컬 헬퍼는 설치된 NDK를 선택할 수 있어 기본 지정값과 실제 선택값도 구분해야 합니다.

4아키텍처 심화 분석

4-0. 전체 시스템 구조도

아래는 대표 경로를 단순화한 구조도입니다. 게임 종류와 선택한 Steam 클라이언트 아키텍처에 따라 세부 경로는 바뀝니다. 그림에서 “호스트”는 Android 쪽, “게스트”는 준비된 Linux 사용자 공간 쪽을 뜻합니다.

LinuxRuntime.SESSION_SCRIPT는 /usr/local/bin/droiddeck-session입니다. 소스 원본은 tools/linuxfs/overlay/usr/local/bin/droiddeck-session에 있고, run_gamescope()와 모드 분기에서 실제 프로세스 실행을 확인할 수 있습니다. Gamescope 인자에는 --backend wayland와 --expose-wayland가 들어갑니다. 소스: Linux 세션 진입 스크립트.

4-1. 설계 패턴 ① 수명주기 조율과 오래된 결과 무효화

app/src/main/java/com/droiddeck/launcher/session/SessionService.kt의 runSession(gen: Int)은 세션을 시작할 때 런타임 파일, 오디오, 컨트롤러, 환경변수, 바인딩을 준비하고 마지막에 프로세스를 띄웁니다. 함수 도중 여러 번 gen != sessionGen을 검사합니다. 사용자가 시작 직후 중지하거나 다시 시작하면, 먼저 시작한 작업의 결과가 현재 세션을 덮어쓰지 않도록 막는 장치입니다.

// SessionService.runSession()에서 발췌한 핵심 조건
if (gen != sessionGen || !SessionState.running) {
    if (gen == sessionGen) components.clear()
    return
}
components.forEach { it.start() }

// 시작 도중 중단된 뒤 정리하는 경로에서 사용
components.reversed().forEach { runCatching { it.stop() } }

app/src/main/java/com/droiddeck/launcher/core/SessionPart.java는 attach(), start(), stop(), suspendPid()라는 공통 계약을 제공합니다. 서비스는 구체적인 오디오·네트워크 구현을 전부 같은 방식으로 다룰 수 있습니다. 역순 정리는 나중에 준비한 자원부터 해제하는 방식이며, 부분 실패를 고려하는 수명주기 설계의 예입니다. 소스: 세션 실행과 정리.

여기에 상태를 이름으로 남기는 설계가 더해집니다. app/src/main/java/com/droiddeck/launcher/session/SessionState.kt에는 SessionPhase 열거형이 있고, app/src/main/java/com/droiddeck/launcher/session/SessionEvents.kt의 transition()은 상태 변경과 이벤트 기록을 묶습니다. 다만 전이표로 모든 잘못된 이동을 강제 차단하는 완전한 상태 기계라고 단정할 수는 없습니다.

// 대표 경로를 학습용으로 요약한 상태 흐름
IDLE → PREPARING → STARTING_COMPOSITOR → STARTING_GUEST
                                              │
                                              ▼
                                        STARTING_STEAM
                                              │
                                              ▼
                               READY ↔ SUSPENDED
                                  │
                                  ▼
                              STOPPING

// 실패 상태는 FAILED, 설치가 필요하면 INSTALLING_RUNTIME도 등장

특히 SessionEvents.markReadyIfPossible()는 실행 중인지, guestPid > 1인지, 첫 프레임을 보았는지, 일시 중지가 아닌지를 함께 확인합니다. 프로세스를 띄운 성공과 사용자가 화면을 볼 수 있는 성공을 분리한 점이 이 실행 구조의 핵심입니다. 사건은 events.jsonl에 시간·이벤트·세션 식별자와 함께 추가됩니다.

4-2. 설계 패턴 ② 언어·스토어 차이를 경계에서 흡수하는 어댑터

app/src/main/java/com/droiddeck/launcher/stores/StoresNative.kt의 ensureLoaded()는 공유 라이브러리의 로드 결과를 캐시하고, 실패 정보를 보관합니다. app/src/main/java/com/droiddeck/launcher/stores/epic/EpicNative.kt의 call()은 연산 이름과 JSON 문자열을 Rust로 넘깁니다. Rust의 app/src/main/rust/stores/src/epic/ffi.rs는 JNI 자료형을 Rust 문자열로 바꾸고 service::call()로 위임합니다.

guarded()는 catch_unwind로 Rust 패닉을 잡고 대체 결과를 반환합니다. 이것만으로 잘못된 포인터나 모든 네이티브 장애를 막는 것은 아닙니다. 학습할 지점은 오류 형태와 자료형 변환을 경계에서 명확히 처리하는 방식입니다. 소스: JNI 변환과 패닉 처리.

설치 요청은 조금 더 복잡합니다. Kotlin EpicNative.install()은 네이티브 핸들을 받고, CountDownLatch로 완료를 기다리며 250ms 간격으로 취소 여부를 확인하고, 취소 요청은 한 번 전달합니다. finally에서는 nativeRelease(handle)를 부릅니다. “실행 요청·진행 통지·취소·자원 해제”가 별개 계약이라는 점을 읽어야 합니다.

Rust 안에서도 app/src/main/rust/stores/src/fetch_core.rs의 FetchSink가 다운로드와 저장 방식을 분리합니다. 네트워크 엔진은 FetchItem을 가져오고, 스토어 쪽 구현은 받은 바이트를 처리합니다. 스트리밍을 지원하지 않는 기본 메서드는 SinkError::Fatal을 반환해 제약을 드러냅니다.

// fetch_core.rs의 공통 계약 일부
pub trait FetchSink: Send + Sync {
    fn process(
        &self,
        item: &FetchItem,
        body: Vec<u8>
    ) -> Result<u64, SinkError>;
}

4-3. 설계 패턴 ③ 임시 작업과 공개를 분리하는 파일 교체

app/src/main/java/com/droiddeck/launcher/runtime/LinuxRuntimeInstaller.java의 installOnce()는 다운로드 완료 후 SHA-256을 다시 계산하고, 새 런타임을 linuxfs.new에 풉니다. 기존 트리는 linuxfs.old로 옮기고, 사용자 홈을 옮긴 다음 새 트리를 정식 이름으로 바꿉니다. 실패하면 이전 트리를 되돌리는 분기도 있습니다.

// 함수의 작업 순서를 요약한 도식
아카이브 다운로드 → SHA-256 검사 → linuxfs.new에 압축 해제
                                      │
기존 linuxfs → linuxfs.old             │
             │                        │
             └─ 사용자 /root 홈 이관 ──┘
                                      ▼
                         linuxfs.new → linuxfs
                                      │
                                      ▼
                              이전 트리 정리

recoverInterruptedSwap()는 다음 시도에서 중단된 교체 흔적을 살펴봅니다. 중요한 것은 “임시 폴더를 쓴다”보다 각 단계 사이에서 앱이 종료되면 무엇이 남는가입니다. 여러 번의 이동과 삭제를 묶은 전체 작업이 데이터베이스 트랜잭션처럼 한 번에 원자적으로 완료되는 것은 아닙니다. 소스: 런타임 설치·복구.

더 작은 복구 사례는 app/src/main/java/com/droiddeck/launcher/session/ComponentsManager.kt에 있습니다. saveState()는 desired.tsv.tmp를 쓰고 동기화한 뒤, 새 상태와 임시 TSV의 해시를 state.pending.json에 기록합니다. desired.tsv 공개 후 state.json을 갱신하고 임시 기록을 지웁니다. recoverState()는 공개 파일의 해시로 상태 갱신을 마무리할지 판단합니다.

게임 파일에서도 같은 원칙을 볼 수 있습니다. Rust app/src/main/rust/stores/src/epic/install/writer.rs의 finish_file()은 sync_all(), 길이 검사, 기대값과 계산값이 모두 있을 때의 SHA-1 검사, 취소 확인, before_replace() 승인 단계를 거친 뒤 fs::rename()으로 해당 파일을 교체합니다. 이 보장은 파일별 교체에 관한 것이며 게임 설치 전체가 단일 원자적 작업이라는 뜻은 아닙니다.

4-4. 설계 패턴 ④ 조건을 좁힌 호환성 보정과 원래 경로로의 복귀

커밋 ffa40a1의 핵심 변경은 tools/linuxfs/preload/usr2.c입니다. ARM64 코드에서 raise(int sig)를 가로채되, 신호가 SIGUSR2인지, 호출자가 ntdll.so의 실행 영역 안에 있는지, GCS 하드웨어 기능 지원 비트가 없는지 등을 검사합니다. 신호 처리기 형식이나 차단 상태가 조건에 맞지 않아도 원래 raise()를 호출합니다.

// usr2.c의 첫 번째 우회 조건을 줄바꿈해 발췌
if (sig != SIGUSR2 ||
    (getauxval(AT_HWCAP) & BL_HWCAP_GCS) ||
    !usr2_from_ntdll(__builtin_return_address(0))) {
    return real(sig);
}

조건을 만족하면 bl_usr2_frame()이 레지스터와 부동소수점 상태를 담을 프레임을 만들고, bl_usr2_run()이 등록된 처리기를 직접 부릅니다. 이후 rt_sigreturn으로 문맥을 복원합니다. BL_FRAME_SIZE는 4688이며 _Static_assert로 구조체 크기와 오프셋을 검사합니다.

커밋 제목의 “커널 신호 없이”는 이 특정 경로에서 신호를 실제로 발생시키는 과정을 줄인다는 뜻입니다. 신호 설정 조회·마스크 처리와 rt_sigreturn 같은 시스템 호출까지 사라진 것은 아닙니다. README는 PRoot가 이 신호 때문에 스레드를 멈추는 비용을 줄이려는 의도라고 설명합니다. 이 구현만으로 속도 향상률을 알 수는 없습니다.

tools/tests/test_usr2_preload.py는 레지스터 보존, 변경된 문맥으로의 이동, 신호 마스크, 일반 신호 경로 등을 확인하는 회귀 검사 코드를 담고 있습니다. 초보 단계에서는 어셈블리를 모두 이해하기보다 최적화를 적용하는 조건과 적용하지 않는 조건을 먼저 적어 보세요. 구현과 검사 소스를 나란히 읽는 것이 좋습니다.

화면 경계에서 얻는 추가 관찰

app/src/main/java/com/droiddeck/launcher/wayland/CompositorHost.kt의 startOrAttach()는 처음에는 합성기를 시작하고, 이미 시작됐다면 Surface만 다시 연결합니다. JNI의 nativeStartWithSurface()는 Android Surface에서 ANativeWindow를 얻고 렌더러에 전달합니다. app/src/main/cpp/waylandcomp/src/compositor.c의 droiddeck_wayland_run()은 wayland-0 소켓을 등록합니다. 화면 객체의 수명과 게임 프로세스의 수명이 다르다는 점이 실제 함수 경계에도 드러납니다.

5디렉토리 구조 해부

다음 트리의 루트는 DroidDeck/ 저장소 루트입니다. 본문의 소스 경로도 저장소 루트를 기준으로 합니다. Java 소스 경로 아래에 Kotlin 파일도 놓이는 것은 Android 프로젝트에서 볼 수 있는 구성입니다.

겉보기에는 비슷하지만 역할이 다른 세 쌍

디렉터리를 이해했다는 기준은 파일 위치를 외우는 것이 아니라 수정한 원본이 어느 결과물에 들어가는지 설명하는 것입니다. 예를 들어 세션 스크립트는 오버레이에서 시작해 자산 준비를 거쳐 APK에 들어갑니다. JNI 함수는 Android용 공유 라이브러리로, Linux 보정 코드는 별도 교차 컴파일 경로로 갑니다.

6학습 포인트 (기술별)

6-1. Kotlin: 변경 가능한 상태와 최신 요청의 의미

app/src/main/java/com/droiddeck/launcher/FrontEndActivity.kt의 mutableStateOf는 화면에 반영할 상태를 보여 줍니다. 반면 app/src/main/java/com/droiddeck/launcher/session/SessionState.kt에는 @Volatile 필드와 Compose 상태가 섞여 있습니다. 둘은 같은 개념이 아닙니다. 스레드 사이에서 값이 보이도록 하는 문제와 화면 재구성을 일으키는 문제를 구별하세요.

더 작게 시작하려면 app/src/main/java/com/droiddeck/launcher/session/LatestRequestCoordinator.kt를 추천합니다. submit()은 최신 요청과 대기 요청을 저장하고, takeLatest()는 대기 요청을 꺼내며, isLatest()는 결과 적용 자격을 검사합니다. 비교 값이 같으면 세대 번호를 증가시키지 않는 점도 관찰할 만합니다.

// 실제 클래스 API를 사용한 학습용 순서 예시
val queue = LatestRequestCoordinator<String>()
queue.submit("A")
val a = queue.takeLatest()!!
queue.submit("B")
queue.submit("C")

queue.isLatest(a)          // false: A 결과는 적용하면 안 됨
queue.takeLatest()?.value  // "C": 대기 중인 B는 최신 값으로 합쳐짐

실습 아이디어: A·B·C 요청의 제출, 계산 완료, 화면 적용 시간을 종이에 표시하세요. 최신 결과 판정은 이전 작업을 실제로 취소하는 것과 다릅니다. 구현과 기존 검사를 비교하면 검색창·설정 미리보기에도 적용할 수 있는 원리입니다.

6-2. Android: Activity와 Service의 책임 분리

화면이 사라졌다고 게임 프로세스를 곧바로 끝내면 안 되고, 게임이 끝나지 않았다고 이전 Surface를 계속 붙잡아도 안 됩니다. app/src/main/java/com/droiddeck/launcher/SessionActivity.kt, app/src/main/java/com/droiddeck/launcher/session/SessionService.kt, app/src/main/java/com/droiddeck/launcher/wayland/CompositorHost.kt를 함께 읽으면 화면 연결과 실행 세션을 다른 수명으로 다루는 이유가 보입니다.

실습 아이디어: “화면 회전”, “다른 앱으로 이동”, “게임 종료”를 행으로 두고 Activity·Service·게스트 프로세스·Surface 중 무엇이 영향을 받는지 표로 정리하세요. 해당 소스에서 확인하지 못한 동작은 예상이라고 표시합니다.

6-3. Rust: 병렬성의 상한보다 자원 예산을 배우기

app/src/main/rust/stores/src/fetch_tuning.rs에는 초기 창 8, 호스트별 상한 6, 창 절대 상한 256, 청크 시도 상한 5가 있습니다. 동시에 작업 중인 바이트의 예산은 최소 24 MiB, 최대 96 MiB로 제한합니다. 상수의 256은 언제나 256개를 병렬 실행한다는 뜻이 아닙니다.

// inflight_budget_bytes()의 계산을 수식으로 정리
예산 = clamp(실효 상한 × 1 MiB × 3 / 2, 24 MiB, 96 MiB)

실효 상한 8   → 12 MiB 계산 → 하한 적용 → 24 MiB
실효 상한 32  → 48 MiB
실효 상한 256 → 384 MiB 계산 → 상한 적용 → 96 MiB

이 값은 다운로드 엔진의 작업 승인 예산이며 앱 전체 메모리 한도는 아닙니다. budget_admits()는 진행 중 작업이 0일 때 큰 작업 하나를 허용하므로 완벽한 바이트 벽으로 해석해서도 안 됩니다. 실습 아이디어: 느린 디스크와 빠른 네트워크를 가정해 대기 바이트가 쌓이는 과정을 그려 보세요. 소스: 예산·재시도·창 크기 상수.

6-4. C·C++와 운영체제: 주소·문맥·장치 경계를 읽기

tools/linuxfs/preload/usr2.c에서는 구조체 배치가 운영체제가 기대하는 형식과 맞아야 합니다. app/src/main/cpp/waylandcomp/src/waylandcomp_jni.c에서는 JVM 객체와 네이티브 윈도우를 연결합니다. 같은 “함수 호출”이라도 메모리 표현과 자원 소유권까지 맞춰야 한다는 공통점이 있습니다.

실습 아이디어: JNI가 문자열을 빌리고 복제하고 돌려주는 지점을 표시하거나, tools/linuxfs/preload/usr2.c에서 real(sig)로 돌아가는 조건을 모두 수집하세요. 어셈블리 명령 하나씩 해석하는 작업은 그다음 단계로 남겨도 됩니다.

6-5. 빌드·테스트: 파일이 존재하는 것과 올바른 파일인 것은 다르다

tools/release/runtime_inputs.py는 소스와 준비된 출력의 해시를 관리하고, 필요한 파일 목록을 확인합니다. app/build.gradle은 이를 패키징 작업에 연결합니다. 네이티브 소스를 바꾸고 예전 라이브러리를 그대로 담는 실수를 막기 위한 설계입니다.

실습 아이디어: CI의 tools/release/check_session_assets.py, tools/release/check_android_libraries.py, cargo test --locked, testReleaseUnitTest가 각각 어떤 종류의 오류를 찾는지 분류해 보세요. CI의 Rust 호스트 테스트 단계는 continue-on-error: true로 설정되어 있어 실패해도 전체 작업이 계속됩니다.

좋은 학습은 기술 이름을 많이 아는 데서 끝나지 않고, 그 기술이 막는 실패 상황을 설명할 수 있어야 합니다. 화면 상태는 재구성과, 오래된 결과 무효화는 세대 번호와, 파일 교체는 중단 복구와, 병렬 다운로드는 자원 예산과 연결해서 공부하세요.

7하드웨어 / 시스템 요구사항

7-1. Android에서 사용할 때

7-2. Android의 자식 프로세스 제한

README는 Android 14 이상에서 개발자 옵션의 자식 프로세스 제한 해제를 먼저 켜도록 안내합니다. Android 12·13에서 해당 옵션이 보이지 않으면 최초 실행의 Fix it for me가 설정을 돕는다고 설명합니다. 실제 코드는 app/src/main/java/com/droiddeck/launcher/core/PhantomProcessLimit.kt에 있습니다.

usesDeviceConfig()는 Android 12(API 31)를 별도 처리하고, blocksSteam()은 적용 대상이 아니거나 명시적으로 해제된 경우를 제외하면 실행을 막습니다. 운영체제 버전별 정책 차이를 한 개의 참·거짓 값보다 자세한 상태로 모델링한 사례입니다. 이 글의 읽기 실습에는 기기 설정 변경이 필요하지 않습니다.

7-3. 소스 읽기와 직접 빌드의 요구사항

8직접 해볼 수 있는 실습 과제

모든 과제는 원본을 읽고 별도 노트를 만드는 방식입니다. 아래 검색 명령은 저장소 루트에서 사용하는 읽기 명령입니다. 과제의 완료 기준은 프로그램을 띄웠다는 사실보다 정상·실패·중단 경로를 근거와 함께 설명하는 것입니다.

# 저장소 루트에서 코드 위치만 검색
rg -n 'activity-alias|targetActivity|SessionService' app/src/main/AndroidManifest.xml
rg -n 'runSession|HostProcess.start|SESSION_SCRIPT' app/src/main/java
rg -n 'run_gamescope|--backend wayland' tools/linuxfs/overlay/usr/local/bin/droiddeck-session

9관련 기술 심화 학습 로드맵

주차는 강의의 절대 분량이 아니라 읽는 순서입니다. Kotlin이 처음이라면 1·2주차를 늘리고, Rust나 C를 이미 쓴다면 4·6주차에서 경계 처리와 오류 흐름을 더 깊게 보세요. 배울 범위를 넓힐 때도 같은 실행 요청을 다시 따라가면 새 개념이 기존 구조에 연결됩니다.

공식 문서와 소스를 짝지어 읽는 방법

• Compose: 공식 상태 문서를 읽은 다음 mutableStateOf를 찾아 화면 상태와 단순 필드를 구분합니다.
• JNI: 문자열 변환과 참조 수명 문서를 읽고 app/src/main/rust/stores/src/epic/ffi.rs의 변환 함수와 네이티브 핸들 해제 경로를 표시합니다.
• Rust: 소유권과 trait를 익힌 뒤 Vec<u8>의 전달과 FetchSink: Send + Sync 계약을 읽습니다.
• Linux: 프로세스·신호·동적 로더 개념을 배운 뒤 tools/linuxfs/preload/usr2.c의 조건과 대체 경로를 설명합니다.
• 빌드: Gradle 작업 의존성을 배운 뒤 stageSessionScripts와 verifyRuntimeInputs가 어느 단계에 붙는지 찾습니다.

학습을 마쳤다고 판단하는 세 질문

1. 사용자의 실행 요청과 첫 프레임 표시 사이에서 어떤 실패가 생길 수 있는가?
2. JNI·파일·프로세스 경계를 넘을 때 자료형, 자원 수명, 오류를 누가 책임지는가?
3. 앱이 중단되거나 오래된 작업이 늦게 끝나도 현재 상태를 지키는 근거는 무엇인가?

이 세 질문에 파일과 함수로 답할 수 있다면, 다른 런처·다운로더·미디어 앱을 읽을 때도 같은 틀을 사용할 수 있습니다.

10핵심 키워드 사전

11참고 링크

공식 저장소·문서와 주요 구현

• DroidDeck 공식 저장소 · 분석 커밋의 README · 공식 릴리스 목록
• Android 빌드·의존성·자산 작업 · Rust 선언 · Rust 고정 버전
• 준비 상태·세션 이벤트 · PRoot 명령과 바인딩
• 구성요소 설정의 저장·복구 · 게임 파일 조립·검증·교체
• 화면 연결 수명 관리 · Wayland 서버 구현
• APK CI · 빌드 입력 검증 · 로컬 빌드 준비 도구
• Gamescope 고정값 · PRoot 소스 고정값 · OpenCV·MediaPipe 고정값
• 스마트 안경 지원 표 · TrendShift

관련 기술을 이어서 공부할 공식 자료

• Compose의 상태 관리 · Android의 JNI 사용 지침 · Android NDK
• Rust 공식 입문서 · Cargo 매니페스트 문서 · Tokio API 문서
• Proton 공식 소스 · FEX 공식 소스 · PRoot 공식 소스
• Wayland 문서 · Gamescope 공식 소스 · Mesa의 Freedreno·Turnip 문서
• DXVK 공식 소스 · Winlator 공식 소스 · Steam Remote Play 안내

현재 상태 (2026-10-23 확인)

언어별 코드 규모와 집계 기준

집계 대상은 Git 추적 파일 중 일반 파일이며, 개행 수에 마지막 줄의 개행이 없으면 한 줄을 더한 값입니다. C·C++·헤더에는 app/src/main/cpp/thirdparty/, app/src/main/cpp/adrenotools/, Wayland 생성 코드 등이 포함됩니다. 확장자 없는 스크립트·XML·Gradle 파일은 위 합계에서 제외했습니다. 예를 들어 확장자 없는 tools/linuxfs/overlay/usr/local/bin/droiddeck-session은 별도로 1,267줄입니다. 이 수치를 프로젝트가 새로 작성한 코드량이나 품질 점수로 해석하면 안 됩니다.

# 저장소 루트에서 Kotlin 집계만 재현하는 읽기 예시
python3 - <<'PY'
from pathlib import Path
import subprocess
names = subprocess.check_output(["git", "ls-files", "-z"]).decode().split("\0")
files = [Path(n) for n in names if n.endswith(".kt") and Path(n).is_file()]
lines = 0
for path in files:
    data = path.read_bytes()
    lines += data.count(b"\n") + int(bool(data) and not data.endswith(b"\n"))
print(len(files), lines)
PY
# 커밋 ffa40a1 기준: 794 128215