Кодинг для умных часов. Знакомимся с Tizen SDK и превозмогаем его подводные камни

Ты только раб, Neo

Мы поз­накомим­ся с уни­вер­саль­ными прин­ципами соз­дания прог­рамм для часов на прак­тичес­ком при­мере гад­жета Samsung Gear 2. Я экспе­римен­тировал с моделью Neo, а к све­жей вер­сии Gear S с изог­нутым дис­пле­ем ком­пания Samsung при­уро­чила выпуск в октябре дорабо­тан­ного Tizen SDK for Wearable 1.0.0, которым наконец‑то ста­ло удоб­но поль­зовать­ся.

Ум­ные часы при­меня­ются как замени­тель смар­тфо­на или, ско­рее, допол­нение к нему, которое всег­да под рукой: на них удоб­но украдкой прос­матри­вать опо­веще­ния, быс­тро отве­чать на вхо­дящие, отда­вать голосо­вые коман­ды, отсле­живать свое физичес­кое сос­тояние, играть и даже исполь­зовать по пря­мому наз­начению (ты навер­няка час­то вытас­кива­ешь свой смар­тфон, что­бы прос­то узнать вре­мя). Глав­ный же минус, пока огра­ничи­вающий этот рынок, — мно­жес­тво мел­ких недоче­тов, как тех­ничес­ких, так и орга­низа­цион­ных, при­сущих сегод­ня фак­тичес­ки всем моделям smart watches. Даже с точ­ки зре­ния конеч­ного поль­зовате­ля уста­нов­ка прог­раммы (вид­жета) на часы — про­цесс нет­риви­аль­ный. В качес­тве при­мера отме­чу, что мой «серый» смар­тфон Samsung S4 с часами вооб­ще не зарабо­тал (судя по все­му, кри­вова­то реали­зован Bluetooth 4), а закон­некти­лись часы толь­ко с «род­ным» S4 mini.

Программная архитектура умных часов

Ти­пич­ная прог­рамма для Neo пред­став­ляет собой клас­сичес­кий APK-файл для Android, уста­нав­лива­емый на кон­крет­ном смар­тфо­не (хост). Вид­жет, реали­зующий прог­рам­мную логику на часах, исходно скрыт внут­ри это­го фай­ла. На хос­те дол­жна быть инстал­лирова­на прог­рамма Gear Manager, управля­ющая вид­жетами на часах через Bluetooth. Сам вид­жет работа­ет под управле­нием сер­виса Wearable Manager Service в ОС Tizen (модифи­циро­ван­ный Android). Воз­можна так­же клас­сичес­кая кли­ент‑сер­верная схе­ма, ког­да на хос­те исполня­ется некая уни­вер­саль­ная «сер­верная» прог­рамма, а на часах — вид­жеты, инстал­лиру­емые отдель­но. И тре­тий вари­ант — авто­ном­ный вид­жет, запус­каемый толь­ко на часах и с телефо­ном не вза­имо­дей­ству­ющий. Это могут быть, нап­ример, самые раз­ные игры, укра­шатель­ства, будиль­ники, спор­тивный софт, не тре­бующий обще­ния со смар­тфо­ном, и подоб­ное.

Настраиваем инструментарий программирования

Ког­да APK-файл запус­кает­ся на смар­тфо­не, скры­тый в нем вид­жет авто­мати­чес­ки гру­зит­ся на часы, где про­веря­ется и уста­нав­лива­ется (или по каким‑то при­чинам в уста­нов­ке отка­зыва­ется), о чем сооб­щает Gear Manager на смар­тфо­не. Так как хост — это обыч­ное APK-при­ложе­ние, то раз­работ­ка ведет­ся с исполь­зовани­ем типовых инс­тру­мен­тов для Android. Рекомен­дован­ная сре­да — это, конеч­но, Eclipse, в допол­нение к которой тре­бует­ся уста­новить Tizen SDK for Wearable (SDK и сре­да на базе Eclipse), пос­ледняя вер­сия которо­го, 1.0.0, выш­ла 6 октября. В свою оче­редь, этот SDK тре­бует исполь­зования основно­го Tizen SDK, поэто­му порядок уста­нов­ки все­го ком­плек­са раз­работ­ки на чис­той машине такой: Eclipse, пла­гин ADT, Tizen SDK, Tizen SDK for Wearable.

