Google Play에서는 곧 개발자에게 APK 대신 App Bundle을 업로드하도록 강제할 예정이며, 이로 인해 요구 사항에 대한 불편한 보안 질문이 제기됩니다.
지난 11월, 구글이 발표했다 개발자는 APK 대신 AAB(Android App Bundle) 형식을 사용하여 Play 스토어에 새 앱을 게시해야 합니다. 얼마 전 구글은 개발자들에게 이 다가오는 요구 사항을 상기시켜 논란의 불씨를 일으켰습니다. Google이 APK를 죽이고, 사이드로딩을 제거하고, 타사 앱 스토어를 방해하고 있다고 믿는 사용자로부터 선반.
Android App Bundle이 사용자와 개발자 모두에게 익숙할 수 있는 기본 APK 형식에서 크게 벗어난 것은 사실입니다. App Bundle을 사용하면 꽤 많은 이점이 있지만 일부 개발자와 보안 전문가가 우려하는 App Bundle을 만드는 데에는 한 가지 중요한 측면이 있습니다.
이 글에서는 Android App Bundle로의 전환에 대해 우리가 본 비판과 제안된 솔루션을 다루고, 이러한 문제에 대해 Google이 제안한 솔루션에 대해서도 이야기하겠습니다.
배경
하지만 그 전에 일반적으로 Android에서 앱 배포가 어떻게 작동하는지 조금 이야기해야 합니다. 앱 서명과 App Bundle의 작동 방식을 이미 알고 있다면 이 부분을 건너뛰어도 됩니다.
APK
대부분의 경우 Android 앱은 APK 파일 내에 배포됩니다. APK에는 서명 매니페스트와 같은 일부 보안 기능과 함께 앱의 모든 코드와 리소스가 포함되어 있습니다. APK가 설치되면 기본적으로 특정 폴더에 복사되고 설치된 앱의 내부 데이터베이스에 추가됩니다.
서명
설치하는 동안 해당 앱의 서명도 확인되어 유효한지 확인합니다. 앱이 이미 설치된 경우 Android는 이미 설치된 앱과 새 앱의 서명을 확인합니다. 서명이 유효하지 않거나 일치하지 않으면 Android는 앱 설치를 거부합니다.
서명 확인은 Android 보안의 중요한 부분입니다. 설치하려는 앱이 유효하고 적어도 이미 설치한 앱과 동일한 소스에서 나온 것인지 확인합니다. 예를 들어, 설치하는 경우 다음과 같이 말하세요.
Play 스토어의 내 잠금화면 위젯 앱, 귀하는 내가 서명한 사람이고 그것이 진짜라는 것을 합리적으로 확신할 수 있습니다. 그런 다음 수상한 제3자 사이트에서 Lockscreen Widgets 업데이트를 설치하려고 시도했지만 실패했다면 누군가가 해당 APK를 변조하여 악성 코드를 추가했다는 사실을 알게 될 것입니다.앱 서명에 사용되는 키는 (이상적으로는) 절대 공개적으로 출시되었습니다. 이를 개인 키라고 합니다. 그런 다음 개인 키는 공개 키라고 하는 앱 서명에 표시된 키를 생성하는 데 사용됩니다. 이는 Android 및 앱 스토어에서 앱의 유효성을 확인하는 데 사용됩니다. 개인 키를 노출하지 않고 공개 키를 생성하는 방법에 대해서는 많은 암호화 수학이 필요하기 때문에 자세히 설명하지 않겠습니다. 더 자세한 내용을 원하시면 확인해 보세요 APK 서명에 관한 Google 문서 또는 단방향 수학 함수에 대해 조사해 보세요.
앱 서명의 또 다른 기능은 서명이 일치하는 앱에만 권한을 제한하는 기능입니다. Android는 프레임워크와 동일한 키로 서명된 앱만 특정 기능에 액세스할 수 있는 많은 기능에 대해 내부적으로 이 작업을 수행합니다.
앱 번들
이제 APK와 서명에 대한 간략한 개요를 살펴보았으니 App Bundle에 대해 이야기해 보겠습니다. APK 리소스가 들어오는 곳입니다. 리소스는 레이아웃, 이미지, 오디오 등과 같은 것입니다. 기본적으로 코드가 아닌 모든 것입니다. 다양한 디스플레이 구성과 다양한 언어를 더 잘 지원하기 위해 개발자는 장치 및 언어에 따라 사용되는 동일한 리소스의 여러 버전을 만들 수 있습니다.
그러나 APK에는 어떤 리소스를 사용하든 모든 리소스가 존재합니다. 그리고 그들은 공간을 차지합니다. 앱의 복잡성에 따라 많은 기기에 사용되지 않는 리소스가 많이 있을 수 있습니다. 이것이 바로 App Bundle이 해결하기 위해 만들어진 것입니다. 개발자는 APK처럼 App Bundle을 생성할 수 있으며, 해당 App Bundle은 APK처럼 Play 스토어에 업로드될 수 있습니다.
그런 다음 Google은 해당 App Bundle을 사용하여 다양한 기기 구성에 맞는 다양한 APK를 생성합니다. 각 App Bundle에는 해당 구성에 필요한 리소스만 포함되어 있습니다. 사용자가 해당 앱을 다운로드하려고 하면 해당 구성과 일치하는 생성된 APK가 제공됩니다. 이는 앱 다운로드 및 설치 크기를 줄여 대역폭과 저장 공간을 절약하는 데 도움이 됩니다.
물론 기기에 특정한 APK를 설치하면 다른 기기에 복사하여 문제 없이 설치하는 것이 더 어려워집니다. 관점에 따라 이는 좋을 수도 있고 나쁠 수도 있습니다. 한편으로는 사용자가 더 이상 전체 앱을 갖고 있지 않기 때문에 불법 복제가 더 어려워집니다. 반면에, 같은 이유로 합법적으로 앱을 보관하는 것이 더 어려워집니다.
앱 서명
Android App Bundle은 APK가 아니기 때문에 AAB 파일을 열고 기기에 직접 설치할 수는 없습니다. Play 스토어에 업로드하면 Google은 번들을 사용하여 서명되지 않은 다양한 APK 파일을 생성합니다. 해당 APK는 설치되기 전에 서명되어야 합니다.
개발자에게 생성된 APK에 서명하고 다시 업로드하도록 요청하는 대신 Google은 서명 자체를 관리합니다. Play 스토어는 자신이 생성한 새 키를 사용하거나 개발자에게 서명에 사용하는 키를 요청합니다. APK. 어느 옵션을 사용하든 Google은 개발자를 위한 공개 서명을 처리하고 업로드를 제공합니다. 열쇠. Google은 내부 확인을 위해 업로드 키를 사용하고 개발자가 업로드하는 App Bundle(또는 경우에 따라 APK)이 올바른지 확인합니다.
업로드 키가 손상되거나 분실된 경우 개발자는 새 키를 요청할 수 있으며 앱 배포에 사용된 서명 키는 변경되지 않습니다.
앱 서명에는 더 많은 내용이 있지만 이것이 이 문서와 관련된 내용입니다. 원하는 경우 App Bundle 및 앱 서명에 대한 자세한 내용을 읽어보세요. Wojtek Kaliciński가 작성한 이 매체 기사.
비판
이론적으로나 실제로 App Bundle은 매우 훌륭합니다. 사용자가 아무 것도 하지 않고도 데이터 사용량과 설치 크기를 줄일 수 있습니다. 그러나 구현 방식 때문에 지난 몇 달 동안 일부 개발자와 보안 연구원들은 우려를 제기해 왔습니다. 이러한 우려 사항을 요약하기 전에 잠시 시간을 내어 아래에 쓰여진 내용의 대부분이 직접적인 문제임을 말씀드리고 싶습니다. 일련의 기사를 기반으로 개발자 Mark Murphy의 커먼즈웨어. 그의 기사는 개발자의 관점에서 더 많은 세부 정보와 비판을 제공하므로 반드시 확인해야 합니다.
보안
기존 배포 모델에서 개발자는 APK에 서명하는 데 사용하는 키를 비공개로 유지합니다. 이 정보는 절대 대중에게 공유되지 않으며 승인된 사람만 접근할 수 있어야 합니다. 이렇게 하면 해당 사람들만 유효한 APK를 생성할 수 있습니다.
하지만 Play 스토어에서 App Bundle을 사용하는 경우 사용자가 받는 APK에 서명하는 키를 관리하는 사람은 Google입니다. 그만큼 기본 Google Play에 업로드된 새 앱의 동작 2021년 8월부터 Google이 개발자로부터 비공개로 유지되는 자체 배포 키를 만드는 것입니다.
제출하는 개발자 새로운 앱 개발자가 업데이트를 제출하더라도 기본적으로 Google에서 개인 키를 관리하게 됩니다. 기존 앱 APK를 계속 사용할 수 있습니다 또는 Google이 신규 사용자에게 사용할 새 키를 생성하여 AAB 배포로 전환할 수 있습니다. 기존 앱 필수는 아니다 APK 배포에서 Android App Bundle로 전환하려면 해당 옵션을 선택해야 합니다. 약간의 반발 끝에 Google은 심지어 그것을 가능하게 할 것이다 신규 앱과 기존 앱 모두에 대해 Google이 서명할 수 있도록 자신의 개인 키를 업로드합니다. 이러한 상황 중 어느 것도 이상적이지 않습니다. 어떤 경우에도 Google은 귀하가 원할 경우 귀하의 개인 키에 액세스할 수 있기 때문입니다. Android App Bundle을 사용하세요. 개발자는 8월 이후에 새 앱을 제출하려는 경우 선택의 여지가 없습니다. 2021!)
Google은 보안을 매우 중요하게 생각한다고 확신하지만 지구상에 데이터 침해로부터 안전한 회사는 없습니다. Google이 배포용 앱에 서명하는 데 사용하는 키가 이러한 위반 사항 중 하나에 속한다면 누구나 앱 버전에 서명하여 귀하가 서명한 것처럼 보이게 할 수 있습니다. 그리고 일부 개발자와 보안 전문가는 이러한 가능성에 만족하지 않습니다. 그렇습니다. 매우 희박한 가능성입니다. 하지만 가능성이 있다는 사실이 정보 보안 커뮤니티의 일부 사람들을 겁나게 합니다.
개발자가 Android APK에 서명하면 누구나 Google Play에서 APK를 확인할 수 있으며 맹목적인 신뢰가 필요하지 않습니다. 검증 가능한 보안을 제공하는 우아한 디자인입니다. App Bundle은 이를 뒤집어 벤더 종속성을 촉진하도록 구조화된 것처럼 보입니다. 개발자가 서명한 작은 APK를 제공하는 대체 기술 접근 방식이 많이 있지만 Play를 선호하지는 않습니다. 예를 들어 개발자가 모든 APK 변형을 생성하고 서명한 다음 모든 앱 스토어에 업로드할 수 있습니다.
개인 키의 안전한 저장소를 Google이나 개별 개발자의 손에 맡기는 것이 더 나은지에 대해서는 확실히 논쟁의 여지가 있습니다. 그러나 해당 개발자는 (아마도) 일반적으로 키에 대한 중앙 저장소를 사용하지 않습니다. 개발자가 Play 앱 서명을 사용하도록 함으로써 악의적인 공격자는 Google의 보안을 한 번만 침해하면 수천 또는 수백만 개의 키를 검색할 수 있습니다.
그 가치에 대해 Google이 인프라에서 서명 키를 보호하는 방법에 대해 말하는 내용은 다음과 같습니다.
[blockquote 작성자="Wojtek Kaliciński, Android Developer Advocate at Google"]Play 앱 서명을 사용하면 Google이 자체 키를 저장하는 데 사용하는 것과 동일한 인프라에 키가 저장됩니다.
키 액세스는 모든 작업에 대해 엄격한 ACL 및 변조 방지 감사 추적에 의해 관리됩니다.
개발자 키로 생성되고 서명된 모든 아티팩트는 검사/증명을 위해 Google Play Console에서 사용할 수 있습니다.
또한 키 손실을 방지하기 위해 기본 스토리지를 매우 자주 백업합니다. 이러한 백업은 강력하게 암호화되어 있으며 정기적으로 이러한 백업에서의 복원을 테스트합니다.
Google의 기술 인프라에 대해 알고 싶다면 다음을 읽어보세요. Google Cloud 보안 백서.[/인용문]
그만큼 모든 소리, 손실 및 도난이 여전히 가능합니다. 그리고 감사 추적은 향후 공격을 예방하는 데에만 도움이 됩니다. 그들은 위반된 키를 돌려받지 못할 것입니다.
무단 수정 가능성
Google이 App Bundle을 설정하는 방식과 관련된 한 가지 큰 문제는 승인되지 않은 수정 사항이 앱에 추가될 가능성이 있다는 것입니다. Google이 각 APK를 수동으로 빌드해야 하기 때문에 App Bundle에서 APK를 추출하는 프로세스에는 본질적으로 수정이 포함됩니다. 하는 동안 Google은 코드를 삽입하거나 수정하지 않을 것이라고 약속했습니다., App Bundle 프로세스의 문제점은 그렇게 할 수 있는 능력이 있다는 것입니다.
다음은 Google의 위치에 있는 회사가 수행할 수 있는 권한에 대한 몇 가지 예입니다.
사람들이 정부 감시의 위험 없이 통신하는 데 사용하는 보안 메시징 앱이 있다고 가정해 보겠습니다. 이는 권위주의 정부에 항의하는 사람들이나 심지어 개인정보를 보호하려는 사람들에게도 매우 유용한 도구가 될 수 있습니다. 앱 사용자가 말하는 내용을 볼 수 있는 능력을 원하는 정부는 Google이 앱 코드에 감시 백도어를 추가하도록 강요할 수 있습니다.
이 예는 좀 더 무해하지만 일부 사람들과 관련된 문제이기도 합니다. 하루에 수백만 건의 다운로드가 발생하지만 광고나 분석이 전혀 없는 앱이 있다고 가정해 보겠습니다. 이는 해당 데이터에 액세스할 방법이 없는 거대한 데이터 소스입니다. 광고 회사인 Google은 해당 데이터에 액세스하기를 원할 수 있습니다.
앱 배포의 클래식 APK 모델에서 Google은 서명을 변경하지 않고는 앱을 수정할 수 없습니다. 특히 인기 있는 앱에서 Google이 서명을 변경하면 업데이트가 설치되지 않기 때문에 사람들이 눈치챌 것입니다. 하지만 App Bundle과 앱 서명을 사용하면 Google은 앱을 배포하기 전에 앱에 자체 코드를 자동으로 삽입할 수 있습니다. Google이 서명 키를 소유하므로 서명은 변경되지 않습니다.
확실하게, 이러한 사례는 일어날 가능성이 매우 낮습니다.. Google은 단순히 문제가 있는 시장에서 완전히 철수하다, 적응하기보다는. 그러나 가능성이 낮더라도 여전히 가능합니다. 회사에서 어떤 일이 일어나지 않을 것이라고 약속한다고 해서 그것을 보장하는 것은 아닙니다.
코드 투명성
Google은 이러한 우려를 듣고 이번 주에 다음과 같은 새로운 기능을 도입했습니다. App Bundle의 코드 투명성. 코드 투명성을 통해 개발자는 기본적으로 앱과 함께 사용자에게 제공되는 두 번째 서명을 만들 수 있습니다. 이 추가 서명은 개발자만 액세스할 수 있는 별도의 개인 키에서 생성되어야 합니다. 그러나 이 방법에는 몇 가지 제한 사항이 있습니다.
코드 투명성은 코드에만 적용됩니다. 이름만 보면 분명해 보일 수도 있지만 이는 사용자가 리소스, 매니페스트 또는 DEX 파일이나 기본 라이브러리가 아닌 다른 항목을 확인할 수 없다는 의미이기도 합니다. 코드가 아닌 파일에 대한 악의적인 수정은 일반적으로 영향이 훨씬 적지만 여전히 앱 보안에 허점이 있습니다.
코드 투명성의 또 다른 문제는 고유한 검증이 없다는 것입니다. 하나는, 선택적인 기능입니다이므로 개발자는 업로드하는 모든 새 APK에 이를 포함해야 한다는 것을 기억해야 합니다. 현재로서는 명령줄에서 다음 버전을 사용하여 수행해야 합니다. bundletool Android Studio에는 제공되지 않습니다. 개발자가 이를 포함하더라도 Android에는 코드 투명성 매니페스트가 앱의 코드와 일치하는지 확인하기 위한 어떤 종류의 확인 기능도 내장되어 있지 않습니다.
개발자가 제공할 수 있는 공개 키와 매니페스트를 비교하거나 확인을 위해 개발자에게 APK를 전송하여 스스로 확인하는 것은 최종 사용자의 몫입니다.
코드 투명성을 사용하면 앱의 코드가 수정되지 않았는지 확인할 수 있지만 앱의 다른 부분에 대한 확인은 포함되지 않습니다. 또한 프로세스에 대한 본질적인 신뢰도 없습니다. Google을 신뢰하지 않는다면 아마도 독립적으로 확인 작업을 수행해야 한다고 주장할 수 있지만 왜 그렇게 해야 합니까?
코드 투명성 기능에는 다음과 같은 다른 문제가 있습니다. 지적했다 마크 머피(Mark Murphy) 커먼즈웨어. 기능에 대한 보다 심층적인 분석을 보려면 그의 기사를 읽어 보시기 바랍니다.
개발자 편의성과 선택
일부 개발자가 App Bundle에 대해 문제를 제기하는 세 번째(그리고 이 기사의 마지막) 이유는 편의성과 선택의 감소입니다.
Google에서 App Bundle을 요구하기 시작한 후 개발자가 Play 스토어에서 새 앱을 만들고 이를 선택한 경우 Google에서 서명 키를 관리하도록 하는 기본 옵션을 사용하면 해당 서명에 액세스할 수 없습니다. 열쇠. 동일한 개발자가 해당 앱을 다른 앱 스토어에 배포하려는 경우 Google의 키와 일치하지 않는 자체 키를 사용해야 합니다.
즉, 사용자는 Google Play 또는 타사 소스에서 설치하고 업데이트해야 합니다. 소스를 변경하려면 앱을 완전히 제거해야 하며, 이로 인해 데이터가 손실될 수 있으며 다시 설치해야 합니다. 다음과 같은 APK 수집기 APK미러 그러면 동일한 앱에 대한 여러 공식 서명도 처리해야 합니다. (기술적으로 앱 서명을 사용하면 신규 사용자를 위해 더욱 안전한 새 키를 생성할 수 있기 때문에 이미 이 작업을 수행해야 하지만 모든 사람이 가지다 그것을 하기 위해.)
이 문제에 대한 Google의 대응은 Play Console의 App Bundle 탐색기 또는 Artifact 탐색기를 사용하여 업로드된 번들에서 결과 APK를 다운로드하는 것입니다. 코드 투명성과 마찬가지로 이는 완전한 솔루션이 아닙니다. Play Console에서 다운로드한 APK는 다양한 기기 프로필에 맞게 분할됩니다. Play Console은 한 앱의 한 버전에 대해 여러 APK 업로드를 지원하지만 다른 배포 채널에서는 지원하지 않습니다.
따라서 개발자가 여러 스토어를 관리하면 App Bundle을 사용하여 얻을 수 있는 많은 이점이 사라져 배포가 더욱 어려워집니다. 그 소식으로 윈도우 11 ~이다 Android 앱 지원 확보 Amazon Appstore 덕분에 일부 사람들은 App Bundle 요구 사항이 개발자가 Amazon에 배포하는 것을 방해할 것이라고 믿습니다. 물론 Google의 주요 관심사는 자체 앱 스토어에 있지만, 그것이 바로 그 것입니다. 경쟁사들과 함께 그들을 뜨거운 물에 빠뜨렸어 그들이 만들도록 이끄는 작고 화해적인 변화 타사 앱 스토어가 Android에서 작동하는 방식에 대해 알아보세요.
여러 매장과 관련된 몇 가지 문제는 앱 상호 연결성과 신속한 테스트입니다.
앱 상호 연결성부터 시작해 보겠습니다. 페이월 뒤에 기능을 잠그는 앱을 다운로드한 적이 있습니까? 거의 확실합니다. 일부 개발자는 인앱 구매 뒤에 기능을 추가하지만 다른 개발자는 별도의 유료 앱을 만들기로 선택할 수도 있습니다. 해당 추가 기능 앱이 설치되면 기본 앱의 기능이 잠금 해제됩니다.
하지만 누군가가 불법 복제 소스에서 추가 기능을 설치하는 것을 막는 것은 무엇입니까? 개발자를 위한 옵션은 많지만 적어도 하나는 서명으로 보호된 권한을 사용하는 것과 관련이 있습니다. 기본 앱이 서명으로 보호되는 권한을 선언한다고 가정해 보겠습니다. 그런 다음 추가 기능 앱은 해당 권한을 사용하겠다고 선언합니다. 이상적으로, 추가 기능 앱에는 사용자가 합법적인지 확인하기 위해 인터넷에 연결하는 일종의 라이센스 확인 기능도 포함되어 있습니다.
두 앱의 서명이 동일한 경우 Android는 추가 기능 앱에 권한을 부여하고 불법 복제 방지 검사를 통과합니다. 추가 기능 앱에 올바른 서명이 없으면 권한이 부여되지 않으며 확인이 실패합니다.
클래식 APK 배포 모델을 사용하면 사용자는 합법적인 소스에서 두 앱 중 하나를 다운로드하여 작업을 완료할 수 있습니다. 현재 기본 App Bundle 모델을 사용하면 기본 앱과 추가 기능 앱의 서명이 일치하지 않습니다. Google은 각 앱마다 고유한 키를 만들 예정입니다. 개발자는 언제든지 서명으로 보호되는 권한을 없애고 직접 서명 해시 확인을 사용할 수 있지만 이는 훨씬 덜 안전합니다.
그리고 신속한 테스트가 있습니다. 사용자는 앱의 문제에 대해 항상 개발자에게 이메일을 보냅니다. 때로는 이러한 문제가 간단한 수정일 수도 있습니다. 즉, 문제를 재현하고, 문제를 찾고, 수정하고, 새 버전을 업로드하는 것입니다. 하지만 때로는 그렇지 않을 때도 있습니다. 개발자가 문제를 재현하지 못하는 경우도 있습니다. 문제라고 생각되는 부분을 해결할 수 있지만 그런 다음에는 사용자가 이를 테스트해야 합니다. 이제 사용자가 Google Play를 통해 앱을 설치했다고 가정합니다.
APK 모델을 사용하면 개발자는 일부 코드를 변경하고 새 APK를 빌드 및 서명한 다음 테스트를 위해 사용자에게 보낼 수 있습니다. 테스트 APK의 서명이 사용자가 설치한 서명과 일치하므로 업데이트, 테스트 및 보고하는 과정이 간단합니다. App Bundle을 사용하면 이러한 문제가 해결됩니다. Google은 사용자가 원래 설치한 APK에 서명하므로 개발자가 보낸 APK의 서명과 일치하지 않습니다. App Bundle 기한 이후에 이 앱이 게시되면 개발자는 Google이 사용하는 키에 액세스할 수도 없습니다. 테스트하려면 사용자는 테스트 버전을 설치하기 전에 현재 앱을 제거해야 합니다.
여기에는 많은 문제가 있습니다. 첫째, 개발자 측과 사용자 측 모두 불편함이 있다. 수정 사항을 테스트하기 위해 앱을 제거하는 것은 재미가 없습니다. 그리고 문제가 사라지면 어떻게 될까요? 개발자가 변경한 것입니까, 아니면 사용자가 앱 데이터를 효과적으로 삭제했기 때문입니까? Play 스토어에는 개발자가 신속한 빌드 및 배포를 수행할 수 있도록 하는 내부 테스트가 있지만 사용자가 먼저 릴리스 버전을 제거해야 합니다. 그것은 실제로 아무것도 고치지 않습니다.
이 모든 것이 헛소리처럼 들리는 경우를 대비해 Google에서 개인 키를 생성하도록 허용하면 이러한 문제를 겪게 될 개발자의 실제 예는 João Dias입니다. 그는 AutoApps 제품군을 포함한 다양한 플러그인 앱과 함께 Tasker의 개발자입니다. 새로운 App Bundle 요구 사항으로 인해 João의 개발 주기는 적어도 새로운 앱의 경우 훨씬 더 까다로워질 수 있습니다. 테스트 버전을 직접 보내는 것은 덜 편리합니다. 라이센스 확인은 덜 효과적입니다.
이것은 약간 극단적인 경우처럼 들릴 수도 있지만 João가 소규모 개발자는 아니며 혼자가 아닐 가능성도 높습니다. Play 스토어에는 불법 사용자를 감지하기 위해 서명 확인을 사용하는 앱이 많이 있습니다.
물론 개발자가 자신의 서명 키를 Google에 업로드할 수 있는 새로운 옵션을 사용하면 이러한 문제가 어느 정도 완화됩니다. 하지만 개발자는 각 앱에 대해 옵션을 활성화하도록 선택해야 합니다. 그렇지 않으면 상호 연결이 실패하고 신속한 지원을 위해서는 번들을 Google에 업로드하고 APK가 생성될 때까지 기다린 후 올바른 번들을 사용자에게 보내야 합니다. 게다가 이는 여전히 개인 키를 공유해야 한다는 것을 의미하며, 이는 앞서 논의한 우려 사항으로 돌아갑니다.
솔루션
App Bundle 요구 사항이 몇 달 전에 공개되었기 때문에 이는 오래된 문제이므로 그 사이에 꽤 많은 솔루션이 제안되었습니다.
한 가지 해결책은 Play 앱 서명이 필요하지 않도록 하는 것입니다. Google이 APK 및 서명으로 처리하는 App Bundle을 생성하는 대신 Android Studio에서 해당 처리를 수행할 수 있습니다. 그런 다음 개발자는 Google이 생성한 각 구성에 대해 로컬로 서명된 APK로 가득 찬 ZIP을 업로드할 수 있습니다.
이 솔루션을 사용하면 Google은 개발자의 키에 전혀 액세스할 필요가 없습니다. 이 프로세스는 기존 APK 배포 모델과 매우 유사하지만 단 하나가 아닌 여러 개의 작은 APK가 포함됩니다.
또 다른 해결책은 App Bundle 사용을 요구하지 않고 개발자가 로컬로 서명된 APK를 계속 업로드하도록 허용하는 것입니다. App Bundle은 대부분의 경우 사용자에게 더 나은 경험을 제공하기 위해 일부 앱은 구성별로 최소 크기로 분할하면 실제로 이점을 얻지 못합니다. 절감.
Google이 이 두 가지 솔루션을 모두 구현했다면 App Bundle을 사용하려는 개발자는 Google에 서명하는 것이 더 이상 필요하지 않으며 앱이 이 형식의 이점을 많이 누리지 못하는 개발자는 이를 사용할 필요가 없습니다. 모두.
Google의 응답
자체 서명
개발자가 App Bundle 서명을 처리할 수 있도록 허용하는 것에 대해 처음 질문을 받았을 때 Google의 답변은 매우 단호했습니다.
[blockquoteauthor=""]그래서 저는 내년에 새로운 앱이 App Bundle을 사용하기 위한 요구 사항에 대해 간략하게 이야기했는데, 그와 함께 제공되는 한 가지는 더 나아가 Play App Signing을 요구한다는 것입니다. 따라서 개발자는 Play에서 앱 서명 키를 생성하거나 자체 키를 Play에 업로드해야 합니다. 이는 App Bundle의 전제 조건이기 때문입니다. 우리는 개발자들 중 일부가 그것을 원하지 않는다는 말을 들었습니다. 그들은 Play에서 키를 관리하는 것을 원하지 않습니다. 현재 App Bundle을 사용하려는 경우에는 불가능합니다.
하지만 우리는 그 피드백을 들었고… 지금은 아무 것도 말할 수 없고, 발표할 것도 없지만, 이러한 우려를 완화할 수 있는 방법을 모색하고 있습니다. 번들을 업로드하는 동안 반드시 자신의 키를 유지하도록 허용할 필요는 없습니다. 우리는 다양한 옵션을 조사하고 있습니다. 지금 당장 발표할 수 있는 솔루션이 없습니다. 하지만 요구 사항까지 아직 1년 정도 남았기 때문에 이에 대해 개발자를 위한 답변을 얻을 수 있기를 바랍니다.[/blockquote]
작년 11월 말이었고 아무 일도 일어나지 않은 것 같습니다. 개강까지 몇 달 남지 않은 상황에서 App Bundle 요구사항이 시행됩니다., 개발자가 자신의 앱 서명을 처리할 수 있는 방법은 아직 없습니다. Google은 이제 다음을 가능하게 했습니다. 업로드 신규 앱과 기존 앱 모두에 대한 자체 키를 사용하면 여전히 개발자의 서명 부분이 필요합니다.
코드 변경
Google은 Play 스토어에서 앱 코드를 수정하지 않을 것이라고 구체적으로 약속했지만 약속이 보장되는 것은 아닙니다. App Bundle 및 앱 서명을 사용하면 Google이 배포 전에 업로드된 앱을 수정하는 것을 방지하는 데 따른 기술적 제한이 없습니다.
구글이 도입한 코드 투명성 선택적 기능으로, 이는 어느 정도 도움이 되지만 앞서 논의한 것처럼 상당한 문제를 안고 있습니다.
자체 제작 번들
Google이 개발자가 자신의 앱 '번들'(분할 APK가 포함된 ZIP)을 만들 수 있도록 허용하는 것에 대해 질문받았을 때 기본적으로 "우리는 그렇게 하지 않을 것입니다"라는 응답이 있었습니다.
아마도 질문에 설명된 것과는 다를 것입니다. 이렇게 하면 개발자에게 게시 프로세스가 더욱 어려워지고 실제로는 이를 더 간단하고 안전하게 만들고 싶습니다. 그러나 우리는 이 피드백을 듣고 이를 가능하게 하는 옵션을 조사할 것입니다. 그러나 아마도 여기에 설명된 방식이 아닐 수도 있습니다.
흥미롭게도 구글은 출판을 더욱 복잡하게 만들 것이라고 정당화하는 것 같습니다. 그러나 Google은 Android Studio의 APK 생성 대화 상자의 일부로 프로세스를 자동화할 수 있습니다. 게다가 문제의 앱이 여러 스토어에 배포된다면 실제로는 개발자가 여러 서명 키와 불만 사항을 관리할 필요가 없기 때문에 게시 프로세스가 더 간단해졌습니다. 사용자.
그리고 코드 투명성이 도입되면서 결국 복잡성은 그다지 문제가 되지 않는 것 같습니다. 적어도 현재로서는 코드 투명성을 위해서는 개발자가 명령줄 도구를 사용해야 하고 사용자는 자신이 제공하는 앱의 유효성을 명시적으로 확인해야 합니다. 이는 자체적으로 번들을 만드는 프로세스보다 더 복잡하며, 이것이 Google이 선호하는 솔루션인 이유가 불분명합니다.
앞으로
App Bundle은 8월 1일부터 Google Play에 제출되는 새 앱에 필요한 배포 형식이 됩니다. Google은 개발자와 보안 전문가가 제기한 대부분의 문제를 어느 정도 해결했지만 답변은 아쉬운 점이 많습니다. 차세대 배포 형식인 App Bundle에는 분명한 이점이 많이 있지만 앱 서명에 대한 부분적 또는 전체 제어권을 Google에 부여하는 것에 대한 우려는 항상 남아 있습니다.
Google의 대응과 노력은 확실히 높이 평가되지만 Mark Murphy와 같은 일부 사람들은 아직 충분하지 않다고 생각합니다. 자체 제작 번들과 같은 솔루션이 구현되지 않고 Android App Bundle 마감 기한이 빠르게 요구되는 상황 다가오는 시점에는 Google Play 개발자가 자신의 앱을 오랫동안 완전히 제어할 수 없을 것으로 보입니다. 더 길게.
오늘 오후 Twitter Space에서 Android App Bundle 요구사항의 의미에 대해 이야기할 예정이니 참여해 보세요!