Wear Watchface

Cómo declarar dependencias

Para agregar una dependencia en Wear, debes agregar el repositorio de Maven de Google a tu proyecto. Consulta el repositorio de Maven de Google para obtener más información.

Agrega las dependencias de los artefactos que necesites en el archivo build.gradle de tu app o módulo:

dependencies {
    // Use to implement wear watchfaces
    implementation "androidx.wear.watchface:watchface:1.2.1"

    // Use to implement wear watchface complications
    implementation "androidx.wear.watchface:watchface-complications-data-source:1.2.1"
    // (Kotlin-specific extensions)
    implementation "androidx.wear.watchface:watchface-complications-data-source-ktx:1.2.1"

    // Use to implement a watchface style and complication editor
    implementation "androidx.wear.watchface:watchface-editor:1.2.1"

    // Can use to render complications.
    // This library is optional and watchfaces may have custom implementation for rendering
    // complications.
    implementation "androidx.wear.watchface:watchface-complications-rendering:1.2.1"
}

dependencies {
    // Use to implement wear watchfaces
    implementation("androidx.wear.watchface:watchface:1.2.1")

    // Use to implement wear watchface complications
    implementation "androidx.wear.watchface:watchface-complications-data-source:1.2.1"
    // (Kotlin-specific extensions)
    implementation "androidx.wear.watchface:watchface-complications-data-source-ktx:1.2.1"

    // Use to implement a watchface style and complication editor
    implementation("androidx.wear.watchface:watchface-editor:1.2.1")

    // Can use to render complications.
    // This library is optional and watchfaces may have custom implementation for rendering
    // complications.
    implementation "androidx.wear.watchface:watchface-complications-rendering:1.2.1"
}

Para obtener más información sobre las dependencias, consulta Cómo agregar dependencias de compilación.

Comentarios

Tus comentarios ayudan a mejorar Jetpack. Avísanos si descubres nuevos errores o tienes ideas para mejorar esta biblioteca. Consulta los errores existentes de esta biblioteca antes de crear uno nuevo. Puedes agregar tu voto a un error existente haciendo clic en el botón de la estrella.

Crear un error nuevo

Consulta la documentación sobre la Herramienta de seguimiento de errores para obtener más información.

Versión 1.3

Versión 1.3.0-alpha03

17 de abril de 2024

Lanzamiento de androidx.wear.watchface:watchface-*:1.3.0-alpha03. La versión 1.3.0-alpha03 contiene estas confirmaciones.

Cambios en la API

• Se agregó EditorSession#setOverrideComplications, que establece temporalmente el ComplicationData de la instancia de cara de reloj subyacente durante la edición. Si las complicaciones cambian con poca frecuencia, esto es más eficiente que pasar anulaciones a través de EditorSession#renderWatchFaceToBitmap. (I19384).

Correcciones de errores

• Anteriormente, selectComplicationDataForInstant llamaba a toApiComplicationData para cualquier cronograma, lo que significaba que la prueba de igualdad de referencia === posterior siempre fallaba. Esto significaba que las complicaciones volvían a cargarse en cada fotograma, lo que provocaba que la batería se agotara. (717406).

Versión 1.3.0-alpha02

3 de abril de 2024

Lanzamiento de androidx.wear.watchface:watchface-*:1.3.0-alpha02. La versión 1.3.0-alpha02 contiene estas confirmaciones.

Nuevas funciones

• Ahora usamos igualdad de referencia para comparar mejor y selectedData porque el operador igual es costoso. (446b00).

Cambios en la API

• Se agregó una API dinámica sin resguardo para GoalProgressComplicationData. (c33264).

Versión 1.3.0-alpha01

7 de febrero de 2024

Lanzamiento de androidx.wear.watchface:watchface-*:1.3.0-alpha01. La versión 1.3.0-alpha01 contiene estas confirmaciones.

Nuevas funciones

• WatchFaceServices se puede inicializar de forma simultánea y, por lo tanto, no debe tener estado. Para ello, agregamos StatefulWatchFaceService, en el que un elemento adicional definido por el usuario creado por createExtra() se pasa a todas las anulaciones a las que se llamó durante la inicialización.
• GlesRenderer2 ahora tiene una sobrecarga de constructor que te permite especificar una lista de atributos para probar a su vez con eglChooseConfig.

Cambios en la API

• StatefulWatchFaceService ahora admite una anulación de getComplicationSlotInflationFactory en la que se pasa el elemento adicional definido por el usuario creado por createExtra(). (I82d9f).
• Algunas caras de reloj deben compartir los datos auxiliares creados durante createUserStyleSchema con otros métodos de inicialización. Debido a que no existía una mejor alternativa, los desarrolladores solían hacer que su WatchFaceServices tuviera estado. Esto es peligroso porque se pueden crear varias instancias de forma simultánea, lo que puede generar errores. Para solucionar este problema, introdujimos StatefulWatchFaceService y StatefulWatchFaceRuntimeService, en los que createExtra() crea un tipo definido por el usuario y se pasa a los distintos métodos de creación como parámetro. (If8a99).
• Se agregó getUserStyleFlavors a InteractiveWatchFaceClient, que es de interés principalmente para los OEM. (I0f5d8).
• GlesRenderer2 ahora tiene una sobrecarga de constructor que te permite especificar una lista de atributos para probar a su vez con eglChooseConfig. Esto, por ejemplo, te permite probar primero una configuración con suavizado de contorno y recurrir a uno sin si es necesario. (I1ba74).
• A partir de Android U, se agregará compatibilidad con SystemDataSources.DATA_SOURCE_HEART_RATE a Wear OS. Solo se garantiza que esta complicación admita complicaciones de SHORT_TEXT, pero se recomienda que ComplicationSlot también acepte SMALL_IMAGE, ya que los OEM pueden optar por entregar un atajo a su app de salud en lugar del valor en tiempo real. (I34223).
• Agregamos METADATA_KEY_CONFIG_RESTORE_SUPPORTED, que, a partir de Android U, controla lo que sucede cuando se restablece el sistema a partir de una copia de seguridad de la fuente de datos de complicaciones con METADATA_KEY_DATA_SOURCE_CONFIG_ACTION. De forma predeterminada, el sistema supone que el servicio de fuente de datos de complicaciones admite la copia de seguridad de cualquier dato de configuración. Sin embargo, si no es así, puede agregar la configuración de metadatos de METADATA_KEY_DATA_SOURCE_CONFIG_ACTION como falsa, lo que marcará la ranura para complicaciones como no configurada. (I6c505).

Versión 1.2

Versión 1.2.1

24 de enero de 2024

Lanzamiento de androidx.wear.watchface:watchface-*:1.2.1. La versión 1.2.1 contiene estas confirmaciones.

Correcciones de errores

• Se solucionó un bloqueo en el Samsung Galaxy Watch 4, 5 y 6. (43f0b0).

Versión 1.2.0

29 de noviembre de 2023

Lanzamiento de androidx.wear.watchface:watchface-*:1.2.0. La versión 1.2.0 contiene estas confirmaciones.

Cambios importantes desde la versión 1.1.0

• Agregamos compatibilidad con algunos tipos de complicación nuevos que están disponibles para Android T:
  • GoalProgressComplicationData, que es similar a RangedValueComplicationData, excepto que es para el progreso hacia un objetivo en el que el mínimo implícito es cero y el valor puede ser mayor que targetValue.
  • WeightedElementsComplicationData, que consiste en un array de elementos (pares de peso y color), junto con texto, imagen y título opcionales. Estos se pueden mostrar como un gráfico circular en el que los colores deben ser significativos según el contexto, ya que, por lo general, no hay espacio en una complicación para procesar las etiquetas
• Se agregó compatibilidad con ColorRanges opcional para RangedValueComplicationData. Por lo general, las complicaciones se renderizan con los colores de la cara de reloj que elija el usuario, pero a veces, ComplicationDataSource se coloca mejor para establecer los colores; p. ej., cuando tienen un significado semántico particular. P. ej., de rojo a azul para la temperatura
• Casi todos los tipos de ComplicationData ahora admiten SmallImages.
• Se agregó ComplicationDisplayPolicy, en el que DO_NOT_SHOW_WHEN_DEVICE_LOCKED le indica a una cara de reloj compatible que no muestre la complicación cuando el dispositivo está bloqueado.
• A partir de Android T, los OEM podrán determinar si una solicitud de complicación proviene de una cara de reloj en la lista definida por los metadatos android.support.wearable.complications.SAFE_WATCH_FACES en el manifiesto de su proveedor mediante ComplicationRequest#isForSafeWatchFace. El proveedor necesitará el permiso com.google.wear.permission.GET_IS_FOR_SAFE_WATCH_FACE para recibir otro elemento que no sea TargetWatchFaceSafety.UNKNOWN`.
• UserStyleFlavors se convirtió en una función no experimental.

