DroidDesk 딥다이브
— 손안의 리눅스 데스크톱을 연결하는 기술

1프로젝트 한줄 요약

DroidDesk는 Android의 Linux 커널을 이용해 데스크톱용 프로그램과 창 관리 환경을 실행하고, 그 화면과 입력을 휴대폰 앱에 연결하는 도구입니다. 기본 구성의 중심은 Termux 사용자 공간, XFCE 데스크톱, Termux:X11에서 가져온 화면·입력 구성요소입니다.

이 저장소에서 배울 핵심은 운영체제를 새로 만드는 법보다, 서로 다른 실행 환경의 경계를 연결하는 법입니다. 같은 설치 버튼에도 Dart와 Kotlin의 경계, 앱 권한의 경계, 프로세스의 경계, 파일 경로의 경계가 숨어 있습니다.

1-1. 먼저 두 제품 경로를 구별하자

이 글은 독립형 앱의 실행 흐름을 중심으로 살펴봅니다. 루트의 셸 스크립트는 비교 대상으로 읽습니다. 한쪽의 설치 방법이나 지원 목록을 다른 쪽의 보장으로 옮기지 않는 것이 첫 번째 소스 읽기 연습입니다.

2왜 주목받는가

2-1. 주머니 속 개발 환경이라는 명확한 사용 장면

2026-10-23 GitHub 기준 스타 4,383개, 포크 407개이며 GitHub Trending Kotlin Weekly #4로 선정됐습니다. 2026-04-20 생성 이후 약 6개월 만의 수치입니다. 다만 스타 수와 순위만으로 실제 사용자 수나 실행 안정성을 알 수는 없습니다.

README가 제시하는 장면은 이해하기 쉽습니다. 휴대폰에서 코드와 문서를 편집하고, 외부 화면에 연결해 데스크톱처럼 쓰다가 그대로 들고 나옵니다. 이 장면의 전달력, 여러 설치 단계를 묶는 자동화, 앱 안의 직접 X11 표시는 관심을 끌 만한 요소입니다. 이는 기능과 소스에서 읽어낸 해석이며, 트렌딩 유입 원인을 측정한 결과는 아닙니다.

2-2. 비슷한 도구와 비교하면 무엇이 보이나

비교 근거: Termux:X11 공식 저장소, UserLAnd 공식 소개, DroidDesk의 README.md와 LinuxRuntime.normalizedDesktop()입니다. 제품 간 속도 우열을 측정한 벤치마크는 이 비교에 포함되지 않습니다.

DroidDesk의 눈에 띄는 장점은 새로운 리눅스 기술보다, 설치부터 화면·입력·앱 실행까지 이어지는 통합 경험에 있습니다.

2-3. 홍보 문장과 구현을 나란히 읽는 습관

3기술 스택 전체 지도

전통적인 웹 서비스처럼 프론트엔드와 원격 백엔드가 있는 구조는 아닙니다. 여기서 백엔드에 해당하는 역할은 기기 안의 Kotlin 실행 계층이 담당합니다. 패키지와 rootfs를 받는 네트워크 통신은 있지만, 핵심 데스크톱 실행에 별도 애플리케이션 서버를 두지 않습니다.

3-1. 프론트엔드: Flutter와 Dart

3-2. 백엔드 역할: Kotlin·Java·C가 맡는 로컬 실행

XFCE·Mesa·일반 Linux 패키지는 설치 시 저장소에서 받습니다. 전체 버전을 고정하는 패키지 잠금 목록은 확인되지 않습니다. libXlorie.so 같은 동봉 바이너리도 정확한 상류 소스 리비전이 미기록이라고 COMPLIANCE.md에 적혀 있습니다.

3-3. 인프라·빌드·배포 설정

빌드 도구 버전, 의존성 해석 결과, 실행 중 내려받는 패키지 버전은 각각 다른 수준의 재현성을 제공합니다. Gradle에 남은 wlroots 관련 주석만으로 Wayland가 실제로 동작한다고 판단하지 마세요. 현재 app/android/app/src/main/cpp/CMakeLists.txt는 JNI 파일 하나와 Android·log 라이브러리만 연결합니다.

