이 페이지는 Cloud Translation API를 통해 번역되었습니다.

SDK 런타임 개요

Android 플랫폼은 앱 샌드박스 개념을 사용하여 프로세스 경계와 함께 앱 코드의 강력한 실행 및 보안 경계를 유지합니다. 일반적으로 앱은 서드 파티 코드를 포함하는데 광고 SDK나 애널리틱스 SDK와 같은 SDK 형태가 많습니다. 이러한 재사용을 통해 앱 개발자는 앱의 차별화에 집중하는 동시에 주제 전문가의 작업을 활용하여 자체적으로 쉽게 할 수 있는 것 이상으로 실행을 확장할 수 있습니다.

대부분의 운영체제와 마찬가지로 Android SDK는 호스트 앱의 샌드박스 내에서 실행되며 호스트 앱의 메모리와 저장소에 대한 액세스 권한뿐만 아니라 호스트 앱의 동일한 권한을 상속받습니다. 이 아키텍처를 사용하면 SDK와 앱을 유연하게 통합할 수 있지만 사용자 데이터가 비공개로 수집 및 공유될 가능성도 생기게 됩니다. 또한 앱 개발자가 서드 파티 SDK의 기능과 액세스하는 데이터의 범위를 전부 알기가 어려워 앱의 데이터 수집과 공유 관행을 설명하기가 쉽지 않을 수 있습니다.

Android 14에는 서드 파티 SDK를 SDK 런타임이라는 전용 런타임 환경에서 실행할 수 있는 새로운 플랫폼 기능이 추가되었습니다. SDK 런타임은 사용자 데이터 수집 및 공유에 관해 다음과 같은 더 강력한 보호 장치 및 보증을 제공합니다.

수정된 실행 환경
SDK에 관한 잘 정의된 권한과 데이터 액세스 권한

Google은 이 설계에 관해 모바일 앱 광고 커뮤니티의 의견을 기다리고 있습니다. 또한 추가 사용 사례 지원을 포함하여 향후 SDK 런타임 버전을 잘 만들 수 있도록 광범위한 개발자 커뮤니티의 의견도 환영합니다.

목표

이 제안서를 통해 다음 목표를 달성하려고 합니다.

프로세스 격리와 잘 정의된 API 및 데이터 액세스 제어를 통해 사용자 앱 데이터에 대한 서드 파티 SDK의 비공개 액세스 및 공유를 줄입니다. 이 문서의 별도 섹션에서 프로세스 격리에 관해 자세히 알아보세요.
SDK에서 고유한 영구 식별자에 액세스하지 못하도록 제한하여 서드 파티 SDK의 사용자 앱 사용에 관한 비공개 추적을 줄입니다.
앱 개발자와 최종 사용자의 부담을 줄여 앱의 SDK 업데이트 배포를 안전하게 가속화합니다. 이 문서의 다른 섹션에서 제안된 신뢰할 수 있는 SDK 배포 모델에 관해 자세히 알아보세요.
앱 개발자가 앱의 데이터 액세스 및 공유 관행을 더 잘 설명하도록 돕습니다.
SDK 개발자가 JNI 코드와 같은 안전하지 않은 특정 언어 구성을 제한하여 다른 SDK의 조작을 방지할 수 있도록 지원합니다.
광고 SDK가 미디어를 표시하는 원격 뷰를 완전히 제어하여 무효 트래픽과 광고 사기를 감지하고 방지할 수 있도록 돕습니다.
앱 및 SDK 개발자에게 미치는 과도한 영향을 가능한 한 최소화합니다.

격리된 프로세스에서 실행되는 SDK

제안된 SDK 런타임을 사용하면 이 문서의 나머지 부분에서 런타임 지원(RE) SDK라고 하는 호환되는 SDK가 별도의 앱 프로세스에서 작동할 수 있습니다. 플랫폼은 앱의 프로세스와 SDK 런타임 간의 양방향 커뮤니케이션을 용이하게 합니다. 자세한 내용은 이 문서의 커뮤니케이션 섹션을 참고하세요. 비 RE SDK는 현재처럼 앱 프로세스에 유지됩니다. 다음 다이어그램은 이러한 변경사항을 보여줍니다.

앱 프로세스를 실행하는 모든 항목을 보여주는 이전 다이어그램 — SDK 런타임에 추가되기 전에는 SDK 호출 코드와 이 코드에서 호출을 수신하는 SDK가 모두 앱의 프로세스에 있습니다.

앱 프로세스와 SDK 런타임 프로세스 간에 분할된 프로세스를 보여주는 변경 후 다이어그램 — SDK 런타임에 추가된 후에는 앱의 포그라운드 프로세스에서 SDK 호출 코드가 SDK 인터페이스와 통신합니다. 그러면 이러한 인터페이스는 프로세스 경계를 지나 SDK 런타임 프로세스로 이동하여 SDK 자체를 호출합니다.

신뢰할 수 있는 새 SDK 배포 모델

앱과 SDK 분리 제안은 SDK와 앱 배포를 위한 또 하나의 분리 개념으로 작용합니다. 올바른 SDK가 앱의 SDK 런타임에 설치되도록 하려면 제안서에는 신뢰할 수 있는 배포 및 설치 메커니즘이 필요합니다. 이렇게 하면 사용자와 앱 개발자가 잘못된 SDK를 로드하는 것을 방지하면서 앱 스토어를 통해 앱 개발자의 SDK 배포 부담을 크게 줄일 수 있습니다.

SDK는 배포를 위해 앱 스토어에 업로드되기 전에 더 이상 앱과 정적으로 연결되고 패키징될 필요가 없습니다. 대신 다음 프로세스가 발생합니다.

