Pantallas traseras y secundarias de smartphones: API, casos de uso y límites

Actualizado: 6 de noviembre de 2026.

La pantalla trasera de un smartphone puede ser una pantalla Android completa, un panel cerrado del sistema, una superficie para una ventana independiente o una matriz LED con su propio SDK. Estas variantes solo se parecen vistas desde lejos. Para el desarrollador, cada una tiene una vía de acceso, un ciclo de vida y unas restricciones diferentes.

El teléfono está boca abajo y muestra un temporizador en la parte trasera. Otra persona escanea un billete mientras el propietario sostiene el dispositivo con la pantalla principal hacia sí. En un plegable, el interlocutor ve la traducción. Son casos atractivos, pero hay que empezar preguntando: ¿qué contrato de software permite que nuestra aplicación muestre estos datos?

Investigación actualizada al 5 de noviembre de 2026. Las tablas distinguen funciones de usuario, API documentadas y acceso no confirmado. Las ilustraciones son conceptos propios. En esta investigación no se probaron dispositivos físicos; una página de producto no demuestra la compatibilidad de una aplicación.

1. Cinco tecnologías diferentes detrás de «segunda pantalla»

Esta es la primera bifurcación de la arquitectura. Si el sistema ya traslada una aplicación convencional a una pantalla estrecha, hace falta una buena interfaz adaptable. Si el panel pertenece a un servicio del sistema, cambiar CSS o Compose no abrirá el acceso. Si es una matriz Nothing, WindowManager ni siquiera es su herramienta principal de programación.

2. Mapa de dispositivos: dónde hay una interfaz confirmada y dónde solo una función

La tabla no significa que exista un SDK único para esos modelos. El resultado negativo de la investigación también se formula con precisión: «API pública no confirmada en los materiales revisados». Esto no demuestra la ausencia de acuerdos privados con socios ni de futuras actualizaciones.

3. Xiaomi: las tarjetas del sistema no equivalen a un lienzo abierto

La página del Xiaomi 17 Pro Max describe estados de entregas, viajes y vuelos, controles de música y llamadas, vista previa de la cámara y traslado de imágenes o QR a la parte trasera. Algunas funciones requieren actualizaciones concretas. Son buenos ejemplos de comportamiento para un producto, pero todavía no instrucciones para conectar vuestro APK.

Que el propietario pueda crear una tarjeta personal con un editor de IA no demuestra la existencia de una API a la que una aplicación externa envíe el estado de un pedido. Un editor de usuario, una integración para socios y un SDK público resuelven tareas diferentes. Del mismo modo, acceder a Xiaomi Super Island no concede automáticamente permiso para dibujar en la pantalla trasera.

En Xiaomi 18 Pro no puede extrapolarse mecánicamente el contrato de la generación anterior. No usamos las menciones a nuevas tarjetas de IA ni a su cantidad como promesa de acceso para desarrolladores: los materiales públicos revisados no permiten confirmar un SDK general de pantalla trasera con dibujo arbitrario para APK de terceros. Para evaluar una integración concreta hacen falta el nombre de la API, documentación, condiciones de admisión, lista de modelos y firmware, y un ejemplo ejecutable.

Decisión práctica para el equipo: registrar esta capacidad como pendiente de confirmación, solicitar al fabricante las condiciones del canal correspondiente y continuar con las superficies del sistema ya disponibles. No vender al cliente «compatibilidad con la pantalla trasera Xiaomi» basándose en una captura de otro servicio.

4. Nothing Glyph Matrix: un SDK real y dos formas distintas de trabajar

El Glyph Matrix Developer Kit oficial documenta el control de fotogramas desde una aplicación y los Glyph Toys independientes. Es una vía pública concreta. Se diferencia del Glyph Interface SDK para segmentos luminosos: compartir marca no hace intercambiables el hardware ni los métodos.

En una aplicación, la secuencia es: incorporar la biblioteca correspondiente, declarar com.nothing.ketchum.permission.ENABLE, crear GlyphMatrixManager, llamar a init(callback)y, tras conectarse, registrar el modelo compatible y enviar fotogramas mediante setAppMatrixFrame(). Al terminar de mostrar contenido se utiliza closeAppMatrix(), y la conexión se libera con unInit().

Aquí, «registrar» significa llamar al SDK para el modelo seleccionado. No debe describirse como una aprobación individual obligatoria de cada aplicación dentro de un acuerdo de socios. Las condiciones de uso del kit y los requisitos de distribución se comprueban por separado.

Un Toy necesita un servicio con los action, metadata y preview previstos por el SDK. El sistema lo invoca cuando el usuario lo selecciona; el trabajo empieza con bind y termina con unbind. El controlador de interacciones recibe eventos documentados mediante Messenger. Si el modelo no admite Glyph Touch, no basta con dibujar «mantén pulsado el botón» y dar la tarea por resuelta. El kit actual describe Phone (4a) Pro como una variante con AOD Toys sin Glyph Touch.

