Assurer la compatibilité avec les tailles de page de 16 Ko

Auparavant, Android n'acceptait que des pages de 4 Ko de mémoire, ce qui optimisée des performances de la mémoire système pour la quantité moyenne de mémoire totale les appareils Android ont généralement eu. À partir d'Android 15, AOSP prend en charge appareils configurés pour utiliser une taille de page de 16 Ko appareils). Si votre application utilise des bibliothèques du NDK, directement ou indirectement via un SDK, vous devez recompiler votre application pour qu'elle fonctionnent sur ces appareils de 16 Ko.

Alors que les fabricants d’appareils continuent à construire des appareils avec de plus grandes quantités mémoire physique (RAM), un grand nombre de ces appareils adopteront un débit de 16 Ko (et et éventuellement plus) pour optimiser les performances de l'appareil. Ajout... la compatibilité avec les appareils dont la taille de page est de 16 Ko permet à votre application de s'exécuter sur ces appareils et aide votre application à bénéficier des performances associées et d'améliorations. Sans recompilation, les applications risquent de ne pas fonctionner sur les appareils de 16 Ko. lorsqu'ils seront mis en production dans les prochaines versions d'Android.

Pour vous aider à proposer la prise en charge de votre application, nous vous fournissons des conseils sur la façon de vérifier si votre application est concernée, comment recompilez votre application (le cas échéant) et comment la tester dans un environnement de 16 Ko utilisant des émulateurs (y compris Android 15) ; images système pour Android Emulator).

Avantages et gains de performances

Les appareils configurés avec une taille de page de 16 Ko utilisent un peu plus de mémoire en moyenne, mais bénéficient également de diverses améliorations des performances pour le système et les applications:

• Temps de lancement des applications plus courts lorsque le système est soumis à une pression de mémoire: 3,16 % de moins en moyenne, avec des améliorations plus importantes (jusqu'à 30%) pour certaines applications que nous avons testées
• Consommation d'énergie réduite au démarrage de l'application: réduction de 4,56% en moyenne
• Lancement plus rapide de l'appareil photo: démarrage à chaud 4,48% plus rapide en moyenne et démarrage à froid 6,60% plus rapide en moyenne
• Amélioration du temps de démarrage du système: 8% (environ 950 millisecondes) en moyenne

Ces améliorations sont basées sur nos premiers tests. Les résultats sur les appareils réels seront probablement différents. Nous fournirons une analyse supplémentaire des gains potentiels pour les applications à mesure que nous poursuivrons nos tests.

Vérifier si votre application est concernée

Si votre application utilise du code natif, vous devez la recompiler pour qu'elle soit compatible avec les appareils 16 ko. Si vous n'êtes pas sûr que votre application utilise du code natif, vous pouvez utiliser l'analyseur d'APK pour identifier la présence de code natif, puis vérifier l'alignement des segments ELF pour toutes les bibliothèques partagées que vous trouvez.

Si votre application n'utilise que du code écrit en langage de programmation Java ou Kotlin, y compris tous ses SDK et bibliothèques, elle est déjà compatible avec les appareils 16 ko. Toutefois, nous vous recommandons de tester votre application dans un environnement de 16 ko pour vérifier qu'il n'y a pas de régressions inattendues dans le comportement de l'application.

Votre application utilise-t-elle du code natif ?

Votre application utilise du code natif si l'une des conditions suivantes s'applique:

• votre application utilise du code C/C++ (natif) ; Si votre application utilise le NDK Android, elle utilise du code natif.
• Votre application est associée à toutes les bibliothèques natives ou dépendances tierces (telles que les SDK) qui les utilisent.
• Votre application est créée par un outil de création d'applications tiers qui utilise des bibliothèques natives sur l'appareil.

Identifier les bibliothèques natives à l'aide de l'analyseur d'APK

L'analyseur d'APK est un outil qui vous permet d'évaluer divers aspects d'un APK créé. Pour savoir si votre application utilise du code natif ou des bibliothèques, procédez comme suit:

1. Ouvrez Android Studio, puis cliquez sur File > Open (Fichier > Ouvrir) et sélectionnez un projet.

2. Dans la barre de menu, cliquez sur Build > Analyze APK (Compilation > Analyser l'APK).

   

3. Sélectionnez l'APK que vous souhaitez analyser.

4. Recherchez dans le dossier lib, qui héberge les fichiers d'objets partagés (.so), le cas échéant. Si des fichiers d'objets partagés sont présents, votre application utilise du code natif. Si aucun fichier d'objet partagé n'est présent ou s'il n'y a pas de dossier lib, votre application n'utilise pas de code natif.

   

Vérifier l'alignement des segments ELF pour les bibliothèques partagées

Pour toutes les bibliothèques partagées, vérifiez que les segments ELF des bibliothèques partagées sont correctement alignés à l'aide d'un alignement ELF de 16 Ko. Si vous développez sur Linux ou macOS, vous pouvez utiliser le script check_elf_alignment.sh comme décrit dans la section suivante. Vous pouvez également utiliser directement les outils de ligne de commande.

Utiliser le script check_elf_alignment.sh (Linux ou macOS)

Pour vérifier l'alignement des segments ELF à l'aide du script check_elf_alignment.sh, procédez comme suit:

1. Enregistrez le script check_elf_alignment.sh dans un fichier.

2. Exécutez le script sur le fichier APK de votre application:

   check_elf_alignment.sh APK_NAME.apk
   

   Le script renvoie ALIGNED ou UNALIGNED pour toutes les bibliothèques partagées arm64-v8a.

3. Si des bibliothèques partagées arm64-v8a ou x86_64 sont UNALIGNED, vous devez mettre à jour l'empaquetage de ces bibliothèques, puis recompiler votre application et la tester à nouveau en suivant les étapes de cette section.

Utiliser directement les outils de ligne de commande

Pour vérifier l'alignement des segments ELF directement à l'aide d'outils de ligne de commande, procédez comme suit:

1. Assurez-vous que les outils de compilation du SDK Android 35.0.0 ou version ultérieure et le NDK Android sont installés à l'aide de SDK Manager dans Android Studio ou de l'outil de ligne de commande sdkmanager.

2. Pour extraire le fichier APK de votre application:

   Linux ou macOS

   unzip APK_NAME.apk -d /tmp/my_apk_out
   

   Windows (PowerShell)

   Expand-Archive -Path .\APK_NAME.apk -DestinationPath ~\tmp\my_apk_out
   

3. Dans le répertoire temporaire dans lequel vous avez extrait votre fichier APK, recherchez les fichiers d'objet partagé (.so) dans le répertoire lib. Il s'agit des mêmes fichiers d'objets partagés que vous auriez vus lorsque vous identifiez des bibliothèques natives à l'aide de l'analyseur d'APK. Exécutez la commande suivante sur chaque fichier d'objet partagé:

   Linux ou macOS

   SDK_ROOT_LOCATION/Android/sdk/ndk/NDK_VERSION/toolchains/llvm/prebuilt/darwin-x86_64/bin/llvm-objdump -p SHARED_OBJECT_FILE.so | grep LOAD
   

   Windows (PowerShell)

   SDK_ROOT_LOCATION\Android\sdk\ndk\NDK_VERSION\toolchains\llvm\prebuilt\windows-x86_64\bin\llvm-objdump.exe -p SHARED_OBJECT_FILE.so | Select-String -Pattern "LOAD"
   

   Où SDK_ROOT_LOCATION correspond au chemin d'accès au répertoire dans lequel vous avez installé le SDK Android, SHARED_OBJECT_FILE au nom du fichier d'objet partagé que vous vérifiez et NDK_VERSION à la version du NDK Android que vous avez installée (par exemple, 28.0.12433566). La sortie ressemble à ce qui suit pour chaque fichier que vous vérifiez:

   LOAD off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**14
   LOAD off    0x0000000000042a90 vaddr 0x0000000000043a90 paddr 0x0000000000043a90 align 2**14
   LOAD off    0x0000000000046230 vaddr 0x0000000000048230 paddr 0x0000000000048230 align 2**14
   

4. Vérifiez les lignes de sortie pour vous assurer que les segments de charge n'ont pas de valeurs inférieures à 2**14. Si des segments de chargement sont des valeurs 2**13, 2**12 ou inférieures, vous devez mettre à jour le packaging de ces bibliothèques, puis recompiler votre application et la tester à nouveau en suivant les étapes de cette section.

5. Exécutez ensuite l'outil de ligne de commande zipalign sur le fichier APK de votre application:

   Linux ou macOS

   SDK_ROOT_LOCATION/Android/sdk/build-tools/35.0.0/zipalign -v -c -P 16 4 APK_NAME.apk
   

   Windows (PowerShell)

   SDK_ROOT_LOCATION\Android\sdk\build-tools\35.0.0\zipalign.exe -v -c -P 16 4 APK_NAME.apk
   

   Où SDK_ROOT_LOCATION est le chemin d'accès au répertoire dans lequel vous avez installé le SDK Android et APK_NAME est le nom du fichier APK de votre application. La dernière ligne de la sortie indique "Validation réussie" si toutes les bibliothèques partagées sont alignées correctement.

   Si la validation a échoué, certaines bibliothèques partagées doivent être réalignées. Vous devez donc mettre à jour le packaging de ces bibliothèques, puis recompiler votre application et la tester à nouveau en suivant les étapes de cette section.

Créer votre application pour les appareils de 16 ko

Pour prendre en charge les appareils de 16 ko, les applications qui utilisent du code natif doivent suivre les étapes décrites dans les sections suivantes. Si vous passez à la version 8.5.1 d'AGP ou une version ultérieure, et à la version r28 du NDK ou une version ultérieure, et que vous utilisez des dépendances précompilées compatibles avec 16 ko, les applications sont compatibles avec 16 ko par défaut.

Mettre à jour le packaging de vos bibliothèques partagées

Nous vous recommandons de passer à la version 8.5.1 ou ultérieure d'AGP et d'utiliser des bibliothèques partagées non compressées.

AGP 8.5.1 ou version ultérieure

Les appareils 16 ko nécessitent des applications fournies avec des bibliothèques partagées non compressées pour les aligner sur une limite zippée de 16 ko. Pour ce faire, vous devez passer à la version 8.5.1 ou ultérieure du plug-in Android Gradle (AGP). Pour en savoir plus sur la procédure de mise à niveau, consultez la section Assistant de mise à niveau du plug-in Android Gradle.

AGP version 8.5 ou antérieure

Remarque :Dans les versions 8.3 à 8.5 d'AGP, les applications sont alignées sur 16 ko par défaut. Toutefois, bundletool ne zipaligne pas les APK par défaut. L'application peut donc sembler fonctionner, mais lorsqu'elle est compilée à partir d'un bundle dans Play, elle ne s'installe pas.

Si vous ne pouvez pas mettre à niveau AGP vers la version 8.5.1 ou ultérieure, vous pouvez utiliser des bibliothèques partagées compressées. Mettez à jour votre configuration Gradle pour que Gradle compresse vos bibliothèques partagées lors de l'empaquetage de votre application afin d'éviter les problèmes d'installation de l'application avec des bibliothèques partagées non alignées.

Groovy

Dans votre fichier build.gradle, ajoutez l'option suivante:

android {
  ...
  packagingOptions {
      jniLibs {
        useLegacyPackaging true
      }
  }
}

Kotlin

Dans votre fichier build.gradle.kts, ajoutez l'option suivante:

android {
  ...
  packagingOptions {
      jniLibs {
        useLegacyPackaging = true
      }
  }
}

Avertissement :Lorsque vous utilisez des bibliothèques partagées compressées, votre application prend plus de place lors de son installation, car les bibliothèques sont extraites de l'APK et copiées sur le disque. L'installation de votre application peut échouer plus fréquemment, car cette augmentation de l'utilisation du disque signifie qu'il y a moins d'espace sur l'appareil. Pour éviter cela, mettez à niveau AGP vers la version 8.5.1 ou ultérieure.

Compiler votre application avec un alignement ELF de 16 Ko

Pour que votre application s'exécute, les appareils de 16 ko nécessitent que les segments ELF des bibliothèques partagées soient correctement alignés à l'aide d'un alignement ELF de 16 ko.

Remarque :Si votre application n'extrait pas de bibliothèques natives dans le système de fichiers (extractNativeLibs défini sur false), vous remarquerez probablement une légère augmentation de la taille binaire de votre application après la compilation à l'aide d'un alignement ELF de 16 ko. Les optimisations apportées au gestionnaire de paquets dans Android 15 annulent les coûts d'exécution liés à cette augmentation.

Pour compiler votre application à l'aide d'un alignement ELF de 16 ko, suivez la procédure décrite dans l'une des sections suivantes en fonction de la version du NDK Android que vous utilisez.

Important :Si votre application utilise des bibliothèques partagées précompilées, vous devez également les recompiler de la même manière et réimporter les bibliothèques alignées sur 16 ko dans votre application.

Android NDK r28 ou version ultérieure

La version r28 du NDK et les versions ultérieures compilent les fichiers 16 Ko alignés par défaut.

Android NDK r27

Pour compiler des bibliothèques partagées alignées sur 16 ko avec la version r27 ou ultérieure de l'Android NDK, vous devez mettre à jour vos indicateurs ndk-build, build.gradle, build.gradle.kts ou de l'éditeur de liens comme suit:

ndk-build

Dans votre Application.mk:

APP_SUPPORT_FLEXIBLE_PAGE_SIZES := true

Groovy

Dans votre fichier build.gradle, définissez l'argument -DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON:

android {
  ...
  defaultConfig {
    ...
    // This block is different from the one you use to link Gradle
    // to your CMake or ndk-build script.
    externalNativeBuild {
      // For ndk-build, instead use the ndkBuild block.
      cmake {
        // Passes optional arguments to CMake.
        arguments "-DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON"
      }
    }
  }
}

Kotlin

Dans votre fichier build.gradle.kts, définissez l'argument -DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON:

android {
  ...
  defaultConfig {
    ...
    // This block is different from the one you use to link Gradle
    // to your CMake or ndk-build script.
    externalNativeBuild {
      // For ndk-build, instead use the ndkBuild block.
      cmake {
        // Passes optional arguments to CMake.
        arguments += listOf("-DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON")
      }
    }
  }
}

Autres systèmes de compilation

Spécifiez les options de l'éditeur de liens suivantes:

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

Android NDK r26 ou version antérieure

Pour compiler des bibliothèques partagées alignées sur 16 ko avec la version r26 ou antérieure du NDK Android, vous devez mettre à jour votre configuration ndk-build ou cmake comme suit:

ndk-build

Mettez à jour votre Android.mk pour activer l'alignement ELF de 16 Ko:

LOCAL_LDFLAGS += "-Wl,-z,max-page-size=16384"

CMake

Mettez à jour votre CMakeLists.txt pour activer l'alignement ELF de 16 Ko:

target_link_options(${CMAKE_PROJECT_NAME} PRIVATE "-Wl,-z,max-page-size=16384")

Important :Même si votre application établit un lien dynamique avec la bibliothèque standard C++ (libc++_shared.so) à partir des versions r26 et antérieures du NDK, dont certaines ne sont pas alignées sur 16 ko, vous devez tout de même mettre à jour l'alignement de toutes les autres bibliothèques ici, et vous devez mettre à jour votre code pour éviter de dépendre de PAGE_SIZE. Pour tester ces versions antérieures du NDK sur des appareils de 16 ko, les versions Canary des versions LTS du NDK r23 et r25 sont disponibles sur Android CI avec des bibliothèques libc++_shared.so alignées sur 16 ko. Quoi qu'il en soit, nous vous recommandons de passer à Android NDK r27 ou version ultérieure pour passer à la version alignée ELF de 16 ko de la bibliothèque standard C++. Sinon, votre application ne pourra pas être installée sur les appareils 16 ko aujourd'hui.

Si vous ne pouvez pas passer à la nouvelle version du NDK Android, vous pouvez peut-être mettre à jour votre application pour compiler de manière statique la bibliothèque standard C++ dans votre bibliothèque partagée. Consultez la section Compatibilité avec les bibliothèques C++ pour en savoir plus sur l'association statique à la bibliothèque standard C++ et assurez-vous de lire la section Considérations importantes.

Rechercher des instances de code qui font référence à des tailles de page spécifiques

Même si votre application est alignée sur 16 ko, elle peut rencontrer des erreurs si des emplacements de votre code supposent qu'un appareil utilise une taille de page spécifique. Pour éviter cela, procédez comme suit:

1. Supprimez toutes les dépendances codées en dur qui font référence à la constante PAGE_SIZE ou aux instances de votre logique de code qui supposent que la taille de page d'un appareil est de 4 ko (4096).

   Utilisez plutôt getpagesize() ou sysconf(_SC_PAGESIZE).

2. Recherchez les utilisations de mmap() et d'autres API qui nécessitent des arguments alignés sur la page, puis remplacez-les par des alternatives si nécessaire.

Dans certains cas, si votre application utilise PAGE_SIZE comme valeur pratique qui n'est pas liée à la taille de page sous-jacente, votre application ne sera pas interrompue lorsqu'elle sera utilisée en mode 16 ko. Toutefois, si cette valeur est transmise au noyau avec mmap sans MAP_FIXED, le noyau utilise toujours une page entière, ce qui gaspille de la mémoire. Pour ces raisons, PAGE_SIZE n'est pas défini lorsque le mode 16 Ko est activé sur NDK r27 ou version ultérieure.

Si votre application utilise PAGE_SIZE de cette manière et ne transmet jamais directement cette valeur au noyau, au lieu d'utiliser PAGE_SIZE, créez une variable avec un nouveau nom pour indiquer qu'elle est utilisée à d'autres fins et qu'elle ne reflète pas une page de mémoire réelle.

Vérifier la compatibilité des SDK avec les tailles de page de 16 ko

De nombreux SDK sont compatibles avec les tailles de page de 16 Ko, en particulier si vous les compilez vous-même ou si vous obtenez des versions précompilées récentes. Toutefois, comme certaines versions prédéfinies ou versions de SDK ne sont pas compatibles avec 16 ko, vous devez consulter le site Web de chaque fournisseur de SDK pour déterminer la version à utiliser avec 16 ko.

Tester votre application dans un environnement de 16 ko

Une fois que vous avez compilé votre application pour les appareils de 16 ko, vous devez la tester dans un environnement de 16 ko pour voir si elle présente des régressions. Pour ce faire, procédez comme suit :

1. Configurez le SDK Android 15.

2. Configurez l'un des environnements de test suivants:

   • Configurer Android Emulator avec une image système Android 15 basée sur 16 ko
   • Activer le mode 16 Ko sur un appareil à l'aide des options pour les développeurs
   • Utiliser Cuttlefish avec une taille de page de 16 ko sur ARM64
   • Simuler Cuttlefish avec une taille de page de 16 Ko sur x86-64

3. Démarrez votre appareil de test, puis exécutez la commande suivante pour vérifier qu'il utilise un environnement de 16 ko:

   adb shell getconf PAGE_SIZE
   

   La commande doit renvoyer la valeur 16384.

4. Exécutez la commande zipalign suivante pour vérifier que votre application est alignée sur 16 ko, où APK_NAME est le nom du fichier APK de votre application:

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

5. Testez minutieusement votre application, en vous concentrant sur les éléments susceptibles d'être affectés par la modification des instances de code qui font référence à des tailles de page spécifiques.

Configurer Android Emulator avec une image système Android 15 basée sur 16 ko

Important :Un problème connu empêche le débogage avec LLDB avec des images système de l'émulateur de 16 ko. Un correctif est inclus dans le NDK r27 RC 1 et la mise à jour groupée d'Android Studio Koala | 02/01/2024 Canary 5.

Pour configurer un environnement de 16 ko à l'aide de l'émulateur Android, procédez comme suit:

1. Les images système de l'émulateur Android 15 basées sur 16 ko sont compatibles avec Android Studio Jellyfish | 2023.3.1 ou version ultérieure. Toutefois, pour bénéficier d'une expérience optimale lorsque vous travaillez avec la version bêta d'Android 15, téléchargez la dernière version preview d'Android Studio.

   N'oubliez pas que vous pouvez conserver la version existante d'Android Studio, puisque vous pouvez installer plusieurs versions simultanément.

2. Dans Android Studio, cliquez sur Tools > SDK Manager (Outils > Gestionnaire de SDK).

3. Dans l'onglet SDK Platforms (Plates-formes SDK), cochez Show Package Details (Afficher les détails du package), puis développez la section Android VanillaIceCream Preview (Preview Android VanillaIceCream) et sélectionnez une ou les deux images système d'émulateur suivantes, en fonction des appareils virtuels que vous souhaitez créer:

   • Image système ARM 64 v8a expérimentale de Google APIs avec taille de page de 16 ko
   • Image système Intel x86_64 Atom avec taille de page expérimentale de 16 ko pour les API Google
   Remarque :Si vous prévoyez d'émuler un appareil Google Pixel compatible, vous n'avez besoin que de l'image système ARM 64 v8a.

   

4. Cliquez sur Appliquer > OK pour télécharger les images système que vous avez sélectionnées.

5. Suivez la procédure pour configurer un appareil virtuel pour Android 15. Lorsque vous êtes invité à sélectionner une image système, sélectionnez l'image système de 16 ko que vous avez téléchargée. Si elle n'est pas recommandée automatiquement, vous trouverez l'image système de 16 ko dans l'onglet Autres images.

   

Avertissement :Pour les versions Android Emulator 35.1.5 à 35.1.20, et avant la révision 4 des images système de taille de page 16 ko Android 15.0 proposées dans SDK Manager, pour simuler un environnement 16 ko sur les systèmes x86_64, vous devez également suivre les étapes suivantes. Ces étapes ne sont pas nécessaires après la version 35.1.21, ni avec la révision 4 des images système de taille de page 16 ko d'Android 15.0 ou version ultérieure.

1. Dans le Gestionnaire d'appareils, cliquez sur les trois points à côté de l'image de 16 ko, puis sur Afficher sur le disque.
2. Dans ce dossier, recherchez le fichier config.ini.

3. Ajoutez la ligne suivante dans le fichier config.ini et enregistrez les modifications:

   kernel.parameters = androidboot.page_shift=14
   

4. Pour vérifier vos modifications, exécutez la commande suivante, qui devrait renvoyer 16384:

   adb shell getconf PAGE_SIZE
   

Activer le mode 16 ko sur un appareil à l'aide des options pour les développeurs

Activez l'option de développement Démarrer avec une page de 16 ko pour démarrer un appareil en mode 16 ko.

À partir d'Android 15 QPR1, vous pouvez utiliser l'option pour les développeurs disponible sur certains appareils pour démarrer l'appareil en mode 16 ko et effectuer des tests sur l'appareil.

Cette option pour les développeurs est disponible sur les appareils suivants:

• Pixel 8 et Pixel 8 Pro (avec Android 15 QPR1 ou version ultérieure)
• Pixel 8a (avec Android 15 QPR1 ou version ultérieure)

Remarque :Android 15 QPR1 est en version bêta. Pour en savoir plus sur l'obtention de QPR1 sur un appareil éligible, consultez Obtenir les versions bêta QPR d'Android 15 .