Android 16 en 2026: Nuevas APIs, Modo Escritorio y Preguntas de Entrevista

Android 16 (API level 36, nombre en código "Baklava") representa una de las actualizaciones de plataforma más significativas desde la renovación de Material You en Android 12. Lanzada como versión estable el 10 de junio de 2025, ahora se ejecuta en más del 21% de los dispositivos activos a marzo de 2026, convirtiéndola en la versión de Android más ampliamente desplegada. Para los desarrolladores Android que se preparan para entrevistas en 2026, comprender estos cambios de API es imprescindible.

Nuevo modelo de lanzamiento del SDK: estrategia Major-Minor

Android 16 introduce una estructura de lanzamiento dual que transforma la planificación de adopción de funcionalidades. El SDK major se entregó con la Beta 3 en marzo de 2025, definiendo los cambios de comportamiento y las APIs principales. Un segundo SDK minor siguió el 2 de diciembre de 2025, agregando nuevas APIs sin alterar el comportamiento de la plataforma.

Esta separación es fundamental en entrevistas: el release major es donde residen los cambios que rompen compatibilidad (edge-to-edge, enforcement de orientación), mientras que el release minor proporciona nuevas capacidades (bibliotecas Jetpack adicionales, APIs relacionadas con IA) sin impacto en el comportamiento existente de las aplicaciones. Google diseñó este modelo para acelerar la entrega de APIs mientras ofrece a los equipos enterprise un objetivo anual estable y predecible para el cumplimiento.

Una pregunta común en entrevistas aborda la diferencia entre targetSdkVersion y compileSdkVersion en el contexto de este modelo dual. La respuesta: targetSdkVersion = 36 activa todos los cambios de comportamiento del release major. El SDK minor es únicamente aditivo — no requiere ningún opt-in ni actualización de target.

Enforcement Edge-to-Edge en API 36

Las aplicaciones que apuntan a Android 16 ya no pueden desactivar los layouts edge-to-edge. El sistema ignora las llamadas a setDecorFitsSystemWindows(true) y los flags de visibilidad SystemUI heredados. Cada aplicación debe manejar correctamente los window insets o arriesgarse a que elementos de UI queden ocultos detrás de la barra de estado y la barra de navegación.

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // enableEdgeToEdge() is now the default on API 36+
        // No opt-out available
        enableEdgeToEdge()
        setContent {
            Scaffold(
                modifier = Modifier.fillMaxSize()
            ) { innerPadding ->
                // innerPadding accounts for system bars
                MainContent(
                    modifier = Modifier.padding(innerPadding)
                )
            }
        }
    }
}

El componente Scaffold de Jetpack Compose maneja los insets automáticamente a través de innerPadding. Para aplicaciones basadas en Views, ViewCompat.setOnApplyWindowInsetsListener sigue siendo el enfoque recomendado. El detalle crítico: WindowInsetsCompat.Type.systemBars() debe consumirse explícitamente, o el sistema aplicará un padding predeterminado que podría no coincidir con el diseño de la aplicación.

Los entrevistadores frecuentemente preguntan qué sucede con las apps que dependían de android:fitsSystemWindows="true" en layouts XML. En API 36, este atributo sigue funcionando pero solo aplica padding para las barras del sistema — ya no impide que la aplicación dibuje en edge-to-edge.

Aplicaciones adaptativas y cambios de orientación en pantallas grandes

Android 16 ignora android:screenOrientation y android:resizeableActivity="false" para aplicaciones que no son juegos en pantallas con smallestWidth >= 600dp. Tablets, foldables y monitores externos conectados vía Desktop Mode califican. Esto pone fin a años de layouts de teléfono con letterbox en pantallas grandes.

