Android-ontwikkelaars moeten in 2019 ook 64bit-versies van apps aanbieden

Google heeft nieuwe richtlijnen voor Android-ontwikkelaars gepubliceerd, waardoor het vanaf augustus 2019 is vereist om ook een 64bit-versie van een app naast een 32bit-versie aan te bieden. Daarnaast kondigt Google veranderingen voor api-levels en beveiliging aan.

Google meldt in een aankondiging dat het de maatregel neemt omdat het verwacht dat er in de toekomst Android-toestellen zullen uitkomen die alleen 64bit-ondersteuning hebben. Daarom moeten apps die een 32bit-softwarebibliotheek aan boord hebben vanaf de helft van 2019 ook een 64bit-alternatief bieden. Hetzelfde geldt voor updates. Sinds Android 5.0 is er 64bit-ondersteuning en volgens Google ondersteunt inmiddels meer dan 40 procent van alle Android-toestellen deze architectuur. Apple ondersteunt 32bit-apps sinds iOS 11 helemaal niet meer.

Daarnaast moeten ontwikkelaars vanaf augustus van volgend jaar hun nieuwe apps richten op gebruik van api level 26, wat staat voor Android 8. Daarbij gaat het om targetSdkVersion en zijn ontwikkelaars dus vrij om ook oudere Android-versies te ondersteunen. Bepaalde nieuwe functies werken alleen als apps expliciet gericht zijn op gebruik van een bepaald api-level, aldus Google. Vanaf november 2018 geldt die eis ook voor updates van bestaande apps en vanaf 2019 gaat binnen een jaar na elke nieuwe Android-versie, zoals Nougat en Oreo, de eis van targetSdkVersion mee omhoog naar een nieuw api level.

De laatste wijziging betreft het toevoegen van 'beveiligingsmetadata' aan Android-apk's. Dat dient ter verificatie dat het daadwerkelijk om een app gaat die via Google Play is verspreid. Hiervoor hoeven ontwikkelaars geen maatregelen te nemen.

Reacties (29)

[sspiff]

Om mogelijke verwarring te vermijden, Google verplicht met de targetSdkVersion niet om oudere versies van Android niet langer te ondersteunen in nieuwe apps:

Developers remain free to use a minSdkVersion of their choice, so there is no change to your ability to build apps for older Android versions.

[Verwijderd]

Nou, sommige zaken werken anders of niet meer bij een hogere targetSdkVersion dus het is wel iets meer dan het eenvoudig verhogen van dat getal in bv. build.gradle.

De truc om gekleurde iconen in de notification balk te krijgen door de targetSdkVersion to values < 21 te zetten gaat dan ook niet meer werken.

[Reactie gewijzigd door Verwijderd op 29 juli 2024 12:57]

[Rafe]

Versie 23 (Android 6.0) targeten dwingt het vragen om runtime permissions af, privacy is iets belangrijker dan een gekleurd icon

[Reactie gewijzigd door Rafe op 29 juli 2024 12:57]

[markb1994]

Iconen in de notificatiebalk horen wit te zijn, dus dit is alleen maar positief!

[Reactie gewijzigd door markb1994 op 29 juli 2024 12:57]

[Verwijderd]

Vind Google, maar het is soms erg onduidelijk. Zo kun je met bv. een groen en een rood icoon heel makkelijk laten zien of je verbinding hebt of niet.

[Lrrr]

Als gebruiker vind ik dit erg lelijk. Dan doe je maar 2 verschillende icoontjes.

[Helium-3]

Daar ben ik het helemaal mee eens. Uniformiteit en strak design vind ik heel belangrijk. Al mijn eigen projecten, websites en apps voldoen dan ook aan het google-internet, en bevatten altijd de nieuwste technieken. Progressief zijn, code herschrijven en gewoon af en toe je app eens omgooien (achter de schermen dan) doet erg goed. Niet lui en conservatief zijn "want het werkt toch"

[Verwijderd]

De huidige platte en minimalistische mode bij grafisch ontwerpers vind ik spuuglelijk dus ik wil dat graag anders doen en daarbij niet tegengewerkt worden door het systeem.

[Helium-3]

Ahja Natuurlijk kunnen de meningen verschillen. Ik vind wel fijn dat google een beetje apps forceert naar 1 richting, want een mix ziet er niet uit. Dan beter óf kleuren óf strak wit (en mijn voorkeur gaat sterk uit naar die laatste)

[duqu]

Klopt, dat zet ik er inderdaad nog even bij!

[theduke1989]

