カテゴリー: Android Wear

Android Wearでアプリを開発する際に躓いたところなどを解説していきます。

リアルタイムで心拍数を計測できるHeart Rate Monitor Wearをリリースしました

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

リアルタイムで心拍数を計測・表示するAndroid Wearアプリをリリースしました。

特徴はリアルタイムで心拍数が分かること、Wear端末で計測した心拍数がそのままスマホに表示可能な機能があることです。

アプリはGoogle Playで公開中です。

開発の動機

運動不足解消とダイエットのために、室内でフィットネスバイクを漕いでいたのですが、あまり効果が現れませんでした。そんな中、ダイエット目的の運動は心拍数を元に運動すると効率がいいという情報を目にしました。

心拍数がだいたい40%〜60%くらいになるように運動すると、脂肪燃焼の効率がいいらしいです。

そこでAndroid Wearを使って心拍数を確認しながら運動することを考え、開発を開始しました。

しかし運動中にいちいち腕時計の画面を確認しないといけないのはちょっと面倒です。特に私はスマホでAbemaTVを見ながら運動していました。心拍数を確認するのに手元に視線を動かすことは、運動から気がそれるだけでなく、番組からも目を離すことになってしまいます。

どうせスマホの画面を見ているのだから、画面の右隅にでも計測中の心拍が表示されればいいのに。そんな思いからこのアプリが誕生しました。

スマホへのオーバーレイ表示

こんな感じで画面の右上に半透明で心拍数が表示されます。

オーバーレイ表示

YouTubeなどで動画を見ながらでも心拍数を確認できます。今はやりのポケモンGOをやりながらでも確認できます。(ただポケモンGOだと心拍数をコントロールするような運動はしないでしょうけど)

心拍の推移を記録

このアプリは心拍数をリアルタイムで表示するだけでなく、その推移を記録します。これはWear端末のみで運動した場合でも記録できます。

例えばWear端末のみを装着してジョギングを行う→家に帰ってスマホでジョギング中の心拍数の変化を振り返る、といった使い方ができます。

Saved heart rate ja

使い方

Android Wearのアプリ一覧からこのアプリを起動すれば心拍数の計測が始まります。

スマホ側にも起動ボタンを用意しているので、そちらからも起動できます。

起動・終了ともに、スマホとWearが通信可能な状態なら、スマホ側で起動すればWear側も起動します。終了に関しても同様です。

計測中はWear端末の画面上に心拍数が表示されます。アンビエントモードに対応しているので、バッテリーに配慮した作りになっています。

スマホに心拍数を表示するよう権限を許可していれば、心拍計測が始まれば自動的にスマホ側にも心拍数が表示されるようになっています

計測を終了するには、Wear端末上のアプリ画面で右に向かってスワイプします。スマホで計測終了ボタンを押してもOKです。

計測したデータはログとしてスマホで後から確認することができます。ただし、あまりにも長い時間計測をした場合、データがうまく保存できない可能性があります。2〜3時間は大丈夫だと思いますが、端末の性能やセンサーの精度などにも影響されるので一概には言えません。

必要な権限について

  • ボディセンサー
  • 他のアプリに重ねて表示
  • 端末スリープの無効化
  • ネットワークアクセス関連

最初2つに関しては、お使いの端末がAndroid 6.0以上の場合には、実行時に許可するかどうかを選択できます。

ボディセンサー

Android Wear端末で心拍数を読み取るために必須です。この権限を許可しない場合このアプリは動作しません。

他のアプリに重ねて表示

スマホ側で心拍数を確認するオーバーレイ表示を行うために必要です。この権限は許可しなくても心拍数の計測はできます。

権限を許可しない場合はオーバーレイ表示ができないので、スマホで心拍数を確認できなくなります。

端末スリープの無効化

Android Wearのアンビエントモードに対応しているため、端末スリープを無効化する表示が出ています。実際にはちゃんとスリープします。

ネットワークアクセス関連

広告の表示や、アプリの機能改善のためのアクセス解析、クラッシュログ送信サービス利用のために必要となっています。

