[APP-7946] Additional Bluetooth Provisioning Changes #96
Conversation
Otterverse
force-pushed
the
james-btfixes
branch
from
b7c395f to
9f14044
Compare
| manufacturerKey = "manufacturer" | ||
| modelKey = "model" | ||
| fragmentKey = "fragment_id" |
There was a problem hiding this comment.
Making a change on my end to read the fragment id, should i read the manufacturer and model for any reason? The only thing I could think of was for displaying it in the UI in some way (from my perspective)
There was a problem hiding this comment.
Think I got an answer here! https://github.com/viamrobotics/canyon-runner-mobile/pull/190#discussion_r2043267806
There was a problem hiding this comment.
These are purely informative for generic whitelabeling purposes. Safe to ignore, but I wanted to match parity with with web/grpc provisioning APIs.
| @@ -13,6 +13,7 @@ SERVICE_FILE=$(cat <<EOF | |||
| [Unit] | |||
| Description=Viam Services Agent | |||
| After=NetworkManager.service | |||
| After=bluetooth.service | |||
There was a problem hiding this comment.
thinking through consequences of the After
systemd docs for After directive
it sounds like this is only respected if 'both units are being started' (i.e. systems without bluetooth will still be able to start agent)
note this has potential to delay startup on systems which have bluetooth -- this is not a merge blocker, but consider pinging SEs before actually releasing this
There was a problem hiding this comment.
Yes, it used to be "Wants=NetworkManager" and that caused problems for systems without. After means "if you're starting it anyway, sequence."
I did a couple timing tests, bluetooth starts up in basically the same second as NetworkManager on my Pi (same timestamp) so I don't think the delay is an issue. And it's definitely an issue if bluetooth provisioning fails to work because it started up in the wrong order. Will definitely let SE know anyway.
| return errw.Wrap(err, "registering custom agent") | ||
| } | ||
|
|
||
| call = obj.Call("org.bluez.AgentManager1.RequestDefaultAgent", 0, dbus.ObjectPath(BluezAgentPath)) |
There was a problem hiding this comment.
[q] Any reason to make your NoInputNoOutput agent the default agent on the device? Were you having issues without this?
There was a problem hiding this comment.
The normal "register agent" functions in other libraries all do this. The idea was maybe I could hook the incoming requests from the pop-up. Otherwise, the registered agent is supposed to ONLY deal with pairing requests our app initiates (and we don't initiate pairing requests ourselves.) Feel free to play around with it.
Further work to support the bluetooth provisioning method and integrate with the bluetooth socks proxy work.