Незабаром Google Play змусить розробників завантажувати набори додатків замість файлів APK, що викликає незручні питання безпеки щодо цієї вимоги.
Минулого листопада, Google оголосив що розробники повинні будуть публікувати нові програми в Play Store, використовуючи формат Android App Bundle (AAB) замість APK. Буквально днями Google нагадав розробникам про цю майбутню вимогу, викликавши бурю суперечок від користувачів, які вважають, що Google вбиває APK, усуває стороннє завантаження, перешкоджає стороннім магазинам програм і що не так.
Це правда, що набори Android App Bundles значно відрізняються від класичного формату APK, до якого ви звикли як користувач, так і розробник. Хоча використання пакетів App Bundle має чимало переваг, є один ключовий аспект їх створення, який справедливо турбує деяких розробників і експертів з безпеки.
У цій статті ми розглянемо критику, яку ми бачили щодо переходу на Android App Bundle, а також деякі запропоновані рішення, а також поговоримо про запропоноване Google вирішення цих проблем.
Фон
Перш ніж це станеться, нам потрібно трохи поговорити про те, як загалом працює розповсюдження програм на Android. Якщо ви вже знаєте, як працюють підписи додатків і набори додатків, можете пропустити цю частину.
APK
Здебільшого програми на Android поширюються всередині APK-файлів. APK містить увесь код і ресурси програми, а також деякі функції безпеки, як-от маніфест підпису. Коли APK встановлено, він просто копіюється в певну папку та додається до внутрішньої бази даних встановлених програм.
Підписи
Під час інсталяції також перевіряється підпис цієї програми, щоб переконатися, що вона дійсна. Якщо програму вже встановлено, Android порівнює підпис нової програми з уже встановленою. Якщо підпис недійсний або не збігається, Android відмовиться встановлювати програму.
Ця перевірка підпису є важливою частиною безпеки в Android. Це гарантує, що програма, яку ви встановлюєте, є дійсною та принаймні з того самого джерела, що й та, яку ви вже встановили. Наприклад, якщо ви встановите, скажімо, мій додаток Lockscreen Widgets із магазину Play, ви можете бути достатньо впевнені, що це я підписав його, і що він справжній. Якщо ви потім спробуєте встановити оновлення Lockscreen Widgets з якогось підозрілого стороннього сайту, і це не вдасться, ви знатимете, що хтось втрутився в цей APK, можливо, щоб додати зловмисне програмне забезпечення.
Ключ, який використовується для підпису програми (в ідеалі) ніколи публічно опублікований. Це відоме як закритий ключ. Потім закритий ключ використовується для створення ключа, який відображається в підписі програми, відомого як відкритий ключ. Це те, що Android і магазини програм використовують для перевірки дійсності програми. Я не буду вдаватися в те, як саме можна згенерувати відкритий ключ, не розкриваючи закритий ключ, оскільки це включає багато математики шифрування. Якщо вам потрібна додаткова інформація, перевірте Документація Google щодо підписання файлів APK або проведіть дослідження щодо односторонніх математичних функцій.
Ще одна особливість підписів додатків — це можливість обмежувати дозволи лише для програм із відповідними підписами. Android робить це внутрішньо для багатьох функцій, де лише програми, підписані тим самим ключем, що й фреймворк, можуть отримати доступ до певних функцій.
Пакети програм
Тепер, коли ми зробили короткий огляд файлів APK і підписів, давайте поговоримо про набори додатків. Ось де ресурси APK. Ресурси – це такі речі, як макети, зображення, аудіо тощо. По суті, це все, що не є кодом. Щоб краще підтримувати різні конфігурації дисплея та різні мови, розробники можуть створювати кілька версій одного ресурсу, які використовуються залежно від пристрою та мови.
Але в APK усі ці ресурси існують, незалежно від того, які ви використовуєте. І вони займають місце. Залежно від складності вашої програми може бути багато невикористаних ресурсів для багатьох пристроїв. Саме для цього створені набори додатків. Розробники можуть створити набір додатків так само, як файл .apk, і потім цей набір можна завантажити в Play Store, як це можна зробити з файлами .apk.
Потім Google використовує цей набір додатків, щоб створити цілу купу різних файлів APK для різних конфігурацій пристроїв. Кожен App Bundle містить лише ресурси, необхідні для цієї конфігурації. Коли користувач завантажує цю програму, йому надається створений APK, який відповідає його конфігурації. Це допомагає зменшити розмір завантаження та встановлення додатків, заощаджуючи пропускну здатність і місце для зберігання.
Звичайно, інсталяція файлу APK для вашого пристрою означає, що вам важче просто скопіювати його на інший пристрій і встановити без проблем. Залежно від вашої точки зору, це може бути добре чи погано. З одного боку, це ускладнює піратство, оскільки користувачі більше не мають повної програми. З іншого боку, це ускладнює законне архівування програм з тієї ж причини.
Підпис додатків
Оскільки пакети Android App Bundle не є файлами .apk, ви не можете просто відкрити файл AAB і встановити його безпосередньо на пристрій. Коли ви завантажуєте його в Play Store, Google використовує пакет для створення різних (непідписаних) файлів APK. Ці файли APK потрібно підписати, перш ніж їх можна буде встановити.
Замість того, щоб просити розробника підписати та повторно завантажити ці створені файли .apk, Google самостійно керує підписанням. Play Store або використовує створений ним новий ключ, або просить у розробника ключ, який вони використовують для підпису APK. У будь-якому випадку Google обробляє публічний підпис для розробника та забезпечує завантаження ключ. Google використовує ключ завантаження для внутрішньої перевірки та перевіряє, чи правильний набір додатків (або в деяких випадках APK), який завантажує розробник.
Якщо ключ завантаження зламано або втрачено, розробники можуть запросити новий, а ключ підпису, який використовується для розповсюдження програми, залишається незмінним.
Підпис додатків містить багато іншого, але це те, що має відношення до цієї статті. Якщо ви хочете, ви можете прочитати більше про App Bundle і App Signing на ця стаття Medium автора Войтека Каліцінського.
Критика
У теорії та на практиці пакети додатків чудові. Вони зменшують використання даних і розмір інсталяції, при цьому користувачеві не потрібно нічого робити. Але через те, як це реалізовано, деякі розробники та дослідники безпеки за останні кілька місяців висловили занепокоєння. Перш ніж підсумувати ці занепокоєння, я хочу сказати, що більшість із того, що написано нижче, є прямим на основі серії статей розробником Марком Мерфі CommonsWare. Ви обов’язково повинні ознайомитися з його статтями, оскільки вони містять більше деталей і критики з точки зору розробника.
Безпека
У класичній моделі розповсюдження розробник зберігає конфіденційність ключа, який він використовує для підписання APK. Він ніколи не публікується, і лише авторизовані люди повинні мати до нього доступ. Це гарантує, що лише ці люди можуть створити дійсний APK.
Але якщо ви використовуєте App Bundle у Play Store, Google керує ключем, який підписує APK, які отримують користувачі. The за замовчуванням поведінку нових програм, завантажених у Google Play починаючи з серпня 2021 року Google має створити власний ключ розповсюдження, який він зберігає в секреті від розробника.
Розробники подають нові програми Google за умовчанням керуватиме їхнім особистим ключем, хоча розробники надсилають оновлення існуючі програми може продовжувати використовувати APK або вони можуть перейти до розповсюдження AAB, згенерувавши новий ключ, який Google використовуватиме для нових користувачів. Існуючі програми не потрібні щоб перейти з розповсюдження APK на пакети Android App Bundle, хоча ця опція доступна для них, якщо вони забажуть. Після деякої відмови Google навіть зробить це можливим щоб завантажити власний приватний ключ для входу в Google як для нових, так і для існуючих програм. Жодна з цих ситуацій не є ідеальною, оскільки, незважаючи ні на що, Google матиме доступ до вашого закритого ключа, якщо ви цього захочете використовуйте Android App Bundles (і розробники не мають вибору, якщо вони хочуть подати нову програму після серпня 2021!)
Хоча ми впевнені, що Google дуже серйозно ставиться до безпеки, на Землі немає жодної компанії, захищеної від витоку даних. Якщо ключ, який Google використовує для підпису вашого додатка для розповсюдження, є одним із цих порушень, тоді будь-хто може підписати версію вашого додатка та зробити так, ніби його підписали ви. І деякі розробники та експерти з безпеки не в захваті від такої можливості. Це дуже, дуже невелика можливість, так, але той факт, що така можливість взагалі є, лякає декого в спільноті інфосекцій.
Підписання розробниками файлів .apk Android означає, що будь-хто може перевірити файли .apk у Google Play, сліпа довіра не потрібна. Це елегантний дизайн, який забезпечує перевірену безпеку. App Bundle перевертають це з ніг на голову та, здається, структуровані для сприяння прив’язці до постачальника. Існує багато альтернативних технічних підходів, які надають невеликі файли APK, підписані розробниками, але вони не віддають перевагу Play. Наприклад, усі варіанти APK можуть бути згенеровані та підписані розробником, а потім завантажені в будь-який магазин програм.
Звичайно, є аргументи щодо того, чи краще залишити безпечне зберігання приватних ключів у руках Google або окремих розробників. Але ці розробники (імовірно) зазвичай не використовують центральне сховище для своїх ключів. Змушуючи розробників використовувати підпис додатків Play, зловмисникам достатньо лише один раз порушити безпеку Google, щоб отримати тисячі або мільйони ключів.
Ось що Google говорить про те, як він захищає ваш ключ підпису у своїй інфраструктурі:
[blockquote author="Wojtek Kaliciński, адвокат розробників Android у Google"]Коли ви використовуєте підпис додатків Play, ваші ключі зберігаються в тій самій інфраструктурі, яку Google використовує для зберігання власних ключів.
Доступ до ключів регулюється суворими списками керування доступом і контрольними журналами для всіх операцій.
Усі артефакти, створені та підписані ключем розробника, доступні для перевірки/атестації в Google Play Console.
Крім того, щоб запобігти втраті ключів, ми дуже часто робимо резервні копії нашого основного сховища. Ці резервні копії надійно зашифровані, і ми регулярно тестуємо відновлення з цих резервних копій.
Якщо ви хочете дізнатися про технічну інфраструктуру Google, прочитайте Технічні документи Google Cloud Security.[/blockquote]
Наскільки чудово, що всі звуки, втрата та крадіжка все ще можливі. А журнали аудиту лише допомагають запобігти майбутнім атакам; вони не отримають зламані ключі назад.
Можливість несанкціонованих змін
Однією з великих проблем із тим, як Google налаштував пакети додатків, є ймовірність додавання до програми несанкціонованих змін. Процес видобування файлів .apk із набору App Bundle за своєю суттю передбачає модифікації, оскільки Google має вручну створювати кожен файл .apk. Поки Google пообіцяв, що не впроваджуватиме та не змінюватиме код, проблема процесу App Bundle полягає в тому, що він має для цього повноваження.
Ось кілька прикладів того, що може робити компанія на позиції Google:
Скажімо, є безпечний додаток для обміну повідомленнями, який люди використовують для спілкування без ризику стеження з боку уряду. Це може бути надзвичайно корисним інструментом для людей, які протестують проти авторитарного уряду, або навіть для людей, які просто хочуть зберегти свою конфіденційність. Цей уряд, бажаючи бачити, що говорять користувачі програми, може спробувати змусити Google додати бекдор для спостереження в код програми.
Цей приклад трохи нешкідливіший, але він також викликає занепокоєння у деяких людей. Скажімо, є програма, яка отримує мільйони завантажень на день, але в ній немає жодної реклами чи аналітики. Це величезне джерело даних, до якого немає можливості отримати доступ. Google, як рекламна компанія, може захотіти отримати доступ до цих даних.
У класичній моделі розповсюдження додатків APK Google не може змінювати додатки без зміни підпису. Якщо Google змінить підпис, особливо в популярній програмі, люди це помітять, оскільки оновлення не встановлюється. Але за допомогою пакетів App Bundle і підпису додатків Google може мовчки вставляти власний код у програми перед їх розповсюдженням. Підпис не зміниться, оскільки Google буде володіти ключем підпису.
Щоб було зрозуміло, ці приклади неймовірно малоймовірні. Google прагне до простого взагалі вийти з проблемних ринків, а не адаптуватися. Але хоч це й малоймовірно, все ж можливо. Просто тому, що компанія обіцяє, що чогось не станеться, вона не гарантує цього.
Прозорість коду
Google, почувши ці занепокоєння, цього тижня представив нову функцію під назвою Прозорість коду для пакетів додатків. Прозорість коду дозволяє розробнику фактично створити другий підпис, який надсилається користувачам із програмою. Цей додатковий підпис має бути створено з окремого закритого ключа, доступ до якого має лише розробник. Однак у цього методу є деякі обмеження.
Прозорість коду стосується лише коду. Це може здатися очевидним, враховуючи назву, але це також означає, що користувачі не можуть перевіряти ресурси, маніфест або щось інше, що не є файлом DEX або рідною бібліотекою. Хоча зловмисні модифікації некодових файлів зазвичай мають набагато менший вплив, це все одно є дірою в безпеці програми.
Ще одна проблема з прозорістю коду полягає в тому, що немає внутрішньої перевірки. Для одного, це необов'язкова функція, тому розробники мають пам’ятати про те, щоб включити його до кожного нового APK, який вони завантажують. Наразі це потрібно робити з командного рядка та за допомогою версії bundletool які не постачаються з Android Studio. Навіть коли розробник включає його, Android не має жодної вбудованої перевірки, щоб перевірити, чи маніфест прозорості коду відповідає коду в програмі.
Кінцевий користувач може перевірити сам, порівнявши маніфест із відкритим ключем, який може надати розробник, або надіславши файл APK розробнику для перевірки.
Хоча прозорість коду дозволяє підтвердити, що жоден код у програмі не змінено, вона не включає будь-яку перевірку інших частин програми. У цьому процесі також немає внутрішньої довіри. Ви можете заперечити, що якщо ви не довіряєте Google, ви, ймовірно, впораєтеся з незалежним підтвердженням, але навіщо вам це робити?
Існують інші проблеми з функцією прозорості коду, наприклад вказано наголошено від Марка Мерфі CommonsWare. Я рекомендую прочитати його статтю для більш глибокого аналізу функції.
Зручність і вибір розробника
Третя (і остання для цієї статті) причина, через яку деякі розробники не погоджуються з наборами додатків, полягає в обмеженні зручності та вибору.
Якщо розробник створить нову програму в Play Store після того, як Google почне вимагати пакети додатків, і він вибере параметр за замовчуванням дозволити Google керувати ключем підпису, вони ніколи не матимуть доступу до цього підпису ключ. Якщо той самий розробник потім захоче розповсюдити цю програму в іншому магазині програм, йому доведеться використовувати власний ключ, який не збігатиметься з ключем Google.
Це означає, що користувачам доведеться встановлювати та оновлюватися з Google Play або зі сторонніх джерел. Якщо вони хочуть змінити джерело, вони повинні повністю видалити програму, потенційно втрачаючи дані, і перевстановити. Як агрегатори APK APKMirror тоді також доведеться мати справу з кількома офіційними підписами для однієї програми. (Технічно вони вже змушені це робити, оскільки підпис додатків дозволяє створити новий, більш безпечний ключ для нових користувачів, але це буде гірше для них та інших сайтів, коли всі має зробити це.)
Відповідь Google на цю проблему полягає в тому, щоб використовувати App Bundle Explorer або Artifact Explorer у Play Console, щоб завантажити отримані файли .apk із завантаженого набору. Подібно до прозорості коду, це не повне рішення. Файли .apk, завантажені з Play Console, будуть розділені для різних профілів пристроїв. Хоча Play Console підтримує завантаження кількох файлів .apk для однієї версії одного додатка, багато інших каналів розповсюдження цього не роблять.
Таким чином, багато переваг використання App Bundle зникають, коли розробники керують кількома магазинами, що ускладнює розповсюдження. З новинами, що Windows 11 є отримати підтримку програм Android Завдяки Amazon Appstore деякі вважають, що вимога до пакетів додатків перешкоджатиме розробникам розповсюджувати на Amazon. Звичайно, першочерговою турботою Google є власний магазин програм, але це саме те поставив їх у гарячу воду з конкурентами спонукаючи їх робити невеликі, примирливі зміни про те, як сторонні магазини програм працюють на Android.
Пара проблем, пов’язаних із кількома магазинами, – взаємозв’язок додатків і швидке тестування.
Почнемо з взаємодії додатків. Ви коли-небудь завантажували програму, яка блокує функції за платним доступом? Майже точно. Деякі розробники розміщують функції за покупку через програму, але інші можуть створити окрему платну програму. Коли цю додаткову програму буде встановлено, основні функції програми розблокуються.
Але що заважає комусь просто встановити доповнення з піратського джерела? Що ж, у розробників є багато варіантів, але принаймні один передбачає використання дозволів, захищених підписом. Скажімо, основна програма оголошує дозвіл, захищений підписом. Потім додаток-додаток заявляє, що хоче використовувати цей дозвіл. В ідеалі додаткова програма також матиме певну функцію перевірки ліцензії, яка підключається до Інтернету, щоб переконатися, що користувач легітимний.
Якщо обидві програми мають однаковий підпис, Android надасть дозвіл додатковій програмі, і перевірки захисту від піратства пройде. Якщо програма-додаток не має правильного підпису, дозвіл не буде надано, і перевірка не вдасться.
Завдяки класичній моделі розповсюдження APK користувач може отримати будь-яку програму з будь-якого законного джерела й покінчити з цим. У поточній моделі App Bundle за замовчуванням підписи основної та додаткової програм не збігаються. Google збирається створити унікальний ключ для кожної програми. Розробник завжди міг відмовитися від дозволу, захищеного підписом, і використовувати пряму хеш-перевірку підпису, але це набагато менш безпечно.
А ще є швидкісні випробування. Користувачі постійно надсилають електронні листи розробникам про проблеми в їхніх програмах. Іноді ці проблеми є простими виправленнями: відтворіть проблему, знайдіть проблему, виправте її та завантажте нову версію. Але іноді це не так. Іноді розробники не можуть відтворити проблему. Вони можуть виправити те, що, на їхню думку, є проблемою, але потім користувач повинен це перевірити. Тепер припустімо, що користувач встановив програму через Google Play.
За допомогою моделі APK розробник може змінити деякий код, створити та підписати новий APK і надіслати його користувачеві для тестування. Оскільки підпис тестового файлу .apk збігається з тим, який встановив користувач, це простий процес для оновлення, тестування та звітування. З App Bundle це розпадається. Оскільки Google підписує APK, який спочатку встановив користувач, він не збігатиметься з підписом APK, який надсилає розробник. Якщо цю програму буде опубліковано після кінцевого терміну App Bundle, розробник навіть не матиме доступу до ключів, які використовує Google. Щоб протестувати, користувачеві доведеться видалити поточну програму перед встановленням тестової версії.
Тут є купа проблем. По-перше, є незручності як з боку розробника, так і з боку користувача. Необхідність видаляти програму лише для того, щоб перевірити виправлення, не весела. А якщо проблема зникне? Це були зміни, внесені розробником, чи тому, що користувач фактично очистив дані програми? У магазині Play є внутрішнє тестування, яке має дозволити розробникам виконувати швидкі збірки та розповсюдження, але воно вимагає від користувача спочатку видалити випускну версію. Це насправді нічого не виправляє.
Якщо все це звучить як купа гіпотетичних нісенітниць, ось дуже реальний приклад розробника, який матиме ці проблеми, якщо він дозволить Google згенерувати для нього закритий ключ: Жоао Діас. Він є розробником Tasker разом із цілим набором плагінів, включаючи пакет AutoApps. З новою вимогою до наборів додатків цикл розробки Жоао може стати набагато складнішим, принаймні для нових програм. Відправляти тестові версії напряму буде менш зручно. Перевірка ліцензій буде менш ефективною.
Це може звучати як крайній випадок, але це не те, що Жоао якийсь дрібний розробник, і, ймовірно, він не один. У магазині Play є багато програм, які використовують перевірку підпису для виявлення нелегальних користувачів.
Звичайно, з новою можливістю для розробників завантажувати власні ключі підпису в Google, ці проблеми принаймні дещо полегшуються. Але розробники повинні ввімкнути опцію для кожної програми. Якщо вони цього не зроблять, міжз’єднання вийде з ладу, а підтримка швидкої стрілянини потребуватиме завантаження пакета в Google і очікування створення файлів APK, перш ніж надіслати правильний файл користувачеві. Крім того, це все ще означає, що вони повинні ділитися своїм закритим ключем, що повертає нас до проблем, які ми обговорювали раніше.
Рішення
Це стара проблема, враховуючи, що вимоги до App Bundle були оприлюднені кілька місяців тому, тому було запропоновано чимало рішень.
Одне з рішень — уникнути необхідності підпису додатків Play. Замість того, щоб генерувати App Bundle, який потім Google обробляє в APK і підписує, цю обробку може виконувати Android Studio. Потім розробники можуть просто завантажити ZIP-архів із локально підписаними файлами APK для кожної конфігурації, яку згенерував би Google.
З таким рішенням Google взагалі не потребував би доступу до ключів розробників. Процес буде дуже схожий на класичну модель розповсюдження APK, але включатиме кілька менших APK замість одного.
Інше рішення полягає в тому, щоб просто не вимагати використання пакетів додатків і продовжувати дозволяти розробникам завантажувати локально підписані APK. Хоча пакети App Bundle можуть бути кращою для користувача в багатьох випадках, деякі програми насправді не виграють від поділу на конфігурацію з мінімальним розміром скорочення.
Якщо Google реалізує обидва ці рішення, то розробнику, який хоче використовувати App Bundle, не доведеться підписувати в Google, і розробнику, чий додаток не матиме великої користі від формату, не доведеться використовувати його на все.
Відповіді Google
Самопідписання
Коли їх вперше запитали про дозвіл розробникам керувати підписом для App Bundle, відповідь Google була дуже стриманою:
[blockquote author=""]Отже, я коротко говорив про вимогу наступного року для нових додатків використовувати пакети додатків, і одна річ, яка приходить із цим, полягає в тому, що ми будемо вимагати підписування додатків Play. Тож розробникам потрібно буде або згенерувати ключ підпису додатків у Play, або завантажити власний ключ у Play… оскільки це обов’язкова умова для наборів програм. Ми чули від розробників, що деякі з них просто не хочуть цього робити. Вони не хочуть, щоб ключами керував Play. І наразі це неможливо, якщо ви хочете використовувати пакети програм.
Але ми почули цей відгук і... Я не можу зараз ні про що говорити, ми не маємо нічого оголосити, але ми шукаємо, як ми можемо пом’якшити деякі з цих проблем. Не обов’язково дозволяти зберігати власний ключ під час завантаження пакетів. Ми розглядаємо різні варіанти. У нас просто немає рішення, яке можна оголосити прямо зараз. Але у нас ще є близько року до вимоги, тому я дуже сподіваюся, що ми отримаємо відповідь для розробників на це питання.[/blockquote]
Це було наприкінці листопада минулого року, і, здається, нічого не сталося. Залишилося лише кілька місяців до Набуває чинності вимога до пакетів App Bundle, розробники все ще не можуть підписувати власні програми. Тоді як тепер Google зробив це можливим завантажити ваш власний ключ як для нових, так і для існуючих програм, це все ще знімає частину підпису з рук розробника.
Зміни коду
Хоча Google конкретно пообіцяв, що Play Store не змінюватиме код програми, обіцянка не є гарантією. У пакетах App Bundle і App Signing немає жодних технічних обмежень, які б заважали Google змінювати завантажені програми перед розповсюдженням.
Google представив Прозорість коду як додаткова функція, і хоча це дещо допомагає, вона має достатню частку проблем, як ми обговорювали раніше.
Саморобні пучки
Коли Google запитали про те, чи дозволити розробникам створювати власні «пакети» додатків (ZIP-файли, що містять розділені файли APK), відповідь була в основному «ми не збираємося цього робити»:
Ймовірно, не так, як описано в запитанні, оскільки це ще більше ускладнить процес публікації для розробників, і ми насправді хочемо зробити його простішим і безпечнішим. Однак знову ж таки ми почули цей відгук і шукатимемо варіанти, як зробити це можливим, однак, ймовірно, не так, як тут описано.
Цікаво, що виправдання Google полягає в тому, що це ускладнить публікацію. Однак Google може зробити процес автоматизованим у рамках діалогового вікна створення APK в Android Studio. Крім того, якщо програма, про яку йде мова, розповсюджується в кількох магазинах, вона справді стане процес публікації простіший, оскільки розробникам не доведеться керувати кількома ключами підпису та скаргами з користувачів.
І з появою прозорості коду здається, що ускладнення не зовсім проблема. Прозорість коду, принаймні наразі, вимагає від розробника використання інструменту командного рядка, а від користувачів — чіткої перевірки дійсності програми, яку вони обслуговують. Це складніше, ніж процес самостійного створення пакетів, і незрозуміло, чому Google віддає перевагу цьому рішенню.
Йти вперед
Починаючи з 1 серпня, пакети App Bundle стануть обов’язковим форматом розповсюдження для нових програм, які надсилаються в Google Play. Хоча Google принаймні певною мірою вирішив більшість питань, поставлених розробниками та експертами з безпеки, відповіді залишають бажати кращого. Є багато очевидних переваг пакетів додатків як формату розповсюдження нового покоління, але завжди залишатимуться проблеми з наданням Google часткового або повного контролю над підписом програм.
Відповіді та зусилля Google, безумовно, цінуються, але деякі, як-от Марк Мерфі, вважають, що вони зайшли недостатньо далеко. Оскільки такі рішення, як саморобні пакети, не впроваджуються, а крайній термін для Android App Bundle вимагається швидко наближається, не схоже, що розробники в Google Play зможуть довго контролювати свої програми довше.
Пізніше ввечері ми обговоримо наслідки вимог Android App Bundle у Twitter Space, тож приєднуйтеся до нас!