Google Play pakottaa kehittäjät pian lataamaan App Bundle -paketteja APK: iden sijaan, mikä herättää epämukavia turvallisuuskysymyksiä vaatimuksesta.
Viime marraskuussa, Google ilmoitti että kehittäjien on julkaistava uudet sovellukset Play Kaupassa Android App Bundle (AAB) -muodossa APK: n sijaan. Juuri toissapäivänä Google muistutti kehittäjiä tästä tulevasta vaatimuksesta ja käynnisti kiistan myrskyn. käyttäjiltä, jotka uskovat, että Google tappaa APK: ita, eliminoi sivulatauksen, estää kolmannen osapuolen sovelluskauppoja ja mitäpä.
On totta, että Android App Bundle -paketit ovat melko suuri ero perinteisestä APK-muodosta, johon saatat tottua, sekä käyttäjänä että kehittäjänä. Vaikka App Bundle -pakettien käyttämisessä on monia etuja, niiden tekemisessä on yksi keskeinen näkökohta, josta jotkut kehittäjät ja tietoturvaasiantuntijat ovat oikeutetusti huolissaan.
Tässä artikkelissa käsittelemme Android App Bundle -paketteihin siirtymistä kohtaan näkemäämme kritiikkiä sekä joitakin ehdotettuja ratkaisuja, ja puhumme myös Googlen ehdottamasta ratkaisusta näihin ongelmiin.
Tausta
Ennen kuin tämä tapahtuu, meidän on kuitenkin puhuttava hieman siitä, kuinka sovellusten jakelu toimii Androidilla yleisesti. Jos tiedät jo, kuinka sovellusten allekirjoittaminen ja sovelluspaketit toimivat, voit ohittaa tämän osan.
APK: t
Suurimmaksi osaksi Android-sovellukset jaetaan APK-tiedostojen sisällä. APK sisältää kaiken sovelluksen koodin ja resurssit sekä joitakin suojausominaisuuksia, kuten allekirjoitusluettelon. Kun APK asennetaan, se periaatteessa vain kopioidaan tiettyyn kansioon ja lisätään asennettujen sovellusten sisäiseen tietokantaan.
Allekirjoitukset
Asennuksen aikana sovelluksen allekirjoitus varmistetaan myös sen oikeellisuuden varmistamiseksi. Jos sovellus on jo asennettu, Android vertaa uuden sovelluksen allekirjoitusta jo asennettuun sovellukseen. Jos allekirjoitus ei ole kelvollinen tai se ei täsmää, Android kieltäytyy asentamasta sovellusta.
Tämä allekirjoituksen tarkistus on tärkeä osa Androidin turvallisuutta. Se varmistaa, että asentamasi sovellus on kelvollinen ja vähintään samasta lähteestä kuin se, jonka olet jo asentanut. Jos asennat esim. Lockscreen Widgets -sovellukseni Play Kaupasta, voit olla melko varma, että olen allekirjoittanut sen ja että se on aito. Jos yrität sitten asentaa päivityksen Lockscreen Widgets -sovellukseen joltain hämärältä kolmannen osapuolen sivustolta, mutta se epäonnistuu, tiedät, että joku on peukaloinut kyseistä APK: ta, mahdollisesti lisätäkseen haittaohjelmia.
Sovelluksen allekirjoittamiseen käytetty avain on (mieluiten) ei koskaan julkisesti julkaistu. Tämä tunnetaan yksityisenä avaimena. Yksityistä avainta käytetään sitten luomaan sovelluksen allekirjoituksessa näkyvä avain, joka tunnetaan nimellä julkista avainta. Tätä Android ja sovelluskaupat käyttävät sovelluksen kelvollisuuden vahvistamiseen. En käsittele sitä, kuinka tarkalleen voit luoda julkisen avaimen paljastamatta yksityistä avainta, koska siihen liittyy paljon salausmatematiikkaa. Jos haluat lisätietoja, tutustu Googlen dokumentaatio APK: iden allekirjoittamisesta tai tee tutkimusta yksisuuntaisista matemaattisista funktioista.
Toinen sovellusten allekirjoitusten ominaisuus on mahdollisuus rajoittaa käyttöoikeudet vain sovelluksiin, joilla on vastaavat allekirjoitukset. Android tekee tämän sisäisesti monille toiminnoille, joissa vain kehyksen kanssa samalla avaimella allekirjoitetut sovellukset voivat käyttää tiettyjä ominaisuuksia.
Sovelluspaketit
Nyt kun olemme antaneet nopean yleiskatsauksen APK: ista ja allekirjoituksista, puhutaanpa App Bundleista. Tässä APK-resurssit tulevat käyttöön. Resursseja ovat esimerkiksi ulkoasut, kuvat, ääni jne. Periaatteessa ne ovat kaikkea, mikä ei ole koodia. Tukeakseen paremmin erilaisia näyttökokoonpanoja ja eri kieliä kehittäjät voivat tehdä samasta resurssista useita versioita, joita käytetään laitteesta ja kielestä riippuen.
Mutta APK: ssa kaikki nämä resurssit ovat olemassa riippumatta siitä, mitä käytät. Ja ne vievät tilaa. Sovelluksesi monimutkaisuudesta riippuen monille laitteille voi olla paljon käyttämättömiä resursseja. Tämä on se, mitä App Bundle -paketit on tehty ratkaisemaan. Kehittäjät voivat luoda App Bundlen kuten APK: n, ja sen jälkeen App Bundle voidaan ladata Play Kauppaan, aivan kuten APK voi.
Google käyttää sitten tätä App Bundlea luodakseen joukon erilaisia APK: ita eri laitekokoonpanoille. Jokainen App Bundle sisältää vain kyseiseen määritykseen tarvittavat resurssit. Kun käyttäjä lataa sovelluksen, hänelle tarjotaan luotu APK, joka vastaa hänen määrityksiään. Tämä auttaa vähentämään sekä sovellusten lataus- että asennuskokoja, mikä säästää kaistanleveyttä ja tallennustilaa.
Tietenkin laitteellesi sopivan APK: n asentaminen tarkoittaa, että sinun on vaikeampaa kopioida se toiseen laitteeseen ja asentaa se ilman ongelmia. Näkökulmastasi riippuen tämä voi olla hyvä tai huono asia. Toisaalta se vaikeuttaa piratismia, koska käyttäjillä ei ole enää koko sovellusta. Toisaalta se vaikeuttaa sovellusten laillista arkistointia samasta syystä.
Sovelluksen allekirjoittaminen
Koska Android App Bundle -paketit eivät ole APK: ita, et voi vain avata AAB-tiedostoa ja asentaa sitä suoraan laitteeseen. Kun lataat sellaisen Play Kauppaan, Google käyttää pakettia erilaisten (allekirjoittamattomien) APK-tiedostojen luomiseen. Nämä APK: t on sitten allekirjoitettava, ennen kuin ne voidaan asentaa.
Sen sijaan, että Google pyytäisi kehittäjää allekirjoittamaan ja lataamaan luodut APK: t uudelleen, Google hallinnoi allekirjoitusta itse. Play Kauppa joko käyttää uutta luomaansa avainta tai pyytää kehittäjältä allekirjoitukseen käyttämänsä avaimen APK: t. Kummallakin vaihtoehdolla Google hoitaa kehittäjän julkisen allekirjoituksen ja tarjoaa latauksen avain. Google käyttää latausavainta sisäiseen vahvistukseen ja varmistaa, että kehittäjän lataama App Bundle (tai joissain tapauksissa APK) on oikea.
Jos lähetysavain vaarantuu tai katoaa, kehittäjät voivat pyytää uutta, ja sovelluksen jakeluun käytetty allekirjoitusavain pysyy muuttumattomana.
Sovelluksen allekirjoittamiseen liittyy paljon muutakin, mutta tämä liittyy tähän artikkeliin. Jos haluat, voit lukea lisää App Bundleista ja App Signing on -sovelluksesta tämä Wojtek Kalicińskin Medium-artikkeli.
Kritiikkiä
Teoriassa ja käytännössä App Bundle -paketit ovat melko mahtavia. Ne vähentävät tiedon käyttöä ja asennuskokoa ilman, että käyttäjän tarvitsee tehdä mitään. Mutta sen käyttöönoton vuoksi jotkut kehittäjät ja tietoturvatutkijat ovat viime kuukausina ilmaisseet huolensa. Ennen kuin teen yhteenvedon näistä huolenaiheista, haluan sanoa, että suurin osa alla kirjoitetusta on suoraan artikkelisarjan perusteella kehittäjä Mark Murphy CommonsWare. Sinun kannattaa ehdottomasti tarkistaa hänen artikkelinsa, koska ne tarjoavat enemmän yksityiskohtia ja kritiikkiä kehittäjän näkökulmasta.
Turvallisuus
Klassisessa jakelumallissa kehittäjä pitää APK: n allekirjoittamiseen käyttämänsä avaimen yksityisenä. Sitä ei koskaan jaeta yleisölle, ja vain valtuutetuilla henkilöillä pitäisi olla pääsy siihen. Tämä varmistaa, että vain kyseiset ihmiset voivat luoda kelvollisen APK: n.
Mutta jos käytät App Bundle -paketteja Play Kaupassa, Google hallinnoi avainta, joka allekirjoittaa käyttäjien vastaanottamat APK: t. The oletuksena Google Playhin ladattujen uusien sovellusten käyttäytyminen elokuuta 2021 alkaen on Googlen tehtävä luoda oma jakeluavaimensa, jonka se pitää yksityisenä kehittäjältä.
Kehittäjät lähettävät uusia sovelluksia Google hallinnoi heidän yksityistä avaimensa oletuksena, vaikka kehittäjät lähettävätkin päivityksiä olemassa olevia sovelluksia voi jatkaa APK: iden käyttöä tai he voivat siirtyä AAB-jakeluun luomalla uuden avaimen, jota Google käyttää uusille käyttäjille. Olemassa olevat sovellukset ei vaadita vaihtaa APK-jakelusta Android App Bundle -paketteihin, vaikka tämä vaihtoehto on heidän valittavissaan. Hetken takaiskun jälkeen Google tekee sen jopa mahdolliseksi ladataksesi oman yksityisen avaimesi Googlea varten kirjautumista varten sekä uusille että olemassa oleville sovelluksille. Mikään näistä tilanteista ei ole ihanteellinen, sillä Googlella on kuitenkin pääsy yksityiseen avaimesi, jos haluat käyttää Android App Bundle -paketteja (eikä kehittäjillä ole tässä asiassa vaihtoehtoa, jos he haluavat lähettää uuden sovelluksen elokuun jälkeen 2021!)
Vaikka olemme varmoja siitä, että Google suhtautuu tietoturvaan erittäin vakavasti, maailmassa ei ole yritystä, joka olisi suojassa tietomurroilta. Jos avain, jolla Google allekirjoittaa sovelluksesi jakelua varten, on jossakin näistä rikkomuksista, kuka tahansa voi allekirjoittaa sovelluksesi version ja saada sen näyttämään sinun allekirjoittamalta. Ja jotkut kehittäjät ja tietoturvaasiantuntijat eivät ole tyytyväisiä tähän mahdollisuuteen. Se on hyvin, hyvin pieni mahdollisuus, kyllä, mutta tosiasia, että se on mahdollista, pelottaa joitain infosec-yhteisössä.
Jos kehittäjät allekirjoittavat Android APK: t, kuka tahansa voi vahvistaa APK: t Google Playsta. Sokeaa luottamusta ei vaadita. Se on tyylikäs muotoilu, joka tarjoaa todennettavissa olevan turvallisuuden. Sovelluspaketit kääntävät sen päälaelleen, ja ne näyttävät rakenteeltaan edistävän toimittajan lukitusta. On olemassa monia vaihtoehtoisia teknisiä lähestymistapoja, jotka tarjoavat pieniä kehittäjien allekirjoittamia APK: ita, mutta ne eivät suosisi Playta. Esimerkiksi kehittäjä voi luoda ja allekirjoittaa kaikki APK-muunnelmat ja ladata ne sitten mihin tahansa sovelluskauppaan.
Argumentteja voidaan varmasti esittää siitä, onko parempi jättää yksityisten avainten turvallinen säilytys Googlen vai yksittäisten kehittäjien käsiin. Mutta nuo kehittäjät (todennäköisesti) eivät yleensä käytä avaimilleen keskusvarastoa. Pakottamalla kehittäjät käyttämään Play App Signingia, haitallisen hyökkääjän tarvitsee vain rikkoa Googlen tietoturvaa kerran saadakseen tuhansia tai miljoonia avaimia.
Mitä se kannattaa, tässä on mitä Google sanoo siitä, kuinka se suojaa allekirjoitusavaimesi infrastruktuurissaan:
[blockquote author="Wojtek Kaliciński, Android Developer Advocate at Google"]Kun käytät Play App Signingia, avaimesi tallennetaan samaan infrastruktuuriin, jota Google käyttää omien avaimiensa tallentamiseen.
Avainten pääsyä säätelevät tiukat ACL-luettelot ja peukaloituvat kirjausketjut kaikille toimille.
Kaikki kehittäjän avaimella luodut ja allekirjoitetut artefaktit ovat saatavillasi Google Play Consolessa tarkastettaviksi/todistettavaksi.
Lisäksi avainten katoamisen estämiseksi teemme erittäin usein varmuuskopioita ensisijaisesta tallennustilastamme. Nämä varmuuskopiot ovat vahvasti salattuja, ja testaamme säännöllisesti palautusta näistä varmuuskopioista.
Jos haluat lisätietoja Googlen teknisestä infrastruktuurista, lue Google Cloud Security Whitepapers.[/lohkolainaus]
Niin hienoa kuin kaikki äänet, katoaminen ja varkaus ovat silti mahdollisia. Ja kirjausketjut vain auttavat estämään tulevat hyökkäykset; he eivät saa rikottuja avaimia takaisin.
Luvattomien muutosten mahdollisuus
Yksi suuri ongelma Googlen sovelluspakettien määrittämisessä on mahdollisuus, että sovellukseen voidaan lisätä luvattomia muutoksia. APK: iden purkamiseen App Bundlesta liittyy luonnostaan muutoksia, koska Googlen on luotava jokainen APK manuaalisesti. Sillä aikaa Google on luvannut, että se ei lisää eikä tule lisäämään tai muokkaamaan koodia, App Bundle -prosessin ongelma on, että sillä on valtuudet tehdä niin.
Tässä on pari esimerkkiä siitä, mitä Googlen asemassa olevalla yrityksellä on valta tehdä:
Oletetaan, että on olemassa turvallinen viestintäsovellus, jota ihmiset käyttävät viestimiseen ilman valtion valvonnan riskiä. Tämä voi olla uskomattoman hyödyllinen työkalu ihmisille, jotka protestoivat autoritaarista hallitusta vastaan, tai jopa ihmisille, jotka haluavat vain säilyttää yksityisyytensä. Tämä hallitus, joka haluaa nähdä, mitä sovelluksen käyttäjät sanovat, voisi yrittää pakottaa Googlen lisäämään valvonnan takaoven sovelluksen koodiin.
Tämä esimerkki on hieman vaarattomampi, mutta se on myös jotain, joka huolestuttaa joitain ihmisiä. Oletetaan, että on olemassa sovellus, joka saa miljoonia latauksia päivässä, mutta siinä ei ole mainoksia tai analytiikkaa. Se on valtava tietolähde, johon ei ole mahdollista päästä käsiksi. Mainosyrityksenä Google saattaa haluta käyttää näitä tietoja.
Sovellusten jakelun perinteisessä APK-mallissa Google ei voi muokata sovelluksia muuttamatta allekirjoitusta. Jos Google muuttaa allekirjoitusta varsinkin suositussa sovelluksessa, ihmiset huomaavat sen, koska päivitys ei asennu. Mutta App Bundlesin ja App Signingin avulla Google pystyi hiljaa syöttämään oman koodinsa sovelluksiin ennen niiden jakamista. Allekirjoitus ei muuttuisi, koska Google omistaisi allekirjoitusavaimen.
Selvyyden vuoksi nämä esimerkit ovat uskomattoman epätodennäköisiä. Google yleensä yksinkertaisesti vetäytyä hankalilta markkinoilta kokonaan, eikä sopeutua. Mutta vaikka se on epätodennäköistä, se on silti mahdollista. Se, että yritys lupaa, että jotain ei tapahdu, ei takaa sitä.
Koodin läpinäkyvyys
Google, kuultuaan nämä huolenaiheet, esitteli tällä viikolla uuden ominaisuuden nimeltä Sovelluspakettien koodin läpinäkyvyys. Code Transparency mahdollistaa sen, että kehittäjä voi käytännössä luoda toisen allekirjoituksen, joka toimitetaan sovelluksen mukana käyttäjille. Tämä ylimääräinen allekirjoitus tulisi luoda erillisestä yksityisestä avaimesta, johon vain kehittäjällä on pääsy. Tällä menetelmällä on kuitenkin joitain rajoituksia.
Code Transparency kattaa vain koodin. Tämä saattaa tuntua itsestään selvältä nimen perusteella, mutta se tarkoittaa myös, että se ei anna käyttäjien vahvistaa resursseja, luetteloa tai mitään muuta, joka ei ole DEX-tiedosto tai alkuperäinen kirjasto. Vaikka ei-kooditiedostojen haitallisilla muokkauksilla on yleensä paljon vähemmän vaikutusta, se on silti aukko sovelluksen suojauksessa.
Toinen koodin läpinäkyvyyteen liittyvä ongelma on, että siinä ei ole luontaista vahvistusta. Yhdelle, se on valinnainen ominaisuus, joten kehittäjien on muistettava sisällyttää se jokaiseen lataamaansa uuteen APK: hen. Tällä hetkellä se on tehtävä komentoriviltä ja versiolla bundletool jota ei tule Android Studion mukana. Vaikka kehittäjä sisällyttää sen, Androidissa ei ole sisäänrakennettua vahvistusta sen tarkistamiseksi, että Code Transparency -luettelo vastaa sovelluksen koodia.
Loppukäyttäjän tehtävänä on tarkistaa itse vertaamalla manifestia kehittäjän tarjoamaan julkiseen avaimeen tai lähettämällä APK kehittäjälle vahvistusta varten.
Vaikka Code Transparency mahdollistaa vahvistuksen, ettei sovelluksen koodia ole muokattu, se ei sisällä minkäänlaista vahvistusta sovelluksen muille osille. Prosessiin ei myöskään liity luontaista luottamusta. Voisit väittää, että jos et luota Googleen, voit luultavasti vahvistaa itsenäisesti, mutta miksi sinun pitäisi tehdä?
Code Transparency -ominaisuuteen liittyy muita ongelmia, kuten huomautti Kirjailija: Mark Murphy CommonsWare. Suosittelen lukemaan hänen artikkelinsa ominaisuuden perusteellisempaa analysointia varten.
Kehittäjän mukavuus ja valinta
Kolmas (ja viimeinen tässä artikkelissa) syy, miksi jotkut kehittäjät suhtautuvat App Bundle -paketteihin, on mukavuuden ja valinnanvaran väheneminen.
Jos kehittäjä tekee uuden sovelluksen Play Kauppaan sen jälkeen, kun Google on alkanut vaatia App Bundle -paketteja ja hän valitsee oletusasetus antaa Googlen hallita allekirjoitusavainta, he eivät koskaan pääse käyttämään allekirjoitusta avain. Jos sama kehittäjä haluaa jakaa sovelluksen toisessa sovelluskaupassa, hänen on käytettävä omaa avaintaan, joka ei vastaa Googlen avainta.
Tämä tarkoittaa, että käyttäjien on joko asennettava ja päivitettävä Google Playsta tai kolmannen osapuolen lähteistä. Jos he haluavat vaihtaa lähdettä, heidän on poistettava sovellus kokonaan, mikä saattaa menettää tietoja, ja asennettava uudelleen. APK-kokoajat pitävät APKMirror sen jälkeen on myös käsiteltävä useita virallisia allekirjoituksia samalle sovellukselle. (Teknisesti heidän on jo tehtävä tämä, koska App Signingin avulla voit luoda uuden, turvallisemman avaimen uusille käyttäjille, mutta se on heille ja muille sivustoille huonompi, kun kaikki on tehdä se.)
Googlen vastaus tähän ongelmaan on käyttää Play Consolen App Bundle Exploreria tai Artifact Exploreria ladatakseen tuloksena olevat APK: t ladatusta paketista. Kuten Code Transparency, tämä ei ole täydellinen ratkaisu. Play Consolesta ladatut APK: t jaetaan eri laiteprofiileille. Vaikka Play Console tukee useiden APK: iden lähettämistä yhden sovelluksen yhdelle versiolle, monet muut jakelukanavat eivät tue.
Näin ollen monet App Bundle -pakettien käytön edut katoavat, kun kehittäjät hallitsevat useita kauppoja, mikä vaikeuttaa jakelua. Sen uutisten kanssa Windows 11 On Android-sovellustuen saaminen Amazon Appstoren ansiosta jotkut uskovat, että sovelluspakettien vaatimus estää kehittäjiä levitmästä Amazonissa. Tietenkin Googlen ensisijainen huolenaihe on oma sovelluskauppa, mutta se on juuri sitä laskeutui kuumaan veteen kilpailijoiden kanssa johtaa heidät tekemään pieniä, sovittelevia muutoksia miten kolmannen osapuolen sovelluskaupat toimivat Androidissa.
Muutama useisiin myymälöihin liittyvä ongelma ovat sovellusten yhteenliitettävyys ja pikatestaukset.
Aloitetaan sovellusten yhteenliitettävyydestä. Oletko koskaan ladannut sovellusta, joka lukitsee ominaisuudet maksumuurin taakse? Melkein ehdottomasti. Jotkut kehittäjät asettavat ominaisuudet sovelluksen sisäisen oston taakse, mutta toiset voivat halutessaan tehdä erillisen, maksullisen sovelluksen. Kun kyseinen lisäsovellus asennetaan, pääsovelluksen ominaisuudet avautuvat.
Mutta mikä estää jotakuta asentamasta lisäosaa piraattilähteestä? No, kehittäjille on monia vaihtoehtoja, mutta ainakin yksi sisältää allekirjoituksella suojattujen käyttöoikeuksien käytön. Oletetaan, että pääsovellus ilmoittaa allekirjoituksella suojatun luvan. Lisäosasovellus ilmoittaa sitten haluavansa käyttää kyseistä lupaa. Ihannetapauksessa lisäsovelluksessa on myös jonkinlainen lisenssin vahvistustoiminto, joka muodostaa yhteyden Internetiin varmistaakseen, että käyttäjä on laillinen.
Jos molemmilla sovelluksilla on sama allekirjoitus, Android myöntää luvan lisäsovellukselle ja piratismin suojaustarkistukset läpäisevät. Jos lisäsovelluksella ei ole oikeaa allekirjoitusta, lupaa ei myönnetä ja vahvistus epäonnistuu.
Klassisen APK-jakelumallin avulla käyttäjä voi hankkia kumman tahansa sovelluksen mistä tahansa laillisesta lähteestä ja tehdä sen. Nykyisessä App Bundle -oletusmallissa pääsovelluksen ja lisäsovelluksen allekirjoitukset eivät täsmää. Google tekee yksilöllisen avaimen jokaiselle sovellukselle. Kehittäjä voisi aina luopua allekirjoituksella suojatusta luvasta ja käyttää suoraa allekirjoituksen hajautusvarmennusta, mutta se on paljon vähemmän turvallista.
Ja sitten on nopea palotestaus. Käyttäjät lähettävät jatkuvasti sähköpostia kehittäjille sovelluksiensa ongelmista. Joskus nämä ongelmat ovat yksinkertaisia korjauksia: toista ongelma, etsi ongelma, korjaa se ja lataa uusi versio. Mutta joskus ne eivät ole. Joskus kehittäjät eivät pysty toistamaan ongelmaa. He voivat korjata heidän mielestään ongelman, mutta sitten käyttäjän on testattava se. Oletetaan nyt, että käyttäjä asensi sovelluksen Google Playn kautta.
APK-mallilla kehittäjä voi muuttaa jotain koodia, rakentaa ja allekirjoittaa uuden APK: n ja lähettää sen käyttäjälle testattavaksi. Koska testi-APK: n allekirjoitus vastaa käyttäjän asentamaa allekirjoitusta, se on helppo päivittää, testata ja raportoida. App Bundlesin kanssa tämä hajoaa. Koska Google allekirjoittaa käyttäjän alun perin asentaman APK: n, se ei vastaa kehittäjän lähettämän APK: n allekirjoitusta. Jos tämä sovellus julkaistaan App Bundlesin määräajan jälkeen, kehittäjällä ei ole edes pääsyä Googlen käyttämiin avaimiin. Testaakseen käyttäjän on poistettava nykyisen sovelluksen asennus ennen testiversion asentamista.
Tässä on joukko ongelmia. Ensinnäkin, sekä kehittäjä- että käyttäjäpuolella on hankaluuksia. Sovelluksen poistaminen vain korjauksen testaamiseksi ei ole hauskaa. Ja entä jos ongelma poistuu? Johtuiko se kehittäjän tekemistä muutoksista vai siitä, että käyttäjä tyhjensi sovelluksen tiedot? Play Kaupassa on sisäinen testaus, jonka on tarkoitus antaa kehittäjien tehdä nopeat koontiversiot ja jakelu, mutta se edellyttää, että käyttäjä poistaa ensin julkaisuversion. Se ei oikeastaan korjaa mitään.
Jos tämä kaikki kuulostaa joukolta hypoteettista hölynpölyä, tässä on erittäin todellinen esimerkki kehittäjästä, jolla on näitä ongelmia, jos hän antaa Googlen luoda heille yksityisen avaimen: João Dias. Hän on Tasker-kehittäjä, samoin kuin koko joukko laajennussovelluksia, mukaan lukien AutoApps-ohjelmisto. Uuden App Bundles -vaatimuksen myötä Joãon kehityssykli voi muuttua paljon hankalammaksi, ainakin uusien sovellusten osalta. Testiversioiden lähettäminen suoraan on vähemmän kätevää. Lisenssien tarkistaminen ei ole yhtä tehokasta.
Tämä saattaa kuulostaa hieman syrjäiseltä tapaukselta, mutta se ei tarkoita, että João olisi pieni kehittäjä, eikä hän todennäköisesti ole yksin. Play Kaupassa on monia sovelluksia, jotka luottavat allekirjoituksen vahvistamiseen laittomien käyttäjien havaitsemiseksi.
Tietenkin, kun kehittäjät voivat ladata omat allekirjoitusavaimensa Googleen, nämä ongelmat ovat ainakin jossain määrin lieventyneet. Mutta kehittäjien on valittava tämä vaihtoehto jokaiselle sovellukselle. Jos näin ei ole, yhteenliittäminen epäonnistuu ja nopean käynnistyksen tuki edellyttää paketin lataamista Googleen ja APK: iden luomisen odottamista ennen oikean lähettämistä käyttäjälle. Lisäksi se tarkoittaa edelleen, että heidän on jaettava yksityinen avaimensa, mikä tuo meidät takaisin aiemmin keskustelemiimme huolenaiheisiin.
Ratkaisut
Tämä on vanha ongelma, koska App Bundle -vaatimukset julkistettiin kuukausia sitten, joten tällä välin on ehdotettu useita ratkaisuja.
Yksi ratkaisu on välttää Play App Signingin tarvetta. Sen sijaan, että Google luoisi App Bundle -paketin, jonka Google sitten käsittelee APK: iksi ja merkeiksi, käsittelyn voi suorittaa Android Studio. Tämän jälkeen kehittäjät voivat vain ladata ZIP-tiedoston, joka on täynnä paikallisesti allekirjoitettuja APK: ita jokaiselle Googlen luomille määrityksille.
Tällä ratkaisulla Google ei tarvitsisi pääsyä kehittäjien avaimiin ollenkaan. Prosessi olisi hyvin samanlainen kuin perinteinen APK-jakelumalli, mutta siihen kuuluisi useita pienempiä APK: ita yhden sijasta.
Toinen ratkaisu on olla vaatimatta App Bundle -paketteja ja sallia edelleen kehittäjien lähettää paikallisesti allekirjoitettuja APK: ita. Vaikka App Bundle -paketit voivat olla parempi käyttökokemus käyttäjälle monissa tapauksissa, jotkin sovellukset eivät itse asiassa hyödy kokoonpanokohtaisesti jaetuista pienimmistä kokoisista vähentäminen.
Jos Google otti käyttöön molemmat ratkaisut, App Bundle -paketteja haluavan kehittäjän ei tarvitse yli kirjautumisen Googleen, ja kehittäjän, jonka sovellus ei hyödy paljon tästä muodosta, ei tarvitse käyttää sitä kaikki.
Googlen vastaukset
Itse allekirjoittaminen
Kun heiltä kysyttiin ensimmäisen kerran, sallitaanko kehittäjien käsitellä App Bundle -pakettien allekirjoittaminen, Googlen vastaus oli hyvin ei-sitova:
[blockquote author=""] Puhuin siis lyhyesti uusien sovellusten vaatimuksesta ensi vuonna käyttää sovelluspaketteja, ja yksi asia, joka liittyy tähän, on, että laajennukselta vaadimme Play App Signingin. Joten kehittäjien on joko luotava sovelluksen allekirjoitusavain Playssa tai ladattava oma avain Playhin… koska se on sovelluspakettien edellytys. Olemme kuulleet kehittäjiltä, että jotkut heistä eivät vain halua tehdä sitä. He eivät halua Playn hallinnoimia avaimia. Ja tällä hetkellä se ei ole mahdollista, jos haluat käyttää sovelluspaketteja.
Mutta olemme kuulleet palautteen ja… En voi puhua mistään juuri nyt, meillä ei ole mitään kerrottavaa, mutta tutkimme, kuinka voisimme lieventää joitain näistä huolenaiheista. Sen ei välttämättä tarvitse sallia oman avaimen säilyttämistä nippujen lataamisen aikana. Tutkimme erilaisia vaihtoehtoja. Meillä ei vain ole julkistettavaa ratkaisua juuri nyt. Mutta meillä on vielä noin vuosi aikaa vaatimukseen, joten olen todella toiveikas, että saamme kehittäjille vastauksen tähän.[/blockquote]
Se oli viime vuoden marraskuun lopulla, eikä mitään näytä tapahtuneen. Vain muutama kuukausi jäljellä ennen Sovelluspakettien vaatimus astuu voimaan, kehittäjät eivät vieläkään pysty allekirjoittamaan omia sovelluksiaan. Vaikka Google on nyt mahdollistanut sen lataa oman avaimesi sekä uusille että olemassa oleville sovelluksille, tämä vie silti allekirjoitusosuuden kehittäjän käsistä.
Koodimuutokset
Vaikka Google on nimenomaisesti luvannut, että Play Kauppa ei aio muokata sovelluskoodia, lupaus ei ole takuu. App Bundleilla ja App Signingilla ei ole tiedossamme olevia teknisiä rajoituksia, jotka estäisivät Googlea muokkaamasta ladattuja sovelluksia ennen jakelua.
Google on esitellyt Koodin läpinäkyvyys valinnaisena ominaisuutena, ja vaikka tämä auttaa jonkin verran, sillä on melkoinen osa ongelmista, kuten aiemmin keskustelimme.
Itsetehdyt niput
Kun Googlelta kysyttiin, sallitaanko kehittäjien tehdä omia sovelluspakettejaan (jaetut APK: t sisältävät ZIP-tiedostot), vastaus oli periaatteessa "emme aio tehdä niin".
Todennäköisesti ei niin kuin kysymyksessä on kuvattu, koska se vaikeuttaisi julkaisuprosessia kehittäjille entisestään, ja haluamme itse asiassa tehdä siitä yksinkertaisemman ja turvallisemman. Olemme kuitenkin jälleen kuulleet tämän palautteen ja tutkimme vaihtoehtoja, kuinka tämä voidaan tehdä mahdolliseksi, mutta ei luultavasti tässä kuvatulla tavalla.
Mielenkiintoista on, että Googlen perustelu näyttää olevan, että se tekisi julkaisemisesta monimutkaisempaa. Google voisi kuitenkin edelleen automatisoida prosessin osana APK: n luontivalintaikkunaa Android Studiossa. Lisäksi, jos kyseistä sovellusta jaetaan useissa myymälöissä, se todella tekisi julkaisuprosessi on yksinkertaisempi, koska kehittäjien ei tarvitse hallita useita allekirjoitusavaimia ja valituksia käyttäjiä.
Ja Code Transparencyn käyttöönoton myötä näyttää siltä, että komplikaatiot eivät ole varsinaisesti ongelma. Code Transparency, ainakin toistaiseksi, edellyttää, että kehittäjä käyttää komentorivityökalua ja että käyttäjät varmistavat nimenomaisesti heille tarjotun sovelluksen kelpoisuuden. Tämä on monimutkaisempaa kuin nippujen itsevalmistusprosessi, ja on epäselvää, miksi tämä on Googlen suosima ratkaisu.
Menee eteenpäin
App Bundle -paketit ovat vaadittu jakelumuoto uusille Google Playhin lähetetyille sovelluksille 1. elokuuta alkaen. Vaikka Google on ainakin jossain määrin käsitellyt suurinta osaa kehittäjien ja tietoturvaasiantuntijoiden esiin nostamista ongelmista, vastaukset jättävät paljon toivomisen varaa. App Bundleilla on monia ilmeisiä etuja seuraavan sukupolven jakelumuodossa, mutta sovelluksen allekirjoittamisen osittaisen tai täydellisen hallinnan antaminen Googlelle aiheuttaa aina ongelmia.
Googlen vastauksia ja ponnisteluja arvostetaan varmasti, mutta jotkut, kuten Mark Murphy, kokevat, että he eivät ole menneet tarpeeksi pitkälle. Ratkaisuja, kuten itse tehtyjä paketteja, ei oteta käyttöön ja Android App Bundle -pakettien määräaikaa vaaditaan nopeasti lähestyessä, ei näytä siltä, että Google Playn kehittäjät pystyvät säilyttämään sovellustensa täyden hallinnan pitkään aikaan kauemmin.
Puhumme Android App Bundle -vaatimuksen vaikutuksista Twitter-tilassa myöhemmin tänä iltapäivänä, joten liity meihin!