Cannot conditionally disable pairing with bluetooth classic (bluedroid) (IDFGH-14491)

[vlang-intona]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

I'm testing pairing by connecting from a macOS computer to an ESP32 board, which implements an A2DP sink. I want the following pairing behavior:

• if a button (or similar condition) on the ESP32 board is pressed during the connection attempt, pairing should just work (no pin entry, just connecting)
• if the button is not pressed, only already bonded devices should be able to connect

For this, I would need to be able to programmatically change pair-ability at runtime with the "just works" method. But ESP32 does not seem to support this.

Running this at initialization makes pairing "just work":

esp_bt_sp_param_t param_type = ESP_BT_SP_IOCAP_MODE;
esp_bt_io_cap_t iocap = ESP_BT_IO_CAP_NONE;
esp_bt_gap_set_security_param(param_type, &iocap, sizeof(uint8_t));

This behavior is fine if the button is pressed. But if the button is not pressed, I need a way to reject not-yet-bonded devices.

Is this just a missing feature? I must have missed something obvious. At least I didn't find anything after spending a lot of time searching the documentation and the internet (where I only found people with the same problem).

I tried working this around by changing it do ESP_BT_IO_CAP_IO at runtime, which would effectively force pin entry. Then I rejected the attempt in the ESP_BT_GAP_CFM_REQ_EVT handler. But this does not seem to allow already bonded devices to connect anyway. (Either ESP32 rejected this because of the settings change, or I made a mistake. But even if it worked, this isn't an ideal solution.)

My next hack idea would be to disconnect the device in response to ESP_BT_GAP_AUTH_CMPL_EVT, which would be even hackier and extremely questionable in multiple ways, but at least it would get the job done.

I'm also confused that this document talks about the device with the yes/no button, but there's no explanation how to achieve it, and instead goes on about things irrelevant to the ESP32 API user:

https://github.com/espressif/esp-idf/blob/master/examples/bluetooth/bluedroid/classic_bt/bt_spp_acceptor/ESP32_SSP.md