Android Live Updates e islas de fabricantes: guía práctica

Actualizado: 6 de noviembre de 2026.

En Android no existe una «isla» única que una aplicación dibuje igual en todos los teléfonos. Hay Live Updates estándar, notificaciones del sistema, superficies propias de fabricantes y SDK independientes. Una integración fiable empieza por un caso adecuado y un modelo de estado, y termina probando dispositivos concretos.

El usuario espera un taxi mientras conversa en una aplicación de mensajería. Una interfaz externa útil responde: cuándo llegará el coche, en qué fase está y si hay que salir. Si se pierde la conexión, la hora antigua no debe parecer vigente. Si termina el viaje, la actividad debe finalizar. La forma de la cápsula importa, pero estas propiedades determinan mucho más la calidad del servicio.

Documentación revisada el 5 de noviembre de 2026. El artículo distingue la API general de Android, la vía de integración del fabricante y la compatibilidad real del dispositivo. Los fragmentos Kotlin ilustran la implementación, pero no forman un proyecto Android compilado. Los diseños son propios y esquemáticos; no son capturas de un firmware concreto.

1. Cómo funcionan las Live Updates

La aplicación crea una notificación que describe una actividad en curso y solicita mayor visibilidad. El sistema comprueba las condiciones y determina la representación: tarjeta, pantalla de bloqueo o chip de estado. El fabricante puede añadir sus propios requisitos. Así funciona el mecanismo estándar de Live Updates.

No promete HTML arbitrario, una pantalla Compose ni un lienzo similar a SwiftUI en la barra de estado. La plantilla del sistema limita el diseño, pero permite al sistema operativo adaptar la información a su interfaz. Solicitar promoción no equivale a conseguirla, y conseguirla no demuestra que la persona haya mirado la notificación.

Para el equipo son cinco preguntas independientes: si la tarea es adecuada; si la notificación está bien construida; si se permite mostrarla; si el dispositivo la admite; y qué se observó realmente al probarla. Ninguna puede sustituirse por una línea «Android 16+» en los requisitos.

2. Qué tareas encajan y cuáles necesitan otro mecanismo

Un buen criterio es la necesidad de consultar repetidamente el estado ahora mismo. La entrega de comida y un viaje activo tienen un final claro y una respuesta cambiante. Un paquete que tardará una semana normalmente no necesita una tarjeta permanente durante toda la semana. La notificación de llegada sigue siendo útil.

Procesar un vídeo o generar contenido con IA no se convierte en una Live Update adecuada solo por su duración. Empezad por el estado convencional de la tarea y una notificación del resultado. Si la persona sigue deliberadamente un proceso breve en curso, evaluad el caso según las reglas de la API elegida. No presentéis una animación fluida inventada como progreso medido.

Para acceder regularmente a una función, considerad un widget o un mosaico de Quick Settings. Para música, una sesión multimedia del sistema. Para comunicación, notificaciones de conversación y burbujas permitidas. Estos mecanismos resuelven sus propias tareas sin convertir artificialmente todo en una actividad en directo.

3. Versión del sistema, AndroidX y capa del fabricante: dependencias diferentes

ProgressStyle apareció en Android 16. Pero la disponibilidad del estilo, la promoción del sistema y la isla del fabricante son capacidades diferentes. Comprobad el runtime, QPR/compilación y firmware del fabricante, no solo compileSdk.

En AndroidX, los métodos setRequestPromotedOngoing y setShortCriticalText están documentados desde Core 1.17.0. No es una recomendación para actualizar dependencias a ciegas: examinad primero la versión instalada, sus requisitos y compatibilidad. Compat no añade una nueva superficie física a un sistema antiguo.

4. Permisos y canal de notificaciones

El manifiesto necesita el permiso habitual de notificaciones y una declaración independiente para la promoción:

<uses-permission android:name="android.permission.POST_NOTIFICATIONS" />
<uses-permission android:name="android.permission.POST_PROMOTED_NOTIFICATIONS" />

En Android 13+, la mayoría de las notificaciones requiere el permiso en tiempo de ejecución POST_NOTIFICATIONS. Solicitadlo en un contexto comprensible, por ejemplo cuando la persona activa el seguimiento del pedido. Las reglas del permiso de notificaciones describen la denegación y los cambios al actualizar el sistema. POST_PROMOTED_NOTIFICATIONS no sustituye esta comprobación ni constituye un segundo diálogo convencional de permiso en tiempo de ejecución.