Durante el desarrollo conviene mantener un pequeño vocabulario visual: anillo para proceso, símbolo fijo para pausa y dibujo final breve para listo. Es una recomendación propia, no un estándar de Nothing. No convirtáis cada tarea en una animación continua: comprobad el consumo energético, la comprensión de la señal y el comportamiento cuando el sistema muestra un Toy de mayor prioridad.

5. Ulefone: adaptad primero la aplicación convencional

Ulefone describe cuatro modos: pantalla principal, pantalla trasera, alternancia entre ambas y duplicación. En el modo duplicado, ambas caras muestran el mismo contenido y una cara seleccionada recibe la entrada. La explicación del fabricante lo distingue expresamente de dos aplicaciones independientes.

La especificación de la pantalla trasera del Armor 30 Pro indica 3,4 pulgadas y 412 × 960 píxeles físicos. No son 412 × 960 dp ni el ancho listo para usar del viewport CSS. La densidad, las barras del sistema y los ajustes de escala influyen en el espacio de la aplicación. Algunas descripciones promocionales ofrecen datos contradictorios; para una decisión de ingeniería hacen falta la especificación y la medición de la ventana en el dispositivo.

Si Android traslada la aplicación a la parte trasera, puede no hacer falta un SDK del fabricante. Comprobad que se conserven el formulario y la navegación al cambiar de pantalla; que el botón principal siga accesible con el teclado abierto; los saltos de etiquetas largas; el desplazamiento; la orientación y qué cara táctil está activa.

No copiéis una tabla administrativa compleja en esa superficie. Para confirmar la recogida de un pedido bastan su número, el estado actual y una acción clara. Los detalles permanecen en el proceso principal. Una pantalla físicamente pequeña revela enseguida las interfaces con altura fija y botones inalcanzables.

6. DisplayManager + Presentation: contenido independiente en una pantalla disponible

DisplayManager permite obtener pantallas aptas para presentaciones. Es una lista de candidatas, no una forma de desbloquear un panel cerrado del fabricante:

val displayManager =
    getSystemService(Context.DISPLAY_SERVICE) as DisplayManager
val candidates = displayManager.getDisplays(
    DisplayManager.DISPLAY_CATEGORY_PRESENTATION
)

No elijáis a ciegas el primer elemento: podría ser un monitor conectado, no la parte trasera del teléfono. No debe fijarse de antemano el identificador de pantalla como 1. Hay que determinar qué pantalla corresponde al caso actual y si está disponible en el estado presente del dispositivo.

val presentation = object : Presentation(this, selectedDisplay) {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(TextView(context).apply {
            text = "Pedido listo para recoger"
            textSize = 24f
        })
    }
}
try {
    presentation.show()
} catch (error: WindowManager.InvalidDisplayException) {
    showDisplayUnavailable(error)
}

Este fragmento se ejecuta desde una Activity: selectedDisplay y showDisplayUnavailable los proporciona vuestra aplicación. El diseño se crea mediante el contexto de Presentation para utilizar los recursos de la pantalla adecuada. Según el contrato de Presentation , la llamada a show() puede lanzar InvalidDisplayException, aunque antes se haya detectado la pantalla. Gestionad su retirada, la detención del propietario, los cambios de geometría y la liberación de vuestros listeners.

Iniciar una Activity independiente es otra vía

Para ello se comprueba FEATURE_ACTIVITIES_ON_SECONDARY_DISPLAYSy, en una versión compatible, ActivityManager.isActivityStartAllowedOnDisplay(...). La pantalla se especifica mediante ActivityOptions.makeBasic().setLaunchDisplayId(...). La comprobación y el método de inicio requieren versiones mínimas de API diferentes. La documentación de ActivityOptions advierte sobre las restricciones de las pantallas privadas; también siguen vigentes las reglas habituales para iniciar una Activity desde segundo plano.

Si el inicio está prohibido, el resultado correcto es un estado de indisponibilidad claro. Las API ocultas, el root y una superposición sobre la pantalla principal no lo convierten en una integración compatible.

7. WindowAreaController: traslado y doble pantalla en plegables

Jetpack WindowManager describe operaciones diferentes: trasladar una Activity al área trasera y mostrar contenido adicional simultáneamente con el principal. La guía de modos para pantallas plegables utiliza comprobaciones de capacidades y sesiones para ello.

El orden es: encontrar un área adecuada → comprobar la operación concreta → distinguir unsupported, unavailable, available y active → solicitar el traslado o la presentation → conservar la sesión recibida → gestionar su finalización. El sistema puede cerrar la sesión al cambiar la postura del dispositivo o la disponibilidad del modo. Es un evento del ciclo de vida, no necesariamente un error de la aplicación.

Contrastad los ejemplos con la versión instalada de androidx.window. La documentación contiene generaciones de API con WindowAreaInfo y transferActivityToWindowArea, mientras que nuevas páginas de referencia contienen WindowArea y transferToWindowArea. Mezclar una guía antigua con un símbolo alpha nuevo produce código que no compila.

Este mecanismo resulta especialmente claro en la traducción a dos caras: el propietario ve los controles y su interlocutor, texto grande. Pero la existencia de WindowAreaController no demuestra acceso a la pequeña AMOLED de Xiaomi, a un widget arbitrario de un Flip ni a Glyph Matrix.

