Nieuwe apps verschijnen vanaf augustus niet langer als apk in Google Play Store

Nieuwe apps zullen niet langer een universeel apk-bestand hebben als ze in de Play Store verschijnen. Google dwingt ontwikkelaars om over te gaan op App Bundles, waarbij de Play Store bij installatie een apk-bestand genereert voor alleen dat apparaat.

App Bundles zijn er al drie jaar, maar worden vanaf augustus verplicht voor nieuwe apps in de Play Store, zegt Google. Met een App Bundle is het installatiebestand rond vijftien procent kleiner, waardoor de installatie sneller gaat, zegt Google. Bovendien kunnen ontwikkelaars ervoor kiezen om bepaalde code of assets alleen mee te leveren met sommige apparaten, om zo te voorkomen dat gebruikers aanlopen tegen zaken in hun app die niet werken.

Door de verplichting zal het voor nieuwe apps onmogelijk zijn om een universeel apk-bestand te delen, iets wat bijvoorbeeld via bluetooth gebeurt in gebieden waar internetverbindingen langzaam of afwezig zijn. Diensten die apk's buiten de Play Store aanbieden, zoals APKMirror van Android Police en APKPure, zijn al voorbereid en hebben ondersteuning voor de installatie van App Bundles.

Bestaande apps hoeven niet over op App Bundles. Google raadt dat wel aan vanwege de voordelen ervan. Android kan apk-bestanden blijven installeren, al is het onbekend of dat in de toekomst zo zal blijven. Apk staat voor application package en is sinds de eerste versie het bestandsformaat voor Android-apps.

Reacties (71)

[reneflo]

"Android kan apk-bestanden blijven installeren, al is het onbekend of dat in de toekomst zo zal blijven."
De Play Store installeert uiteindelijk geen AAB's, maar deze AAB's worden uit elkaar gehaald tot verschillende APK's en de Store installeert dan de APK's die relevant zijn voor jouw toestel. Er is geen enkele reden om aan te nemen dat het installeren van APK's ooit niet meer mogelijk gaat zijn.

[dutchnltweaker]

Dat installeren van vrije apk is de reden waarom ik Android gebruik. Vervalt dit dan misschien toch eens verder kijken dan Android.

Edit:
Tendens begrepen, iets te snel conclusie getrokken.

[Reactie gewijzigd door dutchnltweaker op 23 juli 2024 01:01]

[lasharor]

Het verschil is dat je nu van die mirror sites een app bundle moet downloaden en die dan via een andere app moet installeren. Het is een beetje alsof je de keuze van de gebruiker (kiezen op de site welke APK je download) verplaatst naar het OS (Die automatisch het juiste installeert).

Als je nu op die mirror sites kijkt zie je bij sommige apps zo veel verschillende APK bestanden staan dat het niet direct duidelijk is welke je moet hebben.

[Arnage]

De opmerking in dit artikel over distribueren buiten de Play store om lijken niet te kloppen met andere berichtgeving. Zoals het hier omschreven staat zouden AAB enkel voordelen bieden, maar andere bronnen zoals bijvoorbeeld deze hebben het over een verplichte directere afhankelijkheid van Google, wat alternatieve distributie kanalen dus benadeeld:

Unlike APKs, Android App Bundles cannot exist outside of Google Play and cannot be distributed outside of it. This means that developers switching from APK to App Bundles can no longer provide the exact same package or experience on other app sources unless they opt to maintain a separate APK version

[dasiro]

een APK is redelijk device-onafhankelijk. Als jij in de grootstad 50 apk's download voor het dorp, dan kunnen die eens terug verdeeld worden over meerdere types toestellen. Dat gaat met AAB's mogelijks niet meer lukken, want je samsung galaxy J3 heeft mogelijks een iets ander bestand dan wat op een S5 kan gebruikt worden

[henry906]

apk's kunnen ook al architectuur specifiek zijn, bijvoorbeeld een apk voor elk van de volgende: "armeabi-v7a", "x86", "arm64-v8a", "x86_64"

Deze apk's zullen dan alleen werken op toestellen die diezelfde architectuur ondersteunen.

een app bundle is niks anders dan een pakketje wat al deze verschillende archtecturen bevat (en recourses voor alle verschillende scherm resoluties) en uit welke de store de precieze dingen haalt die je nodig hebt

[dasiro]

het kon idd, maar zo stonden ze niet in de play store

[- peter -]

