Google Play скоро ще принуди разработчиците да качват App Bundles вместо APK, което повдига неудобни въпроси за сигурността относно изискването.
миналия ноември, Google обяви че от разработчиците ще се изисква да публикуват нови приложения в Play Store, използвайки формата на Android App Bundle (AAB) вместо APK. Точно онзи ден Google напомни на разработчиците за това предстоящо изискване, предизвиквайки буря от противоречия от потребители, които вярват, че Google убива APK, елиминира страничното зареждане, възпрепятства магазините за приложения на трети страни и какво ли не.
Вярно е, че Android App Bundles са доста голямо отклонение от класическия APK формат, с който може да сте свикнали, както като потребител, така и като разработчик. Въпреки че има доста предимства от използването на App Bundles, има един ключов аспект за направата им, който кара някои разработчици и експерти по сигурността с право да се притесняват.
В тази статия ще разгледаме критиките, които видяхме за преминаването към Android App Bundles, както и някои предложени решения, а също така ще говорим за предложеното от Google решение за тези проблеми.
Заден план
Преди това обаче да се случи, трябва да поговорим малко за това как разпространението на приложения работи на Android като цяло. Ако вече знаете как работят подписването на приложения и пакетите приложения, можете да пропуснете тази част.
APK файлове
В по-голямата си част приложенията за Android се разпространяват вътре в APK файлове. APK съдържа целия код и ресурси на приложението, заедно с някои функции за сигурност, като манифест за подписване. Когато APK е инсталиран, той просто се копира в конкретна папка и се добавя към вътрешна база данни с инсталирани приложения.
Подписи
По време на инсталацията подписът на това приложение също се проверява, за да се гарантира, че е валиден. Ако приложението вече е инсталирано, Android сравнява подписа на новото приложение с това, което вече е инсталирано. Ако подписът не е валиден или не съвпада, Android ще откаже да инсталира приложението.
Тази проверка на подписа е важна част от сигурността в Android. Той гарантира, че приложението, което инсталирате, е валидно и поне от същия източник като това, което вече сте инсталирали. Например, ако инсталирате, да речем, моето приложение Lockscreen Widgets от Play Store, можете да сте достатъчно сигурни, че аз съм този, който го е подписал и че е автентичен. Ако след това се опитате да инсталирате актуализация на Lockscreen Widgets от някой сенчест сайт на трета страна и тя не успее, ще знаете, че някой е подправил този APK, вероятно за да добави зловреден софтуер.
Ключът, използван за подписване на приложение, е (в идеалния случай) никога публично пуснат. Това е известно като частен ключ. След това частният ключ се използва за генериране на ключа, показан в подписа на приложението, известен като публичен ключ. Това е, което Android и магазините за приложения използват, за да проверят валидността на приложението. Няма да навлизам в това как точно можете да генерирате публичен ключ, без да разкривате частния ключ, тъй като това включва много математика за криптиране. Ако искате повече подробности, вижте Документация на Google за подписване на APK файлове или направете проучване на еднопосочните математически функции.
Друга функция на подписите на приложения е възможността да се ограничават разрешенията само до приложения със съвпадащи подписи. Android прави това вътрешно за много функции, където само приложения, подписани със същия ключ като рамката, имат достъп до определени функции.
Пакети приложения
И така, след като направихме бърз преглед на APK файловете и сигнатурите, нека поговорим за App Bundles. Тук идват APK ресурсите. Ресурсите са неща като оформления, изображения, аудио и т.н. По принцип те са всичко, което не е код. За да поддържат по-добре различни конфигурации на дисплея и различни езици, разработчиците могат да направят множество версии на един и същ ресурс, които се използват в зависимост от устройството и езика.
Но в APK всички тези ресурси съществуват, без значение кои използвате. И заемат място. В зависимост от сложността на вашето приложение може да има много неизползвани ресурси за много устройства. Това е, за което са създадени App Bundles. Разработчиците могат да генерират App Bundle точно като APK и този App Bundle може след това да бъде качен в Play Store, точно както APK може.
След това Google използва този App Bundle, за да генерира цял куп различни APK за различни конфигурации на устройства. Всеки App Bundle съдържа само ресурсите, необходими за тази конфигурация. Когато потребител отиде да изтегли това приложение, той получава генерирания APK, който съответства на неговата конфигурация. Това помага да се намалят размерите както за изтегляне, така и за инсталиране на приложения, спестявайки честотна лента и място за съхранение.
Разбира се, инсталирането на специфичен APK за вашето устройство означава, че е по-трудно за вас просто да го копирате на друго устройство и да го инсталирате без проблем. В зависимост от вашата гледна точка това може да е добро или лошо нещо. От една страна, това прави пиратството по-трудно, тъй като потребителите вече нямат цялото приложение. От друга страна, това прави законното архивиране на приложения по-трудно по същата причина.
Подписване на приложения
Тъй като Android App Bundles не са APK файлове, не можете просто да отворите AAB файл и да го инсталирате директно на устройство. Когато качите такъв в Play Store, Google използва пакета, за да генерира различни (неподписани) APK файлове. След това тези APK файлове трябва да бъдат подписани, преди да могат да бъдат инсталирани.
Вместо да поиска от разработчика да подпише и качи отново тези генерирани APK файлове, Google вместо това управлява самото подписване. Play Store или използва нов ключ, който създава, или иска от разработчика ключа, който използва за подписване APK файлове. И при двете опции Google обработва публичното подписване за програмиста и осигурява качване ключ. Google използва ключа за качване за вътрешна проверка и се уверява, че App Bundle (или APK в някои случаи), който програмистът качва, е правилният.
Ако ключ за качване е компрометиран или изгубен, разработчиците могат да поискат нов и ключът за подписване, използван за разпространение на приложението, остава непроменен.
Има много повече за подписването на приложения, но това е подходящото за тази статия. Ако искате, можете да прочетете повече за App Bundles и App Signing на тази статия Medium от Wojtek Kaliciński.
Критика
На теория и на практика пакетите приложения са страхотни. Те намаляват използването на данни и размера на инсталирането, без да се налага потребителят да прави нищо. Но поради начина, по който се прилага, някои разработчици и изследователи по сигурността през последните няколко месеца изразиха загриженост. Преди да обобщя тези опасения, искам да отделя малко време, за да кажа, че повечето от написаното по-долу е директно въз основа на поредица от статии от разработчика Марк Мърфи от CommonsWare. Абсолютно трябва да проверите неговите статии, тъй като те предоставят повече подробности и критики от гледна точка на разработчик.
Сигурност
В класическия модел на разпространение разработчикът запазва ключа, който използва за подписване на APK, личен. Никога не се споделя публично и само упълномощени хора трябва да имат достъп до него. Това гарантира, че само тези хора могат да генерират валиден APK.
Но ако използвате App Bundles в Play Store, Google е този, който управлява ключа, който подписва APK-тата, които потребителите получават. The по подразбиране поведение за нови приложения, качени в Google Play от август 2021 г е Google да създаде свой собствен дистрибуционен ключ, който пази личен от разработчика.
Разработчиците изпращат нови приложения ще накара Google да управлява техния частен ключ вместо тях по подразбиране, въпреки че разработчиците изпращат актуализации до съществуващи приложения може да продължи да използва APK файлове или те могат да преминат към разпространение на AAB, като генерират нов ключ, който Google да използва за нови потребители. Съществуващи приложения не са задължителни да преминат от разпространение на APK към Android App Bundles, въпреки че тази опция е достъпна за тях, ако изберат. След известно отблъскване Google дори ще го направи възможно за да качите свой собствен частен ключ, с който Google да се подписва, както за нови, така и за съществуващи приложения. Нито една от тези ситуации не е идеална, тъй като независимо от всичко, Google ще има достъп до личния ви ключ, ако искате използвайте Android App Bundles (и разработчиците нямат избор по въпроса, ако искат да изпратят ново приложение след август 2021!)
Въпреки че сме уверени, че Google приема сигурността много сериозно, няма компания на Земята, която да е имунизирана срещу пробиви на данни. Ако ключът, който Google използва, за да подпише приложението ви за разпространение, е в едно от тези пробиви, тогава всеки може да подпише версия на приложението ви и да я накара да изглежда така, сякаш е подписано от вас. И някои разработчици и експерти по сигурността не са доволни от тази възможност. Това е много, много малка възможност, да, но фактът, че това изобщо е възможност, плаши някои в информационната общност.
Подписването на APK за Android от разработчиците означава, че всеки може да проверява APK от Google Play, не е необходимо сляпо доверие. Това е елегантен дизайн, който осигурява проверима сигурност. Пакетите приложения обръщат това с главата надолу и изглеждат структурирани да насърчават привързването към доставчика. Има много алтернативни технически подходи, които биха предоставили малки APK файлове, все още подписани от разработчиците, но те не биха предпочели Play. Например, всички варианти на APK могат да бъдат генерирани и подписани от разработчика, след което да бъдат качени във всеки магазин за приложения.
Със сигурност има аргументи за това дали е по-добре да оставим защитеното съхранение на частните ключове в ръцете на Google или отделни разработчици. Но тези разработчици (вероятно) обикновено не използват централно хранилище за своите ключове. Принуждавайки разработчиците да използват подписване на приложения в Play, злонамерен нападател трябва само веднъж да наруши сигурността на Google, за да извлече хиляди или милиони ключове.
За какво си струва, ето какво казва Google за това как защитава вашия ключ за подписване в своята инфраструктура:
[blockquote author="Wojtek Kaliciński, защитник на разработчиците на Android в Google"]Когато използвате подписване на приложения в Play, вашите ключове се съхраняват в същата инфраструктура, която Google използва за съхраняване на собствените си ключове.
Достъпът до ключове се управлява от стриктни ACL и проверени одитни пътеки за всички операции.
Всички артефакти, генерирани и подписани с ключа на програмиста, са достъпни за вас в Google Play Console за проверка/атестация.
Освен това, за да предотвратим загуба на ключ, ние правим много често резервни копия на нашето основно хранилище. Тези резервни копия са силно криптирани и ние редовно тестваме възстановяването от тези архиви.
Ако искате да научите за техническата инфраструктура на Google, прочетете Бяла книга за сигурността в облака на Google.[/blockquote]
Колкото и да е страхотно, че всички звуци, загуба и кражба все още са възможни. А одитните пътеки само помагат за предотвратяване на бъдещи атаки; те няма да получат нарушените ключове обратно.
Потенциал за неоторизирани модификации
Един голям проблем с начина, по който Google е настроил App Bundles, е потенциалът за добавяне на неоторизирани модификации към приложение. Процесът на извличане на APK файлове от App Bundle по своята същност включва модификации, тъй като Google трябва ръчно да изгради всеки APK. Докато Google обеща, че не инжектира или модифицира код, проблемът с процеса на App Bundle е, че той има силата да го направи.
Ето няколко примера за това какво има властта да направи една компания в позицията на Google:
Да кажем, че има защитено приложение за съобщения, което хората използват, за да комуникират без риск от правителствено наблюдение. Това може да бъде невероятно полезен инструмент за хора, протестиращи срещу авторитарно правителство, или дори за хора, които просто искат да запазят личния си живот. Това правителство, което иска възможността да види какво казват потребителите на приложението, може да се опита да принуди Google да добави задна врата за наблюдение в кода на приложението.
Този пример е малко по-безобиден, но също така е нещо, което притеснява някои хора. Да кажем, че има приложение, което получава милиони изтегляния на ден, но в него няма никакви реклами или анализи. Това е огромен източник на данни без начин за достъп до тези данни. Google, като рекламна компания, може да иска достъп до тези данни.
В класическия APK модел на разпространение на приложения Google не може да модифицира приложенията без промяна на подписа. Ако Google промени подписа, особено на популярно приложение, хората ще забележат, защото актуализацията няма да се инсталира. Но с App Bundles и App Signing, Google може тихо да инжектира свой собствен код в приложенията, преди да ги разпространява. Подписът няма да се промени, защото Google ще притежава ключа за подписване.
За да бъде ясно, тези примери е невероятно малко вероятно да се случат. Google има склонност към просто да се оттегли напълно от проблемните пазари, вместо да се адаптират. Но въпреки че е малко вероятно, все още е възможно. Само защото една компания обещава, че нещо няма да се случи, тя не го гарантира.
Прозрачност на кода
Google, чувайки тези опасения, тази седмица представи нова функция, наречена Прозрачност на кода за пакети приложения. Прозрачността на кода позволява на разработчика по същество да създаде втори подпис, който се доставя с приложението на потребителите. Този допълнителен подпис трябва да бъде създаден от отделен частен ключ, до който само разработчикът има достъп. Има обаче някои ограничения за този метод.
Прозрачността на кода обхваща само кода. Това може да изглежда очевидно предвид името, но също така означава, че не позволява на потребителите да проверяват ресурси, манифест или нещо друго, което не е DEX файл или родна библиотека. Докато злонамерените модификации на файлове без код обикновено имат много по-малко въздействие, това все още е дупка в сигурността на приложението.
Друг проблем с прозрачността на кода е, че няма присъща проверка. За един, това е незадължителна функция, така че разработчиците трябва да не забравят да го включват за всеки нов APK, който качват. В момента трябва да се направи от командния ред и с версия на bundletool които не идват с Android Studio. Дори когато програмист го включи, Android няма вградена никаква проверка, за да провери дали манифестът за прозрачност на кода съответства на кода в приложението.
От крайния потребител зависи да провери сам, като сравни манифеста с публичен ключ, който разработчикът може да предостави, или като изпрати APK на разработчика за проверка.
Въпреки че прозрачността на кода позволява потвърждение, че нито един код в приложение не е променен, тя не включва никаква проверка за други части на приложението. Няма и присъщо доверие в процеса. Може да възразите, че ако нямате доверие на Google, вероятно сте се справили със задачата да проверите независимо, но защо трябва да го правите?
Има и други проблеми с функцията за прозрачност на кода, напр посочен от Марк Мърфи от CommonsWare. Препоръчвам да прочетете неговата статия за по-задълбочен анализ на функцията.
Удобство и избор за разработчици
Трета (и последна за тази статия) причина някои разработчици да се противопоставят на App Bundles е намаленото удобство и избор.
Ако програмист направи ново приложение в Play Store, след като Google започне да изисква App Bundles и той избере опцията по подразбиране да позволи на Google да управлява ключа за подписване, те никога няма да имат достъп до това подписване ключ. Ако същият разработчик след това иска да разпространи това приложение в друг магазин за приложения, той ще трябва да използва свой собствен ключ, който няма да съвпада с този на Google.
Това означава, че потребителите ще трябва или да инсталират и актуализират от Google Play или от източници на трети страни. Ако искат да променят източника, те трябва напълно да деинсталират приложението, потенциално загубвайки данни, и да го инсталират отново. APK агрегатори като APK Mirror след това също ще трябва да се справи с множество официални подписи за едно и също приложение. (Технически те вече трябва да направят това, защото подписването на приложения ви позволява да създадете нов, по-сигурен ключ за нови потребители, но ще бъде по-лошо за тях и за други сайтове, когато всички има да го направя.)
Отговорът на Google на този проблем е да използва App Bundle explorer или Artifact explorer в Play Console, за да изтегли получените APK файлове от качения пакет. Подобно на прозрачността на кода, това не е пълно решение. APK файловете, изтеглени от Play Console, ще бъдат разделени за различни профили на устройства. Въпреки че Play Console поддържа качване на множество APK файлове за една версия на едно приложение, много други канали за разпространение не го правят.
По този начин много от предимствата на използването на App Bundles изчезват, когато разработчиците управляват множество магазини, което прави разпространението по-трудно. С новини, които Windows 11 е получаване на поддръжка за приложения за Android благодарение на Amazon Appstore, някои смятат, че изискването за App Bundles ще демотивира разработчиците да разпространяват в Amazon. Разбира се, основната грижа на Google е собственият му магазин за приложения, но това е точно това ги приземи в гореща вода с конкуренти което ги кара да направят малки, помирителни промени как магазините за приложения на трети страни работят на Android.
Няколко проблема, свързани с множество магазини, са взаимосвързаността на приложенията и бързото тестване.
Нека започнем с взаимосвързаността на приложенията. Изтегляли ли сте някога приложение, което заключва функции зад платена стена? Почти определено. Някои разработчици поставят функциите зад покупка в приложение, но други могат да изберат да направят отделно, платено приложение. Когато това приложение за добавка се инсталира, функциите на основното приложение се отключват.
Но какво пречи на някой просто да инсталира добавката от пиратски източник? Е, има много опции за разработчиците, но поне една включва използване на защитени с подпис разрешения. Да кажем, че основното приложение декларира разрешение, защитено с подпис. След това приложението за добавка декларира, че иска да използва това разрешение. В идеалния случай приложението за добавка ще има и някаква функционалност за проверка на лиценза, която се свързва с интернет, за да се увери, че потребителят е легитимен.
Ако и двете приложения имат еднакъв подпис, Android ще даде разрешение на приложението за добавка и проверките за защита от пиратство ще преминат. Ако приложението за добавка няма правилния подпис, разрешението няма да бъде дадено и проверката ще бъде неуспешна.
С класическия модел на разпространение на APK, потребителят може да получи всяко приложение от всеки законен източник и да приключи с него. С текущия модел на App Bundle по подразбиране, подписите на основното и допълнителното приложение няма да съвпадат. Google ще направи уникален ключ за всяко приложение. Разработчикът винаги може да се откаже от защитеното с подпис разрешение и да използва директна хеш проверка на подписа, но това е много по-малко сигурно.
И тогава има тестове за бърз огън. Потребителите постоянно изпращат имейли на разработчиците за проблеми в техните приложения. Понякога тези проблеми са прости корекции: възпроизведете проблема, намерете проблема, поправете го и качете нова версия. Но понякога не са. Понякога разработчиците не могат да възпроизведат проблем. Те могат да поправят това, което смятат, че е проблемът, но след това потребителят трябва да го тества. Сега приемете, че потребителят е инсталирал приложението през Google Play.
С APK модела разработчикът може да промени някакъв код, да създаде и подпише нов APK и да го изпрати на потребителя за тестване. Тъй като подписът на тестовия APK съвпада с този, който потребителят е инсталирал, това е лесен процес за актуализиране, тестване и докладване. С App Bundle това се разпада. Тъй като Google подписва APK, първоначално инсталиран от потребителя, той няма да съответства на подписа на APK, който програмистът изпраща. Ако това приложение бъде публикувано след крайния срок за App Bundles, разработчикът дори няма да има достъп до ключовите елементи, които Google използва. За да тества, потребителят ще трябва да деинсталира текущото приложение, преди да инсталира тестовата версия.
Тук има куп проблеми. Първо, има неудобство както от страна на програмиста, така и от страна на потребителя. Да се налага да деинсталирате приложението само за да тествате поправка, не е забавно. И какво, ако проблемът изчезне? Дали това са промените, направени от разработчика, или защото потребителят ефективно е изчистил данните на приложението? Play Store има вътрешно тестване, което трябва да позволи на разработчиците да правят бързи компилации и разпространение, но изисква потребителят първо да деинсталира версията за освобождаване. Това наистина не коригира нищо.
В случай, че всичко това звучи като куп хипотетични глупости, ето един много реален пример за разработчик, който ще има тези проблеми, ако позволи на Google да генерира частен ключ за него: Жоао Диас. Той е разработчик на Tasker, заедно с цял куп плъгини, включително пакета AutoApps. С новото изискване за App Bundles, цикълът на разработка на João може да стане много по-сложен, поне за нови приложения. Изпращането на тестови версии директно ще бъде по-малко удобно. Проверката на лицензи ще бъде по-малко ефективна.
Това може да звучи малко като ръбов случай, но не е като Жоао да е малък разработчик и вероятно не е сам. В Play Store има много приложения, които разчитат на проверка на подписа за откриване на нелегитимни потребители.
Разбира се, с новата опция за разработчиците да качват свои собствени ключове за подписване в Google, тези проблеми са поне донякъде облекчени. Но разработчиците трябва да се включат, за да активират опцията за всяко приложение. Ако не го направят, връзките ще се провалят и поддръжката за бърза стрелба ще изисква качване на пакет в Google и изчакване да бъдат генерирани APK файлове, преди да изпрати правилния на потребителя. Плюс това, това все още означава, че те трябва да споделят личния си ключ, което ни връща към опасенията, които обсъдихме по-рано.
Решения
Това е стар проблем, тъй като изискванията на App Bundle бяха публикувани преди месеци, така че междувременно бяха предложени доста решения.
Едно решение е да се избегне необходимостта от подписване на приложения в Play. Вместо да генерира App Bundle, който Google след това обработва в APK и подписва, тази обработка може да се извърши от Android Studio. След това разработчиците могат просто да качат ZIP, пълен с локално подписани APK файлове за всяка конфигурация, която Google би генерирал.
С това решение Google изобщо няма да има нужда от достъп до ключовете на разработчиците. Процесът ще бъде много подобен на класическия модел на разпространение на APK, но ще включва множество по-малки APK вместо само един.
Друго решение е просто да не изисквате използването на App Bundles и да продължите да позволявате на разработчиците да качват локално подписани APK файлове. Докато App Bundle може бъде по-добро изживяване за потребителя в много случаи, някои приложения всъщност не се възползват от това, че са разделени на конфигурация, с минимален размер намаляване.
Ако Google внедри и двете от тези решения, тогава разработчик, който иска да използва App Bundles, няма да трябва над подписването в Google и програмист, чието приложение няма да се възползва много от формата, няма да трябва да го използва в всичко.
Отговорите на Google
Самоподписване
Когато за първи път бяха попитани дали да позволят на разработчиците да се справят с подписването за App Bundles, отговорът на Google беше много неангажиращ:
[blockquote author=""]И така, говорих накратко за изискването през следващата година новите приложения да използват пакети с приложения и едно нещо, което идва с това е, че като разширение ще изискваме подписване на приложения в Play. Така че разработчиците ще трябва или да генерират ключа за подписване на приложения в Play, или да качат свой собствен ключ в Play… защото това е предпоставка за пакети приложения. Чухме от разработчиците, че някои от тях просто не искат да го правят. Те не искат да имат ключове, управлявани от Play. И в момента това не е възможно, ако искате да използвате пакети приложения.
Но чухме тази обратна връзка и... не мога да говоря за нищо в момента, нямаме какво да обявим, но търсим как можем да облекчим някои от тези опасения. Не е задължително да позволявате да запазите собствения си ключ, докато качвате пакети. Разглеждаме различни варианти. Просто нямаме решение, което да обявим в момента. Но все още имаме около година до изискването, така че наистина се надявам, че ще имаме отговор за разработчиците за това.[/blockquote]
Това беше в края на ноември миналата година и изглежда нищо не се е случило. Остават само няколко месеца преди Изискването за App Bundles влиза в сила, все още няма начин разработчиците да се справят с подписването на собствените си приложения. Докато Google вече направи възможно качване вашият собствен ключ както за нови, така и за съществуващи приложения, това все още отнема частта за подписване от ръцете на разработчика.
Промени в кода
Въпреки че Google изрично обеща, че Play Store няма да променя кода на приложението, обещанието не е гаранция. С App Bundles и App Signing няма техническо ограничение, за което знаем, че не позволява на Google да променя качени приложения преди разпространение.
Google представи Прозрачност на кода като незадължителна функция и макар това да помага донякъде, има своя дял от проблеми, както обсъдихме по-рано.
Самоизработени пакети
Когато Google беше попитан относно разрешаването на разработчиците да правят свои собствени „пакети“ на приложения (ZIP файлове, съдържащи разделени APK файлове), отговорът беше основно „няма да правим това“:
Вероятно не както е описано във въпроса, тъй като това би направило процеса на публикуване още по-труден за разработчиците, а ние всъщност искаме да го направим по-прост и по-безопасен. Отново обаче чухме тази обратна връзка и ще разгледаме варианти как да направим това възможно, но вероятно не по начина, описан тук.
Интересното е, че оправданието на Google изглежда е, че това ще направи публикуването по-сложно. Въпреки това, Google може да направи процеса автоматизиран като част от диалоговия прозорец за генериране на APK в Android Studio. Освен това, ако въпросното приложение се разпространява в множество магазини, то всъщност би направило по-прост процес на публикуване, тъй като разработчиците няма да трябва да управляват множество ключове за подписване и оплаквания от потребители.
И с въвеждането на прозрачността на кода изглежда, че усложняването не е точно проблем. Прозрачността на кода, поне засега, изисква разработчикът да използва инструмент от командния ред и потребителите изрично да потвърдят валидността на приложението, което им се предлага. Това е по-сложно от процес за самостоятелно създаване на пакети и не е ясно защо това е решението, което Google предпочита.
Върви напред
Пакетите приложения ще бъдат необходимият формат за разпространение за нови приложения, изпратени в Google Play от 1 август. Въпреки че Google поне донякъде се справи с повечето от проблемите, повдигнати от разработчици и експерти по сигурността, отговорите оставят много да се желае. Има много очевидни предимства на App Bundles като формат за разпространение от следващо поколение, но винаги ще има продължаващи опасения относно предоставянето на частичен или пълен контрол върху подписването на приложения на Google.
Отговорите и усилията на Google със сигурност са оценени, но някои, като Марк Мърфи, смятат, че не са стигнали достатъчно далеч. С решения като самостоятелно направени пакети, които не се внедряват и крайният срок за Android App Bundles се изисква бързо наближава, не изглежда, че разработчиците в Google Play ще могат да запазят пълен контрол върху своите приложения за дълго повече време.
Ще говорим за последиците от изискването за Android App Bundle в Twitter Space по-късно този следобед, така че се присъединете към нас!