Pages Android 16 Ko : impact réel et préparation de votre application

Si vous avez rencontré le message concernant Pages mémoire de 16 Ko sur Android Dans l'émulateur ou sur la Google Play Console, vous n'êtes pas seul. Il s'agit d'un changement technique qui a un réel impact sur le performance et publication d'applications à partir d'Android 15, c'est donc une bonne idée de comprendre ce que c'est, pourquoi c'est fait et comment adapter vos builds.

En termes simples, Android ouvre la porte aux appareils configurés avec Taille de page de 16 Ko (en plus de 4 Ko), ce qui peut se traduire par des lancements d'applications plus rapides, une consommation d'énergie réduite et un système plus réactif. Bien sûr, si votre application intègre code natif (.so), vous devrez recompiler et aligner correctement ou risquer des erreurs d'installation et des plantages sur Google Play.

Que signifie la taille de la page et qu'est-ce qui change avec Android 15 ?

La taille de la page est la unité de base avec laquelle le système d'exploitation gère la RAMHistoriquement, Android était optimisé pour 4 Ko, car c'était la taille la plus courante sur les appareils et les noyaux, tandis que de nombreux processeurs ARM prenaient déjà en charge 16 Ko. Avec Android 15, AOSP ajoute la prise en charge de compiler et exécuter sur des appareils de 16 Ko, et introduit également l'alignement ELF 16 Ko dans l'espace utilisateur qui fonctionne avec les noyaux 4 Ko et 16 Ko (à partir d'Android14-6.1).

Gestionnaire d'applications pour Android

Avantages en termes de performance mesurés par Google

L'adoption de 16 Ko entraîne une petite augmentation moyenne de la mémoire, mais offre améliorations systémiques et applicativesLes premiers tests d'Android 15 ont montré :

Lancements d'applications plus rapides:en moyenne 3,16%, avec des cas particuliers allant jusqu'à 30%.
Consommation réduite au lancement:réduction moyenne de 4,56%.
Appareil photo plus rapide:Démarrages à chaud 4,48 % plus rapides et démarrages à froid 6,60 % plus rapides en moyenne.
Démarrage du système: ~8% d'amélioration (environ 950 ms).

Certaines analyses externes parlent de bénéfices totaux de 5 à 10 % Au prix d'environ 9 % de mémoire physique supplémentaire, bien que le résultat réel varie selon l'appareil et l'application. Quoi qu'il en soit, avec plus de RAM disponible dans la gamme actuelle, le passage à 16 Ko réduit comptabilité de la mémoire et aide tout à se dérouler plus facilement.

Mon application est-elle affectée ?

La règle rapide : si votre application est à 100 % Java/Kotlin (y compris les bibliothèques et les SDK), prend déjà en charge 16 Ko. Cependant, il est conseillé de le tester dans un environnement 16 Ko en cas de problème. régressions inattendues.

Si votre projet utilise du code C/C++ natif (NDK), créez un lien avec SDK qui incluent .so, moteurs de jeu ou compilateurs externes qui intègrent des bibliothèques natives, vous devrez recompiler et aligner pour 16 Ko. C'est généralement le cas pour les applications avec SQLCipher, des moteurs comme Unity/Unreal ou des SDK natifs tiers.

Comment savoir si vous utilisez du natif et si vous respectez 16 Ko

Analyseur APK dans Android Studio

Ouvrez Android Studio et utilisez Créer → Analyser l'APK… Pour inspecter un APK, accédez à lib/ et recherchez les fichiers .so ; s'ils existent, votre application usage indigène. Le panneau affiche des avertissements de Alignement si une bibliothèque ne respecte pas les 16 Ko.

De plus, Android Studio intègre contrôles automatiques: Lint signale les bibliothèques natives comme non alignées sur 16 Ko, et les outils eux-mêmes signalent les problèmes avec les APK ou les pré-construits non conformes.

Script officiel pour vérifier l'alignement ELF

Sous Linux ou macOS, vous pouvez utiliser le script check_elf_alignment.sh Pour analyser un APK et étiqueter chaque .so comme ALIGNÉ ou NON ALIGNÉ (arm64-v8a et x86_64) :

./check_elf_alignment.sh APK_NAME.apk

Si une bibliothèque sort comme NON ALIGNÉ, Tu vas devoir mettre à jour votre emballage, recompilez votre application et répétez les tests. C'est un moyen rapide et efficace détecter la non-conformité avant de télécharger sur Play.

Vérification avec des outils de ligne de commande

Installez Build Tools ≥ 35.0.0 et un NDK récent depuis le SDK Manager. Extrayez l'APK et localisez les fichiers .so dans lib /, et pour chacun exécutez :

readelf -l <SHARED_OBJECT_FILE> | grep LOAD

En sortie, vérifiez que les segments de chargement affichent aligner 214. Si vous voyez 213, 2**12 ou moins, cette bibliothèque n'est pas aligné pour 16 Ko. Enfin, exécutez zipalign sur votre APK :

zipalign -c -P 16 -v 4 APK_NAME.apk

Si cela se termine par 'Vérification réussie', l'APK est zip aligné à 16 Ko correctement, exigence clé pour les appareils de 16 Ko lors de la distribution de fichiers .so non compressés.

Compile et empaquette jusqu'à 16 Ko

Mise à jour du packaging : AGP 8.5.1 ou supérieur

Dans les applications avec des bibliothèques natives non compressées, les appareils de 16 Ko nécessitent que l'APK soit aligné sur une limite ZIP de 16 KoLa méthode recommandée est d'utiliser le plugin Android Gradle 8.5.1 ou version ultérieure, qui applique cet alignement automatiquement. C'est l'option la plus robuste pour installations fiables de Play.

Soyez prudent avec AGP 8.3–8.5 : même si cela semble bien fonctionner localement, bundletool n'effectue pas d'alignement zip par défaut La sortie d'App Bundle pourrait être mal alignée et l'installation pourrait échouer. Si vous ne pouvez pas encore mettre à niveau vers la version 8.5.1, il existe une solution temporaire : le regroupement. jniLibs compressés.

// Groovy
android {
  packagingOptions {
    jniLibs {
      useLegacyPackaging true
    }
  }
}

// Kotlin DSL
android {
  packaging {
    jniLibs {
      useLegacyPackaging = true
    }
  }
}

Veuillez noter que lors de la compression de .so, le programme d'installation doit extraire et copier bibliothèques, ce qui augmente l'utilisation du disque et peut augmenter le débit pannes dans les petits espacesLa solution fondamentale reste de migrer vers AGP ≥ 8.5.1.

Alignement ELF à 16 Ko : NDK et indicateurs

Les appareils de 16 Ko nécessitent que le Segments ELF de votre .so sont alignés sur 16 Ko. La meilleure solution est d'utiliser NDK r28 ou supérieur, qui compile avec 16 Ko par défaut.

Avec NDK-r27 Vous devez activer l'intégration en ligne via des options (ndk-build, CMake/Gradle, ou en transmettant l'option à l'éditeur de liens). Pour les builds avec plusieurs chaînes d'outils, vous pouvez forcer l'intégration avec :

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

Avec NDK r26 ou antérieur Le support est déconseillé ; en dernier recours, ajustez ndk-build/CMake avec les options 16 Ko. Si vous utilisez NDK r22 ou version antérieure, il peut être nécessaire d'ajouter taille-de-page-commune=16384 en raison de bugs historiques dans ld/lld ; cette solution fonctionne si l'ELF inclut .relro_padding (LLD 18+). Malgré cela, il est conseillé de migrer dès que possible vers r27/r28.

Si vous créez un lien dynamique vers un ancienne libc++_shared.so (version r26 ou antérieure, non alignée, 16 Ko), votre application ne s'installera pas sur 16 Ko. Vous devrez migrer vers un NDK récent ou, pour contourner ce problème, lien statique le C++ STL suivant les considérations de compatibilité, pesant le pour et le contre.

Évitez les hypothèses de 4 Ko dans votre code

Même si vous compilez et alignez correctement, votre application peut toujours échouer si le code suppose TAILLE_PAGE = 4096 ou utilisez cette valeur de manière rigide. Dans NDK r27+, la constante PAGE_SIZE ce n'est même pas défini en mode 16 Ko.

La bonne chose à faire est d'interroger la taille de la page au moment de l'exécution avec getpagesize() o sysconf(_SC_PAGESIZE). Examiner les utilisations de mmap() et d'autres API qui nécessitent des tailles ou des adresses alignées sur la page, en les remplaçant par des alternatives le cas échéant et combiner des régions pour réduire les déchets.

N'oubliez pas que le noyau arrondit les requêtes à la page la plus procheDans 16 Ko, une demande de 1 à 5 Ko alloue 16 Ko ; 17 Ko alloue 32 Ko. Si possible, regroupez deux régions RW qui étaient auparavant de 2 × 4 Ko afin qu'elles restent, dans 16 Ko, une seule page et éviter les doublons.

Vérifiez que vos SDK prennent en charge 16 Ko

De nombreux fournisseurs distribuent déjà versions compatibles ou autoriser la recompilation, mais certaines versions plus anciennes ne sont pas compatibles. Consultez la documentation de chaque SDK et mettez à jour version compatible et confirmer l'alignement avec les outils ci-dessus ; s'il n'y a pas de support, évaluer se retirer temporairement cette dépendance.

Test de 16 Ko : émulateur et périphériques

Configurez le SDK Android 15 et créez un appareil virtuel avec un Image système basée sur 16 Ko. Android Studio Jellyfish (2023.3.1) ou version ultérieure le prend en charge, bien que Ladybug (2024.2.1+) soit recommandé pour une meilleure expérience.

Dans SDK Manager → SDK Platforms, cochez Afficher les détails du package et, sous Android VanillaIceCream ou version ultérieure, installez les images pour Page expérimentale de 16 Ko des API Google (ARM 64 v8a et/ou Atom x86_64). Si vous émulez un Pixel compatible, ARM 64 v8a est généralement suffisant.

Sur certaines versions d'émulateur (35.1.5 à 35.1.20) et avant la révision 4 des images Android 15.0 de 16 Ko pour x86_64, ajoutez cette ligne dans le config.ini de l'AVD :

kernel.parameters = androidboot.page_shift=14

Démarrez l'émulateur et vérifiez l'environnement avec shell adb getconf TAILLE_PAGE; devrait renvoyer 16384. Il existe un problème de débogage connu avec LLDB sur les images de 16 Ko, corrigé dans NDK r27 (RC1) et Android Studio Koala | 2024.1.2 Canary 5.

Test sur du matériel réel

Depuis Android 15 QPR1, certains modèles incluent une option développeur pour démarrer l'appareil en 16 Ko. Plus précisément, les Pixel 8/8 Pro/8a l'incluent dans QPR1 ou version ultérieure, et les Pixel 9/9 Pro/9 Pro XL à partir de QPR2 bêta 2 ou version ultérieure. Appliquez les mises à jour système et activez le mode de validation. conditions réelles.

Vérifiez la taille avec shell adb getconf TAILLE_PAGE (devrait être 16384) et vérifiez que votre APK est aligné au format zip à 16 Ko avec :

zipalign -c -P 16 -v 4 APK_NAME.apk

Ensuite, effectuez des tests approfondis, en vous concentrant sur les zones sensibles à tailles de page et la mémoire native.

Mode de compatibilité descendante 16 Ko

Lorsque l'appareil exécute un noyau de 16 Ko, le gestionnaire de paquets peut déclencher un mode de compatibilité descendante Si l'application détecte des fichiers .so avec des segments LOAD alignés de 4 Ko ou si l'APK compressé contient des fichiers ELF non compressés alignés avec ZIP de 4 Ko, elle affichera un avertissement au premier démarrage indiquant qu'elle est exécutée sur le mode de compatibilité.

Comment trouver des applications et des logiciels avec F-Droid

Exigences de Google Play : dates et portée

Pour préparer le lancement de nouveaux appareils, Google Play exigera des applications ciblant Android 15 (API 35) ou supérieur sont compatibles avec des pages de 16 Ko. La date de la clé publique est la Novembre 1 2025 pour les nouvelles applications et mises à jour.

Certains développeurs ont reçu des avis supplémentaires avec un jalon autour du 1 Mai 2026 pour renforcer les blocages pour les builds non conformes. Surveillez votre Play Console et vos communications, mais la référence principale est noviembre de 2025Il ne s'agit pas seulement d'une boîte de conformité : l'intégration d'offres de 16 Ko Amélioration des performances réel.

Paramètres Android en 16 Ko (avancé)

En arm64, si vous compilez le noyau avec Kleaf, utilisez –page_size=16 ko, ou dans la configuration du noyau Linux, sélectionnez CONFIG_ARM64_16K_PAGES Au lieu de CONFIG_ARM64_4K_PAGES. Pour l'espace utilisateur, définissez dans le produit :

PRODUIT_N°_BIONIC_PAGE_SIZE_MACRO := true pour supprimer PAGE_SIZE et forcer la requête à l'exécution.
TAILLE_MAXI_PAGE_DU_PRODUIT_PRIS_EN_CHARGE := 16384 pour compiler ELF avec un alignement de 16 Ko et faciliter la compatibilité future.

Après avoir sélectionné la cible (déjeuner), vérifiez les indicateurs de construction :

$ source build/envsetup.sh
$ lunch <target>
$ get_build_var TARGET_MAX_PAGE_SIZE_SUPPORTED
16384
$ get_build_var TARGET_NO_BIONIC_PAGE_SIZE_MACRO
true

Même si la compilation réussit, des différences peuvent persister. temps d'exécution en 16 Ko, vous devez donc tester minutieusement et examiner les alignements et les appels pour mmap().

Programmation efficace avec des pages de 16 Ko

La plupart du code Android ne gère pas directement les pages, mais si vous traitez de la mémoire, modifiez le comportement du noyauArrondit toujours à la taille de la page. À 4 Ko, allouer 1 à 4 Ko consomme 4 Ko ; à 16 Ko, allouer 1 à 5 Ko consomme 16 Ko ; et à 17 Ko, 32 Ko.

Avoué arrondissez vos tailles avant d'appeler mmap() et, si possible, consolider les régions RW pour tirer parti d'une page unique et réduire le gaspillage. De plus, dans les systèmes optimisés, les tables de pages sont un quart de la taille pour la même mémoire lors de l'utilisation de pages de 16 Ko, ce qui compense en partie la granularité plus élevée.

Vérification des binaires et des pré-compilés

Au-delà des tests sur le noyau 16 Ko, à partir d'Android 16, vous pouvez activer VÉRIFICATION_DU_PRODUIT_PRÉCONSTRUITE_TAILLE_MAXIMALE_DE_PAGE := vrai pour valider les pré-compilés lors de la compilation. Si vous devez l'ignorer temporairement, utilisez ignore_max_page_size : vrai sur Android.bp ou LOCAL_IGNORE_MAX_PAGE_SIZE := vrai sur Android.mk.

Sur les appareils lancés avec Android 15+, il fonctionne test d'alignement elfique atest pour vérifier le Gamme ELF sur l'appareil lui-même et capturez les résultats pour votre pipeline CI.

Erreurs courantes et solutions

S'installe localement mais échoue à partir de Play: Il manque généralement 16 Ko de zipalign dans les builds générées à partir d'App Bundle (AGP 8.3–8.5). Télécharger sur AGP ≥ 8.5.1 ou empaquetez temporairement les jniLibs compressés et validez à nouveau.
INSTALL_FAILED_INVALID_APK / taille de page ELF non prise en charge: vos fichiers .so font 4 Ko. Mettez à jour NDK (r27/r28 est le meilleur), nettoyez et recompilez, puis validez avec alignement automatique 2**14.
readelf échoue ou affiche un en-tête corrompu: Vous inspectez probablement un fichier mal extrait. Décompressez l'APK dans un dossier, accédez à lib/arm64-v8a et exécutez readelf sur le bon .so.
Fonctionne sur l'émulateur mais pas sur l'appareil 16 Ko: est généralement un SDK tiers obsolète. Identifiez le .so problématique avec logcat, mettez à jour la dépendance ou supprimez-la s'il n'existe pas de version prise en charge.
Suivez les instructions dans Play Console après la reconstruction: Il y a un fichier .so de 4 Ko dans l'AAB. Utilisez bundletool pour générer les fichiers .apks, décompressez-les et transmettez-les. lecture automatique/zipalign à tous.jusqu'à ce que le dernier obtempère.

Liste de contrôle pratique avant publication

AGP ≥ 8.5.1 ou, temporairement, jniLibs compressés avec useLegacyPackaging.
NDK r28+ (ou r27 avec des drapeaux) et, le cas échéant, -Wl,-z,max-page-size=16384 dans le lien.
Tout le .so avec CHARGER aligner 2**14 (arm64-v8a/x86_64) et APK zipaligné à 16 Ko.
Prix hors TVA Hypothèses de 4 Ko dans le code ; vous utilisez getpagesize()/sysconf.
Test sur un émulateur/périphérique de 16 Ko et vérification avec adb getconf TAILLE_PAGE = 16384.

Publier sur Google Play avec moins de risques

Montez d'abord à Tests ouverts pour recueillir les premiers retours, puis passer aux tests fermés avec des groupes restreints, et enfin passer en production après validation de la stabilité. Dans les notes de version, indiquez que vous avez ajouté Prise en charge d'Android 15 et pages de 16 Ko pour fournir un contexte aux utilisateurs et aux réviseurs.