При уста­нов­ке Tizen SDK тебя будут под­жидать неп­рият­ные сюр­при­зы, свя­зан­ные с нас­трой­ками кон­крет­ной вер­сии Windows. Для их раз­бора при­дет­ся покопать­ся в логе LOCALAPPDATA%\.installmanager\install-log. Отме­чу баг инстал­лятора, который украл у меня нес­коль­ко часов, — сооб­щение Fatal error "Certificate-generator package". Как выяс­нилось из это­го лога, в перемен­ной PATH моей «семер­ки» не был про­писан путь к катало­гу Windows/System32/. А зачем он понадо­бил­ся? Даже если инстал­лиру­ется 64-раз­рядная вер­сия SDK, в про­цес­се уста­нов­ки фай­лы копиру­ются с помощью сис­темной 32-раз­рядной ути­литы XCOPY!

Разбираем пример взаимодействия часов со смартфоном

Офи­циаль­ный ресурс developer.samsung.com/samsung-gear пред­лага­ет четыре при­мера, из которых три, по сути, друг от дру­га не отли­чают­ся: обмен меж­ду часами и смар­тфо­ном стро­кой, дво­ичны­ми дан­ными и фай­лами. Глав­ное тут — понять общую схе­му вза­имо­дей­ствия; мы рас­смот­рим ее клю­чевые момен­ты на при­мере Hello Accessory. В его сос­тав вхо­дят два про­екта: HelloAccessoryProvider (про­ект хост‑при­ложе­ния для Eclipse) и HelloAccessoryConsumer (про­ект вид­жета для Tizen IDE for Wearable). Они импорти­руют­ся в соот­ветс­тву­ющие сре­ды стан­дар­тным спо­собом. Пос­ле заг­рузки про­екта Eclipse, ско­рее все­го, покажет пер­воначаль­ные ошиб­ки, поэто­му в нас­трой­ках Project -> Properties -> Android надо явно задать вер­сию Android SDK (Project Build Target).

Код логики работы хос­та находит­ся в фай­ле HelloAccessoryProviderService.java, а в катало­ге про­екта assets раз­меща­ется встра­иваемый в APK-прог­рамму вид­жет (файл с рас­ширени­ем wgt). Порядок сбор­ки финаль­ного при­ложе­ния будет таким: прог­рамми­руем и отла­жива­ем вид­жет в Tizen IDE for Wearable, затем копиру­ем его в про­ект хос­та в Eclipse и собира­ем окон­чатель­ный про­дукт.

Ло­гика вид­жета прог­рамми­рует­ся типовым спо­собом на HTML5/JavaScript. Она сос­редото­чена в фай­ле main.js. Эле­мен­ты поль­зователь­ско­го интерфей­са опи­сыва­ются обыч­ным HTML-кодом, который хра­нит­ся в фай­ле про­екта index.html. Кро­ме того, в ряде слу­чаев понадо­бит­ся файл config.xml, где, в час­тнос­ти, опи­сыва­ются допус­тимые раз­решения для вид­жета.

Вза­имо­дей­ству­ют хост и вид­жет пос­редс­твом подобия сокет­ной свя­зи, реали­зуемой клас­сом SASocket. В при­мере на сер­верной сто­роне ведет­ся хеш (HashMap) соеди­нений через класс HelloAccessoryProviderConnection (нас­ледник SASocket). У него, в час­тнос­ти, есть стан­дар­тный метод

пе­реда­ющий сокету нуж­ные дан­ные (см. рис. 1), а ответная информа­ция от вид­жета при­нима­ется переза­писы­ваемым обра­бот­чиком

Ло­гика «кли­ент­ской» час­ти ничуть не слож­нее: так­же исполь­зует­ся SASocket, с помощью которо­го вклю­чает­ся слу­шатель соеди­нения

Об­работ­чик

по­луча­ет стро­ку, которую сра­зу и показы­вает на часах в HTML-фор­мате:

От­прав­ка сооб­щения смар­тфо­ну выпол­няет­ся стан­дар­тным методом сокета sendData():

Вот и вся базовая схе­ма вза­имо­дей­ствия смар­тфо­на и часов.

Отлаживаем виджет на часах

От­ладку вид­жета мож­но вес­ти через встро­енный в Tizen SDK for Wearable эму­лятор (см. рис. 3), одна­ко он по сво­ей тор­мозну­тос­ти не слиш­ком отли­чает­ся от эму­лято­ра Android SDK.