Versión 1.2.0-rc01

18 de octubre de 2023

Lanzamiento de androidx.wear.watchface:watchface-*:1.2.0-rc01. La versión 1.2.0-rc01 contiene estas confirmaciones.

Versión 1.2.0-beta02

6 de septiembre de 2023

Lanzamiento de androidx.wear.watchface:watchface-*:1.2.0-beta02. La versión 1.2.0-beta02 contiene estas confirmaciones.

Nuevas funciones

• SuspendingComplicationDataSourceService#onDestroy ya está abierto. Ten en cuenta que se quitó la compatibilidad con una complicación del clima predeterminada del sistema.

Cambios en la API

• Revertir la opción “Cómo exponer una nueva fuente de datos para complicaciones del clima”. (I6f335).

Versión 1.2.0-beta01

23 de agosto de 2023

Lanzamiento de androidx.wear.watchface:watchface-*:1.2.0-beta01. La versión 1.2.0-beta01 contiene estas confirmaciones.

Nuevas funciones

• A partir de Android T, WearOS ahora admitirá una complicación de sistema meteorológico predeterminada.

Cambios en la API

• Se agregó el resguardo del sistema predeterminado del clima para las complicaciones. (Ia0994).
• Este parche agrega WatchFaceRuntimeService y WatchFaceControlClient.createWatchFaceRuntimeControlClient junto con wrappers de Guava. Agregan compatibilidad con tiempos de ejecución de caras de reloj, que son un tipo especial de cara de reloj que carga su definición desde otro paquete. Actualmente, WearOS solo admite el tiempo de ejecución para el Formato de Caras de Relojes de Android. (I2799f).
• Este parche es un seguimiento de aosp/2636578, en el que cambiamos el nombre de int defs para que no sea necesario cambiar cualquier código que dependa de WatchFaceType, CanvasType, TapType o ComplicationsSlotBoundsType. (I4098b).
• Se actualizaron los archivos de la API para anotar la supresión de compatibilidad. (I8e87a, b/287516207).
• Este parche expone las constantes WatchFaceType en WatchFaceTypes, las constantes CanvasType en CanvasTypes, las constantes TapType en las constantes TapTypes y ComplicationsSlotBoundsType en ComplicationsSlotBoundsType. (I3b85a, b/288750666).
• WatchFace.OverlayStyle se usa muy poco y no es compatible con los OEM, por lo que lo daremos de baja con la intención de quitarlo más adelante. (I7344a).

Versión 1.2.0-alpha09

21 de junio de 2023

Lanzamiento de androidx.wear.watchface:watchface-*:1.2.0-alpha09. La versión 1.2.0-alpha09 contiene estas confirmaciones.

Nuevas funciones

• RangedValueComplicationData.Builder ahora acepta DynamicFloat, y hay un nuevo DynamicComplicationText disponible como subclase de ComplicationText, que puede usar expresiones dinámicas y vinculaciones de plataformas que se actualizan a 1 Hz en dispositivos Wear 4 compatibles.

Cambios en la API

• Se agregaron tipos dinámicos para distancia diaria, calorías diarias y pisos diarios. Las claves para las fuentes de estado de la plataforma ahora están en PlatformHealthSources.Keys (Ib7637).
• Implementa PlatformDataProvider para proporcionar la frecuencia cardíaca y los pasos diarios. Se quitó la interfaz SensorGateway de la API pública. (I55b84).
• Cambia el nombre de StateEntryValue a DynamicDataValue y actualiza las APIs de estado para usar DynamicDataKey. (If1c01).
• Agrega AppDataKey para acceder al estado enviado de la app. Agrega PlatformDataKey para acceder a los datos de la plataforma. Agrega compatibilidad con espacios de nombres en StateStore. (I7985e).
• Se quitaron enable/disablePlatformSource métodos de DynamicTypeEvaluator. El llamador debe ser responsable de las actualizaciones. (I78c6d).
• Permite la limitación del tamaño de los tipos de datos vinculados. (Ie2966).

Versión 1.2.0-alpha08

19 de abril de 2023

Lanzamiento de androidx.wear.watchface:watchface-*:1.2.0-alpha08. La versión 1.2.0-alpha08 contiene estas confirmaciones.

Nuevas funciones

• Desde Android T, los proveedores de complicaciones con el com.google.wear.permission.GET_IS_FOR_SAFE_WATCH_FACE privilegiado pueden registrar metadatos androidx.wear.watchface.complications.datasource.SAFE_WATCH_FACE_SUPPORTED_TYPES que anulan android.support.wearable.complications.SUPPORTED_TYPES para caras de reloj seguras. Esto significa que un proveedor de complicaciones puede optar por publicar diferentes tipos de caras de reloj confiables y no confiables.

Cambios en la API

• Propagación de la clase @Deprecated a la propiedad (I882d1, b/271441831)
• Cambió el nombre del parámetro de valor para Enum.valueOf. (Ia9b89)
• Se agregaron más excepciones arrojadas desde enum valueOf. (I818fe)
• Se quitó renderWatchFaceToSurface y se reemplazó por createRemoteWatchFaceView, que se basa en SurfaceControlViewHost y permite que el llamador incorpore una vista de la cara de reloj, que se renderiza cuando el cliente llama a RemoteWatchFaceViewHost#renderWatchFace. (Ib311d).
• Se agregó renderWatchFaceToSurface a InteractiveWatchFaceClient, HeadlessWatchFaceClient y EditorSession. Por lo general, tendrá un mejor rendimiento que renderizarlo en un mapa de bits. (Ieacad).
• El nombre de ObservableStateStore se cambió por StateStore. (Ieb0e2).
• Se agregó DynamicTypeEvaluator.Builder en lugar de argumentos del constructor para permitir más argumentos opcionales, incluido ObservableStateStore, que ahora muestra un almacén vacío de forma predeterminada. (I6f832).
• Se refactorizó el orden de los parámetros en DynamicTypeEvaluator. (Ic1ba4).
• Se agregó el ejecutor a los métodos DynamicTypeEvaluator.bind. (I346ab).
• Agregamos el método startEvaluation a BoundDynamicType para activar la evaluación después de que se vincule el tipo dinámico. (I19908).
• Los proveedores de complicaciones con el com.google.wear.permission.GET_IS_FOR_SAFE_WATCH_FACE con privilegios pueden registrar metadatos de androidx.wear.watchface.complications.datasource.SAFE_WATCH_FACE_SUPPORTED_TYPES que anulan android.support.wearable.complications.SUPPORTED_TYPES para las caras de reloj seguras. (Id1c73).
• Se cambió el nombre de CustomValueUserStyleSettings2 a LargeCustomValueUserStyleSettings. (Ic17ac).

Correcciones de errores

• Se quitó DynamicTypeValueReceiver#onPreUpdate. (I2dc35).

Versión 1.2.0-alpha07

22 de febrero de 2023

Lanzamiento de androidx.wear.watchface:watchface-*:1.2.0-alpha07. La versión 1.2.0-alpha07 contiene estas confirmaciones.

Nuevas funciones

• A partir de Android T, los OEM podrán determinar si una solicitud de complicación proviene de una cara de reloj en la lista definida por los metadatos android.support.wearable.complications.SAFE_WATCH_FACES en el manifiesto de su proveedor mediante ComplicationRequest#isForSafeWatchFace. El proveedor necesitará el permiso com.google.wear.permission.GET_IS_FOR_SAFE_WATCH_FACE para recibir cualquier otro elemento que no sea TargetWatchFaceSafety.UNKNOWN.

• También está disponible desde Android T CustomValueUserStyleSetting2, que puede almacenar hasta 12.5 KB. El límite anterior de CustomValueUserStyleSetting era de 1 KB. A pesar del aumento en el límite de tamaño, se recomienda que los desarrolladores de caras de reloj no se excedan en el uso de datos, ya que la configuración se envía mediante Bluetooth durante la edición y el ancho de banda de Bluetooth es limitado.