4아키텍처 심화 분석

4-1. ASCII 시스템 구조도

위 그림의 두 통로를 혼동하지 마세요. Linux 프로그램은 X11 소켓으로 서버에 접속하고, Android 화면 쪽은 Binder로 받은 파일 디스크립터를 통해 네이티브 연결을 붙입니다. MethodChannel로 화면 픽셀을 계속 보내는 구조가 아닙니다.

설치 명령의 전달, 데스크톱 프로세스의 실행, 화면의 표시는 서로 다른 경로이므로 각각의 성공 조건을 확인해야 합니다.

4-2. 설계 패턴 ① 어댑터: Dart와 Android의 계약 만들기

app/lib/services/platform_bridge.dart의 DroidDeskPlatform은 Flutter 화면이 Android 세부 API를 직접 알지 않도록 중간 창구를 제공합니다. app/android/app/src/main/kotlin/com/orailnoor/droiddesk/MainActivity.kt의 configureFlutterEngine()이 같은 채널 이름으로 요청을 받습니다.

// platform_bridge.dart: 설치 요청 부분 발췌
static const _channel = MethodChannel('com.droiddesk/core');

static Future<bool> installDesktopNative({String de = 'xfce4'}) async {
  final result = await _channel.invokeMethod('installDesktopNative', {
    'de': de,
  });
  return result as bool? ?? false;
}

Kotlin은 이 요청을 installThread("install-desktop-native")에서 처리하고, LinuxRuntime.installDesktopEnvironmentNative()를 호출합니다. 진행 상황은 onInstallProgress라는 반대 방향 호출로 Dart에 돌아옵니다. 최종 bool 응답과 여러 번 발생하는 진행 알림의 역할이 다릅니다.

app/lib/state/app_state.dart의 initialize()는 콜백을 등록하고 notifyListeners()로 화면을 갱신합니다. onInstallProgress 처리에서 음수는 실패, 0 이상 1 미만은 진행 중, 1 이상은 완료로 해석합니다. 문자열 기반 메서드명과 동적 Map이 계약이므로 이름·키·자료형이 어긋나면 런타임 오류가 날 수 있습니다.

4-3. 설계 패턴 ② 프로세스 격리: X11의 수명을 화면과 분리하기

app/android/app/src/main/AndroidManifest.xml은 X11ServerService에 android:process=":x11", android:exported="false"를 선언합니다. X11 서버가 UI와 별도의 프로세스·파일 디스크립터 테이블을 갖게 하려는 구조입니다. 이는 Linux 배포판 전체를 보안 컨테이너로 격리한다는 뜻은 아닙니다.

// app/android/app/src/main/aidl/com/orailnoor/droiddesk/x11/IX11Service.aidl
interface IX11Service {
    boolean startServer();
    int getServerPid();
    ParcelFileDescriptor getXConnection();
    ParcelFileDescriptor getLogcatOutput();
}

app/android/app/src/main/kotlin/com/orailnoor/droiddesk/x11/X11ServerService.kt의 ensureServerStarted()는 HandlerThread에서 초기화하고 CountDownLatch로 중복 시작 요청을 합칩니다. CmdEntryPoint.start(arrayOf(":0", "-nolock"))가 실제 서버 시작 지점입니다.

app/android/app/src/main/kotlin/com/orailnoor/droiddesk/x11/X11ServiceClient.kt는 Binder 호출을 단일 작업 스레드에서 수행합니다. app/android/app/src/main/kotlin/com/orailnoor/droiddesk/view/DesktopActivity.kt의 connectToX11Service()는 받은 연결을 LorieView.connect(connectionFd.detachFd())로 넘깁니다. 같은 서버 PID에 이미 연결돼 있으면 새 FD를 닫고 연결을 재사용합니다.

