Shizuku 딥다이브
— 앱과 시스템 사이, 권한을 잇는 다리

1프로젝트 한줄 요약

Shizuku는 일반 앱과 Android 시스템 서비스 사이에 들어가는 권한 중계 계층입니다. 사용자가 ADB 또는 root로 shizuku_server를 시작하면, Shizuku를 지원하는 앱이 사용자 승인을 거쳐 이 프로세스에 요청을 보냅니다. 서버는 자신이 가진 권한 범위에서 시스템 API 호출을 중계합니다.

앱 자체의 UID를 root로 바꾸는 것이 아니라, 다른 권한으로 실행 중인 프로세스가 일을 대신하게 만드는 구조입니다.

1-1. 어디에 쓰는가

시스템 기능을 다루는 유틸리티가 매번 명령줄 프로그램의 출력 문자열을 해석하는 대신, Android의 시스템 서비스와 구조화된 통신을 하도록 돕습니다. README는 앱 구성요소를 켜고 끄는 pm enable/disable 같은 명령 기반 구현을 배경 사례로 듭니다. 실제 가능한 작업은 ADB와 root의 차이, OS 버전, 제조사 정책, 사용 앱의 구현에 따라 달라집니다.

Shizuku를 설치했다고 모든 앱이 자동으로 이 통로를 쓰지는 않습니다. 앱이 Shizuku API에 맞춰 연동해야 하며, 관리 화면은 연결된 앱의 허용 상태를 보여줍니다. 터미널 연동용 rish도 있지만, 그 역시 서버가 실행 중이어야 합니다.

1-2. 이 글을 읽고 설명할 수 있어야 할 세 가지

1. 일반 앱, Shizuku 서버, system_server의 역할과 권한이 어떻게 다른가.
2. 서버의 Binder를 전달받는 일과, 실제 사용 권한을 승인받는 일이 왜 다른가.
3. 서버가 살아 있는지, 연결이 되는지, 필요한 권한이 있는지를 왜 각각 확인해야 하는가.

2왜 주목받는가

2-1. 오래된 프로젝트가 계속 읽히는 이유

2026-10-23 GitHub Trending Kotlin Weekly #8에 오른 프로젝트이며, 생성일은 2017-05-24입니다. 같은 날짜 기준 스타는 32,008개, 포크는 3,410개입니다. 이 수치는 관심의 규모를 보여주지만, 특정 업데이트가 이번 순위를 만들었다는 인과관계까지 알려주지는 않습니다. 최근 push는 2025-06-18이므로, 순위만 보고 최근에 새 기능이 출시됐다고 읽으면 안 됩니다.

기술적으로 눈여겨볼 이유는 분명합니다. 루팅하지 않은 기기에도 ADB 기반 경로를 제공하고, 승인 화면과 앱 관리 기능을 공통으로 마련하며, 개발자가 시스템 API 호출을 재사용 가능한 연동으로 만들 수 있게 합니다. 이러한 장점은 코드 구조에 대한 평가이며, 트래픽이나 사용자 증가의 원인을 뜻하지는 않습니다.

2-2. 명령 문자열 대신 API 통신을 선택한다

README는 매번 su 셸에서 명령을 실행하는 방식에 프로세스 생성 비용, 출력 텍스트 해석의 불안정성, 명령이 노출한 기능에만 갇히는 한계가 있다고 설명합니다. 서버를 두고 Binder 요청을 중계하면 반복 업무에서 이 비용을 줄일 여지가 있습니다. 단, README는 구체적인 속도 배수나 성능 비교 결과를 제시하지 않습니다.

이 프로젝트가 바꾸는 것은 권한의 크기만이 아니라, 시스템 기능을 호출하는 인터페이스의 형태입니다.

이 표는 실행 방식의 비교입니다. libsu는 root 연동 라이브러리이고, Shizuku는 자체 관리 앱과 서버, 연동 API를 함께 둡니다. 실제로 manager/build.gradle에는 libsu가 들어 있으므로 둘을 항상 서로 배타적인 경쟁 제품으로 볼 수는 없습니다.

