Pages mémoire de 16 KB: comment corriger l’erreur Google Play

L’avertissement est court, il nomme un fichier au mieux, et il arrive alors que vous pensiez déjà le build terminé. C’est pour cela que les trois mêmes fausses pistes reviennent sans cesse: on fait confiance à une échéance qui a bougé, on met à jour un framework en supposant que le travail est fait, ou on vérifie un seul APK local sans jamais regarder le bundle à partir duquel Google construit réellement. Cet article est organisé comme le problème se résout vraiment, identifier, attribuer, réparer, prouver, et tout ce qui s’y trouve est à jour au 5 août 2026, vérifié dans le guide de Google sur les tailles de page le jour même de sa dernière mise à jour. Quand la preuve vient de l’issue tracker d’un mainteneur plutôt que d’une note de version officielle, la page le dit sur la carte au lieu d’arrondir cela en fait établi.

Corriger en trois étapes

L’exigence elle-même est étroite. Le guide de Google sur les tailles de page indique que les applications ciblant Android 15 (niveau d’API 35) ou supérieur doivent prendre en charge les pages mémoire de 16 KB sur les appareils 64 bits, et qu’à partir du 1er février 2027 vous ne pourrez plus publier de mises à jour qui ne le font pas. Cela ne concerne que le code natif. Si votre application et chaque bibliothèque ou SDK qu’elle contient sont en Java ou Kotlin pur, Google indique que votre application prend déjà en charge les appareils 16 KB. Le problème, c’est que la plupart des développeurs qui voient cet avertissement se croient dans cette catégorie sans y être.

Toute la décision, sur un seul écran

Avant de changer la moindre version de dépendance, parcourez ceci. Cela prend environ deux minutes et c’est la différence entre corriger la bonne chose et mettre à jour onze paquets qui n’ont jamais été le problème.

Ce que signifie vraiment l’avertissement de la Play Console

La formulation compte, parce que la version paniquée de cette histoire voyage plus vite que la version exacte. Lisez les chaînes que Google affiche réellement et le périmètre devient étroit et gérable.

Deux lectures de cette carte sont couramment fausses. D’abord, "Action by Feb 1, 2027" n’est pas un compte à rebours vers une suppression: le texte de Google sur la même page décrit la conséquence comme l’impossibilité de publier ces mises à jour. Ensuite, la chaîne Extension granted apparaît bien sur la capture de Google, mais cela n’établit pas qu’un parcours de demande de prolongation vous soit actuellement ouvert. Ne considérez une prolongation comme réelle que si vous voyez l’option dans votre propre Play Console.

Quelle échéance avez-vous réellement lue?

Trois dates circulent et une seule est vivante. Choisissez celle que vous avez vue et l’outil résout son statut face à la page actuelle de Google, mise à jour pour la dernière fois le 5 août 2026.

L’exigence des 16 KB concerne-t-elle mon application?

Applications en Java ou Kotlin pur

Google est sans ambiguïté ici: si votre application et l’ensemble de ses bibliothèques et SDK n’utilisent que Java ou Kotlin, votre application prend déjà en charge les appareils 16 KB. Google recommande tout de même de tester dans un environnement 16 KB pour détecter des régressions inattendues, ce qui vous coûte une exécution d’émulateur.

Le piège tient dans la formule "et l’ensemble de ses bibliothèques et SDK". Une seule dépendance de base de données, d’analytics, de rapport de plantage, de média, de cartographie, d’apprentissage automatique ou de sécurité peut ajouter des binaires natifs à un projet dont le code source ne contient que du Kotlin. "Je n’ai pas écrit de C++" n’est pas une preuve. Le dossier lib, si.

Flutter, React Native, Unity, Kivy et générateurs no-code