반대로 서버를 완전히 중지할 때는 X11ServerService.onDestroy()가 자기 프로세스를 종료합니다. Java 서비스 객체를 없애도 네이티브 스레드가 자동으로 모두 끝나는 것은 아니라는 설명이 소스에 있습니다. 객체 해제와 프로세스 종료는 서로 다른 생명주기라는 점을 배울 수 있습니다.

4-4. 설계 패턴 ③ 호환 계층: 다른 앱의 절대 경로를 옮기기

Termux 패키지가 원래 기대하는 접두 경로는 /data/data/com.termux/files/usr입니다. DroidDesk는 자신의 context.filesDir/usr에 패키지를 둡니다. app/android/app/src/main/kotlin/com/orailnoor/droiddesk/runtime/LinuxRuntime.kt는 이 주소 차이를 세 가지 수준에서 보정합니다.

patchElfFile()는 ELF64 프로그램 헤더의 PT_DYNAMIC에서 DT_STRTAB·DT_RPATH·DT_RUNPATH를 찾습니다. 주소를 파일 오프셋으로 바꾼 뒤 경로를 덮어쓰며, 공간이 좁으면 ${ORIGIN}이나 ${ORIGIN}/../lib를 사용합니다. 단순한 전체 문자열 치환과 다릅니다.

실행 환경의 핵심 값 — getTermuxEnv()와 socket_hook.c를 요약
PREFIX       = 앱 내부 files/usr
TMPDIR       = 앱 내부 files/tmp
DISPLAY      = :0
LD_PRELOAD   = PREFIX/lib/libsocket_hook.so (파일이 있을 때)

프로그램이 찾는 /tmp/.X11-unix/X0
    → connect() 후크
    → TMPDIR/.X11-unix/X0

원래의 libc 함수 주소
    → dlsym(RTLD_NEXT, "connect")
    → 보정한 주소로 실제 연결

app/assets/socket_hook.c를 빌드한 공유 라이브러리는 동적 링커의 LD_PRELOAD로 먼저 로드됩니다. 후크가 모든 시스템 호출을 완벽히 가로채는 것은 아닙니다. 이 코드는 정의된 libc 함수와 경로 규칙을 보정하는 계층이며, 임의의 Ubuntu 바이너리를 보편적으로 변환하는 도구는 아닙니다.

4-5. 설계 패턴 ④ 상태 기반 복구: 설치됨·실행 중·준비됨을 구별하기

LinuxRuntime.isBootstrapped()는 .bootstrap_extracted 마커와 bin/bash를 확인합니다. getInstalledDE()는 마지막 설치 단계에서 기록하는 .de_installed를 읽습니다. 패키지 파일 몇 개만 생긴 부분 설치를 완료로 오인하지 않으려는 장치입니다.

installPackageGroup()은 설치 명령 뒤에 shebang을 다시 보정하고 dpkg --configure -a로 미완료 설정을 복구합니다. 최초 설치가 실패했어도 복구가 성공하고 dpkg-query -W로 요청 패키지가 조회되면 성공으로 판단합니다. 데이터베이스 트랜잭션처럼 모든 변경을 원상복구하는 방식은 아닙니다.

MainActivity.runPackageOperation()의 AtomicBoolean.compareAndSet()은 앱 스토어 패키지 작업이 겹치지 않게 합니다. 로그는 appendTerminalOutput()에서 약 150ms 단위로 모아 보냅니다. 패키지 관리자의 일관성과 UI 갱신 비용을 함께 생각한 부분입니다.

루팅 경로에서도 파일을 푸는 것만으로는 끝나지 않습니다. ChrootRuntime.ensureMounts()가 /dev·/proc·/sys 등을 연결하고, bindX11Socket()이 앱의 X11 소켓 디렉토리를 chroot 안에 bind mount합니다. 그 뒤 su -c를 거쳐 chroot 안의 셸과 데스크톱 세션을 시작합니다. 비루팅 경로의 경로 후크와 루팅 경로의 마운트는 같은 연결 문제를 다른 권한 수준에서 푸는 방법입니다.

5디렉토리 구조 해부