2-3. 무선 디버깅을 제품 흐름으로 연결한다

Android 11 이상의 무선 디버깅 경로에서는 PC 없이 시작할 수 있습니다. AdbMdns가 서비스를 찾고, AdbPairingClient가 페어링하고, AdbClient.shellCommand()가 시작 명령을 보내는 과정이 관리 앱에 들어 있습니다. 초기 연결의 복잡함을 Kotlin·네이티브 코드·사용자 안내로 나누어 처리한 사례입니다. 시작 조건은 공식 사용자 가이드에서도 확인할 수 있습니다.

3기술 스택 전체 지도

이 프로젝트의 “백엔드”는 인터넷 서버가 아니라 Android 기기 내부의 권한 프로세스입니다. 프론트엔드는 Kotlin·Java와 XML로 만든 네이티브 관리 화면입니다. 버전은 모두 커밋 b844bc4의 선언값이며, 현재 최신 라이브러리 버전을 뜻하지 않습니다.

Kotlin 저장소라는 분류만으로 읽으면, Java 서버와 C++ 실행기에 들어 있는 핵심을 놓치게 됩니다.

3-1. 백엔드: Binder 서버와 설정 저장

compileOnly libs.hidden.stub은 컴파일 시 타입 정보를 쓰겠다는 선언입니다. implementation libs.hidden.compat과 역할이 다릅니다. “컴파일이 된다”는 사실만으로 기기에서 해당 내부 API가 같은 모양으로 존재하거나 호출 권한이 보장되지는 않습니다.

3-2. 프론트엔드: 기존 View 체계와 상태 관찰

manager/build.gradle의 viewBinding true와 HomeActivityBinding.inflate(), manager/src/main/res/layout/home_activity.xml이 화면 구현의 단서입니다. 이 커밋의 관리 앱은 Compose 중심 구조가 아닙니다. HomeViewModel.reload()는 viewModelScope.launch(Dispatchers.IO)에서 상태를 읽어 LiveData에 보냅니다.

3-3. 인프라·빌드: Java, 네이티브, APK를 한 파이프라인으로

네이티브 빌드의 흥미로운 점은 add_executable(libshizuku.so ...)입니다. 이름은 공유 라이브러리처럼 보이지만 대상은 실행 파일입니다. 별도로 add_library(adb SHARED ...)도 있어, 시작 실행기와 JNI 라이브러리가 서로 다른 산출물임을 보여줍니다.

# .github/workflows/app.yml의 빌드 흐름을 요약
checkout@v4: submodules=recursive, fetch-depth=0
setup-java@v4: distribution=temurin, java-version=21
gradle/actions/setup-gradle@v4
./gradlew :manager:assemble
actions/upload-artifact@v4

CI는 ubuntu-latest에서 실행하며 APK 출력 폴더를 아티팩트로 보관합니다. 릴리스 설정에는 코드 축소와 리소스 축소가 켜져 있습니다. 이 워크플로에는 별도 테스트 명령이 없고, 본체 트리에도 test/·androidTest/ 경로가 없습니다. 이것만으로 외부 테스트나 수동 검증의 유무까지 단정할 수는 없습니다.

4아키텍처 심화 분석

4-1. 시스템 구조도: 프로세스 세 개를 구별하자

관리 앱도 일반 앱 프로세스입니다. 관리 화면이 떠 있는 상태와 권한 서버가 실행 중인 상태는 다릅니다. 마지막 요청 경로는 README가 설명하는 중계 구조와 ShizukuSystemApis의 래퍼 사용을 합친 개념도입니다. 중계의 공통 구현과 내부 검사 흐름은 API 서브모듈의 코드로 이어집니다.

4-2. 시작 경로: C++에서 Java의 main까지

manager/src/main/java/moe/shizuku/manager/starter/Starter.kt는 설치된 앱의 nativeLibraryDir에 있는 libshizuku.so 경로로 시작 명령을 만듭니다. StarterActivity.kt의 startRoot()는 libsu를, startAdb()는 AdbClient를 통해 같은 내부 시작 명령을 실행합니다.

