HFP-AGを使ううえでの注意点

いただいた質問に答えていると、自分でもとても勉強になるものです。今週はHFP-AGとして使う際の動作について質問を受けたのですが、自分の使っているヘッドセット(MW600)では経験したことのない問題が、使用する機種や設定によっては発生することを確認することができました。

HFP-AGとしての使用例については、もう２年ほど前にこの記事で触れています。MW600を使ううえでは、この設定で何の問題もないのですが、一般的にはこれでは２点ほど設定が足りません。

まずひとつは、statusコマンドによる網側サービスの状態通知です。WT32のHFP-AGが接続された状態では、WT32はHFPユニット側に対して何のネットワーク状態通知も出しません。そのため、ヘッドセットによっては網側サービスは利用できない状態であると解釈し、着呼や発呼の制御を受け付けないようです。この問題を避けるためには、HFP-AGの接続後HFP-AG側で

status service 1

コマンドを実行することで、明示的に網側サービスが利用可能であることをヘッドセット側に通知してやります。

もうひとつの問題は、呼び出し音の制御です。HFP-AG側でringコマンドを実行すると、WT32はすぐにHFPユニット側にSCOリンクを張りにいきます。これはHFP-AG側で生成する呼び出し音をHFPユニット側に送出することを可能とするためです。しかしながら、ユニット側では自分で呼び出し音を生成する機能をもっており、SCOリンクからの呼び出し音を流さないかもしれません。WM600ではそのように動作しました。これは、HFP-AG側が呼び出し音を生成することを明示的にユニット側に通知していないために生じます。呼び出し音送出を明示的に通知するためには、

+BSIR:1

コマンドをHFP-AG側で実行してやります。逆にインバンドでの呼び出し音送出ができない場合には、

+BSIR:0

を送出してやります。実際に+BSIR:1を実行してやるとWM600は自機での呼び出し音生成をしなくなりました。

ちなみにBluegigaのAP Noteでは、この通知は++BSIRとして説明されていますが、間違いです。元資料であるHFP 1.5を確認してみると、そちらでもタイポになっていましたので、そのままコピペしたために間違っているようです。ちなみに、HFP 1.6ではこのタイポは修正されていました。

PAGEMODEとペアリング

WCA-009を購入いただいた方から質問を受けたので、きょうはペアリングに関連してPAGEMODEとPIN番号の設定について説明しておくことにします。

Bluetoothでは接続に先立って、通常接続するデバイスを互いに認証しておく必要があります。その手順はペアリングと呼ばれ、片方の側(デバイスA)からもう片方(デバイスB)へ接続をおこなうために、つぎのような一連の手順を踏みます。

1. まずデバイスB側を他のデバイスから発見可能な状態に遷移させます。デバイスによってはペアリング受付可能状態とも呼ばれます。
2. デバイスA側からデバイスの検索をかけます。近隣にある自分とつながりそうなデバイスとその名前を見つけます。
3. 見つかったデバイスのリストのなかからデバイスBを選択して、ペアリングあるいは接続動作を試みます。
4. デバイスB側からPIN番号の要求を受けるので、デバイスBの持つPIN番号をデバイスA側で入力します。
5. ペアリングあるいは接続動作が終了します。
6. 必要に応じてデバイスB側の発見可能な状態を解除。

それでは、これらの手順と対応するWT32の設定ならびに操作について説明していくことにします。最初に自分を他のBluetoothデバイスから発見可能な状態にせねばなりません。この設定は SET BT PAGEMODEコマンドでおこないます。WT32のディフォルトでは、

SET BT PAGEMODE 4 2000 1

となっています。この設定では、Bluetooth接続がない状態ではWT32は他のデバイスから発見可能な状態にありますが、接続ができると発見できない状態になります。単一デバイスとの接続であれば、ユーザにペアリング受付可能モードを意識させない都合の良いモード設定というところでしょうか。ただし、この設定ではいったんひとつのデバイスと接続されると、他のデバイスからの接続は受付ないようになります。したがって、音楽プレーヤと接続した状態で、携帯ともつなげようとしてもつながらないという問題が発生します。

SET BT PAGEMODE 3 2000 1

という設定に変更してやれば、常時発見可能/接続可能な状態になります。Bluetooth用語で言えば、Inquiry scanとpage scanの両方を行う状態です。しかし、この状態では常時見え見えの状態なので、セキュリティや消費電力の観点からは必ずしも好ましい状態ではありません。そこで、いったんペアリングができれば、以後は