Is altijd goed om nieuwe regeling te zien betreft beveiliging. Maar toch hoort Google de applicaties van te voren te keuren en kijken of ze aan de. "eisen" voldoend. Zo niet meteen verwijderen.

[Anonymoussaurus]

Waar wordt er dan gezegd dat Google apps niet keurt en niet kijkt naar de eisen? Google doet dat wel (al sinds 2015): https://www.theverge.com/...ps-now-reviewed-by-google

[Reactie gewijzigd door Anonymoussaurus op 29 juli 2024 12:57]

[graey]

Dat klinkt simpel, maar als je kijkt naar de hoeveelheid apps, en de manieren waarop je (ongezien) ongewenste dingen kan doen, is het simpelweg niet altijd alleen maar aan de code te zien.

[brogamma]

Ben het met je eens. Maar als een erkende ontwikkelaar die al een keuze van de redactie is, dan lijkt me dat Google de app niet gaat keuren.

[Verwijderd]

Nou leuk zeg, dan gaan apps die grote native libraries gebruiken dus weer veel groter worden. Ik hoop dat het dan wel eenvoudiger wordt om meer versies aan te bieden zodat je de mensen die het niet nodig hebben niet opscheept met die 64 bit libraries (zelfde verhaal voor mips en x86 libs trouwens).

[lonaowna]

Dat hoeft niet hoor. Ze kunnen twee verschillende APKs maken: een voor arm en een voor arm64. Kijk bijvoorbeeld maar naar Google Docs, die heeft het ook opgesplitst, en de arm en arm64 zijn vrijwel identiek in grootte.

[Verwijderd]

Ik weet dat het kan, maar veel appbouwers zullen het niet doen. Nou ja, dat geeft weer een markt voor apkstrippers die overbodige platformen eruit gooien.

[DrBreakalot]

Sinds deze zomer worden nieuwe apps automatisch opnieuw gesignd door de Play Store. Voor bestaande apps is het ook mogelijk dit te migreren en door de Play Store te laten doen.
In principe is het dus mogelijk dat Google in de Play Store automatisch de APK opsplitst voor verschillende architecturen.

[Verwijderd]

Uit die link haal ik dat het opt-in is. En dat is maar goed ook, apps als Signal zullen hier nooit in meegaan om te voorkomen dat een toekomstige regering ooit Google zal kunnen dwingen een backdoored versie te signen en te pushen.

[DrBreakalot]

Je hebt gelijk, het is inderdaad opt-in. Neemt niet weg dat het voor veruit de meeste apps een goede oplossing.
Of Signal hierin nooit meegaat zou ik niet durven zeggen: ze hebben ook een iOS app en daarop gaat alle signing via Apple. Backdoored iOS-versies zouden dus al mogelijk zijn.

[Verwijderd]

Dat zoiets op het systeem met het kleinste marktaandeel kan wil natuurlijk niet zeggen dat je dan de bulk van de systemen ook maar kwetsbaar moet maken.

[Becquerel]

Gewoon op store level fixen dat de store bepaalt welke versie, en met advanced options dat jij kan kiezen.

[itcouldbeanyone]

Hoe zit dat met verouderde apps, worden die verwijdert uit de playstore ,als zij er niet aan voldoen

[Verwijderd]

Geen idee, maar ik ben blij dat ik van alles wat ik gebruik de apk bewaar. Als ze apps massaal gaan dumpen zullen gebruikers reageren door meer buiten Google Play om te installeren (al is Google dat ook al lastiger aan het maken in Android .

[funrider]

Bij Apple is dat (nog) niet bij de App Store gedaan, daar blijven ze actief staan in de App Store ook al zijn ze 32 bit. Daar zie je ze echter niet meer verschijnen wanneer je ernaar zoekt met een iOS11 device. Met iOS10 en lager zul je de apps nog wel vinden en ook online.

[mjz2cool]

ik denk niet dat bestaande apps verwijderd worden, het gaat om nieuwe apps met target sdk 26. verouderde apps zullen meestal een oudere target sdk gebruiken.

[magnat505]

Hoezo werken bij iOS sinds dit jaar apps niet eens meer onder 32 bit en is het bij google in 2019 pas verplicht om uberhaupt een 64 bit versie te maken.....

[Becquerel]

Omdat mensen denken dat een hoger cijfer gelijk staat aan beter, dus is het al gefikst voor de iphone hype.

[!mark]

Omdat er nog genoeg toestellen zijn waarbij de chipset geen 64bit instructieset heeft.
Voordat 32bit support op Andriod gedropped kan worden zullen er eerst nog wel wat jaartjes moeten verstreiken