// manager/src/main/jni/starter.cpp: 시작 자격 검사 발췌
uid_t uid = getuid();
if (uid != 0 && uid != 2000) {
    // 원본은 진단 문구를 출력한 뒤 종료한다
    exit(EXIT_FATAL_UID);
}

// run_server()의 실행 환경 설정
setenv("CLASSPATH", dex_path, true);
// 인자에는 app_process, APK 경로, 서버 클래스가 들어간다
// execvp()가 현재 프로세스를 새 실행 이미지로 바꾼다

start_server()는 fork()로 자식을 만들고, 자식에서 setsid()와 표준 입출력 재지정을 거쳐 run_server()를 부릅니다. run_server()는 execvp()로 /system/bin/app_process를 실행합니다. Java 진입점은 server/src/main/java/rikka/shizuku/server/ShizukuService.java의 main()입니다.

// ShizukuService.java: main()의 이벤트 루프
Looper.prepareMainLooper();
new ShizukuService();
Looper.loop();

서버 생성자는 package·activity·user·appops 서비스가 준비될 때까지 기다립니다. waitSystemService()는 아직 준비되지 않았으면 1초 뒤 다시 확인합니다. 시작 로그의 성공과 실제 Binder 수신은 별도 단계여서, 관리 화면도 서버 연결을 추가로 기다립니다.

4-3. 패턴 ① 권한 중계자와 프록시·어댑터

manager/src/main/java/moe/shizuku/manager/utils/ShizukuSystemApis.kt의 초기화 블록을 봅시다. 시스템 서비스 Binder를 얻는 지점에 래퍼를 끼워 넣습니다. 이후의 PackageManagerApis.getInstalledPackages() 같은 호출은 이 연결 계층을 이용합니다.

// ShizukuSystemApis.kt의 실제 초기화 코드
init {
    SystemServiceBinder.setOnGetBinderListener {
        return@setOnGetBinderListener ShizukuBinderWrapper(it)
    }
}

프록시는 원래 대상처럼 보이는 창구에서 호출을 받아 다른 경로로 전달하는 방식입니다. 여기서 배울 점은 호출부마다 ADB 명령을 흩뿌리지 않고 통로를 얻는 경계에 변환을 모았다는 것입니다. README는 서버의 transactRemote와 래퍼를 설명하지만, 해당 공통 중계 구현은 본체의 ShizukuService.java에 직접 정의되어 있지 않습니다.

권한 설계는 함수 이름보다, 그 함수를 어느 프로세스의 신원으로 호출하느냐에서 시작합니다.

4-4. 패턴 ② 템플릿 메서드와 생성 훅

ShizukuService는 공통 Service를 상속하고, onCreateUserServiceManager()·onCreateClientManager()·onCreateConfigManager()를 재정의합니다. 공통 흐름에 필요한 부품을 하위 구현이 공급하는 형태로 읽을 수 있습니다. 내부 호출 순서는 API 서브모듈에 있는 기반 클래스의 구현을 함께 읽어야 알 수 있습니다.

// ShizukuService.java: 구체적인 설정 관리자를 공급
@Override
public ShizukuConfigManager onCreateConfigManager() {
    return new ShizukuConfigManager();
}

ShizukuClientManager.java는 생성자에서 super(configManager)를 호출하는 작은 클래스입니다. 반대로 ShizukuUserServiceManager.getUserServiceStartCmd()는 실행할 app_process 경로를 고르고 ServiceStarter.commandForUserService()에 위임합니다. 파일 크기보다 재정의한 훅이 어떤 책임을 추가하는지 읽는 연습이 중요합니다.

4-5. 패턴 ③ 관찰자와 연결 수명 관리

server/src/main/java/rikka/shizuku/server/BinderSender.java의 register()는 프로세스 관찰자를 등록하고, Android 8.0(API 26) 이상에서는 UID 관찰자도 등록합니다. 앱이 활성화되는 등의 이벤트를 받으면 sendBinder()가 실행됩니다. PID·UID 목록으로 같은 실행 상태에 대한 중복 전달을 줄이고, 종료 이벤트에서는 목록의 항목을 제거합니다.