Kotlin의 실행·X11·화면 코드는 각각 app/android/app/src/main/kotlin/com/orailnoor/droiddesk/runtime/·app/android/app/src/main/kotlin/com/orailnoor/droiddesk/x11/·app/android/app/src/main/kotlin/com/orailnoor/droiddesk/view/에 모여 있습니다. 파일이 많아 보이지만 먼저 app/lib/main.dart → AppState → DroidDeskPlatform → MainActivity 순서로 읽으면 사용자 행동이 어느 실행 함수로 이어지는지 찾을 수 있습니다.

5-1. 코드 규모: 주 언어와 제품 전체는 다르다

커밋 a410944의 Git 추적 파일 118개를 기준으로, 확장자별 텍스트의 실제 줄을 셌습니다. 마지막 개행이 없어도 한 줄로 세며 주석·빈 줄을 포함합니다. 압축 bootstrap 내부, 이미지, 글꼴, 동봉 .so, 라이선스·문서 등은 위 소스 합계에서 제외합니다. 위 표의 합계는 21,010줄이며 순수 실행문 수나 개발자가 직접 작성한 코드만의 분량은 아닙니다.

5-2. 파일 이름보다 실제 연결을 확인할 곳

app/android/app/src/main/cpp/compositor_jni.cpp에는 Wayland/wlroots 초기화·종료·입력 주입이 TODO로 남아 있습니다. JNI 함수 이름도 현재 Kotlin 패키지 경로와 다릅니다. 이 파일을 근거로 완성된 Wayland 렌더러가 있다고 설명하면 안 됩니다.

fetch_deps.sh는 wlroots 0.17.4-1, Wayland 1.22.0-1 등의 다운로드 목록과 작성자 컴퓨터의 절대 경로를 갖고 있습니다. 현재 앱의 실제 의존성 잠금 파일로 볼 수 없습니다. app/test_ffi.dart 역시 메모리 할당·해제 실험이며 자동화된 앱 테스트 모음이 아닙니다.

6학습 포인트 (기술별)

한 기능을 화면에서 시스템 호출까지 따라가 보면, 여러 언어를 배우는 일이 하나의 문제를 푸는 과정으로 연결됩니다. 처음부터 모든 파일을 이해하려 하기보다 설치 진행률이나 클립보드처럼 작은 기능 하나를 선택하세요.

6-1. Dart·Flutter: 상태를 화면과 분리하기

app/lib/main.dart는 ChangeNotifierProvider로 AppState를 공급하고, context.watch<AppState>()로 상태를 구독합니다. isSetupComplete에 따라 시작 화면도 달라집니다. 위젯이 설치 프로세스를 직접 다루지 않고 상태를 받아 그린다는 점에 집중하세요.

실습 아이디어: 다운로드·추출·설치의 진행 이벤트를 표로 만든 뒤, 각 이벤트가 _isDownloading·_isExtracting·_isInstallingDE 중 무엇을 바꾸는지 표시하세요. 화면을 다시 그리는 것과 실제 설치가 진행되는 것을 분리해서 설명하는 연습입니다.

6-2. Kotlin·Android: 무거운 작업과 UI 스레드

MainActivity는 설치를 작업 스레드에 보내고 결과·콜백을 runOnUiThread로 돌려보냅니다. 하지만 코드 전체가 코루틴 기반으로 통일돼 있지는 않습니다. thread, Executor, Handler, CountDownLatch를 구분해서 읽어야 합니다.

실습 아이디어: X11ServiceClient.onServiceConnected()에서 Binder 요청과 화면 콜백이 각각 어느 스레드에서 실행되는지 화살표 두 색으로 표시해 보세요. 기다리는 호출이 UI에 놓이면 어떤 현상이 생길지도 함께 적습니다.

6-3. Linux: 프로그램 하나에도 실행 환경이 필요하다