Cambios en la API

• Agregamos un parámetro opcional eglContextAttribList a GlesRenderer y GlesRenderer2, que te permite establecer la EGL14.EGL_CONTEXT_CLIENT_VERSION que se pasa a EGL14.eglCreateContext (I2a83e).
• Migramos las bibliotecas de caras de reloj a androidx.core.util.Consumer en lugar de java.util.function.Consumer (I273f5).
• Se agregaron más excepciones arrojadas por descriptores de acceso de propiedades de KT (Iff9d9).
• Agregamos InteractiveWatchFaceClient.isComplicationDisplayPolicySupported para que el cliente pueda determinar si debe emular la compatibilidad o no en nombre de las caras de reloj anteriores (I24c89).
• Decidimos que isForSafeWatchFace debe ser un IntDef de tres estados (Ief2f7).
• Para Android T, presentamos ComplicationRequest.isForSafeWatchFace, que está destinado al uso de OEM y requiere com.google.wear.permission.GET_IS_FOR_SAFE_WATCH_FACE. Para las fuentes de datos de la imagen del sistema, se mostrará un valor verdadero si la cara de reloj que lo solicita se encuentra dentro de la lista de caras seguras que especifica la fuente de datos en su manifiesto (I0cbb6).
• Para Android T, agregamos CustomValueUserStyleSetting2, que puede almacenar hasta 12.5 KB. El límite anterior de CustomValueUserStyleSetting era de 1 KB (I0b100).

Versión 1.2.0-alpha06

25 de enero de 2023

Se lanzó androidx.wear.watchface:watchface-*:1.2.0-alpha06. La versión 1.2.0-alpha06 contiene estas confirmaciones.

Nuevas funciones

• Se está trabajando para agregar compatibilidad con la vinculación de plataformas de complicaciones. Esto aún no está listo para que lo uses, pero lo estará pronto.
• Se agregó compatibilidad con XML ComplicationSlot para los nuevos tipos de complicación, GOAL_PROGRESS y WEIGHTED_ELEMENTS.

Correcciones de errores

• Se corrigió una fuga en la que el editor de caras de reloj no se lanzaba correctamente en dispositivos Samsung (3b5987).
• Se corrigió un error por el que, a veces, las complicaciones no se mostraban correctamente cuando se cambiaba de cara de reloj con varios favoritos (b38ece).
• Se corrigió un error de serialización con perOptionScreenReaderNames que provocaba fallas en la cara de reloj (e9f466).

Versión 1.2.0-alpha05

7 de diciembre de 2022

Lanzamiento de androidx.wear.watchface:watchface-*:1.2.0-alpha05. La versión 1.2.0-alpha05 contiene estas confirmaciones.

Nuevas funciones

• Hace un tiempo, agregamos compatibilidad con la jerarquía UserStyleSettings y, desde Android T, ahora es posible tener más de una ComplicationSlotsUserStyleSetting en una jerarquía. Solo se activará una ComplicationSlotsUserStyleSetting, según las selecciones de estilo del usuario.

• Agregamos un campo screenReaderName para mejorar la compatibilidad con el lector de pantalla para ListOption y ComplicationSlotsOption. Ten en cuenta que, en las versiones anteriores a Android T, los editores complementarios ignorarán este campo.

Cambios en la API

• Agregamos un nuevo campo opcional screenReaderName a ListOption y ComplicationSlotsOption para que lo usen los editores. Los editores complementarios lo ignorarán en dispositivos con versiones anteriores a Android T (I75326).
• A partir de Android T, se admitirán varias ComplicationSlotsUserStyleSettings en una jerarquía de estilo, siempre y cuando no esté activa más de una de ellas a la vez. Se agregó una función de utilidad findComplicationSlotsOptionForUserStyle a UserStyleSchema para ayudar a encontrar la ComplicationSlotsOption activa, si corresponde (Ic2b06).
• Se incluyeron RangedValuesTypes en el objeto complementario de RangedValueComplicationData y se les cambió el nombre a TYPE_UNDEFINED, TYPE_RATING; y también se agregó un nuevo TYPE_PERCENTAGE (I55d02).
• Cambiamos el nombre de DynamicFloat experimental a FloatExpression y lo marcamos como @hide (Idf4f1).
• Se agregó la anotación @JvmDefaultWithCompatibility (I8f206).

Versión 1.2.0-alpha04

9 de noviembre de 2022

Lanzamiento de androidx.wear.watchface:watchface-*:1.2.0-alpha04. La versión 1.2.0-alpha04 contiene estas confirmaciones.

Nuevas funciones

• Para Android T, agregamos compatibilidad con dos nuevos tipos de complicación: GoalProgressComplicationData y WeightedElementsComplicationData.
• GoalProgressComplicationData es similar a RangedValueComplicationData, pero su valor puede superar el objetivo (en el caso de RangedValueComplicationData, el valor se restringe al rango [mín.-máx.]), lo que tiene implicaciones en el diseño visual que podrían no adaptarse a todos los fondos de pantalla.
• GoalProgressComplicationData agrega compatibilidad con gráficos circulares y desgloses similares de datos simples.
• Agregamos asistencia opcional para ColorRamps en RangedValueComplicationData.
• En el caso de Android T, agregamos ComplicationPersistencePolicy y setCachePolicy a ComplicationData, que actualmente permite que un proveedor controle si una complicación persiste o no (es decir, si se almacenó en caché después del reinicio). La mayoría de las complicaciones no necesitan establecer el control de caché, pero al hacerlo se pueden corregir casos límite con datos inactivos para algunas complicaciones que se actualizan con frecuencia (p. ej., complicaciones de datos de salud). También agregamos ComplicationDisplayPolicy, en la que DO_NOT_SHOW_WHEN_DEVICE_LOCKED indica a una cara de reloj compatible que no muestre la complicación cuando el dispositivo está bloqueado (Ic9574).

Cambios en la API

• GoalProgressComplicationData, WeightedElementsComplicationData y ColorRamp dejaron de ser experimentales (Ica9e2).
• ComplicationPersistencePolicy y ComplicationDisplayPolicy ahora están marcados correctamente como APIs de T (I31d88).
• El constructor obsoleto ComplicationSlotOverlay ahora tiene DeprecationLevel.WARNING, lo que permite que se vuelva a llamar desde Java (Ib308c).
• Se corrigieron algunos problemas de compatibilidad de Java con ComplicationRequestListener, CanvasComplication, ComplicationTapFilter y InteractiveWatchFaceClient agregándoles la anotación @JvmDefaultWithCompatibility (Id94fc).
• Se quitaron los elementos experimentales ProtoLayoutComplicationData y ListComplicationData. La justificación de los desarrolladores para estos no fue clara. Esperamos volver a revisarla en el futuro (I9df05).
• Se agregó un ValueType a RangedValueComplicationData. WeightedElementsComplicationData ahora admite un color de fondo. Se quitó DiscreteRangedValueComplicationData porque su funcionalidad es un subconjunto de WeightedElementsComplicationData (I6446c).

Correcciones de errores

• Incluye isForScreenShot en el código de equals y hash. Asegúrate de que onRenderParametersChanged obtenga un valor de isForScreenshot correcto (I04a41).
• Se corrigieron las filtraciones de WatchFaceControlService de clientes sin interfaz gráfica (e90e00).

Versión 1.2.0-alpha03

5 de octubre de 2022

Lanzamiento de androidx.wear.watchface:watchface-*:1.2.0-alpha03. La versión 1.2.0-alpha03 contiene estas confirmaciones.

Nuevas funciones

• No hay funciones nuevas, pero corregimos algunos errores del editor de caras de reloj.

Cambios en la API

• UserStyleSchema.userStyleSettings dejó de estar disponible, ya que rootUserStyleSettings se vuelve no experimental (Ie96e3).
• rootUserStyleSettings dejó de ser experimental (I8d6b3).
• Se marcó WatchFaceColors como experimental porque no es compatible con todos los sistemas (I6d75d).
• Se expuso DisconnectReasons en la API pública para que funcione con IntDef (I791f8).

Correcciones de errores

