Google Play brzy donutí vývojáře nahrávat balíčky App Bundle místo APK, což vyvolává nepříjemné bezpečnostní otázky ohledně tohoto požadavku.
loni v listopadu, Google oznámil že vývojáři budou muset publikovat nové aplikace v Obchodě Play pomocí formátu Android App Bundle (AAB) namísto souboru APK. Právě druhý den Google připomněl vývojářům tento nadcházející požadavek a vyvolal tak bouři kontroverzí od uživatelů, kteří se domnívají, že Google zabíjí soubory APK, odstraňuje boční načítání, brzdí obchody s aplikacemi třetích stran a co ještě.
Je pravda, že balíčky Android App Bundle jsou docela velkým odklonem od klasického formátu APK, na který byste mohli být zvyklí jako uživatel i jako vývojář. I když používání balíčků aplikací přináší několik výhod, je zde jeden klíčový aspekt, který některé vývojáře a bezpečnostní experty oprávněně znepokojuje.
V tomto článku se budeme zabývat výtkami, které jsme viděli v souvislosti s přechodem na balíčky Android App Bundle, a také některými navrhovanými řešeními a budeme také hovořit o řešení těchto problémů, které navrhuje Google.
Pozadí
Než se tak stane, musíme si trochu promluvit o tom, jak funguje distribuce aplikací na Androidu obecně. Pokud již víte, jak funguje podepisování aplikací a balíčky aplikací, můžete tuto část přeskočit.
APK
Z velké části jsou aplikace pro Android distribuovány uvnitř souborů APK. Soubor APK obsahuje veškerý kód a prostředky aplikace spolu s některými funkcemi zabezpečení, jako je podpisový manifest. Když je soubor APK nainstalován, v podstatě se pouze zkopíruje do konkrétní složky a přidá se do interní databáze nainstalovaných aplikací.
Podpisy
Během instalace je také ověřen podpis této aplikace, aby se zajistilo, že je platný. Pokud je aplikace již nainstalována, Android porovná podpis nové aplikace s podpisem, který je již nainstalován. Pokud podpis není platný nebo se neshoduje, Android aplikaci odmítne nainstalovat.
Tato kontrola podpisů je důležitou součástí zabezpečení v Androidu. Zajišťuje, že aplikace, kterou instalujete, je platná a alespoň ze stejného zdroje jako ten, který jste již nainstalovali. Pokud například nainstalujete, řekněme moje aplikace Lockscreen Widgets z Obchodu Play, můžete si být přiměřeně jisti, že jsem to já, kdo to podepsal, a že je to autentické. Pokud se poté pokusíte nainstalovat aktualizaci widgetů Lockscreen z nějakého stinného webu třetí strany a selže, budete vědět, že někdo s daným souborem APK manipuloval, případně aby přidal malware.
Klíč používaný k podepsání aplikace je (v ideálním případě) nikdy veřejně propuštěn. Toto je známé jako soukromý klíč. Soukromý klíč se pak použije k vygenerování klíče zobrazeného v podpisu aplikace, známého jako veřejný klíč. To je to, co Android a obchody s aplikacemi používají k ověření platnosti aplikace. Nebudu se zabývat tím, jak přesně můžete vygenerovat veřejný klíč, aniž byste odhalili soukromý klíč, protože to vyžaduje spoustu šifrovací matematiky. Pokud chcete další podrobnosti, podívejte se Dokumentace společnosti Google o podepisování souborů APK nebo udělat nějaký výzkum o jednosměrných matematických funkcích.
Další funkcí podpisů aplikací je možnost omezit oprávnění pouze na aplikace s odpovídajícími podpisy. Android to dělá interně pro mnoho funkcí, kde k určitým funkcím mají přístup pouze aplikace podepsané stejným klíčem jako framework.
Balíčky aplikací
Nyní, když jsme uvedli rychlý přehled souborů APK a podpisů, pojďme si promluvit o balíčcích aplikací. Zde přicházejí na řadu zdroje APK. Zdroje jsou věci jako rozvržení, obrázky, zvuk atd. V podstatě jsou to cokoli, co není kód. Pro lepší podporu různých konfigurací zobrazení a různých jazyků mohou vývojáři vytvořit více verzí stejného prostředku, které se používají v závislosti na zařízení a jazyce.
Ale v souboru APK všechny tyto prostředky existují, bez ohledu na to, který používáte. A zabírají místo. V závislosti na složitosti vaší aplikace může být pro mnoho zařízení mnoho nevyužitých zdrojů. To je to, co mají balíčky aplikací vyřešit. Vývojáři mohou vygenerovat App Bundle stejně jako APK a tento App Bundle pak lze nahrát do Obchodu Play, stejně jako APK.
Google pak tento App Bundle použije k vygenerování celé řady různých souborů APK pro různé konfigurace zařízení. Každý App Bundle obsahuje pouze zdroje potřebné pro danou konfiguraci. Když si uživatel danou aplikaci stáhne, zobrazí se mu vygenerovaný soubor APK, který odpovídá jeho konfiguraci. To pomáhá zmenšit velikost stahování a instalace aplikací, což šetří šířku pásma a úložný prostor.
Instalace souboru APK specifického pro vaše zařízení samozřejmě znamená, že je pro vás obtížnější jej pouze zkopírovat do jiného zařízení a nainstalovat jej bez problémů. V závislosti na vašem úhlu pohledu to může být dobrá nebo špatná věc. Na jednu stranu to ztěžuje pirátství, protože uživatelé už nemají celou aplikaci. Na druhou stranu to ze stejného důvodu ztěžuje legitimní archivaci aplikací.
Podepisování aplikací
Protože balíčky Android App Bundle nejsou soubory APK, nemůžete jen otevřít soubor AAB a nainstalovat jej přímo do zařízení. Když jeden nahrajete do Obchodu Play, Google použije balíček ke generování různých (nepodepsaných) souborů APK. Tyto soubory APK je třeba před instalací podepsat.
Místo toho, aby Google požádal vývojáře, aby podepsal a znovu nahrál vygenerované soubory APK, spravuje podepisování sám. Obchod Play buď použije nový klíč, který vytvoří, nebo požádá vývojáře o klíč, který používají k podpisu APK. U obou možností Google za vývojáře zpracovává veřejné podepisování a poskytuje nahrávání klíč. Google používá klíč pro nahrávání k internímu ověření a zajišťuje, aby byl balíček App Bundle (nebo v některých případech APK), který vývojář nahrává, správný.
Pokud dojde ke kompromitaci nebo ztrátě klíče pro nahrávání, vývojáři mohou požádat o nový a podpisový klíč použitý k distribuci aplikace zůstane nezměněn.
Podepisování aplikací je mnohem více, ale toto je to, co je pro tento článek důležité. Pokud chcete, můžete si přečíst více o balíčcích aplikací a přihlašování aplikací na tento střední článek od Wojtka Kalicińského.
Kritika
Teoreticky i v praxi jsou balíčky aplikací docela skvělé. Snižují využití dat a velikost instalace, a to vše, aniž by uživatel musel cokoliv dělat. Ale kvůli tomu, jak je implementován, někteří vývojáři a bezpečnostní výzkumníci v posledních několika měsících vyjádřili obavy. Než shrnu tyto obavy, chtěl bych si na chvíli říci, že většina toho, co je napsáno níže, je přímo na základě série článků od vývojáře Marka Murphyho CommonsWare. Měli byste se rozhodně podívat na jeho články, protože poskytují více podrobností a kritiky z pohledu vývojáře.
Bezpečnostní
V klasickém distribučním modelu si vývojář ponechá klíč, který používá k podepsání souboru APK, jako soukromý. Nikdy se nesdílí veřejně a přístup k němu mají mít pouze oprávněné osoby. To zajišťuje, že pouze tito lidé mohou vygenerovat platný soubor APK.
Pokud ale používáte balíčky App Bundle v Obchodě Play, Google je ten, kdo spravuje klíč, který podepisuje soubory APK, které uživatelé obdrží. The výchozí chování pro nové aplikace nahrané na Google Play počínaje srpnem 2021 je pro Google, aby vytvořil svůj vlastní distribuční klíč, který uchovává v soukromí před vývojářem.
Vývojáři předkládají nové aplikace Google za ně ve výchozím nastavení bude spravovat jejich soukromý klíč, ačkoli vývojáři zasílají aktualizace existující aplikace může nadále používat soubory APK nebo mohou přejít na distribuci AAB vygenerováním nového klíče, který Google použije pro nové uživatele. Stávající aplikace nejsou vyžadovány přepnout z distribuce APK na balíčky Android App Bundle, ačkoli tato možnost je pro ně dostupná, pokud se rozhodnou. Po nějakém odmítnutí Google dokonce to umožní k nahrání vlastního soukromého klíče, pomocí kterého se bude Google podepisovat, pro nové i stávající aplikace. Žádná z těchto situací není ideální, protože bez ohledu na to bude mít Google přístup k vašemu soukromému klíči, pokud budete chtít používat balíčky Android App Bundle (a vývojáři v této věci nemají na výběr, pokud chtějí po srpnu odeslat novou aplikaci 2021!)
I když jsme si jisti, že Google bere zabezpečení velmi vážně, na Zemi neexistuje žádná společnost, která by byla imunní vůči narušení dat. Pokud je klíč, který Google používá k podepisování vaší aplikace k distribuci, v jednom z těchto porušení, pak kdokoli může podepsat verzi vaší aplikace, aby vypadala, jako byste ji podepsali vy. A někteří vývojáři a bezpečnostní experti z této možnosti nejsou nadšení. Je to velmi, velmi malá možnost, ano, ale skutečnost, že je to vůbec možnost, některé v komunitě infosec děsí.
To, že vývojáři podepisují soubory APK pro Android, znamená, že kdokoli může ověřovat soubory APK z Google Play, slepá důvěra není vyžadována. Jde o elegantní design, který poskytuje ověřitelnou bezpečnost. Balíčky aplikací to staví na hlavu a zdá se, že jsou strukturované tak, aby podporovaly uzamčení dodavatele. Existuje mnoho alternativních technických přístupů, které by poskytovaly malé soubory APK stále podepsané vývojáři, ale ty by neupřednostňovaly Play. Všechny varianty APK mohou být například vygenerovány a podepsány vývojářem a poté nahrány do libovolného obchodu s aplikacemi.
Určitě se najdou argumenty o tom, zda je lepší ponechat bezpečné uložení soukromých klíčů v rukou Googlu nebo jednotlivých vývojářů. Ale tito vývojáři (pravděpodobně) obvykle nepoužívají centrální úložiště pro své klíče. Tím, že nutíte vývojáře používat podepisování aplikací Play, stačí útočníkovi se zlými úmysly prolomit zabezpečení Google jen jednou, aby získal tisíce nebo miliony klíčů.
Co to stojí za to, zde je to, co Google říká o tom, jak chrání váš podpisový klíč ve své infrastruktuře:
[blockquote author="Wojtek Kaliciński, Android Developer Advocate ve společnosti Google"]Když používáte podepisování aplikací Play, jsou vaše klíče uloženy ve stejné infrastruktuře, kterou Google používá k ukládání vlastních klíčů.
Přístup ke klíčům je řízen přísnými seznamy ACL a kontrolními záznamy pro všechny operace, které jsou evidentní.
Všechny artefakty vygenerované a podepsané klíčem vývojáře jsou vám zpřístupněny v Google Play Console za účelem kontroly/atestace.
Kromě toho, abychom zabránili ztrátě klíčů, velmi často zálohujeme naše primární úložiště. Tyto zálohy jsou silně šifrované a pravidelně testujeme obnovení z těchto záloh.
Pokud se chcete dozvědět o technické infrastruktuře Google, přečtěte si Dokumenty o zabezpečení cloudu Google.[/blockquote]
Tak skvělé, že všechny zvuky, ztráta a krádež jsou stále možné. A auditní záznamy pouze pomáhají předcházet budoucím útokům; nedostanou prolomené klíče zpět.
Potenciál pro neoprávněné úpravy
Velkým problémem ve způsobu, jakým Google nastavil balíčky aplikací, je možnost přidání neoprávněných úprav do aplikace. Proces extrahování souborů APK z balíčku App Bundle přirozeně zahrnuje úpravy, protože Google musí každý soubor APK sestavit ručně. Zatímco Google slíbil, že nebude a nebude vkládat ani upravovat kód, problém s procesem App Bundle je v tom, že k tomu má moc.
Zde je několik příkladů toho, co má společnost na pozici Google moc dělat:
Řekněme, že existuje aplikace pro bezpečné zasílání zpráv, kterou lidé používají ke komunikaci bez rizika vládního dohledu. To by mohl být neuvěřitelně užitečný nástroj pro lidi, kteří protestují proti autoritářské vládě, nebo dokonce pro lidi, kteří si jen chtějí zachovat své soukromí. Tato vláda, která chce mít možnost vidět, co uživatelé aplikace říkají, by se mohla pokusit přimět Google, aby do kódu aplikace přidal zadní vrátka pro dohled.
Tento příklad je o něco neškodnější, ale také to některé lidi znepokojuje. Řekněme, že existuje aplikace, která má miliony stažení denně, ale neobsahuje žádné reklamy ani analýzy. To je obrovský zdroj dat bez možnosti přístupu k těmto datům. Google jako reklamní společnost může chtít získat přístup k těmto údajům.
V klasickém modelu distribuce aplikací APK nemůže Google upravovat aplikace bez změny podpisu. Pokud Google změní podpis, zejména v populární aplikaci, lidé si toho všimnou, protože se aktualizace nenainstaluje. Ale s App Bundles a App Signing by Google mohl tiše vložit svůj vlastní kód do aplikací před jejich distribucí. Podpis by se nezměnil, protože podpisový klíč by vlastnil Google.
aby bylo jasno, tyto příklady jsou neuvěřitelně nepravděpodobné. Google má tendenci jednoduše úplně vytáhnout z problémových trhů, spíše než se přizpůsobit. Ale i když je to nepravděpodobné, stále je to možné. Jen proto, že společnost slíbí, že se něco nestane, nezaručí to.
Transparentnost kódu
Google, když vyslechl tyto obavy, tento týden představil novou funkci s názvem Transparentnost kódu pro balíčky aplikací. Transparentnost kódu umožňuje vývojáři v podstatě vytvořit druhý podpis, který je uživatelům dodáván s aplikací. Tento zvláštní podpis by měl být vytvořen ze samostatného soukromého klíče, ke kterému má přístup pouze vývojář. Tato metoda má však určitá omezení.
Transparentnost kódu se vztahuje pouze na kód. To se může zdát zřejmé vzhledem k názvu, ale také to znamená, že to uživatelům neumožňuje ověřit zdroje, manifest nebo cokoli jiného, co není soubor DEX nebo nativní knihovna. I když škodlivé úpravy souborů bez kódu mají obvykle mnohem menší dopad, stále jde o díru v zabezpečení aplikace.
Dalším problémem s Transparentností kódu je, že neexistuje žádné vlastní ověření. Pro jednoho, je to volitelná funkce, takže vývojáři musí pamatovat na to, aby jej zahrnuli do každého nového souboru APK, který nahrají. V tuto chvíli to musí být provedeno z příkazového řádku a pomocí verze bundletool který není součástí Android Studia. I když to vývojář zahrne, Android nemá zabudované žádné ověření, které by zkontrolovalo, zda se manifest Transparency kódu shoduje s kódem v aplikaci.
Je na koncovém uživateli, aby se sám zkontroloval porovnáním manifestu s veřejným klíčem, který může vývojář poskytnout, nebo odesláním souboru APK vývojáři k ověření.
Transparentnost kódu sice umožňuje potvrdit, že žádný kód v aplikaci nebyl změněn, nezahrnuje však žádný druh ověření pro ostatní části aplikace. V procesu také neexistuje žádná vlastní důvěra. Můžete namítnout, že pokud nedůvěřujete Googlu, pravděpodobně budete schopni ověřovat nezávisle, ale proč byste měli?
Existují další problémy s funkcí Transparentnost kódu, as vypíchnut od Marka Murphyho z CommonsWare. Doporučuji přečíst si jeho článek pro podrobnější analýzu funkce.
Pohodlí a výběr pro vývojáře
Třetím (a posledním pro tento článek) důvodem, proč někteří vývojáři mají problémy s balíčky aplikací, je snížené pohodlí a výběr.
Pokud vývojář vytvoří novou aplikaci v Obchodě Play poté, co Google začne vyžadovat balíčky aplikací, a rozhodne se výchozí možnost nechat Google spravovat podpisový klíč, nebudou mít nikdy přístup k tomuto podepisování klíč. Pokud chce stejný vývojář distribuovat aplikaci v jiném obchodě s aplikacemi, bude muset použít svůj vlastní klíč, který se nebude shodovat s klíčem Google.
To znamená, že uživatelé budou muset nainstalovat a aktualizovat z Google Play nebo ze zdrojů třetích stran. Pokud chtějí změnit zdroj, musí aplikaci zcela odinstalovat, případně ztratit data, a znovu nainstalovat. APK agregátory mají rádi APKMirror pak se také bude muset vypořádat s několika oficiálními podpisy pro stejnou aplikaci. (Technicky to již musí udělat, protože App Signing vám umožní vytvořit nový, bezpečnější klíč pro nové uživatele, ale pro ně a další weby to bude horší, když všichni má udělat to.)
Reakcí společnosti Google na tento problém je použití Průzkumníka App Bundle nebo Průzkumníka Artifact v Play Console ke stažení výsledných souborů APK z nahraného balíčku. Podobně jako u Code Transparency se nejedná o úplné řešení. Soubory APK stažené ze služby Play Console budou rozděleny pro různé profily zařízení. Zatímco Play Console podporuje nahrávání více souborů APK pro jednu verzi jedné aplikace, mnoho dalších distribučních kanálů nikoli.
Mnoho výhod používání balíčků aplikací tedy zmizí, když vývojáři spravují více obchodů, což ztěžuje distribuci. S těmi novinkami Windows 11 je získání podpory aplikací pro Android díky Amazon Appstore někteří věří, že požadavek na App Bundles odradí vývojáře od distribuce na Amazonu. Primárním zájmem Googlu je samozřejmě vlastní obchod s aplikacemi, ale to je přesně ono vysadil je v horké vodě s konkurenty vést je k tomu, aby vytvořili drobné, smířlivé změny jak fungují obchody s aplikacemi třetích stran na Androidu.
Několik problémů souvisejících s více obchody je propojitelnost aplikací a rychlé testování.
Začněme propojením aplikací. Stáhli jste si někdy aplikaci, která zamyká funkce za paywall? Téměř určitě. Někteří vývojáři zahrnuli funkce do nákupu v aplikaci, ale jiní se mohou rozhodnout vytvořit samostatnou placenou aplikaci. Když se tato doplňková aplikace nainstaluje, odemknou se funkce hlavní aplikace.
Co ale někomu brání v instalaci doplňku z pirátského zdroje? Existuje mnoho možností pro vývojáře, ale alespoň jedna zahrnuje použití oprávnění chráněných podpisem. Řekněme, že hlavní aplikace deklaruje oprávnění chráněné podpisem. Doplňková aplikace pak prohlásí, že chce toto oprávnění použít. V ideálním případě bude mít doplňková aplikace také nějakou funkci ověření licence, která se připojí k internetu, aby se ujistil, že je uživatel legitimní.
Pokud mají obě aplikace stejný podpis, Android udělí oprávnění doplňkové aplikaci a kontroly ochrany proti pirátství projdou. Pokud doplňková aplikace nemá správný podpis, oprávnění nebude uděleno a ověření se nezdaří.
S klasickým distribučním modelem APK může uživatel získat kteroukoli aplikaci z jakéhokoli legitimního zdroje a být s ní hotový. Se současným výchozím modelem App Bundle se podpisy v hlavní a doplňkové aplikaci nebudou shodovat. Google pro každou aplikaci vytvoří jedinečný klíč. Vývojář mohl vždy skoncovat s oprávněním chráněným podpisem a použít přímé ověření hash podpisu, ale to je mnohem méně bezpečné.
A pak je tu rychlopalné testování. Uživatelé neustále e-mailují vývojářům o problémech v jejich aplikacích. Někdy jsou tyto problémy jednoduché opravy: reprodukujte problém, najděte problém, opravte jej a nahrajte novou verzi. Ale někdy nejsou. Někdy vývojáři nemohou problém reprodukovat. Mohou opravit to, co si myslí, že je problém, ale pak to musí otestovat uživatel. Nyní předpokládejme, že uživatel nainstaloval aplikaci prostřednictvím Google Play.
S modelem APK může vývojář změnit nějaký kód, sestavit a podepsat nový APK a odeslat jej uživateli k testování. Vzhledem k tomu, že podpis testovacího souboru APK odpovídá podpisu, který si uživatel nainstaloval, je aktualizace, testování a zpětné hlášení jednoduchý proces. U balíčků aplikací se to rozpadá. Protože Google podepisuje soubor APK, který uživatel původně nainstaloval, nebude se shodovat s podpisem souboru APK, který vývojář odešle. Pokud bude tato aplikace publikována po uzávěrce App Bundle, vývojář nebude mít přístup ani ke klíči, který Google používá. Aby uživatel mohl testovat, musel by před instalací testovací verze odinstalovat aktuální aplikaci.
Je tady spousta problémů. Za prvé, je tu nepříjemnost, a to jak na straně vývojáře, tak na straně uživatele. Nutnost odinstalovat aplikaci jen kvůli testování opravy není legrace. A co když problém zmizí? Byly to změny, které provedl vývojář, nebo to bylo tím, že uživatel efektivně vymazal data aplikace? Obchod Play má interní testování, které má vývojářům umožnit rychlé sestavení a distribuci, ale vyžaduje, aby uživatel nejprve odinstaloval verzi. Opravdu to nic neřeší.
V případě, že to celé zní jako snůška hypotetických nesmyslů, zde je velmi reálný příklad vývojáře, který bude mít tyto problémy, pokud nechá Google vygenerovat pro něj soukromý klíč: João Dias. Je vývojářem Taskeru spolu s celou řadou zásuvných aplikací, včetně sady AutoApps. S novým požadavkem na App Bundles může být vývojový cyklus João mnohem složitější, alespoň pro nové aplikace. Přímé odesílání testovacích verzí bude méně pohodlné. Ověřování licencí bude méně efektivní.
Může to znít jako trochu okrajový případ, ale není to tak, že by João byl nějaký malý vývojář a je pravděpodobné, že není sám. V Obchodě Play je mnoho aplikací, které při odhalování nelegitimních uživatelů spoléhají na ověření podpisu.
S novou možností pro vývojáře nahrávat do Googlu vlastní podpisové klíče se tyto problémy samozřejmě alespoň trochu zmírňují. Vývojáři se však musí přihlásit, aby tuto možnost povolili pro každou aplikaci. Pokud se tak nestane, propojení selžou a podpora rychlého odpalu bude vyžadovat nahrání balíčku do Googlu a čekání na vygenerování souborů APK, než uživateli odešlete ten správný. Navíc to stále znamená, že musí sdílet svůj soukromý klíč, což nás přivádí zpět k obavám, o kterých jsme hovořili dříve.
Řešení
Vzhledem k tomu, že požadavky na App Bundle byly zveřejněny před měsíci, jde o starý problém, takže mezitím bylo navrženo několik řešení.
Jedním z řešení je vyhnout se nutnosti podepisování aplikací Play. Namísto generování App Bundle, který Google následně zpracuje do souborů APK a podepíše, by toto zpracování mohlo provést Android Studio. Poté mohou vývojáři jednoduše nahrát ZIP plný místně podepsaných souborů APK pro každou konfiguraci, kterou by Google vygeneroval.
S tímto řešením by Google vůbec nepotřeboval přístup ke klíčům vývojářů. Tento proces by byl velmi podobný klasickému distribučnímu modelu APK, ale zahrnoval by více menších souborů APK namísto pouze jednoho.
Dalším řešením je prostě nevyžadovat používání balíčků aplikací a nadále umožnit vývojářům nahrávat lokálně podepsané soubory APK. Zatímco balíčky aplikací mohou být pro uživatele v mnoha případech lepší, některé aplikace ve skutečnosti nemají prospěch z rozdělení podle konfigurace s minimální velikostí redukce.
Pokud Google implementoval obě tato řešení, pak vývojář, který chce používat balíčky App Bundle, nebude muset po ruce přes podepisování do Googlu a vývojář, jehož aplikace nebude mít z formátu příliš užitek, jej nebude muset používat Všechno.
Odpovědi Google
Samopodepisování
Když byli poprvé požádáni, aby vývojářům umožnili podepisovat balíčky App Bundle, odpověď Google byla velmi nezávazná:
[blockquote author=""]Takže jsem krátce hovořil o požadavku, aby nové aplikace v příštím roce používaly balíčky aplikací, a jedna věc, která s tím přichází, je, že budeme vyžadovat podepisování aplikací Play. Vývojáři si tedy budou muset buď vygenerovat podpisový klíč aplikace na Play, nebo nahrát svůj vlastní klíč do Play… protože to je nezbytný předpoklad pro balíčky aplikací. Slyšeli jsme od vývojářů, že někteří z nich to prostě nechtějí dělat. Nechtějí mít klíče spravované službou Play. A v současné době to není možné, pokud chcete používat balíčky aplikací.
Ale slyšeli jsme tu zpětnou vazbu a... teď nemůžu o ničem mluvit, nemáme co oznámit, ale hledáme, jak bychom mohli některé z těchto obav zmírnit. Nemusí to nutně umožňovat ponechat si vlastní klíč při nahrávání balíčků. Hledáme různé možnosti. Právě teď nemáme řešení, které bychom mohli oznámit. Do požadavku však zbývá ještě asi rok, takže opravdu doufám, že na to budeme mít pro vývojáře odpověď.[/blockquote]
To bylo koncem listopadu loňského roku a zdá se, že se nic nestalo. Do konce zbývalo jen několik měsíců Požadavek na balíčky aplikací vstoupí v platnost, stále neexistuje způsob, jak by vývojáři zvládli podepisování vlastních aplikací. Zatímco Google to nyní umožnil nahrát váš vlastní klíč pro nové i stávající aplikace, to stále bere vývojáři z rukou část podepisování.
Změny kódu
Zatímco Google konkrétně slíbil, že Obchod Play nebude upravovat kód aplikace, slib není zárukou. V případě balíčků aplikací a podepisování aplikací neexistuje žádné technické omezení, které by společnosti Google bránilo v úpravách nahraných aplikací před distribucí.
Google představil Transparentnost kódu jako volitelná funkce, a i když to trochu pomáhá, má to svůj podíl na problémech, jak jsme diskutovali dříve.
Samostatně vyrobené balíčky
Když byl Google požádán, aby vývojářům umožnil vytvářet vlastní „balíčky“ aplikací (ZIP obsahující rozdělené soubory APK), odpověď byla v podstatě „to neuděláme“:
Pravděpodobně ne tak, jak je popsáno v otázce, protože by to vývojářům ještě více ztížilo proces publikování a my ho ve skutečnosti chceme zjednodušit a zabezpečit. Opět jsme však slyšeli tuto zpětnou vazbu a budeme hledat možnosti, jak to umožnit, pravděpodobně však ne způsobem, který zde byl popsán.
Zajímavé je, že zdůvodnění společnosti Google se zdá být takové, že by to zkomplikovalo publikování. Google by však stále mohl tento proces zautomatizovat jako součást dialogu generování APK v Android Studiu. Kromě toho, pokud je daná aplikace distribuována ve více obchodech, ve skutečnosti by to bylo proces publikování jednodušší, protože vývojáři by nemuseli spravovat více podpisových klíčů a stížnosti uživatelů.
A se zavedením Transparency kódu se zdá, že komplikace nakonec nejsou zrovna problém. Transparentnost kódu, alespoň prozatím, vyžaduje, aby vývojář používal nástroj příkazového řádku a aby uživatelé výslovně ověřili platnost aplikace, kterou jim poskytují. Je to složitější než proces vlastní výroby balíčků a není jasné, proč je to řešení, které Google preferuje.
Jít vpřed
Balíčky aplikací budou požadovaným distribučním formátem pro nové aplikace odeslané na Google Play od 1. srpna. I když Google alespoň trochu vyřešil většinu problémů vznesených vývojáři a bezpečnostními experty, odpovědi zanechávají mnoho přání. Balíčky aplikací jako distribuční formát nové generace mají mnoho zjevných výhod, ale vždy budou existovat přetrvávající obavy z poskytnutí částečné nebo úplné kontroly nad podepisováním aplikací společnosti Google.
Odpovědi a úsilí společnosti Google jsou jistě oceňovány, ale někteří, jako Mark Murphy, mají pocit, že nezašli dostatečně daleko. S řešeními, jako jsou vlastní balíčky, které nejsou implementovány, a konečný termín pro balíčky Android App Bundle je vyžadován rychle Vzhledem k tomu, že se blíží, nezdá se, že by si vývojáři na Google Play mohli po dlouhou dobu ponechat plnou kontrolu nad svými aplikacemi delší.
O důsledcích požadavku na Android App Bundle budeme hovořit na Twitteru později odpoledne, tak se k nám připojte!