SET BT PAGEMODE 2 2000 1

に設定変更するのが好ましい使い方と言えます。Bluetooth用語で言えば、Inquiry scanは行わないが、page scanは行うという設定です。この状態では発見はできませんが、すでにペアリングを終えBluetooth Device Addressを知っているデバイスからの接続受付は可能だからです。

近隣デバイスを検索するには、inquiryコマンドを用います。

このコマンドで近隣で発見可能なデバイスのBluetooth Address(BD ADDR)とそのClass of Device(COD)を知ることができます。またnameオプションを指定することで、対応するデバイス名を調べることができます。上述のように他のデバイスからのinquiryの要求を受け付けるためには、PAGEMODEを適切に設定しておく必要があります。CODの設定は、SET BT CLASSコマンドで設定することができます。装置によってはCODでフィルタをかけることで、特定のクラスに属するデバイスのみを検索して表示するものがあります。このような場合には、PAGEMODE設定で発見可能になっていても、CODが適切に設定されていないと発見してもらえないという現象が発生しますので、注意が必要です。

ペアリングには自動的にPIN番号を生成するSSP(Simple Secure Pairing)という機能も用意されていますが、ここでは静的にPIN番号を設定する方法について紹介しておきます。具体的には、

SET BT AUTH * 1234

とすることでPIN番号として1234を指定することができます。次に示すようにこの設定は、相手側から送られる自分のPIN番号確認にも使われますし、相手側に対して送出するPIN番号としても使われます。

• ヘッドセットのようなデバイスを作る場合には、この設定だけで充分です。スマホやパソコンからデバイスの登録をおこなうと、PIN番号を聞かれますのでスマホ/パソコン側で設定した番号(ここの例では1234)を入力すればペアリングが完了します。
• 音楽プレーヤのような装置を作る場合には、検索して見つけた相手デバイスに対してペアリング操作を行う必要があります。

  PAIR bdaddr

  とすることで指定したアドレスのデバイスとペアリングすることができます。この際に必要となるピン番号にはSET BT AUTHで指定してある番号が使用されます。
• PAIRコマンドを用いて明示的にペアリングをおこなわなくても、CALLコマンドを使って相手側に接続を試みると、必要であれば自動的にペアリングをおこなってくれます。この時にもSET BT AUTHで指定したピン番号が使用されます。

それでは、ペアリング操作の実例を示しておきましょう。まずは、PAIRコマンドを使う例から。SET BT AUTHの設定がない状態でPAIRコマンドを発行しても相手に伝えるPIN番号情報がないので失敗します。SET BT AUTHでPIN番号設定してからPAIRコマンドを出すことで、ペアリングに成功しています。


次の例では、CALLコマンドで接続する際に自動的にペアリングできることを示しています。SET BT PAIR *でいったん全てのペアリングを解除しているのですが、その後のCALLコマンドで接続できているのは自動的にペアリング動作が行われているためです。


インタラクティブなペアリング
さて、上記の方法ではSET BT AUTHコマンドを使うことで、PIN番号を固定的に指定しています。しかし、オーディオ・プレーヤに複数のヘッドホンをペアリング登録したいような場合には、デバイス毎にPIN番号が異なっている可能性があります。このような用途では、コマンドで固定的にPIN番号を指定するのではなく、ペアリング操作時にインタラクティブに番号を指定できた方が便利です。WT32でもそのための機能が用意されています。以下に、その例を示します。

• まず、SET CONTROL CONFIGコマンドで bit 11をセットすることにより、認証要求のイベントを表示するように設定しておきます。
• すると、PAIRやCALLコマンドを出したときに、AUTHイベントが表示されるようになります。
• AUTHコマンドを使って、相手側のPIN番号を返してやります。
• SET CONTROL CONFIGコマンドでビット7がセットされていれば、ペアリング成功時にはPAIRイベントが表示されます。

上の例では1回目のピン番号の入力をわざと間違えてみました。その結果として、PAIRコマンドが失敗したことを示すイベントが出ていることに注意してください。正しいPIN番号を入れるためには、例のようにPAIRコマンドからやり直す必要があります。もちろん、CALLコマンドを使った場合にも同じようにAUTHコマンドでPINを入力することができます。

