しばしば、connectGatt()を呼んでからonConnectionStateChange()までにやたらと時間がかかることがあるのだ。
10秒とはいかないが、そのくらい待つことがある。
かと思えば、さっさとつながることもある。
nRF Master Controlアプリではそういうばらつきがほとんどないので、私のアプリがよくないのだと思う。
logcatを見比べていくと、私の方ではこのログが出ていたのだが、nRF Master Controlアプリには出ていなかった。
D/BluetoothLeScanner: could not find callback wrapper
connectGatt()より後に出ているのだが、別にこれが何度も呼ばれているわけでもないし、待っている間も何かログが出ているわけではない。
なので、疑わしいのはこれか、という程度。
ソースファイルはこの辺だろう。
wrapperがnullだから、というくらいしかわからない。
Log.d()程度だし、あんまり関係ないような気がする。
気になるので出ている原因を調べたところ、私が悪かった。
BluetoothLeScannerでスキャンし、ボタンを押して接続させている。
接続するときにはスキャンを停止させる。
それだけならよかったのだが、ダイアログが消える処理のところにもスキャン停止を行っていた。
このログは、2回目にstopScan()を呼んで、もうコールバック関数の登録が消されたあとだから出力された、ということのようだった。
2重呼びを解消して安定した！ように見えたのだが、まだまだじゃった。。。
それ以外で違うログは、これの出力されるタイミングが早いか遅いかくらいしかない。
--------- beginning of system
私のアプリはconnectGatt()を呼んだ後で、nRF Master Controlアプリはずいぶん前だ。
でも、これって時間やプロセス名が出てないログで、これの前に空いているスペースの数も違うので、何か深いところで出している感じがする。
じゃあ、もしかしたら接続時ではなくて切断で足りていないものがあるのかもしれない。
D/BluetoothGatt: refresh()
私の方には、このログが出ていない。
が、BluetoothGatt#refresh()なんてAPIは引っかからないぞ？
・・・あ、これ@hideだ。
えー、リフレクションして呼んでるの？？
refresh()で検索すると、キャッシュを使わずにサービス検索してほしい場合に呼び出しているようだった。
How to programmatically force bluetooth low energy service discovery on Android without using cache - Stack Overflow
それだと、別にキャッシュは使ってもらって構わないなぁ。
むしろ、キャッシュ使ってもいいから早く接続完了させておくれ、というくらいだ。
まあ、サービス走査は接続した後だけどね。。。
書いてあったメソッドをそのままコピーして呼び出してみたが、うん、早くはならなかったよ。
わからんかった。
悔しいが、保留だ。
だれか教えてくだされ～～～