Is een beetje onzin. Je kan met een commandline tool van Google gewoon uit een bundle een universal APK eruit extracten. Dat doen die custom installers ook. T is niet dat t een richtings verkeer is. Ik genereer in mijn build pipeline een bundle en daarna gelijk een universal APK, voor bijv. de Amazon App Store.

[Reactie gewijzigd door - peter - op 23 juli 2024 01:01]

[eppie]

Helaas dien je ook je private app signing key hiervoor te overhandigen aan google omdat het signen nu gebeurd door google play

[pven]

Waarom dan 'helaas'?

[ro8in]

Alles wat je online moet opslaan is (ja zelfs bij Google) bij voorbaat al onveiliger. Iemand kan met jouw key een fake versie van de app signen en daarna distribueren alsof het van jou komt. Of sterker nog zelfs met toegang tot je play store een app signen en uploaden. Die key wil je zeker in het geval van als je een maker bent van gevoelige apps zoals bijv een bankieren app of DigiD het liefst zo veilig mogelijk hebben staan, daarom helaas.

[Reactie gewijzigd door ro8in op 23 juli 2024 01:01]

[TweetCu]

Google kan potentieel aangepaste versies naar specifieke mensen pushen, of onder druk van overheid... dat zouden ze sowieso misschien nu ook wel kunnen denk ik...maar nu hebben ze meer controle.

Ander probleem met het niet toelaten van APK, is dat je verplicht bent om de Play Store als ontwikkelaars niet zelf de APK ergens uploaden (anders zou het misschien automatisch op zo een APK website belanden, voor oude versies van een app kan dat nu nog misschien handig zijn als de nieuwe versies ruk zijn), en dus alle zooi van Google te gebruiken om een app te kunnen krijgen, dus als je Google loos zover je kan wilt zijn op LineageOS, maar toch bepaalde apps wilt gebruiken, wordt dat lastiger.


Edit: Wil nog even zeggen dat ik het zorgelijk vindt dat Google dit implementeert, is net zoiets met dat AMP gebeuren, ja het is allemaal sneller, maar het centraliseert alles steeds meer bij Google, en iedereen die goed contact heeft met, of macht over hun, of hun heeft gehackt (hoewel bij dat wel andere manieren zijn om problemen te brengen via dat....maar miljoenen apps in een eierendoos klinkt wel aantrekkelijk om wat mee te doen zou ik denken).

Het signing proces zo die nu is, is een stuk vertrouwelijker en mogelijk veiliger sinds je dan de individuele developers moet vertrouwen of uitwijken, in plaats van in een keer 1 persoon voor Alles, dus daarmee zet je niet gelijk al je eieren in een doos, hetzelfde met hoe je websites vertrouwt.
Zo lang de dev maar zijn private key gewoon privé houd en beschermt, kan niemand zijn app signen en is het veilig...
De developer en klant weet zeker wat ze krijgen en versturen zonder dat een tussenpersoon ermee rommelt of ads, of spyware, in stopt, net als hoe ISP's in america bij HTTP verbindingen ads injecteren in websites, en dit niet kunnen bij HTTPS.


Anyway, mogelijk ga ik wel beetje ver, maar hopelijk met dit een idee waarom dit een groot probleem kan zijn, de voordelen van App Bundles zijn wel heel mooi, maar de afhankelijkheid van een bedrijf zonder dat je de app ergens anders vandaan kan halen zonder de afhankelijkheid, en dat je als dev volledig vertrouwen moet geven aan 1 ons kennende grote enge Amerikaanse bedrijf onder de Patriot Act, dat we de hele vertrouwelijkheid van certificaten gewoon teniet doen...

[Reactie gewijzigd door TweetCu op 23 juli 2024 01:01]

[tweaknico]

bij private / public keypair is het de bedoeling dat de public key overal en enrgens bescikbaar is en dat de private key onder controle van de afzender staat.
Als Google zo graag de publishing doet dan moet Google de EIGEN sleutel gebruiken niet de Private key van een ontwikkelaar... let wel het is ook de playstore die het pakket samenstelt, feitelijk is het niet meer de ontwikkelaar die de app maakt en levert maar google doet nog een redactie..

[eppie]

Google zou dan, in theorie, ook je app kunnen aanpassen en toch kunnen signen met jouw key.

[Stoelpoot]

Vanwege het woord "private" wat opeens niet meer zo accuraat is.

[frank87]

