Recent content by fron

ふむ、私のテストではPAIRING_REQUESTではトリガーが2回発火し、BOND_STATE_CHANGEDではうまく動作していました。どちらのトリガーも不安定で信頼できないということがわかりました。 今回の手法は、結局のところデバイスに接続時トリガーの発火は防げず、続く処理の横槍でマクロを中断させています。特定のアプリがこれらの標準的な機能を妨げてしまう場合には適用できないでしょう。確実な方法は @MacroDroidDev がデバイスに接続時トリガーを改造することだけと言うしかありません。...

時間をかけて判定するならACTION_PAIRING_REQUESTが使えます。 インテント受信トリガーに指定する文字列：android.bluetooth.device.action.PAIRING_REQUEST これは、ペアリング要求の通知が送られるときに発生します。BOND_STATE_CHANGEDとどちらが早いかはわかりませんが発生タイミングが明確なのでもっと単純なマクロにできます。

このhackは複数のトリガーが同時に発生した場合、最後のトリガーのみ発火するという仕様を使っています。 発生順序は理論立って正確ですが、それが同時と認識されるかどうかは端末の性能に大きく影響を受けるでしょう。

改めて資料を読み込んでみました。 アプリケーションでペア済みであるかを確認する方法のサンプルが公式にあるので、MacroDroidに実装されることを期待しましょう。 https://developer.android.com/guide/topics/connectivity/bluetooth?hl=ja#QueryPairedDevices また、現在のバージョンのMacroDroidで実現する方法を発見しました。 インテント受信トリガーに指定している文字列：android.bluetooth.device.action.BOND_STATE_CHANGED...

検証他、ありがとうございます。 とするとやはり、（私の想像するところとも違っていましたが）バグではなさそうですね。androidの仕様からすれば想定どおり「デバイス接続時」にトリガーされている。この「デバイス接続時」がユーザーが思うタイミングと違うという話ですね。 通信の段階を考えれば、未接続状態→通信のある状態→ペアリング状態→機器が使用可能になった状態と遷移するはずです。この件は「デバイス接続時」がどのタイミングなのかしっかり把握する必要があると思います。...

ペアリング済みでないデバイスは接続できないのでは？ androidの仕組みにそこまで詳しいわけではありませんが、機械的な仕組みを考えたとき、デバイス接続のタイミングでそれが初回ペアリング直後のものかどうかという処理は不要に思います。何かそのような処理が必要であればペアリングの時にやればいいので。 当然、デバイス接続という処理が起こればそのデバイスはペアリング済みとなるわけで、トリガーの仕組みがこのようなものであれば動作自体は正常でしょう。 要望はあってしかるべきものでしょうが不具合だ、バグだというのは早計では？