Device advertising a 128-bit service UUID is not discovered by the nRF Toolbox scan operation

[Acutetech]

nRF Toolbox scanner code does not seem to discover devices which advertise a 128-bit service UUID.

I have extended the Template app (within nRF Toolbox) to interact with my BLE device which advertises a
custom 128-bit service UUID (complete list, AD type 0x07). My app works as expected if the device has already
been bonded with my phone or tablet, but if it is not bonded then my device is not found during the scan operation.

When I change my device so it uses an arbitrary 16-bit service UUID (and advertises this in a complete list, AD Type 0x03)
then my Template app will discover it during the scan.

Note that when using the 128-bit service UUID my device is seen by the nRF Connect app, and I can use
nRF Connect to connect to my device and bond to it. After bonding, my device appears in the Bonded Devices list
of the Template app, and I can the connect to it, and all is well.

So: why does nRF Template not discover devices which advertise a 128-bit Service UUID, and how can I fix this?

This device is found (made-up 16-bit UUID = 0xfff0):
public final static UUID SERVICE_UUID = UUID.fromString("0000fff0-0000-1000-8000-00805f9b34fb");

This device is not found (custom 128-bit UUID) but does work if the device has bonded:
static final UUID SERVICE_UUID = UUID.fromString("55feb600-0030-11e7-93ae-92361f002671");

My device also advertises flags, local name, tx power and manufacturer data.

One other clue: when I use the 16-bit UUID then (a) the screen shows the RSSI graphic (even in the
Bonded Devices list) and (b) ScannerFragment ScanCallback onBatchResults() callback triggers with the device in the results.
When I use the 128-bit UUID neither of these happen. (The graphic is a result of the callback I think).

[Acutetech]

Hmmm... This was my bug - sorry.

Details: when I used the 128-bit service UUID I placed the wrong value in the advertising data, even though the correct value was in the GATT database. That explains why (a) my device was not found during scanning for advertisments but (b) why it would work OK once my device was present in the Bonded Devices list (since the advertisments were not checked, but the service discovery found the expected service).

When I used the 16-bit service UUID I placed the correct data in the advertisment data and the scan found my device. So it appeared like a problem with the phone scanning 128-bit UUIDs, but the real bug was in the contents of the 128-bit advertising data.