Compatibilidad con arquitecturas de 64 bits

Las apps publicadas en Google Play deben ser compatibles con arquitecturas de 64 bits. Si agregas una versión de 64 bits a la app, mejorarás su rendimiento y te preparará para dispositivos con hardware de 64 bits únicamente.

Los siguientes pasos garantizan que tu app de 32 bits sea compatible con dispositivos de 64 bits.

Evalúa tu app

Si tu app usa únicamente código escrito en el lenguaje de programación Java o Kotlin, incluidos todos los SDKs y las bibliotecas, quiere decir que es compatible con dispositivos de 64 bits. Si tu app usa código nativo o no sabes con seguridad si lo hace, evalúa la app.

Comprobación rápida de estado

Ve a Play Console y consulta las versiones existentes para ver si cumplen con los requisitos.

Play Console también muestra advertencias aplicables a tus versiones en borrador si hay problemas relacionados con el requisito de 64 bits. La siguiente imagen es un ejemplo.

Si aparece una alerta, consulta los siguientes pasos para hacer que tu app sea compatible con dispositivos de 64 bits.

¿Tu app usa código nativo?

Los siguientes casos indican que sí lo hace:

  • Usa cualquier código (nativo) C/C++.
  • Se vincula con alguna biblioteca nativa de terceros.
  • Se compiló mediante terceros que usan bibliotecas nativas.

¿Tu app incluye bibliotecas de 64 bits?

Inspecciona la estructura del archivo APK. Cuando se compila, el APK se empaqueta con las bibliotecas nativas que necesita la app. Esas bibliotecas se almacenan en distintas carpetas según la ABI. No es necesario que ofrezcas compatibilidad con todas las arquitecturas de 64 bits, pero para cada arquitectura nativa de 32 bits que admitas debes incluir la de 64 bits correspondiente.

En el caso de la arquitectura ARM, las bibliotecas de 32 bits se encuentran en la carpeta armeabi-v7a. El equivalente para la arquitectura de 64 bits es arm64-v8a.

En el caso de la arquitectura x86, busca x86 para 32 bits y x86_64 para 64 bits.

Asegúrate de tener bibliotecas nativas en ambas carpetas. En resumen:

Plataforma Carpeta de bibliotecas de 32 bits Carpeta de bibliotecas de 64 bits
ARM lib/armeabi-v7a lib/arm64-v8a
x86 lib/x86 lib/x86_64

Cabe destacar que, según las características de tu app, es posible que no se incluya exactamente el mismo conjunto de bibliotecas en cada carpeta. El objetivo es asegurarse de que la app se ejecute de manera correcta en un entorno solo de 64 bits.

En un caso típico, un APK o paquete compilado para arquitecturas de 32 y 64 bits tiene carpetas para las dos ABI, y cada una incluye el conjunto de bibliotecas nativas correspondiente. Si no es compatible con la arquitectura de 64 bits, es posible que veas una carpeta de 32 bits, pero no una de 64 bits.

Busca bibliotecas nativas con el Analizador de APK

El Analizador de APK es una herramienta que permite evaluar varios aspectos de un APK compilado. Úsala para encontrar bibliotecas nativas y asegurarte de que las bibliotecas de 64 bits estén presentes.

  1. Accede a Android Studio y, luego, abre cualquier proyecto.
  2. En el menú, selecciona Build > Analyze APK…

    Inicia el Analizador de APK

  3. Selecciona el APK que quieras evaluar.

  4. Busca en la carpeta lib, que aloja archivos ".so" si los hay. Si no hay, quiere decir que tu app admite dispositivos de 64 bits y no tendrás que realizar ninguna otra acción. Si encuentras armeabi-v7a o x86, significa que tienes bibliotecas de 32 bits.

  5. Verifica si tienes archivos ".so" similares en las carpetas arm64-v8a o x86_64.

    Inicia el Analizador de APK

  6. Si no tienes ninguna biblioteca arm64-v8a ni x86_64, actualiza el proceso de compilación para comenzar a compilar y empaquetar los artefactos en el APK.

  7. Si ves las dos bibliotecas empaquetadas, puedes avanzar al siguiente paso para probar la app en hardware de 64 bits.

Descomprime los archivos APK para buscar bibliotecas nativas