실제 전달은 ShizukuService.sendBinderToUserApp()이 담당합니다. packageName + ".shizuku"라는 ContentProvider를 얻어 BinderContainer를 넣은 Bundle로 sendBinder 호출을 보냅니다. Provider 사용 뒤에는 finally에서 외부 참조를 반환합니다. 상대 Provider가 죽어 있으면 앱을 종료하고 1초 뒤 한 번 더 시도하는 복구 분기도 있습니다.

starter/src/main/java/moe/shizuku/starter/ServiceStarter.java의 sendBinder()는 UserService를 연결한 뒤 서버 Binder에 linkToDeath()를 등록합니다. 서버가 사라지면 그 UserService 프로세스도 종료합니다. HomeActivity.onDestroy()에서는 화면이 등록했던 수신·종료 리스너를 해제합니다.

4-6. 호출자 확인: 전달받은 이름을 그대로 믿지 않는다

ShizukuService.attachApplication()은 요청 Bundle의 패키지 이름과 Binder가 알려준 호출자 UID를 대조합니다. 패키지 이름은 앱이 보낸 값이지만, 실제 UID는 Binder.getCallingUid()로 얻습니다. 그 UID에 속하는 패키지가 아니면 SecurityException을 던집니다.

// attachApplication()의 신원 대조 부분
int callingPid = Binder.getCallingPid();
int callingUid = Binder.getCallingUid();
List<String> packages =
        PackageManagerApis.getPackagesForUidNoThrow(callingUid);
if (!packages.contains(requestPackageName)) {
    // 원본은 로그를 남기고 SecurityException을 던진다
}

승인 결과를 받는 dispatchPermissionConfirmationResult()도 관리자 앱의 appId인지 먼저 검사합니다. 이후 같은 UID의 클라이언트 기록들에 allowed를 반영하고, 요청한 PID에는 결과 콜백을 보냅니다. onetime이 false인 결과만 설정에 저장합니다. 현재 승인 화면의 버튼은 지속 허용과 일회성 거절을 전달하므로, 프로토콜의 플래그만 보고 “일회성 허용 버튼도 있다”고 추정하면 안 됩니다.

v11 이상 서버에 대한 관리 앱의 AuthorizationManager.revoke()는 서버의 updateFlagsForUid()로 이어집니다. 이 경로는 허용 상태를 해제하고, 해당 UID의 연결된 클라이언트 기록마다 앱 강제 종료와 UserService 정리를 요청합니다. 권한 철회가 저장된 값 하나를 바꾸는 데서 끝나지 않는다는 점을 배울 수 있습니다.

4-7. 패턴 ④ 원자적 파일 저장과 쓰기 묶기

server/src/main/java/rikka/shizuku/server/ShizukuConfigManager.java는 설정을 /data/user_de/0/com.android.shell/shizuku.json에 저장합니다. AtomicFile.startWrite() 뒤에 성공하면 finishWrite(), 실패하면 failWrite()를 호출합니다. 파일을 쓰다 실패했을 때 이전 내용을 복구할 수 있는 저장 절차입니다.

// ShizukuConfigManager.java: 갱신할 비트만 교체
int newValue = (entry.flags & ~mask) | (mask & values);

// 저장은 즉시 하지 않고 10초 뒤로 예약
private static final long WRITE_DELAY = 10 * 1000;

scheduleWriteLocked()는 Android 10 이상에서 이미 예약된 쓰기가 있으면 더 예약하지 않습니다. 이전 버전에서는 기존 예약을 취소하고 다시 10초 뒤로 미룹니다. 두 분기의 차이는 각각 “첫 예약 이후 모아 쓰기”와 “마지막 갱신 뒤 기다리기”로 이해할 수 있습니다. 메모리의 허용 상태가 바뀐 시점과 디스크 저장 완료 시점 사이에는 간격이 있습니다.

생성자에서는 UID에 속한 패키지가 없거나, 기록된 패키지 중 현재 UID에 남아 있는 것이 하나도 없는 설정을 제거합니다. UID만 영구 식별자처럼 믿지 않고 패키지 목록을 함께 대조하는 이유입니다. ShizukuConfig.LATEST_VERSION은 2이며 설정 형식의 버전과 앱 릴리스 버전은 서로 다릅니다.

