Android의 개인 정보 보호 샌드박스 개발자 프리뷰 1이 출시되었습니다. 시작하는 방법을 알아보고 의견을 제공해 주세요.

SDK 런타임

의견 보내기

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

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

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

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

목표

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

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

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

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

변경 전:


변경 후:

그림 1. 런타임 지원 SDK가 SDK 런타임에 추가되기 전후의 상대적 위치. '변경 전' 다이어그램(첫 번째)은 SDK 호출 코드와 이 코드에서 호출을 수신하는 SDK가 모두 앱의 프로세스에 있음을 보여줍니다. '변경 후' 다이어그램(두 번째)은 앱의 포그라운드 프로세스에서 SDK 호출 코드가 SDK 인터페이스와 커뮤니케이션하는 것을 보여줍니다. 그러면 이러한 인터페이스는 프로세스 경계를 지나 SDK 런타임 프로세스로 이동하여 SDK 자체를 호출합니다.

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

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

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

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

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

그림 2는 제안된 SDK 배포 변경사항을 보여줍니다.

변경 전:

변경 전 다이어그램

변경 후:

변경 후 다이어그램
그림 2. 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: 네트워크 정보에 액세스합니다.
  • 앱 간 식별자에 액세스하지 않고도 핵심 광고 기능을 제공하는 개인 정보 보호 API에 액세스하는 권한입니다. 권한 이름은 확정되지 않았지만 이러한 API는 이러한 권한에 대한 앱의 액세스로 관리됩니다.
  • AD_ID: 광고 ID를 요청할 수 있습니다. 이 또한 이 권한에 대한 앱의 액세스로 관리됩니다.
  • BIND_GET_INSTALL_REFERRER_SERVICE: Google Play Install Referrer API를 사용하여 앱 설치 소스의 속성을 지정할 수 있습니다.

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

메모리

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

저장소

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

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

현재 저장소 모델과 마찬가지로 저장소 자체는 크기와 기간에 임의 제한이 없습니다. 즉, 임시는 아니지만 대신 앱 제거 시간에 삭제됩니다.

실행

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

코드

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

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

SELinux

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

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

API

대부분의 자바 기반 언어 API는 Google이 SDK 런타임에서 도달하기 위해 노력하는 개인 정보 보호 모델을 지원하지만 리플렉션 및 호출 API와 같이 사용자 및 SDK 개인 정보 보호를 유지하기 어렵게 하는 자바 기반 API가 몇 가지 있습니다. 따라서 Google에서 적극적으로 조사 중인 다른 API와 함께 SDK 런타임 내에서 이 두 가지 API 집합에 대한 액세스를 방지할 것을 제안하며 다양한 사용 사례에 미치는 영향과 관련하여 의견을 구합니다. 향후 업데이트에서 전체 제안서를 공유해 드릴 예정입니다.

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

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

수명 주기

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

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

    SDK 런타임은 연결된 앱보다 약간 낮은 우선순위로 실행됩니다. 따라서 메모리 압력으로 인해 SDK 런타임 직후 앱이 종료될 가능성이 높습니다. 그렇지 않은 경우 또는 다른 이유가 있는 경우 제안서에서는 앱 개발자가 이 예외를 처리하고 SDK 런타임을 새로고침하는 init() 호출을 사용하여 이를 다시 초기화하도록 관련 수명 주기 콜백 메서드를 제공합니다.

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

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

미디어 렌더링

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

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

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

시스템 상태