SAM3S4Aボード - その2

ひととおりの部品のハンダ付けを完了。いつものようにJTAG接続で、デバイス認識できるところまで確認できました。



SAM3S4Aだけのボードでは面白くないので、基板にはいくつかのオプション部品を搭載できるようにしてあります。今回は試験のためにフル実装することに。まずはSAM3Sのすぐそばには加速度センサーのMMA8452Qを載せられます。このセンサーは、自由落下検出はもちろんのことタップやダブルタップの検出、縦横向きの検出機能等も備わっているので、使い方を覚えるといろいろと便利に利用できそうです。問題はパッケージが3mm×3mmのQFPであり、小さくてハンダ付けが難しいことなんですが、お値段が128円＠Mouserと大変に安かったので、ダメもとで挑戦してみました。なんとかハンダ付けできたと思うのですが、I2Cで操作するソフト用意しないと動作確認できません。

主要部品は表側に配置してありますが、裏側にもオプション扱いの部品を２つ実装できるようにしてあります。ひとつは、32KHzのクリスタルで、もうひとつはSPI接続のData Flashです。この基板単独でも加速度センサのデータをData Flashに記録する用途に利用できることになります。運良く手持ちのAT4DB161Dを発掘できたので、これを実装。



JTAG用のヘッダピンは２列になっています。上側の列の5ピンはVCC, nRST, SWDIO, SWCLK, GNDとなっており、SWD接続ならこれだけで用が足ります。下側の２ピンはTDI, TDOでありJTAG接続したい時に追加で使用します。今回は、JTAG接続することとし、変換アダプタを用意。



アダプタ装着時はこうなります。



はい、アダプタの方が本体ボードよりもひとまわりデカいです。ヘッダピンの横にあるタクトスイッチはリセットです。レギュレータとSAM3S4Aの間に2ピンのジャンパを実装できる穴が用意されていますが、これはERASE端子のジャンパ用です。ショートすることでSAM3S4Aのフラッシュを強制的に消去することができます。SAM-BAを使ってフラッシュへ書き込む場合を考慮して用意してありますが、JTAGを使うぶんには必要ありません。

SAM3S4Aボード

OLIMEXからSAM3-H256が出てからは、ちょっとした実験や工作にSAM3-H256ボードを使っていました。値段が手頃なこともあり、CMOSカメラをつなぐにはSAM3S4Bを使ったこのボードは大変便利に使えましたが、ちょっとした実験をするには不向きな点もあります。SAM3-H256ボードは10x2ピンのソケットがふたつついており、ブレッドボードに挿すこともできません。そのため、いちいちユニバーサル基板に配線する必要が生じます。USB接続もBコネクタなので、ボード高も高くなってしまいます。秋月のアクリルケースに保管したくてもフタが閉まらなくて悲しい思いをしていました。

SAM3S4Aでいいので、もう少し小さいボードがあった方がちょっとした実験には便利だろうと思い立ち、Fusion PCBで基板つくってみました。



SAM3-H256と並べてみるとこんな感じ。使用デバイスが64ピンから48ピンになっていますので、ひとまわり小さくなります。



USBはミニBにして、場所を喰うARM標準20pin JTAGコネクタを使わないことにしました。JTAG接続はアダプタを介して接続することにします。

期待と現実

先週、Android 4.0でHFP 1.6がサポートされていないことを確認して、ガッカリさせられましたが、Galaxy S3のHFP関連ではAT+CCLKコマンドもサポートされていないことも確認。なんとATI0コマンドすらサポートされていない!!??

すでにこのブログでも何度かとりあげていますが、このコマンドがサポートされていれば電話機側からdate/timeを取得して自機側の時計を設定することができます。これまでに何種類かの携帯電話やAndroidスマホと接続を試したことがありますが、いまだに iPhone/iPad touch以外でこのコマンドをサポートする端末に出会えていません。Galaxyくらいにグローバルな端末だったらサポートされているだろうと期待を抱いていたのですが、現実はそんなに甘くありませんでした。せっかく端末買ったのに、WT32の機能デモに活用できないではありませんか!! 現状であれば、Bluetoothデモ用にはiPhoneがベストな端末ですね。Jerry Beanに期待しようかな？でも、期待はずれに終わるかな。