• Se cierra cualquier editor abierto en el reloj si SysUI deja de funcionar. Si SysUI deja de funcionar y el editor de caras de reloj no se cierra, la cara de reloj podría quedar en un estado inconsistente porque el sistema se basa en SysUI para conservar cualquier cambio de estilo del usuario (ba762a).
• Se corrigió una fuga de memoria en ComplicationDataSourceInfoRetriever, en la que una continuación de corrutina de Kotlin funcionaba como raíz de recolección de elementos no usados (GC) y retenía la actividad del editor (33ee06).

Versión 1.2.0-alpha02

21 de septiembre de 2022

Lanzamiento de androidx.wear.watchface:watchface-*:1.2.0-alpha02. La versión 1.2.0-alpha02 contiene estas confirmaciones.

Nuevas funciones

• Algunas caras de reloj tienen una configuración fuera de UserStyle que las afecta visualmente (por ejemplo, al seleccionar una foto de fondo). Agregamos Renderer.sendPreviewImageNeedsUpdateRequest, que permite que la cara de reloj solicite una imagen de vista previa actualizada. Ten en cuenta que esto requiere una actualización del sistema correspondiente para funcionar.

• También agregamos una API para que las caras de reloj expongan sus colores al sistema, que puede elegir su paleta de colores en función de esto. Ten en cuenta que esto se hizo experimental en un parche de seguimiento.

• Casi todos los tipos de ComplicationData ahora admiten SmallImages.

Cambios de APIs

• El administrador de fondos de pantalla a veces puede desconectarse de un motor y hacer otro. Agregamos un DisconnectReason int def y extendimos ClientDisconnectListener con un método nuevo que incluye un DisconnectReason, lo que permite que el objeto de escucha detecte desconexiones del motor (I45cce).
• Se agregaron dos parámetros opcionales nameResourceId y screenReaderResourceId al constructor ComplicationSlotOverlay (I157e8).
• Agregamos un wrapper de guava para la nueva sobrecarga de getOrCreateInteractiveWatchFaceClient con un PreviewImageUpdateRequestedListener (Ic31f0).
• Agregamos Renderer.sendPreviewImageNeedsUpdateRequest, que es útil para las caras de reloj que tienen un estado fuera de UserStyleSchema que afecta su apariencia (por ejemplo, una cara de reloj con una imagen de fondo seleccionable). En el cliente, agregamos PreviewImageUpdateRequestedListener como parámetro opcional para getOrCreateInteractiveWatchFaceClient a fin de observar estas solicitudes (Iff44a).
• Simplificamos la API para exponer WatchFaceColors. Ahora hay una propiedad simple llamada watchFaceColors en el Procesador que la cara de reloj puede configurar. Esta debería actualizarse según sea necesario en respuesta a cualquier cambio de estilo. En lugar de usar WallpaperManager para observar los cambios de color, agregamos OnWatchFaceColorsListener a InteractiveWatchFaceClient (I490bc).
• Agregamos una clase WatchFaceColors que contiene los tres colores más destacados de la cara de reloj y agregamos los métodos abiertos watchfaceColors y notifyWatchFaceColorsChanged al procesador, que permiten que el sistema obtenga los colores de la cara de reloj mediante WallpaperManager.getWallpaperColors (I3d611).
• ShortTextComplicationData, RangedValueComplicationData, NoPermissionComplicationData (y los DiscreteRangedValueComplicationData, GoalProgressComplicationData y WeightedElementsComplicationData experimentales) ahora son compatibles con SmallImages. Si una cara de reloj elige renderizar una complicación con varios colores, ahora tiene la opción de usar un SmallImage multicolor, donde antes tenía que usar una imagen monocromática (I257df).
• En su lugar, se refactoriza PreviewImageUpdateRequestedListener para que sea una Consumer<>. (Ia875d)
• Reemplaza el Método único abstracto (SAM) personalizado OnWatchfaceColorsListener por el tipo genérico de SAM de Java (Consumidor) (I0c489).
• Dimos de baja los viejos métodos getOrCreateInteractiveWatchFaceClient y listenableGetOrCreateInteractiveWatchFaceClient que no especifican un PreviewImageUpdateRequestedListener (Iec502).

Correcciones de errores

• Se cambió el nombre de DisconnectReason.BINDER_DIED por DisconnectReason.ENGINE_DIED (I4eb0e).

Versión 1.2.0-alpha01

10 de agosto de 2022

Lanzamiento de androidx.wear.watchface:watchface-*:1.2.0-alpha01. La versión 1.2.0-alpha01 contiene estas confirmaciones.

Nuevas funciones

• Agregamos compatibilidad experimental con diversos formatos de complicación nuevos. Esta es un área de desarrollo activo; estos formatos nuevos están sujetos a cambios sin previo aviso y, por el momento, no se admite el procesador de CanvasComplicationDrawable.
• También agregamos márgenes opcionales a las ranuras de complicaciones que facilitan el acceso a complicaciones pequeñas.

Cambios en la API

• La clase experimental BoundingArc ahora es inmutable (If624a).
• Las complicaciones pequeñas pueden ser difíciles de presionar. A fin de mitigar este problema, agregamos compatibilidad con los márgenes que aumentan el área táctil sin afectar el procesamiento. A menos que se especifique (ya sea en código o a través de XML), los ComplciationSlots tienen márgenes de tamaño cero (I14089).
• Se cambió la firma getComplicationSlotInflationFactory(CurrentUserStyleRepository) para mostrar una instancia de fábrica no nula. Antes, era un error mostrar un valor nulo, por lo que esto solo hace que el contrato de la API sea más claro (I0fcc0).
• Se agregó un argumento currentUserStyleRepository al método WatchFaceService.getComplicationSlotInflationFactory para que sea coherente con createComplicationSlotsManager (I2ddd2).
• Los elementos UserStyleFlavors se convirtieron en una función no experimental (I69cdc).
• Quitamos el elemento ValueType experimental de RangedValueComplicationData y, en su lugar, presentamos el elemento DiscreteRangedValueComplicationData experimental, que es similar a RangedValueComplicationData, excepto por el rango de números enteros y valor. También introdujimos el GoalProgressComplicationData experimental, que es similar a RangedValueComplicationData, excepto porque es para el progreso hacia un objetivo en el que el valor mínimo implícito es cero y puede ser mayor que targetValue. Ten en cuenta que, para todas las variantes de RangedValue, debe especificarse, al menos, una de las siguientes opciones: monochromeImage, text o title (I9590c).
• Se quitó boundsWithMargins de ComplicationSlotState porque el software del sistema no tiene un caso de uso (I42e26).
• Se agregó compatibilidad experimental para WeightedElementsComplicationData, que consiste en un arreglo de elementos (pares de peso y color) junto con texto, imágenes y títulos opcionales. Estos se pueden mostrar como un gráfico circular en el que los colores deben ser significativos según el contexto, ya que, por lo general, no hay espacio en una complicación para procesar las etiquetas (I87eea).
• El ColorRamps experimental que usan RangedValueComplicationData y GoalProgressComplicationData (opcional) ahora te permite especificar una secuencia de hasta siete colores y una marca que indica si los colores se deben interpolar sin problemas o si se deben realizar pasos de color sólido del mismo tamaño (I9f5bf).
• Se cambió RangedValueComplicationData.drawSegmented a valueType, que es un número entero con un ValueType IntDef correspondiente que proporciona un significado semántico al valor de intervalo y que el procesador de complicaciones puede usar para influir en el estilo (I0616b).
• Se agregó compatibilidad experimental con los ColorRanges opcionales para RangedValueComplicationData. Por lo general, las complicaciones se renderizan con los colores de la cara de reloj que elija el usuario, pero a veces, ComplicationDataSource se coloca mejor para establecer los colores; p. ej., cuando tienen un significado semántico particular. P. ej., de rojo a azul para la temperatura (I5153a).
• Agregamos una sugerencia experimental de drawSegmented a RangedValueComplicationData. Esto indica a los procesadores que dibujen el indicador de valor de intervalo con segmentos, en el que 1 segmento = 1 unidad (I7d7c1).

Correcciones de errores

• Se agregó la capacidad de definir ComplicationSlotBounds en relación con un sistema de coordenadas de pantalla predefinido (I0985d).

Versión 1.1

Versión 1.1.1

10 de agosto de 2022

