AD

Dès le 1er novembre 2025, Google Play exigera que toutes les applications ciblant Android 15 ou supérieur soient compatibles avec les pages mémoire de 16 Ko. Une évolution technique incontournable qui bouscule les habitudes des développeurs, mais qui ouvre aussi la porte à des applications plus performantes, plus stables et mieux optimisées pour la prochaine génération de smartphones.

Google a confirmé ce changement sur son blog développeurs ainsi que dans la documentation Android. Concrètement, toute application ou mise à jour publiée sur Google Play et ciblant Android 15 (API niveau 35) ou supérieur devra fonctionner correctement sur des appareils configurés avec une taille de page mémoire de 16 Ko.

Date clé : 1er novembre 2025.
Sans compatibilité, la mise en ligne ou la mise à jour d’une application sera refusée.

Qu’est-ce qu’une “page mémoire” ?

Une page mémoire est l’unité fondamentale de gestion mémoire utilisée par un système d’exploitation. C’est la taille minimale utilisée par le processeur et l’OS pour :

• allouer et protéger la mémoire,
• mapper des fichiers ou bibliothèques en RAM,
• gérer la mémoire virtuelle.

Jusqu’ici, Android fonctionnait avec des pages de 4 Ko. Les nouveaux processeurs ARM (et certains x86_64) basculent vers des pages de 16 Ko.

Exemple simple :

• Un fichier binaire de 8 Ko occupe deux pages en configuration 4 Ko, mais une seule page en configuration 16 Ko.
• Résultat : moins de fragmentation, moins de tables de pages, gestion mémoire plus rapide et consommation énergétique réduite.

Pourquoi ce changement ?

Google justifie cette évolution par plusieurs avantages :

• Démarrage plus rapide des applications.
• Lancement accéléré de l’appareil photo.
• Amélioration de la réactivité générale du système.
• Réduction de la consommation énergétique.
• Renforcement de la sécurité en limitant certaines failles exploitables liées à la gestion mémoire.
• Préparation aux architectures matérielles des prochaines générations de smartphones.

Qui est concerné ?

Applications en Java ou Kotlin uniquement
La compatibilité est globalement assurée. Ces applications n’utilisant pas de code natif bénéficient de la gestion mémoire de la machine virtuelle. Toutefois, il reste fortement recommandé de tester dans un environnement configuré en 16 Ko (émulateur Android 15 ou appareil compatible).

Applications utilisant du code natif ou des SDK tiers
Ce sont elles les plus impactées. Toute application qui embarque des bibliothèques compilées en C, C++, Rust ou autres doit être recompilée et adaptée. Les dépendances tierces qui ne sont pas compatibles provoqueront des plantages. Résultat : rejet de l’application lors de la publication.

Applications Flutter et compatibilité 16 Ko

Contrairement aux apps Android “pures” en Java/Kotlin, toutes les apps Flutter sont concernées par la transition 16 Ko.
Pourquoi ? Parce que :

• Flutter n’exécute pas uniquement du code Dart.
• Le moteur Flutter (rendu graphique, runtime Dart, bindings plateforme) est compilé en C++ et packagé dans ton APK/AAB sous forme de bibliothèques natives (libflutter.so, libapp.so).
• Ces .so doivent être compatibles avec les tailles de page mémoire de 16 Ko.

Les implications pour un projet Flutter

1. Moteur Flutter lui-même :
   • Les versions récentes de Flutter (3.27 et supérieures) utilisent un NDK à jour et sont déjà compilées avec le support 16 Ko.
   • Si tu es sur une version trop ancienne, il faudra mettre à jour Flutter et le moteur.
2. Plugins et dépendances Flutter :
   • Tous les plugins qui contiennent du code natif (par exemple firebase_ml, camera, video_player, ou certains plugins de pub comme AdMob) embarquent des .so.
   • Si un plugin est mal compilé (par exemple avec une constante 4096 en dur), il peut casser sur 16 Ko.
   • Les mainteneurs doivent mettre à jour leurs plugins, mais en attendant c’est toi qui assumes le risque.