Dat is wel heel raar..
Je zou verwachten dat Google een eigen private key gebruikt, als Google over de inhoud gaat.
Wat door jou getekend is, hoort door jou in elkaar gezet te zijn.
(Dan verzint Google maar iets met getekende subsecties, voor de delenv die ze ongewijzigd inpakken)

[jimshatt]

Jawel, maar ik wil graag dat mijn bank-app getekend is door mijn bank. Ik heb geen verstand van App Bundles, maar als Google bij het bouwen van de APK allerlei vrijheden kan nemen dan wil je ook niet dat dat getekend is door iemand anders dan Google. Want je vertrouwt dan Google dat het in orde is, naast de uitgever.

Het zou fijn zijn als je de keuze krijgt tussen een APK gebouwd door Google uit de AAB (die overigens wel getekend is door de uitgever), of een APK getekend door de uitgever. Maar daar zal Google niet akkoord mee gaan denk ik zo.

[frank87]

Ik kan me heel goed voorstellen dat de ene keer het feit dat de bank het maakt zwaarder telt, en de andere keer dat de telefoon tot op de laatste optie ondersteund wordt.

[Cowamundo]

Geen kennis maar kan dit niet 2 delig?

Jij signed de bestanden waaruit de apk wordt gemaakt zodat deze niet aangepast kunnen worden en google signed vervolgens de apk zelf zodat zeker is dat de apk van google afkomstig is.

Edit: spelfouten en spaties.

[Reactie gewijzigd door Cowamundo op 23 juli 2024 01:01]

[svenk91]

Dan houd je het probleem dat ze zelf zaken in de APK er bij kunnen stoppen. Je mist de garantie dat de APK die Google maakt enkel bestaat uit bestanden die jij aanlevert als ontwikkelaar.

[ATS]

Ja, snap ik, maar je draait e.e.a. op een toestel dat al compleet op de software van datzelfde Google draait. Denk je niet dat als Google iets wil pushen ze daar wel betere manieren voor hebben?

[fre0n]

Het gaat er denk ik meer om wat je een app toevertrouwd, zonder dat jenzeker kunt zijn of er achterdeurtjes in zitten voor bv overheden om te kunnen sleepnetten. Google heeft andere belangen, wereldwijd afzetmarkt houden, dan een ontwikkelaar van een lokale app

[Reactie gewijzigd door fre0n op 23 juli 2024 01:01]

[ATS]

Natuurlijk, maar dat issue heeft niets te maken met deze verandering bij Google toch?

[svenk91]

Het is vooral dat ze er een manier bij hebben weer. Het wordt nu ook lastiger aan te tonen dat Google heeft gerommeld met je app.

[fre0n]

Jawel want het gebeurd nu onder signing van de lokale uitgever. Een uitgever die een neserlandse ontwikkelaar is die een nederlandse app maakt voor de nederlandse marlt verwacht je geen chinees of braziliaams achterdeurtje in, omdat die uitgever geen afzetmarkt heeft in die landen. Maar dat kan nu dus wel gebeuren omdat google daar WEL belangen heeft .

Echter gaat de gebruiker ervanuit dat t een nederlandse app voor de nederlandse markt is en dus vertrouwd.

[Reactie gewijzigd door fre0n op 23 juli 2024 01:01]

[paulmes]

Snap dit niet. APK's toegesneden op je toestel.
Hebben ontwikkelaars dan de beschikking over alle Android toestellen en versies?

[HollowGamer]

Nee, maar het zorgt denk ik ervoor dat je wel specifieke device feature kan ondersteunen. Ik denk hier vooral aan telefoons die kan opvouwen of simpele dingen als sensors/uitklapbaar toetsenbord. Er zal sowieso een stuk shared logica inzitten voor alle apparaten.

Nu zit het meeste van die specifieke logica aan de app kant, terwijl de end user deze mogelijk niet heeft. Daardoor is de APK groter en is er ook potentieel een kans dat iets wordt aangesproken dat niet kan/conflicten veroorzaakt. Elke check kost wellicht ook weer wat performance.

M.a.w. kleinere bundels en mogelijkheden voor optimistisch per toestel. Keerzijde lijkt me inderdaad wel dat je mogelijk per toestel afwijkingen krijgt of dat debuggen moeilijker wordt.

[Reactie gewijzigd door HollowGamer op 23 juli 2024 01:01]

[snarfdwarf]

Normale APK's bevatten dubbele resources zoals plaatjes in verschillende formaten.

[frank87]

