Android搭載のスマートウォッチ向け、自分の好きな画像を文字盤に設定することのできるアプリがカスタムフォトウォッチです。
アプリ実行に必要なもの Android搭載のスマートウォッチ スマートウォッチとペアリングしたAndroidのスマホ（今のところiPhone対応の予定はありません） スマートウォッチのウォッチフェイスをカスタマイズするアプリなので、スマートウォッチがないと意味をなしません。スマホだけでは単なる画像編集アプリのような何かにしかならないのでご注意を。
Android搭載スマートウォッチはiPhoneともペアリングして使えますが、今のところこのアプリはiOSには対応していません。
カスタムフォトウォッチはスマホとスマートウォッチの両方にインストールする必要があります。
以前のバージョンであればスマホからインストールすれば、ペアリングしているスマートウォッチにもアプリが自動的にインストールされていましたが、Ver2からはそれぞれ個別にインストールが必要になっていますのでご注意ください。
実行に必要なソフトウェア GooglePlay開発者サービス Wear OS by Google（スマホとスマートウォッチのペアリングを行うアプリ） これらはスマートウォッチとスマホとの間の通信処理を行うために必要となっています。インストールされていてもバージョンが古い場合にアプリがうまく動作しないおそれがあります。バージョンが古い場合はアプリから更新を促すメッセージが表示されると思うので、各アプリの更新をお願いします。
メッセージを無視しても使うことはできると思いますが、スマホから設定した画像がスマートウォッチに表示されないなど、データの同期がうまくいかないおそれがありますのでご注意ください。
使い方 スマホ側 まずは画像を追加しましょう。右下のプラスボタンを押せば画像を追加できます。
スマホ側からスマートウォッチに設定したい画像を取り込み、文字盤に表示する時刻や日付などの情報を設定します。スマホに保存されている画像データや、カメラからその場で撮影した画像などを取り込むことができます。
中央に表示されている枠がスマートウォッチの文字盤に設定される範囲になります。拡大・縮小などで位置を調整してみてください。拡大・縮小の他回転（90度単位ですが）や反転もサポートしています。位置が決まったら切り取りをおこなってください。
このアプリでは時刻の表示位置などを細かくカスタマイズできるので、画像に合わせて最適な位置に調整していただけます。
以上の手順で画像データを用意すれば自動的にスマートウォッチに同期されます。
スマートウォッチ側 まずはウォッチフェイスにカスタムフォトウォッチを設定してください。スマートウォッチの文字盤で左右にスワイプするとウォッチフェイスの変更ができると思います。そこからカスタムフォトウォッチを選択してください。
スマホから設定した画像に切り替えるには、設定ページを開いてください。カスタムフォトウォッチをウォッチフェイスに設定した状態で、スマートウォッチの画面を長押しすれば開くと思います。
もしくはウォッチフェイス選択画面でカスタムフォトウォッチの下に歯車アイコンが表示されるので、それを押すと設定画面が開きます。
設定画面を開くとスマホで設定した画像が一覧で表示されます。切り替えたい画像を選んでもらえばスマートウォッチの文字盤が設定した画像に切り替わります。
以前までのバージョンでは、スマホで画像を設定したら自動的にその画像に切り替わっていましたが、Ver2からはスマートウォッチで切り替えるようになりました。
FAQ スマホで作成したデータがスマートウォッチにない 同期メニューを実行していただくことで改善する可能性があります。同期メニューはスマホ側のアプリの右上メニューからアクセスできます。
同期メニューを実行しても反映されない場合、以下の可能性が考えられます。
Google Play開発者サービスのバージョンが古い・インストールされていない スマートウォッチ・もしくはスマホ側のアプリが古い スマホおよびスマートウォッチそれぞれでGoogle Play Storeにアクセスして、アプリの更新がないか確認をお願いします。
削除したはずのデータがスマートウォッチ側に残っている 同じく上記の同期メニューの実行で改善されると思います。
スマートウォッチの画像が真っ暗になる・時刻しか表示されない 以前のバージョンからアップデートを行った場合に発生する場合があります。
基本的にはスマホから同期のメニューを実行していただいた後に、スマートウォッチ側の設定画面（画面長押し、もしくはウォッチフェイス選択画面の歯車アイコンをタップ）を開いて画像を選択していただければ改善されると思います。
設定画面すら開けない場合、一度スマートウォッチ側のカスタムフォトウォッチをアンインストールしていただき、再度インストールし直していただくと改善するかと思います。
サポート窓口 ストアページに記載しているメールアドレスまでご連絡ください。
https://play.google.com/store/apps/details?id=jp.gcreate.product.customphotowatch
リアルタイムで心拍数を計測・表示するAndroid Wearアプリをリリースしました。
特徴はリアルタイムで心拍数が分かること、Wear端末で計測した心拍数がそのままスマホに表示可能な機能があることです。
アプリはGoogle Playで公開中です。
開発の動機 運動不足解消とダイエットのために、室内でフィットネスバイクを漕いでいたのですが、あまり効果が現れませんでした。そんな中、ダイエット目的の運動は心拍数を元に運動すると効率がいいという情報を目にしました。
心拍数がだいたい40％〜60％くらいになるように運動すると、脂肪燃焼の効率がいいらしいです。
そこでAndroid Wearを使って心拍数を確認しながら運動することを考え、開発を開始しました。
しかし運動中にいちいち腕時計の画面を確認しないといけないのはちょっと面倒です。特に私はスマホでAbemaTVを見ながら運動していました。心拍数を確認するのに手元に視線を動かすことは、運動から気がそれるだけでなく、番組からも目を離すことになってしまいます。
どうせスマホの画面を見ているのだから、画面の右隅にでも計測中の心拍が表示されればいいのに。そんな思いからこのアプリが誕生しました。
スマホへのオーバーレイ表示 こんな感じで画面の右上に半透明で心拍数が表示されます。
YouTubeなどで動画を見ながらでも心拍数を確認できます。今はやりのポケモンGOをやりながらでも確認できます。（ただポケモンGOだと心拍数をコントロールするような運動はしないでしょうけど）
心拍の推移を記録 このアプリは心拍数をリアルタイムで表示するだけでなく、その推移を記録します。これはWear端末のみで運動した場合でも記録できます。
例えばWear端末のみを装着してジョギングを行う→家に帰ってスマホでジョギング中の心拍数の変化を振り返る、といった使い方ができます。
使い方 Android Wearのアプリ一覧からこのアプリを起動すれば心拍数の計測が始まります。
スマホ側にも起動ボタンを用意しているので、そちらからも起動できます。
起動・終了ともに、スマホとWearが通信可能な状態なら、スマホ側で起動すればWear側も起動します。終了に関しても同様です。
計測中はWear端末の画面上に心拍数が表示されます。アンビエントモードに対応しているので、バッテリーに配慮した作りになっています。
スマホに心拍数を表示するよう権限を許可していれば、心拍計測が始まれば自動的にスマホ側にも心拍数が表示されるようになっています
計測を終了するには、Wear端末上のアプリ画面で右に向かってスワイプします。スマホで計測終了ボタンを押してもOKです。
計測したデータはログとしてスマホで後から確認することができます。ただし、あまりにも長い時間計測をした場合、データがうまく保存できない可能性があります。2〜3時間は大丈夫だと思いますが、端末の性能やセンサーの精度などにも影響されるので一概には言えません。
必要な権限について ボディセンサー 他のアプリに重ねて表示 端末スリープの無効化 ネットワークアクセス関連 最初2つに関しては、お使いの端末がAndroid 6.0以上の場合には、実行時に許可するかどうかを選択できます。
ボディセンサー Android Wear端末で心拍数を読み取るために必須です。この権限を許可しない場合このアプリは動作しません。
他のアプリに重ねて表示 スマホ側で心拍数を確認するオーバーレイ表示を行うために必要です。この権限は許可しなくても心拍数の計測はできます。
権限を許可しない場合はオーバーレイ表示ができないので、スマホで心拍数を確認できなくなります。
端末スリープの無効化 Android Wearのアンビエントモードに対応しているため、端末スリープを無効化する表示が出ています。実際にはちゃんとスリープします。
ネットワークアクセス関連 広告の表示や、アプリの機能改善のためのアクセス解析、クラッシュログ送信サービス利用のために必要となっています。
個人情報の取得・送信は行っていません。
どのようなデータが送信され、どう取り扱われるかについてはプライバシーポリシーをご覧ください。
精度について 計測精度は目安程度に思ってもらったほうが良いかもしれません。
腕時計のセンサーで計測するわけなので、センサーが皮膚としっかり密着していないと正しい数値が出ないようです。
具体的に言うと、比較的腕を動かさないですむサイクリングマシーン（フィットネスバイク）による運動だと安定した計測ができているように感じます。汗を拭くのに腕を動かしたりすると数値が極端に下がったりします。
バーベルを使った筋トレ中に計測をしてみましたが、こちらはまったく安定しません。握ったり動かしたりとセンサーと皮膚の間に空間がしょっちゅうできる上に、よほどきつくバンドを締めていないかぎり腕時計がズレます。そのため、心臓がバクバクしてるのが体感で分かるレベルにもかかわらず、心拍数が安静時と同じ数値を示したりしていました。
とはいえ、スマホで動画を見ながらのながら運動に最適だと思います。ぜひ使ってみて感想をお聞かせください。
アプリはGoogle Playで公開中です。
Android Wearのアプリを作成する際には、パッケージ名をスマホ側と同じにしなければなりません。
新規プロジェクトで初めからWear用のアプリも含めて開発する際は関係ない話です。Android Studioの新規プロジェクトウィザードでターゲットにWearを追加するだけなので、両者のパッケージ名を別のものにしようと思ってもできません。
気をつけなければならないのは、スマホ用のアプリを作成していて、途中からWear用のモジュールを追加する場合です。「Wear用のモジュールだからパッケージ名変えたほうがいいかな」なんて気を利かせると逆にハマります（私のように）。
（ちなみにここで言っているパッケージ名は、アプリのパッケージ名のことです）
開発時はWear用のモジュールを実行、スマホ用のモジュールを実行という感じでアプリをインストールして実行できるので問題に気づきにくいのですが、Wearとスマホで通信を行おうとした際にハマります。
具体的にはCapability APIを使って通信可能なノードを取得する際に、パッケージ名が違うとそのノードが取得できません。
https://stackoverflow.com/questions/35136881/cant-detect-node-using-the-capability-api
Capability APIはWearからの要求に応答可能なデバイスを探すための仕組みです。例えば自分で 「say_helloという要求を行う」と定義しておけば、Wearからメッセージを送信する際にsay_helloが定義されているデバイスだけを、Capability APIを使うことによって取得することが出来るのです。しかし、それはパッケージ名が同じアプリであればの話です。
ちなみにNode APIを使えばパッケージ名が異なっていようが関係なく、ペアリングされているノードが取得できます。パッケージ名が異なると接続されているノードが取得できないのはCapability APIを使った場合の話のようです。
Wearアプリを作成する場合、パッケージ名を変えることは基本的にはないと思いますが、Wearのパッケージ名とスマホのパッケージ名を異なるものにすると弊害があるぞというお話でした。特に後からWear用のパッケージを追加するときには気をつけましょう。
Android WearデバイスをBluetooth経由でデバッグする方法について。
Android WearもUSB経由でパソコンに接続してデバッグする方が何かと便利です。ですが、USB経由で接続しようと思うと、Wearデバイスに直接USBケーブルをつなぐタイプのものなら問題無いでしょうが、クレードル経由で接続するタイプの製品だと腕につけた状態でデバッグできません。
そんなときはBluetooth経由でデバッグすると便利です。
https://developer.android.com/training/wearables/apps/bt-debugging.html
Android Wearでの事前準備 Bluetooth経由でのデバッグを有効化しておく必要があります。
まず設定→端末情報→ビルド番号を7回タップして開発者オプションを有効にします。
すると開発者オプションを選択できるようになるので、そこからADBデバッグとBluetooth経由でデバッグを有効にします。
以上でWear側の事前準備はOK。
スマホ側での事前準備 Android Wearとペアリングしているスマホ側でもBluetooth経由のデバッグを有効化してやる必要があります。
Android Wear companion app（日本語だと単にAndroid Wear）を実行します。Android Wearとのペアリングしたりするアプリです。
使いたいAndroid Wearデバイスとのペアリングした状態で、Appbarにある歯車アイコンを押します。
すると設定画面が開くので、その一番下にあるBluetooth経由のデバッグを有効にしてやります。
ホスト：未接続、ターゲット：接続済みとなっていると思います。
それができたら次のステップ。
パソコンからターミナルで操作 以下のコマンドを実行。
adb forward tcp:4444 localabstract:/adb-hub adb connect localhost:4444 adb connect localhost:4444でConnection Refuesedとなってしまう場合、localhostの部分を127.0.0.1とすれば接続できると思います。
接続できればスマホで「ホスト：未接続」となっていた部分が「ホスト：接続済み」となると思います。
そうすればAndroid StudioからAndroid Wearデバイスが見えるようになっていると思います。
切断 adb disconnect 127.0.0.1:4444 adb forward —remove tcp:4444 ちなみにポートフォワーディングしているかどうかを確認するにはadb forward —listで確認可能。
もっとも、スマホのUSBケーブルを抜くとそのままBluetooth接続も解除されるので、わざわざ上記コマンドを叩いて切断する必要はまったくありません。
注意点 Bluetooth経由のデバッグでも、デバッガでブレークポイントを設定したりステップ実行したりすることができます。ただし、USB経由でのデバッグと比較すると格段に遅いです。
アプリのインストールもBluetooth経由で可能ですが、やっぱりUSBで繋いだ時と比べると遅いです。
ケーブルレスでデバッグできるのは便利なのですが、可能であればUSBで実機をつないでデバッグした方が開発サイクルを早く回すことが出来ると思います。
Bluetooth経由のデバッグは、Wearを腕にはめた状態でないと出来ない動作の確認（センサーを使った動作のデバッグ）などに限定して使ったほうがいいと思います。
ちなみにBluetooth経由のデバッグを有効にした状態で、WearをUSBで直接パソコンにもつないでおくと、WearデバイスはBluetoothで接続したものとUSBで接続したもの2つが見える状態になります。
Android Wearアプリ（WatchFaceも）をGoogle Playで公開するときにbuild.gradleの共通化をやっておいた方がいいと思います。
Android Wearアプリプロジェクトを作成すると、標準ではmobileモジュールとwearモジュールが作成され、それぞれのモジュールにbuild.gradleが作成されます。
Google Playにアプリを公開する場合、build.gradleで指定するversionCodeとversionNameはmobile,wearモジュールで共通にしなければなりません。
初回アップロード時は両方同じ値なので問題ありませんが、アプリをバージョンアップする際に2つのファイルをいじらないといけないのは面倒くさいと思います。（というか絶対に忘れる）
そのためversionCodeなどは、一箇所直せばmobileとwearのどちらにも適用されるようにしてやるといいと思います。
私はmobile,wearのbuild.gradleで共通して利用する部分を、別ファイルにして読み込ませるようにしてみました。
QiitaのAndroidの署名情報(signingConfigs)を外出しようを参考にさせていただきました。
/mobile/buildConfig.gradle
defaultConfig {
applicationId "jp.gcreate.product.customphotowatch" minSdkVersion 18
targetSdkVersion 21 versionCode 3 versionName "1.0.2" } /mobile/build.gradle
apply plugin: "com.android.application" android { apply from: "configBuild.gradle", to: android compileSdkVersion 21 buildToolsVersion "21.1.2" } 〜dependenciesは省略 /wear/build.gradle
apply plugin: "com.android.application" android { apply from: "../mobile/configBuild.gradle", to: android compileSdkVersion 21 buildToolsVersion "21.1.2" defaultConfig{ minSdkVersion 20 }
} 〜dependenciesは省略 上記では省略しましたが、buildTypeも外部ファイルに出して両者で同じ設定が適用されるようにしてます。
やってて未だに不安なのが、ちゃんと正しく設定できているのか、確認の仕方がいまいち分からず不安だということでしょうか・・・。
先日のDroidKaigiで発表のあった、つかえるGradleプロジェクトの作り方のやり方も参考になります。
こちらのスライドでの方法は、versionCode等の値を/build.gradleで定義し、各々のプロジェクトその値を参照することで共通化するやり方です。
こちらのやり方のほうが分かりやすいなぁって発表聞いてて思いました。
ちなみにAndroid Studioではルートのことをプロジェクト、mobileとかwearのことをモジュールと呼びますが、Gradleの世界ではどれもプロジェクトと呼ぶそうです。勉強になりました。
2019/05/18追記: この記事の情報は古いので公式ドキュメントを参照してください。
データのやりとりはWearable.DataApiを使うことでやりとりできます。Wearable.MessageApiを使うことでもできます。
両者の違いはこんな感じ。
DataApi 接続が切れていても送信できる データはonDataChangedで受け取る 送れるデータは100KBまでだが、Assetを使うことで大きいデータも送れる データを送信するというより、DataItemを更新して、その更新を通知するイメージ MessageApi 現在接続中のノードに対してデータを送信することができる データはonMessageReceivedで受け取る データを送る際にはノードを指定する必要がある ノードIDについて 当たり前ですが、ノードIDはAndroid Wear端末とスマホで異なります。
WatchFaceを作成して、その設定画面を用意している場合、WearのノードIDはスマホ側では簡単に取得できます。
mobile側の設定画面となるActivityでgetIntent().getStringExtra(WatchFaceCompanion.EXTRA_PEER_ID)とするとWearのノードIDが取得できます。これは設定画面の起動がAndroid Wearアプリ経由で行われるためです。
一方Wearから、もしくはmobileからでもAndroid Wearアプリを経由しない起動の仕方をするアプリの場合はこの方法では取得できません。
その場合はNodeApi.getConnectedNodesを使うことで、接続されている端末のノードリストを取得することができます。現状スマホとAndroid Wearは1：1でペアリングされるはずなので、これで相手方のノードIDを取得できるでしょう。（将来的に複数ペアリングできるようになったらどうやればいいんでしょうね？）
DataApiを使ったデータ送信の注意点 [DataApi – Android Developers]のConcurrencyにありますが、DataApiを使ったからといってmobileとwearでDataItemが全く同じになるわけではありません。
onDataChanged()内であれば正しいデータが参照できます。これは変更があったDataItemが通知されてきているからです。
しかしAndroid Wear端末を再起動した後に、DataApiを使って送信された設定データを読み込もうとした時に問題が生じます。
wear側からDataItemを識別するUriでデータを取りに行っても、mobile側の設定と齟齬が生じている可能性があります。
その理由はDataItemが以下のように識別されているからです。
wear://ノードID/パス
mobileで作ったDataItemはmobileのノードIDで識別されます。同じパス文字列で識別しているからといって、勝手にwearのノードIDのものが変更されるわけではありません。
これはWatchFaceのサンプルコード（com.example.android.wearable.watchface）を見ると何となく分かると思います。サンプルコードでは、mobileからのDataItemの変更を受け取ると、wear側で同じデータを上書きする処理を行っています。
サンプルのようにmobileからもwearからもデータを送り合うようなアプリの場合、どちらのノードのDataItemも常に同じ状態にするように配慮しないと齟齬が生じて困ることになると思います。
片側からしか送らないというのであれば、ノードIDを指定してDataItemを取りに行くのもありかもしれません。
Android Wearを使っていて、背景画像を自分の好きな画像に設定したいと思ったことはないでしょうか。そんな人にちょうどいいのがこのカスタムフォトウォッチです。
作成のきっかけはデフォルトで設定できるウォッチフェイスの中に、日付と曜日を表示するものがなかったことでした。下にスワイプすれば日付は表示されますが、曜日は出ないしいちいちスワイプするのも面倒くさいので、盤面に常に表示してあるのがほしいなと思ったのです。
今のところデジタル時計だけですが、アナログ形式は要望が多ければ追加するかもしれません。（個人的にアナログは見づらいので優先度低めです）
以下の説明はすべてVer1.0.1のものです。
インストールの仕方 アプリはGoogle Playにて公開中です。
カスタムフォトウォッチを使うためには、Android Wear端末とGoogleのAndroid Wearアプリが別途必要です。どちらが欠けていてもカスタムフォトウォッチは利用できません。
カスタムフォトウォッチをスマホにインストールすると、ペアリングしているAndroid Wear端末にも自動的にカスタムフォトウォッチがインストールされます。（この際、インストールにしばらく時間がかかります）
Android Wear端末にもインストールが完了すると、スマホのAndroid Wearアプリを起動すればウォッチフェイスの中にカスタムフォトウォッチが追加されます。Android Wear端末でウォッチフェイスの変更からカスタムフォトウォッチを設定できますが、基本的な設定はスマホから行います。
カスタムフォトウォッチをウォッチフェイスに設定すると、カスタムフォトウォッチのアイコンに歯車マークが出ます。再度タップするとカスタムフォトウォッチの設定画面が起動します。
ウォッチフェイスの選択画面 カスタムフォトウォッチの設定画面を開くと、最初にこの画面が表示されます。
ここでは壁紙の追加と、既に追加した壁紙への切り替えが行えます。
右下の＋ボタンを押すと次の画像の編集画面に移行します。
追加済みの画像を単にタップすると、ウォッチフェイスの設定（時刻の表示設定）に移行します。長押しするとポップアップメニューが開き、ウォッチフェイスの設定画面を経ることなく画像の切り替えのみを行ったり、不要になった画像の削除ができます。
画像の編集画面 この画面で実際にAndroid Wear端末に転送する画像を作成します。
左下のアイコンを押すことで、スマホ内に保存されている画像を読み込むことができます。SDカードやGoogleドライブにある画像を指定可能です。
カメラのアイコンを押せばその場で写真の撮影を行い、その画像を読み込むこともできます。
Android Wearに表示されるのは中心の明るい部分です。範囲外の部分は切り取られます。
画面内に表示した画像はスワイプすることで移動が、二本指でピンチイン・アウトすることによって縮小・拡大ができますので、Android Wearに表示させたい部分が中心になるように調整してください。
枠は四角と円形の切り替えが可能です。フレーム枠の変更は右上にあるアイコンをタップすることで行えます。（メニューからでも可）
ちなみに枠はあくまで表示確認のためのものであり、枠を円形にしたとしても画像は四角で切り抜かれます。あくまで円形ディスプレイのAndroid Wear端末でどのように表示されるか確認するためのものだとお考えください。
枠の切り替えボタンの隣は、周りの半透明の部分を黒色で塗りつぶすボタンです。Android Wear端末に表示される部分が明確になるので、実際に表示されるとどう見えるのか確認したいときにお使いください。もう一度タップすれば元の半透明に戻ります。
表示位置が決まれば、右下のハサミのアイコンを押してください。画像が切り抜かれ、ウォッチフェイスの設定画面に移行します。
ウォッチフェイスの設定（時刻の表示設定） この画面ではAndroid Wearに表示される時刻や日付の表示設定が行えます。
変更できるのは文字の色、フォント、サイズです。日付に関しては表示形式も変更できます。
画像によっては色だけでは文字の識別が難しいと思います。そのような場合は縁取りを有効化してください。文字が黒で縁どりされるので視認性が向上します。
文字の設定は都度スマホの画面に反映されます。画像と文字の視認性のバランスをとりながら設定することができます。
文字の表示設定が決まればメニューのチェックマークを押せば設定が完了し、画像がAndroid Wear端末に転送されます。（端末のバックキーを押しても同様です）
ただしアプリをインストールした直後やAndroid Wear端末を再起動した後など、スマホで選んだ画像がAndroid Wear端末に転送されないことがあります。その場合、1分程度間を開けてから再度画像の切り替えを行ってみてください。
Google Playにて公開中 カスタムフォトウォッチ
Android Wearでウォッチフェイスを自作するためには、Creating Watch Faces – Android Developersを見て勉強するといいです。
なんかややこしそうな気がするかもしれませんが、そこまで複雑でもないです。Traningにも書いてありますが、Android StudioでWatch Faceのサンプルを取り込んでやると、どういうことやればいいのかわかると思います。
取り込み方はAndroid StudioのFileメニューからImport Samplesを選び、Wearable > Watch Faceを選択すればOKです。
サンプルの実行方法 このサンプルを実行する場合、実行環境にバツ印がついています。これはデフォルトで起動するActivityが設定されていないからです。
そのまま実行しようとすると以下の様な警告メッセージが表示されますが、Continue Anywayを選べばAPKが端末へ転送されます。
毎回このメッセージが表示されるのはうっとおしいので、実行環境設定でDo not launch Activityを選んでおいた方がよいでしょう。
また、WatchFaceの設定画面を作るなど、デフォルトでは起動しないけど用意してあるActivityを起動したい場合は、「launch」を選んで起動させたいActivityを選んでおくと捗ると思います。（そうしないと、APKの転送→Android Wearアプリの起動→該当のWatchFaceを選択→設定画面を起動という手順を踏む必要があって面倒くさい）
ただ、この手法で起動するとgetIntent().getStringExtra(WatchFaceCompanion.EXTRA_PEER_ID);で、ペアリングしている端末のPeerIdを取得しようとしてもnullになってしまうので、PeerId依存の処理が上手くいかないことに注意しましょう。
WatchFaceの動作確認 アプリ（WatchFace）をどうやって端末に転送するのかというと、mobile（サンプルではApplication）とwearモジュールを両方とも実行（デバッグ）してやります。
そうすればWatch Faceが端末に送信されるので、後はスマホもしくはWear端末からWatch Faceの変更をしてやれば動作確認できます。
デバッグ実行はwearとmobile片方ずつやらないといけない リリース用の署名をつけたAPKファイルであれば、mobile側の実行（端末へのインストール）さえ行えば、wear用のAPKがペアリングしている端末へ自動的にインストールされます。（mobile側のAPKの中にwear用のAPKが埋め込まれています）
しかしdebug用のAPKはこの自動転送が働かないので、wear用のAPKはwear用のモジュールを選んで実行しないと端末にインストールされません。
開発にあたっては、スマホ側とWear側両方実行しないといけないので若干面倒くさいです。
サンプルで使われているLog.d()について サンプルでは様々なタイミングでLogにメッセージを流すようになっていますが、そのままではこれを確認することができません。
というのもLogを出力する前にisLoggableでログの出力レベルを設定を確認しているためです。
if (Log.isLoggable(TAG, Log.DEBUG)) { Log.d(TAG, "onConnected: " + connectionHint); } これをLogcatで確認するためには、実行する端末に対してadb shell setprop log.tag.（TAGで指定されている文字列） DEBUGとターミナルから入力してやると、端末のLogcatにログが出力されるようになります。
Android Wearアプリを開発する際にエミュレータを利用する場合の話です。
開発中のアプリを実行してデバッグを行うためには、エミュレータなり実機なりを用意する必要があります。Wearアプリの場合、スマホとWear端末が必要になるため、普通のスマホアプリを開発するより用意するものが多くて面倒なところです。
最も簡単なのはスマホとWear端末共に実機を用意することです。既にペアリングを行った実機があれば、その2つをパソコンにUSB接続すればデバッグできます。特に設定を要しません。
一方で、片側をエミュレータ、もしくは両方をエミュレータでデバッグしたい場合は話がややこしくなります。
エミュレータを利用するにしてもスマホは実機で エミュレータではBluetooth通信まではエミュレートしてくれないので、ポートフォワーディングを利用してスマホ・Wear端末間の通信を再現します。
片方をエミュレータにする場合でも簡単なのはスマホを実機で、Wear端末はエミュレータでやる方法です。
というのもAndroid Wearとのペアリングを行うためには、スマホ側で「Android Wear」というアプリを操作する必要があります。
スマホをエミュレータに置き換えてやろうとすると、このAndroid Wearを使えるようにするのが難しいようなので大変だと思います。どうも直接apkを拾ってきてエミュレータにインストールしないといけないようなので・・・。
Android Wearアプリを開発する場合、基本的にはスマホもWear端末も実機を用意するのがオススメです。実行速度の観点からもそれが一番だと思います。
Android WearのエミュレータはAVDを利用せざるを得ず、上述のポートフォワーディングを利用してペアリングを行ったとしても、端末間の通信は実機に比べるとだいぶタイムラグが生じます。
スマホ実機とWearエミュレータをペアリング パソコンにスマホ実機をUSBで接続し、AVDでWearエミュレータを起動した状態から始めます。
まずターミナルからポートフォワーディングを行うようコマンドを入力します。
adb -d forward tcp:5601 tcp:5601
ポート番号は何でもいいようです。（ただし現在使われていないものでないとダメ）
ちなみに-dはUSBで接続されているデバイスという意味です。-dをつけるか、デバイスを直接指定しないとerror: more than one device and emulatorとエラーが出ます。
特にエラーメッセージが表示されなければ成功です。
スマホからAndroid Wearアプリを起動し、右上の三点ドットをタップ→新しいウェアラブルとペア設定を選びます。（歯車アイコンの設定ではないです）
端末を選択画面が表示されるので、右上の三点ドットをタップして「エミュレータをペア設定」を選べばエミュレータと接続完了します。
どうでもいいことですが、ペアリングが完了するまでの速度だけは実機より早いです。
Wear端末（実機）とペアリングし直す場合は、エミュレータから切断を行った後、端末を選択画面から自分の使っているWear端末を選べばペアリングし直されます。
adbによるポートフォワーディングについて補足 ちなみに現在adbでポートフォワードを行っているポートを確認するには以下のコマンドを使います。
adb forward --list
現在行っているポートフォワーディングを止めるには以下のコマンドを使います。
adb -d forward --remove ポート番号
全てのポートフォワーディングを解除してしまって問題ないならadb forward --remove-allでもいけます。–remove-allの方が入力する量が少なくて楽かもしれません。
せっかくAndroid Wear端末を手に入れたのだから、Wearアプリも作ってみようかなと思いましたが、Wear端末をAndroid Studioに認識させるのも一苦労です。
Android Wearアプリのデバッグやら実行状況を確認するのにUSBで接続するには、クレードル経由でパソコンに接続する必要があります。しかしクレードルを持ち運ばないといけないのは非常に面倒くさいです。
ちなみにクレードル経由でUSB接続すれば、パソコンにAndroid Wearが認識されてlogcatも確認できます。（クレードルとWear端末は充電端子でしか繋がっていないのに、いったいどういう仕組でLogcatが確認できるんでしょうか・・・）
それはともかく、USB経由で繋ぐにはクレードルを持ち運ばなければならず、腕にはめたままデバッグできないのは面倒くさいです。
そんな場合に備えてBluetooth経由でデバッグすることも可能です。
Bluetooth経由で接続する方法 Bluetooth経由はクレードルを持ち運ばなくて済む点はGoodですが、一方でその他の面で面倒くさいです。
Wear端末とペアリングしているスマホをパソコンにUSBで接続する。 スマホ側でAndroid Wearアプリを起動し、設定（歯車のアイコン）→Bluetooth経由のデバッグを有効にする Wear端末側でBluetooth経由のデバッグを有効にする（事前に開発者モードを有効にしておく必要あり） パソコン側でadbコマンドを打ち込み接続を行う 以上のステップを踏むことで、パソコンにWear端末が認識されるようになります。 Wear端末の開発者モードを有効にするには、設定→端末情報→ビルド番号を7回タップします。
adbコマンド adb forward tcp:4444 localabstract:/adb-hub adb connect localhost:4444 ポートは自分で決めていいみたいです。
Android StudioのTerminalタブで打つなり、Macのターミナルを起動して打つなりすればOKです。
スマホを繋いだ時に自動的には認識してはくれないので、毎回このコマンドを打たなければなりません。
スマホのAndroid Wearアプリの表示 Bluetooth経由のデバッグを有効にすると、その下にホストとターゲットの表示が出てきます。
ホストはパソコンのことで、adbコマンドを打って接続してやる必要があります。
ターゲットはWear端末のことです。Wear端末でBluetooth経由のデバッグを有効にすれば接続状態になります。
ホストとターゲットの両方が接続状態になると、パソコンからWear端末が認識できるようになります。
ちなみにWear端末のBluetooth経由でバッグをオフにする度に、再度adbコマンドを打ち込まなくてはなりません。
Bluetoothデバッグ中のAndroid Wear Bluetooth経由のデバッグを有効にすると、常に「Bluetooth経由のデバッグが有効です」と表示され、他のWearアプリを動かしたりできなくなります。
開発中のアプリをWear端末で実行することはできますが、Wear端末からは設定を開く以外なにもできなくなります。
結局どっちがいいのか スマホとWear端末を行き来する必要があるので、Bluetooth経由でのデバッグも面倒くさいです。
Bluetooth経由だと、Wear端末にデバッグ対象のアプリが転送されるのに時間がかかります。スマホのアプリみたいに即座に起動したりはしません。転送に時間がかかっているのか、それとも失敗しているのかよく分からなくて困ります。
USB経由でも転送されるのにラグを感じますが、Bluetoothよりは早い気がします。
そういう観点からは、やっぱりクレードル経由の方が開発には向いている気がします。
普段はUSB経由で開発を行い、パソコンにUSBポートが2つもない（スマホと同時に接続できない）とか、クレードルを持ち運べないとか、クレードルを持ってくるのを忘れた時など、そういう場合にはBluetooth経由で開発するようにしたらいいと思います。
参考サイト Android Developers – Debugging over Bluetooth
Qiita – 15分ではじめるAndroid Wear開発 – 実機を使った開発環境の作り方