3. Ton propre code natif (si tu utilises un android/ avec JNI ou un plugin maison) :
   • Tu dois recompiler ton code avec NDK r28+.
   • Ajouter les flags de linker si nécessaire :

-Wl,-z,max-page-size=16384 -Wl,-z,common-page-size=16384

1. Tests indispensables :
   • Même si tu n’écris pas toi-même de C++, ton app Flutter charge des bibliothèques natives.
   • Tu dois impérativement tester ton APK/AAB sur un émulateur Android 15 configuré en 16 Ko ou sur un Pixel 8/9 activé en 16 Ko.

Exemple concret pour Flutter

• Tu lances un flutter build appbundle.
• Tu analyses ton .aab dans Android Studio → tu verras les .so comme libflutter.so.
• Tu testes sur un environnement 16 Ko.
• Si un plugin n’est pas compatible, ton app plantera au démarrage.

Ce que ça veut dire pour toute app Flutter

• Impossible de se dire “je ne fais que du Dart, je suis tranquille” : Flutter embarque forcément du natif.
• La compatibilité 16 Ko est donc une obligation directe pour toute app Flutter, exactement comme pour Unity ou React Native.

Étapes pour préparer une application

1. Identifier la présence de code natif
Dans Android Studio, utiliser la fonction “Analyze APK”. Si des fichiers .so apparaissent, l’application est concernée.

2. Adapter la compilation NDK

• Avec NDK r28 et supérieur : la compatibilité 16 Ko est activée par défaut.
• Avec NDK r27 ou antérieur : ajouter les options suivantes au moment de l’édition des liens :

-Wl,-z,max-page-size=16384 -Wl,-z,common-page-size=16384

3. Corriger le code dépendant d’une taille de page fixe
Exemple de mauvaise pratique encore trop répandue :

#define PAGE_SIZE 4096

Ce code doit être remplacé par une approche dynamique :

#include <unistd.h>
long page_size = sysconf(_SC_PAGESIZE);

4. Tester en environnement 16 Ko

• Émulateur Android Studio (Android 15) avec images système en 16 Ko.
• Appareils physiques compatibles (Pixel 8, Pixel 9, etc.) via l’option développeur.
• Plateformes de tests à distance comme le Samsung Remote Test Lab.

Commande utile pour vérifier la taille de page d’un appareil :

adb shell getconf PAGE_SIZE

La valeur attendue est 16384.

5. Vérifier l’alignement de l’APK
Avant publication, s’assurer que l’APK est bien aligné :

zipalign -c -P 16 -v monApp.apk

Un binaire mal aligné sera rejeté par le Play Store.

Les difficultés actuelles

• Certaines bibliothèques populaires (FFmpeg, anciens modules de React Native, certains SDK de machine learning) ne sont pas encore prêtes pour 16 Ko.
• De nombreux développeurs demandent déjà un délai supplémentaire à Google.
• Malgré ces demandes, Google a fixé la date butoir et ne prévoit pas de report.

Enjeux pour les entreprises et les développeurs

Ce changement n’est pas un simple détail technique. Il conditionne directement la possibilité de publier sur Google Play.

• Une application non compatible sera bloquée.
• Les éditeurs qui s’adaptent rapidement profiteront d’applications plus rapides, plus fiables et plus compétitives.

La position de SIDL CORPORATION

« Nous considérons cette transition comme une étape nécessaire vers un Android plus moderne et plus performant. Elle demande un effort réel d’adaptation mais représente une opportunité pour livrer des applications robustes et prêtes pour les années à venir. Les développeurs qui anticipent dès maintenant cette évolution garantiront leur présence durable sur Google Play. »

À retenir

• Date limite : 1er novembre 2025.
• Obligation pour toute application Android 15+ publiée sur Google Play.
• Vérifier la présence de code natif, recompiler avec le bon NDK, tester en environnement 16 Ko.
• Ne rien faire équivaut à un rejet automatique de l’application.

AD