По­это­му про­ще все­го открыть файл index.html про­екта вруч­ную в обыч­ном нас­толь­ном бра­узе­ре — глав­ное, дер­жать в уме при­мер­ные гра­ницы изоб­ражения. Кро­ме того, далеко не всег­да удоб­на офи­циаль­ная схе­ма инстал­ляции вид­жета на телефон: в иде­але желатель­но пос­тоян­но сле­дить, как работа­ет вид­жет на реаль­ном устрой­стве. Обой­ти эти незада­чи поможет ути­лита Smart Development Bridge (SDB), рас­положен­ная в катало­ге tizen-wearable-sdk\tools\.

Ус­танов­ка вид­жета на часы, под­клю­чен­ные к компь­юте­ру через USB, выпол­няет­ся прос­той коман­дой

SDB содер­жит мно­жес­тво фич: тут и одновре­мен­ная прос­лушка нес­коль­ких устрой­ств, и уда­лен­ное выпол­нение команд, переда­ча фай­лов, ана­лиз логов, нас­трой­ка рутово­го дос­тупа и дру­гое.

Гладко было при отладке, да забыли про сертификаты

Все было бы прек­расно, ведь APK-файл, соб­ранный из эта­лон­ного при­мера, запус­кает­ся на часах нор­маль­но и обме­нива­ется сооб­щени­ями со смар­тфо­ном, одна­ко при попыт­ке переком­пилиро­вать вид­жет и пересоб­рать хост‑про­ект уже с новым ори­гиналь­ным кли­ент­ским wgt-фай­лом Gear Manager в уста­нов­ке прог­рам­мки на часы отка­жет (PRIVILEGE_LEVEL_VIOLATION). Проб­лема кро­ется в нас­тро­ечном фай­ле вид­жета config.xtm, в час­тнос­ти вот в этой стро­ке:

Эту строч­ку мож­но уда­лить (см. рис. 4), пос­ле чего пересоб­ранный вид­жет успешно уста­новит­ся на часы.

Од­нако теперь он по понят­ным при­чинам не смо­жет уста­нав­ливать соеди­нение с телефо­ном, а будет работать толь­ко как авто­ном­ное при­ложе­ние.

Доламываем часы по-доброму

Samsung Gear лома­ют активно и успешно: на них без осо­бых проб­лем запус­кает­ся мно­жес­тво APK-при­ложе­ний, от MX Player до Candy Crush, и даже ста­вит­ся сто­ковая Android 4.2.2. Но самое вкус­ное, конеч­но, — это орга­низа­ция вза­имо­дей­ствия часов с внеш­ним гад­жетом. Тут два проб­лемных момен­та: во‑пер­вых, воз­можность тес­товой сбор­ки толь­ко под кон­крет­ный гад­жет, во‑вто­рых, уто­митель­ный про­цесс сер­тифика­ции сам­сунгом при­ложе­ний (зна­комые говори­ли, что он занима­ет недели, а то и месяцы, хотя, воз­можно, с выходом Gear S ситу­ация изме­нилась в луч­шую сто­рону). Обой­ти их мож­но без каких‑либо хакер­ских манипу­ляций — дос­таточ­но получить раз­решение Samsung на пол­ноцен­ную отладку и тес­тирова­ние прог­рамм на кон­крет­ном физичес­ком устрой­стве. Для это­го надо отпра­вить в Samsung уни­каль­ный иден­тифика­тор часов Device Unique Identifier (DUID, ука­зыва­ется в фай­ле request_certificate.xml) и получить от них сер­тификат register_certificate.xml, который поз­волит запус­кать пол­ноцен­ные при­ложе­ния на одном кон­крет­ном гад­жете.

DUID опре­деля­ется через Connection Explorer на панели Info обо­лоч­ки Tizen IDE for Wearable. Сам зап­рос так­же мож­но отпра­вить непос­редс­твен­но из этой сре­ды: дос­таточ­но щел­кнуть на кноп­ке глав­ного меню Register Certificate и либо сге­нери­ровать новый зап­рос, либо импорти­ровать уже сущес­тву­ющее хра­нили­ще Android keystore для тво­их андро­ид‑прог­рамм. Таким спо­собом пол­ноцен­ный софт для часов впол­не мож­но офи­циаль­но делать под свои инди­виду­аль­ные хакер­ские нуж­ды либо на кон­крет­ный заказ.