Lanzamiento de androidx.wear.watchface:watchface-*:1.1.1. La versión 1.1.1 contiene estas confirmaciones.

• Esta es una versión con correcciones de errores, y se recomienda que los usuarios de la versión 1.1.0 realicen la actualización.

Correcciones de errores

• La inicialización de la cara de reloj es asíncrona. Si se recibe una complicación antes de que esta esté lista, se agregará a la lista pendingInitialComplications y se aplicará más tarde. Lamentablemente, pendingInitialComplications se aplicó demasiado pronto, lo que significa que hubo un período durante la inicialización de la cara de reloj en el que las complicaciones aún se colocaban en pendingInitialComplications y se ignoraban. Ya se solucionó este problema. Además, este parche corrige un error por el que ComplicationRenderer intentaba cargar marcadores de posición de forma asíncrona, lo que provocaba que el gráfico de compilación nunca se actualizara. Por último, este parche corrige un error teórico por el que se debían combinar varios pendingInitialComplications (0d03ba3).

• Corregimos el interbloqueo potencial en InteractiveInstanceManager, por el que getExistingInstanceOrSetPendingWallpaperInteractiveWatchFaceInstance retenía el bloqueo más tiempo del necesario. Por lo general, se espera que engine.setUserStyle sea rápido, pero si por alguna razón no es así, se genera un interbloqueo o un error de ANR. Este parche quita el trabajo innecesario del bloqueo y quita la posibilidad de un interbloqueo (5a2adca).

• Se corrigieron varios problemas que retenían WatchFaceService. A veces, WakeLock puede retener el WatchFaceService. Para solucionar ese problema, puedes agregar una llamada release(). Además, StateFlows puede retener WatchFaceService y cancelar las correcciones subyacentes de CoroutineScopes (fd48138).

• Agrega tiempos de espera a awaitDeferredWatchFace* y corrige watchfaceOverlayStyle NullPointerException. En circunstancias normales, esto no debería agotar el tiempo de espera, incluso después de una instalación nueva y de situaciones DirectBoot en las que la carga de la CPU es alta. También se corrigió una NPE si se llamaba a getWatchfaceOverlayStyle después de close() (a4c3a5a).

Versión 1.1.0

15 de junio de 2022

Lanzamiento deandroidx.wear.watchface:watchface-*:1.1.0. La versión 1.1.0 contiene estas confirmaciones.

Cambios importantes desde 1.0.0

Edición mejorada:

• Agregamos compatibilidad con esquemas jerárquicos, que permiten que las IU de editores escriban una jerarquía de estilos. Ahora puedes especificar íconos separados para usar en la cara de reloj y los editores complementarios.
• Hay compatibilidad opcional con varias instancias de una cara de reloj, cada instancia tiene un ID único disponible en todas las plataformas de API.
• Ahora puedes especificar nombres legibles para ComplicationSlots a fin de usarlos en editores.
• Compatibilidad experimental con "variantes" de estilos, una selección de estilos que aparecerán en el editor complementario.
• Cuando se cargan dos instancias de la cara de reloj, será posible que las instancias compartan recursos y ahorren memoria.
• Cuando se selecciona una complicación en el editor de caras de reloj, ahora se preselecciona el proveedor actual.

Complicaciones mejoradas:

• Ahora puedes especificar el ComplicationType para las fuentes de datos principales y secundarias, lo que les brinda a los desarrolladores más flexibilidad para la experiencia lista para usar.
• Agregamos ComplicationDataTimeline, que proporciona una secuencia de datos con restricciones de tiempo para que se entreguen a la cara del reloj y se puedan almacenar en caché y actualizar automáticamente. Por ejemplo, el pronóstico del tiempo del día en distintos horarios o varios eventos futuros del calendario.
• El ComponentName del proveedor de complicaciones es parte de ComplicationData.
• Las complicaciones ahora se almacenan en caché, lo que brinda una mejor experiencia cuando se alterna entre caras de reloj.

Otros cambios:

• UserStyleSchema y ComplicationSlots ahora se pueden definir en XML. Esto simplifica la construcción de la cara de reloj y permite consultas más rápidas de metadatos desde el sistema.
• Las caras de reloj ahora pueden influir en los colores que se usan para renderizar la superposición del sistema.

Versión 1.1.0-rc01

18 de mayo de 2022

Se lanzó androidx.wear.watchface:watchface-*:1.1.0-rc01. La versión 1.1.0-rc01 contiene estas confirmaciones.

Nuevas funciones

• Se realizaron algunos ajustes de usabilidad a la compatibilidad con XML de caras de reloj para que sea más fácil especificar ComplicationSlotBounds y referencias compatibles. La experimentación con la complicación perimetral BoundingArc continúa y se la proporciona mediante drawHighlight, aunque no se recomienda usarla en ese momento.

Cambios en la API

• Se agregó una sobrecarga experimental de drawHighlight que acepta un parámetro BoundingArc (I705f8).
• El XML de la cara de reloj ahora admite referencias de recursos. Te permite usar las mismas constantes en XML y en tu código (I3ef61).
• Se agregó la capacidad de definir ComplicationSlotBounds en center_x, center_y, size_x y size_y. Ahora también es posible usar diferentes unidades (es decir, dp) con referencias de recursos (Iace98).

Correcciones de errores

• Se corrigió runBlockingWithTracing, que ejecutaba tareas en el contexto incorrecto (4f595fe).
• Ahora, BaseEditorSession.close es síncrono. El problema con que BaseEditorSession.close sea asíncrono es que ComplicationDataSourceInfoRetriever se libera demasiado tarde, lo que provoca una advertencia de spam en logcat. Probablemente sea inofensivo, pero el spam de logcat puede distraer a los usuarios y se debe evitar (35a5308).

Versión 1.1.0-beta02

11 de mayo de 2022

Se lanzó androidx.wear.watchface:watchface-*:1.1.0-beta02. La versión 1.1.0-beta02 contiene estas confirmaciones.

Nuevas funciones

• Se agregó compatibilidad experimental con los nuevos tipos de ComplicationData. Estos todavía no están listos para usarse, pero pronto habrá más novedades.

Cambios en la API

• Se agregó BoundingArc, una clase experimental que describe la geometría de una ranura de espacio para complicación. Se agregó a ComplicationSlot y se conectó a ComplicationSlotState y WatchFaceMetadataClient (I61a40).
• Se agregó la capacidad de heredar parámetros de configuración en el archivo XML UserStyleSetting. Te permite reducir la verbosidad y compartir un parámetro entre caras de reloj (Ief841).
• Se agregaron dos tipos experimentales nuevos de ComplicationData: ListComplicationData y ProtoLayoutComplicationData. Actualmente, no se admite esta función en ninguno de estos tipos. Por el momento, Wear OS no los reconoce si se agregan a un manifiesto ComplicationDataSource's (I1811c).

Correcciones de errores

• Se corrigió la serialización del tipo TimeLineEntry. No serializamos el tipo TimeLineEntry, lo que significa que el elemento TimeLineEntries de la caché almacenado del tipo NoData se interpretaría de forma incorrecta como si el tipo de complicación superior generara NPE cuando se accediera a campos obligatorios inexistentes (55ffdf5).
• Se corrigió un error por el que setComplicationData descartaba campos de cronograma (fb392f5).
• Se corrigió un error por el que, con frecuencia, runBlockingWithTracing provocaba un elemento NPE (12ca62e).
• Se corrigió un error por el que a veces se obtenía ClassNotFoundException: android.support.wearable.complications.ComplicationText cuando se recibía una complicación (217942d9).
• Se corrigió un error en GlesRenderer.backgroundThreadInitInternal que solo llamaba a onBackgroundThreadGlContextCreated si se llamaba a EGL14.eglCreateContext. Se solucionó otro error en el que se producía una falla visual en la captura de pantalla provocada por verticalFlip (c674ad2).
• Se corrigió la comprobación de la versión XML de WatchFaceService; se estaba cargando desde el paquete incorrecto (dfa06f3).
• El formato de cable del marcador de posición ahora usa un paquete interno. No queremos que los marcadores de posición rompan las caras de reloj existentes que puedan utilizar el a.s.w.c.ComplicationData interno oculto. Antes, el formato de conexión de los datos de NoDataComplication almacenaba el marcador de posición en los campos habituales (lo que era un problema, porque las caras de reloj anteriores renderizaban la string de marcador de posición que no era lo previsto). En su lugar, ahora usamos un paquete interno para aislar por completo esto (d5e7bd2).

