Realme ha confirmado que su serie insignia GT 7 estará entre los primeros dispositivos en recibir la actualización de Android 16, varias semanas después de la versión estable de Google del nuevo sistema operativo el mes pasado. Para ofrecer su compromiso de soporte de software más largo, la compañía planea implementar Android 16 con Realme UI 7 a la serie insignia GT 7 y otros dispositivos más antiguos. El Realme GT 7 Pro, impulsado por el chipset de Elite Snapdragon 8, será el primero en recibir la actualización, seguido del GT 7 y GT 7T, que se ejecutan en los procesadores Dimensidad 9400E y 8400 de MediaTek, respectivamente. Una vez que se completa el despliegue de la Serie GT 7, Realme cambiará el enfoque a la línea GT 6, incluidas GT 6 y GT 6T. Aunque Realme aún no ha publicado una lista oficial de elegibilidad, se espera que la actualización de software se extienda más allá de los modelos insignia. Los dispositivos de la serie numérica (como las familias Realme 14 y 13), la serie Narzo (incluidos los modelos Narzo 80 y 70), la serie NEO, la serie P e incluso los teléfonos presupuestarios de la serie C como el Realme C75 y C71 también pueden recibir Android 16. Realme aún no ha especificado las fechas de implementación exactas, pero planea lanzar un horario detallado a finales de este año.
Etiqueta: Android 16