En Android 8+, cread un canal. Elegid la importancia según el significado del evento. No puede elevarse mediante código por encima de la decisión del usuario; un canal existente conserva sus ajustes. Para una notificación promovida, el canal no debe tener IMPORTANCE_MIN.

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
    val channel = NotificationChannel(
        "active_orders",
        "Pedidos actuales",
        NotificationManager.IMPORTANCE_LOW
    )
    context.getSystemService(NotificationManager::class.java)
        .createNotificationChannel(channel)
}

El texto está fijado en el ejemplo para abreviar; la aplicación debe localizarlo. Crear el canal no activa las notificaciones deshabilitadas. Comprobad los ajustes de la aplicación y del canal concreto, y conservad una pantalla de pedido funcional cuando no estén disponibles. No cambiéis silenciosamente a SMS, correo ni una superposición.

5. Ejemplo mínimo en Kotlin y acceso preciso al pedido

A continuación construimos una notificación con una versión de AndroidX Core que contenga los métodos necesarios. snapshot es el estado del pedido ya verificado por la aplicación, openOrderPendingIntent abre el pedido concreto y el icono es un recurso del proyecto. Debéis implementar estos objetos en la arquitectura existente.

val builder = NotificationCompat.Builder(context, "active_orders")
    .setSmallIcon(R.drawable.ic_delivery_status)
    .setContentTitle("Pedido en camino")
    .setContentText(snapshot.summary)
    .setShortCriticalText(
        snapshot.etaMinutes?.let { "$it min" }
    )
    .setOngoing(true)
    .setRequestPromotedOngoing(true)
    .setOnlyAlertOnce(true)
    .setVisibility(NotificationCompat.VISIBILITY_PRIVATE)
    .setContentIntent(openOrderPendingIntent)

val notification = builder.build()

El fragmento evita intencionadamente inventar «4 minutos» cuando no hay ETA. El texto compacto necesita una respuesta muy breve; el sistema decide la longitud que muestra. setOnlyAlertOnce(true) ayuda a evitar una nueva alerta con cada cambio, pero una transición importante como «el conductor espera» necesita un comportamiento diseñado por separado.

Antes de publicar, comprobad el permiso en tiempo de ejecución y la disponibilidad de notificaciones. Después actualizad la misma instancia de la tarea mediante un identificador estable:

NotificationManagerCompat.from(context)
    .notify(snapshot.notificationId, notification)

notify solo se llama aquí después de las comprobaciones. Cada pedido debe tener un ID diferente o una pareja tag + ID distinta. Si todos los procesos usan el mismo ID, un viaje nuevo sobrescribirá el anterior. Según el mecanismo de actualización de notificaciones, volver a publicar con el mismo identificador modifica la notificación existente.

Para PendingIntent , utilizad un destino explícito, flags adecuados y la identidad del objeto concreto. Unos extras distintos no bastan siempre para obtener PendingIntent diferentes. Al navegar, comprobad de nuevo la cuenta actual y el derecho a ver el pedido; el enlace no autentica al usuario. No lo enviéis al inicio a buscar el viaje necesario.

6. ProgressStyle: fases y puntos de control

ProgressStyle describe el avance por un proceso: los segmentos definen tramos, los puntos representan eventos de control y el valor indica la posición en la misma escala. Sirve para rutas con paradas o entregas por fases. La longitud de un segmento no puede interpretarse accidentalmente como segundos en un lugar y porcentajes en otro.

La variante AndroidX utiliza NotificationCompat.ProgressStyle. Hay que combinarla con Compat Builder, y el Notification.ProgressStyle de plataforma con la API de plataforma correspondiente. No mezcléis ambos tipos por el parecido de los ejemplos.

val progressStyle = NotificationCompat.ProgressStyle()
    .setProgressSegments(listOf(
        NotificationCompat.ProgressStyle.Segment(20),
        NotificationCompat.ProgressStyle.Segment(30),
        NotificationCompat.ProgressStyle.Segment(50)
    ))
    .setProgress(measuredProgress)

// Aplicar antes de builder.build():
builder.setStyle(progressStyle)

En este ejemplo didáctico, las tres longitudes forman una escala de 100. El valor measuredProgress debe proceder del modelo real y estar dentro de su intervalo; 20/30/50 solo ilustra la estructura de la API. Si se conocen las fases pero no la proporción completada, mostrad la fase con palabras. Un «65 %» arbitrario no mejora la precisión de la previsión.