個人情報の取得・送信は行っていません。

どのようなデータが送信され、どう取り扱われるかについてはプライバシーポリシーをご覧ください。

精度について

計測精度は目安程度に思ってもらったほうが良いかもしれません。

腕時計のセンサーで計測するわけなので、センサーが皮膚としっかり密着していないと正しい数値が出ないようです。

具体的に言うと、比較的腕を動かさないですむサイクリングマシーン(フィットネスバイク)による運動だと安定した計測ができているように感じます。汗を拭くのに腕を動かしたりすると数値が極端に下がったりします。

バーベルを使った筋トレ中に計測をしてみましたが、こちらはまったく安定しません。握ったり動かしたりとセンサーと皮膚の間に空間がしょっちゅうできる上に、よほどきつくバンドを締めていないかぎり腕時計がズレます。そのため、心臓がバクバクしてるのが体感で分かるレベルにもかかわらず、心拍数が安静時と同じ数値を示したりしていました。

とはいえ、スマホで動画を見ながらのながら運動に最適だと思います。ぜひ使ってみて感想をお聞かせください。

アプリはGoogle Playで公開中です。

CapabilityAPIを使う場合、アプリのパッケージ名に注意

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

Android Wearのアプリを作成する際には、パッケージ名をスマホ側と同じにしなければなりません。

新規プロジェクトで初めからWear用のアプリも含めて開発する際は関係ない話です。Android Studioの新規プロジェクトウィザードでターゲットにWearを追加するだけなので、両者のパッケージ名を別のものにしようと思ってもできません。

気をつけなければならないのは、スマホ用のアプリを作成していて、途中からWear用のモジュールを追加する場合です。「Wear用のモジュールだからパッケージ名変えたほうがいいかな」なんて気を利かせると逆にハマります(私のように)。

(ちなみにここで言っているパッケージ名は、アプリのパッケージ名のことです)

開発時はWear用のモジュールを実行、スマホ用のモジュールを実行という感じでアプリをインストールして実行できるので問題に気づきにくいのですが、Wearとスマホで通信を行おうとした際にハマります。

具体的にはCapability APIを使って通信可能なノードを取得する際に、パッケージ名が違うとそのノードが取得できません。

http://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用のパッケージを追加するときには気をつけましょう。

Bluetooth経由でデバッグする

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

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アプリを開発するときはversionCodeなどを一元管理すると便利

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

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の世界ではどれもプロジェクトと呼ぶそうです。勉強になりました。

WatchFaceのサンプルを実行する

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

Android Wearでウォッチフェイスを自作するためには、Creating Watch Faces – Android Developersを見て勉強するといいです。

なんかややこしそうな気がするかもしれませんが、そこまで複雑でもないです。Traningにも書いてありますが、Android StudioでWatch Faceのサンプルを取り込んでやると、どういうことやればいいのかわかると思います。

取り込み方はAndroid StudioのFileメニューからImport Samplesを選び、Wearable > Watch Faceを選択すればOKです。

Watch Faceサンプルを取り込む

サンプルの実行方法

このサンプルを実行する場合、実行環境にバツ印がついています。これはデフォルトで起動するActivityが設定されていないからです。

実行環境にバツ印がついている

そのまま実行しようとすると以下の様な警告メッセージが表示されますが、Continue Anywayを選べばAPKが端末へ転送されます。

気にせず続ける

毎回このメッセージが表示されるのはうっとおしいので、実行環境設定でDo not launch Activityを選んでおいた方がよいでしょう。

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にログが出力されるようになります。

音声コマンドで自分の作ったアプリのActivityを起動する

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

Android Wearでアプリを起動するのに音声入力でアプリが起動できるととても便利です。Wear用アプリを作る上では外せない要素だと思います。

Android Developersのトレーニングを見ると、AndroidManifest.xmlでintent-filterかけておくだけでいいということです。activityに設定したlabelをキーワードとして、Activityが起動するようになります。

ぶっちゃけると、ラベルをしっかり設定さえすれば、初期状態で音声入力によってActivityが起動するということであります。