Versión 1.1.0-beta01

20 de abril de 2022

Se lanzó androidx.wear.watchface:watchface-*:1.1.0-beta01. La versión 1.1.0-beta01 contiene estas confirmaciones.

Cambios en la API

• Ahora los métodos WatchFaceMetadataClient (getUserStyleSchema, getComplicationSlotMetadataMap, getUserStyleFlavors) y HeadlessWatchFaceClient.getUserStyleFlavors arrojan una excepción RuntimeException sin verificar en lugar de WatchFaceException. (I0718a)
• WatchFaceMetadataClient.WatchFaceException se quitó de la clase para permitir que se vuelva a usar. (I4e869)

Correcciones de errores

• WatchFaceMetadataClient ya no fallará cuando se envíe una versión parcial de ComplicationSlotBounds.(Iaafd)

Versión 1.1.0-alpha05

6 de abril de 2022

Se lanzó androidx.wear.watchface:watchface-*:1.1.0-alpha05. La versión 1.1.0-alpha05 contiene estas confirmaciones.

Nuevas funciones

• Ahora puedes saber qué fuente de datos envió un ComplicationData si inspeccionas ComplicationData.dataSource. Algunas caras de reloj pueden usar esto para personalizar la visualización de complicaciones. (I44a73)

Cambios en la API

• Renderer.CanvasRenderer y Renderer.GlesRenderer dejaron de estar disponibles y se los reemplazó por Renderer.CanvasRenderer2 y Renderer.GlesRenderer2, que admiten SharedAssets y se pasan a los métodos de renderización. Para la interoperabilidad de Java, presentamos ListenableCanvasRenderer2 y ListenableGlesRenderer2. (I31ffa)
• Se agregó la capacidad @WatchFaceFlavorsExperimental para definir variantes: lista preconfigurada de caras de reloj con estilo. (I04dd0)
• Renderer.sharedAssets ahora es un StateFlow y quitamos el Renderer.SharedAssetsFactory que no se usa. (I12ac5)
• UserStyleSchema.userStyleSettings ya no es obsoleto. (Iba7e3)
• Agregamos HeadlessWatchFaceClient.getUserStyleSchemaDigestHash, que permite que un HeadlessWatchFaceClient evite la sobrecarga relativamente baja de pasar el esquema por AIDL antes de calcular el hash de resumen. (I33597)
• Se agregó isUserStyleSchemaStatic a WatchFaceMetadataClient, que es verdadero si solo se puede confiar en que no se modificará el UserStyleSchema, a menos que se actualice el APK de la cara de reloj. (I45a3f)
• Agregamos getDigestHash a UserStyleSchema, que calcula un hash de resumen del esquema. Se puede usar para determinar de manera eficiente si cambió el UserStyleSchema. (I2063d)
• Se cambió el nombre de METADATA_KEY_DATA_SOURCE_DEFAULT_CONFIGURATION_SUPPORTED por METADATA_KEY_DATA_SOURCE_DEFAULT_CONFIG_SUPPORTED. (I9ba5d)
• Se cambió el nombre de UserStyleSetting.OnWatchEditorData por UserStyleSetting.WatchFaceEditorData, que contiene datos que solo usa el editor de caras de reloj. (If3afb)

Versión 1.1.0-alpha04

9 de marzo de 2022

Lanzamiento de androidx.wear.watchface:watchface-*:1.1.0-alpha04. La versión 1.1.0-alpha04 contiene estas confirmaciones.

Cambios en la API

• Es posible que ComplicationData actualizado no siempre esté disponible (p. ej., ComplicationData vencido almacenado en caché), por lo que extendimos NoDataComplication con ComplicationData de marcador de posición opcional y agregamos ComplicationText.PLACEHOLDER, MonochromaticImage.PLACEHOLDER, SmallImage.PLACEHOLDER y PhotoImage.PLACEHOLDER, que solo se pueden usar dentro del contexto de un marcador de posición NoDataComplicationData. Si seleccionas esta opción, se sugiere que estos marcadores de posición se rendericen con cuadros o arcos grises (I6285d).
• Agregamos ComplicationData.getNextChangeInstant, que te indica el próximo Instant después de Instant de referencia en el que puede cambiar cualquier campo de la complicación. Se usa de forma interna a fin de programar fotogramas para actualizaciones de complicaciones. Por ejemplo, si una cara de reloj se actualiza, por lo general, una vez por minuto, configurar la complicación de cronómetro causará que se actualice una vez por segundo (I7ceb2).
• Ahora se puede usar EditorSession.watchFaceId en todos los niveles de API. Además, su valor ahora siempre será coherente con WatchState.watchFaceInstanceId (I323b9).
• La API de getPendingIntentForTouchEvent ya no es necesaria, ya que el problema subyacente se corrigió en el framework, por lo que se quitaron todas las API relacionadas. Las caras de reloj no necesitan realizar ninguna acción especial para que se active PendingIntents, incluso si se acaba de presionar el botón de inicio (I1f2e8).
• Se agregó RendererParameters.isForScreenShot, que será verdadero si la renderización es para una captura de pantalla. Algunas caras de reloj con animaciones deben saber esto para realizar ajustes a fin de garantizar los mejores resultados (I96d99).
• Se agregó WatchFaceExceptionReason a WatchFaceException para proporcionar contexto sobre el problema (I01d15).
• Se quitó ComplicationDataSourceService.onImmediateComplicationRequest; en su lugar, se agregó ComplicationRequest.immediateResponseRequired para indicar que el proveedor debe responder con rapidez (lo ideal sería responder en menos de 100 ms). Ten en cuenta que esta funcionalidad está protegida con el permiso com.google.android.wearable.permission.USE_IMMEDIATE_COMPLICATION_UPDATE privilegiado (Ie6b23).
• Se actualizó la nulabilidad en core y appcompat para que coincida con Tiramisu DP2 (I0cbb7).

Correcciones de errores

• Ahora la app de la cara de reloj falla con una excepción si se produce un error en la validación del esquema (Ia400f).

Versión 1.1.0-alpha03

9 de febrero de 2022

Lanzamiento de androidx.wear.watchface:watchface-*:1.1.0-alpha03. La versión 1.1.0-alpha03 contiene estas confirmaciones.

Cambios en la API

• Se agregó la compatibilidad experimental con los esquemas de estilo jerárquico. Agregamos una nueva propiedad a androidx.wear.watchface.style.UserStyleSetting.Option, childSettings que inicialmente solo usa ListOption. De esta manera, se puede describir una jerarquía de estilos para que los usen las IU de Editor. El objeto UserStyle subyacente no se modifica y sigue siendo Map<String, ByteArray> (Iaf6f4).
• Se agregó WatchFace.OverlayStyle, que permite que la cara de reloj configure la renderización de la superposición de estado del sistema (I8520d).
• Presentamos clearWithBackgroundTintBeforeRenderingHighlightLayer un nuevo parámetro de constructor opcional para CanvasRenderer (el valor predeterminado es falso). Si se establece en verdadero, el lienzo se borrará y quedará el color de tono del fondo (Ie01e5).
• Se agregó la clave de metadatos androidx.watchface.complications.datasource.DEFAULT_CONFIGURATION_SUPPORTED, que permite que las fuentes de datos de complicaciones indiquen que pueden proporcionar un valor predeterminado sin ninguna configuración (Icc0d4).
• Cuando se edita una cara de reloj, con frecuencia hay una instancia interactiva y una instancia sin interfaz gráfica. Para ahorrar memoria, presentamos Renderer.SharedAssets, que permite que un procesador de caras de reloj comparta datos inmutables (p. ej., texturas y sombreadores) entre instancias. GlesRenderer.setEglConfig y GlesRenderer.setEglDisplay quedaron obsoletos, y nunca estuvo previsto que se puedan configurar. Hacerlo, hubiese provocado un comportamiento indefinido (I0d9e7).
• Agregamos setNameResourceId y setScreenReaderNameResourceId (que son recursos de strings de referencia) a ComplicationSlot.Builder y los métodos get correspondientes en androidx.wear.watchface.client.ComplicationSlotState. Esto permite que el sistema recupere los nombres de ComplicationSlots para usar en editores y lectores de pantalla (If6c6a).
• WatchfaceMetadataClient.getUserStyleSchema y getComplicationSlotMetadataMap ahora arrojan WatchFaceException en lugar de RemoteException (I86f11).
• Se cambió el nombre de onSynchronousComplicationRequest y las funciones relacionadas en ComplicationDataSourceService por onImmediateComplicationRequest, etcétera (I87ba0).
• Los editores de caras de reloj tienen mucho menos espacio de pantalla que los editores complementarios. Por lo tanto, conviene admitir diferentes íconos en los editores de cara de reloj. Este parche agrega OnWatchEditorData (que actualmente contiene solo un ícono) a todas las opciones de UserStyleSettings y, cuando corresponda, a sus clases de opción (If1886).
• Se agregó @JvmOverloads al constructor de ListenableGlesRenderer para una mejor interoperabilidad de Java (I2974a).

