Cómo precargar aplicaciones en dispositivos Android a escala

La respuesta corta

Colocar una aplicación en una flota son dos decisiones, no una, y los proyectos que lo tratan como una sola decisión suelen pagar la segunda más tarde. La primera decisión es la vía de entrega: cómo llega físicamente el paquete al dispositivo —instalado por una plataforma de gestión tras la inscripción, preparado durante el aprovisionamiento en el banco de trabajo, escrito en la imagen que se envía para que esté presente en el primer arranque, o integrado en una partición del sistema con una posición elevada—. La segunda decisión es la responsabilidad sobre las actualizaciones: quién custodia la clave de firma, quién decide que se publique una versión nueva, cómo se fija una versión en el registro de configuración y qué tiene que ocurrir, física y comercialmente, para retirar una compilación defectuosa. Ambas se condicionan entre sí. Cuanto más profundo se sitúa una aplicación dentro de la compilación, más cosas puede hacer y más caro resulta cambiarla, porque el cambio deja de ser una publicación en una tienda y se convierte en un evento de firmware con un OEM de por medio. Ese equilibrio es todo el tema de esta página. Conviene delimitar algo desde el principio: esta guía trata las vías de llegada al dispositivo, no la cuestión de qué canal de distribución transporta el paquete; Google Play público, Google Play administrado o un APK alojado de forma privada es una decisión relacionada, con sus propias restricciones, y se resuelve por separado de las decisiones de ubicación que se describen a continuación.

Cómo llega una aplicación al dispositivo: cuatro familias de vías

Las vías parecen intercambiables en un documento de requisitos y se comportan de forma muy distinta en campo. Una instalación administrada ocurre después de que el dispositivo se inscribe: el controlador de políticas del dispositivo (DPC), establecido como device owner durante el aprovisionamiento, instala la aplicación por indicación de la plataforma de gestión, que es también la vía por la que la aplicación se actualiza, se sustituye o se elimina más adelante. La preparación en el momento del aprovisionamiento instala el paquete durante la propia sesión de preparación, antes de encajar la unidad, de modo que el dispositivo sale con la aplicación presente vaya o no a mantener una relación de gestión continuada. Una precarga de fábrica escribe el paquete en la imagen que se envía, y es la vía a la que hay que recurrir cuando la aplicación debe estar presente en el primer arranque en un dispositivo que quizá nunca se inscriba y quizá nunca vea una red. La integración en el sistema va un nivel más allá y coloca la aplicación en una partición del sistema, lo que es algo distinto de una precarga y se trata en su propia sección más abajo. Las vías administradas son las más baratas de cambiar y las más fáciles de demostrar, así que la disciplina útil consiste en justificar cualquier opción más pesada en lugar de adoptarla por defecto; los comportamientos estándar de distribución administrada, incluidos los tipos de instalación que bloquean la vía de desinstalación visible para el usuario, están documentados en la guía de aplicaciones de la Android Management API. Todas las vías que siguen dependen del OEM y de la plataforma, y se confirman por modelo en lugar de darse por supuestas a partir del nombre de una familia.

Precarga de aplicaciones frente a integración como aplicación del sistema

