Hi Jeffrey,
Characteristics changing in a way that the handles range wouldn't
change is probably near impossible right now, service normally are
register and unregistered including all attributes in most systems
since the service handles needs to be continuous when you discover
them. Also service definitions are normally static, have been since
classic, which is perhaps the reason service changed shall carry the
start and end handle of the entire service as it doesn't expect
internal changes to service as it would things a lot more complicated.
Regarding the bond, I don't think we need to add anything actually, in
BlueZ the cache is not really tied to the bonding information and wont
be loaded until the device is connected again. That being said perhaps
you are talking about a feature of remembering devices even if is not
paired/bonded, I wouldn't call this a bond because that is different
than what the spec suggest, so that perhaps don't have to be exposed.
From what I could test with chrome 50 under Linux it does appear to
get the list of devices from BlueZ regardless if they were bonded or
not which I find it great.
Regarding the service-changed events, I remember seems them handled in
the bottom layer at least, it is actually used to build the list of
services in case of getPrimaryService, etc. So perhaps it is just a
matter to forwarding them to the application somehow, but perhaps you
only want to do that if is actually a UUID the application is
interested.
--
Luiz Augusto von Dentz