SDK 개발자는 버전이 지정된 SDK를 앱 자체와는 별개로 앱 스토어에 업로드할 수 있습니다.
앱 개발자는 버전에 따라 SDK 종속 항목을 지정하고 실제 SDK 종속 항목이 포함되지 않은 앱 출시를 빌드하고 업로드할 수 있습니다.
사용자가 이 앱을 다운로드하면 설치 프로세스는 앱의 지정된 SDK 종속 항목을 사용하여 앱 스토어에서 다운로드할 수 있습니다.

이 새로운 배포 메커니즘을 통해 SDK 개발자는 SDK를 브레이킹 체인지 없이 변경(즉, API나 그 시맨틱스를 변경하지 않음)하고 앱 개발자의 개입 없이 기기에 배포할 수 있습니다. 브레이킹 체인지 없이 변경된 이러한 SDK는 앱 개발자가 새로운 SDK로 앱을 다시 빌드하거나 최종 사용자가 앱을 업데이트할 때까지 기다릴 필요 없이 배포되거나 롤백될 수 있습니다. 브레이킹 체인지는 여전히 앱 개발자가 업데이트해야 하지만, SDK 개발자는 브레이킹 체인지가 아닌 변경사항과 수정사항을 더 많은 사람들이 더 빠르고 균일하게 사용할 수 있도록 배포하여 버전 지원을 최소화할 수 있습니다.

다음 다이어그램은 제안된 SDK 배포 변경사항을 보여줍니다.

변경 전 다이어그램 — SDK 런타임이 도입되기 전에는 개발자가 SDK를 앱에 직접 전송했습니다.

변경 후 다이어그램 — SDK 런타임이 도입된 후 SDK 개발자는 SDK 업로드 UI를 사용하여 앱 스토어에 SDK를 게시했습니다. 그러면 앱 스토어에서는 SDK 종속 항목과 함께 최종 사용자 기기에 배포되는 앱을 처리합니다.

SDK 및 앱 빌드, 실행, 배포 방법 변경사항

유연한 SDK 런타임 및 배포 기술을 위한 초기 제안서입니다. 다음 섹션에서는 다음과 같은 광범위한 카테고리에 관한 일련의 변경사항을 제안합니다.

액세스: 권한, 메모리, 저장소
실행: 언어, 런타임 변경사항, 수명 주기, 미디어 렌더링
커뮤니케이션: 앱과 SDK 간 및 SDK 간
개발: 이 모델에서 빌드, 디버그, 테스트하는 방법
배포: Android, 앱, SDK의 여러 버전에서 배포, 업데이트, 롤백하는 방법

이 문서에는 일반적인 질문을 해결하는 데 도움이 되는 FAQ도 포함되어 있습니다.

이는 초기 설계 제안서이고 Google 생태계의 일부 구성원에게는 의미 있는 변화일 수 있다는 점을 잘 알고 있습니다. 따라서 Google에서는 여러분의 의견을 기다리고 있습니다. 이 Issue Tracker를 통해 의견을 보내주시기 바랍니다.

액세스

시스템의 개인 정보 보호 관리는 다양한 당사자가 여러 리소스에 액세스할 수 있는 방법을 관리한다는 것을 의미합니다. Google의 개인 정보 보호 가치 제안을 충족하기 위해 Google에서는 잠재적으로 민감한 정보에 대한 비공개 액세스를 방지하도록 앱, SDK, 사용자 데이터에 액세스하는 모델을 최소 권한의 원칙을 따르도록 업데이트할 것을 제안합니다.

SDK 권한

별도의 프로세스로서 SDK 런타임은 사용자가 앱에 부여한 권한을 상속받기보다는 잘 정의된 자체 권한 집합을 보유합니다. 광고 관련 SDK에서 사용하는 권한에 관한 예비 연구에 따라 기본적으로 SDK 런타임의 SDK에서 다음 권한에 액세스할 수 있다고 제안합니다.

INTERNET: 웹 서비스와 통신할 수 있도록 인터넷에 액세스합니다.
ACCESS_NETWORK_STATE: 네트워크 정보에 액세스합니다.
READ_BASIC_PHONE_STATE: 휴대전화 상태에 관한 정보(예: 모바일 네트워크 유형)에 액세스합니다.
앱 간 식별자에 액세스하지 않고도 핵심 광고 기능을 제공하는 개인 정보 보호 API에 액세스하는 권한입니다.
AD_ID: 광고 ID를 요청할 수 있습니다. 이 또한 이 권한에 대한 앱의 액세스로 관리됩니다.

Google에서는 현재 개인 정보 보호와 사용성 측면에서 모두 최종 사용자에게 미치는 영향을 제한하면서 추가 권한을 승인할지 여부와 승인 방법을 조사하고 있습니다. 이 권한 집합으로 충족할 수 없는 사용 사례에 관한 의견을 작성해 주시기 바랍니다.

메모리

SDK 런타임은 자체 프로세스를 보유하고 있어 격리된 자체 메모리 공간이 있습니다. 이 구조는 기본적으로 앱의 메모리 공간에 대한 SDK 액세스를 거부하며 마찬가지로 애플리케이션은 SDK의 메모리 공간에 액세스할 수 없습니다. 최소 권한의 원칙에 계속 일치하도록 이 기본 동작을 유지하는 것이 좋습니다.

저장소

이 제안서에 따라 SDK는 일반 작업을 위한 저장소에 액세스해야 하고 영구 저장소를 사용하여 앱 간 및 프로세스 간 추적을 최소화해야 합니다. 이제 저장소 액세스 방식에 관한 다음 업데이트를 제안합니다.

앱은 SDK 저장소에 직접 액세스할 수 없으며 그 반대의 경우도 마찬가지입니다.
기기의 외부 저장소에는 SDK에서 액세스할 수 없습니다.
각 SDK 런타임 내에는 모든 SDK에서 액세스할 수 있는 저장소와 특정 SDK에 비공개인 저장소가 모두 있습니다.

현재 저장소 모델과 마찬가지로 저장소의 크기는 임의로 제한되지 않습니다. SDK는 애셋 캐싱에 저장소를 사용할 수 있습니다. 이 저장소는 SDK가 실행 중이 아니면 주기적으로 지워집니다.