Esta es la distinción que con más frecuencia queda sin examinar, porque en las reuniones ambas cosas se describen como «la aplicación viene precargada». Son compromisos de ingeniería distintos, con responsables distintos. Una precarga es la colocación de una aplicación corriente para que esté presente cuando el usuario enciende el dispositivo por primera vez. Una integración como aplicación del sistema cambia lo que la aplicación es: su partición, su posición en materia de permisos, su comportamiento de desinstalación y su relación con todas las compilaciones de firmware futuras. Conviene separar cinco ubicaciones, y son escalonadas. Una aplicación instalada normal vive en el área de datos, la firma el equipo de la aplicación, se puede desinstalar salvo que una política lo bloquee y desaparece con un restablecimiento de fábrica: el equipo de la aplicación es responsable de ella de principio a fin. Una precarga colocada en el área de datos durante el primer arranque, con origen en una región de precarga o de personalización del OEM, resulta idéntica para el usuario, pero un restablecimiento la restaura; el equipo de la aplicación sigue siendo responsable del paquete y el OEM lo es de la ubicación. Una aplicación del sistema preinstalada reside en una partición de solo lectura, como la imagen del sistema o la de producto: al usuario no se le ofrece desinstalarla, solo eliminar cualquier actualización posterior, y la versión de fábrica vuelve tras un restablecimiento porque esa partición nunca se borra. Una aplicación privilegiada va todavía más allá: colocada en el directorio de aplicaciones privilegiadas, puede tener permisos que el framework no concede a una aplicación corriente, y esos permisos deben figurar en la lista de permitidos de permisos privilegiados de la compilación, un mecanismo documentado en la referencia de la lista de permitidos de permisos privilegiados de AOSP. Cuando la imposición está activada, una compilación cuya aplicación privilegiada solicite un permiso ausente de esa lista puede negarse a arrancar, lo que es un fallo a nivel de firmware detectado en el banco de trabajo y no un informe de error llegado desde el campo. Una aplicación firmada con la clave de plataforma es el último paso: se firma con la clave de plataforma del OEM, que el OEM controla y rara vez comparte, y que vincula la aplicación a permisos de nivel de firma y a las compilaciones de ese fabricante. Conviene enunciar con claridad tres consecuencias antes de que nadie se comprometa. Primera, todo lo que va más allá de una instalación normal exige la participación del OEM en la compilación: el equipo de la aplicación ya no puede entregar el artefacto por su cuenta, y la ubicación solo está disponible en la medida en que lo estén la voluntad y el calendario del OEM. Segunda, cada nivel se vuelve a validar con cada cambio de firmware: un parche de seguridad, una actualización de versión de Android o una variante regional de la compilación reabren la pregunta de si la ubicación, los permisos y la lista de permitidos han sobrevivido, y por eso la integración en el sistema se registra como una obligación de mantenimiento y no como una tarea terminada. Tercera, cada nivel cierra puertas. Una compilación firmada con la clave de plataforma ata la aplicación a un único fabricante y complica cualquier cambio a hardware de segunda fuente. Una ubicación privilegiada reduce la lista de dispositivos candidatos a los fabricantes dispuestos a ejecutar siquiera la integración, y puede afectar a la presentación de compatibilidad de la compilación. Y una ubicación en el sistema cambia la historia de la reversión: una aplicación corriente se revierte publicando una versión corregida, mientras que una ubicación en el sistema que está mal en la imagen se corrige con una publicación de firmware, un regreso al banco de trabajo o, en el peor de los casos, un lote que se envía con una limitación conocida adjunta. La regla honesta de planificación es mantener la aplicación en el nivel más ligero que cumpla el requisito, escalar solo frente a un requisito escrito que el nivel inferior demostrablemente no pueda cubrir, y tratar esa escalada como una decisión de selección de dispositivo y no como una decisión de software: la versión más amplia de ese argumento se expone en MDM frente a ROM Android personalizada.

Requisitos previos del paquete que deciden qué vías quedan abiertas

Antes de poder elegir una vía hay que entender el paquete, porque varias de sus propiedades cierran vías en silencio. El nombre de paquete y la identidad de firma deben ser estables entre versiones: son lo que vincula una actualización a una instalación existente, y una discrepancia no se degrada con elegancia —una actualización firmada con una clave distinta de la de la copia que ya está en el dispositivo se rechaza—, de modo que una precarga firmada con una clave de desarrollo puede quedar permanentemente fuera del alcance del canal de actualización de producción. Los permisos en tiempo de ejecución importan dos veces: una por lo que la aplicación necesita para funcionar, y otra porque una política de device owner puede concederlos o denegarlos en silencio, lo que cambia lo que demuestra realmente una prueba de primer uso. La dependencia de los servicios de Google Play es una decisión de vía y no un detalle, ya que un paquete que los presupone se comportará de otra forma en una compilación que no los incluya; la comparación entre GMS y AOSP explica qué elimina esa elección. Las bibliotecas nativas deben corresponder a la arquitectura de CPU del dispositivo, y un paquete compilado para una sola arquitectura excluye en silencio parte de una lista de dispositivos candidatos. El nivel de API objetivo, los supuestos sobre ejecución en segundo plano, los tipos de servicio en primer plano y cualquier dependencia de ser el gestor predeterminado de un intent deben comprobarse contra la versión exacta de Android de la compilación objetivo, y no contra la versión con la que se desarrolló la aplicación. Nada de esto es exótico; son sencillamente las propiedades que deciden si funciona la vía más ligera, y cada una es más barata de confirmar en la primera semana que de descubrir durante una sesión de preparación. La lista completa de comprobaciones previas que debe recorrer un equipo de aplicación se expone en la lista de dispositivos Android preparados para aplicaciones.

