Android Wear
«Износ Android» — это версия Android, предназначенная для устройств носимого пользователем, таких как интеллектуальные контрольные значения. В этом разделе приводятся инструкции по установке и настройке средств, необходимых для выполнения разработки, пошаговое пошаговое руководство по созданию первого устройства, а также список примеров, на которые можно ознакомиться для создания собственных приложений для износа.
Начало работы
В этой статье представлены сведения об износе Android, описывается, как установить и настроить компьютер для обеспечения действительной разработки, а также пошаговые инструкции по созданию и запуску первого приложения «износа Android» на эмуляторе или устройстве износа.
Пользовательский интерфейс
Описание элементов управления, относящихся к износу Android, и ссылки на примеры, демонстрирующие использование этих элементов управления.
Функции платформы
Документы в этом разделе охватывают функции, относящиеся к износу Android. Здесь вы найдете раздел, в котором описано, как создать Ватчфаце.
Размеры экрана
Предварительный просмотр и оптимизация пользовательского интерфейса для доступных размеров экрана.
Тестирование и развертывание
Объясняется, как развернуть приложение «износ Android» на устройстве «износ Android» или в эмуляторе Android, настроенном для износа. в нем также содержатся советы по отладке и сведения о настройке Bluetooth подключения между компьютером разработчика и устройством Android.
API-интерфейсы износа
Сайт для разработчиков Android предоставляет подробные сведения об основных API-интерфейсах износа, такихкак действия носимого пользователем, намерения, Проверка подлинности, сложности, визуализация, уведомления, представленияи ватчфаце.
Примеры
| Образец | Описание | Снимок экрана |
|---|---|---|
| скелетонвеар | Простой пример основ проектов носимого пользователем, включая Гридвиевпажер и интерактивные уведомления. |  |
| ватчвиевстуб | Простая демонстрация элемента управления Ватчвиевстуб, который обнаруживает форму экрана и автоматически загружает правильный макет. Узнайте, как работает Ватчвиевстуб в макете » ресурсы/макет/main_activity.xml «. |  |
| реЦипеассистант | Демонстрация страниц с нестандартными уведомлениями в виде шагов рецепта. Уведомления создаются в РеЦипесервице. cs. |  |
| елизачат | Забавный пример взаимодействия с «личным помощником», именуемый Елиза, с использованием стандартных интерактивных уведомлений для создания диалога с использованием предустановленных ответов. |  |
| GridViewPager | Гридвиевпажер реализует плоский навигационный шаблон, где пользователь выполняет вертикальное перемещение, а затем по горизонтали для навигации по параметрам и содержимому. |  |
| WatchFace | Ватчфаце — это пользовательское лицо с контрольными данными с использованием часов, минут и секунд с аналоговым стилем. В этом примере показано, как создать службу отслеживания лиц, которая рисует текущее время и обрабатывает события изменения внешнего режима и видимости. Он включает широковещательный приемник, который прослушивает изменения часового пояса и автоматически обновляет соответствующее время. | |
Видео
Ознакомьтесь с этими видеоматериалами, посвященными Xamarin. Android с поддержкой износа:
Использование Intel HAXM при разработке приложений для Android Wear и TV
Предварительные сведения
Intel Hardware Accelerated Execution Manager (HAXM) – это Android-эмулятор, который поддерживает аппаратную виртуализацию. Он создаёт невысокую нагрузку на систему, обладает отличной производительностью и быстрым интерфейсом.
Используя Intel HAXM, можно запустить несколько экземпляров Android-эмулятора на одном компьютере, не особо беспокоясь о производительности, о нагрузке на систему или о «тормозах» интерфейса. Подобный подход может быть весьма полезным в итеративном процессе создания и тестирования приложений, он способен дать огромный прирост производительности труда разработчиков.
Образы Android-эмуляторов, рассчитанные на архитектуры, отличные от x86, могут медленно запускаться и с задержкой откликаться на команды пользователя. Кроме того, в отличие от некоторых Android-эмуляторов сторонних производителей, с помощью Intel HAXM вы получаете возможность работать с последними версиями API и платформ Android сразу же после их выпуска.
Здесь вы можете найти подробное руководство по работе с HAXM.
В этом материале мы поговорим о том, как пользоваться возможностями Intel HAXM при создании приложений, рассчитанных на всевозможные варианты платформы Android. Такие приложения могут работать на обычных смартфонах разных форм-факторов, и на устройствах, несущих на борту Android Wear и Android TV.
Работа с универсальным приложением-примером для Android
Компания Google недавно выпустила приложение, на примере которого показано, как охватить одной кодовой базой множество различных Android-устройств.
В примере продемонстрированы передовые подходы к разработке универсальных приложений. Для сборки проекта воспользуйтесь инструкциями, которые можно найти по вышеупомянутой ссылке. Мы, в данном практическом руководстве, будем испытывать пример на x86 HAXM-эмуляторах Android TV, Wear и смартфона.
Проект можно импортировать в Android Studio и воспользоваться возможностями этой среды по сборке и запуску приложения на эмуляторе. Если вы предпочитаете работать с другой IDE, то, о чём пойдёт речь дальше, так же окажется полезным.
Если вам близок интерфейс командной строки, можете просто запустить Gradle-скрипт для сборки приложения из папки с исходным кодом примера.
Результирующий APK-файл можно найти в папке «mobile/build/outputs/apk/mobile-debug.apk».
Создание AVD для Android TV и Wear
Для начала нужно удостовериться в том, что у нас имеются самые свежие образы эмуляторов для платформ Android TV, Wear, а так же – для обычных смартфонов.
Откроем Android SDK Manager. Его можно запустить из интерфейса Android Studio или из командной строки (папка /tools должна быть указана в переменных среды) с помощью такой команды:
Окно Android SDK Manager. Образы систем, которые нужно загрузить, выделены
После того, как необходимые пакеты загружены, нужно, для использования соответствующих образов систем, настроить конфигурации эмуляторов (то есть, создать набор AVD). Для этого нам понадобится Android Virtual Device Manager. Запустим его из командной строки:
Окно Android Virtual Device Manager, здесь можно создавать новые AVD и настраивать существующие
Эмуляция Android Wear
Создадим конфигурацию виртуального устройства для Android Wear так, как показано на рисунке ниже.
Настройка конфигурации эмулятора для Android Wear
После того, как настройки выполнены, нажмём кнопку OK, после чего – запустим эмулятор. Для этого его нужно выделить в окне AVD Manager и нажать на кнопку Start. Вот как выглядит окно эмулятора.
Окно эмулятора Android Wear
Для того чтобы смартфон мог взаимодействовать с устройством, работающим под управлением Android Wear (или с соответствующим эмулятором), нужно дополнительное приложение. Единственный способ установить это приложение на устройство – загрузка из Магазина Google Play. Соответственно, нам понадобится Android-смартфон, который имеет доступ к Магазину.
Устройство должно быть доступно для ADB. Для того чтобы оно смогло подключиться к эмулятору, нужно, чтобы и смартфон, и эмулятор, присутствовали в списке устройств, который можно получить следующей командой:
Список подключенных устройств
Теперь перенаправим TCP-порты такой командой:
Теперь всё готово для сопряжения эмулятора Android Wear и аппаратного устройства. Осталось лишь запустить на смартфоне приложение Android Wear, и, из его меню, выполнить команду подключения к эмулятору. Если подключение удалось, экран эмулятора будет выглядеть так, как показано в левой части рисунка. В правой части показан экран эмулятора, не подключенного к смартфону.
Экраны эмулятора Android Wear в подключенном (слева) и неподключенном (справа) состоянии
Подробные сведения о создании приложений для Android Wear можно найти здесь. APK-файл тестового приложения ничем не отличается от других APK, его можно установить на эмулятор Android Wear с использованием ADB.
Проверить, установлено ли приложение на эмуляторе, можно с помощью такой команды:
Установка приложения на эмулятор и проверка установки
Имя пакета приложения-примера (com.example.android.uamp) присутствует в списке. Из командной строки можно и запустить приложение:
Теперь приложение запущено на эмуляторе Android Wear
Эмуляция Android TV
Создадим конфигурацию виртуального устройства для Android TV так, как показано на рисунке ниже.
Настройка конфигурации эмулятора для Android TV
После настройки нажмём на кнопку OK и запустим эмулятор кнопкой Start в окне ADV Manager.
Проверить доступность эмулятора для ADB можно такой командой:
Запишите или запомните идентификатор эмулятора (что-то вроде emulator-55xx). Он понадобится для указания целевого устройства при работе с эмулятором с помощью ADB. Для установки приложения на эмулятор можно воспользоваться такой командой:
Запустить приложение на эмуляторе Android TV можно так:
Вот как приложение выглядит на экране эмулятора.
Приложение, запущенное на эмуляторе Android TV
Создание и запуск необходимого количества экземпляров эмуляторов
Если в ходе разработки и тестирования приложения возникает необходимость создания и запуска нескольких экземпляров эмуляторов – всё это достижимо с использованием Intel HAXM. При установке HAXM можно настроить размер оперативной памяти, который отводится для его работы. Вот набор конфигураций AVD для Android Wear, TV и смартфона.
Список виртуальных устройств Android
Ниже вы можете видеть приложение-пример, запущенное одновременно на трёх виртуальных устройствах (Android TV, Wear и эмулятор смартфона). Здесь же показаны сведения об использовании CPU. Как видно, все эти экземпляры эмулятора не создают чрезмерной нагрузки на систему.
Три одновременно запущенных эмулятора и сведения о нагрузке на систему, которую они создают
В ходе работы можно настраивать выделение памяти для эмуляторов, оптимизируя потребление ими системных ресурсов. Для того, чтобы перенастроить параметры выделения памяти, заданные при установке HAXM, нужно повторно запустить его установку и указать нужные параметры.
Опыт разработки под Android Wear
Спешу поделиться с коллегами накопленным опытом при разработке для Android Wear.
Все важные моменты проще всего показать на примере приложения, которое показывает уровень заряда батареи на часах и смартфоне.
Загрузим Android Studio.
Создадим новый проект:
Выбираем оба устройства:
Далее все стандартно:
В итоге получим хорошую заготовку для обоих устройств, с пустыми активностями:
ListenerService сам не появится, ниже расскажу как его добавить.
Чтобы связать наши устройства, был придуман хитрый слой. Приложения могут обмениваться сообщениями через этот слой. Отправка сообщений должна проходить в отдельном потоке. Очень подробно реализация этой задачи описана здесь.
Вы должны подключиться к GoogleApiClient, потом отправить в отдельном потоке сообщение. В примерах это описано подробно, но я решил вынести всю работу с сообщениями в отдельный сервис и получилось довольно компактно.
Вот наш ListenerService, он одинаков для обоих частей проекта.
В оба манифеста нужно его добавить:
Во время создания сервиса, мы собираем GoogleApiClient и подключаемся к слою данных.
Событие onMessageReceived вызывается при получении сообщения. У полученного события (MessageEvent) мы смотрим папку назначения (getPath()). Если это наша папка, получаем данные (messageEvent.getData()). Далее эти данные можно сохранить в настройки, базу данных. В общем, использовать как будет нужно. А мы с помощью LocalBroadcastManager отправим их в нашу основную программу (MainActivity). Но для этого локальный приёмник в ней нужно зарегистрировать. Мы это будем делать при старте, а разрегистрировать будем при выходе.
Для отправки сообщения другому устройству мы будем запускать сервис с нужными данными.
В сервисе может быть уже подключен GoogleApiClient, а может и не быть. Если он ещё не подключен, то нужно запустить blockingConnect, иными словами заставить его подключиться напрямую, блокируя соединение. Делать все это нужно в отдельном потоке, т.к. работает это все асинхронно.
Вот код MainActivity для мобильного устройства:
Тут мы при старте создаем приемник, получающий сообщения о батареи устройства. Как только получили сообщение (onReceive), отправляем его сообщением в слой данных (sendMessage) и обновляем значения переменных (updateUI). Далее регистрируем локальный приемник (MessageReceiver), он при приеме также обновит экран приложения (updateUI).
Вот код MainActivity для wear-устройства, т.е. для часов:
Он, в принципе, похож на старшего брата, но есть отличия в постройке разметки, т.к. устройства могут быть с квадратными и круглыми экранами. Компонент WatchViewStub дает нам возможность упростить выбор разметки, для этого нужно просто спроектировать 2 файла rect_activity_main.xml и round_activity_main.xml.
При публикации приложения в гугл маркете у обоих модулей должен быть одинакова версия (versionCode) кода и одинаковое имя пакета. По умолчанию Android Studio эту работу за нас сделает. Когда соберем apk файл для мобильного устройства, внутри него будет находиться apk для wear. Эту работу можно сделать и в Eclipse. В общем, кому как проще. При установке приложения из маркета на мобильное устройство придет толстый apk, который сам установит apk для wear устройства.
Она вам не Android. Особенности разработки под Wear OS
18 марта Google переименовала операционную систему для носимой электроники Android Wear и начала распространять её под именем Wear OS, чтобы привлечь новую аудиторию. Компания опубликовала новые дизайн-гайдлайны и обновила документацию. Когда я начал разработку приложения для часов, не нашел ни одной русскоязычной публикации на эту тему. Поэтому хочу поделиться своим опытом и рассказать подробнее про Wear OS, из чего она состоит и как с ней работать. Всех небезразличных к мобильным технологиям прошу под кат.
Начиная с версии Android Wear 2.0, система научилась работать с «Standalone Apps» – полностью независимыми wearable-приложениями. Пользователь может установить их с нативного Google Play прямо на часы. Wear OS – это практически независимая система, которая всё ещё продолжает работать в рамках инфраструктуры Google Services, дополняя её, но не привязываясь к ней.
Android, но не очень
Как бы Google ни позиционировала Wear OS, платформа основана на Android со всеми его особенностями, прелестями и недостатками. Поэтому, если вы уже знакомы с Android-разработкой, то сложностей с Wear OS возникнуть не должно. Wear OS почти не отличается от своего «старшего брата», за исключением отсутствия некоторых пакетов:
Да, браузер на часах мы в ближайшее время не сможем увидеть из-за отсутствия Webkit. Но серфить на часах будет всё равно неудобно. У нас по-прежнему есть великий и ужасный Android Framework с Support Library и Google Services. Структурных и архитектурных отличий тоже будет мало.
Структура приложения
Предположим, мы решили сделать wearable-приложение. Открыли Android Studio, нажали «New project» и поставили галочку напротив «Wear». Мы сразу обнаружим, что в пакете нашего приложения появилось два модуля: wear и mobile.
Clean architecture?
А почему бы и нет? Это такое же Android-приложение, поэтому архитектурные подходы для него могут быть схожие с Android.
Я использовал такой же стек технологий, который мы используем в Android-приложениях:
У нас два модуля в проекте, и модели данных, скорее всего, будут одинаковые для обеих платформ. Поэтому часть логики и моделей можно вынести в ещё один модуль «common». Затем подключить его к mobile и wearable пакетам, чтобы не дублировать код.
Одна из главных особенностей Android-разработки – обилие девайсов разного размера и с разным разрешением экрана. В Wear OS, ещё и разная форма экрана: круглый, квадратный и круглый с обрезанным краем.
Если мы попробуем сверстать какой-либо лейаут и отобразить его на разных экранах, скорее всего, увидим примерно такой вот кошмар:
Во второй версии системы Google любезно решила часть UI-проблем, включив в Support wearable library новые адаптивные view-компоненты. Пробежимся по самым любопытным из них.
BoxInsetLayout
BoxInsetLayout – это FrameLayout, который умеет адаптировать дочерние элементы под круглый дисплей. Он помещает их в прямоугольную область, вписанную в окружность экрана. Для квадратных дисплеев подобные преобразования, само собой, игнорируются.
Таким образом, одна и та же верстка будет примерно одинаково выглядеть для всех форм экранов часов.
Выглядит лучше, не правда ли?
WearableRecyclerView
Списки – удобный паттерн, который активно используется в мобильном (и не только) UX. Wear-интерфейсы исключением не стали. Но из-за закругления углов дисплея верхние View у списка могут обрезаться. WearableRecyclerView помогает исправить такие недоразумения.
Например, есть параметр isEdgeItemsCenteringEnabled, который позволяет задать компоновку элементов по изгибу экрана и расширять центральный элемент, делает список более удобным для чтения на маленьком экране.
Есть WearableLinearLayoutManager, который позволяет прокручивать список механическим колесиком на часах и доскроливать крайние элементы до середины экрана, что очень удобно на круглых интерфейсах.
Сейчас библиотека поддержки Wear включает пару десятков адаптивных View. Они все разные, и обо всех можно подробно почитать в документации.
Рисовать данные на экране – весело, но эти данные нужно откуда-то получать. В случае мобильного клиента, мы чаще используем REST API поверх привычных всем сетевых протоколов (HTTP/TCP). В Wear OS подобный подход тоже допустим, но Google его не рекомендует.
В носимой электронике большую роль играет энергоэффективность. А активное интернет-соединение будет быстро сажать батарею, и могут регулярно происходить разрывы связи. Ещё носимые устройства предполагают активную синхронизацию, которую тоже нужно реализовывать.
Все эти проблемы за нас любезно решает механизм обмена данными в Google Services под названием «Data Layer». Классы для работы с ним нашли свое место в пакете com.google.android.gms.wearable.
Data Layer
Data Layer помогает синхронизировать данные между всеми носимыми устройствами, привязанными к одному Google аккаунта пользователя. Он выбирает наиболее оптимальный маршрут для обмена данными (bluetooth, network) и реализует стабильную передачу. Это гарантирует, что сообщение дойдет до нужного девайса.
Data Layer состоит из пяти основных элементов:
Data Item
Data Item – компонент, который предназначен для синхронизации небольших объемов данных между устройствами в wearable-инфраструктуре. Работать с ними можно через Data Client. Вся синхронизация реализуется через Google сервисы.
DataItem состоит из трёх частей:
Давайте попробуем создать и сохранить DataItem. Для этого воспользуемся PutDataRequest, которому передадим все нужные параметры. Затем PutDataRequest скормим DataClient’у в метод putDataItem().
Для удобства есть DataMapItem, в котором уже решена проблема сериализации. С его помощью мы можем работать с данными, как с Bundle-объектом, в который можно сохранять примитивы.
Теперь наш DataItem хранится в DataClient’е, и мы можем получить к нему доступ со всех Wearable-девайсов.
Теперь мы можем забрать у DataClient список всех Item’ов, найти тот, который нас интересует, и распарсить его:
Assets
А теперь давайте представим, что нам внезапно потребовалось отправить на часы фотографию, аудио или еще какой-то файл. DataItem с такой нагрузкой не справится, потому как предназначен для быстрой синхронизации, а вот Asset может. Механизм синхронизации ассетов предназначен для сохранения файлов размером более 100kb в wearable-инфраструктуре и плотно связан с DataClient’ом.
Как упоминалось ранее, DataItem может иметь ссылку на Asset, но сами данные сохраняются отдельно. Возможен сценарий, когда Item сохранился быстрее Asset, а файл всё еще продолжает загружаться.
Создать Asset можно с помощью Asset.createFrom[Uri/Bytes/Ref/Fd], после чего передать его в DataItem:
Чтобы загрузить Asset на другой стороне, нужно открыть inputStream, получить сам массив байт, а затем представить его в нужной нам форме:
Capabilities
Сеть носимых девайсов может быть гораздо шире, чем два устройства, соединенные по Bluetooth, и включать в себя десятки девайсов. Представим ситуацию, когда нужно отправить сообщение не на все устройства, а на какие-то конкретные часы. Нужен способ для идентификации устройств в этой сети. Способ есть – это механизм Capabilities. Смысл его очень прост – любой девайс-участник сети с помощью CapabilitiesClient может узнать, какое множество узлов поддерживает ту или иную функцию, и отправить сообщение именно на один из этих узлов.
Для того чтобы добавить Capabilities в наше wearable-приложение, нужно создать файл res/values/wear.xml и записать туда массив строк, которые и будут обозначать наши Capabilities. Звучит довольно просто. На практике тоже ничего сложного:
wear.xml:
На стороне другого устройства:
Если у вас, как и у меня, развился Rx головного мозга, то от себя порекомендую расширение для объекта Task. Этот объект довольно часто фигурирует во фреймворках от Google (в т.ч. Firebase):
Тогда цепочка для получения Nodes будет выглядеть красивее:
Messages
Все предыдущие компоненты Data Layer предполагали кэширование данных. Message помогает отправлять сообщения без синхронизации в формате «отправили и заб(ы|и)ли». Причем отправить сообщение можно только на конкретный узел или на конкретное множество узлов, которые предварительно необходимо получить через CapabilitiesClient:
Потенциальный получатель сообщения, в свою очередь, должен подписаться на получение сообщений, и найти нужное по его URI:
Channels
Каналы служат для передачи потоковых данных в режиме реального времени без кэширования. Например, если нам нужно отправить голосовое сообщение с часов на телефон, то каналы будут очень удобным инструментом. Клиент для каналов можно получить через Wearable.getChannelClient(), и дальше открыть входной или выходной поток данных (один канал может работать в обе стороны).
Google активно развивает Data Layer, и вполне вероятно, что через полгода эти клиенты снова куда-то «переедут», или их API снова поменяется.
Разумеется, Data Layer – не единственный способ общения с внешним миром, никто не запретит нам по-старинке открыть tcp-socket и разрядить устройство пользователя.
В заключение
Это был всего лишь краткий обзор актульных технических возможностей платформы. Wear OS быстро развивается. Устройств становится больше, и возможно, скоро это будут не только часы. Support Wearable Library тоже не стоит на месте и меняется вместе с платформой, радуя нас новыми UI-компонентами и чудесами синхронизации.
Как и у любой другой системы, тут есть свои тонкости и интересные моменты, о которых можно говорить долго. Многие детали остались раскрыты не полностью, поэтому пишите в комментариях, о чем хочется поговорить подробнее, и мы расскажем об этом в следующей статье. Делитесь своим опытом wearable-разработки в комментариях.