실행

앱, SDK, 사용자 간 비공개 시스템을 보장하려면 실행 컨텍스트 자체(코드 형식, 언어 구성, 액세스 가능한 API, 시스템 데이터)는 이러한 개인 정보 보호 경계를 강화해야 합니다. 또는 최소한 이를 우회할 수 있도록 하면 안 됩니다. 동시에 풍부한 플랫폼과 SDK가 현재 보유하는 대부분의 런타임 기능에 대한 액세스 권한을 유지하려고 합니다. 여기서는 이러한 균형을 이끌기 위해 런타임 환경 업데이트 집합을 제안합니다.

코드

Android 코드(앱과 SDK)는 코드가 Kotlin 또는 Java로 작성되었는지 여부와 관계없이 주로 Android 런타임(ART)에서 해석됩니다. ART의 풍부함과 ART가 제공하는 언어 구성은 특히 네이티브 코드에서 다른 대안과 비교할 때 제공하는 인증 가능성과 결합되어 기능과 개인 정보 보호의 적절한 균형을 유지하는 것으로 보입니다. 런타임 지원 SDK 코드는 JNI 액세스를 지원하는 대신 Dex 바이트 코드로만 구성되는 것이 좋습니다.

Google에서는 네이티브 코드 사용을 고려할 때 Android SDK의 내장 SQLite 버전과 같은 대안으로 대체해야 하는 맞춤 패키지 SQLite를 사용하는 등의 사용 사례가 있다는 것을 알고 있습니다.

SELinux

Android에서는 각 프로세스(루트로 실행되는 프로세스 포함)가 특정 SELinux 컨텍스트로 실행되므로 커널이 시스템 서비스, 파일, 기기, 기타 프로세스의 액세스 제어를 관리할 수 있습니다. 대부분의 SDK 사용 사례를 유지하면서 계속해서 개선하려는 개인 정보 보호 기능의 우회를 최소화하기 위해 비 시스템 앱의 SELinux 컨텍스트에서 다음 업데이트를 SDK 런타임에 제안합니다.

제한된 시스템 서비스 집합에 액세스할 수 있습니다. (현재 설계 중)
SDK는 APK에서만 코드를 로드하고 실행할 수 있습니다.
제한된 시스템 속성 집합에 액세스할 수 있습니다. (현재 설계 중)

API

SDK 런타임 내에서 리플렉션 사용 및 API 호출은 허용됩니다. 그러나 다른 런타임 지원 SDK에서는 SDK가 Reflection API 또는 Invoke API를 사용할 수 없습니다. 향후 업데이트에서 금지된 API에 관한 전체 제안서를 공유할 예정입니다.

또한 최근 Android 플랫폼 출시에서는 개인 정보 보호를 위해 영구 식별자 액세스가 점점 더 제한되고 있습니다. SDK 런타임의 경우 교차 앱 추적에 사용할 수 있는 식별자에 대한 액세스를 추가로 제한할 것을 제안합니다.

SDK 런타임 API는 포그라운드에서 실행되는 앱에서만 액세스할 수 있습니다. 백그라운드의 앱에서 SdkSandboxManager API에 액세스하려고 하면 SecurityException이 발생합니다.

마지막으로 RE SDK는 알림 API를 사용하여 어느 시점에서든 사용자 알림을 전송할 수 없습니다.

수명 주기

앱 SDK는 현재 호스트 앱의 수명 주기를 따릅니다. 즉, 앱이 포그라운드로 전환되거나 포그라운드에서 나가거나, 종료되거나 메모리 압력으로 운영체제에 의해 강제 종료되는 경우 앱의 SDK도 동일하게 작동합니다. 앱의 SDK를 다른 프로세스로 분리하는 제안은 다음 수명 주기 변경사항을 의미합니다.

앱이 사용자나 운영체제에 의해 종료될 수 있습니다. SDK 런타임이 그 직후 자동으로 종료됩니다.
SDK 런타임은 메모리 압력이나 SDK의 처리되지 않은 예외 등으로 인해 운영체제에 의해 종료될 수 있습니다.

Android 14에서는 앱이 포그라운드에 있으면 SDK 런타임이 높은 우선순위로 실행되며 종료될 가능성이 작습니다. 앱이 백그라운드로 이동하면 SDK 런타임 프로세스의 우선순위가 낮아지고 종료될 수 있습니다. 앱이 포그라운드로 다시 전환되어도 SDK 런타임 프로세스의 우선순위는 여전히 낮습니다. 따라서 SDK 런타임은 앱에 비해 메모리 압력으로 종료될 가능성이 매우 높습니다.

Android 14 이상에서는 앱과 SDK 런타임의 프로세스 우선순위가 일치됩니다. 앱과 SDK 런타임에 대한 ActivityManager.RunningAppProcessInfo.importance 프로세스 우선순위는 거의 동일해야 합니다.

앱이 활성화된 상태에서 SDK 런타임이 종료되면(예: SDK에 처리되지 않은 예외가 있는 경우) 이전에 로드된 모든 SDK와 원격 뷰를 포함하여 SDK 런타임 상태가 손실됩니다. 앱 개발자가 SDK 런타임 종료를 처리할 수 있는 방법은 다음과 같습니다.
- SDK 런타임 종료가 발생했을 때 앱 개발자가 감지할 수 있도록 관련된 수명 주기 콜백을 제공합니다.
- 광고가 표시되는 동안 SDK 런타임이 종료되면 광고가 예상대로 작동하지 않을 수도 있습니다. 예를 들어 뷰가 화면에서 멈추고 더 이상 상호작용하지 않을 수 있습니다. 광고 뷰가 사용자 환경에 영향을 미치지 않는 경우 앱에서 삭제할 수 있습니다.
- 앱에서 SDK를 로드하고 광고를 다시 요청하려고 다시 시도할 수 있습니다.
- Android 14에서는 SDK가 로드되는 동안 SDK 런타임이 종료되고 앱 개발자가 앞서 언급한 수명 주기 콜백 메서드를 등록하지 않았다면 앱은 기본적으로 종료됩니다. SDK를 로드한 앱 프로세스만 종료되고 정상적으로 리소스가 해제됩니다.
- 통신하기 위해 SDK에서 반환하는 바인더 객체(예: SandboxedSdk)를 앱에서 사용했다면 DeadObjectException이 발생합니다.
이 수명 주기 모델은 향후 업데이트에서 변경될 수 있습니다.