6月にはiWRAP5も正式リリースの予定だったのですが、こちらも遅れているようです。今週、iWRAP5.0.0 rc1がリリースされて、正式リリースまではあと少しのようです。さて、このiWRAP5ですが、当初の計画とはちょっと違ってきてしまった部分もあるようです。

• PIOにつなげたスイッチの長押しが検出できる計画だったが、実装取りやめになった。
• WT32ではHDPはサポートされないことになった。

βコードでHIDが動かない問題を見つけて報告してあるのですが、アチラでは修正したと言っているのに、こちら側では修正を確認できずちっとも動きません。どうしてむこうでは問題が再現しないのか、不思議なくらい。もともとメモリが不足気味のWT32ですので、HIDのサポートも打ち切りにならないかとヒヤヒヤしています。

SAM4S Xplained

ATMELは自社製品のマーケティングのためにAtmel Technology on Tourというイベントを企画し、世界各地で製品の紹介とトレーニングをおこなっているようです。日本では6月28日開催ですから、もう終わってしまったようですね。じつはわたしも申し込んでみたのですが、「お得意様相手のイベントで、(あんたみたいな)個人は相手にしていません。」とキッパリ断られてしまいました。

このイベント, 例年開催されているようですが、これまではAVRがトレーニンングの中心で合ったのに対し、今年はSAM4Sがトレーニンング対象となっていたので興味をもった次第です。トレーニング内容としては、ATMEL Studio 6を使ってサンプルをコンパイル、評価ボードSAM4S-EKで動かしてみるといった内容のようです。参加費$49が必要なのですが、おみやげにSAM4S Xplainedというボードがもらえることになっています。はい、このボード目当てで申し込んでみたわけです。

さて、このSAM4S Xplainedですが、いまだATMEL Storeでも販売されていません。いまのところトレーニングに参加できた人だけが入手できるお宝ガジェットというところでしょうか? 　クッソー!と思っていたのですが、ふとしたことでMouserのカタログに登録されているのを発見!! まだ在庫ありませんが、3000円切ってます。ついにATMELも安価なCortex-M4のボードを市販してくれるんでしょうか？楽しみです。



どんなボードなのかなぁと思って検索してみたら、User Guide発見!! J-link機能付きのボードですが、J-link実現するのにSAM3U使ってますね。SAM4Sのパッケージには、ES2と書かれています。ボード上には外部SRAMも搭載されていますが、評価ボードに比べると周辺機能はずいぶんと寂しく、LCDもSDカードもついてません。いちおう、ADC, SPIとTWIは拡張ヘッダーで外に出ています。

HFP 1.6はどこにいったのか？

わたしの場合、なかばGalaxy S3はBluetoothの機能確認のために購入したようなものなので、続いてHFPの確認です。まずは、前回の記事でも掲載したSDPの内容を確認しておきましょう。

Service Name: Voice Gateway
Service RecHandle: 0x10006
Service Class ID List:
  "Handsfree Audio Gateway" (0x111f)
  "Generic Audio" (0x1203)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 10
Profile Descriptor List:
  "Handsfree" (0x111e)
    Version: 0x0105

この部分がHFPなのですが、プロファイルバージョンが0x0105 つまり1.5になっています。ガーン、ショック受けました。Android 4.0ではHFP 1.6がサポートされるものだとばかり思っていましたから。たとえばこことかココとかに書いてあったわけです。改めて読み直してみると、これらの記事はGoogleさん発表の紹介記事であって、その時点では実機やコードで確認することもできないわけですから、これらの記事のとおりの機能を有した端末が出てくるとは限りません。そうすると、HFP 1.6に対応できていない理由としては、どのような可能性があるのでしょうか。思いつくままに列挙してみます。

• そもそもGoogleの発表が間違っていた。HFP 1.6対応の計画はなかった。
• 発表の時点では対応する計画であったが、その後計画が変更された。
• 発表はNexus端末を対象としたものであり、他の端末のサポートは知ったことではない。
• GoogleはHFP 1.6対応したが、Samsungは自社端末や周辺機器の都合上、これを採用しないことにした。
• Galaxy S3のグローバル版端末では1.6対応しているが、DoCoMoは、自社版ではこれを採用しなかった。

