Google Play sunnib peagi arendajaid APK-de asemel üles laadima App Bundle'id, tekitades nõude kohta ebamugavaid turvaküsimusi.
Eelmise aasta novembris, Google teatas et arendajad peavad avaldama Play poes uued rakendused, kasutades APK asemel Android App Bundle'i (AAB) vormingut. Just üleeile tuletas Google arendajatele meelde seda eelseisvat nõuet, põhjustades vaidlusi. kasutajatelt, kes usuvad, et Google tapab APK-sid, välistab külglaadimise, takistab kolmandate osapoolte rakenduste poode ja mida mitte.
On tõsi, et Android App Bundle'id on päris suur kõrvalekalle klassikalisest APK-vormingust, millega võite olla harjunud nii kasutaja kui ka arendajana. Kuigi App Bundle'i kasutamisel on üsna palju eeliseid, on nende tegemisel üks põhiaspekt, mis paneb mõned arendajad ja turbeeksperdid õigustatult muretsema.
Selles artiklis käsitleme kriitikat, mida oleme näinud Android App Bundle'ile ülemineku kohta, ja mõningaid pakutud lahendusi ning räägime ka Google'i pakutud lahendustest nendele probleemidele.
Taust
Enne kui see juhtub, peame siiski natuke rääkima sellest, kuidas rakenduste levitamine Androidis üldiselt töötab. Kui teate juba, kuidas rakenduste allkirjastamine ja rakenduste komplektid töötavad, võite selle osa vahele jätta.
APK-d
Enamasti levitatakse Androidi rakendusi APK-failide sees. APK sisaldab kogu rakenduse koodi ja ressursse ning mõningaid turvafunktsioone, nagu allkirjastamise manifest. Kui APK on installitud, kopeeritakse see põhimõtteliselt lihtsalt konkreetsesse kausta ja lisatakse installitud rakenduste sisemisse andmebaasi.
Allkirjad
Installimise ajal kontrollitakse ka selle rakenduse allkirja, et veenduda selle kehtivuses. Kui rakendus on juba installitud, kontrollib Android uue rakenduse allkirja juba installitud allkirjaga. Kui allkiri ei kehti või ei ühti, keeldub Android rakendust installimast.
See allkirjade kontrollimine on Androidi turvalisuse oluline osa. See tagab, et installitav rakendus on kehtiv ja pärineb vähemalt samast allikast, millest juba installitud rakendus. Kui installite näiteks minu rakendus Lockscreen Widgets Play poest, võite olla üsna kindel, et mina olen selle allkirjastanud ja et see on autentne. Kui proovite seejärel installida mõnelt hämaralt kolmanda osapoole saidilt Lockscreeni vidinate värskendust ja see ebaõnnestub, saate teada, et keegi rikkus seda APK-d, et lisada tõenäoliselt pahavara.
Rakenduse allkirjastamiseks kasutatav võti on (ideaaljuhul) mitte kunagi avalikult vabastatud. Seda tuntakse kui privaatvõtit. Seejärel kasutatakse privaatvõtit rakenduse allkirjas oleva võtme, mida nimetatakse avalikuks võtmeks, genereerimiseks. Seda kasutavad Android ja rakenduste poed rakenduse kehtivuse kontrollimiseks. Ma ei hakka uurima, kuidas täpselt saate luua avalikku võtit ilma privaatvõtit paljastamata, kuna see hõlmab palju krüpteerimismatemaatikat. Kui soovite rohkem üksikasju, vaadake Google'i dokumentatsioon APK-de allkirjastamise kohta või uurige ühesuunalisi matemaatilisi funktsioone.
Rakenduse allkirjade teine funktsioon on võimalus piirata õigusi ainult vastavate allkirjadega rakendustele. Android teeb seda paljude funktsioonide jaoks sisemiselt, kus teatud funktsioonidele pääsevad juurde ainult raamistikuga sama võtmega allkirjastatud rakendused.
Rakenduste komplektid
Nüüd, kui oleme andnud kiire ülevaate APK-dest ja signatuuridest, räägime App Bundle'idest. Siin tulevad sisse APK ressursid. Ressursid on sellised asjad nagu paigutused, pildid, heli jne. Põhimõtteliselt on need kõik, mis pole kood. Erinevate kuvakonfiguratsioonide ja erinevate keelte paremaks toetamiseks saavad arendajad teha samast ressursist mitu versiooni, mida kasutatakse olenevalt seadmest ja keelest.
Kuid APK-s on kõik need ressursid olemas, olenemata sellest, millist te kasutate. Ja nad võtavad ruumi. Olenevalt teie rakenduse keerukusest võib paljude seadmete jaoks olla palju kasutamata ressursse. Selle lahendamiseks on App Bundle'id loodud. Arendajad saavad luua App Bundle'i nagu APK ja selle App Bundle'i saab seejärel Play poodi üles laadida, täpselt nagu APK.
Seejärel kasutab Google seda App Bundle'i, et luua terve hulk erinevaid APK-sid erinevate seadme konfiguratsioonide jaoks. Iga App Bundle sisaldab ainult selle konfiguratsiooni jaoks vajalikke ressursse. Kui kasutaja laadib selle rakenduse alla, esitatakse talle loodud APK, mis vastab nende konfiguratsioonile. See aitab vähendada nii rakenduste allalaadimise kui installimise mahtu, säästes ribalaiust ja salvestusruumi.
Loomulikult tähendab teie seadmele spetsiifilise APK installimine seda, et teil on raskem seda lihtsalt teise seadmesse kopeerida ja probleemideta installida. Sõltuvalt teie vaatenurgast võib see olla hea või halb asi. Ühest küljest muudab see piraatluse keerulisemaks, kuna kasutajatel pole enam tervet rakendust. Teisest küljest muudab see samal põhjusel rakenduste seadusliku arhiveerimise keerulisemaks.
Rakenduse allkirjastamine
Kuna Android App Bundle'id ei ole APK-d, ei saa te lihtsalt AAB-faili avada ja seda otse seadmesse installida. Kui laadite selle Play poodi üles, kasutab Google paketti erinevate (allkirjata) APK-failide loomiseks. Need APK-d tuleb enne installimist allkirjastada.
Selle asemel, et paluda arendajal need loodud APK-d allkirjastada ja uuesti üles laadida, haldab Google allkirjastamist ise. Play pood kasutab enda loodud uut võtit või küsib arendajalt allkirjastamiseks kasutatavat võtit APK-d. Mõlema valiku korral tegeleb Google arendaja avaliku allkirjastamisega ja pakub üleslaadimist võti. Google kasutab sisemiseks kinnitamiseks üleslaadimisvõtit ja tagab, et arendaja üleslaaditav App Bundle (või mõnel juhul APK) on õige.
Kui üleslaadimisvõti on ohus või kaob, saavad arendajad taotleda uut ja rakenduse levitamiseks kasutatav allkirjastamisvõti jääb muutumatuks.
Rakenduse allkirjastamises on palju muudki, kuid see on selle artikli jaoks asjakohane. Soovi korral saate lugeda lisateavet App Bundle'ide ja rakenduse sisselogimise kohta see keskmise artikli autor Wojtek Kaliciński.
Kriitika
Teoreetiliselt ja praktikas on App Bundle'id päris suurepärased. Need vähendavad andmekasutust ja installimahtu, ilma et kasutaja peaks midagi tegema. Kuid selle rakendamise tõttu on mõned arendajad ja turvauurijad viimastel kuudel muret tekitanud. Enne nende murede kokkuvõtmist tahan öelda, et suurem osa allpool kirjutatust on otse artiklite sarja põhjal arendaja Mark Murphy CommonsWare. Peaksite kindlasti tema artikleid üle vaatama, kuna need pakuvad arendaja vaatenurgast rohkem üksikasju ja kriitikat.
Turvalisus
Klassikalises levitamismudelis hoiab arendaja APK allkirjastamiseks kasutatava võtme privaatsena. Seda ei jagata kunagi avalikkusele ja sellele peaks juurdepääs olema ainult volitatud inimestel. See tagab, et ainult need inimesed saavad luua kehtiva APK.
Kuid kui kasutate Play poes App Bundle'i, haldab Google võtit, millega kasutajad saavad APK-sid allkirjastada. The vaikimisi Google Playsse üles laaditud uute rakenduste käitumine alates augustist 2021 Google peab looma oma jaotusvõtme, mida ta hoiab arendaja eest privaatsena.
Arendajad esitavad uued rakendused vaikimisi haldab Google nende privaatvõtit, kuigi arendajad saadavad värskendusi olemasolevaid rakendusi saab APK-de kasutamist jätkata või nad saavad lülituda AAB-levitamisele, luues Google'ile uue võtme, mida uute kasutajate jaoks kasutada. Olemasolevad rakendused ei ole nõutavad et lülituda APK levitamiselt üle Android App Bundle'ile, kuigi see valik on neile saadaval, kui nad valivad. Pärast mõningast tagasilööki Google teeb selle isegi võimalikuks oma privaatvõtme üleslaadimiseks, et Google saaks sellega nii uute kui ka olemasolevate rakenduste jaoks sisse logida. Ükski neist olukordadest pole ideaalne, sest Google'il on soovi korral juurdepääs teie privaatvõtmele kasutage Android App Bundle'i (ja arendajatel pole selles küsimuses valikut, kui nad soovivad pärast augustit uue rakenduse esitada 2021!)
Kuigi oleme kindlad, et Google võtab turvalisust väga tõsiselt, pole maailmas ühtegi ettevõtet, mis oleks kaitstud andmetega seotud rikkumiste eest. Kui võti, mida Google teie rakenduse levitamiseks allkirjastamiseks kasutab, on ühes neist rikkumistest, saab igaüks teie rakenduse versiooni allkirjastada ja jätta selle mulje, nagu oleks selle allkirjastanud teie. Ja mõned arendajad ja turvaeksperdid pole selle võimalusega rahul. See on väga-väga väike võimalus, jah, kuid asjaolu, et see võimalus üldse on, hirmutab mõnda infoseci kogukonnas.
Kui arendajad allkirjastavad Androidi APK-d, siis igaüks saab APK-sid Google Playst kinnitada. Pime usaldus pole vajalik. See on elegantne disain, mis tagab kontrollitava turvalisuse. App Bundle'id pööravad selle pea peale ja näivad olevat üles ehitatud nii, et need soodustavad müüja lukustumist. On palju alternatiivseid tehnilisi lähenemisviise, mis pakuvad väikeseid APK-sid, mille arendajad on endiselt allkirjastanud, kuid need ei eelistaks Play. Näiteks võib arendaja kõik APK variandid luua ja allkirjastada ning seejärel laadida üles mis tahes rakenduste poodi.
Kindlasti tuleb arutleda selle üle, kas parem on jätta privaatvõtmete turvaline hoidmine Google'i või üksikute arendajate hoolde. Kuid need arendajad (tõenäoliselt) ei kasuta tavaliselt oma võtmete jaoks keskset hoidlat. Sundides arendajaid kasutama Play App Signingut, peab pahatahtlik ründaja tuhandete või miljonite võtmete hankimiseks Google'i turvalisust rikkuma vaid üks kord.
Mida see väärt on, ütleb Google selle kohta, kuidas ta oma infrastruktuuris teie allkirjastamisvõtit kaitseb:
[blockquote author="Wojtek Kaliciński, Google'i Androidi arendaja advokaat"]Kui kasutate Play rakenduse allkirjastamist, salvestatakse teie võtmed samasse infrastruktuuri, mida Google kasutab oma võtmete salvestamiseks.
Võtmejuurdepääsu reguleerivad kõigi toimingute jaoks ranged ACL-id ja võltsimist tuvastavad kontrolljäljed.
Kõik arendaja võtmega loodud ja allkirjastatud artefaktid tehakse teile Google Play Console'is kontrollimiseks/atesteerimiseks kättesaadavaks.
Lisaks varundame võtmete kadumise vältimiseks oma esmasest salvestusruumist väga sageli. Need varukoopiad on tugevalt krüptitud ja me testime regulaarselt nendest varukoopiatest taastamist.
Kui soovite saada teavet Google'i tehnilise infrastruktuuri kohta, lugege Google'i pilveturbe valged paberid.[/blockquote]
Nii suurepärased kui ka kõik helid, on kadumine ja vargus siiski võimalik. Ja kontrolljäljed aitavad ainult tulevasi ründeid ennetada; nad ei saa purustatud võtmeid tagasi.
Volitamata muudatuste võimalus
Üks suur probleem, kuidas Google on App Bundle'i seadistanud, on võimalus, et rakendusse võidakse lisada volitamata muudatusi. App Bundle'ist APK-de ekstraktimise protsess hõlmab oma olemuselt muudatusi, kuna Google peab iga APK käsitsi looma. Kuigi Google on lubanud, et ta ei sisesta ega hakka koodi sisestama ega muutma, on App Bundle'i protsessi probleem selles, et see suudab seda teha.
Siin on paar näidet selle kohta, mida Google'i positsioonil olev ettevõte suudab teha:
Oletame, et on olemas turvaline sõnumsiderakendus, mida inimesed kasutavad suhtlemiseks ilma valitsuse järelevalveta. See võib olla uskumatult kasulik tööriist inimestele, kes protesteerivad autoritaarse valitsuse vastu, või isegi inimestele, kes tahavad lihtsalt oma privaatsust säilitada. See valitsus, kes soovib näha, mida rakenduse kasutajad räägivad, võiks sundida Google'it lisama rakenduse koodile valve tagaukse.
See näide on natuke kahjutum, kuid see puudutab ka mõnda inimest. Oletame, et on olemas rakendus, mida laaditakse päevas miljoneid allalaadimisi, kuid selles pole reklaame ega analüüse. See on tohutu andmeallikas, millel pole võimalust neile andmetele juurde pääseda. Google, kes on reklaamiettevõte, võib soovida neile andmetele juurde pääseda.
Rakenduste levitamise klassikalises APK mudelis ei saa Google rakendusi muuta ilma allkirja muutmata. Kui Google muudab allkirja, eriti populaarse rakenduse puhul, märkavad inimesed seda, kuna värskendust ei installita. Kuid rakenduste komplektide ja rakenduste allkirjastamise abil saab Google enne nende levitamist rakendustesse vaikselt oma koodi sisestada. Allkiri ei muutu, kuna Google'ile kuuluks allkirjastamisvõti.
Et oleks selge, need näited on uskumatult ebatõenäolised. Google kipub lihtsalt tülikatelt turgudelt üldse välja tõmmata, mitte kohaneda. Kuid kuigi see on ebatõenäoline, on see siiski võimalik. See, et ettevõte lubab, et midagi ei juhtu, ei garanteeri seda.
Koodi läbipaistvus
Neid muresid kuuldes tutvustas Google sel nädalal uut funktsiooni nimega App Bundle'i koodide läbipaistvus. Koodi läbipaistvus võimaldab arendajal sisuliselt luua teise allkirja, mis tarnitakse koos rakendusega kasutajatele. See lisasignatuur tuleks luua eraldi privaatvõtmega, millele on juurdepääs ainult arendajal. Sellel meetodil on siiski mõned piirangud.
Koodi läbipaistvus hõlmab ainult koodi. See võib nime järgi tunduda ilmselge, kuid see tähendab ka, et see ei lase kasutajatel kontrollida ressursse, manifesti ega midagi muud, mis pole DEX-fail või omateek. Kuigi mittekoodifailide pahatahtlikud muudatused mõjutavad tavaliselt palju vähem, on see siiski rakenduse turvalisuses auk.
Teine koodi läbipaistvuse probleem on see, et puudub loomupärane kinnitamine. ühe jaoks see on valikuline funktsioon, nii et arendajad peavad meeles pidama selle lisamist iga uue üleslaaditava APK jaoks. Praegu tuleb seda teha käsurealt ja versiooniga bundletool mida Android Studioga kaasas ei ole. Isegi kui arendaja selle kaasab, ei ole Androidil sisseehitatud mingit kinnitust, mis kontrolliks, kas Code Transparency manifest vastab rakenduse koodile.
Lõppkasutaja peab ise kontrollima, võrreldes manifesti arendaja pakutava avaliku võtmega või saates APK arendajale kinnitamiseks.
Kuigi koodi läbipaistvus võimaldab kinnitada, et rakenduse koodi ei muudeta, ei hõlma see rakenduse muude osade kinnitamist. Protsessi vastu puudub ka loomupärane usaldus. Võite väita, et kui te Google'it ei usalda, olete tõenäoliselt iseseisva kontrollimise ülesande kõrgusel, kuid miks peaksite seda tegema?
Koodi läbipaistvuse funktsiooniga on muid probleeme, nagu välja toodud autor Mark Murphy alates CommonsWare. Soovitan selle funktsiooni põhjalikumaks analüüsiks lugeda tema artiklit.
Arendaja mugavus ja valik
Kolmas (ja selle artikli jaoks viimane) põhjus, miks mõned arendajad App Bundle'iga vaidlustavad, on vähenenud mugavus ja valikuvõimalus.
Kui arendaja teeb Play poes uue rakenduse pärast seda, kui Google hakkab App Bundle'i nõudma ja ta valib vaikevalik lubada Google'il allkirjastamisvõtit hallata, ei ole neil kunagi juurdepääsu sellele allkirjastamisele võti. Kui sama arendaja soovib seda rakendust teises rakenduste poes levitada, peavad nad kasutama oma võtit, mis ei ühti Google'i omaga.
See tähendab, et kasutajad peavad installima ja värskendama Google Playst või kolmandate osapoolte allikatest. Kui nad soovivad allikat muuta, peavad nad rakenduse täielikult desinstallima, mis võib kaotada andmed, ja uuesti installima. APK koondajatele meeldib APKMirror peab siis tegelema ka mitme ametliku allkirjaga sama rakenduse jaoks. (Tehniliselt peavad nad seda juba tegema, sest rakenduse allkirjastamine võimaldab teil luua uutele kasutajatele uue turvalisema võtme, kuid see on nende ja teiste saitide jaoks halvem, kui kõik on seda teha.)
Google'i vastus sellele probleemile on kasutada Play Console'is App Bundle'i uurijat või Artefact Explorerit, et laadida üleslaaditud komplektist saadud APK-d alla. Sarnaselt koodi läbipaistvusele pole see täielik lahendus. Play Console'ist alla laaditud APK-d jagatakse erinevate seadmeprofiilide jaoks. Kuigi Play Console toetab ühe rakenduse ühe versiooni jaoks mitme APK üleslaadimist, ei toeta paljud teised levituskanalid seda.
Seega kaovad paljud App Bundle'i kasutamise eelised, kui arendajad haldavad mitut poodi, muutes levitamise keerulisemaks. Selle uudisega Windows 11 on Androidi rakenduste toe saamine tänu Amazon Appstore'ile usuvad mõned, et rakenduste komplektide nõue ei tõuka arendajaid Amazonis levitamast. Loomulikult on Google'i esmane mure oma rakenduste poe pärast, kuid see on täpselt see maandas nad koos konkurentidega kuuma vette suunates neid tegema väikesed, leplikud muudatused kuidas kolmanda osapoole rakenduste poed Androidis töötavad.
Paar mitme kauplusega seotud probleemi on rakenduste ühenduvus ja kiirtestimine.
Alustame rakenduste ühendamisest. Kas olete kunagi alla laadinud rakenduse, mis lukustab funktsioonid tasulise seina taha? Peaaegu kindlasti. Mõned arendajad panevad funktsioonid rakendusesisese ostu taga, kuid teised võivad valida eraldi tasulise rakenduse. Kui see lisandmoodul installitakse, avatakse rakenduse põhifunktsioonid.
Kuid mis takistab kellelgi lihtsalt piraatallikast pärit lisandmoodulit installimast? Noh, arendajatele on palju võimalusi, kuid vähemalt üks hõlmab allkirjaga kaitstud õiguste kasutamist. Oletame, et põhirakendus deklareerib allkirjaga kaitstud loa. Seejärel teatab lisandmoodul, et soovib seda luba kasutada. Ideaalis on lisarakendusel ka mingisugune litsentsi kinnitamise funktsioon, mis loob Interneti-ühenduse, et veenduda kasutaja seaduslikkuses.
Kui mõlemal rakendusel on sama allkiri, annab Android lisarakendusele loa ja piraatluskaitse kontroll läbib. Kui lisandmoodulil pole õiget allkirja, siis luba ei anta ja kinnitamine ebaõnnestub.
Klassikalise APK levitamismudeliga saab kasutaja hankida kummagi rakenduse mis tahes seaduslikust allikast ja sellega hakkama saada. Praeguse App Bundle'i vaikemudeli korral ei ühti põhi- ja lisarakenduse allkirjad. Google teeb iga rakenduse jaoks ainulaadse võtme. Arendaja võib alati loobuda allkirjaga kaitstud loa kasutamisest ja kasutada otsest allkirja räsikontrolli, kuid see on palju vähem turvaline.
Ja siis on kiirtestimine. Kasutajad saadavad arendajatele pidevalt e-kirju nende rakendustes esinevate probleemide kohta. Mõnikord on need probleemid lihtsad: taastootke probleem, leidke probleem, parandage see ja laadige üles uus versioon. Kuid mõnikord nad ei ole. Mõnikord ei saa arendajad probleemi taasesitada. Nad saavad parandada selle, mis nende arvates on probleem, kuid seejärel peab kasutaja seda testima. Oletame nüüd, et kasutaja installis rakenduse Google Play kaudu.
APK mudeliga saab arendaja mõnda koodi muuta, luua ja allkirjastada uue APK ning saata selle kasutajale testimiseks. Kuna test-APK allkiri ühtib kasutaja installitud signatuuriga, on seda lihtne värskendada, testida ja aru anda. App Bundle'iga läheb see laiali. Kuna Google allkirjastab APK, mille kasutaja algselt installis, ei ühti see arendaja saadetud APK allkirjaga. Kui see rakendus avaldatakse pärast App Bundlesi tähtaega, pole arendajal isegi juurdepääsu võtmetele, mida Google kasutab. Testimiseks peab kasutaja enne testversiooni installimist praeguse rakenduse desinstallima.
Siin on hunnik probleeme. Esiteks on ebamugavused nii arendaja kui ka kasutaja poolel. Rakenduse desinstallimine lihtsalt paranduse testimiseks ei ole lõbus. Ja mis siis, kui probleem kaob? Kas põhjuseks olid arendaja tehtud muudatused või see, et kasutaja kustutas rakenduse andmed? Play poes on küll sisetestimine, mis peaks laskma arendajatel teha kiireid koostamisi ja levitamist, kuid see nõuab kasutajalt esmalt väljalaskeversiooni desinstallimist. See ei paranda tegelikult midagi.
Kui see kõik kõlab kui hüpoteetiline jama, siis siin on väga ehe näide arendajast, kellel tekivad need probleemid, kui nad lasevad Google'il nende jaoks privaatvõtme genereerida: João Dias. Ta on Taskeri arendaja koos terve hulga pistikprogrammide, sealhulgas AutoAppsi komplektiga. Uue App Bundle'i nõude tõttu võib João arendustsükkel muutuda palju keerulisemaks, vähemalt uute rakenduste puhul. Testversioonide otse saatmine on vähem mugav. Litsentside kontrollimine on vähem tõhus.
See võib tunduda pisut äärmusliku juhtumina, kuid see ei tähenda, et João oleks väike arendaja ja tõenäoliselt pole ta üksi. Play poes on palju rakendusi, mis tuginevad ebaseaduslike kasutajate tuvastamiseks allkirjade kinnitamisele.
Loomulikult on need probleemid vähemalt mõnevõrra leevendunud, kui arendajad saavad oma allkirjastamisvõtmed Google'isse üles laadida. Kuid arendajad peavad iga rakenduse jaoks selle valiku lubama. Kui nad seda ei tee, siis ühendamine ebaõnnestub ja kiirtoe tugi nõuab enne kasutajale õige saatmist kogumi Google'isse üleslaadimist ja APK-de loomist. Lisaks tähendab see siiski, et nad peavad oma privaatvõtit jagama, mis toob meid tagasi varem käsitletud probleemide juurde.
Lahendused
See on vana probleem, kuna App Bundle'i nõuded avaldati kuid tagasi, seega on vahepeal välja pakutud üsna palju lahendusi.
Üks lahendus on vältida Play rakenduse allkirjastamise vajadust. Selle asemel, et luua App Bundle'i, mida Google seejärel APK-deks ja märkideks töötleb, võib selle töötlemise teha Android Studio. Seejärel saavad arendajad lihtsalt laadida üles ZIP-faili, mis on täis kohalikult allkirjastatud APK-sid iga konfiguratsiooni jaoks, mille Google oleks loonud.
Selle lahendusega ei vajaks Google üldse juurdepääsu arendajate võtmetele. Protsess oleks väga sarnane klassikalise APK levitamismudeliga, kuid hõlmaks ühe asemel mitut väiksemat APK-d.
Teine lahendus on lihtsalt mitte nõuda App Bundle'ide kasutamist ja lubada arendajatel jätkuvalt kohalikult allkirjastatud APK-sid üles laadida. Kuigi App Bundles võib kasutajale paljudel juhtudel paremaks kasutuskogemuseks, mõned rakendused ei saa tegelikult kasu, kui need on konfiguratsioonipõhiselt jagatud minimaalse suurusega vähendamine.
Kui Google rakendas mõlemad lahendused, ei pea arendaja, kes soovib kasutada App Bundle'i Google'iga üle logides ja arendaja, kelle rakendus vormingust palju kasu ei saa, ei pea seda kasutama kõik.
Google'i vastused
Enda allkirjastamine
Kui neilt esimest korda küsiti, kas lubada arendajatel App Bundle'i jaoks allkirjastada, oli Google'i vastus väga mittekohustav:
[blockquote author=""]Niisiis rääkisin lühidalt nõudest, et järgmisel aastal uued rakendused peavad kasutama rakenduste komplekte, ja üks asi, mis sellega kaasneb, on see, et laiemalt nõuame Play rakenduse allkirjastamist. Seega peavad arendajad kas looma Plays rakenduse allkirjastamise võtme või laadima Playsse üles oma võtme… kuna see on rakenduse kogumite eeltingimus. Oleme arendajatelt kuulnud, et mõned neist lihtsalt ei taha seda teha. Nad ei taha, et võtmeid haldaks Play. Ja praegu pole see võimalik, kui soovite kasutada rakenduse kogumeid.
Kuid me oleme seda tagasisidet kuulnud ja… ma ei saa praegu millestki rääkida, meil pole midagi teatada, kuid me uurime, kuidas saaksime mõnda neist muredest leevendada. See ei pea tingimata võimaldama kimpude üleslaadimise ajal oma võtit alles hoida. Uurime erinevaid võimalusi. Meil lihtsalt ei ole praegu lahendust välja kuulutada. Kuid meil on veel umbes aasta aega nõude täitmiseni, nii et ma loodan väga, et saame selle jaoks arendajatele vastuse.[/blockquote]
See oli eelmise aasta novembri lõpus ja tundub, et midagi pole juhtunud. Vaid paar kuud on jäänud enne Rakenduse kogumite nõue jõustub, ei ole arendajatel ikka veel võimalust oma rakenduste allkirjastamisega hakkama saada. Kuigi Google on nüüd võimaldanud Laadi üles oma võti nii uute kui ka olemasolevate rakenduste jaoks, see võtab siiski allkirjastamise osa arendaja käest.
Koodi muudatused
Kuigi Google on konkreetselt lubanud, et Play pood ei muuda rakenduse koodi, ei ole lubadus garantii. Rakenduste kogumite ja rakenduste allkirjastamise puhul pole meile teadaolevaid tehnilisi piiranguid, mis takistaksid Google'il üleslaaditud rakendusi enne levitamist muutmast.
Google on tutvustanud Koodi läbipaistvus valikulise funktsioonina ja kuigi see aitab mõnevõrra, on sellel omajagu probleeme, nagu me varem arutasime.
Isetehtud kimbud
Kui Google'ilt küsiti, kas lubada arendajatel luua oma rakenduste komplekte (lõigatud APK-sid sisaldavad ZIP-id), vastati põhimõtteliselt "me ei kavatse seda teha".
Tõenäoliselt mitte nii, nagu küsimuses kirjeldatud, kuna see muudaks avaldamisprotsessi arendajatele veelgi keerulisemaks ja tegelikult tahame seda lihtsamaks ja turvalisemaks muuta. Kuid jällegi oleme seda tagasisidet kuulnud ja uurime võimalusi, kuidas see võimalikuks teha, kuid tõenäoliselt mitte nii, nagu siin kirjeldatud.
Huvitaval kombel tundub Google’i põhjendus olevat, et see muudaks avaldamise keerulisemaks. Google võib siiski Android Studio APK genereerimise dialoogi osana protsessi automatiseerida. Veelgi enam, kui kõnealust rakendust levitatakse mitmes poes, teeks see tegelikult avaldamisprotsess on lihtsam, kuna arendajad ei peaks haldama mitut allkirjastamisvõtit ja kaebusi kasutajad.
Ja koodi läbipaistvuse kasutuselevõtuga tundub, et komplikatsioon pole siiski probleem. Koodi läbipaistvus nõuab vähemalt praegu, et arendaja kasutaks käsurea tööriista ja kasutajad kontrolliksid selgelt pakutava rakenduse kehtivust. See on keerulisem kui kimpude isevalmistamise protsess ja pole selge, miks Google seda lahendust eelistab.
Läheb edasi
App Bundle'id on alates 1. augustist Google Playsse saadetavate uute rakenduste jaoks nõutav levitamisvorming. Kuigi Google on enamiku arendajate ja turvaekspertide tõstatatud probleemidega vähemalt mõnevõrra tegelenud, jätavad vastused palju soovida. App Bundle'il kui järgmise põlvkonna levitusvormingul on palju ilmseid eeliseid, kuid Google'ile rakenduste allkirjastamise osalise või täieliku kontrolli andmine tekitab alati muret.
Google'i vastuseid ja jõupingutusi hinnatakse kindlasti, kuid mõned, nagu Mark Murphy, tunnevad, et nad pole piisavalt kaugele jõudnud. Kuna selliseid lahendusi nagu isetehtud paketid ei rakendata ja Android App Bundle'i tähtaeg on kiire lähenedes ei paista, et Google Play arendajad suudavad pikka aega oma rakenduste üle täielikku kontrolli säilitada kauem.
Android App Bundle'i nõude tagajärgedest räägime hiljem täna pärastlõunal Twitteri ruumis, nii et liituge meiega!