| Message ID | 20200401221434.12185-1-sonnysasaka@chromium.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/5] D-Bus API changes for managing SDP records | expand |
Hi Sonny, > This defines the DBus API that we'll use with BlueZ to create, remove > and get service records. > --- > doc/adapter-api.txt | 46 +++++++++++++++++++++++++++++++++++++++++++++ > doc/device-api.txt | 37 ++++++++++++++++++++++++++++++++++++ > 2 files changed, 83 insertions(+) > > diff --git a/doc/adapter-api.txt b/doc/adapter-api.txt > index acae032d9..6e4c37fc9 100644 > --- a/doc/adapter-api.txt > +++ b/doc/adapter-api.txt > @@ -204,6 +204,52 @@ Methods void StartDiscovery() > org.bluez.Error.NotReady > org.bluez.Error.Failed > > + uint32 CreateServiceRecord(dict record) > + > + This method creates an entry with the local SDP server > + for this adapter for the specified record. This method > + will only create the SDP record and not start listening > + on any ports. It is up to the caller of the method to > + ensure the validity of the service record. This record > + will not be parsed for any validation but will instead > + directly be inserted into the local SDP server’s > + records. > + > + The return value from this method will be the 32 bit > + handle for the created service record. > + > + The record dictionary will have dictionary entries of > + the format: {id : (type, size, value)}, where, > + > + uint16 id: The 16 bit attribute ID for an > + attribute. > + uint8 type: This will contain the type of the > + attribute value. Attribute type values > + are defined in the Bluetooth spec in > + Volume 3, Part B, 3.2. > + uint32 size: This is the size of the attribute > + value. > + variant value: This will contain the attribute value > + for a given attribute_id. This variant > + can either contain a primitive type, or > + if type is SEQUENCE, an array of struct > + of the signature (type, size, value). > + > + Possible errors: org.bluez.Error.NotReady > + org.bluez.Error.AlreadyExists > + org.bluez.Error.Failed > + org.bluez.Error.InvalidArguments > + > + void RemoveServiceRecord(uint32 handle) > + > + This method removes the SDP record with the given > + handle from the local SDP server. > + > + Possible errors: org.bluez.Error.NotReady > + org.bluez.Error.DoesNotExist > + org.bluez.Error.Failed > + org.bluez.Error.InvalidArguments > + so when design the BlueZ 5.x APIs, we on purpose didn’t do this. You are suppose to use doc/profile-api.txt for these kind of things. I am not in favor of dangling SDP records where we have no lifetime guarantee of the service behind it. If you look at profiles/iap/main.c then you see how you could write a vendor profile just as easily. That one is the skeleton for iOS accessory protocol over Bluetooth. > Properties string Address [readonly] > > The Bluetooth device address. > diff --git a/doc/device-api.txt b/doc/device-api.txt > index ceb68d2f6..e8f2c670d 100644 > --- a/doc/device-api.txt > +++ b/doc/device-api.txt > @@ -120,6 +120,43 @@ Methods void Connect() > Possible errors: org.bluez.Error.DoesNotExist > org.bluez.Error.Failed > > + array{array{dict}} GetServiceRecords() > + > + This method returns the complete service records of all > + discovered BR/EDR services of the connected device till > + now. The return value will be an array of an array of > + dictionary entries. Each nested array of dictionary > + entries will contain one service record. Each pair in > + the returned dictionary entries will represent an > + attribute in the service record. > + > + The dictionary entries in the returned array of entries > + will be of the format: {id : (type, size, value)} where, > + > + uint16 id: The 16 bit attribute ID for an > + attribute. > + uint8 type: This will contain the type of the > + attribute value. Attribute type values > + are defined in the Bluetooth spec in > + Volume 3, Part B, 3.2. > + uint32 size: This is the size of the attribute > + value. > + variant value: This will contain the attribute value > + for a given attribute_id. This variant > + can either contain a primitive type, or > + if type is SEQUENCE, an array of struct > + of the signature (type, size, value). > + > + Since the service record contains the service UUID and > + name, these fields do not need to be given separately. > + This method should be called after the ServiceResolved > + property for this object has been set to true otherwise > + it may return a partial or stale cached list. > + > + Possible errors: org.bluez.Error.NotReady > + org.bluez.Error.NotConnected > + org.bluez.Error.Failed > + These two things are not related and do not belong in the same patch. However what is your goal behind this API since even here we tried not to give raw SDP to the application. It is all baked into the Profile API. Regards Marcel
Hi Marcel, This was needed to support emulation of Android apps's Bluetooth API on top of BlueZ. Android expects to be able to access the SDP database of a remote device via its HAL interface (https://android.googlesource.com/platform/system/bt/+/master/include/hardware/bt_sdp.h#38). Thanks for the feedback, we will revisit this and see if a redesign based on your suggestion is possible. On Thu, Apr 9, 2020 at 11:05 AM Marcel Holtmann <marcel@holtmann.org> wrote: > > Hi Sonny, > > > This defines the DBus API that we'll use with BlueZ to create, remove > > and get service records. > > --- > > doc/adapter-api.txt | 46 +++++++++++++++++++++++++++++++++++++++++++++ > > doc/device-api.txt | 37 ++++++++++++++++++++++++++++++++++++ > > 2 files changed, 83 insertions(+) > > > > diff --git a/doc/adapter-api.txt b/doc/adapter-api.txt > > index acae032d9..6e4c37fc9 100644 > > --- a/doc/adapter-api.txt > > +++ b/doc/adapter-api.txt > > @@ -204,6 +204,52 @@ Methods void StartDiscovery() > > org.bluez.Error.NotReady > > org.bluez.Error.Failed > > > > + uint32 CreateServiceRecord(dict record) > > + > > + This method creates an entry with the local SDP server > > + for this adapter for the specified record. This method > > + will only create the SDP record and not start listening > > + on any ports. It is up to the caller of the method to > > + ensure the validity of the service record. This record > > + will not be parsed for any validation but will instead > > + directly be inserted into the local SDP server’s > > + records. > > + > > + The return value from this method will be the 32 bit > > + handle for the created service record. > > + > > + The record dictionary will have dictionary entries of > > + the format: {id : (type, size, value)}, where, > > + > > + uint16 id: The 16 bit attribute ID for an > > + attribute. > > + uint8 type: This will contain the type of the > > + attribute value. Attribute type values > > + are defined in the Bluetooth spec in > > + Volume 3, Part B, 3.2. > > + uint32 size: This is the size of the attribute > > + value. > > + variant value: This will contain the attribute value > > + for a given attribute_id. This variant > > + can either contain a primitive type, or > > + if type is SEQUENCE, an array of struct > > + of the signature (type, size, value). > > + > > + Possible errors: org.bluez.Error.NotReady > > + org.bluez.Error.AlreadyExists > > + org.bluez.Error.Failed > > + org.bluez.Error.InvalidArguments > > + > > + void RemoveServiceRecord(uint32 handle) > > + > > + This method removes the SDP record with the given > > + handle from the local SDP server. > > + > > + Possible errors: org.bluez.Error.NotReady > > + org.bluez.Error.DoesNotExist > > + org.bluez.Error.Failed > > + org.bluez.Error.InvalidArguments > > + > > so when design the BlueZ 5.x APIs, we on purpose didn’t do this. You are suppose to use doc/profile-api.txt for these kind of things. > > I am not in favor of dangling SDP records where we have no lifetime guarantee of the service behind it. > > If you look at profiles/iap/main.c then you see how you could write a vendor profile just as easily. That one is the skeleton for iOS accessory protocol over Bluetooth. > > > Properties string Address [readonly] > > > > The Bluetooth device address. > > diff --git a/doc/device-api.txt b/doc/device-api.txt > > index ceb68d2f6..e8f2c670d 100644 > > --- a/doc/device-api.txt > > +++ b/doc/device-api.txt > > @@ -120,6 +120,43 @@ Methods void Connect() > > Possible errors: org.bluez.Error.DoesNotExist > > org.bluez.Error.Failed > > > > + array{array{dict}} GetServiceRecords() > > + > > + This method returns the complete service records of all > > + discovered BR/EDR services of the connected device till > > + now. The return value will be an array of an array of > > + dictionary entries. Each nested array of dictionary > > + entries will contain one service record. Each pair in > > + the returned dictionary entries will represent an > > + attribute in the service record. > > + > > + The dictionary entries in the returned array of entries > > + will be of the format: {id : (type, size, value)} where, > > + > > + uint16 id: The 16 bit attribute ID for an > > + attribute. > > + uint8 type: This will contain the type of the > > + attribute value. Attribute type values > > + are defined in the Bluetooth spec in > > + Volume 3, Part B, 3.2. > > + uint32 size: This is the size of the attribute > > + value. > > + variant value: This will contain the attribute value > > + for a given attribute_id. This variant > > + can either contain a primitive type, or > > + if type is SEQUENCE, an array of struct > > + of the signature (type, size, value). > > + > > + Since the service record contains the service UUID and > > + name, these fields do not need to be given separately. > > + This method should be called after the ServiceResolved > > + property for this object has been set to true otherwise > > + it may return a partial or stale cached list. > > + > > + Possible errors: org.bluez.Error.NotReady > > + org.bluez.Error.NotConnected > > + org.bluez.Error.Failed > > + > > These two things are not related and do not belong in the same patch. However what is your goal behind this API since even here we tried not to give raw SDP to the application. It is all baked into the Profile API. > > Regards > > Marcel >
Hi Sonny, On Thu, Apr 9, 2020 at 11:28 AM Sonny Sasaka <sonnysasaka@chromium.org> wrote: > > Hi Marcel, > > This was needed to support emulation of Android apps's Bluetooth API > on top of BlueZ. Android expects to be able to access the SDP database > of a remote device via its HAL interface > (https://android.googlesource.com/platform/system/bt/+/master/include/hardware/bt_sdp.h#38). I suppose you could read the cache directly, though there is no guarantee that we won't change the format of that, btw I suppose services handled by the daemon should not be exposed to the Android side otherwise you may have conflicts so going with Profile interface is probably the way to go, but you will need to know the UUIDs that would be handled by Android. > Thanks for the feedback, we will revisit this and see if a redesign > based on your suggestion is possible. > > On Thu, Apr 9, 2020 at 11:05 AM Marcel Holtmann <marcel@holtmann.org> wrote: > > > > Hi Sonny, > > > > > This defines the DBus API that we'll use with BlueZ to create, remove > > > and get service records. > > > --- > > > doc/adapter-api.txt | 46 +++++++++++++++++++++++++++++++++++++++++++++ > > > doc/device-api.txt | 37 ++++++++++++++++++++++++++++++++++++ > > > 2 files changed, 83 insertions(+) > > > > > > diff --git a/doc/adapter-api.txt b/doc/adapter-api.txt > > > index acae032d9..6e4c37fc9 100644 > > > --- a/doc/adapter-api.txt > > > +++ b/doc/adapter-api.txt > > > @@ -204,6 +204,52 @@ Methods void StartDiscovery() > > > org.bluez.Error.NotReady > > > org.bluez.Error.Failed > > > > > > + uint32 CreateServiceRecord(dict record) > > > + > > > + This method creates an entry with the local SDP server > > > + for this adapter for the specified record. This method > > > + will only create the SDP record and not start listening > > > + on any ports. It is up to the caller of the method to > > > + ensure the validity of the service record. This record > > > + will not be parsed for any validation but will instead > > > + directly be inserted into the local SDP server’s > > > + records. > > > + > > > + The return value from this method will be the 32 bit > > > + handle for the created service record. > > > + > > > + The record dictionary will have dictionary entries of > > > + the format: {id : (type, size, value)}, where, > > > + > > > + uint16 id: The 16 bit attribute ID for an > > > + attribute. > > > + uint8 type: This will contain the type of the > > > + attribute value. Attribute type values > > > + are defined in the Bluetooth spec in > > > + Volume 3, Part B, 3.2. > > > + uint32 size: This is the size of the attribute > > > + value. > > > + variant value: This will contain the attribute value > > > + for a given attribute_id. This variant > > > + can either contain a primitive type, or > > > + if type is SEQUENCE, an array of struct > > > + of the signature (type, size, value). > > > + > > > + Possible errors: org.bluez.Error.NotReady > > > + org.bluez.Error.AlreadyExists > > > + org.bluez.Error.Failed > > > + org.bluez.Error.InvalidArguments > > > + > > > + void RemoveServiceRecord(uint32 handle) > > > + > > > + This method removes the SDP record with the given > > > + handle from the local SDP server. > > > + > > > + Possible errors: org.bluez.Error.NotReady > > > + org.bluez.Error.DoesNotExist > > > + org.bluez.Error.Failed > > > + org.bluez.Error.InvalidArguments > > > + > > > > so when design the BlueZ 5.x APIs, we on purpose didn’t do this. You are suppose to use doc/profile-api.txt for these kind of things. > > > > I am not in favor of dangling SDP records where we have no lifetime guarantee of the service behind it. > > > > If you look at profiles/iap/main.c then you see how you could write a vendor profile just as easily. That one is the skeleton for iOS accessory protocol over Bluetooth. > > > > > Properties string Address [readonly] > > > > > > The Bluetooth device address. > > > diff --git a/doc/device-api.txt b/doc/device-api.txt > > > index ceb68d2f6..e8f2c670d 100644 > > > --- a/doc/device-api.txt > > > +++ b/doc/device-api.txt > > > @@ -120,6 +120,43 @@ Methods void Connect() > > > Possible errors: org.bluez.Error.DoesNotExist > > > org.bluez.Error.Failed > > > > > > + array{array{dict}} GetServiceRecords() > > > + > > > + This method returns the complete service records of all > > > + discovered BR/EDR services of the connected device till > > > + now. The return value will be an array of an array of > > > + dictionary entries. Each nested array of dictionary > > > + entries will contain one service record. Each pair in > > > + the returned dictionary entries will represent an > > > + attribute in the service record. > > > + > > > + The dictionary entries in the returned array of entries > > > + will be of the format: {id : (type, size, value)} where, > > > + > > > + uint16 id: The 16 bit attribute ID for an > > > + attribute. > > > + uint8 type: This will contain the type of the > > > + attribute value. Attribute type values > > > + are defined in the Bluetooth spec in > > > + Volume 3, Part B, 3.2. > > > + uint32 size: This is the size of the attribute > > > + value. > > > + variant value: This will contain the attribute value > > > + for a given attribute_id. This variant > > > + can either contain a primitive type, or > > > + if type is SEQUENCE, an array of struct > > > + of the signature (type, size, value). > > > + > > > + Since the service record contains the service UUID and > > > + name, these fields do not need to be given separately. > > > + This method should be called after the ServiceResolved > > > + property for this object has been set to true otherwise > > > + it may return a partial or stale cached list. > > > + > > > + Possible errors: org.bluez.Error.NotReady > > > + org.bluez.Error.NotConnected > > > + org.bluez.Error.Failed > > > + > > > > These two things are not related and do not belong in the same patch. However what is your goal behind this API since even here we tried not to give raw SDP to the application. It is all baked into the Profile API. > > > > Regards > > > > Marcel > >
Thanks for the feedback, Luiz. We will explore the ways you all suggested. On Thu, Apr 9, 2020 at 11:35 AM Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > > Hi Sonny, > > On Thu, Apr 9, 2020 at 11:28 AM Sonny Sasaka <sonnysasaka@chromium.org> wrote: > > > > Hi Marcel, > > > > This was needed to support emulation of Android apps's Bluetooth API > > on top of BlueZ. Android expects to be able to access the SDP database > > of a remote device via its HAL interface > > (https://android.googlesource.com/platform/system/bt/+/master/include/hardware/bt_sdp.h#38). > > I suppose you could read the cache directly, though there is no > guarantee that we won't change the format of that, btw I suppose > services handled by the daemon should not be exposed to the Android > side otherwise you may have conflicts so going with Profile interface > is probably the way to go, but you will need to know the UUIDs that > would be handled by Android. > > > Thanks for the feedback, we will revisit this and see if a redesign > > based on your suggestion is possible. > > > > On Thu, Apr 9, 2020 at 11:05 AM Marcel Holtmann <marcel@holtmann.org> wrote: > > > > > > Hi Sonny, > > > > > > > This defines the DBus API that we'll use with BlueZ to create, remove > > > > and get service records. > > > > --- > > > > doc/adapter-api.txt | 46 +++++++++++++++++++++++++++++++++++++++++++++ > > > > doc/device-api.txt | 37 ++++++++++++++++++++++++++++++++++++ > > > > 2 files changed, 83 insertions(+) > > > > > > > > diff --git a/doc/adapter-api.txt b/doc/adapter-api.txt > > > > index acae032d9..6e4c37fc9 100644 > > > > --- a/doc/adapter-api.txt > > > > +++ b/doc/adapter-api.txt > > > > @@ -204,6 +204,52 @@ Methods void StartDiscovery() > > > > org.bluez.Error.NotReady > > > > org.bluez.Error.Failed > > > > > > > > + uint32 CreateServiceRecord(dict record) > > > > + > > > > + This method creates an entry with the local SDP server > > > > + for this adapter for the specified record. This method > > > > + will only create the SDP record and not start listening > > > > + on any ports. It is up to the caller of the method to > > > > + ensure the validity of the service record. This record > > > > + will not be parsed for any validation but will instead > > > > + directly be inserted into the local SDP server’s > > > > + records. > > > > + > > > > + The return value from this method will be the 32 bit > > > > + handle for the created service record. > > > > + > > > > + The record dictionary will have dictionary entries of > > > > + the format: {id : (type, size, value)}, where, > > > > + > > > > + uint16 id: The 16 bit attribute ID for an > > > > + attribute. > > > > + uint8 type: This will contain the type of the > > > > + attribute value. Attribute type values > > > > + are defined in the Bluetooth spec in > > > > + Volume 3, Part B, 3.2. > > > > + uint32 size: This is the size of the attribute > > > > + value. > > > > + variant value: This will contain the attribute value > > > > + for a given attribute_id. This variant > > > > + can either contain a primitive type, or > > > > + if type is SEQUENCE, an array of struct > > > > + of the signature (type, size, value). > > > > + > > > > + Possible errors: org.bluez.Error.NotReady > > > > + org.bluez.Error.AlreadyExists > > > > + org.bluez.Error.Failed > > > > + org.bluez.Error.InvalidArguments > > > > + > > > > + void RemoveServiceRecord(uint32 handle) > > > > + > > > > + This method removes the SDP record with the given > > > > + handle from the local SDP server. > > > > + > > > > + Possible errors: org.bluez.Error.NotReady > > > > + org.bluez.Error.DoesNotExist > > > > + org.bluez.Error.Failed > > > > + org.bluez.Error.InvalidArguments > > > > + > > > > > > so when design the BlueZ 5.x APIs, we on purpose didn’t do this. You are suppose to use doc/profile-api.txt for these kind of things. > > > > > > I am not in favor of dangling SDP records where we have no lifetime guarantee of the service behind it. > > > > > > If you look at profiles/iap/main.c then you see how you could write a vendor profile just as easily. That one is the skeleton for iOS accessory protocol over Bluetooth. > > > > > > > Properties string Address [readonly] > > > > > > > > The Bluetooth device address. > > > > diff --git a/doc/device-api.txt b/doc/device-api.txt > > > > index ceb68d2f6..e8f2c670d 100644 > > > > --- a/doc/device-api.txt > > > > +++ b/doc/device-api.txt > > > > @@ -120,6 +120,43 @@ Methods void Connect() > > > > Possible errors: org.bluez.Error.DoesNotExist > > > > org.bluez.Error.Failed > > > > > > > > + array{array{dict}} GetServiceRecords() > > > > + > > > > + This method returns the complete service records of all > > > > + discovered BR/EDR services of the connected device till > > > > + now. The return value will be an array of an array of > > > > + dictionary entries. Each nested array of dictionary > > > > + entries will contain one service record. Each pair in > > > > + the returned dictionary entries will represent an > > > > + attribute in the service record. > > > > + > > > > + The dictionary entries in the returned array of entries > > > > + will be of the format: {id : (type, size, value)} where, > > > > + > > > > + uint16 id: The 16 bit attribute ID for an > > > > + attribute. > > > > + uint8 type: This will contain the type of the > > > > + attribute value. Attribute type values > > > > + are defined in the Bluetooth spec in > > > > + Volume 3, Part B, 3.2. > > > > + uint32 size: This is the size of the attribute > > > > + value. > > > > + variant value: This will contain the attribute value > > > > + for a given attribute_id. This variant > > > > + can either contain a primitive type, or > > > > + if type is SEQUENCE, an array of struct > > > > + of the signature (type, size, value). > > > > + > > > > + Since the service record contains the service UUID and > > > > + name, these fields do not need to be given separately. > > > > + This method should be called after the ServiceResolved > > > > + property for this object has been set to true otherwise > > > > + it may return a partial or stale cached list. > > > > + > > > > + Possible errors: org.bluez.Error.NotReady > > > > + org.bluez.Error.NotConnected > > > > + org.bluez.Error.Failed > > > > + > > > > > > These two things are not related and do not belong in the same patch. However what is your goal behind this API since even here we tried not to give raw SDP to the application. It is all baked into the Profile API. > > > > > > Regards > > > > > > Marcel > > > > > > > -- > Luiz Augusto von Dentz
Hi Sonny, > This was needed to support emulation of Android apps's Bluetooth API > on top of BlueZ. Android expects to be able to access the SDP database > of a remote device via its HAL interface > (https://android.googlesource.com/platform/system/bt/+/master/include/hardware/bt_sdp.h#38). > > Thanks for the feedback, we will revisit this and see if a redesign > based on your suggestion is possible. if you can get this done by using existing APIs and the Profile API, then that would be best. I would have to get myself a bit more familiar with the Android APIs. However in the worst case, we can introduce an Android specific D-Bus API as part of a plugin. It would be then disabled in standard Linux systems. From BlueZ for Android project, we fundamentally took the Android HAL parts 1:1 and mapped them to a Unix based protocol. Then the Android bluetoothd had to do the rest of the work. A similar approach (and using D-Bus) might be most efficient here actually. However as Luiz noted, we need to be careful that bluetoothd system services / profiles are not messed with. Meaning bluetoothd has to play guardian on what Android apps can do. On a side note, I am going to remove the BlueZ for Android code from the tree. Let me know if you find parts of it still useful. It is git, so we can always bring it back, but if you already have some idea on how to utilize it, feel free to start with that right away. Regards Marcel
diff --git a/doc/adapter-api.txt b/doc/adapter-api.txt index acae032d9..6e4c37fc9 100644 --- a/doc/adapter-api.txt +++ b/doc/adapter-api.txt @@ -204,6 +204,52 @@ Methods void StartDiscovery() org.bluez.Error.NotReady org.bluez.Error.Failed + uint32 CreateServiceRecord(dict record) + + This method creates an entry with the local SDP server + for this adapter for the specified record. This method + will only create the SDP record and not start listening + on any ports. It is up to the caller of the method to + ensure the validity of the service record. This record + will not be parsed for any validation but will instead + directly be inserted into the local SDP server’s + records. + + The return value from this method will be the 32 bit + handle for the created service record. + + The record dictionary will have dictionary entries of + the format: {id : (type, size, value)}, where, + + uint16 id: The 16 bit attribute ID for an + attribute. + uint8 type: This will contain the type of the + attribute value. Attribute type values + are defined in the Bluetooth spec in + Volume 3, Part B, 3.2. + uint32 size: This is the size of the attribute + value. + variant value: This will contain the attribute value + for a given attribute_id. This variant + can either contain a primitive type, or + if type is SEQUENCE, an array of struct + of the signature (type, size, value). + + Possible errors: org.bluez.Error.NotReady + org.bluez.Error.AlreadyExists + org.bluez.Error.Failed + org.bluez.Error.InvalidArguments + + void RemoveServiceRecord(uint32 handle) + + This method removes the SDP record with the given + handle from the local SDP server. + + Possible errors: org.bluez.Error.NotReady + org.bluez.Error.DoesNotExist + org.bluez.Error.Failed + org.bluez.Error.InvalidArguments + Properties string Address [readonly] The Bluetooth device address. diff --git a/doc/device-api.txt b/doc/device-api.txt index ceb68d2f6..e8f2c670d 100644 --- a/doc/device-api.txt +++ b/doc/device-api.txt @@ -120,6 +120,43 @@ Methods void Connect() Possible errors: org.bluez.Error.DoesNotExist org.bluez.Error.Failed + array{array{dict}} GetServiceRecords() + + This method returns the complete service records of all + discovered BR/EDR services of the connected device till + now. The return value will be an array of an array of + dictionary entries. Each nested array of dictionary + entries will contain one service record. Each pair in + the returned dictionary entries will represent an + attribute in the service record. + + The dictionary entries in the returned array of entries + will be of the format: {id : (type, size, value)} where, + + uint16 id: The 16 bit attribute ID for an + attribute. + uint8 type: This will contain the type of the + attribute value. Attribute type values + are defined in the Bluetooth spec in + Volume 3, Part B, 3.2. + uint32 size: This is the size of the attribute + value. + variant value: This will contain the attribute value + for a given attribute_id. This variant + can either contain a primitive type, or + if type is SEQUENCE, an array of struct + of the signature (type, size, value). + + Since the service record contains the service UUID and + name, these fields do not need to be given separately. + This method should be called after the ServiceResolved + property for this object has been set to true otherwise + it may return a partial or stale cached list. + + Possible errors: org.bluez.Error.NotReady + org.bluez.Error.NotConnected + org.bluez.Error.Failed + Properties string Address [readonly] The Bluetooth device address of the remote device.
From: Rahul Chaturvedi <rkc@google.com> This defines the DBus API that we'll use with BlueZ to create, remove and get service records. --- doc/adapter-api.txt | 46 +++++++++++++++++++++++++++++++++++++++++++++ doc/device-api.txt | 37 ++++++++++++++++++++++++++++++++++++ 2 files changed, 83 insertions(+)