tree a283eda2f817c877a1ba42f43cec4bf20b14e3cc
parent 0e106007572f2df12c23424a97ccb7983f8b51bf
author Qasim Javed <qasimj@google.com> 1660332454 -0700
committer Jack He <siyuanh@google.com> 1660771584 -0700

Cache EIR UUIDs per Bluetooth address outside the pairing_cb_t

Currently, EIR UUIDs are cached inside the pairing control block. This
means EIR UUIDs belonging to device A can overwrite the EIR UUIDs
belonging to device B. Subsequently, if SDP fails for device A, we would
happily fetch the EIR UUIDs we know of (Device B's) and report it to the
Java layer. This is clearly incorrect.

Fix this by storing the EIR UUIDs per bdaddr. Upon failure of SDP, send
the EIR UUIDs belonging to the device for which SDP failed to Java and
then clear those EIR UUIDs so that we do not store them in memory for
longer than desired.

We are now using an LRU Cache to store the EIR UUIDs corresponding to
each discovered bdaddr. The cache can have EIR UUIDs for upto 128
devices.

1 BD_ADDR = 6 bytes
1 set of, say 6, 128-bit UUIDs = 96 bytes
=========================================
128 entries = 128*(6+96) = 13,056 bytes ~ 13KB of memory usage

If pairing is never done for certain devices after discovery, then
entries for these previously seen devices will always stay there in the
cache until the cache fills up with 128 entries at which point the
oldest entry will be replaced with the newest one.

Therefore, this CL adds a permanent memory footprint of about 13KB.

Bug: 242350646
Tag: #refactor
Test: tested it manually by forcing only EIR UUIDs to propagate to the
Java layer and also tested the case where zero EIR UUIDs exist and an
empty UUID is sent to the Java layer

Merged-In: Id3c4f7efd44c724a9451f31388d96d8f6119c1ba
Change-Id: Id3c4f7efd44c724a9451f31388d96d8f6119c1ba