7. MetricStyle, temporizadores y valores medidos

MetricStyle en Android 17 está destinado a magnitudes medidas y admite hasta tres métricas y tres acciones. En la vista expandida importan el nombre, el valor y la unidad; al contraerse, algunas métricas pueden no caber. Colocad primero la más importante.

Para un entrenamiento pueden ser tiempo, distancia y pulso; para un temporizador basta con el tiempo. Tener tres espacios no obliga a llenarlos. Si el pulso deja de actualizarse, el valor antiguo no debe seguir pareciendo una medición en directo.

Un cronómetro o una cuenta atrás del sistema es preferible a un mensaje de red nuevo cada segundo. Para notificaciones convencionales compatibles, consultad setUsesChronometer(), setWhen() y el modo de cuenta atrás; para MetricStyle, sus herramientas de tiempo actuales. El ETA del repartidor no es un temporizador: es una previsión que necesita datos nuevos.

8. Cómo saber si la promoción está realmente disponible

Las comprobaciones solo se ejecutan en versiones donde existan los símbolos correspondientes. Para acceder a los ajustes existe Settings.ACTION_MANAGE_APP_PROMOTED_NOTIFICATIONS; explicad antes la utilidad y comprobad que se admita el intent. No abráis los ajustes repetidamente tras cada negativa.

Que falle la promoción no significa por sí solo que el pedido se haya detenido o que se hayan perdido los datos. Es un estado de la representación. El proceso principal debe seguir siendo comprensible sin cápsula. En analítica, distinguid notificación creada, promoción permitida, flag del sistema observado y acción de la persona.

9. Actualizaciones en segundo plano, vigencia y finalización

La API de notificaciones no mantiene la aplicación en ejecución. El transporte del servidor, la ejecución en segundo plano y la visualización de la notificación son mecanismos independientes. FCM o el push del fabricante deben entregar el evento, el código procesarlo en un contexto autorizado y el adaptador representar el estado vigente. Enviarlo correctamente desde el servidor no demuestra que la tarjeta ya se haya actualizado.

Un foreground service solo sirve para una tarea de usuario adecuada y un tipo de servicio permitido. No puede añadirse únicamente para mantener una isla permanente. Google describe por separado las restricciones para iniciar foreground services desde segundo plano. WorkManager tampoco es un canal en tiempo real que opere cada segundo.

Guardad la identidad de la tarea, la revisión del estado, la hora de confirmación y la condición de finalización. Un mensaje antiguo «el repartidor ha salido» recibido después de «entregado» no debe resucitar la actividad. Cambiar de cuenta exige limpiar las vistas asociadas a la cuenta anterior.

Decidid de antemano qué significa la ausencia de datos. Podéis mostrar la última fase conocida con su hora, retirar un ETA no fiable o finalizar la vista en directo según las reglas del producto. Es una decisión explícita de diseño; no sustituyáis silenciosamente lo desconocido por cero ni prolonguéis indefinidamente «dentro de un minuto».

Al finalizar, detened las actualizaciones en curso. Si hace falta un resumen, publicad el estado final diseñado; si no, eliminad la notificación mediante cancel. Ocultarla no cancela el pedido. El comportamiento al retirar notificaciones ongoing varía entre versiones: comprobadlo, sin restaurar la tarjeta por la fuerza para reclamar atención.

10. Samsung, Xiaomi, OPPO y otros: condiciones de integración independientes

En la tabla, «API pública» significa un mecanismo de desarrollo documentado. «Vía OEM» es un canal independiente del fabricante que puede requerir admisión. «Función del dispositivo» confirma una capacidad para el usuario, pero no un SDK para cualquier aplicación. Son niveles de evidencia diferentes.

Samsung: Now Bar debe probarse como una vista independiente

Samsung describe Now Bar principalmente como una superficie de la pantalla de bloqueo para actividades compatibles. El usuario elige las aplicaciones en ajustes; también deben estar permitidas las notificaciones y su visualización en bloqueo. Por tanto, «el sistema es nuevo, nuestra aplicación aparecerá seguro» es una base técnica débil. Las instrucciones de Samsung para configurar Now Bar incluyen los ajustes necesarios y el diagnóstico del contenido ausente.

Para un producto multimedia, tiene sentido implementar primero correctamente la reproducción del sistema. Para una entrega, comprobar Live Updates estándar. No debe prometerse control directo sobre contenido arbitrario de Now Bar hasta encontrar una vía documentada adecuada para vuestra aplicación.

