Aerlink: conexión Bluetooth entre iOS y Wear OS

Aerlink: conexión Bluetooth entre iOS y Wear OS Aerlink: Bluetooth connection between iOS and Wear OS Guillermo Cique Fernández GRADO EN INGENIERÍA DEL SOFTWARE. FACULTAD DE INFORMÁTICA UNIVERSIDAD COMPLUTENSE DE MADRID Trabajo de fin de grado del Grado en Ingeniería del Software Curso 2019-2020 Director: Jorge Jesús Gómez Sanz Resumen Un reloj inteligente o smartwatch es uno de los dispositivos tecnológicos más personales que podemos poseer, siempre está con nosotros, actuando como una pequeña ventana a nuestro mundo digital y, en muchos casos, monitorizando diversos aspectos de nuestra salud. Para usuarios de iOS, la opción más obvia puede ser el Apple Watch, pero hay un mundo entero de dispositivos con el sistema operativo Wear OS que pueden convertirse en una opción más económica o menos restrictiva para estos usuarios. Este proyecto relata la creación de Aerlink, un sistema compuesto por dos aplicaciones que, trabajando juntas, consiguen conectar gracias a la tecnología Bluetooth Low Energy un dispositivo iOS y un dispositivo Wear OS, ofreciendo funcionalidades no disponibles previamente. Palabras clave Bluetooth Low Energy iOS Android Wear Wear OS Reloj inteligente Wearable Conexión inalámbrica Desarrollo móvil Abstract A smartwatch is one of the most personal devices we can own, it is always with us, acting as a small window into our digital world and, in many cases, monitoring diverse aspects of our health. For iOS users, the obvious choice may be the Apple Watch, but there is a whole world of devices with similar functionalities running the operating system Wear OS that can become a more economic or less restrictive option for these users. This project narrates the creation of Aerlink, a system composed by two applications that, working together, manage to connect through Bluetooth Low Energy an iOS device and a Wear OS device, offering functionalities previously not available. Keywords Bluetooth Low Energy iOS Android Wear Wear OS Smartwatch Wearable Wireless connection Mobile development Dedicatoria A mi padre y a mi hermana. A mi novia. A los chicos del DAM. Al director de este TFG. Índice general Índice i Índice de figuras iv 1. Introducción 1 1.1. Motivación..................................... 1 1.2. Objetivos ..................................... 2 1.3. Plandetrabajo.................................. 3 1.4. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction 4 1.1. Motivation..................................... 4 1.2. Goals........................................ 5 1.3. Workplan..................................... 5 1.4. Documentstructure................................ 6 2. Estado del Arte 7 2.1. Mercado de smartwatches ............................ 7 2.2. WearOSbyGoogle................................ 8 2.3. Interoperabilidad mediante Bluetooth . . . . . . . . . . . . . . . . . . . . . . 10 2.3.1. Servicios y Características . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.2. Dificultades ................................ 12 3. Especificación de Requisitos 13 3.1. Ámbitodelsistema................................ 13 3.2. RestriccionesdeDiseño.............................. 14 i 3.3. Características de los Usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.4. Requisitosespecíficos............................... 15 3.4.1. Especificación de Atributos de Calidad . . . . . . . . . . . . . . . . . 15 3.4.2. Especificación de Requisitos Funcionales . . . . . . . . . . . . . . . . 16 4. Diseño e implementación del sistema 19 4.1. AerlinkWearOS ................................. 20 4.1.1. MainService................................ 20 4.1.2. DiscoveryManager ............................ 20 4.1.3. BondManager............................... 22 4.1.4. ConnectionManager............................ 23 4.1.5. ServiceContract y ServiceManager . . . . . . . . . . . . . . . . . . . . 24 4.1.6. CharacteristicIdentifier . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.1.7. Command................................. 25 4.2. AerlinkiOS .................................... 25 4.2.1. MainService................................ 26 4.2.2. DataActionService ............................ 26 4.3. DiseñodeserviciosApple............................. 26 4.3.1. Notificaciones............................... 27 4.3.2. Controlmultimedia............................ 30 4.3.3. Batería................................... 32 4.4. Diseño del servicio Aerlink . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.4.1. Control remoto de cámara . . . . . . . . . . . . . . . . . . . . . . . . 33 4.4.2. Recordatorios............................... 35 5. Experimentación 38 5.1. Pruebas ...................................... 40 5.1.1. Notificaciones............................... 40 ii 5.1.2. Controlmultimedia............................ 41 5.1.3. Batería................................... 42 5.1.4. Control remoto de cámara . . . . . . . . . . . . . . . . . . . . . . . . 43 5.1.5. Recordatorios............................... 44 5.1.6. Conexión ................................. 45 6. Conclusiones y líneas futuras 46 6. Conclusions and future lines 49 Glosario 52 Bibliografía 55 iii Índice de figuras 2.1. Proyección del mercado de smartwatches .................... 8 2.2. Capturas de pantalla de Wear OS by Google . . . . . . . . . . . . . . . . . . 9 2.3. Descargas desde 2015 a 2020 de Aerlink iOS . . . . . . . . . . . . . . . . . . 10 2.4. Representación de un Perfil BLE . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. SistemaAerlink.................................. 20 4.2. Wear OS: Diagrama de clases responsables de la conexión . . . . . . . . . . . 21 4.3. Requisito funcional 1: Inicio del servicio Aerlink . . . . . . . . . . . . . . . . 22 4.4. Requisito funcional 2: Establecer conexión . . . . . . . . . . . . . . . . . . . 24 4.5. iOS: Diagrama de clases responsables de la conexión . . . . . . . . . . . . . . 25 4.6. DiagramadeclasesANCS ............................ 27 4.7. Ejemplodeevento ................................ 28 4.8. Ejemplodecomando ............................... 28 4.9. Ejemploderespuesta............................... 28 4.10. Requisito funcional 4: Recibir notificación . . . . . . . . . . . . . . . . . . . 29 4.11. Requisito funcional 5: Descartar una notificación . . . . . . . . . . . . . . . . 29 4.12.DiagramadeclasesAMS............................. 30 4.13. Requisito funcional 6: Ver información multimedia . . . . . . . . . . . . . . . 31 4.14. Requisito funcional 7: Controlar reproducción multimedia . . . . . . . . . . . 31 4.15. Diagrama de clases Battery Service . . . . . . . . . . . . . . . . . . . . . . . 32 4.16. Requisito funcional 3: Ver nivel de batería . . . . . . . . . . . . . . . . . . . 33 4.17. iOS: Diagrama de clases del servicio de control remoto de cámara . . . . . . 34 4.18. Requisito funcional 8: Tomar foto . . . . . . . . . . . . . . . . . . . . . . . . 34 4.19. Wear OS: Diagrama de clases del servicio de control remoto de cámara . . . 35 iv 4.20. iOS: Diagrama de clases del servicio de recordatorios . . . . . . . . . . . . . 36 4.21. Wear OS: Diagrama de clases del servicio de recordatorios . . . . . . . . . . 37 4.22. Requisito funcional 11: Ver listado de recordatorios . . . . . . . . . . . . . . 37 5.1. LGGWatch ................................... 38 5.2. TicwatchEExpress................................ 38 5.3. SonySmartWatch3................................ 39 5.4. Motorola Moto 360 V2 Sport . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.5. iPhone11Pro................................... 39 5.6. Nexus5 ...................................... 39 5.7. Ejemplodenotificación.............................. 40 5.8. Ejemplo de reproducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.9. Niveldebatería.................................. 42 5.10. Control remoto de cámara . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.11. Gestión de recordatorios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 v Capítulo 2 Estado del Arte Un artista copia, un gran artista roba. Guillermo Cique En este capítulo se revisa el contexto comercial de los smartwatches, las alternativas disponibles en el mercado y la problemática de la conexión entre dispositivos iOS y Wear OS. 2.1. Mercado de smartwatches El mercado de smartwatches está en su mejor momento con algunas estimaciones (Fig. 2.1) poniendo el número de ventas en 2020 por encima de los 80 millones1. Situándose en cabeza, el Apple Watch con un market share de más del 50 %2muestra el gran interés en este tipo de dispositivos de los usuarios de las plataformas de Apple. Por debajo del Apple Watch el mercado está bastante fragmentado, hay muchas empresas que intentan usar sistemas operativos propietarios como Samsung, Garmin o Fitbit y a parte tenemos Wear OS con el que Google intenta replicar el éxito que tuvo en el mercado móvil con su sistema operativo Android. En noviembre de 2019, Google compró uno de sus mayores competidores, Fitbit, por 2.100 millones de dólares con intenciones de seguir invirtiendo en este mercado y con vistas de, en un futuro, acabar presentando relojes inteligentes “hechos por Google” 3. 7 Figura 2.1:Proyección del mercado de smartwatches 2.2. Wear OS by Google El soporte oficial de iOS para relojes Android Wear fue presentado con la app Wear OS by Google4a principios de septiembre de 2015. Esta aplicación permite vincular un reloj Wear OS con un dispositivo iOS ofreciendo las siguientes funcionalidades (Fig. 2.2): Asistente de Google Control de la actividad física Control de la música Notificaciones Responder correos de Gmail Se trata de la única alternativa disponible para poder conectar un reloj Wear OS con un dispositivo iOS, esta conexión requiere enlazar un reloj de cero con un dispositivo iOS haciendo imposible conectar un reloj enlazado con un Android con un dispositivo iOS manteniendo una conexión con ambos. 8 Figura 2.2:Capturas de pantalla de Wear OS by Google La mayor desventaja de está aplicación es su fuerte dependencia de los servicios de Google, todas las funcionalidades extra que ofrece, como por ejemplo el control de la actividad física, requieren que el usuario utilice un servicio de Google para hacer uso de ellas. La mayoría de usuarios de Apple preferiría dar uso a los servicios ofrecidos directamente en su dispositivo y muchos otros simplemente no estarían dispuestos a usar ciertos servicios de Google. El sistema Aerlink vio la luz por primera vez en 2015, meses antes del lanzamiento de Wear OS by Google para iOS, siendo la aplicación para Wear OS gratuita en el Play Store de Android y teniendo su contra-parte en iOS un precio de 1,99$ en el App Store de iOS. A pesar de ser Wear OS by Google una opción gratuita y oficial, Aerlink ha seguido siendo descargada, llegando a acumular más de 180.000 descargas en Android y más de 50.000 en iOS (Fig. 2.3); superando los 100.000 dólares americanos en ventas. Estos datos hacen obvia la demanda de los usuarios por una alternativa a la aplicación oficial de Wear OS by Google. 9 Figura 2.3:Descargas desde 2015 a 2020 de Aerlink iOS 2.3. Interoperabilidad mediante Bluetooth Apple no permite establecer conexiones Bluetooth Classic con dispositivos que no tengan la certificación MFi. La única forma disponible en la actualidad para conectar este tipo de dispositivos entre sí es con Bluetooth Low Energy. Bluetooth Low Energy (BLE) se trata de la versión de bajo consumo del estándar Bluetooth que nos permite desplegar redes inalámbricas de área personal (PAN) y forma parte de la especificación de Bluetooth 4.0. Su sustancial reducción del consumo lo hace perfecto para gran variedad de aplicaciones como wearables, fitness o seguridad. El Generic Access Profile (GAP) se encarga de controlar las conexiones y los anuncios en BLE permitiendo hacer la presencia de un dispositivo pública y determinando si dos dispositivos pueden (o no) establecer una conexión entre ellos. En el caso de Aerlink, la parte iOS tomará el papel de periférico e empezará a anunciar su presencia a través de GAP. Será la app de Wear OS la que actúe como central, conectándose al dispositivo iOS para empezar a recibir información sobre este. La manera en que dos dispositivos BLE se comunican viene definida por el Generic Attribute Profile (GATT). En GATT el periférico se conoce como servidor GATT, contiene 10 los datos de búsqueda ATT y las definiciones de servicio y características, la central o cliente GATT es quien envía solicitudes a este servidor. 2.3.1. Servicios y Características Las transacciones GATT en BLE se basan en objetos anidados de alto nivel denominados Perfiles, Servicios y Características organizados como se muestra en la Fig. 2.4: Figura 2.4:Representación de un Perfil BLE Un perfil es simplemente una colección de servicios predefinidos por el Bluetooth Special Interest Group, por el fabricante del periférico o, en el caso de Aerlink, por el desarrollador de la aplicación que inicia los servicios. Los servicios, al igual que los perfiles, se utilizan para dividir datos en entidades lógicas, conteniendo a su vez una colección de características. Cada servicio se distingue a través de un Universally Unique Identifier o Identificador Único Universal (UUID) y puede tener una o más características a su vez identificadas por un UUID. El nivel más bajo en las transacciones GATT son las características, que encapsulan un único tipo de dato que variará dependiendo del uso de la característica y cuyo formato deberá ser conocido por la central. Las centrales pueden registrase a ellas para obtener 11 actualizaciones cuando este dato cambie o pueden escribir en ellas para transmitir un cambio o actualización en el periférico. 2.3.2. Dificultades A la restricción de Apple de no poder utilizar Bluetooth Classic libremente hay que añadir la estricta gestión de las aplicaciones en segundo plano de iOS, que penaliza especialmente a aplicaciones como Aerlink, aplicaciones que idealmente el usuario no necesitaría estar abriendo continuamente pero se ve forzado a hacerlo periódicamente; en el caso de Aerlink esta puede ser la única forma que tiene de restablecer una conexión perdida con un dispositivo Wear OS. Por otro lado, el Bluetooth stack de Android es en un pequeño desastre. Un claro ejemplo es la función de reconexión automática de BluetoothDevice, una función plagada de errores que parece funcionar de manera aleatoria en algunos dispositivos y en otros directamente no funciona nunca. Esto consigue que el desarrollador simplemente no pueda recurrir a esta funcionalidad y tenga que volver a escanear en busca del dispositivo al que estaba conectado para poder iniciar una conexión de cero manualmente. 12 Capítulo 3 Especificación de Requisitos First, solve the problem. Then, write the code. John Johnson El objetivo de la Especificación de Requisitos Software5es definir de forma precisa y comprensible todas las funcionalidades y restricciones del sistema que se desea construir. Se procura que la Especificación de Requisitos Software despeje y clarifique cualquier duda que pueda surgir sobre el funcionamiento del sistema a modo de “guía de usuario”. 3.1. Ámbito del sistema El sistema Aerlink consiste en dos aplicaciones, una para dispositivos Wear OS y otra para dispositivos iOS, que deberán establecer una conexión mediante tecnología Bluetooth LE, permitiendo al usuario recibir información del dispositivo iOS en su dispositivo Wear OS y controlar diversas funcionalidades de su dispositivo iOS remotamente con su dispositivo Wear OS. No se contempla el caso de conectar un dispositivo Wear OS con un dispositivo Android, este tipo de conexión queda resuelta por la conexión nativa ofrecida por ambos sistemas operativos que además permite añadir funcionalidades nuevas de forma sencilla. Se da por supuesto el uso de un dispositivo ejecutando el sistema operativo Wear OS y otro ejecutando el sistema operativo iOS. Además de un correcto funcionamiento de las 13 capacidades Bluetooth de ambos dispositivos se supone que el usuario acepta los permisos necesarios para la ejecución de ambas aplicaciones; siendo estos el permiso de localización en el dispositivo Wear OS y los permisos de Bluetooth, acceso a cámara, guardar imágenes y acceso a los recordatorios en el dispositivo iOS. 3.2. Restricciones de Diseño Apple solo permite establecer conexiones BLE con dispositivos que no formen parte del programa MFi. Al no tener acceso a Bluetooth Classic la velocidad y fiabilidad de la conexión se ven muy afectadas pasando de 2-3 Mbps a tan solo 200 kbps. La gestión de aplicaciones en segundo plano de Apple es muy estricta causando que el servicio BLE pueda no encontrarse disponible, forzando al usuario a reabrir la aplicación para relanzar el servicio. La única acción permitida en las notificaciones de Apple desde un dispositivo Bluetooth es la eliminación de las notificaciones. La gran cantidad de distintos relojes Wear OS hace imposible probar la aplicación en todos pudiendo causar comportamientos extraños en algún dispositivo. Las distintas compañías aplican regímenes distintos de gestión de memoria pudiendo llegar a cerrar conexiones Bluetooth en algunos dispositivos donde otros no se hubieran visto afectados. 3.3. Características de los Usuarios El sistema solo tiene un tipo de usuario, el usuario final de las aplicaciones. Estos usuarios tendrán un conocimiento técnico por encima de la media al haberse instalado en sus dispositivos una forma alternativa a la oficial de Google de conectar sus relojes con sus dispositivos iOS. 14 3.4. Requisitos específicos Diferenciaremos entre requisitos funcionales, es decir aquellos relacionados con los servicios o prestaciones que debe cumplir el sistema y no funcionales o atributos de calidad que hacen referencia a las características de funcionamiento. Para cada requisito identificado se especifica: ID Identificador numérico único Nombre Nombre descriptivo del requisito Descripción Descripción específica del requisito y su función Entrada Acciones y parámetros solicitados al usuario para llevar a cabo la funcionalidad Salida Respuesta del sistema Contexto App y pantalla en la que se desarrolla la acción 3.4.1. Especificación de Atributos de Calidad 1. Seguridad y privacidad: El sistema debe asegurar la protección de los datos e información personal del usuario. 2. Usabilidad: El sistema debe ser eficaz, intuitivo y ofrecer al usuario una experiencia agradable. 3. Compatibilidad: El sistema deberá ser compatible con el mayor número de dispositivos posibles tanto en Wear OS como iOS. 4. Actualizable: El sistema deberá permitir actualizaciones que añadan funcionalidad con facilidad sin afectar a la ya existente. 15 3.4.2. Especificación de Requisitos Funcionales ID 1 Nombre Inicio del servicio Aerlink Descripción Un usuario puede iniciar el servicio Aerlink para poder establecer la conexión entre dispositivos. Entrada El usuario marca como activa la opción “Aerlink” Salida Si el usuario concedió el permiso de localización el servicio se inicia, si no, se le pide que lo conceda. Contexto Wear OS app. Pantalla principal ID 2 Nombre Establecer conexión Descripción Una vez iniciado el servicio Aerlink este debe intentar establecer la conexión con un dispositivo iOS cercano. Entrada - Salida Los dispositivos iOS y Wear OS quedan conectados. Contexto Wear OS app. Servicio Aerlink ejecutándose tanto en iOS como en Wear OS ID 3 Nombre Ver nivel de batería Descripción Un usuario puede ver el nivel de batería de su dispositivo iOS Entrada - Salida El nivel de batería es visible Contexto Wear OS app. Estando conectado. Pantalla principal ID 4 Nombre Recibir notificación Descripción Un usuario puede recibir notificaciones de su dispositivo iOS Entrada Se recibe una notificación en el dispositivo iOS Salida Se recibe la misma notificación en el reloj Contexto Wear OS app. Estando conectado 16 4.1.4. ConnectionManager El ConnectionManager se encarga de establecer una conexión con un dispositivo Bluetooth previamente descubierto. Al ser la clase encargada de la conexión permite también comprobar si un servicio está disponible en el dispositivo conectado y ejecutar comandos en este. A través de su Callback se reciben mensajes cuando el dispositivo este listo para recibir suscripciones a sus servicios, cuando ocurra algún cambio en el estado de la conexión, cuando el dispositivo con el que estamos intentando conectarnos necesita un un enlace seguro o cuando ha habido cambios en una de las Characteristics de los servicios a los que nos hemos suscrito. Al intentar conectarse con un dispositivo el ConnectionManager comprueba primero si existe un enlace con este, pidiendo uno a través de su Callback si fuese necesario. En caso de tratarse de un dispositivo ya enlazado se inicia el proceso de conexión. Una vez establecida la conexión lo primero que se intenta es aumentar la Maximum Transmission Unit o Unidad Máxima de Transferencia (MTU) para permitir el envío y recepción de paquetes más grandes. Se consiga o no este cambio, el proceso de conexión continua con el descubrimiento de los servicios disponibles en el dispositivo conectado. Una vez descubiertos los servicios disponibles se pide al Callback las características a las que quiere suscribirse, se añaden a una cola y se procede a intentar suscribirse a todas; en caso de error o de que no haya ningún servicio disponible se considera que la conexión ha fallado. Por cada característica se intenta la suscripción un máximo número veces antes de considerar que la conexión ha fallado, al suscribirse a una característica se comprueba de nuevo la cola para continuar con la siguiente hasta que no quede ninguna, en este caso se considerará que la conexión está lista. Para acabar con el ConnectionManager, la gestión de comandos se hace también a través de una cola que se comprueba siempre que se añade un nuevo comando o se completa la ejecución del último. 23 Todas las acciones realizadas en el ConnectionManager tienen un tiempo límite de ejecución antes de que se considere que la conexión ha fallado, esto se hace para poder informar al usuario de que la conexión se ha perdido e intentar restablecerla. Figura 4.4:Requisito funcional 2: Establecer conexión 4.1.5. ServiceContract y ServiceManager ServiceContract es una interfaz que define el UUID del servicio, las características a suscribirse y un método para crear un ServiceManager. La interfaz ServiceManager incluye métodos para inicializar el ServiceManager, comprobar si puede manejar una característica, gestionar una característica que haya recibido un cambio y para cerrar el ServiceManager. Cada servicio GATT necesita su ServiceContract y su ServiceManager para que se pueda 24 trabajar con él. 4.1.6. CharacteristicIdentifier La clase CharacteristicIdentifier simplemente se usa para identificar una característica GATT, esta compuesta del UUID del servicio y del UUID de la característica. 4.1.7. Command Un Command tiene la información necesaria para realizar una acción de lectura o escritura en el dispositivo enlazado. Contiene la información para identificar la característica donde se va a ejecutar, el paquete de datos en caso de tratarse de una acción de escritura y lleva la cuenta de intentos fallidos. 4.2. Aerlink iOS La gran parte del código que gestiona la conexión entre los dispositivos se encuentra en la aplicación Wear OS pero el usuario necesitará también la aplicación iOS para que esta pueda anunciar su presencia yofrecer las funcionalidades exclusivas de Aerlink. Figura 4.5:iOS: Diagrama de clases responsables de la conexión 25 4.2.1. MainService La clase MainService actúa de delegado de un CBPeripheralManager 8, esto le permite recibir actualizaciones cuando, entre otras cosas, ha habido un cambio en la disponibilidad del Bluetooth en el dispositivo, cuando se ha realizado una conexión o desconexión, o cuando un dispositivo se ha registrado a una característica. Al recibir un estado válido se inicia un servicio y se le añaden las características de los servicios exclusivos de Aerlink; además, al recibir un estado inválido, deja de anunciarse y reinicia ambos servicios a su estado inicial. La clase MainService también se encarga de enviar los datos a los dispositivos Wear OS conectados, divide los datos a enviar en paquetes con un MTU válido y en caso de error avisará a los servicios cuando puedan volver a enviar datos. 4.2.2. DataActionService Para simplificar el desarrollo, los servicios implementados en la aplicación iOS tendrán un par de características con un funcionamiento análogo. Cada DataActionService tendrá una característica de datos a la que la aplicación Wear OS se podrá suscribir para recibir datos, y una característica de acciones a través de la cual la aplicación Wear OS podrá enviar comandos. 4.3. Diseño de servicios Apple En esta sección se describen los servicios preexistentes a los que tendrá acceso la aplicación Wear OS. Los servicios de notificaciones, control multimedia y batería son servicios implementados por Apple y que se vuelven disponibles una vez se ha establecido la conexión entre los dispositivos del sistema. Estos servicios solo requieren ser gestionados en la aplicación Wear OS. 26 4.3.1. Notificaciones El Apple Notification Center Service (ANCS)9es un servicio disponible en dispositivos iOS que permite a los dispositivos registrados obtener el feed de notificaciones y realizar determinadas acciones sobre ellas. Figura 4.6:Diagrama de clases ANCS La aplicación Wear OS utiliza este servicio para mostrar todas las notificaciones recibidas en el dispositivo con el que está emparejado. El usuario podrá descartarlas deslizando el dedo sobre la notificación eliminándose a su vez de su dispositivo iOS. 27 Figura 4.7:Ejemplo de evento Figura 4.8:Ejemplo de comando Figura 4.9:Ejemplo de respuesta Eventos (Fig. 4.7) son recibidos en la característica Fuente de notificaciones como un paquete de bytes con la información necesaria para pedir la información sobre la notificación que sea necesaria. El NotificationUID de estos se eventos se puede usar para pedir a la característica Punto de control atributos sobre la notificación como pueden ser el título, el mensaje o la aplicación origen de la notificación enviando un comando como el de la Fig. 4.8. Si la petición se realiza correctamente, la característica Fuente de datos responderá con la información pedida utilizando paquetes con el formato en Fig. 4.9. El NotificationServiceManager se encarga de gestionar los cambios en estas características y la creación de los eventos necesarios para obtener la información necesaria. Los eventos recibidos se añaden a una cola para poder gestionarlos de uno en uno, por cada evento se crea un comando para pedir la información completa y se crea un Notifica28 tionDataReader para juntar todos los paquetes que la conforman y poder manejar la información una vez la respuesta este completa. Una vez se han recibido todos los atributos necesarios se puede crear la notificación y publicar usando el NotificationManager para que el usuario pueda verla. Figura 4.10:Requisito funcional 4: Recibir notificación Figura 4.11:Requisito funcional 5: Descartar una notificación 29 4.3.2. Control multimedia El Apple Media Service (AMS)10 es un servicio disponible en dispositivos iOS que permite a los dispositivos registrados controlar remotamente aplicaciones multimedia y obtener información de los medios multimedia siendo consumidos. Figura 4.12:Diagrama de clases AMS Los dispositivos registrados a este servicio pueden registrarse a la característica Actualización de entidades para recibir actualizaciones cuando haya cambios en determinados atributos como pueden ser el álbum, el nombre o el cantante de la canción actual. También se puede controlar el estado de reproducción escribiendo comandos en la característica Comandos remotos. El MediaServiceManager se encarga de registrarse a las características necesarias, recibir las actualizaciones, enviar los comandos para controlar el estado de reproducción y hacer todo esto disponible al usuario. 30 La aplicación Wear OS utiliza este servicio para mostrar la información de los medios multimedia en reproducción en el dispositivo con el que está emparejado. Además, el usuario podrá controlar remotamente estos medios, pudiendo retroceder, avanzar, reproducir, pausar o controlar el volumen. Figura 4.13:Requisito funcional 6: Ver información multimedia Figura 4.14:Requisito funcional 7: Controlar reproducción multimedia 31 4.3.3. Batería El Battery Service11 es un servicio incluido en la especificación oficial de Bluetooth LE y disponible en dispositivos iOS. Figura 4.15:Diagrama de clases Battery Service Los dispositivos registrados a este servicio recibirán actualizaciones cuando el nivel de batería del dispositivo con el que está emparejado cambie. El BatteryServiceManager se registra a los cambios en esta característica y mantiene actualizado el nivel de batería mostrado al usuario. Además, cuando el nivel de batería es inferior al 20 %, muestra una notificación al usuario con el nivel de batería. La aplicación Wear OS utiliza este servicio para mostrar el nivel de batería del dispositivo con el que está emparejado. 32 Figura 5.3:Sony SmartWatch 3 Figura 5.4:Motorola Moto 360 V2 Sport La aplicación iOS se instalará en un iPhone 11 Pro con iOS 13 (Fig. 5.5) que actuará de dispositivo iOS para todos los dispositivos Wear OS. Por último, se utilizará un Nexus 5 con Android 6.0.1 para facilitar el despliegue y depuración de la aplicación Wear OS en varios dispositivos a la vez, este dispositivo es necesario ya que, a pesar de no realizar función alguna en el sistema Aerlink, hay algunos dispositivos Wear OS que solo permiten depuración por Bluetooth a través de un dispositivo Android enlazado. Figura 5.5:iPhone 11 Pro Figura 5.6:Nexus 5 39 5.1. Pruebas 5.1.1. Notificaciones En la Fig. 5.7 se puede ver como una notificación recibida en el dispositivo iOS es también recibida y mostrada al usuario correctamente en los dispositivos Wear OS. Figura 5.7:Ejemplo de notificación. De izquierda a derecha: Moto 360, Ticwatch, iPhone 11 Pro, G Watch, SmartWatch 3. Las notificaciones pueden ser descartadas desde un dispositivo Wear OS, esto hace que desaparezcan también del centro de notificaciones del dispositivo iOS. Aunque según la documentación del servicio de notificaciones estas pueden venir acompañadas de una acción positiva y otra negativa, por lo general estas vienen solo con una acción negativa equivalente a descartar la notificación; en las pruebas solo se ha encontrado que al recibir una llamada, esta se recibe como una notificación cuya acción positiva es descolgar y cuya acción negativa es colgar, al tratarse de un caso especial este tipo de notificaciones se gestiona de forma especial mostrando una interfaz especifica. 40 5.1.2. Control multimedia En la Fig. 5.8 se puede ver como la información multimedia del dispositivo iOS se muestra en los dispositivos Wear OS correctamente. El control funciona correctamente desde todos los dispositivos a pesar de tratarse de versiones diferentes de Wear OS. Figura 5.8:Ejemplo de reproducción. De izquierda a derecha: Ticwatch, iPhone 11 Pro, G Watch. Se muestran correctamente los datos de título y artista, y se permite reproducir, pausar, avanzar pista, retroceder pista y controlar el volumen. En caso de tratarse de un título o nombre de artista largo este llega truncado, el servicio multimedia permitía pedir por separado los datos completos si estos llegaban truncados, en las pruebas esta funcionalidad no ha cumplido con la fiabilidad esperada llegando a mostrar datos incorrectos. Finalmente se ha decidido mostrar los datos truncados añadiendo “...” al final de estos. 41 5.1.3. Batería En la Fig. 5.9 se puede ver que la información de la batería del dispositivo iOS es mostrada correctamente en los dispositivos Wear OS. Al ocurrir cambios en el nivel de la batería, estos cambios son mostrados correctamente en la interfaz de los dispositivos Wear OS. Figura 5.9:Nivel de batería. De izquierda a derecha: Moto 360, Ticwatch, iPhone 11 Pro, G Watch, SmartWatch 3. Se ha comprobado que al bajar el nivel de batería del 20 % se muestra una notificación en el smartwatch enlazado, además esta notificación viene acompañada de una vibración al ser el nivel de batería exactamente 20%, 15%, 10% o 5% siempre y cuando el nivel anterior haya sido superior, es decir, esta vibración no se dará en el caso de que el dispositivo este cargándose. Por último, la notificación desaparecerá al superar el nivel de batería el 20%. 42 5.1.4. Control remoto de cámara En la Fig. 5.10 se puede ver la interfaz de la aplicación Wear OS de control remoto de cámara antes y después de tomar una foto. Figura 5.10:Control remoto de cámara. De izquierda a derecha: Ticwatch, iPhone 11 Pro, G Watch. Al tomar una foto desde cualquier de los dispositivos Wear OS esta es recibida en ambos, la aplicación Aerlink en iOS no diferencia quien ha iniciado la acción de tomar foto, toma la foto y esta es enviada a todos los dispositivos conectados. La calidad de la foto recibida en el smartwatch es bastante baja pero suficiente para cumplir el cometido de comprobar si el encuadre de la foto es correcto o si el objetivo de la foto ha salido correctamente. Esta funcionalidad se inspiró en la funcionalidad del Apple Watch que permite ver en tiempo real lo que está capturando la cámara del iPhone, en un principio se intentó replicar esta funcionalidad aunque fuese recibiendo imágenes cada X segundos; tras probar distintas soluciones se llegó a la conclusión de que requería un flujo de datos mucho mayor al que podía proporcionar BLE y se optó por recibir la imagen únicamente tras haberse completado la captura correctamente. 43 5.1.5. Recordatorios En la Fig. 5.11 se puede ver la interfaz de la aplicación Wear OS de gestión de recordatorios. En el dispositivo Wear OS de la izquierda se observa el listado de listas replicando los datos del dispositivo iOS, en el de la derecha se observa el contenido de la lista “Compra”. Figura 5.11:Gestión de recordatorios. De izquierda a derecha: Ticwatch, iPhone 11 Pro, G Watch. Se ha comprado que los colores de los listados mostrados en los dispositivos Wear OS son los mismos que se muestran en la aplicación Recordatorios de iOS. También se ha probado que funciona el modificar el estado de un recordatorio desde el smartwatch, este cambio se ve reflejado en tiempo real en la aplicación Recordatorios de iOS. En caso de no tener una conexión establecida, tanto está aplicación como la de control remoto de cámara muestran un mensaje informando al usuario que necesitan establecer una conexión antes de poder continuar. 44 5.1.6. Conexión Este es el apartado donde más pruebas se han realizado, siendo estas también las que más variabilidad han tenido en sus resultados. Se ha logrado establecer una conexión plena con todos los dispositivos Wear OS probados, pero también es cierto que el tiempo de conexión puede variar mucho entre un dispositivo Wear OS y otro, ya no solo por la versión de Wear OS si no también por el fabricante de este. Por ejemplo, algunos dispositivos pueden tener problemas al establecer la conexión llegando a requerir un reinicio de las funcionalidades Bluetooth del dispositivo, Aerlink realiza automáticamente este tipo de reinicio, pero esto llega a tener un impacto en el tiempo de conexión. Para realizar un enlace BLE con otro dispositivo, iOS requiere que la aplicación Aerlink esté en primer plano. Mientras no tenga una conexión establecida, el dispositivo Wear OS informa al usuario que tiene que abrir la aplicación Aerlink en su dispositivo iOS para poder establecerla. Esto puede ser una molestia para el usuario pero no hay forma de evitarlo. Para probar la reconexión se ha deshabilitado el Bluetooth en el dispositivo iOS, al rehabilitar el Bluetooth todos los dispositivos Wear OS han vuelto a encontrar al dispositivo iOS e intentado restablecer la conexión. También se ha probado a encerrar el dispositivo iOS en un microondas para simular una desconexión en la que el Bluetooth no es deshabilitado, en este caso ocurre lo mismo, al sacar el iPhone del microondas los dispositivos Wear OS son capaces de encontrarlo e intentan restablecer la conexión perdida. El éxito de está reconexión es similar al de la conexión normal, variando también de dispositivo a dispositivo. 45 Capítulo 6 Conclusiones y líneas futuras How does a project get to be a year late?... One day at a time. Fred Brooks Aerlink es sin duda uno de los proyectos que más me ha aportado, he disfrutado mucho aprendiendo a trabajar con la tecnología Bluetooth a bajo nivel, intentando solucionar problemas de conexión en muchos dispositivos diferentes, teniendo como competencia directa una aplicación desarrollada por Google, trabajando en una interfaz que recuerde al Apple Watch pero que no se sienta fuera de lugar en Wear OS, viendo como la gente disfruta de un trabajo realizado por mí... Por un lado, estoy satisfecho con el trabajo realizado. Se han cumplido los objetivos propuestos en la sección 1.2, Aerlink es capaz de establecer una conexión entre un dispositivo iOS y un dispositivo Wear OS, utilizando únicamente la tecnología BLE, ofreciendo las funcionalidades deseadas. Se cubren las funcionalidades básicas, como son la gestión de notificaciones recibidas o el control remoto de medios multimedia, y las funcionalidades exclusivas de Aerlink demuestran que, a pesar de los problemas planteados, es posible aumentar la utilidad de un dispositivo Wear OS emparejado con un dispositivo iOS. Por otro lado, sé que este trabajo está lejos de ser perfecto. Es un poco descorazonador el estado del desarrollo BLE para plataformas Android e iOS. Como se ha mencionado previamente, el Bluetooth stack de Android es un desastre, con funcionalidades mal imple46 mentadas o códigos de error sin documentar. En iOS, las restricciones de Apple dificultan mucho el desarrollo de una aplicación como Aerlink. Las faltas de iOS en este aspecto se hacen patentes en la aplicación de Wear OS by Google, demostrando que no importa si eres un gigante tecnológico como Google o un desarrollador solitario madrileño, te vas a enfrentar a las mismas dificultades. No cabe duda de que tener herramientas que no ofrece a sus competidores puede beneficiar a Apple, al no poder estos ofrecer funcionalidades similares a las de un Apple Watch; pero no queda tan claro que esto no perjudique al mercado de accesorios wearable en general, ya que alguien que esté desarrollando un accesorio tendrá que, o bien ignorar la plataforma iOS, o bien ofrecer un set de funcionalidades muy limitado, siendo ninguna de estas opciones ideal. El futuro de las aplicaciones que añaden funcionalidad a los dispositivos móviles más allá de una interfaz visual es demasiado incierto. Android, la plataforma que tradicionalmente ha dado más libertad a los desarrolladores, se parece cada vez más a iOS, añadiendo limitaciones a los desarrolladores para proteger la seguridad y rendimiento de sus dispositivos. iOS a su vez se ha ido abriendo, ofreciendo herramientas hace unos años impensables, pero lejos queda aún la ejecución de servicios en segundo plano sin restricciones. Claramente, la seguridad y rendimiento de nuestros dispositivos es algo que nos interesa a todos, pero también está claro que, tanto usuarios como desarrolladores de software, no queremos un futuro de la computación dictado en exclusiva por los proveedores de sistemas operativos, un futuro en el que la única forma de obtener funcionalidad extra en tu dispositivo dependa de quien te lo ha vendido o en el que las únicas aplicaciones que podamos desarrollar sean para gestionar datos en un servidor. A pesar de todo, espero que este proyecto le pueda resultar útil a alguien iniciándose en el desarrollo de funcionalidades BLE. Creo que merece la pena seguir trabajando con esta tecnología, ya sea en plataformas móviles o en cualquier otro tipo de dispositivo; es una tecnología con mucho futuro y aún estamos muy lejos de llegar a ver su verdadero potencial. Por último, tengo muchas ganas de continuar mi trabajo en Aerlink. Sé que hay mucha 47 gente que ha elegido Aerlink como la forma principal de conexión con su smartwatch y sé que hay muchas más funcionalidades en las que se pueden trabajar para mejorar, aún más, el funcionamiento de este con un dispositivo iOS. Creo que el tracking de actividad física y salud puede generar mucho interés en los usuarios, así que, aprovechando que muchos relojes Wear OS en la actualidad vienen con un sensor de ritmo cardíaco y podómetro, el siguiente paso para Aerlink será conseguir obtener información de estos sensores y sincronizarlos con la aplicación Salud en el dispositivo iOS. 48 [19] Android Developers. Documentation, . URL https://developer.android.com/docs. 55