Mishaal Rahman / Android AuthorityTL; Dr. Android 16 presenta actualizaciones en vivo, una nueva característica que eleva las notificaciones continuas a la barra de estado, pero excluye las notificaciones de reproducción de los medios. Esto se debe a que las aplicaciones de medios usan una plantilla dedicada de «estilo de medios», que no es uno de los estilos específicos que se puede promover a una actualización en vivo. El cambio de estilos haría que las aplicaciones de los medios pierdan controles y características clave, es poco probable que los desarrolladores de compensación hagan esta nueva funcionalidad. Escuchar música, audiolibros o podcasts es una de las actividades de teléfonos inteligentes más comunes, por lo que Android ofrece un tratamiento especial de notificaciones de medios. En lugar de agruparlos con otras alertas, Android muestra prominentemente notificaciones de medios en el panel de configuración rápida, en la pantalla de bloqueo e incluso en la pantalla siempre encendida. Aún así, debe reducir la sombra de notificación solo para ver el nombre de la pista actual. Una nueva característica en Android 16 presenta chips de barra de estado que podrían resolver esto, pero lamentablemente, no funcionará con su reproductor de música favorito. He aquí por qué. Estás leyendo una historia de Authority Insights. Descubra las ideas de la autoridad para informes más exclusivos, desmontaje de aplicaciones, filtraciones y cobertura tecnológica en profundidad que no encontrará en ningún otro lugar. Estos informes reflejan desarrollos al momento de escribir. Algunas características o detalles descubiertos en fugas pueden cambiar antes del lanzamiento oficial. Android 16 trae una nueva función de notificación llamada Live Actualates, que son básicamente la versión de Android de actividades en vivo en iOS. Las actualizaciones en vivo son notificaciones especiales que el sistema eleva para aparecer prominentemente en la pantalla de bloqueo, la pantalla siempre en la pantalla, el panel de notificación y en la barra de estado. Por diseño, siempre se expanden por completo y no pueden ser colapsados por el usuario. En la pantalla de bloqueo y la visualización siempre en la pantalla, las actualizaciones en vivo permanecen completamente expandidas incluso cuando se minimizan otras notificaciones. En el cajón de notificaciones, aparecen en la parte superior, mientras que en la barra de estado, se convierten en pequeños chips con un icono y un breve fragmento de texto de la aplicación. Un ejemplo de actualizaciones en vivo de la aplicación Uber Eats en la AOD (izquierda), la pantalla de bloqueo (Medio izquierdo), la barra de estado (Barra de estado derecha) y la notificación de cabezales (derecha). Para una aplicación AOD para calificar como una actualización en vivo, tiene que cumplir con varios llave cita de teclado: Criteria: It Notifications. La aplicación tiene que solicitar el nuevo permiso de Post_promoted_Notification agregado en Android 16 QPR1, que el usuario puede otorgar o revocar en cualquier momento desde la configuración. Debe solicitarse explícitamente. La aplicación debe solicitar al sistema que promocione su notificación a una actualización en vivo, ya sea configurando el indicador extra_request_promoted_ongoing o utilizando la API requestpromotedongoing. Debe ser «continuo». Esto le dice al sistema que la notificación es para una tarea de fondo que el usuario está «comprometido activamente», lo que evita que se lo descarte. Debe seguir reglas de formato específicas. La notificación debe tener un título y una prioridad más alta que la mínima. No puede ser un resumen grupal, incrustar contenido personalizado o usar un color de fondo personalizado. Aunque los requisitos anteriores son sencillos, hay una limitación final y crucial: el estilo de la notificación. Solo las notificaciones que usan una de las cuatro plantillas específicas se pueden promover a una actualización en vivo. Estándar: esta es la plantilla de notificación básica sin características especiales. BigText: esta plantilla se usa para notificaciones que contienen un gran bloque de texto expandible, como un correo electrónico. Llame: personalizado para alertas de llamadas entrantes, este estilo a menudo presenta una gran foto de contacto y proporciona acciones específicas de llamadas como «respuesta» o «declive». Progreso: Nuevo en Android 16, este estilo está diseñado para cualquier tarea que necesite mostrar una barra de progreso. Entonces, ¿por qué las notificaciones de los medios no pueden convertirse en actualizaciones en vivo, especialmente porque a menudo tienen barras de progreso? La respuesta es que no usan el estilo de progreso de Android 16. En su lugar, las aplicaciones de música, audiolibro y podcast generalmente usan la plantilla de estilo de medios dedicada. Como se mencionó anteriormente, hacen esto para recibir el tratamiento especial que Android proporciona para las notificaciones de reproducción de medios. Si cambiaran al estilo de progreso, sus notificaciones no se fijarían al panel de configuración rápida o mostrarían el conmutador de salida de medios, entre otras cosas. En última instancia, las aplicaciones de los medios tendrían que sacrificar la funcionalidad esencial solo para obtener acceso a la función de actualizaciones en vivo: una compensación es poco probable que hagan. Después de todo, Samsung ya ha hecho algo similar en un UI 7, lo que hace que las notificaciones de los medios aparezcan como «notificaciones en vivo» por defecto. Esta sería una gran experiencia de usuario, lo que le permite ver los controles de medios de pista y acceso actuales con un solo toque en el chip de la barra de estado, eliminando la necesidad de deslizar hacia abajo. Mishaal Rahman / Android Authorityas, lo que podemos decir, no hay razón técnica por la que Google no pueda hacer esto. Parece que la compañía simplemente no considera que la reproducción de medios sea un caso de uso válido para actualizaciones en vivo. Según la documentación de Google, la característica es para actividades que están «activamente en progreso, con un comienzo y un final distintos» y requieren la atención del usuario «a lo largo de la actividad». Los usos apropiados incluyen «navegación activa, llamadas telefónicas en curso, seguimiento activo de viajes compartidos y seguimiento activo de entrega de alimentos», mientras que los usos inapropiados incluyen cosas como «mensajes de chat, alertas, próximos eventos calendario y acceso rápido a las funciones de la aplicación». Entonces, si bien la reproducción de los medios no está rechazada explícitamente, no se ajusta al modelo «sensible al tiempo» de Google, lo que explica por qué el estilo de los medios no se promueve automáticamente. Sin embargo, es una pena, porque creemos que mostrar información de reproducción continua en un chip de barra de estado sería una característica fantástica, y al menos Samsung parece estar de acuerdo. Con suerte, Google ve lo que están haciendo sus socios y reevalúa su posición. Para aquellos que desean probar la función de actualizaciones en vivo, deberán instalar el Android 16 QPR1 Beta en un dispositivo de píxel compatible, ya que la función no está activa en la versión estable. También necesitará encontrar una aplicación compatible, como la aplicación de muestra propia de Google. Los desarrolladores interesados en apoyar las actualizaciones en vivo pueden consultar la documentación oficial de Google y experimentar con la última versión alfa de la Biblioteca Core JetPack. ¿Tienes una propina? ¡Habla con nosotros! Envíe un correo electrónico a nuestro personal a news@androidauthority.com. Puede permanecer en el anonimato o obtener crédito por la información, es su elección.