Assurer la compatibilité avec les architectures 64 bits

Les applications publiées sur Google Play doivent être compatibles avec les architectures 64 bits. L'ajout d'une version 64 bits de votre application améliore les performances et vous permet de prendre en charge des appareils avec du matériel 64 bits uniquement.

Suivez les étapes ci-dessous pour que votre application 32 bits soit compatible avec les appareils 64 bits.

Évaluer votre application

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 compatible avec les appareils 64 bits. Si elle utilise un code natif, ou si vous n'êtes pas sûr qu'elle en utilise un, vous devez évaluer votre application.

Vérification rapide de l'état

Accédez à la Play Console et consultez les versions existantes pour vérifier si elles sont conformes ou non :

La Play Console affiche également des avertissements qui s'appliquent aux versions brouillon en cas de problème lié à l'exigence 64 bits. L'image suivante en est un exemple.

Si une alerte s'affiche, suivez les étapes ci-dessous pour rendre votre application compatible avec les appareils 64 bits.

Votre application utilise-t-elle du code natif ?

C'est le cas si :

• elle utilise du code C/C++ (natif) ;
• elle est associée à des bibliothèques natives tierces ;
• elle est conçue par un outil de création d'applications tiers qui utilise des bibliothèques natives.

Votre application intègre-t-elle des bibliothèques 64 bits ?

Inspectez la structure de votre fichier APK. Lors de sa compilation, l'APK est empaqueté avec toutes les bibliothèques natives dont a besoin l'application. Celles-ci sont stockées dans différents dossiers en fonction de l'ABI. Il n'est pas obligatoire de prendre en charge toutes les architectures 64 bits, mais vous devez inclure l'architecture 64 bits correspondante pour chaque architecture native 32 bits prise en charge.

Pour l'architecture ARM, les bibliothèques 32 bits se trouvent dans le dossier armeabi-v7a. Les bibliothèques 64 bits équivalentes se trouvent dans le dossier arm64-v8a.

Pour l'architecture x86, recherchez x86 pour 32 bits et x86_64 pour 64 bits.

Assurez-vous de disposer de bibliothèques natives dans ces deux dossiers. En résumé :

Notez que selon votre application, il peut y avoir ou non exactement le même ensemble de bibliothèques dans chaque dossier. L'objectif est de vous assurer que votre application s'exécute correctement dans un environnement 64 bits uniquement.

Généralement, un APK ou un bundle créé pour les architectures 32 bits et 64 bits contient des dossiers pour les deux ABI, chacun avec un ensemble correspondant de bibliothèques natives. Si la version 64 bits n'est pas prise en charge, il se peut que vous trouviez un dossier ABI 32 bits, mais pas de dossier 64 bits.

Rechercher des 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éé. Utilisez-le pour rechercher d'éventuelles bibliothèques natives et vous assurer que des bibliothèques 64 bits sont présentes.

1. Ouvrez Android Studio, puis ouvrez n'importe quel projet.