SDK 런타임이 최종 사용자 기기에 미치는 시스템 상태 영향을 최소화하려고 하며 이를 위한 방법을 계획하고 있습니다. 하지만 대부분의 경우 Android(Go 버전)과 같이 시스템 리소스가 매우 제한된 일부 보급형 Android 13 기기는 시스템 상태 영향으로 인해 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 개발자에게 미치는 영향을 최소화하면서 이를 최대한 자동화하려고 합니다. 그림 3은 Google에서 고려하는 접근 방식을 보여줍니다.

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

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

  • 우선 앱은 SDK 런타임 프로세스가 (다시) 시작되거나 SDK가 데이터를 다시 앱으로 전송할 때와 같은 이벤트에 관한 알림을 받도록 콜백을 등록합니다. 예를 들어 앱은 앱 시작 중에 콜백을 등록할 수 있습니다.

    다음 코드 스니펫은 API 예시를 보여줍니다.

    SdkRuntimeManager.registerSdkRuntimeCallback(SdkRuntimeCallback callback,
        Executor executor)
    
  • 앱이 SDK와 상호작용하기 전에 먼저 앱은 플랫폼이 SDK를 로드하도록 요청합니다. 시스템 무결성을 보장하기 위해 앱은 매니페스트 파일에 로드하려는 SDK를 지정하며, 이러한 SDK만 로드될 수 있습니다. 앱은 특정 SDK나 매니페스트에 정의된 모든 SDK를 로드하도록 요청할 수 있습니다. 그러면 앱 시작 중에 또는 SDK 런타임이 다시 시작될 때 앱이 SDK를 로드할 수 있습니다.

    다음 코드 스니펫은 API 예시를 보여줍니다.

    SdkRuntimeManager.loadSdk(String sdkName, LoadSdkCallback callback,
        Executor executor)
    
    SdkRuntimeManager.loadAllSdks(LoadAllSdksCallback callback,
        Executor executor)
    
  • SDK가 SDK 런타임에 로드된 후 Google의 제안서에서는 앱이 SDK의 인터페이스에서 생성된 마샬링 레이어를 통해 SDK와 상호작용하도록 허용합니다. 내부적으로는 sendData() API를 통해 호출이 마샬링됩니다. 실제 예시:

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

    다음 코드 스니펫은 API 예시를 보여줍니다.

    SdkRuntimeManager.requestSurfacePackage(String sdkName, IBinder appToken,
        int displayId, Bundle extraParams,
        RequestSurfacePackageCallback callback, Executor executor)
    
  • 그런 다음 앱은 반환된 SurfacePackage를 SurfaceView의 setChildSurfacePackage API를 통해 SurfaceView에 삽입할 수 있습니다.

    다음 코드 스니펫은 API 예시를 보여줍니다.

    SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)
    

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

SDK 간

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

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

  • 두 SDK가 모두 RE인 경우 이 경우 두 SDK가 검색을 위한 리플렉션 기능 부족을 포함하여 모든 보호 조치와 함께 SDK 런타임에서 모두 실행됩니다. SDK는 현재 앱 내에서와 같이 커뮤니케이션할 수 없습니다. 따라서 커뮤니케이션을 용이하게 하려고 SDK 등록 및 검색을 위해 SDK 런타임에서 API를 설계합니다.
  • 한 SDK만 RE인 경우.
    • 호출 SDK가 앱에서 실행 중인 경우 이는 앱 자체가 SDK 런타임 내에서 두 번째 SDK를 호출하는 것과 다르지 않게 작동합니다.
    • 호출 SDK가 SDK 런타임 내에서 실행 중이면 앱의 코드가 수신 대기하고 처리하고 제공된 콜백으로 응답하는 일반 sendData(...) 호출을 노출하도록 제안합니다. 이는 현재 조사가 진행 중입니다.

Google에서는 이러한 프리미티브를 설계할 때 다음 사용 사례를 고려합니다.

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

앱 간

앱 간 커뮤니케이션으로, 커뮤니케이션하는 두 프로세스 중 하나 이상이 RE SDK입니다. 이는 앱 간 커뮤니케이션이므로 비공개 데이터 공유를 위한 자연스러운 벡터입니다.

따라서 SDK 런타임은 브로드캐스트와 인텐트를 포함한 어떠한 수단으로도 다른 앱 프로세스와 커뮤니케이션할 수 없습니다. 따라서 SDK 런타임 내의 SDK는 다른 앱 또는 다른 앱에서 호스팅하는 RE SDK와 커뮤니케이션할 수 없습니다.

개발

이 제안서의 핵심 원칙은 가능한 한 개발자 생태계에 미치는 영향을 최소화하는 것입니다. 따라서 이 제안서에서는 개발자에게 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 13 기기와 같은 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 13을 실행하는 기기에서 평소처럼 앱을 테스트할 수 있습니다. 앱을 빌드하고 나면 RE 기기 또는 에뮬레이터에 앱을 설치할 수 있습니다. 이 설치 프로세스를 통해 SDK를 원격 SDK 저장소나 빌드 시스템의 캐시에서 가져왔는지와 관계없이 기기나 에뮬레이터의 SDK 런타임에 올바른 SDK가 설치됩니다.

SDK 개발자

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

배포

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

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

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

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

FAQ

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

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

  2. SDK 런타임에서 모든 SDK를 실행할 수 있나요?

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

  3. 프로세스의 자바 기반 런타임 내에서의 격리 대신 프로세스 격리를 선택한 이유는 무엇인가요?

    현재 자바 기반 런타임은 Google에서 Android 사용자에게 제공하려고 하는 개인 정보 보호 보장에 필요한 보안 경계를 손쉽게 촉진하지 않습니다. 이 같은 기능을 구현하려고 하면 수년간의 노력이 필요할 수 있고 성공이 보장되는 것도 아닙니다. 따라서 오랜 시간에 걸쳐 검증되고 잘 파악된 기술인 프로세스 경계를 사용하기로 했습니다.