Los archivos APK están estructurados como archivos ZIP. Con la línea de comandos o cualquier otra herramienta de extracción, descomprime el archivo APK. Según tu herramienta de extracción, es posible que debas cambiar el nombre del archivo a .zip.

Sigue las instrucciones que se indican más arriba para buscar los archivos correspondientes y verificar si tu app es compatible con dispositivos de 64 bits. Puedes ejecutar el siguiente ejemplo de comando desde la línea de comandos:

:: 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

Observa la presencia de las bibliotecas armeabi-v7a y arm64-v8a en este ejemplo, lo cual significa que la app es compatible con arquitecturas de 64 bits.

Compila tu app con bibliotecas de 64 bits

En las siguientes instrucciones, se describe cómo compilar bibliotecas de 64 bits. Ten en cuenta que estos pasos solo abarcan la compilación de código y bibliotecas que puedes compilar desde la fuente.

Si usas bibliotecas o SDKs externos, sigue los pasos que se indican más arriba para asegurarte de que correspondan a versiones de 64 bits. Si no hay versiones de 64 bits disponibles, comunícate con el propietario del SDK o la biblioteca y ten esto en cuenta cuando planifiques la compatibilidad con dispositivos de 64 bits.

Cómo compilar con Android Studio o Gradle

La mayoría de los proyectos de Android Studio usan Gradle como sistema de compilación subyacente; por lo tanto, esta sección se aplica a ambos casos. Habilitar compilaciones para tu código nativo es tan simple como agregar las carpetas arm64-v8a o x86_64, en función de las arquitecturas con las que quieras que sea compatible, a la configuración de ndk.abiFilters del archivo "build.gradle" de la app:

Groovy

// 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'
// ...

Kotlin

// 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")
        }
// ...

Cómo compilar con CMake

Si compilaste tu app con CMake, puedes adaptarla a las ABI de 64 bits. Para ello, debes pasar la carpeta arm64-v8a al parámetro "-DANDROID_ABI":

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

Esta opción no tiene ningún efecto cuando se usa externalNativeBuild. Consulta la sección para compilar con Gradle.

Cómo compilar con ndk-build

Si tu app se compiló con ndk-build, puedes adaptarla a las ABI de 64 bits. Para ello, debes modificar el archivo Application.mk con la variable APP_ABI:

APP_ABI := armeabi-v7a arm64-v8a x86 x86_64

Esta opción no tiene ningún efecto cuando se usa externalNativeBuild. Consulta la sección para compilar con Gradle.

Cómo migrar del código de 32 bits al de 64 bits

Si tu código ya se ejecuta en computadoras o en iOS, no deberías tener que realizar ningún trabajo adicional para Android. Si es la primera vez que se compila tu código para un sistema de 64 bits, el problema principal que debes abordar es que los punteros ya no se ajustan a los tipos enteros de 32 bits como int.

Actualiza el código que almacena punteros en tipos como int, unsigned o uint32_t. En los sistemas Unix, long coincide con el tamaño del puntero, pero no sucede lo mismo en Windows. En su lugar, usa los tipos que revelan la intención uintptr_t o intptr_t. Para almacenar la diferencia entre dos punteros, usa el tipo ptrdiff_t.

Siempre deberías optar por los tipos de número entero de ancho fijo específicos que se definen en <stdint.h>, en lugar de los tradicionales, como int o long, incluso para los elementos que no sean punteros.

Usa las siguientes marcas del compilador para identificar casos en los que tu código convierte punteros en números enteros, y viceversa, de manera incorrecta:

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

Las clases Java con campos int que incluyen punteros a objetos C/C++ tienen el mismo problema. Busca jint en tu fuente JNI y asegúrate de cambiar a long en el lado de Java y a jlong en el lado de C++.

Las declaraciones de función implícitas son mucho más peligrosas para el código de 64 bits. Los objetos C/C++ asumen que el tipo de datos que se muestra de una función declarada de manera implícita (es decir, una función para la que el compilador no vio una declaración) es int. Si el tipo de dato real que se muestra de tu función es un puntero, funcionará bien en un sistema de 32 bits en el que el puntero se adapta a un int. Sin embargo, en un sistema de 64 bits, el compilador quitará la mitad superior del puntero. Por ejemplo:

// 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`.

La siguiente marca del compilador convierte advertencias de declaración de funciones implícitas en errores para que puedas encontrar los problemas y solucionarlos más fácilmente:

-Werror=implicit-function-declaration

Si tienes un ensamblador intercalado, vuelve a escribirlo o usa una implementación C/C++ simple.

Si tienes tamaños hard-coded de tipos (8 o 16 bytes, por ejemplo), reemplázalos por la expresión sizeof(T) equivalente, como sizeof(void*).

Si necesitas compilar condicionalmente un código diferente para 32 bits y 64 bits, puedes usar #if defined(__LP64__) para las diferencias genéricas entre 32 y 64, o __arm__, __aarch64__ (arm64), __i386__ (x86) y __x86_64__ para las arquitecturas específicas compatibles con Android.

Ajusta las cadenas de formato para funciones similares a printf o scanf, ya que los especificadores de formato tradicionales no te permiten especificar tipos de 64 bits de una manera que sea correcta tanto para dispositivos de 32 bits como de 64 bits. Las macros PRI y SCN en <inttypes.h> solucionan este problema: PRIxPTR y SCNxPTR para punteros hexadecimales de escritura y lectura, y PRId64 y SCNd64 para valores de 64 bits de escritura y lectura portátiles.

Cuando realices cambios, es posible que debas usar 1ULL para obtener una constante de 64 bits, en lugar de 1, que solo tiene 32 bits.

Cómo reducir los efectos del aumento de tamaño con Android App Bundle

Si modificas la app para que sea compatible con la arquitectura de 64 bits, es posible que aumente el tamaño del APK. Te recomendamos que aproveches la función Android App Bundle para minimizar el impacto de incluir código nativo de 32 y 64 bits en el mismo APK.

Desarrolladores de juegos

Los tres motores que más se utilizan actualmente admiten 64 bits:

  • Unreal desde 2015
  • Cocos2d desde 2015
  • Unity desde 2018

Desarrolladores de Unity

Actualiza a las versiones compatibles

Unity proporciona compatibilidad con arquitecturas de 64 bits en las versiones 2018.2 y 2017.4.16.

Si tienes una versión de Unity que no es compatible con la arquitectura de 64 bits, determina aquella a la que quieras cambiar y sigue las guías que ofrece Unity a fin de migrar tu entorno. Para ello, debes asegurarte de actualizar tu app a una versión que pueda compilar bibliotecas de 64 bits. Unity recomienda que actualices a la versión más reciente de LTS del editor para tener acceso a las funciones y actualizaciones más nuevas.

En la siguiente tabla, se detallan las distintas versiones de Unity y lo que debes hacer:

Versión de Unity ¿Es compatible con la arquitectura de 64 bits? Acciones recomendadas

2020.x

✔️

Asegúrate de que la configuración de la compilación genere bibliotecas de 64 bits.

2019.x

✔️

Asegúrate de que la configuración de la compilación genere bibliotecas de 64 bits.

2018.4 (LTS)

✔️

Asegúrate de que la configuración de la compilación genere bibliotecas de 64 bits.

2018.3

✔️

Asegúrate de que la configuración de la compilación genere bibliotecas de 64 bits.

2018.2

✔️

Asegúrate de que la configuración de la compilación genere bibliotecas de 64 bits.

2018.1

Ofrece compatibilidad experimental con arquitecturas de 64 bits.

2017.4 (LTS)

✔️

Compatible a partir de la versión 2017.4.16. Asegúrate de que la configuración de la compilación genere bibliotecas de 64 bits.

2017.3

✖️

Actualiza a una versión que sea compatible con arquitecturas de 64 bits.

2017.2

✖️

Actualiza a una versión que sea compatible con arquitecturas de 64 bits.

2017.1

✖️

Actualiza a una versión que sea compatible con arquitecturas de 64 bits.

≤5.6

✖️

Actualiza a una versión que sea compatible con arquitecturas de 64 bits.

Cambia la configuración de la compilación para que genere bibliotecas de 64 bits