// Responsive layout using WindowSizeClass
@Composable
fun AdaptiveLayout() {
    val windowSizeClass = currentWindowAdaptiveInfo().windowSizeClass
    when {
        windowSizeClass.windowWidthSizeClass == 
            WindowWidthSizeClass.EXPANDED -> {
            // Two-pane layout for tablets/desktop
            TwoPaneLayout()
        }
        windowSizeClass.windowWidthSizeClass == 
            WindowWidthSizeClass.MEDIUM -> {
            // Adapted layout for foldables
            MediumLayout()
        }
        else -> {
            // Phone layout
            CompactLayout()
        }
    }
}

La biblioteca Jetpack WindowManager proporciona WindowSizeClass para diseño responsive. Una propiedad de opt-out estaba disponible para apps que apuntan específicamente a API 36, pero Android 17 (esperado Q2 2026) elimina esta opción de desactivación por completo.

Los entrevistadores suelen formular esto como: "¿Cómo migrarías una aplicación bloqueada en orientación portrait para soportar pantallas grandes?" La respuesta implica reemplazar la orientación fija con layouts responsive, probar los cambios de configuración (especialmente onConfigurationChanged), y verificar que el estado guardado sobreviva las transiciones de tamaño de pantalla.

Modo escritorio y pantallas conectadas

El Desktop Mode se lanzó como funcionalidad GA en Android 16 QPR3 (Pixel Drop de marzo 2026), con soporte para Pixel 8+ y dispositivos Samsung Galaxy S26/Fold7/Flip7. Conectar un teléfono a un monitor externo vía USB-C lanza una sesión de escritorio independiente con barra de tareas, ventanas redimensionables, múltiples escritorios virtuales y soporte completo de teclado/mouse.

fun launchOnExternalDisplay(context: Context) {
    val displayManager = context.getSystemService(
        Context.DISPLAY_SERVICE
    ) as DisplayManager
    // Find external displays
    val externalDisplays = displayManager.displays.filter {
        it.displayId != Display.DEFAULT_DISPLAY
    }
    if (externalDisplays.isNotEmpty()) {
        val options = ActivityOptions.makeBasic().apply {
            launchDisplayId = externalDisplays.first().displayId
        }
        context.startActivity(
            Intent(context, DesktopActivity::class.java),
            options.toBundle()
        )
    }
}

El teléfono y la pantalla externa operan independientemente — las aplicaciones son específicas del display en el que se ejecutan. Google y Samsung colaboraron en la experiencia de ventanas de escritorio para reducir la fragmentación en el ecosistema. Samsung DeX integra las mismas APIs de plataforma, creando un objetivo de desarrollo unificado.

Consideraciones clave para el Desktop Mode:

• Las métricas de ventana cambian dinámicamente. Nunca almacenar en caché objetos Display. Consultar WindowMetricsCalculator o LocalConfiguration de Compose en cada cambio de configuración.
• Soporte de teclado y mouse. Los periféricos externos son la norma en sesiones de escritorio. Manejar el dispatch de KeyEvent y los estados hover del puntero.
• Soporte multi-instancia. Los usuarios de escritorio esperan múltiples ventanas de la misma aplicación. Declarar android:documentLaunchMode="intoExisting" o manejar FLAG_ACTIVITY_NEW_DOCUMENT apropiadamente.

Notificaciones ProgressStyle y actualizaciones en vivo

Android 16 introduce Notification.ProgressStyle, una nueva plantilla de notificación para experiencias de usuario centradas en el progreso como seguimiento de viajes compartidos, actualizaciones de entregas y navegación. Esto reemplaza los layouts de notificación personalizados ad hoc con un formato estandarizado y promovido por el sistema.