2. Dans le menu, sélectionnez Build > Analyze APK (Compilation > Analyser l'APK).

   

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

4. Regardez si le dossier lib contient des fichiers ".so". S'il n'y en a pas, votre application est compatible avec les appareils 64 bits et vous n'avez rien d'autre à faire. Si vous voyez des dossiers armeabi-v7a ou x86, cela signifie que vous disposez de bibliothèques 32 bits.

5. Vérifiez si vous avez des fichiers ".so" similaires dans le dossier arm64-v8a ou x86_64.

   

6. Si vous ne disposez d'aucune bibliothèque arm64-v8a ou x86_64, mettez à jour votre processus de compilation pour commencer à compiler et à empaqueter ces artefacts dans votre APK.

7. Si les deux bibliothèques sont déjà empaquetées, vous pouvez passer directement au test de votre application sur du matériel 64 bits.

Rechercher des bibliothèques natives en décompressant les APK

Les fichiers APK sont structurés comme des fichiers ZIP. Utilisez la ligne de commande ou un autre outil d'extraction pour extraire le fichier APK. En fonction de votre outil d'extraction, vous devrez peut-être renommer le fichier au format .zip.

Parcourez les fichiers extraits en suivant les instructions ci-dessus pour déterminer si votre application est compatible avec les appareils 64 bits. Vous pouvez exécuter l'exemple de commande suivant depuis la ligne de commande :

:: Command Line
> zipinfo -1 YOUR_APK_FILE.apk | grep \.so$
lib/armeabi-v7a/libmain.so
lib/armeabi-v7a/libmono.so
lib/armeabi-v7a/libunity.so
lib/arm64-v8a/libmain.so
lib/arm64-v8a/libmono.so
lib/arm64-v8a/libunity.so

Notez dans cet exemple la présence des bibliothèques armeabi-v7a et arm64-v8a, ce qui signifie que l'application est compatible avec les architectures 64 bits.

Compiler votre application avec des bibliothèques 64 bits

Les instructions suivantes expliquent comment compiler des bibliothèques 64 bits. Notez que cette procédure ne concerne que la compilation du code et des bibliothèques que vous pouvez compiler à partir de la source.

Compiler avec Android Studio ou Gradle

La plupart des projets Android Studio utilisent Gradle comme système de compilation sous-jacent. Cette section s'applique donc aux deux cas. Pour activer les compilations pour votre code natif, ajoutez arm64-v8a et/ou x86_64, en fonction des architectures que vous souhaitez prendre en charge, à ndk.abiFilters dans le fichier "build.gradle" de votre application :

// Your app's build.gradle
plugins {
  id 'com.android.app'
}

android {
   compileSdkVersion 27
   defaultConfig {
       appId "com.google.example.64bit"
       minSdkVersion 15
       targetSdkVersion 28
       versionCode 1
       versionName "1.0"
       ndk.abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64'
// ...

// Your app's build.gradle
plugins {
    id("com.android.app")
}

android {
    compileSdkVersion(27)
    defaultConfig {
        appId = "com.google.example.64bit"
        minSdkVersion(15)
        targetSdkVersion(28)
        versionCode = 1
        versionName = "1.0"
        ndk {
            abiFilters += listOf("armeabi-v7a","arm64-v8a","x86","x86_64")
        }
// ...

Compiler avec CMake

Si votre application est compilée à l'aide de CMake, vous pouvez la compiler pour des ABI 64 bits en transmettant arm64-v8a au paramètre "-DANDROID_ABI" :

:: Command Line
> cmake -DANDROID_ABI=arm64-v8a … or
> cmake -DANDROID_ABI=x86_64 …

Compiler avec ndk-build

Si votre application est compilée à l'aide de ndk-build, vous pouvez la compiler pour des ABI 64 bits en modifiant votre fichier "Application.mk" à l'aide de la variable APP_ABI :

APP_ABI := armeabi-v7a arm64-v8a x86 x86_64

Portage de code 32 bits vers 64 bits

Si votre code est déjà exécuté sur le bureau ou sur iOS, vous ne devriez rien avoir d'autre à faire pour Android. Si c'est la première fois que vous créez votre code pour un système 64 bits, le principal problème à résoudre est le fait que les pointeurs ne sont plus adaptés aux types entiers 32 bits comme int.

Mettez à jour le code qui stocke les pointeurs dans des types tels que int, unsigned ou uint32_t. Sur les systèmes Unix, long correspond à la taille du pointeur, mais ce n'est pas le cas sous Windows. À la place, utilisez les types uintptr_t ou intptr_t. Pour stocker la différence entre les deux pointeurs, utilisez le type ptrdiff_t.

Vous devez toujours privilégier les types entiers à largeur fixe spécifiques définis dans <stdint.h> aux types à largeur non fixe comme int ou long, même pour les éléments qui ne sont pas des pointeurs.

Utilisez les indicateurs de compilation suivants pour détecter les cas où votre code effectue des conversions incorrectes entre des pointeurs et des entiers :

-Werror=pointer-to-int-cast
-Werror=int-to-pointer-cast
-Werror=shorten-64-to-32

Les classes Java avec des champs int contenant des pointeurs vers des objets C/C++ ont le même problème. Recherchez jint dans votre source JNI et assurez-vous de passer à long côté Java et à jlong côté C++.

Les déclarations de fonction implicites sont bien plus dangereuses pour le code 64 bits. C/C++ suppose que le type renvoyé d'une fonction implicitement déclarée (c'est-à-dire une fonction pour laquelle le compilateur n'a pas vu de déclaration) est int. Si le type effectivement renvoyé de votre fonction est un pointeur, cela fonctionne bien sur un système 32 bits où votre pointeur s'intègre dans un élément int. Cependant, sur un système 64 bits, le compilateur tronquera la moitié supérieure de votre pointeur. Exemple :

// This function returns a pointer:
// extern char* foo();

// If you don't include a header that declares it,
// when the compiler sees this:
char* result = foo();

// Instead of compiling that to:
result = foo();

// It compiles to something equivalent to:
result = foo() & 0xffffffff;

// Which will then cause a SIGSEGV if you try to dereference `result`.

L'indicateur de compilation suivant transforme les avertissements de déclaration de fonction implicites en erreurs pour que vous puissiez détecter et résoudre ce problème plus facilement :

-Werror=implicit-function-declaration

Si vous disposez de l'assembleur intégré, réécrivez-le ou utilisez une implémentation C/C++ simple.

Si vous avez des tailles de types codées en dur (8 ou 16 octets, par exemple), remplacez-les par l'expression sizeof(T) équivalente, par exemple sizeof(void*).

Si vous devez compiler de manière conditionnelle un code différent pour les versions 32 bits et 64 bits, vous pouvez utiliser #if defined(__LP64__) pour les différences 32/64 génériques, ou __arm__, __aarch64__ (arm64), __i386__ (x86) et __x86_64__ pour les architectures spécifiques prises en charge par Android.

Ajustez les chaînes de format pour les fonctions de type printf ou scanf, car les spécificateurs de format classiques ne vous permettent pas de spécifier des types 64 bits d'une manière correcte à la fois pour les appareils 32 bits et les appareils 64 bits. Les macros PRI et SCN dans <inttypes.h> résolvent ce problème, PRIxPTR et SCNxPTR pour écrire/lire des pointeurs hexadécimaux, et PRId64 et SCNd64 pour écrire/lire des valeurs 64 bits de manière portable.

Lors du passage de 32 à 64 bits, vous devrez peut-être utiliser 1ULL pour obtenir une constante de 64 bits, plutôt que 1, qui ne comporte que 32 bits.

Limiter l'augmentation de la taille avec Android App Bundle

L'ajout d'une architecture 64 bits à votre application peut augmenter la taille de votre APK. Nous vous recommandons vivement d'exploiter la fonctionnalité Android App Bundle pour minimiser l'impact sur la taille de l'ajout d'un code natif 32 et 64 bits dans le même fichier APK.

Développeurs de jeux

Les trois moteurs les plus utilisés sont actuellement compatibles avec les architectures 64 bits :

• Unreal depuis 2015
• Cocos2d depuis 2015
• Unity depuis 2018

Développeurs Unity

Passer à des versions compatibles

Les versions 2018.2 et 2017.4.16 d'Unity sont compatibles avec les architectures 64 bits.

Si vous utilisez une version d'Unity qui n'est pas compatible avec les architectures 64 bits, déterminez la version vers laquelle vous souhaitez effectuer la mise à niveau et suivez les guides fournis par Unity pour procéder à la migration de votre environnement, en veillant à ce que votre application soit mise à niveau vers une version permettant de compiler des bibliothèques 64 bits. Unity vous recommande d'accéder aux dernières fonctionnalités et mises à jour en passant à la dernière version LTS de l'éditeur.

Voici un tableau présentant les différentes versions d'Unity et la procédure à suivre :

Modifier les paramètres de compilation pour générer des bibliothèques 64 bits

Si vous utilisez une version d'Unity compatible avec les bibliothèques Android 64 bits, vous pouvez générer une version 64 bits de votre application en ajustant vos paramètres de compilation. Utilisez le backend IL2CPP comme backend de script. Pour configurer votre projet Unity afin de compiler une architecture 64 bits, procédez comme suit :

1. Accédez à Build Settings (Paramètres de compilation) et assurez-vous de compiler pour Android en vérifiant que le symbole Unity se trouve à côté d'Android dans Platform (Plate-forme). 1. Si le symbole Unity ne se trouve pas à côté de la plate-forme Android, sélectionnez Android, puis cliquez sur Switch Platform (Changer de plate-forme).

2. Cliquez sur Player settings (Paramètres du joueur).

   

3. Accédez à Player Settings Panel > Settings for Android > Other settings > Configuration (Panneau des paramètres du joueur > Paramètres pour Android > Autres paramètres > Configuration).

4. Définissez Scripting Backend (Backend de script) sur IL2CPP.

5. Cochez la case Target Architecture > ARM64 (Architecture cible > ARM64).

   

6. Compilez comme d'habitude !

Notez que la compilation pour ARM64 nécessite que tous vos éléments soient créés spécifiquement pour cette plate-forme. Suivez les conseils d'Unity et pensez à exploiter la fonctionnalité Android App Bundle pour réduire la taille des APK.

APK multiples et compatibilité 64 bits

Si vous utilisez la compatibilité avec plusieurs fichiers APK de Google Play pour publier votre application, notez que la compatibilité 64 bits est évaluée au niveau de la version. Toutefois, l'obligation de fournir une version 64 bits ne s'applique pas aux APK ni aux app bundles qui ne sont pas distribués aux appareils équipés d'Android 9 Pie ou version ultérieure.

Si l'un de vos APK est signalé comme non conforme, mais qu'il s'agit d'une version antérieure et qu'il est impossible de le mettre en conformité, vous pouvez ajouter un attribut maxSdkVersion="27" dans l'élément uses-sdk du fichier manifeste de cet APK. Cet APK n'est pas distribué aux appareils équipés d'Android 9 Pie ou version ultérieure, et ne bloque plus la conformité.

RenderScript et compatibilité 64 bits

Si votre application utilise RenderScript et a été créée avec une version antérieure des outils Android, vous pouvez rencontrer des problèmes de compatibilité 64 bits pour l'application. Avec des outils de compilation antérieurs à la version 21.0.0, le compilateur peut générer un bitcode dans un fichier .bc externe. Ces anciens fichiers .bc ne sont plus compatibles avec les architectures 64 bits. Par conséquent, la présence du fichier dans votre APK entraîne un problème de compatibilité.

Pour résoudre le problème, supprimez tous les fichiers .bc de votre projet, mettez à niveau votre environnement vers build-tools-21.0.0 ou version ultérieure, puis définissez renderscriptTargetApi dans Android Studio sur 21+ pour indiquer au compilateur de ne pas émettre de fichiers .bc. Ensuite, recompilez votre application, recherchez les fichiers .bc et importez-les dans la Play Console.

Tester votre application sur du matériel 64 bits

La version 64 bits de votre application doit offrir la même qualité et les mêmes fonctionnalités que la version 32 bits. Testez votre application pour vous assurer que les utilisateurs des derniers appareils 64 bits bénéficient d'une expérience optimale.

Appareils 64 bits uniquement

Dans la mesure du possible, nous vous recommandons de tester votre application dans un environnement strict 64 bits uniquement de l'une des manières suivantes :

• Google Pixel avec une image système 64 bits uniquement
• Android Emulator

Google Pixel avec une image système 64 bits uniquement

Pour faciliter le développement et le test des applications, nous avons fourni des images système spéciales avec un environnement strict 64 bits uniquement pour certains appareils Pixel. À l'origine, ces images 64 bits uniquement étaient fournies parallèlement à des images système d'usine standards pour les versions preview d'Android 13 et 14, mais vous pouvez continuer à les utiliser pour tester la compatibilité 64 bits de votre application.

Obtenir une image 64 bits uniquement

Comme pour les images système d'usine, vous pouvez flasher une image 64 bits uniquement sur votre appareil à l'aide d'Android Flash Tool ou en flashant manuellement votre appareil, comme décrit dans les sections suivantes.

Flasher votre appareil à l'aide d'Android Flash Tool

Android Flash Tool vous permet de flasher de manière sécurisée une image système sur votre appareil Pixel compatible. Android Flash Tool fonctionne avec n'importe quel navigateur Web compatible avec WebUSB, tel que Chrome ou Edge 79+.

Android Flash Tool vous guide pas à pas pour flasher votre appareil. Vous n'avez pas besoin d'installer d'outils, mais vous devez déverrouiller votre appareil et activer le débogage USB dans les Options pour les développeurs. Pour obtenir des instructions détaillées, consultez la documentation d'Android Flash Tool.

Connectez votre appareil par USB. Accédez ensuite à Android Flash Tool à l'aide de l'un des liens ci-dessous en fonction du type d'image système que vous souhaitez flasher, puis suivez les instructions à l'écran :

• Images système Android 14 (bêta 5.2) 64 bits uniquement

  Sélectionnez l'appareil que vous essayez de flasher :

  • Pixel 4a (5G)
  • Pixel 5
  • Pixel 6
  • Pixel 6 Pro

• Images système Android 13 (QPR3 bêta 3.2) 64 bits uniquement

  Sélectionnez l'appareil que vous essayez de flasher :

  • Pixel 4a (5G)
  • Pixel 5
  • Pixel 6
  • Pixel 6 Pro

Flasher manuellement votre appareil

Vous pouvez également télécharger la dernière image système et la flasher manuellement sur votre appareil. Consultez le tableau suivant pour télécharger l'image système de votre appareil de test. Le flash manuel peut s'avérer utile si vous avez besoin de contrôler précisément l'environnement de test ou si vous devez réinstaller fréquemment votre application, par exemple lors de tests automatisés.

Après avoir sauvegardé les données de votre appareil et téléchargé l'image système correspondante, vous pouvez flasher l'image sur votre appareil.

Vous pouvez choisir de revenir à la dernière version publique à tout moment.

Images d'usine 64 bits uniquement pour Android 14 (bêta 5.3)

Ces images fournissent un environnement strict 64 bits uniquement. Elles vous permettent de tester la compatibilité des applications 64 bits. Ces configurations 64 bits sont réservées aux développeurs.

Images d'usine 64 bits uniquement pour Android 13 (QPR3 bêta 3.2)

Ces images fournissent un environnement strict 64 bits uniquement. Elles vous permettent de tester la compatibilité des applications 64 bits. Ces configurations 64 bits sont réservées aux développeurs.

Revenir à une version publique

Vous pouvez utiliser Android Flash Tool pour flasher l'image d'usine ou obtenir une image système aux spécifications d'usine depuis la page Images d'usine pour les appareils Nexus et Pixel, puis la flasher manuellement sur l'appareil.

Android Emulator

À partir d'Android 12 (niveau d'API 31), les images système d'Android Emulator sont au format 64 bits uniquement. Créez un appareil virtuel Android à l'aide d'une image système avec Android 12 (niveau d'API 31) ou version ultérieure afin d'obtenir un environnement 64 bits uniquement strict pour tester vos applications.

Autres options d'appareil

Si vous ne possédez aucun de ces appareils ou si vous ne pouvez pas utiliser Android Emulator, la meilleure solution consiste à utiliser un appareil compatible 64 bits, par exemple un Google Pixel ou un modèle récent d'un autre fabricant d'appareils.

Installer et tester votre application

Le moyen le plus simple de tester votre APK consiste à installer l'application à l'aide d'Android Debug Bridge (adb). Dans la plupart des cas, vous pouvez fournir --abi comme paramètre pour indiquer les bibliothèques à installer sur l'appareil. L'application sera installée uniquement avec les bibliothèques 64 bits sur l'appareil.

:: Command Line
# A successful install:
> adb install --abi armeabi-v7a YOUR_APK_FILE.apk
Success

# If your APK does not have the 64-bit libraries:
> adb install --abi arm64-v8a YOUR_APK_FILE.apk
adb: failed to install YOUR_APK_FILE.apk: Failure [INSTALL_FAILED_NO_MATCHING_ABIS: Failed to extract native libraries, res=-113]

# If your device does not support 64-bit, an emulator, for example:
> adb install --abi arm64-v8a YOUR_APK_FILE.apk
ABI arm64-v8a not supported on this device

Une fois l'installation terminée, testez votre application comme vous le feriez normalement pour vous assurer que la qualité est identique à celle de la version 32 bits.

Rechercher les problèmes de compatibilité connus

Lorsque vous testez votre application, vérifiez qu'elle ne présente pas les problèmes suivants lorsqu'elle s'exécute sur des appareils 64 bits. Même si votre application ne dépend pas directement des bibliothèques concernées, il se peut que des bibliothèques et SDK tiers dans les dépendances de votre application en dépendent.

SoLoader

Si vous utilisez le SDK de chargeur de code natif SoLoader, passez à la version 0.10.4 ou à une version ultérieure. Si votre application utilise des SDK qui dépendent de SoLoader, veillez également à passer à la dernière version stable des SDK concernés.

SoLoader 0.9.0 et versions antérieures supposent que des bibliothèques système sont présentes dans /vendor/lib:/system/lib. Ce bug n'affecte pas les appareils tels que le Pixel 7 où le chemin d'accès existe, mais cette hypothèse provoque des plantages sur ceux qui n'ont que des bibliothèques système dans /vendor/lib64:/system/lib64.

Pour en savoir plus sur la résolution de ce problème et d'autres problèmes causés par SoLoader, consultez la réponse correspondante dans le centre d'aide Google.

OpenSSL

Si vous utilisez la bibliothèque OpenSSL, passez à OpenSSL 1.1.1i ou version ultérieure. Si votre application utilise des SDK qui fournissent des communications via HTTPS, ou d'autres SDK qui dépendent d'OpenSSL, veillez également à passer à la dernière version du SDK utilisant une version plus récente d'OpenSSL. Contactez le fournisseur du SDK si aucune version n'est disponible.

PAC ARMv8.3 permet d'assurer l'intégrité du flux de contrôle via le matériel en authentifiant les pointeurs au moment de l'exécution. Les versions antérieures d'OpenSSL utilisent ces fonctionnalités de manière incorrecte, ce qui entraîne des plantages au moment de l'exécution sur tous les appareils équipés de processeurs basés sur ARM 8.3a et versions ultérieures.

Pour en savoir plus sur la résolution de ce problème et d'autres problèmes causés par OpenSSL, consultez la réponse correspondante dans le centre d'aide Google.

BTI

ARM 8.5 et versions ultérieures utilisent les instructions de branche cible (BTI) pour se protéger contre les attaques JOP. Les anciennes versions des SDK d'obscurcissement qui ont donné lieu à des branches comportant des décalages aléatoires de bibliothèques compilées avec BTI peuvent provoquer le plantage des applications. Les instructions étant encodées en tant que HINT, ce bug n'affecte pas les appareils non compatibles avec BTI.

Publier

Lorsque vous pensez que votre application est prête, publiez-la normalement. Comme toujours, déployez votre application en respectant les bonnes pratiques en la matière. Nous vous recommandons d'utiliser des canaux de test fermés pour la déployer auprès d'un nombre limité d'utilisateurs afin d'en garantir la qualité.

Comme lorsque vous déployez une mise à jour importante, assurez-vous d'avoir effectué des tests approfondis sur des appareils compatibles 64 bits avant de publier votre application auprès d'un public plus large.