• Nombre de paquete e identidad de firma estables entre versiones y coincidentes con el canal de actualización
• Permisos en tiempo de ejecución revisados frente a las expectativas de privilegio mínimo y frente a lo que la política concede en silencio
• Dependencia de los servicios de Play resuelta frente a un objetivo GMS o AOSP antes de fijar la lista de dispositivos candidatos
• Bibliotecas nativas ajustadas a la arquitectura de CPU del dispositivo en todos los modelos incluidos en el alcance
• Nivel de API objetivo, ejecución en segundo plano y supuestos sobre el gestor predeterminado comprobados en la compilación exacta

Quién es responsable de la actualización después de la entrega

La entrega es la mitad fácil. La mitad que decide si una flota se mantiene sana es quién es responsable de la versión una vez que las unidades están en campo, y se concreta en cuatro preguntas que corresponden a un contrato y no a una conversación. La primera es la custodia de la clave. Quien tenga la clave de firma tiene la capacidad de publicar cualquier actualización, porque la plataforma solo acepta una versión nueva firmada con la misma identidad que la instalada. Si la aplicación se distribuye a través de una tienda que gestiona la clave de firma en nombre del editor, el artefacto entregado a la fábrica para la precarga debe ser el que esa tienda vaya a distribuir, y no una compilación firmada localmente del mismo código fuente: de lo contrario, la copia precargada y la copia de la tienda son dos aplicaciones distintas para el dispositivo, y la actualización de la tienda no se instalará sobre la precarga. La mecánica, incluida la diferencia entre una clave de carga y la clave de firma y las circunstancias limitadas en las que se puede rotar una clave, está documentada en la guía de firma de aplicaciones de Android. La custodia de la clave lleva además una pregunta de salida: si termina la relación con el integrador, con el OEM o con el distribuidor, quién puede seguir firmando una publicación. La segunda pregunta es la fijación de versión. Un despliegue solo es reproducible si la versión aprobada se anota como un código de versión y una identidad de compilación exactos en la especificación de configuración del dispositivo, junto con la compilación de firmware contra la que se aceptó. Una especificación de configuración que nombra una aplicación sin fijar su versión no ha fijado nada, porque el artefacto se moverá. La fijación también da al lote una comprobación que puede ejecutarse en lugar de suponerse: cada unidad preparada informa de una versión, y esa versión o coincide con el registro o la unidad se detiene. La tercera pregunta es la reversión, y es la que con más frecuencia se supone en lugar de diseñarse. En Android, una aplicación instalada no acepta normalmente un paquete con un código de versión inferior, y el soporte de reversión que sí existe a nivel de plataforma es limitado y depende del instalador. En la práctica, revertir significa publicar un código de versión superior que contiene el código anterior, lo que solo es posible si ese código anterior todavía se puede compilar, todavía se puede firmar y sigue siendo compatible con el estado que la versión defectuosa haya creado en el backend. Para una aplicación precargada la situación es todavía más difícil, porque la copia que está en la imagen no se mueve: revertir una actualización devuelve el dispositivo a la versión de fábrica, que puede ser más antigua de lo que la flota espera, y corregir la propia imagen es un evento de firmware con el plazo de entrega del OEM. Un plan de reversión que sobrevive al contacto con la realidad nombra el artefacto, la persona que puede firmarlo, el canal que lo transporta, el tiempo previsto hasta llegar a un dispositivo y qué hace la flota mientras tanto. La cuarta pregunta es la que hay que probar en lugar de creer: «la aplicación se actualiza sola». Esa frase puede significar una actualización gestionada por una tienda, una actualización impulsada por la plataforma de gestión, un actualizador integrado en la aplicación que descarga su propio paquete, o absolutamente nada en una compilación que carece del componente del que depende ese actualizador. Las vías de autoactualización necesitan a menudo un permiso de instalación que la política de device owner ha restringido, un acceso a la red que una configuración bloqueada no permite, o un componente de tienda que no está presente en la compilación objetivo. Trátelo como una afirmación con una prueba adjunta: sobre la muestra aceptada y sobre la compilación aceptada, publique una versión nueva y observe si llega, cuánto tarda, si el dispositivo debe estar desbloqueado o atendido, y qué ocurre cuando la actualización aterriza en mitad de un turno mientras una persona está a medias de una tarea. La responsabilidad sobre las actualizaciones es además un elemento del traspaso, porque la flota sobrevive al proyecto: designe a la persona que publica, a la persona que aprueba y a la persona a la que se llama cuando una publicación sale mal.