Adding Voice Capabilities – Android Developers

しかしいくらやってみてもうまくいかなくて、何がいけないのかサッパリ分かりませんでした。

単純すぎるのか調べてもなかなかピタリとくる情報もなくて困っていたら、Stack over Flowを見て謎が解けました。

Wear: Open my app with custom voice Start command, not working – Stack Over Flow

つまるところ、mobile側のActivityにintent-filterをつけてないとうまく動作しないのです。

私はデバッグのため、wear側のアプリしか動かしていませんでした。(開発中のサンプルアプリはwearにしかインストールされていない状態)

スマホ側に音声コマンドを受け取るintent-filterがなかったためにWear上のActivityも起動しなかったということなんだと思います。

Wearアプリを開発する場合は、Wearモジュールだけでなく、mobileモジュールも実行してスマホにインストールしておかないと、ちゃんとした動作確認ができないということが分かりました。

実験

構成

Android StudioのNew Projectウィザードで作成した初期状態のままです。

wearモジュールもmobileモジュールも、Hello Worldの文字列を表示するだけのMainActivityがあるだけの状態です。

mobileのラベルとwearのラベルを同じにする

mobile側のActivityのラベルに「サンプル」と設定して、wear側のActivityのラベルにも「サンプル」と設定します。

この状態でOK Googleから「サンプル開始」と言うと、WearのMainActivityが起動します。スマホのMainActivityは起動しません。

mobileのラベルとwearのラベルを異なるものにする

mobile側のActivityのラベルに「サンプル」と設定して、wear側のActivityのラベルに「テスト」と設定します。

この状態でOK Googleから「サンプル開始」というと、スマホ側のMainActivityが起動します。(Wear端末には「アプリを開いています・・・」というメッセージが表示され、スマホ側で指定したActivityが起動します)

一方で「テスト開始」というと「テスト開始」でWeb検索を行った結果がWear端末に表示されます。

どちらにせよWearのMainActivityは起動しませんでした。

スマホ側での音声入力

ちなみにスマホ側でOK Googleからの音声入力を行った場合は、全てWeb検索として扱われてしまい、MainActivityは起動しませんでした。

どういうことなんでしょう?

そもそもスマホとペアリングされていないと音声入力は使えない

Wear端末はスマホとペアリングされている状態でなければ音声入力を使うことができません。

このことから、音声入力の処理を実際に行っているのはスマホ側であると考えられます。

おそらくスマホ側に入力結果に該当するActivityがあるかどうかが調べられ、なければWeb検索として処理されるのだと思います。

スマホ側に該当するActivityがあれば、そのActivityを開くぞという情報をwear端末へ送るのでしょう。その際にWear上にも同一のActivityがあれば、Wear上でActivityが開かれるんでしょう、多分。

この辺りの音声入力の結果、どのようなデータがどうやって送受信されているのかを調べる方法があればもっと分かりやすいとは思うのですが、私には調べる方法が分かりません。

Android Developers探したらどこかにあるんですかね・・・?

しかし一時期mobile側関係なく動いていたが・・・?

以前試した時は、mobile側のラベルに関係なくWearにインストールしたアプリのActivityが起動していました。

そのためいまひとつ腑に落ちません。

うまくいかなくなったのはWear端末のリセットを行ってからなので、何らかの設定が変わってしまったせいもあるかもしれません。OSのバージョンが5.0.2になったせいもあるかもしれません。

Android Wearアプリ開発にエミュレータを利用する

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

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の方が入力する量が少なくて楽かもしれません。

adbコマンドを使ってアプリを手動で削除する

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

adbコマンドを使ってアプリを手動で削除するのは、スマホのアプリを作成する上では必要ないと思っていましたが、Android Wearアプリを作る場合には覚えておいた方がいいです。

というのもWearに一度インストールしたアプリは、Wear上での操作では削除することができないからです。

スマホ経由でインストールしたアプリの場合、スマホ側でアプリを削除すればWearにインストールされたアプリも一緒に消えてくれますので、一般的にはあまり問題にならないのかもしれません。