Correcciones de errores

• El constructor de ListenableGlesRenderer ahora está marcado correctamente como @Throws(GlesException::class) y es posible extender esta clase en Java (Iac6d0).
• Se corrigió un error con PhotoImageComplicationData tapAction que no se manejaba de forma correcta (I1cc30).

Versión 1.1.0-alpha02

12 de enero de 2022

Lanzamiento de androidx.wear.watchface:watchface-*:1.1.0-alpha02. La versión 1.1.0-alpha02 contiene estas confirmaciones.

Nuevas funciones

• Para facilitar la depuración y las pruebas, ComplicationData y las subclases relacionadas ahora anularon el código hash y los métodos equals y toString, lo que permite trabajar con más facilidad.

Cambios en la API

• Los métodos WatchfaceMetadataClient vuelven a arrojar RemoteExceptions cuando corresponda, lo que facilita que el código del cliente detecte errores de la cara de reloj. (I78785)
• ComplicationData y subclases ahora tienen código hash y métodos equals y toString. (I24bc6)

Versión 1.1.0-alpha01

15 de diciembre de 2021

Lanzamiento de androidx.wear.watchface:watchface-*:1.1.0-alpha01. La versión 1.1.0-alpha01 contiene estas confirmaciones.

Nuevas funciones

• UserStyleSchema y ComplicationSlots ahora se pueden definir en XML. De esta manera, se simplifica la creación de caras de reloj. Además, las búsquedas de WatchFaceMetadataClient son más rápidas porque este objeto no necesita vincularse al servicio para obtener los metadatos. WatchFaceMetadataClient y ListenableWatchFaceMetadataClient ya no son experimentales y pasarán a formar parte de la API estable. El sistema podrá admitir varias instancias de una cara de reloj, cada una con las distintas opciones de estilo definidas por el usuario. Podrán verse en el selector de caras de reloj. Para habilitar esta función, una cara de reloj debe incluir la siguiente etiqueta de metadatos en su manifiesto.

      <meta-data
          android:name="androidx.wear.watchface.MULTIPLE_INSTANCES_ALLOWED"
          android:value="true" />
  

• Algunas caras de reloj tienen un estado que no se captura en UserStyle. Para admitir esta y varias instancias, el ID de instancia de la cara de reloj ahora está disponible a través de WatchState.watchFaceInstanceId.

• ComplicationData ahora se almacena en caché para permitir que se muestren las complicaciones de inmediato cuando se carga. En ocasiones, el sistema almacena ComplicationData en caché de la memoria y, a veces, las bibliotecas de caras de reloj los serializan. Al serializar, se pierde cualquier acción tapAction asociada. En ese caso, ComplicationData.tapActionLostDueToSerialization mostrará true y la cara de reloj debería renderizar la complicación de manera diferente (p. ej., inhabilitada o semitransparente) para indicar que no se puede presionar. El sistema enviará ComplicationData actualizados con una tapAction lo antes posible.

• Algunos ComplicationData no deberían almacenarse en caché mucho tiempo. Sin embargo, para admitir esta opción, agregamos una función más general, ComplicationDataTimeline. Esta se puede usar para proporcionar una secuencia de ComplicationData con restricciones de tiempo para que se entregue a la cara del reloj y se pueda almacenar en caché y actualizar automáticamente. Por ejemplo, el pronóstico del tiempo del día en distintos horarios o varios eventos futuros del calendario. Se amplió ComplicationRequestListener con un nuevo método onComplicationDataTimeline, que puedes usar para mostrar estos datos.

• DefaultComplicationDataSourcePolicy se amplió para que puedas especificar ComplicationType para las fuentes de datos principal y secundaria.

• Agregamos compatibilidad con proveedores de complicaciones síncronas en los que la complicación se actualiza con una frecuencia mayor que la normal (hasta una vez por segundo) cuando la cara de reloj es visible y no ambiental. Nota: Es posible que los proveedores de complicaciones síncronas tengan un uso limitado debido a los problemas de presión de la memoria.

• Es probable que se reviertan los cambios de PendingIntentTapListener porque resolvimos el problema subyacente (no es posible que la cara de reloj inicie actividades durante 5 segundos después de presionar el botón de inicio) en el framework.

Cambios en la API

• Se cambió ComplicationData.isCached por tapActionLostDueToSerialization, que resulta más útil para determinar si la ranura de la complicación debe procesarse de manera diferente para indicar que no se puede presionar (I6de2f).
• Se agregó ComplicationDataTimeline a wear-complication-data-source. Esta se puede usar para proporcionar una secuencia de ComplicationData con restricciones de tiempo para que se entregue a la cara del reloj y se pueda almacenar en caché y actualizar automáticamente. Por ejemplo, el pronóstico del tiempo del día en distintos horarios o varios eventos futuros del calendario. Se amplió ComplicationRequestListener con un nuevo método onComplicationDataTimeline, que puedes usar para mostrar estos datos. Hay un nuevo wrapper de Kotlin SuspendingTimelineComplicationDataSourceService para suspender servicios de fuentes de datos (Idecdc).
• Se agregaron PendingIntentTapListener y WatchFaceControlClient.getPendingIntentForTouchEvent. Esto puede ayudar a las caras de reloj que necesitan iniciar intents en respuesta a presiones para solucionar un problema en el que el framework bloquea el inicio de actividades nuevas durante 5 segundos después de presionar el botón de inicio (I98074).
• Se introdujo una caché ComplicationData de cara de reloj. Su propósito es permitir que la cara de reloj muestre los últimos valores de datos de complicación conocidos al cargarse hasta que el sistema haya tenido la oportunidad de actualizarlos. Hay un nuevo método de API WatchFaceControlClient.hasComplicationCache para OEM. Esto puede influir en la estrategia del sistema para enviar complicaciones a una cara de reloj. Además, ComplicationData tiene una propiedad isCached, por lo que se recomienda que las complicaciones almacenadas en caché se rendericen de manera diferente debido a que tapAction no se puede almacenar en caché y será null en una complicación almacenada en caché (I404b0).
• El ID de instancia de la cara de reloj ahora está disponible a través de WatchState.watchFaceInstanceId. La mayoría de las caras de reloj no necesitan este recurso, pero si hay un estado de cara de reloj que no esté almacenado en el esquema, esta es la clave que debes usar para identificar la instancia de cara de reloj. Para admitir esta opción, ahora puedes proporcionar un ID cuando llames a WatchFaceControlClient.createHeadlessWatchFaceClient (I1ff98).
• Se amplió DefaultComplicationDataSourcePolicy con la capacidad de establecer el ComplicationTypes predeterminado para el proveedor principal y secundario, y el proveedor de sistemas de resguardo. Se dio de baja ComplicationSlot.defaultDataSourceType (If0ce3).
• ComplicationSlot.configExtras ahora es mutable y se puede actualizar antes de llamar a EditorSession.openComplicationDataSourceChooser() (I6f852).
• Se agregaron WatchFace.setComplicationDeniedDialogIntent y setComplicationRationaleDialogIntent. Estos intents se inician para mostrar un diálogo de justificación antes de solicitar permisos de complicación y otro cuadro que explique que se necesita permiso de complicación cuando se intenta editar una complicación, pero se rechazaron los permisos (el selector de proveedores no podrá abrirse, por lo que se necesita el diálogo) (I3a29c).
• UserStyleSchema y ComplicationSlots ahora se pueden definir en XML. Esto simplifica la construcción de la cara de reloj y hace que las búsquedas de WatchFaceMetadataClient sean más rápidas, ya que no necesitan vincularse al servicio para obtener los metadatos (I85bfa).
• Se agregó InteractiveWatchFaceClient.supportsPendingIntentForTouchEvent para que un cliente pueda determinar si una cara de reloj admite getPendingIntentForTouchEvent (I0b917).
• WatchFaceMetadataClient y ListenableWatchFaceMetadataClient dejaron de ser experimentales. Se pueden usar de manera eficiente para obtener metadatos de la cara de reloj cuando sea posible sin abrir una vinculación con la cara de reloj (Ibb827).
• Agregamos compatibilidad con proveedores de complicaciones síncronas en los que la complicación se actualiza con una frecuencia mayor que la normal (hasta una vez por segundo) cuando la cara de reloj es visible y no ambiental. Para usar esta función, el proveedor debe incluir una nueva etiqueta de metadatos androidx.wear.watchface.complications.data.source.SYNCHRONOUS_UPDATE_PERIOD_SECONDS en su manifiesto y anular onSynchronousComplicationRequest. Según la naturaleza de la fuente de datos, es posible que también deba anular onStartSynchronousComplicationRequests y onStopInteractiveComplicationRequests para recibir notificaciones cuando la complicación ingresa al modo interactivo y sale de él (I8fe9d).