• Custodia de la clave asignada, incluido quién puede seguir firmando una publicación si termina la relación comercial
• Código de versión e identidad de compilación exactos fijados en la especificación de configuración frente a una compilación de firmware designada
• Reversión diseñada como una publicación hacia delante del código anterior, con firmante, canal y tiempo de llegada previsto designados
• Comportamiento de autoactualización probado en la compilación aceptada en lugar de aceptarse como una afirmación de producto
• Editor, aprobador y contacto de escalamiento designados antes del traspaso, no después de la primera publicación defectuosa

Demostrar la entrega y la actualización en la muestra con control de versiones

Una vía de entrega es una hipótesis hasta que una unidad la demuestra. La muestra con control de versiones fija el modelo exacto y el SKU regional, la versión de Android y la compilación de firmware, el nombre de paquete, el código de versión y el firmante de la aplicación, la vía de aprovisionamiento y la versión de la política, de modo que cada afirmación de esta página queda ligada a algo reproducible y no a una familia de dispositivos. La evidencia de entrega es conductual y parte de un dispositivo limpio: restablezca la unidad a valores de fábrica, ejecute la vía de aprovisionamiento prevista y cronometre cuánto tarda la aplicación en estar presente y utilizable sin que nadie toque el equipo. Después pruebe los estados que realmente ocurren: un dispositivo que arranca sin red, un dispositivo que se enciende por primera vez semanas después de la preparación, una configuración inicial interrumpida, una unidad con poco almacenamiento y un dispositivo del que el usuario intenta eliminar la aplicación. La evidencia de actualización exige un segundo acto sobre la misma unidad: publique una versión nueva, observe cómo llega, confirme que la versión que informa el dispositivo coincide con la publicada y, después, vuelva a la versión anterior por la vía que indique el plan de reversión y confirme que el dispositivo sigue siendo utilizable. La evidencia de eliminación cierra el ciclo: bloquee la desinstalación y después inténtela desde el launcher, desde los ajustes, desde la información de la aplicación y desde cualquier gestor de archivos o gestor de acciones que permita la configuración, y registre qué se ofrece. Los resultados corresponden a un registro estructurado y no a un hilo de chat, que es el propósito de la matriz de aceptación de muestra —escenario, comportamiento esperado, comportamiento observado, veredicto y responsable—, y todo lo que no pueda cerrarse se anota en la biblioteca de limitaciones conocidas para que quien aprueba lo vea antes de firmar. La preparación de lotes reproduce después el estado aceptado en lugar de reinventarlo: la misma imagen, el mismo paquete y el mismo código de versión, la misma vía de aprovisionamiento, comprobados unidad por unidad contra la muestra de referencia y con una regla de parada cuando una unidad se desvía, tal como se describe en dispositivos Android preparados por lotes antes de la entrega. Por eso los programas se cotizan a partir de unas 500 unidades, con una fase piloto de veinte a cien dispositivos dentro del programa: el piloto es donde se confirman las vías de entrega y de actualización en condiciones reales, y el resto de las unidades solo se preparan una vez que existe esa evidencia.

• Una única muestra con control de versiones fija el modelo, el SKU, la compilación de firmware, el paquete, el código de versión, el firmante, la vía de aprovisionamiento y la versión de la política
• La entrega se cronometra desde un dispositivo restablecido de fábrica, por la vía de aprovisionamiento real y sin intervención
• La actualización y la reversión se ejercitan ambas sobre la misma unidad, no solo la primera instalación
• La desinstalación se intenta desde todas las superficies que la configuración deja accesibles, y el resultado se registra
• La preparación de lotes reproduce el estado aceptado y se detiene cuando una unidad se desvía de la referencia