どれもこれもありそうなハナシのような気もしちゃいますが、しばらくは他のAndroid 4.0端末を調査する機会も無さそうなので、もう少し自分なりに調べてみることにしてみました。上述したメディアのソースはAndroidの開発者向け情報のようですので、この原典にあたってみました。なんと、どこにもHFP 1.6なんて書いてありません。HDPについては言及されていますが、APIを調べてもHFPは1.5であると明記されています。どうやら、いつのまにかHFP 1.6の記述は削除されているようです。Jelly Beanの説明でもHFP 1.6には言及されていません。

世の中のBluetoothヘッドフォンやヘッドセットでは、すでに新しめの製品はHFP 1.6対応しているようですから、当然HFP 1.6対応したスマホの需要があり、それに対応するのだと思っていたですが。。自社のNexusを差別化するための、隠し球のひとつとして取り置きしておくことにしたんでしょうか。。？

BlueZの最新版4.101をダウンロードして覗いてみましたが、ここでもやはりHFPのバージョンは1.5のままのようです。そうすると、HFP 1.6はまだしばらくの間使えないということでしょうか? iWRAP5がHFP 1.6に対応するので、その動作確認することを楽しみにしていたのに、当分お預けのようです。

Galaxy S3とメディア・プレーヤ

ひとさまから遅れること何年かにして、ようやくとスマホデビューしました。購入した端末は累積販売台数1000万台とかで話題のGalaxy S3 SC-06Dです。この端末、Android 4.0対応しているだけでなく、Samsungが独自にAVRCP 1.3に対応しているらしいとの情報があったために選択しました。iPhone以外でAVRCP 1.3機能がまっとうに使える数少ない端末であると見込んで購入したのにもかかわらず、曲名等のメタデータをWM600やBlueSAM上で表示できないという問題に遭遇しました。きょうは、その顛末の報告です。

まずは、現在のAndroidにおけるAVRCPプロファイルサポートに関する背景を簡単にまとめておきましょう。AndroidはLinuxベースであり、そのBluetooth機能についてはBlueZプロジェクトの成果を取り入れたものがベースとなっています。このブログ記事の説明によれば現行の4.0 ICSで使用されているBlueZのバージョンは4.94であり、そのAVRCPサポートはプロファイルバージョン1.0のようです。AndroidにおいてAVRCP 1.3がサポートされるのは、次の4.1 Jerry Beanになるようです。しかしながら、これは素のAndroid環境を用いた場合の話であり、自分で機能強化を行えばもちろん4.0 ICS(あるいはそれ以前の版)でもAVRCP 1.3対応することは可能となります。実際にシャープ製の端末では、IS01のころからAVRCP 1.3対応しているようですし、世の中には勝手ROMでAVRCP 1.3対応しているものもあるようです。

Galaxyの場合も同様にSamsungが独自にAVRCP 1.3に対応しているらしく、こちらの記事によればGalaxy S2でメタデータの送信ができているとの報告があります。この情報からわたしはS３においても当然同様の機能がサポートされているに違いないと確信したわけです。このようにベンダーが独自に機能拡張をおこなっている場合には、ベンダーが提供するMedia Playerを使用しないとその機能は利用できない可能性があります。他の評判のいいプレーヤがあっても、端末ベンダが提供する拡張APIに対応していなければメタデータ送信はできないからです。

ここからは実証編です。まずはAVRCPのプロファイル・バージョンを確認してみます。別のUbuntuマシン上からsdptoolを使ってSC-06DのSDP情報をbrowseしてみた結果です。

Browsing 0C:71:5D:10:85:1E ...
Service RecHandle: 0x10000
Service Class ID List:
  "PnP Information" (0x1200)
Profile Descriptor List:
  "PnP Information" (0x1200)
    Version: 0x0102

Service Name: Audio Source
Service RecHandle: 0x10001
Service Class ID List:
  "Audio Source" (0x110a)
Protocol Descriptor List:
  "L2CAP" (0x0100)
    PSM: 25
  "AVDTP" (0x0019)
    uint16: 0x102
Profile Descriptor List:
  "Advanced Audio" (0x110d)
    Version: 0x0102

Service Name: AVRCP TG
Service RecHandle: 0x10002
Service Class ID List:
  "AV Remote Target" (0x110c)
Protocol Descriptor List:
  "L2CAP" (0x0100)
    PSM: 23
  "AVCTP" (0x0017)
    uint16: 0x103
Profile Descriptor List:
  "AV Remote" (0x110e)
    Version: 0x0103

