React Native et pages mémoire de 16 Ko : trouver ce qui bloque la mise à jour Android

Google Play vérifie désormais deux choses différentes sur la préparation d'une application Android à la plateforme, et il est facile d'en corriger une alors que l'autre bloque encore votre publication. Ce guide porte sur la seconde, moins visible : la prise en charge des pages mémoire de 16 Ko. C'est une méthode concrète pour trouver quelle bibliothèque native d'une vraie version React Native ou Expo n'est pas prête, la vérifier avec les outils officiels et valider la correction sur un appareil en 16 Ko. Les faits et les dates ci-dessous ont été vérifiés dans la documentation Android et Expo le 11 octobre 2026.

Deux contrôles Play, pas un seul

1. Niveau d'API cible. Google Play exige que les nouvelles applications et les mises à jour ciblent un niveau d'API Android récent. Cette règle porte sur le targetSdkVersion que vous déclarez et sur les changements de comportement qui l'accompagnent. Elle est documentée sur sa propre page : Target API level requirements for Google Play apps.

2. Prise en charge des pages de 16 Ko. Certains appareils Android récents utilisent des pages mémoire de 16 Ko au lieu de 4 Ko. Selon le guide Android sur les pages de 16 Ko, les applications qui ciblent Android 15 (API 35) ou plus doivent prendre en charge les pages de 16 Ko sur les appareils 64 bits distribués via Google Play, et à partir du 1er février 2027, les mises à jour qui ne les prennent pas en charge ne pourront plus être publiées.

Le second contrôle ne porte pas sur ce que vous déclarez. Il porte sur la structure binaire du code natif que vous livrez. Augmenter targetSdkVersion ne rend pas une bibliothèque native compatible, et un projet peut passer le contrôle du niveau d'API cible alors qu'un fichier .so échoue encore au contrôle de la taille de page.

Pourquoi le problème ne vient pas du JavaScript

Votre bundle JavaScript s'exécute dans le moteur JavaScript de l'application et n'est pas chargé comme du code natif par le système d'exploitation. Ce qui compte pour la taille des pages, ce sont les bibliothèques partagées (fichiers .so) embarquées dans votre application : le code natif de React Native lui-même, le moteur JavaScript, et chaque dépendance qui contient du code C ou C++, qu'il soit compilé depuis les sources pendant votre build ou fourni précompilé dans un AAR.

Vous ne pouvez donc pas répondre à la question « sommes-nous compatibles 16 Ko ? » en lisant package.json. Il faut inspecter l'artefact de publication que vous téléversez réellement, et regarder son dossier lib/.

Étape 1 : générer l'artefact que vous livrez vraiment

Vérifiez le même type de build que celui que vous envoyez sur Play, pas un build de débogage :

• React Native CLI : cd android && ./gradlew bundleRelease produit un AAB (par défaut dans android/app/build/outputs/bundle/release/). ./gradlew assembleRelease produit un APK dans android/app/build/outputs/apk/release/.
• Expo : utilisez l'AAB de votre build de publication EAS, ou le résultat d'un build de publication local après npx expo prebuild.

Si vous n'avez qu'un AAB, vous pouvez en générer des APK installables avec bundletool build-apks pour l'inspection et les tests sur appareil ci-dessous.

Étape 2 : lister les bibliothèques natives

Ouvrez l'APK de publication dans l'APK Analyzer d'Android Studio (Build > Analyze APK) et dépliez lib/. Vous verrez un dossier par ABI, comme arm64-v8a, armeabi-v7a, x86 et x86_64, chacun contenant des fichiers .so. Le guide sur les pages de 16 Ko explique que l'APK Analyzer affiche des avertissements d'alignement pour les bibliothèques qui posent problème.

Concentrez-vous sur les ABI 64 bits (arm64-v8a et x86_64), puisque c'est là que l'exigence s'applique. Notez chaque fichier .so. S'il n'y a aucun dossier lib/, l'application ne contient pas de code natif et cette exigence ne la concerne pas ; dans une application React Native, c'est très peu probable.