5디렉토리 구조 해부

api/는 단순한 빈 코드 폴더가 아닙니다. 본체 커밋은 Shizuku-API의 a27f6e4151ba7b39965ca47edb2bf0aeed7102e5를 가리킵니다. settings.gradle은 이 아래에서 aidl·rish·shared·api·provider·server-shared·hidden-api-stub을 연결합니다. 본체 트리만으로 공통 API 구현 전체를 읽을 수 없는 이유입니다.

5-1. 본체 코드 규모

집계 기준은 커밋 b844bc4 본체의 추적 파일 300개입니다. 확장자로 분류하고 빈 줄·주석을 포함한 물리 줄을 셌으며, 서브모듈 내용과 생성 산출물은 제외했습니다. 따라서 이 수치는 전체 Shizuku 생태계의 코드량이나 실행 가능한 문장 수가 아닙니다. XML에는 화면뿐 아니라 다국어 문자열과 리소스 정의도 포함됩니다.

Kotlin·Java·C++·헤더만 모듈별로 보면 manager 6,910줄, server 1,386줄, starter 196줄, shell 171줄, common 75줄입니다. 처음 읽을 때는 592줄인 ShizukuService.java 전체를 한 번에 이해하려 하기보다, 앞 장의 시작·전달·승인 흐름별로 나누어 읽는 편이 좋습니다.

6학습 포인트 (기술별)

6-1. Kotlin: 상태·수명·취소를 함께 보기

HomeViewModel.reload()는 IO 디스패처에서 조회하고 Resource.success/error를 LiveData로 전달합니다. HomeActivity는 상태를 관찰해 목록을 갱신합니다. UI가 통신 세부사항을 직접 처리하지 않게 만드는 책임 분리를 배울 수 있습니다.

한편 StarterActivity.kt의 시작 로직은 GlobalScope.launch(Dispatchers.IO)를 사용합니다. 화면 수명과 작업 수명을 어떻게 연결할지 검토할 학습 지점입니다. 시작 작업을 화면 밖에서도 유지해야 하는지부터 정한 뒤, 취소 가능한 범위와 정리 책임을 설계해 보세요. 현재 사용법을 모든 비동기 작업의 표준으로 일반화할 필요는 없습니다.

6-2. Binder와 Parcel: 쓴 순서대로 읽어야 한다

manager/src/main/java/moe/shizuku/manager/authorization/AuthorizationManager.kt의 getApplications()는 인터페이스 토큰, userId 순서로 Parcel에 기록합니다. 서버의 onTransact()는 토큰을 검사하고 정수를 읽은 뒤 목록을 반환합니다. 클라이언트가 reply.readException() 뒤에 목록을 읽는 순서까지 짝을 맞춰 보세요. finally의 recycle()도 통신 자원 관리의 일부입니다.

// 양쪽 소스의 기록·해석 순서를 학습용으로 요약
보내는 쪽: writeInterfaceToken → writeInt(userId) → transact
받는 쪽:   enforceInterface   → readInt          → 결과 기록
돌아온 쪽: readException      → 목록 역직렬화    → recycle

Android AIDL 공식 문서는 원격 호출이 Binder 스레드 풀에서 처리될 수 있으므로 동시성을 고려해야 한다고 설명합니다. IPC 메서드를 일반적인 UI 콜백과 같은 스레드에서 실행된다고 가정하지 않는 것이 출발점입니다. 인터페이스 토큰 검사는 통신 계약 확인이며, 그것만으로 모든 호출자 권한 검사가 끝나는 것도 아닙니다.

6-3. 바이너리 프로토콜: 길이·바이트 순서·검증

AdbMessage.kt의 HEADER_LENGTH는 24입니다. 명령·인자 둘·길이·체크섬·magic을 4바이트 정수 여섯 개로 기록하고, toByteArray()와 AdbClient.read()는 LITTLE_ENDIAN을 사용합니다. 반면 페어링 헤더는 AdbPairingClient.kt에서 6바이트, BIG_ENDIAN으로 다룹니다.