LinuxRuntime.getTermuxEnv()에서 PATH·HOME·SHELL· DISPLAY·LD_LIBRARY_PATH·APT_CONFIG를 찾아보세요. 같은 바이너리도 어떤 환경을 물려받느냐에 따라 인터프리터·라이브러리·화면 서버를 찾지 못할 수 있습니다.

실습 아이디어: 각 변수를 빼면 실패할 것 같은 기능과 예상 오류를 한 줄씩 적으세요. 예측이라는 점을 표시하고, 코드에서 해당 값을 읽는 소비자를 찾으며 근거를 보강합니다. Android Termux의 Bionic 환경과 Ubuntu의 glibc 환경을 구별하는 것도 다음 학습 주제입니다.

6-4. C·ELF: 주소를 바꾸는 두 가지 시점

patchElfFile()는 파일 안의 동적 라이브러리 검색 정보를 고칩니다. 반면 app/assets/socket_hook.c는 프로그램 실행 중 libc 함수를 감싸 호출 인자를 고칩니다. 설치된 파일을 바꾸는 작업과 실행 중 호출을 중개하는 작업의 차이를 배울 수 있습니다.

실습 아이디어: rewrite_path()를 순수 문자열 함수로 옮겨 모의 입력을 넣으세요. 정확한 접두 경로, 접두 경로와 비슷하지만 다른 이름, 빈 값, 상대 경로를 구별해야 합니다. 실제 후크를 주입하지 않아도 경계 조건과 버퍼 크기 문제를 공부할 수 있습니다.

6-5. 그래픽: 화면 서버와 GPU 드라이버를 구별하기

X11은 프로그램이 창·입력과 통신하는 체계이고, GPU 드라이버는 그래픽 연산을 처리하는 경로입니다. LinuxRuntime.getTermuxEnv()는 Adreno와 ICD 파일이 있을 때 zink를 선택하고, 그렇지 않으면 swrast·llvmpipe로 전환합니다.

Mesa의 Zink 문서는 OpenGL 작업을 Vulkan API로 보내는 역할을 설명합니다. LLVMpipe 문서는 CPU 기반 소프트웨어 래스터화 경로를 설명합니다. 실습 아이디어: 장치 노드 존재 여부와 ICD 파일 존재 여부의 네 조합을 표로 만들어 선택되는 환경 변수를 써 보세요.

6-6. 배포: 다운로드 성공과 신뢰할 수 있는 업데이트

app/lib/services/update_service.dart의 UpdateService.check()는 자동 확인에 6시간 간격 제한과 건너뛴 태그를 적용하며, 수동 확인은 이 둘을 무시합니다. 초안·사전 릴리스는 제외하고 첫 APK 자산을 선택합니다. app/android/app/src/main/kotlin/com/orailnoor/droiddesk/runtime/AppUpdater.kt의 download()는 예상 크기가 0보다 클 때 파일 크기를 검사하고, verify()는 패키지명과 설치된 앱·내려받은 APK의 서명 인증서 지문을 확인합니다.

실습 아이디어: 새 버전 없음, APK 없음, 크기 불일치, 패키지명 불일치, 서명 불일치를 서로 다른 실패 사례로 나누세요. 버전 비교는 업데이트 후보를 고르고, 서명 확인은 설치할 파일의 신뢰 조건을 검사합니다. isNewer()는 앞의 숫자 세 부분을 비교하므로 모든 사전 릴리스 규칙을 구현한 완전한 SemVer 파서는 아닙니다.

6-7. 작은 연동 기능: 앱 실행과 클립보드

app/android/app/src/main/kotlin/com/orailnoor/droiddesk/runtime/AndroidAppBridge.kt의 syncLaunchers()는 Android 앱 목록을 Linux의 .desktop 파일로 바꾸고 Python 런처를 만듭니다. 런처는 Unix 소켓으로 패키지명을 보내고, serve()와 launchPackage()가 Android의 정상 실행 Intent로 연결합니다. Android 앱이 Linux 프로그램으로 바뀌는 것은 아닙니다.

