APK vs AAB: Alt hvad du skal vide!

snow Cone Android 12 dessertnavn
Efterhånden som vi kommer tættere på den stabile Android 12-udgivelse, foretager Google nogle grundlæggende ændringer i app-levering og distribution på Android-enheder. Fra august 2021 vil alle de nye apps i Play Store blive offentliggjort i Android App Bundles (.aab) -formatet i stedet for det eksisterende APK-format. I denne guide gennemgår vi APK vs AAB.

Rent teknologisk kommer der nogle ændringer med ankomsten af den stabile version af Android 12.

I denne guide gennemgår vi de to teknologier, hvordan du installerer AAB-filer, udpakker APK'er fra AAB'er og meget mere.



APK vs AAB: Det grundlæggende

For det første er vi nødt til at gennemgå det helt grundlæggende for korrekt at forstå, hvad forskellene er mellem en APK og en Android App Bundle.

APK har været go-to-distributions-app-pakke på Android siden starten. En APK består primært af app-koder, krævende ressourcer såsom billede, lyd osv. og en app-signeringsnøgle genereret af udvikleren. Bemærk, at Android-enheder kommer i forskellige formfaktorer og specifikationer. For eksempel kan enhederne have en varierende grad af screen density (320dpi, 480dpi osv.), Processortype (ARM, ARM64, x86) og mere. Baseret på brugerens placering skal appen også have en sprogpakke (DK, EN, DE osv.).

I en ideel situation er en udvikler nødt til at opbygge og uploade flere APK'er i Play Butik baseret på brugerens region, processortype og screen densiy. Når en bruger trykker på “Install” -knappen i Play Butik, installeres den korrekte og mest egnede APK derefter på deres enhed. Imidlertid placerer dette en ret så krævende opgave i udviklerens hænder. De skal ikke bare udvikle apps, men ligeledes administrerer flere APK'er til at understøtte en ofte ret så omfangsrig pulje med enheder.

For at undgå dette komplekse og tidskrævende arbejde bygger de fleste udviklere en Universal APK, der kommer med alle ressourcerne bundled (sprogpakker, koder og mere), selvom du muligvis ikke har brug for alt på en given enhed. Dette resulterer i en voluminøs APK med en ofte ret så omfangsrig app-størrelse, der kræver længere installationstid og optager efterfølgende mere båndbredde.

Google ønsker at irettesætte dette og påtage sig det meste af denne byrde for udviklere med Android App Bundles (AAB). Dette hjælper igen med at reducere app-størrelsen, installationstiden og ikke mindst forbruget af båndbredde. Virksomheden introducerede AAB ved Google I / O 2018, og nu næsten to år senere pålægger Google, udviklerne skal indsende nye apps i AAB-format i Play Butik.

Sammenlignet med APK er AAB-formatet ikke en komplet ny distributionspakke. Faktisk er AAB en container, der er vært for en basis-APK og flere split-APK'er. Grundlæggende er AAB et udgivelsesformat, som en udvikler sender til Play Butik, mens APK er et ”pakketerings-format” til Android-apps, som du installerer på din enhed.

Så hvad ændrer sig her? Fra august 2021 behøver udviklere ikke at håndtere og administrere en hel masse APK'er til en bred vifte af enheder. Med AAB overdrager udviklere i princippet alt til Google – app-koden, aktiver, tunge ressourcer, alle sprogpakker og vigtigst af alt den private app-signeringsnøgle. Nu kan Google generere og servere optimerede APK'er til brugere baseret på deres enheds konfiguration.

Det kan resultere i langt mindre AAB-bundles, kræver mindre plads, hurtigere installationstid og ikke mindst kræver mindre, som kommer low-end-enheder til gode.

Deling af privat signaturnøgle med Google

Når man ser på, hvad AAB bringer til bordet, virker det som et godt alternativ til APK. AAB-formatet reducerer app-størrelsen, og udviklere behøver ikke oprette flere APK'er. Imidlertid har mange udviklere udtrykt bekymring over deling af privat signaturnøgle med Google.

Hovedpinnen kan, ifølge udviklerne opstå, når der skal kontrolleres APK-integritet. Selvom du sideloader en APK fra en tredjepartskilde, kontrollerer Google Play Butik signaturnøglen for at sikre sig, at der ikke er blevet manipuleret med noget.

Med AAB pålægger Google, at udviklere skal dele den private signeringsnøgle, så Google kan generere app-pakken og signere AAB’en med den samme private nøgle. Når brugere installerer appen eller opdaterer til en ny version, vil Play Services matche signaturnøglen, og installationen finder efterfølgende sted. Med det sagt mener nogle udviklere, at det potentielt åbner døren for kodeinjektion.