Tratamiento del código y las credenciales en la cadena de entrega

Preparar una flota implica manejar código ajeno y, a menudo, credenciales ajenas. Los controles no tienen nada de extraordinario y siguen siendo los que se omiten. La transferencia del paquete se controla y el artefacto se comprueba antes de entrar en una compilación o en un flujo de preparación, cotejando el archivo recibido con una suma de verificación publicada por el equipo de la aplicación y no con un nombre de archivo. Las cuentas de prueba usan credenciales de privilegio mínimo emitidas para el proyecto y revocadas en el traspaso, nunca secretos de producción, porque un banco de trabajo de preparación es un entorno compartido y un APK que lleva incrustado un token de producción es un problema más duradero que una prueba fallida. Lo que la aplicación puede alcanzar en el dispositivo se delimita de forma deliberada mediante los permisos que solicita y la política aplicada a su alrededor, y cualquier ubicación elevada se justifica por escrito en lugar de concederse porque resultaba cómodo. Son prácticas de trabajo aplicadas y validadas durante la configuración, con los resultados registrados junto al resto de la evidencia de aceptación; se describen aquí como controles, no como una garantía de que un despliegue esté libre de riesgo.

• Transferencia controlada del paquete con una suma de verificación cotejada con lo que publicó el equipo de la aplicación
• Credenciales de proyecto de privilegio mínimo para las cuentas de prueba, revocadas en el traspaso
• Acceso de la aplicación a los datos delimitado mediante los permisos solicitados y la política aplicada
• Ubicación elevada justificada por escrito en lugar de concedida por comodidad

Limitaciones conocidas de las vías de precarga

El marco anterior es una herramienta de planificación, y conviene señalar dónde deja de ser ordenado. La disponibilidad de cada vía depende en todo momento del OEM, de la versión de Android, del EMM y del hardware, de modo que una vía confirmada en un modelo no queda confirmada en su sucesor ni en una variante regional de la compilación del mismo modelo.

• Todo lo que va más allá de una instalación normal exige la participación del OEM en la compilación, y solo está tan disponible como lo estén el calendario y la voluntad de ese OEM.
• Las ubicaciones en el sistema y las privilegiadas se vuelven a validar con cada cambio de firmware, incluidos los parches de seguridad y las variantes regionales de la compilación.
• Una discrepancia de clave de firma entre una copia precargada y el canal de actualización no se puede recuperar sobre el terreno: hay que sustituir la aplicación.
• Un restablecimiento de fábrica borra el área de datos: las instalaciones administradas y las preparadas en el banco de trabajo no lo sobreviven, mientras que las ubicaciones en la partición del sistema sí.
• Las políticas de las tiendas y de las plataformas de gestión sobre aplicaciones preinstaladas cambian con el tiempo y se vuelven a comprobar en cada compilación, en lugar de darse por supuestas a partir de un programa anterior.
• Un dispositivo que nunca se conecta conserva la versión con la que salió; las publicaciones nuevas se acumulan en cola y nunca llegan, y una marca de tiempo de última conexión desactualizada puede parecer un dispositivo sano.

Decida la vía antes de congelar la imagen

El momento más barato para corregir una decisión de entrega es antes de congelar la compilación, porque después esa misma corrección es una publicación de firmware y no una publicación en una tienda. Traiga el requisito y no el mecanismo preferido: si la aplicación debe estar presente sin red en el primer encendido, si el usuario puede eliminarla, si debe volver tras un restablecimiento de fábrica, qué necesita hacer que una aplicación corriente no puede, con qué frecuencia va a cambiar, quién custodiará la clave de firma y el rango de cantidad del que se está hablando. Vantora traslada esas líneas a una vía de entrega y a un nivel de ubicación, indica qué partes se imponen y cuáles simplemente están presentes, confirma la vía en una muestra con control de versiones y registra las limitaciones residuales antes de comprometer nada: las vías de aprovisionamiento que llevan la aplicación al dispositivo se comparan en métodos de aprovisionamiento de dispositivos Android, y el trabajo de integración en sí se describe en Integración de aplicaciones, MDM y modo quiosco.