Waarschijnlijk worden de opties die een bepaald toestel niet heeft automatisch uitgeschakeld.
Maar inderdaad, dat levert behoorlijke testproblemen op.

[- peter -]

Je bouwt native libraries bijv voor 4 platformen (ARM, ARM64, x86, x86_64), en een telefoon heeft altijd maar 1 nodig. In de apk die je krijgt van Google Play zijn dan (als je een bundle hebt geüpload) die niet gebruikte eruit geknipt. Dat scheelt een boel.

[DigitalExorcist]

Ik ben geen programmeur, verre van zelfs, maar is dat niet een soort JIT compiler die dit doet? (Misschien iemand met meer kennis die dit weet?). Dat het gecompileerd wordt op het moment dat je het bestand ophaalt zeg maar?

[svenk91]

Volgens mij kan het systeem ook nog een universele apk maken. Niettemin zal Google wel een stevige database met toestellen hebben, en de optie via de app store/play services zelf data te vergaren. Google ript zo goed als alle data van elke mobiel met Google Play, dus die weten een hoop

[CAPSLOCK2000]

waarbij de Play Store bij installatie een apk-bestand genereert voor alleen dat apparaat.

Dat klinkt als een ware hel om te debuggen. Dan weet je toch nooit zeker of de developer wel hetzelfde ziet als de gebruiker? Bij iedere (nog) onverklaarbare bug moet je dan overwegen of er misschien iets mis is gegaan bij het maken van de bundle.

Elders in de software wereld wordt er enorm veel moeite gedaan voor 'reproducible builds' zodat het beter voorspelbaar is wat de gebruiker krijgt. Dit lijkt helemaal de andere kant op te gaan.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 01:01]

[djiwie]

In de praktijk geen last van gehad. Voornaamste wat uit elkaar getrokken wordt zijn assets voor verschillende schermresoluties, zodat je op een device met een matige resolutie niet de xxxhdpi afbeeldingen hebt en op een grote tablet niet de mhdpi sizes. Dat scheelt nogal in de grootte van de uiteindelijke APK.

[holoduke51]

Maar ook vervelend als je multi language op je telefoon hebt. Met een bundel krijg je maar een taal geïnstalleerd. Sommige landen wordt dat veel gebruikt.

[svenk91]

Enig idee hoe dit werkt als je de resolutie aanpast? Op tablet en pc toch niet ongebruikelijk.

[jorisvergeerTBA]

Dat zal allemaal wel meevallen. Als jij een APK runt, dan draai je ook alleen de binaries voor de architectuur van jouw test apparaat. Wie zegt dat er geen fout zit in een andere architectuur dan de architectuur van jouw test apparaat.

Voor ontwikkelaars verandert er vrij weinig behalve dat je een ander type output bestand upload naar google.

[Umbrah]

Hmmm, zou dit iets te maken hebben met de wens van andere platformen om óók native Android apps te willen draaien, zoals Windows 11? Gewoon om puur alternatieve stores af te snijden door het "lastiger" te maken?

[Bensjero]

Windows 11 draait geen native Android apps. Het gaat om een samenwerking met Amazon die een soort runtime app voor Windows 11 gemaakt heeft waarin Android apps werken.

[mrdodojo]

Dit klopt niet. Windows 11 zal android apps via het WSA (WSL maar voor Android) draaien, de Amazon store is gewoon toegevoegd aan de Microsoft store, andere apps kan je gewoon nog sideloaden.

[Bensjero]

Ok, goed om te weten. Dat klinkt beter dan hoe youtuber Marques Brownlee het uitlegde.

[keranoz]

Hij probeert het natuurlijk uit te leggen op een manier die voor zo veel mogelijk mensen begrijpelijk is.

[PrimusIP]

Ik vraag me af of Google het zelfde gaat doen als wat Apple gedaan heeft.

IOS apps draaien in principe ook onder MacOs (mits je M1 processor hebt), maar als developer heb je een opt-out optie. Hier maken vervolgens een hoop ontwikkelaars (zoals de Facebook groep) gebruik van.
Via een omweggetje kon je dit in het begin omzijlen. Je kon de apps (*.IPA) van de appstore plukken en je ze vervolgens op de Mac installeren. Dat is inmiddels niet meer mogelijk. Bij installeren krijg je de melding dat die app niet voor dit platform is bedoeld.
De enige reden die ik me kan bedenken waarom Apple dit doet is de keuze van de ontwikkelaar af te dwingen.

