Preparar una aplicación para su lanzamiento
Después de haber codificado y probado una aplicación, es necesario preparar un paquete para la distribución. La primera tarea en la preparación de este paquete es compilar la aplicación para el lanzamiento, lo que implica principalmente establecer algunos atributos de la aplicación.
Para compilar la aplicación para lanzamiento, siga estos pasos:
Especificar el icono de la aplicación: todas las aplicaciones de Xamarin.Android deben tener un icono de aplicación especificado. Aunque técnicamente no es necesario, algunos mercados lo requieren, como Google Play.
Versión de la aplicación: este paso consiste en inicializar o actualizar la información de control de versiones. Esto es importante para las actualizaciones futuras de la aplicación y para asegurarse de que los usuarios sean conscientes de qué versión de la aplicación han instalado.
Reducir el APK: se puede reducir considerablemente el tamaño del APK final si se usa el enlazador de Xamarin.Android en el código administrado y ProGuard en el código de bytes de Java.
Proteger la aplicación: impida que los usuarios o los atacantes depuren, alteren o usen técnicas de ingeniería inversa en la aplicación. Para ello, deshabilite la depuración, ofusque el código administrado, agregue protección contra la depuración y la alteración y use la compilación nativa.
Establecer las propiedades de empaquetado: las propiedades de empaquetado controlan la creación del paquete de aplicaciones Android (APK). En este paso se optimiza el APK, se protegen sus activos y se modulariza el empaquetado según sea necesario. Además, puede proporcionar a los usuarios un lote de aplicaciones para Android optimizadas para sus dispositivos.
Compilar: en este paso se compila el código y los recursos para comprobar que se compila en el modo de lanzamiento.
Archivar para la publicación: en este paso se compila la aplicación y se coloca en un archivo para la firma y la publicación.
Cada uno de estos pasos se describe con más detalle a continuación.
Especificar el icono de la aplicación
Se recomienda encarecidamente que cada aplicación de Xamarin.Android especifique un icono de aplicación. Algunos mercados de aplicaciones no permitirán que una aplicación de Android se publique sin uno. La propiedad Icon del atributo Application se usa para especificar el icono de la aplicación para un proyecto de Xamarin.Android.
En Visual Studio 2017 y versiones posteriores, especifique el icono de aplicación en la sección Manifiesto de Android de las Propiedades del proyecto, como se muestra en la siguiente captura de pantalla:
En estos ejemplos, @drawable/icon hace referencia a un archivo de icono que se encuentra en Resources/drawable/icon.png (tenga en cuenta que la extensión .png no está incluida en el nombre del recurso). Este atributo se puede declarar también en el archivo Properties\AssemblyInfo.cs, como se muestra en este fragmento de código de ejemplo:
[assembly: Application(Icon = "@drawable/icon")]
Normalmente, using Android.App se declara en la parte superior de AssemblyInfo.cs (el espacio de nombres del atributo Application es Android.App); sin embargo, puede que necesite agregar esta instrucción using si todavía no está presente.
Versión de la aplicación
El control de versiones es importante para el mantenimiento y la distribución de aplicaciones de Android. Sin ningún tipo de control de versiones, resulta difícil determinar si una aplicación ha de actualizarse o cómo ha de hacerse. Para ayudar con el control de versiones, Android reconoce dos tipos diferentes de información:
Número de versión: valor entero (usado internamente por la aplicación y Android) que representa la versión de la aplicación. La mayoría de las aplicaciones empieza con este valor establecido en 1, que luego se incrementa con cada versión. Este valor no tiene relación ni afinidad con el atributo de nombre de versión (ver abajo). Las aplicaciones y los servicios de publicación no deberían mostrar este valor a los usuarios. Este valor se almacena en el archivo AndroidManifest.xml como
android:versionCode.Nombre de versión: cadena que solo se usa para comunicar información al usuario sobre la versión de la aplicación (según esté instalada en un dispositivo concreto). El nombre de versión está pensado para mostrarse a los usuarios o en Google Play. Android no usa esta cadena internamente. El nombre de versión puede ser cualquier valor de cadena que ayude a un usuario a identificar la versión instalada en el dispositivo. Este valor se almacena en el archivo AndroidManifest.xml como
android:versionName.
En Visual Studio, estos valores se pueden establecer en la sección Manifiesto de Android de las Propiedades del proyecto, como se muestra en la siguiente captura de pantalla:
Reducir el APK
Es posible reducir el tamaño de los APK de Xamarin.Android. Para ello, use el enlazador de Xamarin.Android, que quita el código administrado innecesario, y la herramienta ProGuard de Android SDK, que elimina el código de bytes de Java que no se usa. El proceso de compilación usa primero el enlazador de Xamarin.Android para optimizar la aplicación a nivel de código administrado (C#) y, después, usa ProGuard (si está habilitado) para optimizar el APK a nivel de código de bytes de Java.
Configurar el enlazador
El modo de versión desactiva el tiempo de ejecución compartido y activa la vinculación, de modo que la aplicación solo envía las partes de Xamarin.Android necesarias en tiempo de ejecución. El enlazador de Xamarin.Android usa el análisis estático para determinar qué ensamblados, tipos y miembros de tipo se usan o a los que hace referencia una aplicación de Xamarin.Android. Después, el enlazador descarta todos los ensamblados, tipos y miembros que no se usan (o a los que no se hace referencia). De este modo, se puede producir una reducción significativa del tamaño del paquete. Por ejemplo, tenga en cuenta el ejemplo de HelloWorld, que experimenta una reducción del 83 % en el tamaño final de su APK:
Configuración: Ninguna - Tamaño de Xamarin.Android 4.2.5 = 17,4 MB.
Configuración: Solo ensamblados de SDK - Tamaño de Xamarin.Android 4.2.5 = 3 MB.
Establezca las opciones del enlazador en la sección Opciones de Android de las Propiedades del proyecto:
El menú desplegable Linking (Vinculación) proporciona las siguientes opciones para controlar el enlazador:
Ninguno: esta opción desactiva el enlazador, por lo que no se realizará la vinculación.
Solo ensamblados de SDK: esta opción vinculará solo los ensamblados que requiere Xamarin.Android. No se vincularán otros ensamblados.
Ensamblados de SDK y usuario: se vincularán todos los ensamblados que requiere la aplicación, y no solo los que requiere Xamarin.Android.
La vinculación puede producir algunos efectos secundarios no deseados, por lo que es importante que la aplicación se vuelva a probar en el modo de versión en un dispositivo físico.
ProGuard
ProGuard es una herramienta de Android SDK que vincula y oculta el código de Java. ProGuard normalmente se utiliza para crear aplicaciones más pequeñas reduciendo el tamaño de las grandes bibliotecas incluidas, como Google Play Services, en el APK. ProGuard elimina el código de bytes de Java que no se utiliza, de modo que la aplicación resultante es más pequeña. Por ejemplo, el uso de ProGuard en pequeñas aplicaciones de Xamarin.Android suele llegar a reducir su tamaño hasta en un 24 %, mientras que el uso de ProGuard en aplicaciones más grandes con varias dependencias de bibliotecas suele alcanzar una reducción de tamaño aún mayor.
ProGuard no es una alternativa al enlazador Xamarin.Android. El enlazador de Xamarin.Android vincula el código administrado, mientras que ProGuard vincula el código de bytes de Java. El proceso de compilación usa, en primer lugar, el enlazador de Xamarin.Android para optimizar el código administrado (C#) en la aplicación y, después, usa ProGuard (si está habilitado) para optimizar el APK a nivel del código de bytes de Java.
Cuando se activa Habilitar ProGuard, Xamarin.Android ejecuta la herramienta ProGuard en el APK resultante. Se genera un archivo de configuración de ProGuard que ProGuard usa en tiempo de compilación. Xamarin.Android también admite las acciones de compilación personalizadas de ProguardConfiguration. Puede agregar un archivo de configuración de ProGuard personalizado al proyecto. Para ello, haga clic en él con el botón derecho y selecciónelo como una acción de compilación, tal como se muestra en este ejemplo:
ProGuard está deshabilitado de forma predeterminada. La opción Habilitar ProGuard solo está disponible cuando el proyecto se establece en modo de Lanzamiento. Se omiten todas las acciones de compilación de ProGuard a menos que Enable ProGuard (Habilitar ProGuard) esté activado. La configuración de ProGuard de Xamarin.Android no ofusca el APK y no es posible habilitar la ofuscación, ni siquiera con archivos de configuración personalizados. Si quiere usar la ofuscación, consulte Application Protection with Dotfuscator (Protección de aplicaciones con Dotfuscator).
Para obtener más información sobre cómo usar la herramienta ProGuard, consulte ProGuard.
Proteger la aplicación
Deshabilitar la depuración
Durante el desarrollo de una aplicación Android, la depuración se realiza mediante el uso del Protocolo de conexión de depuración de Java (JDWP). Se trata de una tecnología que permite que herramientas como adb se comuniquen con una JVM para fines de depuración. JDWP está activado de forma predeterminada para las compilaciones de depuración de una aplicación Xamarin.Android. Aunque JDWP es importante durante el desarrollo, puede suponer un problema de seguridad para las aplicaciones lanzadas.
Importante
Deshabilite siempre el estado de depuración en una aplicación lanzada cuando sea posible (a través de JDWP) para obtener acceso completo al proceso de Java y ejecutar un código arbitrario en el contexto de la aplicación si no se deshabilita este estado de depuración.
El manifiesto de Android contiene el atributo android:debuggable, que controla si se puede depurar la aplicación o no. Se considera una buena práctica establecer el atributo android:debuggable en false. La manera más sencilla de hacerlo es mediante la adición de una instrucción de compilación condicional en AssemblyInfo.cs:
#if DEBUG
[assembly: Application(Debuggable=true)]
#else
[assembly: Application(Debuggable=false)]
#endif
Tenga en cuenta que las compilaciones de depuración establecen automáticamente algunos permisos para que la depuración sea más sencilla (como Internet y ReadExternalStorage). Sin embargo, las compilaciones de versión solo utilizan los permisos que usted configure explícitamente. Si al cambiar a la compilación de versión, la aplicación pierde un permiso que estaba disponible en la compilación de depuración, compruebe que ha habilitado explícitamente este permiso en la lista Permisos necesarios como se describe en Permisos.
Protección de aplicaciones con Dotfuscator
Incluso con la depuración deshabilitada, los atacantes siguen teniendo la posibilidad de volver a empaquetar una aplicación, así como de agregar o quitar opciones de configuración o permisos. Esto les permite usar técnicas de ingeniería inversa en la aplicación, depurarla o alterarla. Puede usar Dotfuscator Community Edition (CE) para ofuscar el código administrado e inyectar código de detección de estado de seguridad en tiempo de ejecución en una aplicación de Xamarin.Android en tiempo de compilación para detectar si la aplicación se está ejecutando en un dispositivo liberado y reaccionar en consecuencia.
Dotfuscator CE está incluido con Visual Studio 2017. Para usar Dotfuscator, haga clic en Herramientas > PreEmptive Protection - Dotfuscator.
Para configurar Dotfuscator CE, consulte Using Dotfuscator Community Edition with Xamarin (Usar Dotfuscator Community Edition con Xamarin). Una vez que lo haya configurado, Dotfuscator CE protegerá automáticamente todas las compilaciones que cree.
Empaquetar ensamblados en código nativo
Cuando esta opción está habilitada, los ensamblados se agrupan en una biblioteca compartida nativa. Esto permite comprimir los ensamblados, lo que hace posibles archivos .apk más pequeños. La compresión de ensamblados también confiere una forma mínima de ofuscación, si bien no conviene basarse en ella.
Esta opción requiere una licencia empresarial y solo está disponible cuando está deshabilitada la opción Use Fast Deployment (Utilizar la implementación rápida) . La opción Bundle assemblies into native code (Agrupar los ensamblados en el código nativo) está deshabilitada de forma predeterminada.
Tenga en cuenta que la opción Bundle into Native Code (Agrupar en código nativo)no implica que los ensamblados se compilen en código nativo. La compilación AOT no se puede usar para compilar ensamblados en código nativo.
Compilación AOT
La opción compilación AOT (de la página Propiedades de empaquetado) habilita la compilación Ahead Of Time (AOT) de los ensamblados. Cuando esta opción está habilitada, la sobrecarga de inicio Just-In-Time (JIT) se minimiza al precompilar ensamblados antes del tiempo de ejecución. El código nativo resultante se incluye en el APK junto con los ensamblados sin compilar. Esto da como resultado un tiempo de inicio de la aplicación más corto, pero a costa de tamaños APK ligeramente más grandes.
La opción compilación AOT necesita una licencia de Enterprise o superior. Compilación AOT solo está disponible cuando el proyecto se configura para el modo de versión, y está deshabilitado de manera predeterminada. Para obtener más información sobre la compilación AOT, consulte AOT.
Compilador de optimización de LLVM
El Compilador de optimización de LLVM creará un código compilado más pequeño y rápido y convertirá ensamblados compilados mediante AOT en código nativo, pero a costa de tiempos de compilación más lentos. El compilador de LLVM está deshabilitado de manera predeterminada. Para usar el compilador de LLVM, es necesario habilitar primero la opción Compilación de AOT en la página Propiedades de empaquetado.
Nota:
La opción Compilador de optimización de LLVM necesita una licencia Enterprise.
Establecer las propiedades de empaquetado
Las propiedades de empaquetado se pueden establecer en la sección Android Options (Opciones de Android) de las Properties (Propiedades) del proyecto, como se muestra en la siguiente captura de pantalla:
Muchas de estas propiedades, como Use Shared Runtime (Usar tiempo de ejecución compartido) y Use Fast Deployment (Usar implementación rápida), están pensadas para el modo de depuración. Pero cuando la aplicación está configurada para el modo de versión, hay otras opciones que determinan cómo se optimiza la aplicación para el tamaño y la velocidad de ejecución, cómo se protege contra la alteración y cómo puede empaquetarse para admitir distintas arquitecturas y restricciones de tamaño.
Especificar arquitecturas compatibles
Al preparar una aplicación Xamarin.Android para publicarla, es necesario especificar las arquitecturas de CPU que se admiten. Un APK único puede contener código máquina para admitir varias arquitecturas diferentes. Consulte Arquitecturas de CPU para obtener más información sobre la compatibilidad con varias arquitecturas de CPU.
Generar un paquete (.APK) por ABI seleccionado
Cuando esta opción está habilitada, se creará un APK para cada uno de los ABI admitidos (seleccionados en la pestaña Opciones avanzadas, como se describe en Arquitecturas de CPU) en lugar de un único APK grande para todos los ABI que se admiten. Esta opción solo está disponible cuando el proyecto se configura para el modo de versión, y está deshabilitado de manera predeterminada.
Multi-Dex
Cuando la opción Habilitar Multi-Dex está habilitada, se usan herramientas del SDK de Android para omitir el límite de 65 000 métodos del formato de archivo .dex. La limitación de 65 000 métodos se basa en el número de métodos de Java a los que una aplicación hace referencia (incluidos los de las bibliotecas de las que depende la aplicación), no se basa en el número de métodos que se escriben en el código fuente. Si una aplicación solo define algunos métodos pero usa muchos (o bibliotecas grandes), es posible que se supere el límite de 65 000.
Es posible que una aplicación no use todos los métodos de todas las bibliotecas a los que se haga referencia, de modo que es posible que una herramienta como ProGuard (vea más arriba) pueda eliminar del código los métodos que no se usen. La práctica recomendada es habilitar Habilitar Multi-Dex solo si es absolutamente necesario, por ejemplo, si aplicación aún hace referencia a más de 65 000 métodos de Java incluso después de usar ProGuard.
Para más información sobre Multi-Dex, vea Configurar aplicaciones con más de 64 000 métodos.
Lotes de aplicaciones para Android
Los lotes de aplicaciones son diferentes a los APK, ya que no se pueden implementar directamente en un dispositivo. Es un formato que se debe cargar con todos los recursos y el código compilado. Después de cargar el lote de aplicaciones firmado, Google Play tendrá todo lo necesario para compilar y firmar el APK de la aplicación y proporcionarlo a los usuarios mediante la entrega dinámica.
Para habilitar la compatibilidad con lotes de aplicaciones para Android, deberá habilitar el valor bundle de la propiedad Formato de paquete Android en las opciones del proyecto de Android. Antes de hacerlo, asegúrese de cambiar el proyecto a una configuración de Release, ya que los lotes de aplicaciones están destinados únicamente para los paquetes de lanzamiento.
Ahora puede generar un lote de aplicaciones siguiendo el flujo de archivo. Se generará un lote de aplicaciones para la aplicación.
Para obtener más información sobre los lotes de aplicaciones para Android, vea Acerca de los paquetes Android App Bundle.
Compile
Una vez que haya completado todos los pasos anteriores, la aplicación estará lista para la compilación. Seleccione Compilar > Recompilar solución para comprobar que se compila correctamente en el modo de versión. Tenga en cuenta que en este paso todavía no se produce un APK.
En Signing the App Package (Firmar el paquete de aplicación) se describe con más detalle el proceso de empaquetar y firmar.
Archivo para la publicación
Para empezar el proceso de publicación, haga clic con el botón derecho en el proyecto en el Explorador de soluciones y seleccione el elemento de menú contextual Archivo… :
La opción Archivo… inicia Archive Manager y comienza el proceso de archivado del paquete de aplicaciones, como se muestra en esta captura de pantalla:
Otra forma de crear un archivo consiste en hacer clic con el botón derecho en la solución en el Explorador de soluciones y seleccionar Archivar todo… , con lo que se compila la solución y se archivan todos los proyectos de Xamarin que pueden generar un archivo:
Tanto la opción Archivo como la opción Archivar todo inician automáticamente Archive Manager. Para iniciar Administrador de Archivo directamente, haga clic en el elemento de menú Herramientas > Administrador de Archivo...:
Puede ver los archivos de la solución en cualquier momento. Para ello, haga clic con el botón derecho en el nodo Solución y seleccione Ver archivos:
Archive Manager
Archive Manager está formado por una lista de soluciones, una lista de archivos y un panel de detalles:
En la lista de soluciones se muestran todas las soluciones que tienen como mínimo un proyecto archivado. En la lista de soluciones se incluyen las secciones siguientes:
- Solución actual: muestra la solución actual. Tenga en cuenta que esta área puede estar vacía si la solución actual no tiene ningún archivo.
- Todos los archivos: muestra todas las soluciones que tienen un archivo.
- Cuadro de texto de Búsqueda (en la parte superior): filtra las soluciones incluidas en la lista Todos los archivos según la cadena de búsqueda especificada en el cuadro de texto.
En la lista de archivos se muestra una lista de todos los archivos de la solución seleccionada. En la lista de archivos se incluyen las secciones siguientes:
- Nombre de la solución seleccionada: muestra el nombre de la solución seleccionada en la lista de soluciones. Toda la información que se muestra en la lista de archivos hace referencia a esta solución seleccionada.
- Filtro de plataformas: este campo permite filtrar archivos por tipo de plataforma (por ejemplo, iOS o Android).
- Elementos de archivo: muestra los archivos de la solución seleccionada. Cada elemento de esta lista incluye el nombre del proyecto, la fecha de creación y la plataforma. También puede incluir información adicional, como el progreso cuando se está archivando o publicando un elemento.
En el panel de detalles se muestra información adicional sobre cada archivo. El panel también permite al usuario iniciar el flujo de trabajo de distribución o abrir la carpeta donde se ha creado la distribución. En la sección Comentarios de la compilación se pueden incluir comentarios de compilación en el archivo.
Distribución
Cuando una versión archivada de la aplicación esté lista para la publicación, seleccione el archivo en Archive Manager y haga clic en el botón Distribuir… :
En el cuadro de diálogo Canal de distribución se muestra información sobre la aplicación, una indicación del progreso del flujo de trabajo de distribución y las opciones de canales de distribución. En la primera ejecución, se ofrecen dos opciones:
Es posible elegir uno de los siguientes canales de distribución:
Ad hoc: guarda un APK firmado en el disco que se puede instalar como prueba en dispositivos Android. Vaya a Signing the App Package (Firmar el paquete de aplicación) para obtener información sobre cómo crear una identidad de firma de Android, crear un certificado de firma para aplicaciones de Android y publicar una versión ad hoc de la aplicación en disco. Esta es una buena forma de crear un APK para realizar pruebas.
Google Play: publica un APK firmado en Google Play. Vaya a Publicación en Google Play para obtener información sobre cómo firmar y publicar un APK en Google Play Store.