Ces stacks livrent par conception des runtimes natifs, des binaires de moteur et des bibliothèques de plugins: elles sont donc presque toujours dans le périmètre. Google cite explicitement les générateurs d’applications tiers qui utilisent des bibliothèques natives parmi les façons dont une application peut être concernée alors que son auteur n’a jamais écrit de C ni de C++. Ce qui varie, ce n’est pas si vous avez du code natif mais quel paquet a fourni la pièce fautive: c’est pour cela qu’attribuer le nom de fichier passe avant toute mise à jour.

Comment vérifier, exactement

Ouvrez l’APK de production, dépliez lib, et regardez les dossiers d’ABI qu’il contient, normalement arm64-v8a et x86_64. La présence du moindre fichier objet partagé signifie que votre application utilise du code natif. Aucun fichier .so et aucun dossier lib signifie que cet APK n’utilise pas de code natif du tout. La colonne Alignment de l’analyseur affiche des avertissements pour les fichiers qui ont un problème d’alignement: c’est le chemin le plus rapide pour passer de "quelque chose ne va pas" à un nom de fichier.

Pourquoi un binaire 4 KB échoue sur un appareil 16 KB

C’est tout le mécanisme, et il explique le seul nombre que vous allez voir revenir. L’alignement s’exprime en puissance de deux: 2**12 vaut 4096 octets, 2**14 vaut 16384 octets. La règle de Google est que chaque segment LOAD d’une bibliothèque native doit être aligné sur 2**14 ou plus. Une bibliothèque compilée en 2**14 fonctionne à la fois sur les appareils 4 KB et 16 KB, parce que 16384 est un multiple exact de 4096. Une bibliothèque compilée en 2**12 ne fonctionne que sur la plus petite taille de page. C’est cette asymétrie qui fait que la correction consiste toujours à "monter l’alignement" et jamais à "détecter l’appareil".

Il existe une seconde contrainte, entièrement distincte, qui vit en dehors de la bibliothèque. Les bibliothèques natives stockées non compressées dans un APK doivent elles aussi se placer sur une frontière de 16 KB à l’intérieur de l’archive ZIP. C’est une propriété d’empaquetage, contrôlée avec zipalign et configurée par votre plugin de build, et elle peut être fausse alors que chaque bibliothèque à l’intérieur est parfaitement alignée. Garder ces deux idées séparées est la chose la plus utile à retenir de cette section.

Le correctif le plus court pour chaque framework

Toutes les références dans un tableau

Les niveaux de confiance ont le même sens partout sur cette page. VÉRIFIÉ signifie qu’une source primaire actuelle l’affirme directement. PARTIEL signifie qu’une source fiable soutient l’affirmation centrale mais pas tous les détails d’implémentation. SIGNALÉ signifie que la preuve est l’issue tracker d’un mainteneur ou des rapports de développeurs plutôt qu’une note de version officielle.

Trouver la bibliothèque exacte à l’origine de l’erreur

Commencez dans APK Analyzer

Ouvrez Build > Analyze APK..., chargez l’APK de production, et dépliez lib. À l’intérieur vous verrez un dossier par ABI, normalement arm64-v8a et x86_64. La colonne Alignment affiche des messages d’avertissement en face des fichiers qui ont un problème d’alignement. Les avertissements propres à Android Studio et Lint mettront eux aussi en évidence les bibliothèques natives non conformes: vous pouvez donc voir le même constat remonter à plusieurs endroits.

Notez chaque nom de fichier signalé avant de toucher au moindre numéro de version. Contrôlez les deux dossiers d’ABI séparément: il est tout à fait normal que arm64-v8a passe alors que x86_64 échoue, ou l’inverse, parce que ce sont des binaires différents compilés par des pipelines potentiellement différents.

Décoder la sortie en ligne de commande

Si vous préférez travailler dans un terminal, Google livre check_elf_alignment.sh, qui rapporte ALIGNED ou UNALIGNED pour un APK, et vous pouvez inspecter une bibliothèque isolée avec llvm-objdump. Les deux exigent Android SDK Build-Tools 35.0.0 ou plus récent. Collez ci-dessous ce qu’ils affichent et l’outil vous le relira.

