该规范只允许每个连接一个MTU协商。以前，每个持有蓝牙Gatt对象的客户端都可以请求自己的MTU。Android以前忽略了该规范，并在每个MTU请求上重新协商MTU。允许自定义MTU在共享环境中不起作用，其中多个独立的应用程序与同一个BLE设备对话。如果一个应用程序首先协商MTU=25，因为它不需要更多，但是另一个应用程序想要（稍后）协商MTU=500，如果要遵循规范，它就不能这样做。
因此，现在Android选择的MTU应该足够好，以满足客户端第一次协商MTU时的大多数用例（517）。517的MTU确保最长的GATT值（512字节）可以在一个L2 CAP数据包中发送，用于大多数类型的命令/请求/通知。
我不明白为什么这会破坏4.2之前的BLE设备。任何版本的BLE都没有改变MTU或GATT数据包长度。不支持高于默认值（23）的MTU的设备将继续使用23，支持高于23但低于517的MTU的设备将协商该值。

编辑：

我决定测试当远程设备不支持MTU Exchange时会发生什么。根据规范（所有BLE版本），应该向Exchange MTU请求发送错误响应，包含错误代码“请求不支持”。
当Android应用调用requestMtu时，使用任意MTU作为参数，请查看此btmon日志交换了哪些数据包：

> ACL Data RX: Handle 3585 flags 0x02 dlen 7
      ATT: Exchange MTU Request (0x02) len 2
        Client RX MTU: 517
< ACL Data TX: Handle 3585 flags 0x00 dlen 9
      ATT: Error Response (0x01) len 4
        Exchange MTU Request (0x02)
        Handle: 0x0000
        Error: Request Not Supported (0x06)

字符串
然后调用回调函数onMtuChanged，参数为mtu=23和status=6（请求不支持）。因此MTU仍然是默认值（23）。
然而，我注意到了Android中的一个bug（运行Android 14的Pixel 7）如果任何Bluetooth Gatt客户端在任何Bluetooth Gatt客户端调用之前的requestMtu之后尝试调用requestMtu，（可能是另一个）导致错误“请求不支持”。此时，不会调用onMtuChanged回调，并且似乎没有其他GATT操作在此Bluetooth Gatt对象上工作，例如，调用readCharacteristic不会发送任何读取请求，也不会调用任何响应回调。这种糟糕的状态一直存在，直到设备断开连接。