Xiaomi: interfaz expresiva y un procedimiento de integración propio

Xiaomi ofrece Super Island con varias islas, expansión, apertura en una ventana pequeña y transferencia de contenido mediante arrastre. El proceso oficial incluye registrar la aplicación, solicitar el servicio, aprobar el caso de uso y realizar pruebas. La documentación también describe MiPush como mecanismo de entrega cuando el proceso de la aplicación no está ejecutándose.

Los criterios de Xiaomi no son idénticos a los de Google. Las reglas de admisión de Super Island establecen un ciclo de vida finito de hasta 12 horas y prohíben los usos de marketing; ciertas categorías las gestiona el sistema y no admiten integraciones duplicadas. No extrapoléis automáticamente las condiciones del portal chino a Global/EEA: hay que confirmar por separado el acceso al programa y el comportamiento del firmware internacional.

OPPO, OnePlus y realme: nombres parecidos no implican un contrato común

OPPO tiene su propia vía Fluid Cloud. Por ejemplo, la guía de Alibaba Cloud EMAS para actualizar Fluid Cloud describe la preparación, la aprobación de OPPO y las operaciones del servidor. Demuestra las capacidades de ese canal de integración, no un acceso universal para todos los APK en cualquier región.

OnePlus presenta Fluid Cloud en OxygenOS 16 para música, deporte, información de tráfico y entregas. Pero una presentación del producto no sustituye una especificación de integración. En realme C75, Mini Capsule 3.0 muestra el estado de Grab; la compatibilidad de ese servicio no demuestra que cualquier aplicación externa pueda integrarse igual. Incluso en ecosistemas próximos, la matriz de compatibilidad sigue siendo independiente.

vivo y HONOR: se diseña un caso de uso, no un banner arbitrario

Las notificaciones atómicas de vivo contemplan crear, modificar y finalizar una actividad. La descripción de integración de Origin Island mediante EMAS muestra plantillas para cápsula, tarjetas y bloqueo, operaciones locales y push del servidor; el acceso debe solicitarse. La página identifica esta función del canal como prueba pública. Registrad los límites numéricos de frecuencia y duración a partir del contrato vigente del canal concreto, no de una tabla general de Android.

HONOR considera Magic Capsule uno de los puntos de acceso a Magic Live y YOYO, junto con recomendaciones, AOD y otras vistas. Es útil para servicios con una intención actual clara: viajes, reservas o recogida de pedidos. Sin embargo, que exista una cápsula en el sistema no da a la aplicación derecho a ocuparla permanentemente; la vía exacta y las condiciones de acceso deben confirmarse en el programa del fabricante.

Huawei: el nombre del dispositivo no determina la tecnología de desarrollo

Live View de Huawei para usuarios incluye una cápsula compacta y una tarjeta expandible de la tarea actual. Para HarmonyOS NEXT existe un Live View Kitindependiente. No debe tratarse como otra biblioteca Android: HarmonyOS nativa requiere su propia implementación. Tampoco se pueden extrapolar las condiciones de una versión concreta del Kit a todos los dispositivos Huawei.

Nothing: la carcasa se convierte en interfaz

Para Glyph Interface cuenta con un developer kit publicado, pero su documentación limita el uso a aplicaciones en primer plano. Es fundamental: no se puede prometer un indicador de entrega en segundo plano solo por ver una demostración llamativa de LED.

Glyph Matrix tiene su propio conjunto de interfaces y Glyph Toys. En la tabla de compatibilidad, Phone (3) y Phone (4a) Pro difieren en tamaño de matriz y posibilidades de interacción. Comprobad las capacidades del hardware en ejecución, las prioridades de visualización y las condiciones del SDK. Un repositorio público no sustituye esa verificación.

Un buen ejemplo de proyecto es un indicador comprensible del tiempo restante de una sesión de concentración. Uno malo son diez parpadeos parecidos cuyo significado debe memorizarse. La luz no debe ser la única confirmación de error o de finalización de una operación.

TECNO, Infinix y el resto de dispositivos

Los fabricantes muestran Dynamic Port en HiOS y Magic Ring de Infinix. Esta investigación no ha confirmado una vía pública universal para crear cápsulas propias con estos mecanismos. No significa que la integración sea imposible; es una razón para no venderla como una función ya garantizada del proyecto.

Los paneles LED y las pantallas traseras necesitan una clasificación independiente. La guía de segundas pantallas analiza Glyph Matrix, aplicaciones convencionales en Ulefone, Presentation y WindowManager. La admisión en HyperIsland no concede permiso para dibujar en el panel trasero de Xiaomi.

