Google Play vil snart tvinge udviklere til at uploade App Bundles i stedet for APK'er, hvilket rejser ubehagelige sikkerhedsspørgsmål om kravet.
november sidste år, Google meddelte at udviklere skal udgive nye apps i Play Butik ved hjælp af Android App Bundle-formatet (AAB) i stedet for en APK. Forleden mindede Google udviklere om dette kommende krav, hvilket udløste en ildstorm af kontroverser fra brugere, der mener, at Google dræber APK'er, eliminerer sideloading, hindrer tredjeparts appbutikker og hvad ikke.
Det er rigtigt, at Android App Bundles er en ret stor afvigelse fra det klassiske APK-format, du måske er vant til, både som bruger og som udvikler. Selvom der er en del fordele ved at bruge App Bundles, er der et vigtigt aspekt ved at lave dem, som nogle udviklere og sikkerhedseksperter med rette bekymrer sig om.
I denne artikel vil vi dække den kritik, vi har set af skiftet til Android App Bundles, samt nogle foreslåede løsninger, og vi vil også tale om Googles foreslåede løsning på disse problemer.
Baggrund
Før det sker, skal vi dog tale lidt om, hvordan appdistribution fungerer på Android generelt. Hvis du allerede ved, hvordan app-signering og App Bundles fungerer, kan du springe denne del over.
APK'er
For det meste distribueres apps på Android inde i APK-filer. En APK indeholder al en apps kode og ressourcer sammen med nogle sikkerhedsfunktioner som et signeringsmanifest. Når en APK er installeret, bliver den stort set bare kopieret til en bestemt mappe og tilføjet til en intern database med installerede apps.
Underskrifter
Under installationen verificeres appens signatur også for at sikre, at den er gyldig. Hvis appen allerede er installeret, tjekker Android den nye apps signatur mod den, der allerede er installeret. Hvis signaturen ikke er gyldig eller ikke stemmer overens, vil Android nægte at installere appen.
Denne signaturkontrol er en vigtig del af sikkerheden i Android. Det sikrer, at den app, du installerer, er gyldig og i det mindste fra samme kilde som den, du allerede havde installeret. Hvis du f.eks. installerer f.eks. min Lockscreen Widgets app fra Play Butik, du kan være rimelig sikker på, at det er mig, der har skrevet under, og at det er autentisk. Hvis du derefter prøver at installere en opdatering til Lockscreen Widgets fra et lyssky tredjepartswebsted, og det mislykkes, vil du vide, at nogen har pillet ved den APK, muligvis for at tilføje malware.
Nøglen, der bruges til at signere en app er (ideelt set) aldrig offentligt udgivet. Dette er kendt som den private nøgle. Den private nøgle bruges derefter til at generere nøglen vist i appens signatur, kendt som den offentlige nøgle. Dette er, hvad Android- og appbutikker bruger til at bekræfte en apps gyldighed. Jeg vil ikke komme ind på, hvordan du nøjagtigt kan generere en offentlig nøgle uden at afsløre den private nøgle, da det involverer en masse krypteringsmatematik. Hvis du vil have flere detaljer, så tjek ud Googles dokumentation om signering af APK'er eller forske i envejs matematiske funktioner.
En anden funktion ved app-signaturer er muligheden for kun at begrænse tilladelser til apps med matchende signaturer. Android gør dette internt for en masse funktioner, hvor kun apps, der er signeret med samme nøgle som rammen, kan få adgang til visse funktioner.
App Bundles
Så nu hvor vi har givet et hurtigt overblik over APK'er og signaturer, lad os tale om App Bundles. Det er her APK-ressourcer kommer ind. Ressourcer er ting som layout, billeder, lyd osv. Dybest set er de noget, der ikke er kode. For bedre at understøtte forskellige skærmkonfigurationer og forskellige sprog kan udviklere lave flere versioner af den samme ressource, der bruges afhængigt af enhed og sprog.
Men i en APK findes alle disse ressourcer, uanset hvilken du bruger. Og de fylder. Afhængigt af kompleksiteten af din app kan der være mange ubrugte ressourcer til mange enheder. Dette er, hvad App Bundles er lavet for at løse. Udviklere kan generere en App Bundle ligesom en APK, og den App Bundle kan derefter uploades til Play Butik, ligesom en APK kan.
Google bruger derefter denne App Bundle til at generere en hel masse forskellige APK'er til forskellige enhedskonfigurationer. Hver App Bundle indeholder kun de ressourcer, der er nødvendige for den pågældende konfiguration. Når en bruger går for at downloade den app, får de serveret den genererede APK, der matcher deres konfiguration. Dette hjælper med at reducere både app-download- og installationsstørrelser, hvilket sparer båndbredde og lagerplads.
At installere en APK, der er specifik for din enhed, betyder selvfølgelig, at det er sværere for dig bare at kopiere den til en anden enhed og installere den uden problemer. Afhængigt af dit perspektiv kan dette være en god eller en dårlig ting. På den ene side gør det piratkopiering sværere, da brugerne ikke har hele appen længere. På den anden side gør det lovlig arkivering af apps sværere af samme grund.
App-signering
Da Android App Bundles ikke er APK'er, kan du ikke bare åbne en AAB-fil og installere den direkte på en enhed. Når du uploader en til Play Butik, bruger Google pakken til at generere forskellige (usignerede) APK-filer. Disse APK'er skal derefter signeres, før de kan installeres.
I stedet for at bede udvikleren om at signere og genuploade de genererede APK'er, administrerer Google i stedet signeringen selv. Play Butik bruger enten en ny nøgle, den opretter, eller beder udvikleren om den nøgle, de bruger til at signere APK'er. Med begge muligheder håndterer Google den offentlige signering for udvikleren og giver en upload nøgle. Google bruger uploadnøglen til intern bekræftelse og sørger for, at den app-pakke (eller APK i nogle tilfælde), som udvikleren uploader, er den rigtige.
Hvis en uploadnøgle er kompromitteret eller tabt, kan udviklere anmode om en ny, og signeringsnøglen, der bruges til at distribuere appen, forbliver uændret.
Der er meget mere til App Signing, men det er det, der er relevant for denne artikel. Hvis du vil, kan du læse mere om App Bundles og App Signing denne Medium artikel af Wojtek Kaliciński.
Kritik
I teorien og i praksis er App Bundles ret gode. De reducerer dataforbrug og installationsstørrelse, alt sammen uden at brugeren behøver at gøre noget. Men på grund af hvordan det er implementeret, har nogle udviklere og sikkerhedsforskere i de sidste par måneder rejst bekymringer. Før jeg opsummerer disse bekymringer, vil jeg bruge et øjeblik på at sige, at det meste af det, der er skrevet nedenfor, er direkte baseret på en række artikler af udvikler Mark Murphy af CommonsWare. Du bør absolut tjekke hans artikler ud, da de giver flere detaljer og kritik fra en udviklers perspektiv.
Sikkerhed
I den klassiske distributionsmodel holder en udvikler nøglen, de bruger til at signere en APK, privat. Det deles aldrig med offentligheden, og kun autoriserede personer skal have adgang til det. Dette sikrer, at kun disse personer kan generere en gyldig APK.
Men hvis du bruger App Bundles i Play Butik, er det Google, der administrerer nøglen, der signerer APK'erne, som brugerne modtager. Det Standard adfærd for nye apps uploadet til Google Play fra august 2021 er for Google at skabe sin egen distributionsnøgle, som den holder privat fra udvikleren.
Udviklere indsender nye apps vil få Google til at administrere deres private nøgle for dem som standard, selvom udviklere sender opdateringer til eksisterende apps kan fortsætte med at bruge APK'er eller de kan skifte til AAB-distribution ved at generere en ny nøgle, som Google kan bruge til nye brugere. Eksisterende apps er ikke påkrævet at skifte fra APK-distribution til Android App Bundles, selvom den mulighed er tilgængelig for dem, hvis de vælger det. Efter lidt pushback, Google vil endda gøre det muligt at uploade din egen private nøgle, som Google kan logge på med, både for nye og eksisterende apps. Ingen af disse situationer er ideelle, da uanset hvad, Google vil have adgang til din private nøgle, hvis du vil bruge Android App Bundles (og udviklere har ikke noget valg i sagen, hvis de vil indsende en ny app efter august 2021!)
Selvom vi er overbeviste om, at Google tager sikkerhed meget alvorligt, er der ingen virksomhed på jorden, der er immun over for databrud. Hvis nøglen, Google bruger til at signere din app til distribution, er i et af disse brud, så kan enhver signere en version af din app og få det til at se ud som om, den er signeret af dig. Og nogle udviklere og sikkerhedseksperter er ikke glade for denne mulighed. Det er en meget, meget lille mulighed, ja, men det faktum, at det overhovedet er en mulighed, skræmmer nogle i infosec-samfundet.
At lade udviklere signere Android APK'er betyder, at alle kan bekræfte APK'er fra Google Play, blind tillid er ikke påkrævet. Det er et elegant design, der giver verificerbar sikkerhed. App Bundles vender det på hovedet og virker struktureret til at fremme leverandørlåsning. Der er mange alternative tekniske tilgange, der ville give små APK'er, der stadig er underskrevet af udviklere, men disse foretrækker ikke Play. For eksempel kunne alle APK-varianter genereres og signeres af udvikleren og derefter uploades til enhver appbutik.
Der er helt sikkert argumenter for, om det er bedre at overlade sikker opbevaring af private nøgler i hænderne på Google eller individuelle udviklere. Men disse udviklere bruger (sandsynligvis) normalt ikke et centralt lager til deres nøgler. Ved at tvinge udviklere til at bruge Play App Signing behøver en ondsindet angriber kun at bryde Googles sikkerhed én gang for at hente tusinder eller millioner af nøgler.
For hvad det er værd, her er hvad Google siger om, hvordan det beskytter din signeringsnøgle på sin infrastruktur:
[blockquote author="Wojtek Kaliciński, Android Developer Advocate at Google"]Når du bruger Play App Signing, gemmes dine nøgler på den samme infrastruktur, som Google bruger til at gemme sine egne nøgler.
Nøgleadgang er styret af strenge ACL'er og manipulationssikre revisionsspor for alle operationer.
Alle artefakter, der er genereret og signeret med udviklerens nøgle, stilles til rådighed for dig i Google Play Console til inspektion/attestering.
For at forhindre nøgletab laver vi desuden meget hyppige sikkerhedskopier af vores primære lager. Disse sikkerhedskopier er stærkt krypteret, og vi tester regelmæssigt gendannelse fra disse sikkerhedskopier.
Hvis du vil lære mere om Googles tekniske infrastruktur, kan du læse Google Cloud Security Whitepapers.[/blockquote]
Så fantastisk som at alle lyde, tab og tyveri stadig er mulige. Og revisionsspor hjælper kun med at forhindre fremtidige angreb; de får ikke ødelagte nøgler tilbage.
Potentiale for uautoriserede ændringer
Et stort problem med den måde, Google har opsat App Bundles på, er muligheden for, at uautoriserede ændringer kan tilføjes til en app. Processen med at udtrække APK'er fra en App Bundle involverer i sagens natur ændringer, da Google skal bygge hver APK manuelt. Mens Google har lovet, at de ikke vil indsprøjte eller ændre kode, er problemet med App Bundle-processen, at den har magten til at gøre det.
Her er et par eksempler på, hvad en virksomhed i Googles position har magten til at gøre:
Lad os sige, at der er en sikker besked-app, som folk bruger til at kommunikere uden risiko for regeringsovervågning. Dette kan være et utroligt nyttigt værktøj for folk, der protesterer mod en autoritær regering, eller endda folk, der bare ønsker at bevare deres privatliv. Denne regering, der ønsker muligheden for at se, hvad app-brugere siger, kunne prøve at tvinge Google til at tilføje en overvågningsbagdør i appens kode.
Dette eksempel er lidt mere harmløst, men det er også noget, der bekymrer nogle mennesker. Lad os sige, at der er en app, der henter millioner af downloads om dagen, men den har ingen annoncer eller analyser i den. Det er en enorm datakilde uden mulighed for at få adgang til disse data. Google, som er et reklamefirma, ønsker måske at få adgang til disse data.
I den klassiske APK-model for appdistribution kan Google ikke ændre apps uden at ændre signaturen. Hvis Google ændrer signaturen, især på en populær app, vil folk bemærke, fordi opdateringen ikke installeres. Men med App Bundles og App Signing kunne Google stille sin egen kode ind i apps, før de distribuerede dem. Signaturen ville ikke ændre sig, fordi Google ville eje signaturnøglen.
For at være klar, Det er utroligt usandsynligt, at disse eksempler vil ske. Google har en tendens til simpelthen helt trække sig ud af besværlige markederi stedet for at tilpasse sig. Men selvom det er usandsynligt, er det stadig muligt. Bare fordi en virksomhed lover, at noget ikke vil ske, garanterer det det ikke.
Kodegennemsigtighed
Google, der hørte disse bekymringer, introducerede i denne uge en ny funktion kaldet Kodegennemsigtighed for App Bundles. Kodegennemsigtighed giver en udvikler mulighed for i det væsentlige at skabe en anden signatur, der leveres sammen med appen til brugerne. Denne ekstra signatur skal oprettes fra en separat privat nøgle, som kun udvikleren har adgang til. Der er dog nogle begrænsninger for denne metode.
Kodegennemsigtighed dækker kun kode. Det kan virke indlysende givet navnet, men det betyder også, at det ikke lader brugere verificere ressourcer, manifestet eller noget andet, der ikke er en DEX-fil eller et oprindeligt bibliotek. Selvom ondsindede ændringer af ikke-kodefiler normalt har meget mindre indflydelse, er det stadig et hul i appens sikkerhed.
Et andet problem med Code Transparency er, at der ikke er nogen iboende verifikation. For en, det er en valgfri funktion, så udviklere skal huske at inkludere det for hver ny APK, de uploader. I øjeblikket skal det gøres fra kommandolinjen og med en version af bundletool der ikke følger med Android Studio. Selv når en udvikler inkluderer det, har Android ikke nogen form for verifikation indbygget for at kontrollere, at Code Transparency-manifestet matcher koden i appen.
Det er op til en slutbruger at tjekke selv ved at sammenligne manifestet med en offentlig nøgle, som udvikleren kan levere, eller ved at sende APK'en til udvikleren til verifikation.
Mens kodegennemsigtighed giver mulighed for bekræftelse af, at ingen kode i en app er ændret, inkluderer den ikke nogen form for bekræftelse for andre dele af en app. Der er heller ingen iboende tillid til processen. Du kan argumentere for, at hvis du ikke stoler på Google, er du sandsynligvis klar til opgaven med at verificere uafhængigt, men hvorfor skulle du være nødt til det?
Der er andre problemer med funktionen Kodegennemsigtighed, f.eks påpegede af Mark Murphy fra CommonsWare. Jeg anbefaler at læse hans artikel for en mere dybdegående analyse af funktionen.
Udvikler bekvemmelighed og valg
En tredje (og sidste for denne artikel) grund til, at nogle udviklere tager problemer med App Bundles, er reduceret bekvemmelighed og valgmuligheder.
Hvis en udvikler laver en ny app i Play Butik, efter at Google begynder at kræve App Bundles, og de vælger standardindstillingen for at lade Google administrere signeringsnøglen, vil de aldrig have adgang til denne signering nøgle. Hvis den samme udvikler så ønsker at distribuere den app i en anden app-butik, skal de bruge deres egen nøgle, som ikke matcher Googles.
Det betyder, at brugere enten skal installere og opdatere fra Google Play eller fra tredjepartskilder. Hvis de vil ændre kilden, skal de helt afinstallere appen, hvilket potentielt mister data, og geninstallere. APK-aggregatorer kan lide APKMirror vil så også have at gøre med flere officielle signaturer for den samme app. (Teknisk set er de allerede nødt til at gøre dette, fordi App Signing lader dig oprette en ny, mere sikker nøgle til nye brugere, men det bliver værre for dem og andre websteder, når alle har at gøre det.)
Googles svar på dette problem er at bruge App Bundle Explorer eller Artifact Explorer i Play Console til at downloade de resulterende APK'er fra den uploadede pakke. På samme måde som Code Transparency er dette ikke en komplet løsning. De APK-filer, der downloades fra Play Console, vil blive opdelt for forskellige enhedsprofiler. Mens Play Console understøtter upload af flere APK'er til én version af én app, gør mange andre distributionskanaler det ikke.
Således forsvinder mange af fordelene ved at bruge App Bundles, når udviklere administrerer flere butikker, hvilket gør distributionen sværere. Med nyheder der Windows 11 er at få Android app support takket være Amazon Appstore mener nogle, at kravet om App Bundles vil afskrække udviklere fra at distribuere på Amazon. Selvfølgelig er Googles primære bekymring med sin egen app-butik, men det er præcis det landede dem i varmt vand med konkurrenterne fører dem til at lave små, forsonende ændringer til, hvordan tredjeparts app-butikker fungerer på Android.
Et par relaterede problemer til flere butikker er app-sammenkobling og hurtig brandtest.
Lad os starte med app-sammenkobling. Har du nogensinde downloadet en app, der låser funktioner bag en betalingsmur? Næsten bestemt. Nogle udviklere sætter funktionerne bag et køb i appen, men andre kan vælge at lave en separat, betalt app. Når den tilføjelsesapp bliver installeret, låses hovedappens funktioner op.
Men hvad forhindrer nogen i bare at installere tilføjelsen fra en piratkilde? Nå, der er mange muligheder for udviklere, men mindst én involverer brug af signaturbeskyttede tilladelser. Lad os sige, at hovedappen erklærer en signaturbeskyttet tilladelse. Tilføjelsesappen erklærer derefter, at den ønsker at bruge denne tilladelse. Ideelt set vil tilføjelsesappen også have en form for licensbekræftelsesfunktionalitet i sig, der forbinder til internettet for at sikre, at brugeren er legitim.
Hvis begge apps har den samme signatur, giver Android tilladelsen til tilføjelsesappen, og kontrol af piratkopiering vil bestå. Hvis tilføjelsesappen ikke har den rigtige signatur, vil tilladelsen ikke blive givet, og verifikationen mislykkes.
Med den klassiske APK-distributionsmodel kan en bruger få begge apps fra enhver legitim kilde og være færdig med den. Med den nuværende standard App Bundle-model vil signaturerne på hoved- og tilføjelsesapps ikke matche. Google vil lave en unik nøgle til hver app. Udvikleren kunne altid gøre op med den signaturbeskyttede tilladelse og bruge direkte signatur-hash-bekræftelse, men det er meget mindre sikkert.
Og så er der hurtig brandtestning. Brugere e-mailer hele tiden udviklere om problemer i deres apps. Nogle gange er disse problemer simple rettelser: genskab problemet, find problemet, ret det, og upload en ny version. Men nogle gange er de ikke. Nogle gange kan udviklere ikke genskabe et problem. De kan ordne det, de tror er problemet, men så skal brugeren teste det. Antag nu, at brugeren installerede appen via Google Play.
Med APK-modellen kan en udvikler ændre noget kode, bygge og signere en ny APK og sende den til brugeren til test. Da signaturen på test-APK'en matcher den, brugeren har installeret, er det en simpel proces at opdatere, teste og rapportere tilbage. Med App Bundles falder dette fra hinanden. Da Google signerer APK'en, som brugeren oprindeligt installerede, vil den ikke matche signaturen på APK'en, som udvikleren sender. Hvis denne app udgives efter App Bundles deadline, vil udvikleren ikke engang have adgang til de nøgler, Google bruger. For at teste skal brugeren afinstallere den aktuelle app, før testversionen installeres.
Der er en masse problemer her. For det første er der besvær, både på udvikler- og brugersiden. Det er ikke sjovt at skulle afinstallere appen bare for at teste en rettelse. Og hvad hvis problemet forsvinder? Var det de ændringer, udvikleren lavede, eller var det fordi brugeren effektivt ryddede appens data? Play Butik har intern testning, som formodes at lade udviklere lave hurtig-fire builds og distribution, men det kræver, at brugeren afinstallerer udgivelsesversionen først. Det løser ikke rigtig noget.
Hvis det hele lyder som en masse hypotetisk nonsens, er her et meget reelt eksempel på en udvikler, der vil have disse problemer, hvis de lader Google generere en privat nøgle til dem: João Dias. Han er udvikleren af Tasker sammen med en hel masse plugin-apps, inklusive AutoApps-pakken. Med det nye App Bundle-krav kan Joãos udviklingscyklus blive meget vanskeligere, i det mindste for nye apps. Det vil være mindre bekvemt at sende testversioner direkte. Bekræftelse af licenser vil være mindre effektiv.
Dette kan lyde som lidt af en kant-case, men det er ikke sådan, at João er en lille udvikler, og det er sandsynligt, at han ikke er alene. Der er mange apps i Play Butik, der er afhængige af signaturbekræftelse for at opdage illegitime brugere.
Selvfølgelig, med den nye mulighed for udviklere til at uploade deres egne signeringsnøgler til Google, er disse problemer i det mindste lindret noget. Men udviklere skal tilmelde sig for at aktivere muligheden for hver app. Hvis de ikke gør det, vil sammenkoblinger mislykkes, og hurtig-fire-support vil kræve, at du uploader en bundle til Google og venter på, at APK'er bliver genereret, før den korrekte sendes til brugeren. Plus, det betyder stadig, at de skal dele deres private nøgle, hvilket bringer os tilbage til de bekymringer, vi diskuterede tidligere.
Løsninger
Dette er et gammelt problem, da App Bundle-kravene blev offentliggjort for måneder siden, så der har været en del løsninger foreslået i mellemtiden.
En løsning er at undgå behovet for Play App Signing. I stedet for at generere en App Bundle, som Google derefter behandler til APK'er og tegn, kunne denne behandling udføres af Android Studio. Derefter kan udviklere bare uploade en ZIP fuld af lokalt signerede APK'er for hver konfiguration, som Google ville have genereret.
Med den løsning ville Google slet ikke have brug for adgang til udviklerens nøgler. Processen ville være meget lig den klassiske APK-distributionsmodel, men ville involvere flere, mindre APK'er i stedet for kun én.
En anden løsning er bare ikke at kræve brug af App Bundles og fortsætte med at tillade udviklere at uploade lokalt signerede APK'er. Mens App Bundles evt være en bedre oplevelse for brugeren i mange tilfælde, nogle apps har faktisk ikke gavn af at blive delt op pr. konfiguration med minimal størrelse reduktion.
Hvis Google implementerede begge disse løsninger, behøver en udvikler, der ønsker at bruge App Bundles, ikke over at logge på Google, og en udvikler, hvis app ikke vil have meget gavn af formatet, behøver ikke bruge den på alle.
Googles svar
Selvsignering
Da de første gang blev spurgt om at tillade udviklere at håndtere signeringen af App Bundles, var Googles svar meget uforpligtende:
[blockquote author=""]Så jeg talte kort om kravet næste år om, at nye apps skal bruge app bundles, og en ting, der følger med det, er, at vi i forlængelse heraf vil kræve Play App Signing. Så udviklere skal enten generere app-signeringsnøglen på Play eller uploade deres egen nøgle til Play … fordi det er en forudsætning for app-bundter. Vi har hørt fra udviklere, at nogle af dem bare ikke ønsker at gøre det. De ønsker ikke at have nøgler administreret af Play. Og i øjeblikket er det ikke muligt, hvis du vil bruge app-bundter.
Men vi har hørt den feedback, og... jeg kan ikke tale om noget lige nu, vi har ikke noget at annoncere, men vi undersøger, hvordan vi kan afhjælpe nogle af disse bekymringer. Det behøver ikke nødvendigvis at give mulighed for at beholde din egen nøgle, mens du uploader bundter. Vi undersøger forskellige muligheder. Vi har bare ikke en løsning at annoncere lige nu. Men vi har stadig omkring et år til kravet, så jeg håber virkelig, at vi har et svar til udviklerne på dette.[/blockquote]
Det var i slutningen af november sidste år, og intet ser ud til at være sket. Med kun få måneder tilbage før Kravet om App Bundles træder i kraft, er der stadig ikke en måde for udviklere at håndtere signering af deres egne apps. Mens Google nu har gjort det muligt at upload din egen nøgle til både nye og eksisterende apps, dette tager stadig signeringsdelen ud af hænderne på udvikleren.
Kodeændringer
Selvom Google specifikt har lovet, at Play Butik ikke vil ændre appkoden, er et løfte ikke en garanti. Med App Bundles og App Signing er der ingen teknisk begrænsning, som vi kender til at forhindre Google i at ændre uploadede apps før distribution.
Google har introduceret Kodegennemsigtighed som en valgfri funktion, og selvom dette hjælper noget, har det sin rimelige andel af problemer, som vi diskuterede tidligere.
Selvlavede bundter
Da Google blev spurgt om at tillade udviklere at lave deres egne app-"bundles" (ZIP'er indeholdende opdelte APK'er), var svaret dybest set "det vil vi ikke gøre":
Sandsynligvis ikke som det er beskrevet i spørgsmålet, da dette ville gøre publiceringsprocessen endnu sværere for udviklere, og vi ønsker faktisk at gøre det enklere og mere sikkert. Men igen, vi har hørt denne feedback, og vi vil undersøge mulighederne for, hvordan man gør dette muligt, dog sandsynligvis ikke på den måde, som blev beskrevet her.
Interessant nok synes Googles begrundelse at være, at det ville gøre publicering mere kompliceret. Google kunne dog stadig gøre processen automatiseret som en del af APK-genereringsdialogen i Android Studio. Ydermere, hvis den pågældende app bliver distribueret i flere butikker, ville den faktisk gøre publiceringsprocessen enklere, da udviklere ikke skal administrere flere signeringsnøgler og klager fra brugere.
Og med introduktionen af Code Transparency lader det til, at komplikation ikke ligefrem er et problem alligevel. Kodegennemsigtighed kræver i det mindste nu, at udvikleren bruger et kommandolinjeværktøj, og at brugerne eksplicit bekræfter gyldigheden af den app, de får serveret. Dette er mere kompliceret end en proces til selv at lave bundter, og det er uklart, hvorfor dette er den løsning, Google foretrækker.
Fremadrettet
App Bundles vil være det påkrævede distributionsformat for nye apps, der indsendes til Google Play fra den 1. august. Mens Google i det mindste i nogen grad har behandlet de fleste af de problemer, som udviklere og sikkerhedseksperter har rejst, lader svarene meget tilbage at ønske. Der er mange åbenlyse fordele ved App Bundles som næste generations distributionsformat, men der vil altid være vedvarende bekymringer med at give delvis eller total kontrol over app-signering til Google.
Googles svar og indsats er bestemt værdsat, men nogle, som Mark Murphy, føler, at de ikke er gået langt nok. Med løsninger som selvfremstillede bundter, der ikke er implementeret, og deadline for Android App Bundles kræves hurtig nærmer sig, ser det ikke ud til, at udviklere på Google Play vil være i stand til at beholde fuld kontrol over deres apps for meget længere.
Vi vil tale om implikationerne af Android App Bundle-kravet i et Twitter-område senere i eftermiddag, så slutt dig til os!