Service Name: Voice Gateway
Service RecHandle: 0x10003
Service Class ID List:
  "Headset Audio Gateway" (0x1112)
  "Generic Audio" (0x1203)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 11
Profile Descriptor List:
  "Headset" (0x1108)
    Version: 0x0102

Service Name: OBEX Object Push
Service RecHandle: 0x10004
Service Class ID List:
  "OBEX Object Push" (0x1105)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 12
  "OBEX" (0x0008)
Profile Descriptor List:
  "OBEX Object Push" (0x1105)
    Version: 0x0100

Service Name: OBEX Phonebook Access Server
Service RecHandle: 0x10005
Service Class ID List:
  "Phonebook Access - PSE" (0x112f)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 19
  "OBEX" (0x0008)
Profile Descriptor List:
  "Phonebook Access" (0x1130)
    Version: 0x0100

Service Name: Voice Gateway
Service RecHandle: 0x10006
Service Class ID List:
  "Handsfree Audio Gateway" (0x111f)
  "Generic Audio" (0x1203)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 10
Profile Descriptor List:
  "Handsfree" (0x111e)
    Version: 0x0105

AVRCP Protocol Descriptor内のVersionが0x0103になっていることから、バージョン1.3になっていることが確認できます。Androidのアプリケーション管理で実行中プロセスを見てみると....



明らかにSC-06DではSamsung独自のAVRCPサービスが走っていますので、このサービスがAVRCP 1.3に関連した機能を提供している可能性があります。Samsungが提供するプレーヤでは、このサービスを介してメタデータを送信することができるのではないかと推測されます。

ところが実際にSC-06Dにインストールされている「メディアプレイヤー」を使ってWT32でAVRCPの動作を確認してみると。。



メタデータを要求しても、拒否されてしまいます。場合によっては、拒否はされなくてもデータとしてヌル文字列が返される場合もあるようです。orz


この「メディアプレイヤー」ですが確認してみると、上図のようにDoCoMo提供になっています。Samsungの純正プレイヤーだと思っていなのですが、違ったようです。あるいは、実際の開発はSamsungだけど開発費DoCoMo持ちのためドコモ提供になっているだけ？いずれにしても、動作検証はDoCoMoの責任ですよね。このメディアプレイヤーがちゃんとメタデータ送信に対応できていないんじゃないでしょうか？　良く見てみるとSC-06Dにはもうひとつ音符アイコンに「音楽」と記したアプリが用意されており、こちらもプレイヤーになっているようです。




こちらのプレイヤーを使うと正常にメタデータが送信されるようになりました。



日本語文字列の送信も問題ないようです。SonyのWM600とつないでもちゃんと曲名が表示されます。つまり、ドコモ純正の「メディアプレイヤー」がダメダメじゃん!! というオチだったのです。


このようにAVRCPを使うアプリの機能仕様は、残念ながらAndroidのバージョンだけでは判断できません。Androidは共通プラットフォーム機能を提供してはいますが、各ベンダは差別化のためにサービスやライブラリのレベルで機能仕様を強化して、それに対応したアプリを用意しているかもしれません。これら３つの層が正しく協調動作してくれないと期待した機能を提供してくれないことになります。ドコモ純正プレーヤは、良くできたSamsungの下位層をちゃんと使いこなせていない悪いお手本になっていたようです。次のJBでは、すべての層がGoogle提供のもので統一されることにより、このような問題が無くなれば良いのですが。。。

	SONY ソニーエリクソン Bluetoothワイヤレスヘッドセットマイク付き ブラック MW600/B
	ソニー
	ソニー

2012-07-03 10:52:30 追記
「音楽」と表示されるプレイヤーアプリはGoogle標準プレイヤーなのですね。つまり標準プレイヤーだとAVRCP 1.3に対応できて、DoCoMo純正プレイヤーでは対応できていないという当初予想とは真逆の結果になっているようです。APIの仕組みの都合でしょうか。
AvrcpServiceSamsungは、プレイヤーから受信したメタデータをキャッシュしており、Bluetooth経由での要求があった際にそのデータを送信しているようです。そのため、最後に標準プレイヤーで再生した曲のデータを保持しており、そのあとでDoCoMo純正プレーヤーで再生をすると、キャッシュされていたデータを送信します。そのため、純正プレイヤーを使用していると再生されている曲とは違うメタデータが表示され、しかも曲送りをしてもデータが変化しないという症状を引き起こすこととなります。