Issues with BLE AutoConnect: Directed Advertising (Error 60) vs. Filter Accept List on Android

[Marcos Carballo]

I am working with:

• NCS Version: 2.6.1 (SoftDevice Controller)
• Hardware: nRF52x Platform

on a custom board (nRF52 series) and I'm trying to achieve a "Headphones-like" reconnection experience. My goal is to have the device automatically reconnect to its last bonded owner as soon as it powers on, without manual intervention in the phone's UI. 

I am not an Android App Developer, so I am relying on the OS/nRF Connect App behavior. Any advice on how to make my device "attractive" enough for the Android Bluetooth stack to reconnect natively would be greatly appreciated.

 

My Current Implementation:

I have confirmed that my bond management logic (saving/loading bonds via Settings) works perfectly. When using Normal Advertising + Filter Accept List (Whitelist), I can manually connect without issues, proving that the stored addresses are correct.

I use a 30-second window where the device tries to reconnect to the bonded peer before falling back to normal advertising. I’ve tested two methods

• Directed Advertising (ADV_DIRECT_IND): I consistently get Error 60 (ETIMEDOUT). I understand this has a 1.28s hardware limit, but even within that window, my Android phone fails to connect?.

  int err = bt_le_adv_start(
      BT_LE_ADV_PARAM(BT_LE_ADV_OPT_CONNECTABLE | BT_LE_ADV_OPT_DIR_ADDR_RPA,
                      BT_GAP_ADV_FAST_INT_MIN_2, BT_GAP_ADV_FAST_INT_MAX_2, &bond_addr),
      NULL, 0, NULL, 0);

• Filter Accept List (Whitelist): This works better for manual connections, but the Android Native AutoConnect (tested via nRF Connect App) is not triggering as expected unless the app is active.

  struct bt_le_adv_param param =
      *BT_LE_ADV_PARAM(BT_LE_ADV_OPT_CONNECTABLE | BT_LE_ADV_OPT_FILTER_CONN,
                       BT_GAP_ADV_FAST_INT_MIN_2, BT_GAP_ADV_FAST_INT_MAX_2, NULL);

  // Start the advertising
  err = bt_le_adv_start(&param, adv_data, adv_data_len, adv_response_data, adv_response_data_len);

My Questions:

• The AutoConnect in nRF Connect App (Android): Why does the AutoConnect feature in the nRF Connect App Android remain idle during my Filter Advertising or Direct Advertaising window? Is there a specific requirement (Flags, Appearance, or Service UUIDs) for the Android OS to "wake up" and initiate the connection?

• Why does Directed Advertising fail with Error 60? Is it because the phone's RPA resolution takes longer than the hardware timeout allowed by the stack?

• Native Reconnection: Why do commercial headphones reconnect to Android natively without any app open, while my GATT peripheral requires the nRF Connect App "AutoConnect" feature to be active? What specific Appearance or Services (like HID/HOGP) does Android look for to allow "App-less" reconnection?

• Filter Logic: Is it better to use Normal Advertising + Filter Accept List instead of Directed Advertising for better compatibility with Android’s background scanning?

[Simonr]

Hi Marcos

I think the auto connect issue you have is that the nRF Connect app doesn't scan unless you tell it to, usually by refreshing the SCANNER page by dragging it down, then it should auto-connect to a bonded board where you have checked this box.

Do you also make sure the Android device is actually scanning when you're trying to do direct advertising. I assume you do multiple attempts after one another when trying this? If not, you should make it try multiple times if it fails, and make sure the Android does scan for devices.

If I recall correctly, in order to achieve this app-less reconnection, there needs to be a HID device for it to auto register.

Generally, normal advertising and filtering is more common and popular in the industry than Direct advertising.

Best regards,

Simon