Google Play uskoro će prisiliti programere da učitaju pakete aplikacija umjesto APK-ova, postavljajući neugodna sigurnosna pitanja o zahtjevu.
Prošlog studenog, objavio je Google da će programeri morati objavljivati nove aplikacije u Trgovini Play koristeći Android App Bundle (AAB) format umjesto APK-a. Baš prije neki dan, Google je podsjetio programere na ovaj nadolazeći zahtjev, izazvavši oluju kontroverzi od korisnika koji vjeruju da Google ubija APK-ove, eliminira bočno učitavanje, ometa trgovine aplikacija trećih strana i sitnica.
Istina je da su Android App Bundles prilično veliki odmak od klasičnog APK formata na koji ste možda navikli, i kao korisnik i kao programer. Iako postoji dosta prednosti korištenja App Bundlesa, postoji jedan ključni aspekt njihove izrade zbog kojeg su neki programeri i stručnjaci za sigurnost s pravom zabrinuti.
U ovom ćemo članku pokriti kritike koje smo vidjeli o prelasku na Android App Bundles kao i neka predložena rješenja, a također ćemo govoriti o Googleovom predloženom rješenju za te probleme.
Pozadina
No, prije nego što se to dogodi, moramo malo porazgovarati o tome kako općenito funkcionira distribucija aplikacija na Androidu. Ako već znate kako funkcioniraju potpisivanje aplikacija i paketi aplikacija, možete preskočiti ovaj dio.
APK-ovi
Uglavnom se aplikacije na Androidu distribuiraju unutar APK datoteka. APK sadrži sav kôd i resurse aplikacije, zajedno s nekim sigurnosnim značajkama poput manifesta za potpisivanje. Kada se APK instalira, u osnovi se samo kopira u određenu mapu i dodaje internoj bazi podataka instaliranih aplikacija.
Potpisi
Tijekom instalacije potpis te aplikacije također se provjerava kako bi se provjerilo je li valjan. Ako je aplikacija već instalirana, Android provjerava potpis nove aplikacije u odnosu na onu koja je već instalirana. Ako potpis nije valjan ili se ne podudara, Android će odbiti instalirati aplikaciju.
Ta provjera potpisa važan je dio sigurnosti u Androidu. Provjerava je li aplikacija koju instalirate važeća i barem iz istog izvora kao ona koju ste već instalirali. Na primjer, ako instalirate, recimo, moju aplikaciju Lockscreen Widgets iz Trgovine Play, možete biti prilično sigurni da sam ja taj koji ga je potpisao i da je autentičan. Ako zatim pokušate instalirati ažuriranje Lockscreen Widgeta s nekog sumnjivog web-mjesta treće strane i ne uspije, znat ćete da je netko petljao s tim APK-om, vjerojatno da bi dodao zlonamjerni softver.
Ključ koji se koristi za potpisivanje aplikacije je (idealno) nikada javno objavljeno. Ovo je poznato kao privatni ključ. Privatni ključ se zatim koristi za generiranje ključa prikazanog u potpisu aplikacije, poznatog kao javni ključ. To je ono što Android i trgovine aplikacija koriste za provjeru valjanosti aplikacije. Neću ulaziti u to kako točno možete generirati javni ključ bez izlaganja privatnog ključa, jer to uključuje mnogo matematike enkripcije. Ako želite više detalja, pogledajte Googleova dokumentacija o potpisivanju APK-ova ili malo istražiti jednosmjerne matematičke funkcije.
Još jedna značajka potpisa aplikacija je mogućnost ograničavanja dopuštenja samo na aplikacije s odgovarajućim potpisima. Android to radi interno za mnoge funkcije, gdje samo aplikacije potpisane istim ključem kao okvir mogu pristupiti određenim značajkama.
App Bundleovi
Sada kada smo dali brzi pregled APK-ova i potpisa, razgovarajmo o paketima aplikacija. Ovdje dolaze APK resursi. Resursi su stvari poput izgleda, slika, zvuka itd. U osnovi, oni su sve što nije kod. Kako bi bolje podržali različite konfiguracije zaslona i različite jezike, programeri mogu izraditi više verzija istog resursa koji se koriste ovisno o uređaju i jeziku.
Ali u APK-u postoje svi ti resursi, bez obzira na to koje koristite. I zauzimaju prostor. Ovisno o složenosti vaše aplikacije, moglo bi biti mnogo neiskorištenih resursa za mnogo uređaja. To je ono što App Bundleovi trebaju riješiti. Programeri mogu generirati App Bundle baš kao APK, a taj App Bundle se zatim može prenijeti u Trgovinu Play, baš kao što to može APK.
Google zatim koristi taj App Bundle za generiranje cijele hrpe različitih APK-ova za različite konfiguracije uređaja. Svaki App Bundle sadrži samo resurse potrebne za tu konfiguraciju. Kada korisnik ode preuzeti tu aplikaciju, poslužuje mu se generirani APK koji odgovara njegovoj konfiguraciji. To pomaže smanjiti veličinu preuzimanja i instaliranja aplikacije, štedeći propusnost i prostor za pohranu.
Naravno, instaliranje APK-a specifičnog za vaš uređaj znači da vam je teže jednostavno ga kopirati na drugi uređaj i instalirati bez problema. Ovisno o vašoj perspektivi, to može biti dobra ili loša stvar. S jedne strane, to otežava piratstvo jer korisnici više nemaju cijelu aplikaciju. S druge strane, to otežava legitimno arhiviranje aplikacija, iz istog razloga.
Potpisivanje aplikacije
Budući da Android App Bundles nisu APK-ovi, ne možete jednostavno otvoriti AAB datoteku i instalirati je izravno na uređaj. Kada prenesete jedan u Trgovinu Play, Google koristi paket za generiranje različitih (nepotpisanih) APK datoteka. Ti APK-ovi moraju biti potpisani prije nego što se mogu instalirati.
Umjesto da traži od razvojnog programera da potpiše i ponovno prenese te generirane APK-ove, Google umjesto toga sam upravlja potpisivanjem. Trgovina Play ili koristi novi ključ koji sam izradi ili traži od programera ključ koji koristi za potpisivanje APK-ovi. S bilo kojom opcijom, Google upravlja javnim potpisivanjem za programera i omogućuje prijenos ključ. Google koristi ključ za prijenos za internu provjeru i osigurava da je App Bundle (ili APK u nekim slučajevima) koji razvojni programer prenosi pravi.
Ako je ključ za prijenos ugrožen ili izgubljen, programeri mogu zatražiti novi, a ključ za potpisivanje koji se koristi za distribuciju aplikacije ostaje nepromijenjen.
Potpisivanje aplikacija ima još puno toga, ali ovo je ono što je relevantno za ovaj članak. Ako želite, možete pročitati više o paketima aplikacija i potpisivanju aplikacija na ovaj Medium članak Wojtek Kaliciński.
Kritika
U teoriji i praksi, App Bundleovi su prilično dobri. Smanjuju korištenje podataka i veličinu instaliranja, a sve to bez potrebe korisnika. Ali zbog načina na koji se implementira, neki su programeri i istraživači sigurnosti u proteklih nekoliko mjeseci izrazili zabrinutost. Prije nego što rezimiram ove brige, želim izdvojiti trenutak i reći da je većina onoga što je napisano u nastavku izravno na temelju niza članaka programer Mark Murphy iz CommonsWare. Svakako biste trebali provjeriti njegove članke, budući da pružaju više detalja i kritika iz perspektive programera.
Sigurnost
U klasičnom distribucijskom modelu, programer čuva ključ koji koristi za potpisivanje APK-a privatnim. Nikada se ne dijeli s javnošću i samo ovlaštene osobe trebaju imati pristup. To osigurava da samo te osobe mogu generirati važeći APK.
Ali ako koristite pakete aplikacija u Trgovini Play, Google je taj koji upravlja ključem koji potpisuje APK-ove koje korisnici primaju. The zadano ponašanje za nove aplikacije prenesene na Google Play počevši od kolovoza 2021 je da Google stvori vlastiti distribucijski ključ koji čuva u tajnosti od programera.
Podnošenje programera nove aplikacije Google će prema zadanim postavkama upravljati njihovim privatnim ključem, iako programeri podnose ažuriranja postojeće aplikacije može nastaviti koristiti APK-ove ili mogu se prebaciti na AAB distribuciju generiranjem novog ključa koji će Google koristiti za nove korisnike. Postojeće aplikacije nisu potrebni da prijeđu s distribucije APK-a na Android App Bundles, iako im je ta opcija dostupna ako to odaberu. Nakon malo odbijanja, Google čak će to i omogućiti za prijenos vlastitog privatnog ključa kojim se Google može prijaviti, za nove i postojeće aplikacije. Nijedna od ovih situacija nije idealna, jer bez obzira na sve, Google će imati pristup vašem privatnom ključu ako to želite koristite Android App Bundles (i programeri nemaju izbora ako žele poslati novu aplikaciju nakon kolovoza 2021!)
Iako smo uvjereni da Google shvaća sigurnost vrlo ozbiljno, ne postoji tvrtka na svijetu koja je imuna na povrede podataka. Ako je ključ koji Google koristi za potpisivanje vaše aplikacije za distribuciju u jednoj od tih povreda, tada svatko može potpisati verziju vaše aplikacije i učiniti da izgleda kao da ste je vi potpisali. Neki programeri i stručnjaci za sigurnost nisu sretni zbog ove mogućnosti. To je vrlo, vrlo mala mogućnost, da, ali činjenica da je uopće moguća plaši neke u infosec zajednici.
Ako programeri potpišu Android APK-ove, to znači da svatko može provjeriti APK-ove s Google Playa, slijepo povjerenje nije potrebno. To je elegantan dizajn koji pruža provjerljivu sigurnost. App Bundleovi to preokreću naopako i čini se da su strukturirani za promicanje vezanosti za dobavljača. Postoje mnogi alternativni tehnički pristupi koji bi pružili male APK-ove koje još uvijek potpisuju programeri, ali oni ne bi preferirali Play. Na primjer, razvojni programer može generirati i potpisati sve varijante APK-a, a zatim ih učitati u bilo koju trgovinu aplikacija.
Svakako postoje argumenti o tome je li bolje ostaviti sigurnu pohranu privatnih ključeva u rukama Googlea ili pojedinačnih programera. Ali ti programeri (vjerojatno) obično ne koriste središnje spremište za svoje ključeve. Prisiljavanjem razvojnih programera da koriste Play App Signing, zlonamjerni napadač treba samo jednom probiti Googleovu sigurnost kako bi dohvatio tisuće ili milijune ključeva.
Što se toga tiče, evo što Google kaže o tome kako štiti vaš ključ za potpisivanje na svojoj infrastrukturi:
[blockquote author="Wojtek Kaliciński, zagovornik razvojnih programera za Android u Googleu"]Kada upotrebljavate potpisivanje aplikacije Play, vaši se ključevi pohranjuju na istoj infrastrukturi koju Google koristi za pohranjivanje vlastitih ključeva.
Pristup ključu reguliran je strogim ACL-ovima i revizijskim stazama koje su evidentne neovlaštene promjene za sve operacije.
Svi artefakti generirani i potpisani ključem razvojnog programera dostupni su vam na Google Play konzoli za pregled/ovjeru.
Nadalje, kako bismo spriječili gubitak ključa, vrlo često izrađujemo sigurnosne kopije naše primarne pohrane. Ove sigurnosne kopije su snažno šifrirane i redovito testiramo vraćanje iz tih sigurnosnih kopija.
Ako želite saznati više o Googleovoj tehničkoj infrastrukturi, pročitajte Bijele knjige o sigurnosti Google Clouda.[/blockquote]
Koliko god to bilo sjajno, svi zvukovi, gubitak i krađa su i dalje mogući. A revizijski tragovi samo pomažu u sprječavanju budućih napada; neće dobiti izgubljene ključeve natrag.
Mogućnost neovlaštenih izmjena
Jedan veliki problem s načinom na koji je Google postavio App Bundleove je mogućnost da se aplikaciji dodaju neovlaštene izmjene. Proces izdvajanja APK-ova iz App Bundlea inherentno uključuje izmjene jer Google mora ručno izraditi svaki APK. Dok Google je obećao da neće i neće ubacivati ili modificirati kod, problem s procesom App Bundlea je u tome što ima moć za to.
Evo nekoliko primjera onoga što tvrtka na poziciji Googlea ima moć učiniti:
Recimo da postoji aplikacija za sigurnu razmjenu poruka koju ljudi koriste za komunikaciju bez rizika od nadzora vlade. Ovo bi mogao biti nevjerojatno koristan alat za ljude koji protestiraju protiv autoritarne vlade ili čak za ljude koji samo žele zadržati svoju privatnost. Ta bi vlada, želeći mogućnost da vidi što korisnici aplikacije govore, mogla pokušati natjerati Google da doda stražnja vrata za nadzor u kod aplikacije.
Ovaj primjer je malo bezazleniji, ali je i nešto što zabrinjava neke ljude. Recimo da postoji aplikacija koja ima milijune preuzimanja dnevno, ali u njoj nema oglasa niti analitike. To je ogroman izvor podataka bez mogućnosti pristupa tim podacima. Google, kao tvrtka za oglašavanje, možda želi pristup tim podacima.
U klasičnom APK modelu distribucije aplikacija, Google ne može modificirati aplikacije bez promjene potpisa. Ako Google promijeni potpis, osobito na popularnoj aplikaciji, ljudi će primijetiti jer se ažuriranje neće instalirati. Ali uz App Bundles i App Signing, Google bi mogao tiho ubaciti vlastiti kod u aplikacije prije nego što ih distribuira. Potpis se ne bi promijenio jer bi Google posjedovao ključ za potpisivanje.
Da bude jasno, nevjerojatno je malo vjerojatno da će se ovi primjeri dogoditi. Google nastoji jednostavno potpuno se povući s problematičnih tržišta, umjesto prilagođavanja. Ali iako je malo vjerojatno, ipak je moguće. Samo zato što tvrtka obećava da se nešto neće dogoditi, to ne jamči.
Transparentnost koda
Google je, čuvši ovu zabrinutost, ovaj tjedan predstavio novu značajku tzv Transparentnost koda za pakete aplikacija. Transparentnost koda omogućuje razvojnom programeru stvaranje drugog potpisa koji se korisnicima isporučuje s aplikacijom. Ovaj dodatni potpis treba izraditi iz zasebnog privatnog ključa kojemu samo razvojni programer ima pristup. Međutim, postoje neka ograničenja ove metode.
Transparentnost koda pokriva samo kod. To se može činiti očiglednim s obzirom na naziv, ali također znači da ne dopušta korisnicima provjeru resursa, manifesta ili bilo čega drugog što nije DEX datoteka ili izvorna biblioteka. Iako zlonamjerne izmjene nekodiranih datoteka obično imaju mnogo manji učinak, to je još uvijek rupa u sigurnosti aplikacije.
Još jedan problem s Transparentnošću koda je taj što ne postoji inherentna provjera. Za jednog, to je izborna značajka, pa ga programeri moraju zapamtiti uključiti za svaki novi APK koji učitaju. Trenutačno se to mora učiniti iz naredbenog retka i s verzijom programa bundletool koji ne dolazi s Android Studiom. Čak i kada ga programer uključi, Android nema ugrađenu nikakvu vrstu provjere za provjeru podudara li se manifest transparentnosti koda s kodom u aplikaciji.
Na krajnjem korisniku je da sam provjeri usporedbom manifesta s javnim ključem koji razvojni programer može dati ili slanjem APK-a razvojnom programeru na provjeru.
Dok Transparentnost koda omogućuje potvrdu da nijedan kôd u aplikaciji nije izmijenjen, ne uključuje nikakvu vrstu provjere za druge dijelove aplikacije. Također nema inherentnog povjerenja u procesu. Mogli biste tvrditi da ako ne vjerujete Googleu, vjerojatno ste dorasli zadatku neovisne provjere, ali zašto biste morali?
Postoje i drugi problemi sa značajkom transparentnosti koda, npr istaknuto Marka Murphyja iz CommonsWare. Preporučujem da pročitate njegov članak za dublju analizu značajke.
Praktičnost i izbor programera
Treći (i posljednji za ovaj članak) razlog zbog kojeg neki razvojni programeri imaju problem s paketima aplikacija jest smanjena praktičnost i izbor.
Ako razvojni programer napravi novu aplikaciju u Trgovini Play nakon što Google počne zahtijevati App Bundleove i on odabere zadana opcija dopuštanja Googleu da upravlja ključem za potpisivanje, oni nikada neće imati pristup tom potpisivanju ključ. Ako taj isti razvojni programer zatim želi distribuirati tu aplikaciju u drugoj trgovini aplikacija, morat će koristiti vlastiti ključ, koji neće odgovarati Googleovom.
To znači da će korisnici morati instalirati i ažurirati s Google Playa ili iz izvora trećih strana. Ako žele promijeniti izvor, moraju potpuno deinstalirati aplikaciju, potencijalno gubeći podatke, i ponovno instalirati. APK agregatori poput APK Mirror tada će se također morati nositi s više službenih potpisa za istu aplikaciju. (Tehnički, oni to već moraju učiniti jer vam potpisivanje aplikacije omogućuje stvaranje novog, sigurnijeg ključa za nove korisnike, ali bit će gore za njih i druge web-lokacije kada svi ima učiniti to.)
Googleov odgovor na ovaj problem je korištenje App Bundle explorera ili Artifact explorera na Play konzoli za preuzimanje dobivenih APK-ova iz prenesenog paketa. Slično Transparentnosti koda, ovo nije potpuno rješenje. APK-ovi preuzeti s Play konzole bit će podijeljeni za različite profile uređaja. Dok Play Console podržava prijenos više APK-ova za jednu verziju jedne aplikacije, mnogi drugi distribucijski kanali to ne podržavaju.
Stoga mnoge prednosti korištenja paketa aplikacija nestaju kada programeri upravljaju s više trgovina, što otežava distribuciju. Uz vijest da Windows 11 je dobivanje podrške za Android aplikacije zahvaljujući Amazon Appstoreu, neki vjeruju da će zahtjev za App Bundleove odvratiti programere od distribucije na Amazonu. Naravno, Googleova primarna briga je njegova vlastita trgovina aplikacija, ali to je upravo ono doveo ih je u vruću vodu s konkurentima navodeći ih da naprave male, pomirljive promjene kako trgovine aplikacija trećih strana rade na Androidu.
Nekoliko problema vezanih uz više trgovina su međusobno povezivanje aplikacija i brzo testiranje.
Počnimo s međusobnom povezanošću aplikacija. Jeste li ikada preuzeli aplikaciju koja zaključava značajke iza paywalla? Gotovo sigurno. Neki programeri stavljaju značajke iza kupnje unutar aplikacije, ali drugi mogu odlučiti napraviti zasebnu aplikaciju koja se plaća. Kada se ta dodatna aplikacija instalira, značajke glavne aplikacije su otključane.
Ali što sprječava nekoga da jednostavno instalira dodatak iz piratskog izvora? Pa, postoji mnogo opcija za programere, ali barem jedna uključuje korištenje dopuštenja zaštićenih potpisom. Recimo da glavna aplikacija deklarira dopuštenje zaštićeno potpisom. Dodatna aplikacija tada izjavljuje da želi koristiti to dopuštenje. U idealnom slučaju, dodatna aplikacija će također imati neku vrstu funkcije provjere licence u sebi, koja se povezuje na internet kako bi se uvjerilo da je korisnik legitiman.
Ako obje aplikacije imaju isti potpis, Android će dati dopuštenje aplikaciji dodatka i proći će provjere zaštite od piratstva. Ako dodatna aplikacija nema pravi potpis, dopuštenje se neće dati i provjera neće uspjeti.
Uz klasični model distribucije APK-a, korisnik može nabaviti bilo koju aplikaciju iz bilo kojeg legitimnog izvora i završiti s njom. Uz trenutni zadani model App Bundlea, potpisi na glavnoj i dodatnoj aplikaciji neće se podudarati. Google će napraviti jedinstveni ključ za svaku aplikaciju. Programer bi uvijek mogao izbaciti dopuštenje zaštićeno potpisom i koristiti izravnu provjeru hashiranja potpisa, ali to je puno manje sigurno.
A tu je i testiranje brze paljbe. Korisnici cijelo vrijeme šalju e-poštu programerima o problemima u njihovim aplikacijama. Ponekad su ti problemi jednostavni popravci: reproducirajte problem, pronađite problem, popravite ga i prenesite novu verziju. Ali ponekad nisu. Ponekad programeri ne mogu reproducirati problem. Oni mogu popraviti ono za što misle da je problem, ali onda to korisnik mora testirati. Sada pretpostavimo da je korisnik instalirao aplikaciju putem Google Playa.
Uz model APK-a, programer može promijeniti neki kod, izgraditi i potpisati novi APK te ga poslati korisniku na testiranje. Budući da potpis testnog APK-a odgovara onom koji je korisnik instalirao, jednostavan je postupak za ažuriranje, testiranje i izvješćivanje. S App Bundleovima ovo pada u vodu. Budući da Google potpisuje APK koji je korisnik izvorno instalirao, on neće odgovarati potpisu APK-a koji programer šalje. Ako se ova aplikacija objavi nakon roka za App Bundles, razvojni programer čak neće imati pristup ključu koji Google koristi. Kako bi testirao, korisnik bi trebao deinstalirati trenutnu aplikaciju prije instaliranja testne verzije.
Ima tu hrpa problema. Prvo, tu su neugodnosti, i na strani programera i na strani korisnika. Deinstaliranje aplikacije samo radi testiranja popravka nije zabavno. A što ako problem nestane? Jesu li to bile promjene koje je napravio programer ili je to zato što je korisnik učinkovito izbrisao podatke aplikacije? Play Store ima interno testiranje, koje bi trebalo programerima omogućiti brzu izgradnju i distribuciju, ali zahtijeva od korisnika da prvo deinstalira verziju izdanja. To zapravo ništa ne popravlja.
U slučaju da sve ovo zvuči kao gomila hipotetskih gluposti, evo vrlo stvarnog primjera programera koji će imati ove probleme ako dopusti Googleu da za njih generira privatni ključ: João Dias. On je programer Taskera, zajedno s čitavom hrpom dodataka, uključujući paket AutoApps. S novim zahtjevom za pakete aplikacija, Joãov razvojni ciklus mogao bi postati puno složeniji, barem za nove aplikacije. Slanje testnih verzija izravno bit će manje zgodno. Provjera licenci bit će manje učinkovita.
Ovo može zvučati kao krajnji slučaj, ali nije kao da je João neki mali programer i vjerojatno nije jedini. Postoje mnoge aplikacije u Trgovini Play koje se oslanjaju na provjeru potpisa za otkrivanje nelegitimnih korisnika.
Naravno, s novom opcijom za programere da učitaju vlastite ključeve za potpisivanje na Google, ti su problemi barem donekle ublaženi. Ali programeri se moraju uključiti kako bi omogućili opciju za svaku aplikaciju. Ako to ne učine, međupovezivanja neće uspjeti, a podrška za brzu paljbu zahtijevat će učitavanje paketa na Google i čekanje da se generiraju APK-ovi prije slanja ispravnog korisniku. Osim toga, to još uvijek znači da moraju dijeliti svoj privatni ključ, što nas vraća na nedoumice o kojima smo ranije govorili.
Rješenja
Ovo je stari problem s obzirom da su zahtjevi za App Bundle objavljeni prije nekoliko mjeseci, tako da je u međuvremenu bilo predloženo dosta rješenja.
Jedno je rješenje izbjeći potrebu za potpisivanjem aplikacije Play. Umjesto generiranja App Bundlea koji Google potom obrađuje u APK-ove i potpisuje, tu bi obradu mogao obaviti Android Studio. Zatim, programeri mogu samo prenijeti ZIP pun lokalno potpisanih APK-ova za svaku konfiguraciju koju bi Google generirao.
S tim rješenjem Google uopće ne bi trebao pristup ključevima programera. Proces bi bio vrlo sličan klasičnom modelu distribucije APK-a, ali bi uključivao više, manjih APK-ova umjesto samo jednog.
Drugo je rješenje jednostavno ne zahtijevati upotrebu paketa aplikacija i nastaviti dopuštati programerima da učitaju lokalno potpisane APK-ove. Dok App Bundleovi mogu biti bolje iskustvo za korisnika u mnogim slučajevima, neke aplikacije zapravo nemaju koristi od toga što su podijeljene po konfiguraciji, s minimalnom veličinom smanjenje.
Ako Google implementira oba ova rješenja, razvojni programer koji želi koristiti App Bundleove neće morati preko potpisivanja Googleu, a programer čija aplikacija neće imati mnogo koristi od formata neće ga morati koristiti na svi.
Googleovi odgovori
Samopotpisivanje
Kad su ih prvi put pitali o dopuštanju programerima da upravljaju potpisivanjem za App Bundleove, Googleov odgovor bio je vrlo neobavezan:
[blockquote author=""]Dakle, kratko sam govorio o zahtjevu sljedeće godine za nove aplikacije da koriste pakete aplikacija, a jedna stvar koja dolazi s tim je da ćemo kao proširenje zahtijevati potpisivanje Play aplikacije. Stoga će programeri morati ili generirati ključ za potpisivanje aplikacije na Playu ili prenijeti vlastiti ključ na Play… jer je to preduvjet za pakete aplikacija. Čuli smo od programera da neki od njih to jednostavno ne žele učiniti. Ne žele imati ključeve kojima upravlja Play. A trenutno to nije moguće ako želite koristiti pakete aplikacija.
Ali, čuli smo te povratne informacije, i... ne mogu sada govoriti ni o čemu, nemamo što objaviti, ali tražimo kako bismo mogli ublažiti neke od tih zabrinutosti. Ne mora nužno dopustiti zadržavanje vlastitog ključa tijekom učitavanja skupova. Razmatramo različite opcije. Samo trenutno nemamo rješenje za objaviti. No, imamo još oko godinu dana do zahtjeva, tako da se stvarno nadam da ćemo imati odgovor za programere na ovo.[/blockquote]
Bilo je to krajem studenog prošle godine i čini se da se ništa nije dogodilo. Preostalo je samo nekoliko mjeseci prije Zahtjev za pakete aplikacija stupa na snagu, još uvijek ne postoji način na koji bi programeri mogli sami potpisivati svoje aplikacije. Dok je Google sada to omogućio Učitaj Vaš vlastiti ključ za nove i postojeće aplikacije, ovo i dalje izuzima dio potpisivanja iz ruku programera.
Promjene koda
Iako je Google izričito obećao da Play Store neće mijenjati kod aplikacije, obećanje nije jamstvo. S App Bundleovima i App Signingom ne postoji tehničko ograničenje za koje znamo da sprječava Google da mijenja prenesene aplikacije prije distribucije.
Google je predstavio Transparentnost koda kao izborna značajka, i dok ovo donekle pomaže, ima dosta problema, kao što smo ranije spomenuli.
Svežnjeve vlastite izrade
Kada je Google upitan o dopuštanju razvojnim programerima da naprave vlastite "pakete" aplikacija (ZIP-ove koji sadrže podijeljene APK-ove), odgovor je u biti bio "nećemo to učiniti":
Vjerojatno ne kao što je opisano u pitanju, jer bi to još više otežalo proces objavljivanja programerima, a mi ga zapravo želimo učiniti jednostavnijim i sigurnijim. Međutim, opet, čuli smo te povratne informacije i razmotrit ćemo opcije kako to omogućiti, ali vjerojatno ne na način koji je ovdje opisan.
Zanimljivo, čini se da je Googleovo opravdanje da bi to zakompliciralo objavljivanje. Međutim, Google bi i dalje mogao automatizirati proces kao dio dijaloga za generiranje APK-a u Android Studiju. Nadalje, ako se predmetna aplikacija distribuira u više trgovina, to bi zapravo činilo proces objavljivanja jednostavniji, budući da programeri ne bi morali upravljati višestrukim ključevima za potpisivanje i pritužbama iz korisnika.
A s uvođenjem transparentnosti koda, čini se da kompliciranje ipak nije problem. Transparentnost koda, barem za sada, zahtijeva od programera da koristi alat naredbenog retka i da korisnici izričito provjeravaju valjanost aplikacije koja im se poslužuje. Ovo je kompliciranije od procesa samostalne izrade paketa i nejasno je zašto je to rješenje koje Google preferira.
Ide naprijed
App Bundleovi bit će obavezni format distribucije za nove aplikacije poslane na Google Play počevši od 1. kolovoza. Iako se Google barem donekle pozabavio većinom problema koje su postavili programeri i stručnjaci za sigurnost, odgovori ostavljaju mnogo nedostatkom. Mnogo je očitih prednosti App Bundlesa kao distribucijskog formata sljedeće generacije, ali uvijek će postojati dugotrajni problemi s davanjem djelomične ili potpune kontrole nad potpisivanjem aplikacije Googleu.
Googleovi odgovori i napori svakako su cijenjeni, ali neki, poput Marka Murphyja, smatraju da nisu otišli dovoljno daleko. S rješenjima kao što su paketi koje sami izradite nisu implementirana, a rok za Android App Bundles koji se zahtijeva brzo približava, ne čini se da će programeri na Google Playu moći dugo zadržati potpunu kontrolu nad svojim aplikacijama više.
Razgovarat ćemo o implikacijama zahtjeva za Android App Bundle u Twitter prostoru kasnije popodne, stoga nam se pridružite!