지속적인 실패가 발생할 경우 앱 개발자는 SDK와 별도로 단계적 성능 저하를 계획하거나 SDK가 앱의 핵심 기능에 중요한 경우 사용자에게 알려야 합니다. 앱과 SDK 간의 이러한 상호작용에 관한 자세한 내용은 이 문서의 커뮤니케이션 섹션을 참고하세요.

비 RE SDK는 서비스, 활동, 브로드캐스트를 포함하여 삽입된 앱에서 사용할 수 있는 표준 OS 프리미티브를 계속 사용할 수 있지만 RE SDK는 사용할 수 없습니다.

특수한 케이스

다음 케이스는 지원되지 않으며 예상치 못한 동작이 발생할 수 있습니다.

여러 앱이 동일한 UID를 공유하면 SDK 런타임이 제대로 작동하지 않을 수 있습니다. 향후 공유 UID 지원이 추가될 수 있습니다.
앱에 프로세스가 여러 개인 경우 기본 프로세스에서 SDK를 로드해야 합니다.

미디어 렌더링

앱에서 지정한 뷰에서 텍스트, 이미지, 동영상과 같은 콘텐츠를 렌더링하는 SDK가 있습니다. 이를 위해 SDK가 SDK 런타임 내에서 미디어를 렌더링하지만 SurfaceControlViewHost API를 사용하여 미디어가 앱 지정 뷰에서 렌더링되도록 허용하는 원격 렌더링 접근 방식을 제안합니다. 이를 통해 SDK는 이 미디어를 사용자에게 비공개되는 방식으로 렌더링하면서 렌더링된 미디어와의 잘못되거나 사기성의 사용자 상호작용을 방지 및 감지할 수 있습니다.

SDK가 렌더링하지 않고 앱에서 렌더링하는 네이티브 광고는 SDK 런타임의 SDK에서 지원합니다. 신호 수집 및 광고 소재 가져오기 프로세스는 네이티브가 아닌 광고에서 일관되게 발생합니다. 이는 현재 조사 중인 영역입니다.

인스트림 광고는 앱 내의 플레이어에 표시되는 동영상과 함께 인스트림으로 실행되는 광고입니다. 동영상이 SDK의 플레이어나 뷰가 아닌 앱의 플레이어 내에서 재생된다는 점을 고려하면 렌더링 모델은 다른 광고 형식과 다릅니다. Google에서는 서버 측 광고 삽입과 SDK 기반 광고 삽입을 모두 지원하는 메커니즘을 적극적으로 찾고 있습니다.

시스템 상태

Google은 SDK 런타임이 최종 사용자 기기에 미치는 시스템 상태 영향을 최소화하기 위해 노력하고 있으며 이를 위한 방법을 설계하고 있습니다. 그러나 Android (Go 버전)과 같이 시스템 리소스가 매우 제한된 일부 보급형 Android 14 기기는 시스템 상태 영향으로 인해 SDK 런타임을 지원하지 않을 가능성이 높습니다. 곧 SDK 런타임을 성공적으로 사용하는 데 필요한 최소 요구사항을 공유해 드릴 예정입니다.

커뮤니케이션

앱과 SDK는 현재 동일한 프로세스에서 실행되므로 이들 간 커뮤니케이션이 제한되지 않고 중재되지 않습니다. 또한 Android는 SDK로 커뮤니케이션이 시작되고 종료되더라도 앱 간 커뮤니케이션을 허용합니다. 이렇게 자유롭게 흐르는 커뮤니케이션 모델을 사용하면 여러 사용 사례를 지원하는 동시에 앱 간에 그리고 앱 내 및 앱 간의 SDK 간에 비공개 데이터를 공유할 수 있습니다. Google은 이러한 커뮤니케이션의 가치와 명시된 목표 실현 간의 균형을 이루려고 하는 이 커뮤니케이션 모델에 다음 업데이트를 제안합니다.

앱과 SDK 간

앱과 SDK 간의 인터페이스는 가장 일반적인 SDK 커뮤니케이션 경로이며 SDK의 API는 사용자 대상 차별화와 혁신의 대부분이 있는 곳입니다. Google은 여기에서 SDK의 혁신과 차별화 기능을 유지하려고 합니다. 따라서 제안서를 통해 SDK는 앱에 API를 확실히 노출하고 앱은 이러한 모든 혁신의 이점을 누릴 수 있습니다.

SDK 런타임의 프로세스 경계 구조를 고려할 때 Google에서는 앱 내에서 액세스할 수 있는 마샬링 레이어를 빌드하여 앱과 SDK 간의 이 경계에서 API 호출 및 응답 또는 콜백을 전달하는 것을 제안합니다. 이 마샬링 레이어에 관한 인터페이스는 SDK 개발자가 정의하고 Google에서 개발할 공식 오픈소스 빌드 도구로 생성할 것을 제안합니다.

이 제안서를 통해 앱 및 SDK 개발자에게서 상용구 마샬링 작업을 제거하는 동시에 SDK 개발자에게 유연성을 제공하고, SDK 코드가 SDK 런타임에서 실행되어 Google의 개인 정보 보호 목표가 실현되도록 하려고 합니다. 이 경로를 선택하면 개발자의 입력으로 API 정의 언어와 도구가 설계되어야 합니다.