루팅 DesktopActivity.startDesktopSessionIfRequested()에는 AndroidAppSync.syncApps()와 FIFO 기반 android_intent_pipe 경로도 남아 있습니다. 유사한 기능의 구현이 둘이면 현재 호출 경로를 함께 확인해야 합니다. 클래스 이름 하나만 보고 연동이 모두 한 방식으로 통일됐다고 판단하지 마세요.

app/android/app/src/main/kotlin/com/orailnoor/droiddesk/runtime/ClipboardSync.kt는 800ms 간격으로 평문을 동기화하고 busy.compareAndSet()으로 작업 중복을 막습니다. 실습 아이디어: 양쪽 텍스트가 동시에 바뀌었을 때 Android 변경을 먼저 처리하는 분기를 찾고, 자신이 원하는 충돌 해결 규칙과 비교해 보세요. 이 기능의 시작·중지는 데스크톱 창의 포커스와도 연결됩니다.

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

7-1. 실행 대상은 ARM64 Android

ARM64와 최소 Android 버전을 만족하는 것만으로 GPU 가속, 외부 화면 출력, 모든 Ubuntu 앱의 호환성까지 보장되지는 않습니다. 낮게 설정된 targetSdk는 앱 내부 실행 파일의 호환성을 위한 선택이라고 Gradle 주석에 설명돼 있습니다. Android 정책 전체를 해제하거나 모든 제조사 제약을 없애는 설정으로 해석해서는 안 됩니다.

7-2. 메모리·저장 공간은 어느 정도인가

이 커밋에는 기기 RAM의 공식 최소·권장 사양표가 없습니다. app/android/app/src/main/kotlin/com/orailnoor/droiddesk/runtime/RootfsManager.kt 주석의 압축 300~500MB·해제 후 2~4GB도 일반적인 예상치이며, 고정된 Ubuntu Base 파일의 실측 크기나 XFCE까지 설치한 최종 사용량은 아닙니다.

실제 공간에는 다운로드 캐시, 압축 해제본, 패키지, 사용자 파일이 함께 들어갑니다. LinuxRuntime.getStorageInfo()와 cleanPackageCache()가 별도 기능인 이유입니다. CPU 렌더링은 앱 실행 가능 여부와 별개로 응답성·발열·전력 소비에 영향을 줍니다.

7-3. 모니터 연결과 세션 유지의 조건

USB-C 단자가 있다고 영상 출력이 되는 것은 아닙니다. README의 직접 HDMI 연결 경로는 휴대폰이 USB-C 영상 출력을 지원할 때의 안내입니다. Raspberry Pi 경로는 셸 설치판에서 VNC를 켜고, Pi가 USB 테더링 네트워크를 통해 화면을 받는 방식입니다.

pi-launch_phone.sh는 기본 경로의 게이트웨이를 휴대폰 IP로 간주해 vncviewer를 5901 포트로 연결합니다. USB 인터페이스 자체를 판별하지 않으므로 다른 기본 경로가 잡혀 있으면 잘못된 주소를 선택할 수 있습니다.

app/android/app/src/main/kotlin/com/orailnoor/droiddesk/service/DroidDeskService.kt는 포그라운드 알림과 PARTIAL_WAKE_LOCK을 사용합니다. 이는 CPU 수면과 세션 유지에 도움을 주는 수단이지 Android의 모든 백그라운드 종료를 막는 보장은 아닙니다. 실제 기기별 동작은 제조사 정책과 배터리 설정의 영향을 받습니다.

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

아래 소스 탐색 명령은 저장소 루트를 기준으로 적었습니다. 코드를 고치는 과제는 원본과 분리한 연습용 코드에서 진행하세요. 실습의 완료 기준을 실행 화면 하나로 끝내지 말고, 정상·실패·중복 요청을 설명할 수 있는 결과물로 정하세요.

# 읽기 전용 탐색: 의존성 선언과 잠금 결과
rg -n 'provider|shared_preferences|google_fonts|sdk:' app/pubspec.yaml
rg -n -A8 '^  provider:|^sdks:' app/pubspec.lock

