BLE advertising data flags field and discovery

Question

For the BLE GAP advertising flags byte in the advertising data, we have the following options: 
 /**@defgroup BLE_GAP_ADV_FLAGS GAP Advertisement Flags
 * @{ */
#define BLE_GAP_ADV_FLAG_LE_LIMITED_DISC_MODE (0x01) /**< LE Limited Discoverable Mode. */
#define BLE_GAP_ADV_FLAG_LE_GENERAL_DISC_MODE (0x02) /**< LE General Discoverable Mode. */
#define BLE_GAP_ADV_FLAG_BR_EDR_NOT_SUPPORTED (0x04) /**< BR/EDR not supported. */
#define BLE_GAP_ADV_FLAG_LE_BR_EDR_CONTROLLER (0x08) /**< Simultaneous LE and BR/EDR, Controller. */
#define BLE_GAP_ADV_FLAG_LE_BR_EDR_HOST (0x10) /**< Simultaneous LE and BR/EDR, Host. */
#define BLE_GAP_ADV_FLAGS_LE_ONLY_LIMITED_DISC_MODE (BLE_GAP_ADV_FLAG_LE_LIMITED_DISC_MODE | BLE_GAP_ADV_FLAG_BR_EDR_NOT_SUPPORTED) /**< LE Limited Discoverable Mode, BR/EDR not supported. */
#define BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE (BLE_GAP_ADV_FLAG_LE_GENERAL_DISC_MODE | BLE_GAP_ADV_FLAG_BR_EDR_NOT_SUPPORTED) /**< LE General Discoverable Mode, BR/EDR not supported. */
/**@} */
 
 So this byte mixes two concepts: 
 
 Discoverability (non-discoverable vs. limited vs. general) 
 Bluetooth LE vs. Bluetooth Classic. 
 
 By setting this flag only: 
 BLE_GAP_ADV_FLAG_BR_EDR_NOT_SUPPORTED
 
 we've specified that we're a BLE device and not a Bluetooth Classic device, but we've said nothing about discoverability. Does the central interpret that to mean that the peripheral is non-discoverable and it should not attempt to perform service discovery after connection? 
 Testing use the nRF Connect Android app and my own custom app, that's not the behaviour I'm seeing. Both will happily perform service discovery after connecting. I'm testing this with a BLE MAC address that hasn't been connected to or bonded with by the central before, so I don't think a cache in the BLE stack on the central is affecting what I'm seeing. 
 Secondly, what really is the difference between limited and general discoverability? I've read the spec on it and I still don't understand it (Vol 3, part C, section 4.1). (That section also suggests that if we set neither limited nor general here, the peripheral is non-discoverable.)

run_ar · Accepted Answer

I think these flags is meant as a help to the scanner to see which advertisements to prioritize. Basically all advertisements are visible to all scanners. But the scanners can assume that: 
 
 if the Limited discoverable mode is used the device will only advertise for a limited amount of time. e.g. the user has put the device in bondable mode or some other time limited mode. 
 If a scanner sees a "non discoverable" advertisement it can assume this device uses a whitelist or for some other reason is not connectable. So it can save power by not trying to connect. 
 But I'm afraid the behavior will depend on the implementation, as it's up to the developer to use these flags correctly. Unless you are implementing a sig define profile with given requirements for flags. 
 
 Regardless I don't think there is anything wrong with Android or iOS when allowing you to connect to these devices. Hopefully the flags is forwarded to the application (looks like both Android and iOS forwards a string with the content of the ad packet), so the application can choose what to do. 
 Not sure why you are talking about service discovery. That seems unrelated to me, and should be performed after connecting, at least when connecting to an unknown device.