일반적인 상호작용 모델은 다음과 같습니다.

앱이 인터페이스를 통해 SDK를 호출하여 콜백을 전달합니다.
SDK는 비동기적으로 요청을 충족하고 콜백을 사용하여 응답합니다.
이는 모든 게시자-구독자 모델에 일반화될 수 있습니다. 즉, 앱은 콜백을 통해 SDK의 이벤트를 구독할 수 있으며 이러한 이벤트가 발생하면 콜백이 트리거됩니다.

이 제안서의 새로운 프로세스 간 구조로 인해 관리해야 하는 프로세스 수명 주기는 두 가지로, 하나는 앱 자체의 프로세스 수명 주기이고 다른 하나는 SDK 런타임의 프로세스 수명 주기입니다. 제안서를 통해 앱 및 SDK 개발자에게 미치는 영향을 최소화하면서 이를 최대한 자동화하려고 합니다. 다음 다이어그램은 Google에서 고려하는 접근 방식을 보여줍니다.

앱 및 SDK 시작 중에 앱과 SDK 간 상호작용을 보여주는 시퀀스 다이어그램

플랫폼은 앱을 위한 새로운 API를 노출하여 SDK 런타임 프로세스에 SDK를 동적으로 로드하고, 프로세스 상태 변경사항에 관한 알림을 받고, SDK 런타임에 로드된 SDK와 상호작용합니다.

이전 그림의 그래프는 마샬링 레이어가 없는 하위 수준의 앱과 SDK 간 통신을 보여줍니다.

앱은 다음 단계를 통해 SDK 런타임 프로세스에서 실행되는 SDK와 통신합니다.

앱은 SDK와 상호작용하기 전에 플랫폼이 SDK를 로드하도록 요청합니다. 시스템 무결성을 보장하기 위해 앱은 매니페스트 파일에 로드하려는 SDK를 지정하며, 이러한 SDK만 로드될 수 있습니다.

다음 코드 스니펫은 API 예시를 보여줍니다.
```
SdkSandboxManager.loadSdk(String sdkName, Bundle data, Executor executor,
    OutcomeReceiver<SandboxedSdk, LoadSdkException> receiver)
```
SDK는 로드되었다는 알림을 받고 인터페이스를 반환합니다. 이 인터페이스는 앱 프로세스에서 사용됩니다. 프로세스 경계 외부에서 인터페이스를 공유하려면 IBinder 객체로 반환되어야 합니다.

바인드된 서비스 가이드는 IBinder를 제공하는 다양한 방법을 제공합니다. 어떤 방식을 선택하든 SDK와 호출자 앱 간에 일관되어야 합니다. 다이어그램은 AIDL을 예로 사용합니다.
SdkSandboxManager가 IBinder 인터페이스를 수신하여 앱에 반환합니다.

앱은 IBinder를 가져와 SDK 인터페이스로 전송하여 함수를 호출합니다.

IBinder binder = sandboxSdk.getInterface();
ISdkInterface mySdkInterface = ISdkInterface.Stub.asInterface(binder);
mySdkInterface.something();

또한 앱은 다음 단계에 따라 SDK에서 미디어를 렌더링할 수 있습니다.

이 문서의 미디어 렌더링 섹션에 설명된 것처럼 앱이 뷰에서 미디어를 렌더링하도록 SDK를 가져오기 위해 앱은 requestSurfacePackage()를 호출하여 적절한 SurfaceControlViewHost.SurfacePackage를 가져올 수 있습니다.

다음 코드 스니펫은 API 예시를 보여줍니다.
```
SdkSandboxManager.requestSurfacePackage(String sdkName, Bundle extraParams,
        Executor executor,
        OutcomeReceiver<Bundle, RequestSurfacePackageException> receiver)
```
그러면 앱은 반환된 SurfacePackage를 SurfaceView의 setChildSurfacePackage API를 통해 SurfaceView에 삽입할 수 있습니다.

다음 코드 스니펫은 API 예시를 보여줍니다.
```
SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)
```

Google의 제안은 IBinder 및 requestSurfacePackage() API가 일반적이며 앱에서 직접 호출할 수 없도록 하는 것입니다. 대신 이러한 API는 위에서 설명한 생성된 API 참조로 'shim' 레이어에서 호출하여 앱 개발자의 부담을 줄여줍니다.

SDK 간

동일한 앱의 두 SDK는 종종 통신이 필요합니다. 이는 특정 SDK가 구성요소 SDK로 구성되도록 설계되었을 때 발생할 수 있으며, 서로 다른 당사자의 두 SDK에서 호출 앱의 요청을 충족하기 위해 공동작업해야 할 때 발생할 수 있습니다.

고려할 두 가지 주요 사례는 다음과 같습니다.

두 SDK 모두 런타임을 지원하는 경우. 이 경우 두 SDK 모두 모든 보호 조치와 함께 SDK 런타임에 실행되고 있습니다. SDK는 현재 앱 내에서와 같이 통신할 수 없습니다. 이에 따라 로드된 모든 RE-SDK의 SandboxedSdk 객체를 가져올 수 있도록 SdkSandboxController의 API가 추가되었습니다. 이를 통해 RE-SDK가 SDK 런타임에 로드된 다른 SDK와 통신할 수 있습니다.
하나의 SDK만 런타임을 지원하는 경우.
- 호출 SDK가 앱에서 실행 중인 경우 이는 앱 자체가 SDK 런타임 내에서 두 번째 SDK를 호출하는 것과 동일하게 작동합니다.
- 호출 SDK가 SDK 런타임 내에서 실행 중인 경우 이 제안서에서는 앱의 코드가 수신 대기하고 처리하고 제공된 콜백으로 응답하는, 앱과 SDK 간 섹션에 설명된 IBinder를 사용하여 메서드를 노출하는 것을 권장합니다.
- 런타임을 지원하지 않는 광고 SDK는 자체적으로 등록하지 못할 수 있습니다. Google에서는 모든 파트너 또는 앱 SDK를 앱의 직접적인 종속 항목으로 포함하고 등록을 처리하는 미디에이터 SDK의 생성을 제안합니다. 이 미디에이터 SDK는 런타임을 지원하지 않는 SDK 또는 다른 앱 종속 항목과 어댑터 역할을 하는 런타임 지원 미디에이터 간 통신을 설정합니다.

