Google Play bo kmalu prisilil razvijalce, da naložijo App Bundle namesto APK-jev, kar bo sprožilo neprijetna varnostna vprašanja o zahtevi.
Lani novembra, Google je objavil da bodo morali razvijalci objaviti nove aplikacije v Trgovini Play z uporabo formata Android App Bundle (AAB) namesto APK-ja. Ravno pred dnevi je Google spomnil razvijalce na to prihajajočo zahtevo in sprožil vihar polemike od uporabnikov, ki verjamejo, da Google ubija APK-je, odpravlja stransko nalaganje, ovira trgovine z aplikacijami tretjih oseb in kaj ne.
Res je, da so paketi Android App Bundles precej velik odmik od klasičnega formata APK, ki ste ga morda vajeni, tako kot uporabnik kot razvijalec. Čeprav ima uporaba paketov App Bundle kar nekaj prednosti, obstaja en ključni vidik njihove izdelave, ki nekatere razvijalce in varnostne strokovnjake upravičeno skrbi.
V tem članku bomo obravnavali kritike, ki smo jih opazili glede prehoda na pakete Android App Bundles, ter nekatere predlagane rešitve, govorili pa bomo tudi o Googlovi predlagani rešitvi za te težave.
Ozadje
Preden pa se to zgodi, se moramo malo pogovoriti o tem, kako na splošno deluje distribucija aplikacij v sistemu Android. Če že veste, kako delujejo podpisovanje aplikacij in paketi aplikacij, lahko ta del preskočite.
APK-ji
Večinoma se aplikacije v sistemu Android distribuirajo znotraj datotek APK. APK vsebuje vso kodo in vire aplikacije, skupaj z nekaterimi varnostnimi funkcijami, kot je manifest za podpisovanje. Ko je APK nameščen, se v bistvu samo kopira v določeno mapo in doda v notranjo zbirko podatkov nameščenih aplikacij.
Podpisi
Med namestitvijo se preveri tudi podpis te aplikacije, da se zagotovi, da je veljaven. Če je aplikacija že nameščena, Android preveri podpis nove aplikacije glede na že nameščeno. Če podpis ni veljaven ali se ne ujema, bo Android zavrnil namestitev aplikacije.
To preverjanje podpisa je pomemben del varnosti v sistemu Android. Zagotavlja, da je aplikacija, ki jo nameščate, veljavna in vsaj iz istega vira kot tista, ki ste jo že namestili. Na primer, če namestite npr. mojo aplikacijo Lockscreen Widgets iz Trgovine Play, ste lahko razumno prepričani, da sem ga jaz podpisal in da je pristen. Če nato poskušate namestiti posodobitev za pripomočke Lockscreen Widgets s sumljivega spletnega mesta tretje osebe in ne uspe, boste vedeli, da je nekdo posegel v ta APK, morda zato, da bi dodal zlonamerno programsko opremo.
Ključ, ki se uporablja za podpisovanje aplikacije, je (idealno) nikoli javno objavljeno. To je znano kot zasebni ključ. Zasebni ključ se nato uporabi za ustvarjanje ključa, prikazanega v podpisu aplikacije, znanega kot javni ključ. To je tisto, kar Android in trgovine z aplikacijami uporabljajo za preverjanje veljavnosti aplikacije. Ne bom se spuščal v to, kako natančno lahko ustvarite javni ključ, ne da bi razkrili zasebni ključ, saj vključuje veliko matematike šifriranja. Če želite več podrobnosti, preverite Googlova dokumentacija o podpisovanju APK-jev ali opravite nekaj raziskav o enosmernih matematičnih funkcijah.
Druga značilnost podpisov aplikacij je možnost omejitve dovoljenj samo na aplikacije z ujemajočimi se podpisi. Android to počne interno za veliko funkcij, kjer lahko samo aplikacije, podpisane z istim ključem kot ogrodje, dostopajo do določenih funkcij.
App Bundle
Zdaj, ko smo podali kratek pregled APK-jev in podpisov, se pogovorimo o paketih App Bundle. Tukaj pridejo na vrsto viri APK. Viri so stvari, kot so postavitve, slike, zvok itd. V bistvu so vse, kar ni koda. Za boljšo podporo različnih konfiguracij zaslona in različnih jezikov lahko razvijalci naredijo več različic istega vira, ki se uporabljajo glede na napravo in jezik.
Toda v APK-ju obstajajo vsi ti viri, ne glede na to, katerega uporabljate. In zavzamejo prostor. Odvisno od kompleksnosti vaše aplikacije je lahko veliko neuporabljenih virov za veliko naprav. To je tisto, za kar so namenjeni App Bundle. Razvijalci lahko ustvarijo App Bundle tako kot APK in ta App Bundle je nato mogoče naložiti v Trgovino Play, tako kot APK.
Google nato uporabi ta App Bundle za ustvarjanje celega kupa različnih APK-jev za različne konfiguracije naprav. Vsak App Bundle vsebuje samo vire, potrebne za to konfiguracijo. Ko uporabnik prenese to aplikacijo, mu je postrežen ustvarjen APK, ki ustreza njegovi konfiguraciji. To pomaga zmanjšati velikost prenosa in namestitve aplikacije ter prihrani pasovno širino in prostor za shranjevanje.
Seveda namestitev posebnega APK-ja za vašo napravo pomeni, da ga je težje preprosto kopirati v drugo napravo in brez težav namestiti. Glede na vašo perspektivo je to lahko dobra ali slaba stvar. Po eni strani otežuje piratstvo, saj uporabniki nimajo več celotne aplikacije. Po drugi strani pa iz istega razloga otežuje legitimno arhiviranje aplikacij.
Podpisovanje aplikacij
Ker paketi Android App Bundle niso APK-ji, ne morete preprosto odpreti datoteke AAB in jo namestiti neposredno v napravo. Ko ga naložite v Trgovino Play, Google s svežnjem ustvari različne (nepodpisane) datoteke APK. Te APK-je je treba podpisati, preden jih je mogoče namestiti.
Namesto da bi od razvijalca zahteval, da podpiše in znova naloži te ustvarjene APK-je, Google sam upravlja podpisovanje. Trgovina Play uporabi nov ključ, ki ga ustvari, ali vpraša razvijalca za ključ, ki ga uporablja za podpis APK-ji. Pri kateri koli možnosti Google obravnava javno podpisovanje za razvijalca in zagotovi nalaganje ključ. Google uporablja ključ za nalaganje za interno preverjanje in poskrbi, da je App Bundle (ali APK v nekaterih primerih), ki ga nalaga razvijalec, pravi.
Če je ključ za nalaganje ogrožen ali izgubljen, lahko razvijalci zahtevajo novega, ključ za podpisovanje, uporabljen za distribucijo aplikacije, pa ostane nespremenjen.
Podpisovanje aplikacij je veliko več, vendar je to tisto, kar je pomembno za ta članek. Če želite, lahko preberete več o paketih aplikacij in podpisovanju aplikacij na ta članek Medium Wojtek Kaliciński.
Kritika
V teoriji in praksi so App Bundle precej odlični. Zmanjšajo porabo podatkov in velikost namestitve, pri čemer uporabniku ni treba storiti ničesar. Toda zaradi tega, kako se izvaja, so nekateri razvijalci in raziskovalci varnosti v zadnjih nekaj mesecih izrazili pomisleke. Preden povzamem te pomisleke, si želim vzeti trenutek in povedati, da je večina spodaj zapisanega neposredno temelji na seriji člankov razvijalec Mark Murphy iz CommonsWare. Vsekakor bi morali preveriti njegove članke, saj ponujajo več podrobnosti in kritik z vidika razvijalca.
Varnost
V klasičnem distribucijskem modelu razvijalec ohrani ključ, ki ga uporablja za podpisovanje APK-ja, zaseben. Nikoli se ne deli z javnostjo in samo pooblaščene osebe bi morale imeti dostop do njega. To zagotavlja, da lahko samo te osebe ustvarijo veljaven APK.
Če pa v Trgovini Play uporabljate App Bundle, je Google tisti, ki upravlja ključ, ki podpisuje APK-je, ki jih prejmejo uporabniki. The privzeto vedenje za nove aplikacije, naložene v Google Play z začetkom avgusta 2021 je, da Google ustvari lasten distribucijski ključ, ki ga hrani zasebno od razvijalca.
Oddaja razvijalcev nove aplikacije Google bo namesto njih privzeto upravljal zasebni ključ, čeprav bodo razvijalci predložili posodobitve obstoječe aplikacije lahko še naprej uporablja APK-je oz lahko preklopijo na distribucijo AAB tako, da ustvarijo nov ključ, ki ga Google uporablja za nove uporabnike. Obstoječe aplikacije niso potrebni da preklopijo z distribucije APK-jev na Android App Bundle, čeprav jim je ta možnost na voljo, če se odločijo. Po nekaj odziva, Google bo to celo omogočilo da naložite svoj zasebni ključ, s katerim se Google podpiše, tako za nove kot za obstoječe aplikacije. Nobena od teh situacij ni idealna, saj bo imel Google ne glede na vse dostop do vašega zasebnega ključa, če boste to želeli uporabite pakete Android App Bundles (in razvijalci pri tem nimajo nobene izbire, če želijo predložiti novo aplikacijo po avgustu 2021!)
Čeprav smo prepričani, da Google jemlje varnost zelo resno, ni podjetja na Zemlji, ki bi bilo imuno na kršitve podatkov. Če je ključ, ki ga Google uporablja za podpis vaše aplikacije za distribucijo, v eni od teh kršitev, potem lahko kdorkoli podpiše različico vaše aplikacije in poskrbi, da je videti, kot da ste jo podpisali vi. In nekateri razvijalci in varnostni strokovnjaki niso zadovoljni s to možnostjo. To je zelo, zelo majhna možnost, da, toda dejstvo, da sploh obstaja, nekatere v skupnosti infosec prestraši.
Če razvijalci podpišejo APK-je za Android, pomeni, da lahko kdorkoli preveri APK-je v Googlu Play, slepo zaupanje ni potrebno. Je eleganten dizajn, ki zagotavlja preverljivo varnost. App Bundles to obrnejo na glavo in zdi se, da so strukturirani tako, da spodbujajo vezanost na prodajalca. Obstaja veliko alternativnih tehničnih pristopov, ki bi zagotovili majhne APK-je, ki jih še vedno podpisujejo razvijalci, vendar ti ne bi dali prednost Play. Na primer, vse različice APK-ja lahko ustvari in podpiše razvijalec, nato pa jih naloži v katero koli trgovino z aplikacijami.
Vsekakor je treba podati argumente o tem, ali je bolje varno shranjevanje zasebnih ključev prepustiti Googlu ali posameznim razvijalcem. Toda ti razvijalci (verjetno) običajno ne uporabljajo osrednjega repozitorija za svoje ključe. S tem ko razvijalce prisili k uporabi podpisovanja aplikacij Play, mora zlonamerni napadalec samo enkrat vdreti v Googlovo varnost, da pridobi na tisoče ali milijone ključev.
Glede na to, kaj je vredno, tukaj je tisto, kar Google pravi o tem, kako ščiti vaš podpisni ključ na svoji infrastrukturi:
[blockquote author="Wojtek Kaliciński, zagovornik razvijalcev za Android pri Googlu"]Ko uporabljate podpisovanje aplikacij Play, so vaši ključi shranjeni v isti infrastrukturi, kot jo Google uporablja za shranjevanje lastnih ključev.
Dostop do ključev je urejen s strogimi ACL-ji in revizijskimi sledmi, ki so vidne nedovoljenim posegom, za vse operacije.
Vsi artefakti, ustvarjeni in podpisani s ključem razvijalca, so vam na voljo v konzoli Google Play za pregled/potrditev.
Poleg tega, da preprečimo izgubo ključa, zelo pogosto izdelujemo varnostne kopije našega primarnega pomnilnika. Te varnostne kopije so močno šifrirane in redno testiramo obnovitev iz teh varnostnih kopij.
Če želite izvedeti več o Googlovi tehnični infrastrukturi, preberite Bele knjige o varnosti Google Cloud.[/blockquote]
Kakorkoli že, vsi zvoki so še vedno možni, izguba in kraja. Revizijske sledi le pomagajo preprečiti prihodnje napade; vlomljenih ključev ne bodo dobili nazaj.
Možnost nepooblaščenih sprememb
Ena velika težava v načinu, kako je Google nastavil App Bundle, je možnost, da se v aplikacijo dodajo nepooblaščene spremembe. Postopek pridobivanja APK-jev iz App Bundle sam po sebi vključuje spremembe, saj mora Google vsak APK sestaviti ročno. Medtem Google je obljubil, da ne bo in ne bo vnašal ali spreminjal kode, je težava s postopkom App Bundle ta, da ima moč za to.
Tukaj je nekaj primerov, kaj ima podjetje na položaju Google:
Recimo, da obstaja aplikacija za varno sporočanje, ki jo ljudje uporabljajo za komunikacijo brez tveganja nadzora vlade. To bi lahko bilo izjemno uporabno orodje za ljudi, ki protestirajo proti avtoritarni vladi, ali celo ljudi, ki želijo samo ohraniti svojo zasebnost. Ta vlada, ki želi imeti možnost videti, kaj govorijo uporabniki aplikacije, bi lahko poskusila prisiliti Google, da v kodo aplikacije doda stranska vrata za nadzor.
Ta primer je nekoliko bolj neškodljiv, a je tudi nekaj, kar nekatere skrbi. Recimo, da obstaja aplikacija, ki prejme na milijone prenosov na dan, vendar v njej ni nobenih oglasov ali analitike. To je ogromen vir podatkov, do katerega ni mogoče dostopati. Google, ki je oglaševalsko podjetje, bi morda želel dostopati do teh podatkov.
V klasičnem modelu distribucije aplikacij APK Google ne more spreminjati aplikacij brez spremembe podpisa. Če Google spremeni podpis, zlasti v priljubljeni aplikaciji, bodo ljudje opazili, ker se posodobitev ne namesti. Toda s svežnji aplikacij in podpisovanjem aplikacij bi lahko Google tiho vbrizgal lastno kodo v aplikacije, preden jih distribuira. Podpis se ne bi spremenil, ker bi bil Google lastnik podpisnega ključa.
Da bo jasno, ti primeri se neverjetno verjetno ne bodo zgodili. Google se nagiba k preprostemu popolnoma umakniti s težavnih trgov, namesto prilagajanja. A čeprav je malo verjetno, je še vedno mogoče. Samo zato, ker podjetje obljublja, da se nekaj ne bo zgodilo, tega še ne jamči.
Preglednost kode
Google, ki je slišal te pomisleke, je ta teden predstavil novo funkcijo, imenovano Preglednost kode za App Bundle. Transparentnost kode omogoča razvijalcu, da v bistvu ustvari drugi podpis, ki je uporabnikom priložen aplikaciji. Ta dodatni podpis je treba ustvariti iz ločenega zasebnega ključa, do katerega ima dostop samo razvijalec. Vendar pa ima ta metoda nekaj omejitev.
Preglednost kode zajema samo kodo. To se morda zdi očitno glede na ime, vendar pomeni tudi, da uporabnikom ne dovoljuje preverjanja virov, manifesta ali česar koli drugega, kar ni datoteka DEX ali izvorna knjižnica. Čeprav imajo zlonamerne spremembe datotek brez kode običajno veliko manjši učinek, je to še vedno luknja v varnosti aplikacije.
Druga težava s preglednostjo kode je, da ni inherentnega preverjanja. Za enega, to je neobvezna funkcija, zato ga morajo razvijalci vključiti v vsak nov APK, ki ga naložijo. Trenutno je treba to narediti iz ukazne vrstice in z različico bundletool ki ni priložen Android Studiu. Tudi ko ga razvijalec vključi, Android nima vgrajenega nobenega preverjanja, da bi preveril, ali se manifest preglednosti kode ujema s kodo v aplikaciji.
Končni uporabnik mora sam preveriti tako, da primerja manifest z javnim ključem, ki ga lahko zagotovi razvijalec, ali tako, da pošlje APK razvijalcu v preverjanje.
Čeprav preglednost kode omogoča potrditev, da nobena koda v aplikaciji ni spremenjena, ne vključuje nobenega preverjanja za druge dele aplikacije. V procesu tudi ni inherentnega zaupanja. Lahko trdite, da če ne zaupate Googlu, ste verjetno kos nalogi neodvisnega preverjanja, toda zakaj bi morali?
Obstajajo še druge težave s funkcijo preglednosti kode, npr izpostavljeno avtor Mark Murphy iz CommonsWare. Priporočam branje njegovega članka za bolj poglobljeno analizo funkcije.
Priročnost in izbira za razvijalce
Tretji (in zadnji za ta članek) razlog, zaradi katerega nekateri razvijalci nimajo težav s svežnji aplikacij, je zmanjšana priročnost in izbira.
Če razvijalec naredi novo aplikacijo v Trgovini Play, potem ko Google začne zahtevati App Bundle in se odloči privzeta možnost, da Googlu dovolite upravljanje ključa za podpisovanje, ne bodo imeli nikoli dostopa do tega podpisovanja ključ. Če bo isti razvijalec nato želel to aplikacijo distribuirati v drugi trgovini z aplikacijami, bo moral uporabiti svoj ključ, ki se ne bo ujemal z Googlovim.
To pomeni, da bodo morali uporabniki namestiti in posodobiti iz Googla Play ali iz virov tretjih oseb. Če želijo spremeniti vir, morajo popolnoma odstraniti aplikacijo, s čimer lahko izgubijo podatke, in jo znova namestiti. Agregatorji APK, kot so APKMirror potem se bo moral ukvarjati tudi z več uradnimi podpisi za isto aplikacijo. (Tehnično morajo to že storiti, ker vam podpisovanje aplikacij omogoča ustvarjanje novega, varnejšega ključa za nove uporabnike, vendar bo zanje in za druga spletna mesta slabše, ko vsi ima narediti.)
Googlov odgovor na to težavo je uporaba raziskovalca App Bundle ali Artifact explorer v Konzoli Play za prenos nastalih APK-jev iz naloženega svežnja. Podobno kot preglednost kode tudi to ni popolna rešitev. APK-ji, preneseni iz Play Console, bodo razdeljeni za različne profile naprav. Medtem ko Play Console podpira nalaganje več APK-jev za eno različico ene aplikacije, številni drugi distribucijski kanali tega ne podpirajo.
Tako veliko prednosti uporabe App Bundles izgine, ko razvijalci upravljajo več trgovin, zaradi česar je distribucija težja. Z novicami, ki Windows 11 je pridobitev podpore za aplikacije za Android zahvaljujoč trgovini Amazon Appstore nekateri menijo, da bo zahteva po paketih aplikacij odvrnila razvijalce od distribucije na Amazonu. Seveda je Googlova glavna skrb lastna trgovina z aplikacijami, vendar je točno to pristali v vroči vodi s tekmeci jih vodijo k ustvarjanju majhne, spravne spremembe o tem, kako trgovine z aplikacijami tretjih oseb delujejo v sistemu Android.
Nekaj težav, povezanih z več trgovinami, je povezljivost aplikacij in hitro testiranje.
Začnimo z medsebojno povezljivostjo aplikacij. Ste že kdaj prenesli aplikacijo, ki zaklene funkcije za plačljivim zidom? Skoraj zagotovo. Nekateri razvijalci postavijo funkcije za nakup v aplikaciji, drugi pa se lahko odločijo za ločeno, plačljivo aplikacijo. Ko je ta dodatek nameščen, so funkcije glavne aplikacije odklenjene.
Toda kaj preprečuje, da bi nekdo preprosto namestil dodatek iz piratskega vira? No, obstaja veliko možnosti za razvijalce, vendar vsaj ena vključuje uporabo dovoljenj, zaščitenih s podpisi. Recimo, da glavna aplikacija izjavi dovoljenje, zaščiteno s podpisom. Dodatna aplikacija nato izjavi, da želi uporabiti to dovoljenje. Idealno bi bilo, če bi imela dodatna aplikacija v sebi tudi nekakšno funkcijo preverjanja licence, ki se poveže z internetom in tako preveri, ali je uporabnik zakonit.
Če imata obe aplikaciji enak podpis, bo Android dodelil dovoljenje za aplikacijo dodatka in preverjanja zaščite pred piratstvom bodo uspela. Če aplikacija dodatka nima pravega podpisa, dovoljenje ne bo podeljeno in preverjanje ne bo uspelo.
S klasičnim distribucijskim modelom APK lahko uporabnik dobi katero koli aplikacijo iz katerega koli legitimnega vira in z njo zaključi. S trenutnim privzetim modelom App Bundle se podpisi v glavni in dodatni aplikaciji ne bodo ujemali. Google bo naredil edinstven ključ za vsako aplikacijo. Razvijalec bi lahko vedno opustil dovoljenje, zaščiteno s podpisom, in uporabil neposredno preverjanje zgoščevanja podpisa, vendar je to veliko manj varno.
In potem je tu še testiranje hitrega ognja. Uporabniki razvijalcem ves čas pošiljajo e-pošto o težavah v njihovih aplikacijah. Včasih so te težave preprosti popravki: ponovite težavo, poiščite težavo, jo popravite in naložite novo različico. Ampak včasih niso. Včasih razvijalci ne morejo reproducirati težave. Lahko popravijo tisto, kar mislijo, da je težava, potem pa mora uporabnik to preizkusiti. Predpostavimo, da je uporabnik namestil aplikacijo prek Google Play.
Z modelom APK lahko razvijalec spremeni nekaj kode, zgradi in podpiše nov APK ter ga pošlje uporabniku v testiranje. Ker se podpis preskusnega APK-ja ujema s tistim, ki ga je uporabnik namestil, je posodobitev, testiranje in poročanje preprost postopek. S paketi App Bundle to razpade. Ker Google podpiše APK, ki ga je uporabnik prvotno namestil, se ta ne bo ujemal s podpisom APK-ja, ki ga pošlje razvijalec. Če je ta aplikacija objavljena po roku App Bundles, razvijalec sploh ne bo imel dostopa do ključa, ki ga uporablja Google. Za preizkus bi moral uporabnik odstraniti trenutno aplikacijo, preden namesti preskusno različico.
Tukaj je en kup problemov. Prvič, obstajajo neprijetnosti, tako na strani razvijalca kot uporabnika. Odstranjevanje aplikacije samo zato, da preizkusite popravek, ni zabavno. In kaj, če težava izgine? Je šlo za spremembe, ki jih je naredil razvijalec, ali zato, ker je uporabnik dejansko izbrisal podatke aplikacije? Trgovina Play ima sicer interno testiranje, ki naj bi razvijalcem omogočilo hitro gradnjo in distribucijo, vendar zahteva, da uporabnik najprej odstrani različico za izdajo. Pravzaprav ne popravi ničesar.
Če se vse to sliši kot kup hipotetičnih nesmislov, je tukaj zelo resničen primer razvijalca, ki bo imel te težave, če bo Googlu dovolil, da zanj ustvari zasebni ključ: João Dias. Je razvijalec Taskerja, skupaj s celo vrsto vtičnikov, vključno s paketom AutoApps. Z novimi zahtevami za svežnje aplikacij bo Joãov razvojni cikel lahko postal veliko bolj zapleten, vsaj za nove aplikacije. Neposredno pošiljanje testnih različic bo manj priročno. Manj učinkovito bo preverjanje licenc.
To morda zveni kot nekakšen robni primer, vendar ni tako, da je João nek majhen razvijalec in verjetno ni edini. V Trgovini Play je veliko aplikacij, ki za odkrivanje nelegitimnih uporabnikov uporabljajo preverjanje podpisa.
Seveda pa so z novo možnostjo razvijalcev, da naložijo lastne podpisne ključe v Google, te težave vsaj nekoliko omilile. Toda razvijalci se morajo prijaviti, da omogočijo možnost za vsako aplikacijo. Če tega ne storijo, medsebojne povezave ne bodo uspele in podpora za hitro streljanje bo zahtevala nalaganje svežnja v Google in čakanje na generiranje APK-jev, preden uporabniku pošlje pravilnega. Poleg tega to še vedno pomeni, da morajo deliti svoj zasebni ključ, kar nas pripelje nazaj k pomislekom, o katerih smo razpravljali prej.
Rešitve
To je stara težava, glede na to, da so bile zahteve za App Bundle objavljene pred meseci, zato je bilo v vmesnem času predlaganih kar nekaj rešitev.
Ena rešitev je, da se izognete potrebi po podpisovanju aplikacij Play. Namesto generiranja App Bundle, ki ga Google nato predela v APK-je in podpiše, lahko to obdelavo izvede Android Studio. Nato lahko razvijalci preprosto naložijo ZIP, poln lokalno podpisanih APK-jev za vsako konfiguracijo, ki bi jo ustvaril Google.
S to rešitvijo Google sploh ne bi potreboval dostopa do ključev razvijalcev. Postopek bi bil zelo podoben klasičnemu modelu distribucije APK-jev, vendar bi vključeval več manjših APK-jev namesto enega.
Druga rešitev je, da preprosto ne zahtevate uporabe aplikacijskih svežnjev in razvijalcem še naprej dovoljujete nalaganje lokalno podpisanih APK-jev. Medtem ko App Bundle lahko v mnogih primerih boljša izkušnja za uporabnika, nekatere aplikacije dejansko nimajo koristi od razdelitve na konfiguracijo z minimalno velikostjo zmanjšanje.
Če bi Google implementiral obe rešitvi, potem razvijalcu, ki želi uporabljati App Bundle, ne bo treba nad podpisovanjem v Google in razvijalcu, čigar aplikaciji format ne bo imel veliko koristi, je ne bo treba uporabljati pri vse.
Googlovi odgovori
Samopodpisovanje
Ko so jih prvič vprašali, ali razvijalcem dovolijo, da upravljajo podpisovanje za App Bundle, je bil Googlov odgovor zelo neobvezujoč:
[blockquote author=""]Torej, na kratko sem govoril o zahtevi, da bodo naslednje leto nove aplikacije uporabljale aplikacijske svežnje, in ena stvar, ki prihaja s tem, je, da bomo po razširitvi zahtevali podpisovanje aplikacij Play. Torej bodo morali razvijalci ustvariti ključ za podpisovanje aplikacij v storitvi Play ali naložiti svoj ključ v storitev Play... ker je to predpogoj za pakete aplikacij. Od razvijalcev smo slišali, da nekateri od njih tega preprosto ne želijo storiti. Ne želijo imeti ključev, ki jih upravlja Play. In trenutno to ni mogoče, če želite uporabljati pakete aplikacij.
Vendar smo slišali te povratne informacije in... Trenutno ne morem govoriti o ničemer, nimamo ničesar za napovedati, vendar iščemo, kako bi lahko ublažili nekatere od teh skrbi. Ni nujno, da dovolite, da med nalaganjem svežnjev obdržite svoj ključ. Iščemo različne možnosti. Trenutno nimamo rešitve, ki bi jo lahko objavili. Vendar imamo še približno eno leto do zahteve, zato resnično upam, da bomo imeli odgovor za razvijalce na to.[/blockquote]
To je bilo konec novembra lani in zdi se, da se ni nič zgodilo. Le še nekaj mesecev do Veljati stopi v veljavo zahteva za App Bundle, razvijalci še vedno ne morejo obvladati podpisovanja svojih aplikacij. Medtem ko je Google zdaj to omogočil nalaganje vaš lasten ključ za nove in obstoječe aplikacije, to še vedno odvzame del podpisovanja iz rok razvijalca.
Spremembe kode
Čeprav je Google izrecno obljubil, da Trgovina Play ne bo spremenila kode aplikacije, obljuba ni jamstvo. Pri svežnjih aplikacij in podpisovanju aplikacij ni nobene tehnične omejitve, ki bi Googlu preprečevala spreminjanje naloženih aplikacij pred distribucijo.
Google je predstavil Preglednost kode kot izbirna funkcija, in čeprav to nekoliko pomaga, ima precej težav, kot smo že omenili.
Samoizdelani svežnji
Ko so Google vprašali, ali dovoli razvijalcem, da naredijo lastne "svežnje" aplikacij (ZIP-je, ki vsebujejo razdeljene APK-je), je bil odgovor v bistvu "tega ne bomo storili":
Verjetno ne tako, kot je opisano v vprašanju, saj bi to še bolj otežilo proces objave za razvijalce, mi pa ga pravzaprav želimo narediti enostavnejšega in varnejšega. Vendar smo spet slišali te povratne informacije in preučili bomo možnosti, kako to omogočiti, vendar verjetno ne na način, kot je opisan tukaj.
Zanimivo je, da se zdi, da je Googlova utemeljitev ta, da bi objavljanje postalo bolj zapleteno. Vendar bi lahko Google še vedno avtomatiziral postopek kot del pogovornega okna za generiranje APK-ja v Android Studiu. Poleg tega, če se zadevna aplikacija distribuira v več trgovinah, bi dejansko naredila enostavnejši postopek objave, saj razvijalcem ne bi bilo treba upravljati več podpisnih ključev in pritožb iz uporabniki.
In z uvedbo preglednosti kode se zdi, da zapletanje sploh ni problem. Preglednost kode vsaj zaenkrat zahteva, da razvijalec uporablja orodje ukazne vrstice in da uporabniki izrecno preverijo veljavnost aplikacije, ki jim je na voljo. To je bolj zapleteno kot postopek samoizdelave svežnjev in ni jasno, zakaj je to rešitev, ki jo ima Google raje.
Gredo naprej
App Bundle bodo od 1. avgusta zahtevana oblika distribucije za nove aplikacije, poslane v Google Play. Medtem ko je Google vsaj nekoliko obravnaval večino vprašanj, ki so jih izpostavili razvijalci in varnostni strokovnjaki, je glede odgovorov veliko nezaželenega. App Bundles kot oblika distribucije naslednje generacije prinašajo veliko očitnih prednosti, vendar bodo vedno prisotni pomisleki glede dajanja delnega ali popolnega nadzora nad podpisovanjem aplikacij Googlu.
Googlovi odzivi in prizadevanja so vsekakor cenjeni, vendar nekateri, kot je Mark Murphy, menijo, da niso šli dovolj daleč. Z rešitvami, kot so samoizdelani paketi, ki se ne izvajajo, rok za Android App Bundle pa je potreben hitro se približuje, ni videti, da bodo razvijalci v Googlu Play še dolgo lahko obdržali popoln nadzor nad svojimi aplikacijami dlje.
Pozneje popoldne bomo govorili o posledicah zahteve za Android App Bundle v Twitter Spaceu, zato se nam pridružite!