Ik vraag me af voor Google er ook zoets achter zit. En misschien dan niet voor die ontwikkelaarskeuze, maar dan meer om te voorkomen dat Apps op platformen geïnstalleerd worden die niet officieel aan hun Appstore verbonden zijn. (een Huawei, een Android fork, een pc waar iets op draait wat in principe Android apps zou kunnen draaien, etc.)

[locke960]

Hoe gaan Mobile Device Management systemen zoals SOTI hier mee om?
Nu kun je nog een APK via SOTI installeren op apparaten die geen toegang tot het internet hebben. Dat maakt in veel situaties beveiliging een stuk eenvoudiger.

Als ik dit verhaal goed begrijp kan dit niet meer?

[svenk91]

Dit kan nog wel.

Je APK uit de app store halen kan niet meer direct. Je kan wel de bundle uit de app store halen en daar een (universele) apk van maken geloof ik.

[DutchKevv]

Nog sneller?

Het valt me op dat vergeleken met Apple App Store, installatie al verdomd snel is.

Game regelmatig tegen mijn broer die een iPhone 11 heeft..

Op zelfde WiFi Netwerk, zelfde game, zelfde starttijd is mijn OnePlus budget phone haast altijd 50% sneller en opgestart in de game. Volgens mij vanwege sterke compressie.

Maar wel jammer dat APK niet meer onderling gedeeld kan worden.

Even voor de duidelijkheid, inclusief installeren dus. Vandaar op de eerste regel 'installatie al verdomd snel is'

Kortom allebij installeren en opstarten

[Reactie gewijzigd door DutchKevv op 23 juli 2024 01:01]

[Bensjero]

Het gaat hier toch over de snelheid van de installatie toch? Niet over opstarttijd.
Daarnaast ligt het waarschijnlijk aan hoe de desbetreffende app geprogrammeerd is in jou voorbeeld en nauwelijks aan het verschil in OS.

[HollowGamer]

Daarnaast is de installatie van een APK helemaal niet zo snel. Als ik een eigen APK push via Android Studio of handmatig installeer, dan duurt dit soms wel één minuut of langer. Inderdaad afhankelijk van de bundel, maar via de Play Store duurt het ook al lang.

Ik heb een vrij nieuw toestel, maar op oudere/minder krachtige zal het nog langer duren. Doe maar eens een re-install van je toestel, dat duurt vaak ontzettend lang voordat al je vorige apps uit de Play Store op je toestel weer staan geïnstalleerd (download tijd daarbuiten gelaten).

Nee, voor mij zou dit zeker een toegevoegde waarde zijn.

[Reactie gewijzigd door HollowGamer op 23 juli 2024 01:01]

[pven]

Je vergelijkt starttijd met installatietijd, volgens mij is dat iets met appels en peren.

[pven]

Dan is het toch een onzinnige vergelijking? In het artikel gaat het alleen over het installeren.

[DutchKevv]

Klopt..

Had het dus ook over hele flow

Downloaden, installeren, opstarten..

Maar zo veel -1,

Stik maar.

Nutteloos om iets te noemen..

(Zet regelmatig volledige test straten op als dev, maar als je dit toch leest, geef me anders gewoon -1)

Daar red je levens mee.
Stumpers

[Reactie gewijzigd door DutchKevv op 23 juli 2024 01:01]

[Zeror]

Ik ben eigenlijk wel benieuwd in hoeverre dit invloed gaat hebben op de websites, zoals APKMirror etc..., die APK bestanden aanbieden.

[Anoniem: 1532362]

Het artikel waar je op reageert benoemd dit gewoon.

"Diensten die apk's buiten de Play Store aanbieden, zoals APKMirror van Android Police en APKPure, zijn al voorbereid en hebben ondersteuning voor de installatie van App Bundles."

Als je dit artikel mag geloven, heeft dit dus niet veel invloed.

Nou kan ik je wel wat meer vertellen wat hier niet benoemd wordt, die websites willen al heel lang dat je hun app download en via hun app i.p.v. de website de APK's download. Dit is voor hun een goede reden, want dan kunnen ze makkelijker detecteren wat voor .aab bestand voor jou nodig is.

Want het lijkt me lastig voor hun om te detecteren welke .aab ik nodig heb voor mijn telefoon, als ik vanaf mijn Windows PC de website bezoek. En het is maar de vraag of ze je dan handmatig de benodigde gegevens laten invoeren.

[Reactie gewijzigd door Anoniem: 1532362 op 23 juli 2024 01:01]