Pour chaque bibliothèque, identifiez qui la fournit. Chercher le nom du fichier dans node_modules mène généralement au paquet, et ./gradlew :app:dependencies affiche les bibliothèques Android qui arrivent de façon transitive via Gradle (les SDK d'analyse, de paiement, de cartes ou de vidéo en sont des sources fréquentes).

Étape 3 : lancer les trois contrôles d'alignement

Chaque outil répond à une question différente. Aucun ne prouve à lui seul que l'application fonctionne sur un appareil en 16 Ko.

AAB : le bundle est-il configuré pour l'alignement 16 Ko ?

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

La sortie doit contenir PAGE_ALIGNMENT_16K. Cela indique que le bundle est configuré pour que les bibliothèques natives non compressées soient empaquetées avec un alignement ZIP de 16 Ko. Ce contrôle n'inspecte pas les segments ELF de chaque .so : une bibliothèque compilée avec des segments de 4 Ko peut donc se trouver dans un bundle qui passe ce contrôle.

Si la valeur est absente, regardez d'abord votre version de l'Android Gradle Plugin. Android recommande AGP 8.5.1 ou plus pour empaqueter les fichiers .so non compressés avec un alignement ZIP de 16 Ko.

APK : les bibliothèques sont-elles alignées sur 16 Ko dans le ZIP ?

zipalign -c -P 16 -v 4 app-release.apk

Cette commande vérifie l'alignement ZIP de l'APK, bibliothèques natives comprises, sur 16 Ko. C'est un contrôle d'empaquetage, pas un test d'exécution. Un échec désigne généralement la chaîne d'empaquetage (là encore, AGP) ; une réussite ne dit rien des segments ELF.

ELF : les segments de chargement de chaque bibliothèque sont-ils alignés sur 16 Ko ?

C'est le contrôle qui révèle le plus souvent le vrai blocage. Le guide Android fournit un script check_elf_alignment.sh qui inspecte les bibliothèques natives d'un APK et indique celles qui ne sont pas alignées sur 16 Ko. Récupérez le script et son mode d'emploi dans le guide officiel plutôt que depuis une copie, afin d'exécuter la version à jour.

Si une bibliothèque est signalée ici, c'est le .so lui-même qui a été compilé pour des pages de 4 Ko. Le réempaqueter n'y changera rien : il doit être recompilé ou remplacé.

Étape 4 : corriger la bibliothèque en cause, pas le symptôme

Associez chaque échec à sa cause :

Deux mises en garde :

• Mettre à jour AGP ou React Native ne corrige pas tous les .so. Cela met à jour l'empaquetage et les bibliothèques que ces projets compilent, mais un binaire précompilé dans un SDK tiers reste exactement tel que son éditeur l'a compilé.
• Changez une seule chose à la fois et relancez les contrôles après chaque changement, pour savoir quelle mise à jour a réellement supprimé la bibliothèque signalée.

Si vous utilisez Expo avec Continuous Native Generation

Avec Continuous Native Generation, le dossier android/ est généré par npx expo prebuild et peut être régénéré à tout moment. Une correction faite à la main dans android/build.gradle peut disparaître au prochain prebuild ou build dans le cloud. Placez la modification là où elle sera conservée : versions des paquets, app.json / app.config.js, ou un plugin de configuration. Lancez ensuite un prebuild propre et répétez les contrôles sur le nouvel artefact.

Étape 5 : tester rapidement dans un vrai environnement en 16 Ko

Les contrôles statiques trouvent la plupart des problèmes, mais la preuve finale consiste à exécuter le build de publication là où les pages font 16 Ko.

1. Créez un émulateur à partir d'une image système avec des pages de 16 Ko dans Android Studio, ou utilisez un appareil qui prend en charge le mode 16 Ko (le guide officiel liste les options).
2. Vérifiez l'environnement :

adb shell getconf PAGE_SIZE

La commande doit afficher 16384. Si elle affiche 4096, vous ne testez pas ce que vous croyez tester. 3. Installez l'APK de publication (ou les APK générés depuis votre AAB) et parcourez chaque chemin qui charge du code natif : le démarrage de l'application, puis les écrans qui utilisent la caméra, les cartes, la vidéo, les bases de données, le chiffrement, le traitement d'images, les paiements ou tout SDK identifié à l'étape 2. Une bibliothèque chargée sur un seul écran n'échoue que sur cet écran. 4. Surveillez adb logcat pendant vos tests pour repérer les erreurs de chargement de bibliothèques natives et les plantages.

Android dispose aussi d'un mode de rétrocompatibilité 16 Ko qui peut permettre à certaines applications non alignées de tourner sur des appareils en 16 Ko. Ne le considérez pas comme une validation. Si votre application ne fonctionne que grâce à lui, le build n'est toujours pas aligné, et c'est cela que Play vérifie.

Liste de contrôle condensée avant publication

• Niveau d'API cible traité séparément (exigence Play)
• AAB ou APK de publication généré, pas un build de débogage
• Chaque .so de lib/arm64-v8a et lib/x86_64 listé, avec le paquet qui le fournit
• bundletool dump config affiche PAGE_ALIGNMENT_16K
• zipalign -c -P 16 -v 4 réussit sur l'APK
• check_elf_alignment.sh ne signale aucune bibliothèque non alignée
• AGP 8.5.1+ et NDK r28+ pour le code que vous compilez ; des builds 16 Ko pour chaque SDK précompilé
• Corrections Expo CNG enregistrées dans la configuration ou des plugins, vérifiées après un prebuild propre
• Build de publication testé sur un appareil ou un émulateur où getconf PAGE_SIZE renvoie 16384, y compris chaque écran qui sollicite du code natif
• Tout cela fait bien avant le 1er février 2027

Besoin d'aide pour trouver le blocage ?

Si une bibliothèque native bloque la mise à jour de votre application React Native, ou si l'application doit être mise à jour avant de pouvoir être publiée à nouveau, mon offre Play-Ready Rescue commence par un audit au forfait du code, du build et des problèmes signalés dans la Play Console, puis un sprint pour corriger les priorités et publier un build conforme. Voir l'offre Play-Ready Rescue.

Hamza El Haissouf

Développeur full-stack depuis 6 ans · Maroc

Je conçois des assistants WhatsApp et des sites web pour les cliniques privées et les entreprises de logistique. À distance, en français et en anglais.

Voir les projetsÀ proposLinkedIn

À lire aussi

MobileMettre à jour React Native de 0.76 à 0.78 : étapes et correctionsMobileMettre en place un plan de marquage GA4 + Firebase pour votre application mobileServiceDéveloppeur React Native au Maroc