함수 이름도 검증 대상입니다. AdbMessage.crc32()는 이름과 달리 일반적인 CRC32 계산이 아니라 각 바이트를 0~255 값으로 보아 합산합니다. 페어링의 PairingPacketHeader.readFrom()는 버전·종류와 1~16,384바이트 길이 범위를 검사합니다. 반면 AdbClient.read()의 본문 버퍼 할당에는 같은 식의 명시적인 상한 검사가 보이지 않습니다. 두 구현을 비교하며 입력 검증 항목을 적는 연습을 할 수 있습니다.

주석과 함수 이름은 길잡이지만, 동작을 판정할 때는 실제 분기와 반환값까지 읽어야 합니다.

6-4. Java 동시성: 타임아웃은 예외인가, 반환값인가

RequestPermissionActivity.waitForBinder()는 CountDownLatch.await(5, TimeUnit.SECONDS) 뒤에 true를 반환하고, TimeoutException을 잡습니다. 하지만 이 await는 제한 시간이 지나면 false를 반환합니다. 그래서 타임아웃만으로는 코드의 해당 catch 분기에 들어가지 않고, 대기 결과를 성공으로 취급할 수 있습니다. 이는 Java API 계약과 대조해 확인할 수 있는 개선 지점입니다.

// 학습용 개선 예시. 원본 waitForBinder()의 전체 대체 코드는 아니다
val received = countDownLatch.await(5, TimeUnit.SECONDS)
if (!received) {
    return false
}
return true
// InterruptedException 처리와 리스너 해제도 별도로 설계해야 한다

6-5. C++·JNI: 한쪽의 생성은 다른 쪽의 정리와 짝이다

AdbPairingClient.kt의 PairingContext는 네이티브 포인터를 Long으로 보관하고 nativeEncrypt·nativeDecrypt·nativeDestroy를 호출합니다. manager/src/main/jni/adb_pairing.cpp는 SPAKE2, HKDF, AES-128-GCM 관련 BoringSSL 함수를 사용하고 JNI_OnLoad()에서 네이티브 메서드를 연결합니다. 생성 실패·중간 실패·정상 종료에서 누가 자원을 해제하는지 선으로 이어 보세요.

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

무선 디버깅은 Android 11부터 제공되는 플랫폼 기능입니다. 일반적인 ADB 구성과 PC 연결 조건은 Android의 ADB 공식 문서에서 확인할 수 있습니다. starter.cpp에는 arm·arm64·x86·x86_64 경로 분기가 있지만, 그것만으로 특정 릴리스 APK에 모든 ABI가 들어 있다고 확정할 수는 없습니다.

빌드에 필요한 Java 버전과 휴대전화가 지원해야 하는 Android 버전은 서로 다른 요구사항입니다.

7-1. 재부팅 이후: 앱의 일반 안내와 조건부 시작 코드

관리 앱의 manager/src/main/res/values/strings.xml은 PC를 통한 ADB 시작을 재부팅 때마다 반복하라고 안내합니다. 다만 커밋 b844bc4의 manager/src/main/java/moe/shizuku/manager/receiver/BootCompleteReceiver.kt에는 다음 조건부 분기가 있습니다. 일반적인 시작 안내와 조건부 자동 시작 경로를 함께 살펴보세요.

// BootCompleteReceiver.onReceive()의 조건을 학습용으로 요약
기본 사용자이고 서버가 아직 실행되지 않았는가?
  ├─ 마지막 시작 방식이 ROOT → rootStart()
  └─ Android 13 이상
       + WRITE_SECURE_SETTINGS 허용
       + 마지막 시작 방식이 ADB → adbStart()

ADB 자동 시작 경로는 무선 디버깅 설정을 쓰고, mDNS로 포트를 찾은 뒤, 127.0.0.1에 연결해 시작 명령을 보냅니다. 포트 탐색 대기는 3초입니다. 저장된 키·시스템 권한·부팅 브로드캐스트·제조사 정책까지 영향을 주므로, 코드가 있다는 사실을 자동 시작 보장으로 바꿔 읽으면 안 됩니다.

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