Cómo reorganizar la interfaz principal en Flip/Fold

Al trasladarla entre la pantalla exterior y la interior cambian más cosas que el tamaño. Hay que comprobar la altura disponible, la densidad, las zonas seguras, el teclado, el estado y la geometría del pliegue. En una ventana estrecha, la lista y los detalles pueden abrirse sucesivamente; en una ancha, uno junto a otro. Deben conservarse el objeto seleccionado, el borrador, la posición de lectura y la operación en curso.

En un dispositivo medio plegado, repartir la vista y los controles entre zonas solo es útil para un caso adecuado y con datos fiables de postura. Una bisagra física, un pliegue que no oculta píxeles y un cambio de ventana convencional son condiciones distintas. En la web, tener un Fold no garantiza que el navegador informe de los segmentos.

El apartado práctico del artículo general muestra cuatro variantes de una misma interfaz y el orden de comprobación de. Para implementarlo existe un skill Adaptive Interfaces para sitios y aplicaciones; las instrucciones de instalación están junto al artículo general. Complementa la comprobación del acceso a la pantalla, sin sustituirla.

8. Qué pueden hacer un sitio web y una PWA

Si el sistema abre el navegador en la pantalla trasera, el sitio se adapta a la ventana real: diseño responsive, botones accesibles, teclado y desplazamiento correctos. La aplicación web no necesita conocer el modelo del teléfono para funcionar bien en un área estrecha.

También existe una Window Management API para colocar ventanas del navegador en varias pantallas. Hay que comprobarla mediante detección de funciones y permisos, por ejemplo antes de acceder a window.getScreenDetails(). Esta API gestiona ventanas del navegador en pantallas disponibles; no da acceso directo a un servicio cerrado del panel trasero ni sustituye el SDK de Glyph.

Instalar una PWA tampoco añade ActivityKit. Si el proyecto necesita realmente integración nativa, hay que diseñar por separado el componente nativo, el canal de datos y su ciclo de vida. No puede prometerse como consecuencia automática de un diseño adaptable.

9. Qué mostrar: un estado breve y una acción deliberada

Para un temporizador resulta útil el tiempo restante. Para una tarea, una fase fiable y su finalización. Para mostrar algo a otra persona, una versión pública preparada expresamente: número de recogida, billete autorizado o texto traducido. El propietario debe entender el paso al modo «mostrar».

La generación con IA pone de manifiesto el riesgo: si el servidor deja de responder, que «el teléfono siga activo» no debe significar que la carcasa muestre un progreso inventado. Un patrón luminoso puede indicar espera, pero el estado «datos desactualizados» debe distinguirse y la finalización confirmada solo aparecer cuando la tarea termine.

Un QR requiere contenido real, superficie suficiente, contraste, zona libre y una prueba con escáner. Una matriz monocroma con pocos puntos no se convierte en una pantalla fiable para billetes porque permita dibujar un patrón parecido. Utilizad un sistema real de emisión y validación de pases, no una imagen decorativa.

No mostréis automáticamente mensajes privados, códigos de verificación ni datos médicos en la cara visible para otras personas. Bloquear la pantalla principal no demuestra que la superficie adicional haya ocultado el contenido. Cambiar de cuenta o cerrar sesión debe retirar las vistas asociadas a ella.

10. Pruebas en dispositivo y decisión de publicación

Medid la utilidad en un caso concreto: si permitió conocer antes el estado, evitar girar el teléfono, mostrar la información necesaria o ejecutar una acción. El número de destellos, fotogramas y aperturas de la aplicación no tiene valor por sí mismo.

Una buena primera versión resuelve un caso claro en un dispositivo confirmado: un temporizador en Glyph Matrix, recogida de pedidos adaptable en Ulefone o traducción a dos caras mediante una Window Area compatible. Ampliad la cobertura después de verificar el acceso y el ciclo de vida. El modelo general de la tarea puede ser único; cada pantalla adicional sigue siendo una integración independiente.

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 y Adaptive Interfaces orienta la adaptación entre tamaños y pantallas. 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 la comprobación del acceso a la pantalla, DisplayManager y Presentation, WindowManager, Glyph Matrix y las reglas de sincronización con la aplicación principal. 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

¿Existe una API Android universal para todas las pantallas traseras?

No hay un contrato único que abra cualquier panel. Existen mecanismos estándar de múltiples pantallas, WindowManager y SDK de fabricantes; primero hay que identificar a cuál pertenece el dispositivo.

¿Se puede prescindir del SDK del fabricante?

Sí, cuando el sistema ya ejecuta una aplicación convencional en la pantalla necesaria o proporciona acceso estándar a la pantalla. Esto no funciona automáticamente en paneles del sistema con acceso cerrado.

¿Un editor de animaciones para usuarios implica que existe un SDK?

No. El editor puede guardar imágenes para una función del sistema sin proporcionar a la aplicación llamadas, eventos ni permiso para mostrar datos actuales.