SDK 간 통신을 위한 기능 세트는 다음과 같은 카테고리로 나뉩니다.

SDK 런타임 내의 SDK 간 통신(최신 개발자 프리뷰에서 사용 가능)
앱과 SDK 런타임 간의 SDK 간 통신(최신 개발자 프리뷰에서 사용 가능)
미디에이션에서 보기 및 원격 렌더링이 작동하는 방식(제안서 개발 중)

프리미티브를 설계할 때 다음 사용 사례가 고려됩니다.

미디에이션 및 입찰. 많은 광고 SDK는 광고 노출(미디에이션) 또는 입찰을 실행하기 위한 신호 수집(입찰)을 위해 SDK가 기타 다양한 SDK를 호출하는 미디에이션 또는 입찰 기능을 제공합니다. 일반적으로 조정 SDK는 조정 SDK에서 제공한 어댑터를 통해 다른 SDK를 호출합니다. 위의 프리미티브가 주어지면 조정 SDK(RE든 아니든)는 정상 작동을 위해 모든 RE 및 비 RE SDK에 액세스할 수 있어야 합니다. 이 컨텍스트에서 렌더링은 현재 조사 중인 영역입니다.
기능 검색. 일부 SDK 제품은 SDK 간 검색 프로세스를 통해 앱 개발자에게 노출되는 최종 기능 세트를 결정하는 더 작은 SDK로 구성됩니다. 등록 및 검색 프리미티브가 이 사용 사례를 사용 설정해야 합니다.
게시자 구독 모델. 일부 SDK는 다른 SDK 또는 앱에서 콜백을 통한 알림을 위해 구독할 수 있는 이벤트의 중앙 게시자를 보유하도록 설계되었습니다. 위의 프리미티브는 이 사용 사례를 지원해야 합니다.

앱 간

앱 간 통신에서는 통신하는 두 프로세스 중 최소 하나가 런타임 지원 SDK이며 비공개 데이터 공유를 위한 잠재적인 벡터입니다. 따라서 SDK 런타임은 클라이언트 애플리케이션 이외의 앱 또는 다른 앱을 위해 만들어진 다른 SDK 런타임의 SDK와의 직접 통신 채널을 설정할 수 없습니다. 이는 다음과 같은 방식으로 이루어집니다.

SDK는 <service>, <contentprovider> 또는 <activity> 같은 구성요소를 매니페스트에서 정의할 수 없습니다.
SDK는 ContentProvider를 게시하거나 브로드캐스트를 전송할 수 없습니다.
SDK는 다른 앱에 속한 활동을 실행할 수 있지만 인텐트에서 전송할 수 있는 항목에 제한이 있습니다. 예를 들어 이 인텐트에 추가 작업이나 맞춤 작업을 추가할 수 없습니다.
SDK는 서비스 허용 목록을 시작하거나 이 목록에 바인딩할 수만 있습니다.
SDK는 시스템 ContentProvider의 하위 집합(예: com.android.providers.settings.SettingsProvider)에만 액세스할 수 있습니다. 여기에는 획득한 데이터에 식별자가 없고 사용자의 지문을 빌드하는 데 이를 사용할 수 없습니다. 이러한 검사는 ContentResolver를 사용하여 ContentProvider에 액세스하는 경우에도 적용됩니다.
SDK는 보호되는 broadcast receiver의 하위 집합(예: android.intent.action.AIRPLANE_MODE)에만 액세스할 수 있습니다.

매니페스트 태그

SDK가 설치되면 PackageManager가 SDK의 매니페스트를 파싱하고, 금지된 매니페스트 태그가 있는 경우 SDK를 설치하지 못합니다. 예를 들어 SDK는 <service>, <activity>, <provider> 또는 <receiver>와 같은 구성요소를 정의하지 않을 수 있으며 매니페스트에서 <permission>을 선언하지 않을 수도 있습니다. 설치에 실패한 태그는 SDK 런타임에서 지원되지 않습니다. 설치에 실패하지는 않지만 자동으로 무시되는 태그는 향후 Android 버전에서 지원될 수 있습니다.

이러한 검사는 SDK 번들을 만드는 데 SDK가 사용하는 빌드 시간 도구에서 적용하거나 애플리케이션 스토어에 업로드할 때 적용할 수도 있습니다.

활동 지원

SDK 런타임 환경의 SDK는 활동 태그를 매니페스트 파일에 추가할 수 없으며 Context.startActivity를 사용하여 자체 활동을 시작할 수 없습니다. 대신 플랫폼은 요청 시 SDK의 활동을 만들고 SDK와 공유합니다.

플랫폼 활동의 유형은 android.app.Activity입니다. 플랫폼 활동은 앱 활동 중 하나에서 시작되며 앱 작업의 일부입니다. FLAG_ACTIVITY_NEW_TASK는 지원되지 않습니다.

SDK가 활동을 시작하려면 앱이 SdkSandboxManager::startSdkSandboxActivity(Activity, IBinder)를 호출하여 활동을 시작할 때 활동 생성에 관해 알리는 데 사용되는 SdkSandboxActivityHandler 유형의 인스턴스를 등록해야 합니다.

다음 그래프는 활동을 요청하는 흐름을 보여줍니다.

개발