Google siger, at alle “signing keys are stored on the same infrastructure that Google uses to store its own keys.” Så her skal man være sikker på, at alle private signaturnøgler er godt beskyttet.

APK Google.jpg
Source: Google

Desuden annoncerede Google Code Transparency for at modvirke udviklernes bekymringer, der giver udviklere mulighed for at generere en separat privat nøgle, som kun er tilgængelig for dem. Fra den separate private nøgle kan udviklere derefter oprette en ekstra signatur, der kan bruges til at verificere app-integritet. Der løftes dog bekymring om denne metode. Kodetransparens handler kun om koden og ikke om aktiver, ressourcer eller manifest. Google påtvinger ikke denne del, og lade rden fremstå som en valgfri funktion.

Vil AAB gøre tingene sværere for tredjeparts-app-butikker?

Et andet problem, der opstår ved at dele den private nøgle med Google, er, at det kan gøre tingene sværere for tredjeparts app-butikker. For eksempel, hvis du installerer en app fra Play Butik, men ønsker at opdatere til den nyeste version fra et andet Play Store-alternativ (f.eks. Amazon App Store eller Aptoide Store), kan installationen muligvis mislykkes på grund af en signaturfejl.

Det skyldes, at Google nu administrerer den private signeringsnøgle, så du kan ikke bruge den samme nøgle, mens du uploader din app til en tredjeparts Android-app-butik. Du bliver nødt til at bruge en anden privat nøgle, og det vil medføre, at den private nøgle ikke stemmer overens. Vil dette være et problem for Android-app-support på Windows 11? Besvarelse på spørgsmålet står hen i det udvisse indtil android 12 officielt lanceres i en stabil version.

Bortset fra det synes formodningen om, at AAB forhindrer udviklere i at uploade APK'er til tredjeparts app-butikker, forkert. Google har allerede lavet et open source-værktøj kaldet Bundletool, der giver udviklere mulighed for at oprette APK'er fra AAB-bundles. Det eneste umildbare problem, for nu, er deling af den private signeringsnøgle, der efter signende vil påvirker Android power users.

Kan man sideloade AAB'er ligesom APK'er?

Fra hvad vi ved ser det ud til, at sideloading af AAB'er på Android-enheder vil være mulig, men det vil ikke være så praktisk som sideloading af APK'er. Androids package-installer understøtter i øjeblikket ikke AAB-pakkeformat, hvilket betyder, at AAB-installation på enheden ikke er mulig. Du kan dog bruge tredjepartsinstallationsapps til at installere en AAB-pakke på enheden.

Bortset fra det ikke være muligt at sideload din vej frem til installation af AAB'er. Du bliver nødt til at bruge open source bundletool for at få den korrekte APK, der er kompatibel med din enhed. Efterhånden som AAB'er bliver mere almindelige, kan der komme nye og praktiske metoder til sideloading.

For eksempel giver APKMirror Installer (gratis, tilbyder køb i appen) i øjeblikket dig mulighed for at installere APKM-bundles (Base APK + Split APK'er) med sin installations-app.

APK vs AAB: Fordele og ulemper

Konklusionen synes at være, at AAB'er ikke vil gøre meget forskel med hensyn til brugeroplevelse for de fleste brugere – dog reduceres app-størrelsen, hvilket vil være nyttigt for de fleste.

AAB bevæger sig væk fra OBB (Opaque binær blob) for at downloade store aktiver og ressourcer. I stedet bruges Play Asset Delivery eller Play Feature Delivery til at downloade ressourcer med en downloadstørrelse på 150 MB eller højere. Hvorvidt det påvirker sideloading af spil, må tiden vise.

Hvad angår udviklere, der er mest berørt af denne ændring, behøver de ikke ændre deres kode.  AAB'er bringer også modularitet, hvilket betyder, at de kan ændre et kode-snippet og merge det med core-base.  

chrome_HTmmriPS5Y.jpgSource: Hothardware

En fordel ved AAB er, at det giver tilpasningsmuligheder til udviklere. De kan vælge, hvilket API-niveau de skal målrette mod, eller hvilken enhedstype de vil understøtte. Udviklere kan også beslutte, om alle funktioner skal leveres på en bestemt enhedstype eller smartphones, der kører på en minimum SDK-version.

Hvad angår ulemperne, er kernen i problemet at dele den private nøgle, som nu administreres af Google. Uforenelighed med tredjeparts-app-butikker kan være et andet stort problem, og udviklerne bliver nødt tænke kreativt for at udgive og administrere APK-filer (ligesom Play Store) i andre app-butikker.


Source & Image credit:

Google, Hothardware, Android.developers, Stack overflow, Pixabay