Si usas una versión de Unity compatible con bibliotecas de Android de 64 bits, puedes adaptar la configuración de la compilación para generar una versión de 64 bits de la app. Usa el backend de IL2CPP como backend de secuencias de comandos. Para configurar tu proyecto de Unity de manera que sea compatible con arquitecturas de 64 bits, sigue estos pasos:

  1. Accede a Build Settings y asegúrate de que aparezca el símbolo de Unity en Platform junto a Android a fin de verificar que la compilación sea para esa plataforma.
    1. Si el símbolo de Unity no está junto a la plataforma de Android, selecciona Android y haz clic en Switch Platform.
  2. Haz clic en Player settings.

    Configuración del reproductor en Unity

  3. Ve a Player Settings Panel > Settings for Android > Other settings > Configuration.

  4. Establece el valor de Scripting Backend en IL2CPP.

  5. Selecciona la casilla de verificación Target Architecture > ARM64.

    Configuración de arquitecturas de destino en Unity

  6. Procesa la compilación de forma habitual.

Ten en cuenta que compilar para ARM64 requiere que todos tus elementos se compilen específicamente para esa plataforma. Sigue las indicaciones de Unity para reducir el tamaño del APK y considera aprovechar la función Android App Bundle para reducir los efectos del aumento de tamaño.

Cumplimiento del requisito de 64 bits y varios APKs

Si usas la compatibilidad con varios APKs de Google Play para publicar la app, ten en cuenta que el cumplimiento del requisito de 64 bits se evalúa en el nivel de lanzamiento. Sin embargo, este requisito no se aplica a los APKs ni a los paquetes de aplicación que no se distribuyen a dispositivos con Android 9 Pie ni versiones posteriores.

Si uno de tus APKs no cumple con los requisitos, pero es más antiguo y no es posible lograr que los cumpla, una estrategia consiste en agregar un atributo maxSdkVersion="27" en el elemento uses-sdk del manifiesto de ese APK. Este APK no se entregará a los dispositivos con Android 9 Pie ni versiones posteriores, y ya no impedirá el cumplimiento.

Cumplimiento con el requisito de 64 bits y RenderScript

Si la app usa RenderScript y se creó con una versión anterior de las herramientas de Android, es probable que presente problemas de cumplimiento. Con las herramientas de compilación anteriores a 21.0.0, el compilador podría generar código de bits en un archivo .bc externo. Estos archivos .bc heredados ya no son compatibles con las arquitecturas de 64 bits, de manera que el archivo del APK provoca el error de cumplimiento.

Para solucionar el problema, quita los archivos .bc del proyecto, actualiza el entorno a build-tools-21.0.0 o versiones posteriores y establece renderscriptTargetApi en Android Studio como 21+ a fin de indicarle al compilador que no genere archivos .bc. Luego, vuelve a compilar la app, verifica que no haya archivos .bc y súbela a Play Console.

Prueba la app en hardware de 64 bits

La versión de 64 bits de tu app debe ofrecer la misma calidad y el mismo conjunto de funciones que la de 32 bits. Prueba la app para asegurarte de que los usuarios que tengan los dispositivos de 64 bits más recientes disfruten de la mejor experiencia.

Dispositivos solo de 64 bits

Siempre que sea posible, te recomendamos que pruebes tu app en un entorno estricto solo de 64 bits con una de las siguientes opciones:

Google Pixel con una imagen del sistema de solo 64 bits

Para facilitar el desarrollo y las pruebas de apps, proporcionamos imágenes especiales del sistema con un entorno estricto solo de 64 bits para algunos dispositivos Pixel. Estas imágenes de solo 64 bits se proporcionan de forma simultánea con las imágenes del sistema de fábrica estándar para las versiones preliminares de Android.

Android 14 (versión beta)

Para obtener una imagen solo de 64 bits de Android 14, consulta la sección sobre imágenes solo de 64 bits en la página de descargas.

Al igual que con las imágenes del sistema de fábrica, puedes escribir en la memoria flash de tu dispositivo una imagen solo de 64 bits de Android 14. Para ello, usa Android Flash Tool o escríbelo en la memoria flash de forma manual.

Android 13 (QPR3 beta 3.2)

Para obtener una imagen solo de 64 bits de Android 13 QPR3, consulta la sección sobre imágenes solo de 64 bits en la página de descargas.

Al igual que con las imágenes del sistema de fábrica, puedes instalar una imagen solo de 64 bits de Android 13 en tu dispositivo. Para ello, usa Android Flash Tool o escríbelo en la memoria flash de forma manual.