11. Arquitectura: una tarea, varios adaptadores

La aplicación debe tener un único modelo vigente del pedido. De él derivan la pantalla convencional, la notificación y las vistas OEM autorizadas. El fabricante influye en el formato y el canal de entrega, pero no debe crear una versión independiente de la verdad sobre la ubicación del repartidor.

Para cada adaptador OEM, registrad mercado y compilación, identificador de aplicación, caso de uso aprobado, esquema del payload, acciones permitidas, transporte y reglas de actualización y finalización. Tomad los valores de Notification.extras de la especificación oficial, sin deducirlos del aspecto de la cápsula. Una biblioteca conectada sin admisión ni payload verificado todavía no constituye una integración.

Los comandos también son comunes: una pulsación en la notificación llama al mismo controlador de dominio verificado que la pantalla. Repetir una solicitud no debe cancelar dos veces un pedido ni volver a alternar el entrenamiento. Para una acción irreversible, incluid la confirmación necesaria; el tamaño del botón del sistema no reduce el riesgo de una pulsación equivocada.

12. Privacidad y accesibilidad

Diseñad una versión pública del contenido para la pantalla de bloqueo. VISIBILITY_PUBLIC, PRIVATE, SECRET y una public version adecuada ayudan a controlar la exposición, aunque el resultado también depende de los ajustes del usuario y del sistema. Los detalles figuran en la guía de notificaciones de Android.

El número de pedido, el nombre del conductor, la dirección, el código de recogida y los valores médicos tienen distinta sensibilidad. No copiéis todo el contenido de la pantalla principal en una tarjeta pequeña. La disponibilidad del comando no debe eludir la autorización; una etiqueta privada no protege por sí sola la acción.

Comprobad TalkBack, letra grande, RTL, traducciones largas, contraste, bloqueo y AOD. El color de un tramo de progreso debe complementar un texto comprensible. Un número breve sin unidad puede perder todo sentido cuando el sistema retire las etiquetas secundarias.

13. Matriz de pruebas antes de publicar

Registrad para cada resultado el dispositivo, versión/compilación del sistema, región del firmware, versión de la aplicación y ajustes. «Probado en Android» es demasiado impreciso. El emulador ayuda con la implementación general, pero no demuestra el comportamiento de Now Bar o HyperIsland en un teléfono real.

El criterio de aceptación puede formularse así: el usuario recibe un estado actual fiable, abre la tarea correcta, percibe la pérdida de vigencia, conserva el control de la notificación y no vuelve a recibir una actividad obsoleta tras finalizar. Un chip bonito sin estas propiedades sigue siendo una demostración.

Aplicar la guía con Codex y Claude Code

Esta investigación nos llevó a crear skills abiertos para Codex y Claude Code que analizan un proyecto y proponen mejoras útiles para su sitio web o aplicación. Interaction Surfaces ayuda a descubrir superficies e interacciones adecuadas. Las propuestas son opcionales: el usuario elige qué escenarios aportan valor y cuáles quiere implementar.

Para trabajar en vuestra aplicación podéis instalar el skill Interaction Surfaces desde GitHub. Incluye un ejemplo Kotlin, permisos y diagnóstico de Live Updates, integraciones OEM y una guía específica de Wear OS. El paquete en inglés abarca toda la serie; las instrucciones de instalación y un ejemplo de invocación están en el artículo general.

Preguntas frecuentes

¿Puede crearse una isla universal para todo Android?

Se pueden utilizar un modelo de datos común y API estándar, pero no garantizar la misma capa, posición, acciones y admisión en cada dispositivo. Las vías OEM se integran por separado.

Si la notificación se ha creado, ¿por qué no aparece la cápsula?

Comprobad los criterios del caso de uso, propiedades de la notificación, canal, ajustes de promoción, runtime y condiciones del fabricante. La llamada a notify por sí sola no promete una vista promovida.

¿Hace falta SYSTEM_ALERT_WINDOW?

Para una Live Update del sistema, no. Una superposición propia es otro tipo de ventana, con un permiso especial y restricciones. No sustituye una integración nativa en la barra de estado.

¿Sirve una notificación estándar para dispositivos antiguos?

Es una vía compatible independiente que debe diseñarse y probarse para las versiones objetivo. No prometáis vistas nuevas del sistema por utilizar una biblioteca Compat.