Déterminer quelle dépendance la fournit

La Play Console et APK Analyzer vous donnent tous les deux un nom de fichier et aucun propriétaire. Saisissez-le ci-dessous et l’outil vous dira ce que l’on sait de ce binaire, avec la qualité de la preuve attachée, et vous donnera les commandes de recherche avec votre nom de fichier déjà en place.

Vérifier l’app bundle, pas seulement l’APK local

C’est le mécanisme derrière la version la plus frustrante du problème: le développeur met tout à jour, inspecte l’APK local, obtient une sortie propre, importe, et l’avertissement est toujours là. Rien de ce qu’il a vérifié n’était faux. Il n’a simplement jamais vérifié ce que Play évalue.

Lancez donc ceci sur le bundle que vous vous apprêtez à importer, à chaque fois:

bundletool dump config --bundle=app-release.aab | grep alignment

PAGE_ALIGNMENT_16K est le résultat que vous voulez. PAGE_ALIGNMENT_4K signifie que le bundle demande à bundletool d’empaqueter les bibliothèques natives sur des frontières de 4 KB: chaque APK que Play en tire sera donc faux. Google avertit spécifiquement qu’Android Gradle Plugin 8.3 à 8.5 peut produire exactement cet écart: le build local paraît aligné, et l’application que Play construit à partir du bundle ne s’installera pas correctement sur un appareil 16 KB. La correction à privilégier est le passage à Android Gradle Plugin 8.5.1 ou plus récent.

Toutes les commandes, avec vos propres noms de fichiers

Saisissez vos noms de fichiers une seule fois. Chaque commande ci-dessous se réécrit, et chaque onglet affiche la sortie exacte qui compte comme une réussite: vous ne devinez jamais si un résultat était bon.

AGP, NDK et le piège de l’empaquetage

Le terrain dangereux, c’est Android Gradle Plugin 8.3 à 8.5. Dans cette plage, un build local peut sembler parfaitement correct alors que bundletool n’aligne pas en ZIP les APK qu’il produit à partir de votre bundle pour Play, et la formulation de Google est sans détour sur le résultat: l’application construite à partir de ce bundle ne s’installera pas correctement. Si vous êtes en 8.5.0 et que votre APK local passe toutes les vérifications imaginables, c’est la première chose à écarter.

Référence des réglages de build

Ce que l’empaquetage ne peut pas corriger

Si votre propre code C ou C++ suppose une taille de page, aucun réglage de build ne vous sauvera. Retirez les valeurs 4096 codées en dur et toute dépendance à une constante PAGE_SIZE fixe, interrogez la vraie valeur à l’exécution avec getpagesize() ou sysconf(_SC_PAGESIZE), et passez en revue chaque appel à mmap() ainsi que tout argument que vous alignez sur une page à la main. C’est la catégorie de panne où une application s’installe proprement sur un appareil 16 KB, passe les contrôles du bundle, puis plante la première fois qu’elle touche au mappage mémoire.

Tester dans un vrai environnement 16 KB

Vous avez trois voies pratiques et deux voies spécialisées. Prenez celle à laquelle vous pouvez réellement accéder aujourd’hui: pour détecter les défaillances de taille de page, il n’y a aucune différence de qualité entre elles.

adb shell getconf PAGE_SIZE

Ce qu’il faut réellement solliciter

Une fois l’environnement confirmé, le passage de test utile n’est pas "est-ce que ça démarre". Les défaillances natives se concentrent dans les fonctionnalités qui touchent au code natif: sollicitez-les donc délibérément, démarrage à froid, navigation dans l’application, appareil photo, lectures et écritures en base de données, lecture et enregistrement de médias, authentification, tâches en arrière-plan, toute fonctionnalité d’apprentissage automatique ou de réalité augmentée, chaque surface de plugin natif, et tout ce qui, dans votre propre code, utilise le mappage mémoire. Si une fonctionnalité repose sur une des bibliothèques que vous venez de mettre à jour, cette fonctionnalité est le test.