Android Emulator

A partir de Android 12 (nivel de API 31), las imágenes del sistema de Android Emulator son de solo 64 bits Crea un dispositivo virtual de Android (AVD) con una imagen del sistema con Android 12 (nivel de API 31) o versiones posteriores para obtener un entorno estricto de solo 64 bits para pruebas de apps.

Otras opciones de dispositivo

Si no tienes uno de estos dispositivos o no puedes usar Android Emulator, la mejor opción es usar un dispositivo que admita 64 bits, como un Google Pixel o algún otro dispositivo insignia reciente de otros fabricantes.

Instala y prueba tu app

La forma más fácil de probar tu APK es instalar la app mediante Android Debug Bridge (adb). En la mayoría de los casos, puedes suministrar --abi como parámetro para indicar las bibliotecas que quieres instalar en el dispositivo. De esta manera, se instala la app solo con bibliotecas de 64 bits.

:: 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

Una vez que se haya instalado la app de manera correcta, realiza la prueba como lo haces habitualmente para asegurarte de que tenga la misma calidad que la versión de 32 bits.

Cómo comprobar si hay problemas de compatibilidad conocidos

Mientras realizas pruebas, verifica si la app tiene los siguientes problemas que afectan a las apps que se ejecutan en dispositivos de 64 bits. Aunque tu app no dependa de las bibliotecas afectadas directamente, es posible que lo hagan las bibliotecas de terceros y los SDKs en sus dependencias.

SoLoader

Si usas el SDK de cargador de código nativo SoLoader, actualiza a la versión 0.10.4 o posterior. Si la app usa SDKs que dependen de SoLoader, asegúrate de actualizarlo también a la versión estable más reciente de los SDKs afectados.

SoLoader v0.9.0 y versiones anteriores suponen que las bibliotecas del sistema están presentes en /vendor/lib:/system/lib. Este error no se puede observar en dispositivos como el Pixel 7 en los que existe la ruta de acceso, pero esta suposición causa fallas en los dispositivos que solo tienen bibliotecas del sistema en /vendor/lib64:/system/lib64.

Si quieres obtener más información para solucionar este y otros problemas causados por SoLoader, consulta la respuesta correspondiente en el Centro de ayuda de Google.

OpenSSL

Si usas la biblioteca de OpenSSL, actualiza a OpenSSL 1.1.1i o una versión posterior. Si tu app usa SDKs que proporcionan comunicación mediante HTTPS, o bien otros SDKs que dependen de OpenSSL, asegúrate también de actualizar a la versión más reciente del SDK que usa una versión más reciente de OpenSSL. Comunícate con el proveedor del SDK si no hay uno disponible.

La función ARMv8.3 PAC permite la integridad del flujo de control asistido por hardware con la autenticación de punteros en el tiempo de ejecución. Las versiones anteriores de OpenSSL usan esta funcionalidad de manera incorrecta, lo que provoca fallas en el tiempo de ejecución en todos los dispositivos con procesadores basados en ARM versión 8.3a y posteriores.

Si quieres obtener más información para solucionar este y otros problemas causados por OpenSSL, consulta la respuesta correspondiente en el Centro de ayuda de Google.

BTI

ARMv8.5 y versiones posteriores usan instrucciones de destino de la rama (BTI) para ayudar a proteger contra ataques JOP. Las versiones anteriores de los SDKs de ofuscación que se ramifican en compensaciones aleatorias de bibliotecas compiladas con BTI pueden causar que las apps fallen. Debido a que las instrucciones están codificadas como HINTs, este error no se puede observar en dispositivos que no admiten BTI.

Cómo publicar

Cuando consideres que tu app está lista, publícala de la manera habitual. Como siempre, sigue las prácticas recomendadas para la implementación de la app. Te aconsejamos que aproveches los segmentos de pruebas cerradas para lanzar la app entre una cantidad limitada de usuarios y garantizar el mismo nivel de calidad.

Asegúrate de haber probado la app de manera exhaustiva en dispositivos compatibles con arquitecturas de 64 bits antes de publicarla para un segmento de usuarios más amplio, como cuando realizas el lanzamiento de una actualización importante.