TI中文支持网Hi,Ti员工,
我在论坛上看到了关于Connections may drop after connecting with Android 7+ devices这个问题的描述，我查阅了LPRF BLE Porting project的内容：
Connections may drop after connecting with Android 7+ devices. This issues presents when SNV flash memory has high utilization from either large numbers of pairing / bonding sequences and/or high write usage of customer NV IDs. These operations can lead to large numbers of discarded records and excessive SNV record lookup times which can impact protocol stack realtime operations during a connection. To fix, apply the optimization to the findItem() function as described and attached in this E2E forum post
我想知道，对于两边都是CC2541的设备，如果也存在一些customer NV id的存储，读取，配对绑定过程，是否也会发生连接断开的情况。
谢谢。
Susan Yang：
若是您的DEFAULT_BONDING_MODE 设置为true的时候，是会记录绑定信息的，重连之后不需要再重新配对。重新刷程序会把绑定信息刷掉，这样连接是需要重新配对的，但理论上不会出现连接断开的情况。您的从机pairMode 是设置成 GAPBOND_PAIRING_MODE_WAIT_FOR_REQ？ 主机那边会主动发起配对？
DEFAULT_BONDING_MODE 为false, 则每次连接都像刷过程序一样需要重新配对
SunnyHua：
回复 Susan Yang:
Hi, Susan,
我的DEFAULT_BONDING_MODE设置为TRUE，
同时从机的pairMode设置为GAPBOND_PAIRING_MODE_WAIT_FOR_REQ，由主机发起配对。
请帮忙再看下，如此设置是否会有相似问题？
谢谢。
Susan Yang：
回复 SunnyHua:
DEFAULT_BONDING_MODE设置为TRUE后再次连接时是不需要重新配对的。您现在说的是只有2个CC2541的板子的情况？那应该不会的
SunnyHua：
回复 Susan Yang:
Susan,
那您了解到的可发生connection drop的情况，是发生在什么条件下的，因为我们设备的使用场景比较特殊，也不太好描述，所以还请您那边指出一下。
谢谢。
Susan Yang：
回复 SunnyHua:
若是您有比较耗时的事件需要处理，导致事件处理时间已经超过了“连接间隔+超时时间”，则有可能会出现断开连接
SunnyHua：
回复 Susan Yang:
如果超过这个时间，底层也应该会向上层报断开命令，但我现在遇见的问题是，两个连接配对好的设备，一方断开，另一方还保持连接状态。这会是因为什么呢？
Alvin Chen：
回复 SunnyHua:
Hello Sunny, The issue is due to an problem we've seen in some older Androids where they don't properly respond to the BT4.2 LL_LENGTH_REQ Data Length Update procedure.
SunnyHua：
回复 Alvin Chen:
Hi, Alvin，
Thanks for your response to my question.
I have more question about the issue, whether it would be a random problem or a always happened issue each time about the connections drop with Android 7+ devices.