아래 다섯 과제는 소스 독해와 별도의 작은 연습 코드로 진행할 수 있습니다. 시스템 설정을 바꾸거나 실제 기기에서 높은 권한을 행사해야만 완성되는 과제가 아닙니다. 각 과제의 완료 기준을 만족했는지 스스로 설명해 보세요.

실습의 완료 기준은 코드를 읽었다는 느낌이 아니라, 정상 경로와 실패 경로를 함께 설명할 수 있다는 것입니다.

// 학습용 입력: 관계없는 비트 8은 유지되어야 한다
기존 flags = 8 | 2 = 10
mask = 2 | 4 = 6
values = 4
새 flags = (10 & ~6) | (6 & 4) = 12

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

하루에 모두 이해하려 하기보다 매주 하나의 경계를 다루는 편이 좋습니다. 아래 로드맵은 Kotlin 기초 문법을 아는 독자를 기준으로 한 6주 학습안입니다. Android 경험이 없다면 1~2주차를 늘리고, 시스템 프로그래밍 경험이 있다면 후반 과제에 시간을 더 쓰세요.

다음 단계로 넘어갈 기준은 파일을 다 읽었는지가 아니라, 그 경계에서 무엇이 실패할 수 있는지 설명할 수 있는지입니다.

9-1. 로드맵을 관통하는 확인 질문

• 신원: 패키지 이름·UID·PID 중 어느 값을 누가 제공하며, 어느 값을 신뢰할 수 있는가.
• 통신: Binder 전달은 언제 끝나고, 승인과 실제 API 호출은 언제 시작되는가.
• 수명: 화면, 서버, UserService가 각자 종료되면 어떤 참조와 리스너를 정리해야 하는가.
• 저장: 메모리 반영·쓰기 예약·파일 교체 완료 중 어느 시점을 사용자에게 설명하고 있는가.
• 호환: Android 버전, Shizuku API 버전, 설정 형식 버전, 앱 릴리스 버전을 혼동하고 있지 않은가.

10핵심 키워드 사전

11참고 링크

11-1. 공식 저장소·문서

• RikkaApps/Shizuku 공식 저장소 — 배경·개발 안내·릴리스 입구.
• 분석 기준 커밋 b844bc4의 전체 트리 — 본문의 경로·함수·설정값을 다시 확인할 기준.
• 해당 커밋의 README — 중계 구조와 사용 시 주의점. 일부 클래스 경로 표기는 현재 import와 차이가 있음.
• Shizuku 공식 사이트 · 사용자 가이드 — 다운로드와 기기별 시작·문제 해결 안내.
• 본체가 참조하는 Shizuku-API 커밋 — 별도 API·AIDL·공통 서버를 이어 읽는 대상.
• v13.6.0 릴리스 — 출시판 정보. 본문 분석 커밋은 이 릴리스 이후의 코드임.

11-2. 핵심 코드를 다시 찾는 링크

• ShizukuService.java — main, 연결 등록, 승인 결과, Binder 배포.
• BinderSender.java — 프로세스·UID 이벤트와 연결 전달.
• ShizukuConfigManager.java — 설정 정리, 비트 갱신, 지연·원자적 저장.
• starter.cpp — UID 검사와 fork·exec 기반 서버 시작.
• AdbClient.kt — ADB 연결·TLS 전환·셸 명령·메시지 해석.
• BootCompleteReceiver.kt — 조건부 부팅 시작 경로.

11-3. 관련 기술의 공식 학습 자료

• Android AIDL — 인터페이스 계약·스레딩·호환성.
• Android Debug Bridge — 개발 도구의 구성과 무선 디버깅.
• Binder API — 호출자 정보와 프로세스 간 통신.
• AtomicFile API — 저장 확정과 실패 복구 절차.
• Android JNI 안내 — 네이티브 경계를 다룰 때의 자원·성능 고려.
• Java CountDownLatch — await의 반환값과 예외 계약.
• libsu 공식 저장소 — root 셸 연동을 별도로 공부할 때의 출발점.

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