# 읽기 전용 탐색: 요청과 콜백이 만나는 네 위치
rg -n 'installDesktopNative|onInstallProgress' \
  app/lib/services/platform_bridge.dart app/lib/state/app_state.dart \
  app/android/app/src/main/kotlin/com/orailnoor/droiddesk/MainActivity.kt
rg -n 'normalizedDesktop|installDesktopEnvironmentNative' \
  app/android/app/src/main/kotlin/com/orailnoor/droiddesk/runtime/LinuxRuntime.kt

연습용 의사 코드 — 실제 AppState 구현의 직접 인용은 아닙니다.
분류(progress):
    숫자가 유효하지 않으면 → 실패
    progress < 0 이면     → 실패
    progress < 1 이면     → 진행
    그 밖에는             → 성공

추가 상태: 작업 ID, 마지막 상태, 취소 여부
질문: 이전 작업의 완료 이벤트가 새 작업에 도착하면?

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

매주 소스에서 질문 하나를 고르고 설명 자료 하나를 남기는 방식입니다. 처음에는 프로그램을 실행하지 않고도 따라갈 수 있습니다. 학습 진도는 읽은 파일 수보다, 입력에서 결과까지의 흐름을 스스로 설명할 수 있는지로 확인하세요.

9-1. 관심사별로 갈라지는 다음 단계

• 모바일 앱 개발: 문자열 기반 채널 계약을 타입으로 표현하는 방법, 화면 생명주기와 작업 취소, 상태 복원으로 이어가세요.
• 시스템 프로그래밍: Bionic과 glibc, ELF 로딩, Unix 소켓, 파일 디스크립터 복제·이전, chroot와 namespace의 차이로 넓혀 보세요.
• 그래픽: X11 클라이언트·서버와 Surface를 먼저 구별하고, 그 다음 OpenGL·Vulkan·Mesa 드라이버 경로를 공부하세요.
• 배포 엔지니어링: APK 서명키 유지, 동봉 바이너리의 출처, 패키지 버전 고정, 의존성 고지 자동화로 확장하세요.

10핵심 키워드 사전

PRoot의 시스템 호출 추적과 실제 루트 권한의 차이는 PRoot-Distro 공식 문서에서도 설명합니다. 이 문서의 최신 명령 체계와 DroidDesk가 설치 시 받는 패키지 버전은 별개이므로 개념 설명과 버전 정보를 구별해 읽으세요.

11참고 링크

11-1. 공식 저장소와 주요 소스

• DroidDesk 공식 저장소 · v1.3.1 릴리스
• README · 두 실행 경로와 프로젝트의 사용 장면
• pubspec.yaml · pubspec.lock · 선언 범위와 잠금 버전
• Android 앱 빌드 설정 · SDK·ABI·서명·CMake 연결
• DroidDeskPlatform · AppState · UI의 요청과 상태
• MainActivity.kt · 플랫폼 채널 처리와 설치 작업 관리
• LinuxRuntime.kt · 비루팅 실행·패키지·경로 복구
• socket_hook.c · 경로와 X11 소켓 연결 후크
• ChrootRuntime.kt · 루팅 Ubuntu 실행·마운트
• X11ServerService.kt · X11ServiceClient.kt · 프로세스 사이 연결
• AppUpdater.kt · RELEASING.md · 업데이트와 서명 절차
• termux-linux-setup.sh · pi-launch_phone.sh · 셸 설치판과 Pi 연결

11-2. 관련 기술의 공식 문서

• Flutter 플랫폼 채널 · Dart와 Android 사이의 호출·자료형·스레드
• Termux 앱 · Termux 패키지 빌드 · Android용 사용자 공간의 배경
• Termux:X11 · 내장 화면·입력 코드의 상류 프로젝트
• PRoot-Distro · 루트 없는 배포판 환경과 제약
• TUR · Termux 사용자 저장소
• Mesa Zink · Mesa LLVMpipe · GPU와 CPU 렌더링 경로
• UserLAnd · Android 위 Linux 환경이라는 같은 문제의 다른 접근

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