しかしWearアプリを開発していると、デバッグのためなどでWearに直接アプリをインストールすることが多くなります。こうなるとWearがデバッグ用のアプリで埋め尽くされる事態になってくるのです。

インストールされているパッケージの一覧を確認する

adb shell pm list package

ターミナルからコマンドを入力すると、対象デバイスにインストールされているパッケージの一覧が表示されます。

adb shell pm list package

アプリを削除するためにはパッケージ名が必要になるので、このコマンドで確認しましょう。

ちなみにパソコンに複数の端末が接続されている場合、adbコマンドを送るデバイスを指定する必要があるので注意しましょう。

アプリを手動で削除する

adb uninstall アプリのパッケージ名

adb uninstall

Wearのアプリを削除する場合は、コマンドの結果が返ってくるまで時間がかかります。

Wearの初期化のほうが早いかもしれない

ちなみに、Wearを初期化してしまえば済む話でもあるので、手動で消さなくてもなんとかなる話ではあります。Wearは初期化したところでスマホとペアリングし直すだけでほぼ元に戻ると言っても過言ではないため、初期化したほうが手っ取り早いのかもしれません。

ただ、サンプルアプリを1個インストールする度に初期化するのも馬鹿らしいので、コマンドを使えば簡単にアプリを消せるということを知っておくと何かと便利かもしれません。

Wear端末をパソコンに接続し、Android Studioでデバッグできるようにする方法

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

せっかくAndroid Wear端末を手に入れたのだから、Wearアプリも作ってみようかなと思いましたが、Wear端末をAndroid Studioに認識させるのも一苦労です。

Android Wearアプリのデバッグやら実行状況を確認するのにUSBで接続するには、クレードル経由でパソコンに接続する必要があります。しかしクレードルを持ち運ばないといけないのは非常に面倒くさいです。

ちなみにクレードル経由でUSB接続すれば、パソコンにAndroid Wearが認識されてlogcatも確認できます。(クレードルとWear端末は充電端子でしか繋がっていないのに、いったいどういう仕組でLogcatが確認できるんでしょうか・・・)

それはともかく、USB経由で繋ぐにはクレードルを持ち運ばなければならず、腕にはめたままデバッグできないのは面倒くさいです。

そんな場合に備えてBluetooth経由でデバッグすることも可能です。

Bluetooth経由で接続する方法

Bluetooth経由はクレードルを持ち運ばなくて済む点はGoodですが、一方でその他の面で面倒くさいです。

  1. Wear端末とペアリングしているスマホをパソコンにUSBで接続する。
  2. スマホ側でAndroid Wearアプリを起動し、設定(歯車のアイコン)→Bluetooth経由のデバッグを有効にする
  3. Wear端末側でBluetooth経由のデバッグを有効にする(事前に開発者モードを有効にしておく必要あり)
  4. パソコン側で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端末からは設定を開く以外なにもできなくなります。

Bluetooth経由のデバッグが有効と常に表示される

結局どっちがいいのか

スマホとWear端末を行き来する必要があるので、Bluetooth経由でのデバッグも面倒くさいです。

Bluetooth経由だと、Wear端末にデバッグ対象のアプリが転送されるのに時間がかかります。スマホのアプリみたいに即座に起動したりはしません。転送に時間がかかっているのか、それとも失敗しているのかよく分からなくて困ります。

USB経由でも転送されるのにラグを感じますが、Bluetoothよりは早い気がします。

そういう観点からは、やっぱりクレードル経由の方が開発には向いている気がします。

普段はUSB経由で開発を行い、パソコンにUSBポートが2つもない(スマホと同時に接続できない)とか、クレードルを持ち運べないとか、クレードルを持ってくるのを忘れた時など、そういう場合にはBluetooth経由で開発するようにしたらいいと思います。

参考サイト

Android Developers – Debugging over Bluetooth

Qiita – 15分ではじめるAndroid Wear開発 – 実機を使った開発環境の作り方