Versión 1.0

Versión 1.0.1

9 de febrero de 2022

Lanzamiento de androidx.wear.watchface:watchface-*:1.0.1. La versión 1.0.1 contiene estas confirmaciones.

Correcciones de errores

• Se corrigió un error con PhotoImageComplicationData tapAction que no se manejaba de forma correcta (I1cc30)

Versión 1.0.0

1 de diciembre de 2021

Lanzamiento de androidx.wear.watchface:watchface-*:1.0.0. La versión 1.0.0 contiene estas confirmaciones.

Funciones principales de la versión 1.0.0

El paquete androidx.wear.watchface es la nueva biblioteca recomendada para desarrollar caras de reloj para Wear OS. Incluye varias funciones nuevas en comparación con la antigua biblioteca de compatibilidad con dispositivos wearable.

• La biblioteca es compatible directamente con el estilo del usuario (p. ej., permite cambiar la paleta de colores, el estilo de las agujas, el aspecto de las marcas de hora, etc.) (consulta androidx.wear.watchface.style). Ahora es mucho más fácil desarrollar un editor para la cara del reloj mediante androidx.wear.watchface.editor, y la cara del reloj puede editarse desde la app complementaria del sistema sin necesidad de escribir código adicional.
• Prácticas recomendadas integradas. La biblioteca genera automáticamente etiquetas de contenido del lector de pantalla para las complicaciones (también puedes agregar otras propias), y la velocidad de fotogramas disminuye de manera automática cuando el nivel de batería es bajo y no se carga el dispositivo a fin de mejorar la duración de la batería.
• Se necesita menos código para desarrollar una cara de reloj, en especial para las complicaciones en las que gran parte del código estándar se trasladó a la biblioteca.

Correcciones de errores

• Se corrigió EditorSession.userStyle.compareAndSet (I6f676).
• Se corrigieron los breves retrasos de las caras de reloj (Iffb97).
• El elemento InteractiveWatchFaceImpl.onDestroy se envía en el subproceso de IU (I83340).
• Se solucionaron varios problemas con los receptores de emisión (I7d25f).

Versión 1.0.0-rc01

3 de noviembre de 2021

Se lanzó androidx.wear.watchface:watchface-*:1.0.0-rc01. La versión 1.0.0-rc01 contiene estas confirmaciones.

Correcciones de errores

• Se corrigió dump() (llamado adb shell dumpsys), que se rompió por las migraciones de flujo (087cf9e).

• Garantiza el orden adecuado de writeDirectBootPrefs. Queremos que writeDirectBootPrefs se ejecute siempre después de initStyleAndComplications o corremos el riesgo de retrasar el init del subproceso de IU (37650ac).

• Asegúrate de que se llame a Renderer.onDestroy. En el escenario en que se creó el procesador, pero no se completó el init de WF y se llama a Engine.onDestroy, debemos llamar a Renderer.onDestroy (f9952dc).

• Optimización o corrección de isBatteryLowAndNotCharging. Este parche mueve la configuración inicial de isBatteryLowAndNotCharging antes, lo que significa que se puede realizar en paralelo con createWatchFace. Además, ahora escuchamos ACTION_POWER_DISCONNECTED (ddffd80

• InteractiveWatchFaceClientImpl.isConnectionAlive será falso después de cerrar (ab9774e).

Versión 1.0.0-beta01

27 de octubre de 2021

Se lanzó androidx.wear.watchface:watchface-*:1.0.0-beta01. La versión 1.0.0-beta01 contiene estas confirmaciones.

Versión 1.0.0-alpha24

13 de octubre de 2021

Lanzamiento de androidx.wear.watchface:watchface-*:1.0.0-alpha24. La versión 1.0.0-alpha24 contiene estas confirmaciones.

Cambios en la API

• Las clases en el paquete androidx.wear.watchface.complications se movieron a un proyecto wear:watchface:watchface-complications nuevo. Ten en cuenta que esto implica que no puedes incluir esta biblioteca, así como tampoco ninguna versión alfa anterior de wear:watchface:watchface-complications-data, ya que se producirán errores relacionados con las clases duplicadas. (I97195)
• Renderer.dump cambió de nombre a Renderer.onDump y se anotó con @UiThread. (I44845)
• Se cambió el nombre de InteractiveWatchFaceClient.addWatchFaceReadyListener por addOnWatchFaceReadyListener y el de removeWatchFaceReadyListener por removeOnWatchFaceReadyListener. (I48fea)
• EditorSession getComplicationsPreviewData y getComplicationsDataSourceInfo ya no son funciones de suspensión, sino que son propiedades StateFlow<> cuyo valor, en un principio, es nulo. En ListenableEditorSession, se quitaron getListenableComplicationPreviewData y getListenableComplicationsProviderInfo, y se reemplazaron por los objetos StateFlow<> nuevos desde la clase base. Si necesitas detectar los cambios en el código Java, considera usar androidx.lifecycle.FlowLiveDataConversions.asLiveData para convertir a LiveData<>. (Ic5483)

Versión 1.0.0-alpha23

29 de septiembre de 2021

Lanzamiento de androidx.wear.watchface:watchface-*:1.0.0-alpha23. La versión 1.0.0-alpha23 contiene estas confirmaciones.

Nuevas funciones

La biblioteca de caras de reloj ahora es un solo grupo de bibliotecas. Como resultado, las bibliotecas se trasladaron, y deberás actualizar tus importaciones de Gradle de la siguiente manera:

Cambios en la API

• Se migraron las bibliotecas de caras de reloj y complicaciones androidx.wear por separado al grupo de bibliotecas androidx.wear.watchface. (b25f3c0)
• Se agregó EditorRequest.canWatchFaceSupportHeadlessEditing para de informar al cliente si un editor de cara de reloj admite la edición sin interfaz gráfica. Ten en cuenta que habrá algunos falsos negativos debido a que se agregó compatibilidad en asop/1756809. Sin embargo, se mostrará el valor correcto para todas las caras de reloj futuras. (ca55590)
• El procesador ahora tiene un método dump() que se puede anular para agregar datos personalizados a la información generada por el servicio de actividad de volcado de shell de ABD WatchFaceService. (95235f9)
• InteractiveWatchFaceClient.addWatchFaceReadyListener ahora especifica el ejecutor primero. (563ac2f)
• Se quitó StateFlowCompatHelper. En su lugar, debes usar asLiveData (androidx.lifecycle.asLiveData). (bd35d3)
• El objeto CurrentUserStyleRepository.userStyle ya no es mutable. (I44889)
• Se cambió el nombre de WatchFaceReadyListener por OnWatchFaceReadyListener. (Ic12a9)

Correcciones de errores

• InteractiveInstanceManager.deleteInstance para llamar a onDestroy. Esto es necesario para asegurarse de que InteractiveWatchFaceImpl obtenga la recolección de elementos no utilizados. (fce4af8, b/199485839)