Pourquoi l’avertissement survit à une mise à jour

Deux de ces cas méritent une réserve plutôt qu’une réponse assurée. Aucune source primaire n’établit le délai que met Google Play à réévaluer un bundle importé: si votre avertissement persiste juste après un import, la démarche honnête consiste à confirmer que le nouveau code de version apparaît bien dans vos dernières versions et app bundles, puis à revérifier plus tard, plutôt qu’à faire confiance à un chiffre lu quelque part sur les délais de traitement. Et une application qui ne tourne que parce que le mode de compatibilité est intervenu n’a pas été corrigée: elle a été accommodée.

Les bibliothèques tierces qui reviennent sans cesse

Servez-vous en comme point de départ quand un nom de fichier vous semble familier, puis vérifiez face aux versions actuelles et aux issues ouvertes du projet concerné. Quand la preuve vient de l’issue tracker d’un mainteneur plutôt que d’une note de version, la carte le dit.

Le lien avec l’échéance API 36 du 31 août 2026

Google Play impose aux nouvelles applications et aux mises à jour de cibler Android 16 (niveau d’API 36) à partir du 31 août 2026, avec une prolongation possible jusqu’au 1er novembre 2026. C’est un changement de manifeste et de comportement. La règle des 16 KB, elle, est un changement de compatibilité binaire. Le développeur qui monte targetSdk un lundi et voit un avertissement 16 KB le mardi n’a rien cassé: les bibliothèques natives étaient déjà compilées pour des pages de 4 KB, et le niveau cible plus élevé a simplement fait entrer l’application dans le périmètre d’un contrôle qui allait de toute façon s’appliquer.

En pratique, traitez-les comme une seule migration avec deux preuves. Vous allez monter le niveau cible de toute façon: planifiez l’audit des bibliothèques natives dans la même version plutôt que de le découvrir en pleine course à l’API 36. Pour l’ensemble des niveaux par format d’appareil, des exceptions et du mécanisme de prolongation, voyez notre article sur l’échéance API 36 de Google Play, et pour toute la séquence du compte à la production, notre article sur les exigences de publication 2026.

Le contrôle à passer avant l’import

Votre progression est enregistrée dans ce navigateur uniquement. Rien n’est envoyé nulle part, et vider les données du navigateur l’efface.

Là où cela percute votre test fermé

Le scénario qui fait mal ressemble à ceci. Un compte de développeur personnel démarre un test fermé, la fenêtre de 14 jours d’inscription sans interruption commence, et quelque part au milieu une montée du niveau cible fait apparaître un avertissement 16 KB. Le développeur recompile alors ses dépendances natives pendant qu’un groupe de testeurs doit rester intact autour de lui. Importer une nouvelle version dans le canal de test ne pose aucun problème, et Google encourage même les développeurs à continuer de mettre à jour pendant un test. Ce qui casse la série, c’est que le côté testeurs devienne silencieux.

C’est exactement la partie que PrimeTestLab maintient stable. Nous fournissons 12 testeurs réels sur de vrais appareils couvrant Android 7 à 17, inscrits et maintenus pendant les 14 jours complets, pour que votre recompilation se déroule face à un test stable et non à un test qui s’effondre. Le test démarre en 4-6 heures, et nous avons mené cette opération sur 7 400+ applications dans 120+ pays avec un taux de réussite de 99.9%.

Recruter vos testeurs vous-même ou passer par un test géré

Pour être direct sur la limite: nous ne recompilons pas vos bibliothèques natives et cet article n’est pas un argumentaire de vente pour le faire. Le travail sur les 16 KB est le vôtre, et tout ce qui précède cette section est écrit pour le rendre aussi court que possible. Ce que nous vous enlevons, c’est l’exigence de testeurs qui court en parallèle, pour que les deux problèmes cessent de se disputer la même quinzaine.

Questions fréquentes

L’essentiel