fun buildDeliveryNotification(
    context: Context,
    orderId: String,
    progress: Float,  // 0.0 to 1.0
    currentStep: String
): Notification {
    val style = Notification.ProgressStyle()
        .setStyledByProgress(true)
        .setProgress(progress)
        .setProgressTrackerIcon(
            Icon.createWithResource(context, R.drawable.ic_delivery_truck)
        )
        .addProgressSegment(
            Notification.ProgressStyle.Segment(0.33f)
                .setColor(context, R.color.segment_preparing)
        )
        .addProgressSegment(
            Notification.ProgressStyle.Segment(0.33f)
                .setColor(context, R.color.segment_in_transit)
        )
        .addProgressSegment(
            Notification.ProgressStyle.Segment(0.34f)
                .setColor(context, R.color.segment_delivered)
        )
        .addProgressPoint(
            Notification.ProgressStyle.Point(0.0f)
                .setLabel("Order placed")
        )
        .addProgressPoint(
            Notification.ProgressStyle.Point(0.33f)
                .setLabel("Preparing")
        )
        .addProgressPoint(
            Notification.ProgressStyle.Point(0.66f)
                .setLabel("In transit")
        )
        .addProgressPoint(
            Notification.ProgressStyle.Point(1.0f)
                .setLabel("Delivered")
        )

    return Notification.Builder(context, DELIVERY_CHANNEL_ID)
        .setSmallIcon(R.drawable.ic_notification)
        .setContentTitle("Order #$orderId")
        .setContentText(currentStep)
        .setStyle(style)
        .setOngoing(true)
        .build()
}

ProgressStyle soporta segmentos (secciones coloreadas de la barra de progreso), puntos (hitos etiquetados) y un ícono de seguimiento que se mueve a lo largo de la barra. Configurar setStyledByProgress(true) permite al sistema colorear los segmentos según el avance. Para la preparación de entrevistas sobre notificaciones Android, entender cuándo usar ProgressStyle versus una notificación estándar setProgress() es esencial: ProgressStyle es para trayectos multi-etapa con hitos distintos, mientras que setProgress() sigue siendo apropiado para operaciones de una sola tarea como descargas de archivos.

Navegación predictiva hacia atrás con OnBackInvokedCallback

Android 16 completa la migración plurianual de onBackPressed() a la API OnBackInvokedCallback. El sistema ahora muestra una animación de "peek" de la pantalla de destino durante el gesto hacia atrás, permitiendo a los usuarios confirmar o cancelar. Las aplicaciones que aún sobreescriben onBackPressed() sin registrar un callback rompen esta animación.

class DetailActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        if (Build.VERSION.SDK_INT >= 36) {
            onBackInvokedDispatcher.registerOnBackInvokedCallback(
                OnBackInvokedDispatcher
                    .PRIORITY_SYSTEM_NAVIGATION_OBSERVER
            ) {
                // Observe back navigation without intercepting
                // Log analytics or trigger save-draft logic
                analyticsTracker.logBackNavigation(
                    screen = "detail"
                )
            }
        }
    }
}

La nueva prioridad PRIORITY_SYSTEM_NAVIGATION_OBSERVER permite a las aplicaciones observar eventos de retroceso sin bloquear la animación del sistema. Android 16 también agrega finishAndRemoveTaskCallback y moveTaskToBackCallback para comportamientos personalizados del back-stack que aún se integran con la animación predictiva.

La navegación predictiva también funciona en la navegación de 3 botones en Android 16: mantener presionado el botón de retroceso inicia la misma animación de previsualización que la navegación por gestos. Este es un tema frecuente en entrevistas — los candidatos que solo mencionan la navegación por gestos omiten la mitad de la respuesta.

Cooldown de notificaciones y agrupación obligatoria

Dos cambios adicionales de notificación afectan a todas las aplicaciones Android. El cooldown de notificaciones reduce el volumen de alertas para notificaciones rápidas de la misma aplicación, disminuyendo gradualmente el nivel de sonido durante aproximadamente 60 segundos antes de reiniciarse. Esta función está habilitada por defecto y no puede ser anulada por los desarrolladores.

La agrupación obligatoria de notificaciones significa que el sistema ahora agrupa las notificaciones automáticamente sin importar si la aplicación usa setGroup(). Las aplicaciones que dependían de la prominencia individual de las notificaciones para engagement podrían necesitar replantear su estrategia de notificaciones.

APIs Health Connect FHIR y RangingManager