이 제안서의 핵심 원칙은 가능한 한 개발자 생태계에 미치는 영향을 최소화하는 것입니다. 이 제안서에서는 개발자에게 RE 앱과 SDK를 작성, 빌드, 디버그할 수 있는 포괄적인 개발 도구 모음을 제공합니다. 이 제안서의 무결성을 보장하기 위해 RE 앱 및 SDK의 구성, 작성, 빌드 방식이 일부 변경됩니다.

작성

Android 스튜디오 및 관련 도구가 SDK 런타임을 인식하도록 업데이트되므로 개발자가 RE 앱 및 SDK를 올바르게 구성했는지 확인할 수 있고 관련 있는 경우 기존 또는 지원되지 않는 호출이 최신 대안으로 업데이트되도록 합니다. 제안서에는 작성 단계 중에 개발자가 진행해야 하는 몇 가지 단계가 있습니다.

앱 개발자

앱은 앱 매니페스트에서 RE SDK 및 SDK 인증서 종속 항목을 지정해야 합니다. 제안서에서는 이 제안서 전체에 걸쳐 이를 애플리케이션 개발자의 정보 소스로 간주합니다. 예:

이름: SDK 또는 라이브러리의 패키지 이름입니다.
주 버전: SDK의 주 버전 코드입니다.
인증서 다이제스트: SDK 빌드의 인증서 다이제스트입니다. 특정 빌드의 경우 SDK 개발자가 관련 앱 스토어를 통해 이 값을 가져오고 등록할 것을 제안합니다.

이는 RE 여부와 관계없이 앱 스토어 배포 SDK에만 적용됩니다. SDK를 정적으로 연결하는 앱은 현재 종속 항목 메커니즘을 사용합니다.

개발자에게 미치는 영향을 최소화한다는 목표를 고려할 때 SDK 런타임을 지원하는 대상 API 수준이 지정되면 앱 개발자는 SDK 런타임을 지원하거나 지원하지 않는 기기에서 단일 빌드가 실행되는지와 상관없이 이 빌드만 보유해야 하는 것이 중요합니다.

SDK 개발자

제안된 설계에서 RE SDK 개발자는 매니페스트에서 SDK 또는 라이브러리 항목을 나타내는 새 요소를 명시적으로 선언해야 합니다. 또한 종속 항목과 유사한 값 집합을 부 버전과 함께 제공해야 합니다.

이름: SDK 또는 라이브러리의 패키지 이름입니다.
주 버전: SDK의 주 버전 코드입니다.
부 버전: SDK의 부 버전 코드입니다.

RE SDK 개발자가 다른 RE SDK를 빌드 시간 종속 항목으로 갖는 경우 앱 개발자가 동일한 종속 항목을 선언하는 것과 동일한 방식으로 이를 선언해야 할 수 있습니다. 비 RE SDK에 종속되는 RE SDK는 이를 정적으로 연결합니다. 이로 인해 비 RE SDK에 SDK 런타임이 지원하지 않는 기능이 필요하거나 앱 프로세스에서 실행되어야 하는 경우 빌드 시간 또는 테스트 성공 중에 감지되는 문제가 발생할 수 있습니다.

RE SDK 개발자는 Android 12 이하 및 이 문서의 시스템 상태 섹션에서 언급한 시스템 리소스가 매우 제한된 보급형 Android 14 기기와 같은 RE 기반이 아닌 기기를 계속 지원하려고 할 수 있습니다. Google에서는 SDK 개발자가 단일 코드베이스를 유지하여 RE 및 비 RE 환경을 지원할 수 있도록 하는 접근 방식을 연구하고 있습니다.

빌드

앱 개발자

앱 개발자는 빌드 단계의 변화를 거의 경험하지 않을 것으로 예상됩니다. SDK 종속 항목은 로컬 배포든 앱 스토어 배포(RE든 아니든)든 상관없이 린트 작업, 컴파일, 빌드를 위해 머신에 있어야 합니다. Google에서는 Android 스튜디오가 일반적인 사용으로 앱 개발자로부터 이러한 세부정보를 추출하여 이를 최대한 투명하게 할 것을 제안합니다.

디버그 가능성을 위해 DEBUG 빌드에 있어야 할 모든 코드 및 기호가 DEBUG 빌드에 포함되어야 할 것으로 예상하지만 RELEASE 빌드에는 최종 아티팩트에서 삭제된 모든 앱 스토어 배포 SDK(RE든 아니든)가 선택적으로 포함됩니다.

지금은 설계 단계의 초기이므로 구체화 시에 내용을 더 많이 공유하겠습니다.

SDK 개발자

Google은 SDK의 비 RE 및 RE 버전이 배포를 위해 단일 아티팩트로 빌드될 수 있도록 하는 경로를 작업하고 있습니다. 이를 통해 앱 개발자는 SDK의 RE 및 비 RE 버전을 위해 별도의 빌드를 지원할 필요가 없습니다.

앱의 경우와 마찬가지로 앱 스토어 배포 종속 항목 SDK는 린트 작업, 컴파일, 빌드를 위해 머신에 있어야 하며 Android 스튜디오에서는 이를 원활하게 촉진해야 합니다.

테스트

앱 개발자

제안서에서 설명했듯이 앱 개발자는 Android 14를 실행하는 기기에서 평소처럼 앱을 테스트할 수 있습니다. 앱을 빌드하고 나면 RE 기기 또는 에뮬레이터에 앱을 설치할 수 있습니다. 이 설치 프로세스를 통해 SDK를 원격 SDK 저장소나 빌드 시스템의 캐시에서 가져왔는지와 관계없이 기기나 에뮬레이터의 SDK 런타임에 올바른 SDK가 설치됩니다.

SDK 개발자

SDK 개발자는 일반적으로 기기와 에뮬레이터에서 자체 테스트 앱을 사용하여 개발을 테스트합니다. 제안서에서는 이를 변경하지 않으며, 인앱 검증은 RE 앱과 비 RE 앱 모두를 위한 단일 빌드 아티팩트를 사용하여 위의 앱 개발자를 위해 설명된 것과 동일한 단계를 따릅니다. SDK 개발자는 SDK 런타임에 있는지와 상관없이 코드를 단계별로 실행할 수 있지만 고급 디버깅 및 프로파일링 도구에는 몇 가지 제한사항이 있을 수 있습니다. 이는 현재 조사 중인 영역입니다.