Android 16 expande Health Connect con soporte de escritura FHIR (Fast Healthcare Interoperability Resources), permitiendo que las aplicaciones de salud creen y almacenen registros médicos estructurados. La API RangingManager unifica la medición de distancia/ángulo a través de BLE channel sounding, BLE RSSI, Ultra-Wideband y Wi-Fi RTT — consolidando lo que previamente requería cuatro superficies de API separadas.

El selector de fotos gana APIs de personalización más profundas, permitiendo a los desarrolladores controlar la apariencia del selector mientras mantienen el mismo modelo de seguridad sandboxed. La búsqueda en proveedores de medios en la nube se agregó en la Developer Preview 2.

Estas APIs tienen menos probabilidad de aparecer en entrevistas Android generales pero son críticas para roles especializados en salud, IoT o aplicaciones multimedia.

Preguntas y respuestas de entrevista Android 16

P: ¿Cuáles son los cambios de comportamiento obligatorios al apuntar a API 36? Se imponen tres cambios: renderizado edge-to-edge (sin opt-out), restricciones de orientación/redimensionamiento ignoradas en pantallas >= 600dp, y navegación predictiva hacia atrás habilitada en todo el sistema. Las apps deben manejar WindowInsets correctamente, soportar layouts responsive y migrar de onBackPressed() a OnBackInvokedCallback.

P: ¿Cómo afecta el Desktop Mode a la arquitectura de una aplicación? El Desktop Mode crea una sesión de display independiente. Las aplicaciones deben evitar cachear objetos Display, soportar métricas de ventana dinámicas, manejar input de teclado/mouse y considerar escenarios multi-instancia. La API ActivityOptions.launchDisplayId permite apuntar a displays específicos programáticamente.

P: ¿Cuándo debería ProgressStyle reemplazar a setProgress()? ProgressStyle es para trayectos de usuario multi-etapa con hitos distintos (viajes compartidos, entregas, navegación). El setProgress() estándar sigue siendo apropiado para progreso de operación única (descarga de archivos, subida). ProgressStyle obtiene visibilidad promovida en el panel de notificaciones.

P: ¿Qué es el modelo de release SDK major/minor de Android 16? El release major (marzo 2025) contiene cambios de comportamiento y requiere actualización de targetSdkVersion. El release minor (diciembre 2025) agrega nuevas APIs sin cambios de comportamiento — no se necesita actualizar targetSdkVersion. Esto desacopla la estabilidad de la innovación.

P: ¿Cómo funciona la navegación predictiva hacia atrás con la navegación de 3 botones? En API 36+, mantener presionado el botón de retroceso en la navegación de 3 botones activa la misma animación predictiva que la navegación por gestos. Las apps deben registrar un OnBackInvokedCallback con la prioridad apropiada. La prioridad PRIORITY_SYSTEM_NAVIGATION_OBSERVER permite observar sin interceptar.

Conclusión

• El edge-to-edge ya no es opcional en API 36. Auditar todas las pantallas para un manejo correcto de WindowInsets, especialmente barras de herramientas personalizadas y bottom sheets.
• Reemplazar los manifests con orientación fija por layouts responsive de Jetpack Compose usando WindowSizeClass antes de que Android 17 elimine la opción de desactivación.
• El Desktop Mode está listo para producción en Pixel 8+ y flagships Samsung. Probar las aplicaciones con pantallas externas, input de teclado y escenarios multi-instancia.
• Migrar de onBackPressed() a OnBackInvokedCallback. Usar PRIORITY_SYSTEM_NAVIGATION_OBSERVER para tracking de analytics sin bloquear animaciones del sistema.
• Adoptar Notification.ProgressStyle para cualquier trayecto de usuario multi-etapa. El cooldown de notificaciones y la agrupación obligatoria afectan a todas las apps independientemente del SDK objetivo.
• El modelo SDK major/minor significa que los cambios de comportamiento llegan una vez al año. El SDK minor trae nuevas APIs sin riesgo de compatibilidad — adoptarlas libremente.