배포

SDK와 앱을 분리하는 Google의 설계 제안서로 인해 SDK의 앱 스토어 배포 가능성이 생겼습니다. 이는 특정 앱 스토어에 국한되지 않는 일반적인 가능성입니다. 이점은 다음과 같이 명확합니다.

SDK의 품질과 일관성을 보장합니다.
SDK 개발자를 위해 게시를 간소화합니다.
설치된 앱의 SDK 부 버전 업데이트 출시를 가속화합니다.

SDK 배포를 지원하려면 앱 스토어에서 다음과 같은 기능 대부분을 제공해야 할 수 있습니다.

SDK 개발자가 앱 스토어 배포 가능 SDK를 스토어에 업로드하고 업데이트하고 롤백하고 삭제할 수 있는 메커니즘
SDK 및 SDK 출처와 앱 및 앱 출처의 무결성을 보장하고 그 종속 항목을 확인하는 메커니즘
일관되게 안정적이고 성능 기준에 부합하는 방식으로 기기에 배포하는 메커니즘

시간 경과에 따른 제한 증가

SDK 런타임의 코드가 직면하는 제한사항이 이후 버전의 Android와 함께 변경될 것으로 예상됩니다. 애플리케이션 호환성을 보장하기 위해 특정 SDK 수준의 메인라인 모듈 업데이트에서는 이러한 제한사항이 변경되지 않습니다. 지정된 targetSdkVersion과 관련된 동작은 앱 스토어 정책을 통해 해당 targetSdkVersion에 대한 지원이 중단될 때까지 보존되며 targetSdkVersion 지원 중단은 앱보다 더 빠른 주기로 발생할 수 있습니다. 특히 처음 몇 개의 출시에서는 Android SDK 버전 전반에서 제한사항이 자주 변경될 것으로 예상됩니다.

또한 Google에서는 다음 버전의 Android에서 제안된 제한사항을 받는 그룹에 외부 및 내부 테스터가 참여할 수 있도록 카나리아 메커니즘을 구축하고 있습니다. 이렇게 하면 제안된 제한사항 변경에 관한 의견을 받고 확신을 얻는 데 도움이 됩니다.

FAQ

광고 관련 SDK란 무엇인가요?

광고 관련 SDK는 광고주가 소유하지 않은 앱에서 상업적 목적의 메시지로 사용자 타겟팅의 모든 부분을 용이하게 하는 SDK입니다. 여기에는 후속 타겟팅을 위해 사용자 그룹을 만들 수 있는 애널리틱스 SDK, 광고 게재 SDK, 광고 악용 방지 및 사기 방지 SDK, 참여 SDK, 기여 분석 SDK가 포함되지만 이에 국한되지는 않습니다.
SDK 런타임에서 모든 SDK를 실행할 수 있나요?

초기에는 광고 관련 SDK에 집중하지만 개인 정보 보호 친화적인 상태를 추구하고 위에 설명된 조건에서 작동할 수 있다고 생각하는, 비 광고 관련 SDK의 개발자는 SDK 런타임에서 실행되는 SDK에 관한 의견을 공유할 수 있습니다. 하지만 SDK 런타임은 모든 SDK 설계와 호환되도록 설계되지 않았습니다. 문서화된 제한사항 외에 SDK 런타임은 호스팅 앱과의 실시간 커뮤니케이션이나 높은 처리량 커뮤니케이션이 필요한 SDK에는 적합하지 않을 수 있습니다.
프로세스의 Java 기반 런타임 내에서의 격리 대신 프로세스 격리를 선택하는 이유는 무엇인가요?

현재 Java 기반 런타임은 Android 사용자에게 바람직한 개인 정보 보호 보장에 필요한 보안 경계를 쉽게 지원하지 않습니다. 이 같은 기능을 구현하려고 하면 수년간의 노력이 필요할 수 있고 성공이 보장되는 것도 아닙니다. 따라서 개인 정보 보호 샌드박스는 오랜 시간 테스트되고 잘 알려진 기술인 프로세스 경계를 사용합니다.
SDK를 SDK 런타임 프로세스로 이동하면 다운로드 크기 또는 공간이 절약되나요?

여러 앱이 동일한 버전의 런타임 지원 SDK와 통합된 경우 다운로드 크기와 디스크 공간이 줄어들 수 있습니다.
SDK 런타임에서 SDK가 액세스할 수 있는 앱 수명 주기 이벤트(예: 앱이 백그라운드로 전환되는 시점)의 종류는 무엇인가요?

Google에서는 클라이언트 애플리케이션의 앱 수준 수명 주기 이벤트(예: 앱이 백그라운드로 전환됨, 앱이 포그라운드로 전환됨)에서 SDK 런타임에 알림을 보내기 위한 설계 지원을 적극적으로 개발하고 있습니다. 설계와 샘플 코드는 예정된 개발자 프리뷰에서 공유됩니다.

SDK 런타임 개요

목표

격리된 프로세스에서 실행되는 SDK

신뢰할 수 있는 새 SDK 배포 모델

SDK 및 앱 빌드, 실행, 배포 방법 변경사항

액세스

SDK 권한

메모리

저장소

실행

코드

SELinux

API

수명 주기

특수한 케이스

미디어 렌더링

시스템 상태

커뮤니케이션

앱과 SDK 간

SDK 간

앱 간

매니페스트 태그

활동 지원

개발

작성

앱 개발자

SDK 개발자

빌드

앱 개발자

SDK 개발자

테스트

앱 개발자

SDK 개발자

배포

시간 경과에 따른 제한 증가

FAQ

추천 서비스