| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
Bytes matcher has been moved to frameworks/libs/modules-utils in this
CL: aosp/1821533
Bug: 200202780
Tag: #refactor
Test: atest cts/tests/tests/bluetooth/src/android/bluetooth/cts/ScanRecordTest.java frameworks/base/core/tests/bluetoothtests/src/android/bluetooth/le/ScanRecordTest.java
Change-Id: I4d374217100635a49918f8e88f2cb5327e758e9f
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As part of building out support for robustly matching Bluetooth LE
devices in the wild, this change checks all "fields" contained in a
ScanRecord against a given BytesMatcher.
To support matching variable-length Eddystone beacons, this change
also expands BytesMatcher to support both exact length and prefix
based rules, which are then used with rules that verify that example
Eddystone and iBeacon values can be detected with these rules:
Eddystone: ⊆0016AAFE/00FFFFFF
iBeacon: ⊆00FF4C0002/00FFFFFFFF
Expands testing to confirm all newly added capabilities are working.
Bug: 181812624
Test: atest BluetoothTests:android.bluetooth.le
Test: atest FrameworksCoreTests:android.os.BytesMatcherTest
Change-Id: I1cff8e08604436f4bba6f55aad64c3ce5969bf56
|
|
|
As part of an upcoming feature, we're anticipating the need to match
arbitrary byte sequences, such as Bluetooth UUIDs or MAC addresses,
so this change adds a new BytesMatcher similar in spirit to
the existing PatternMatcher.
It supports a reasonably compact serialization format which can be
used to transport a server-pushed deny-list. The choice to support
both "accept" and "reject" rules in an ordered list means that very
complex matching rules can be expressed efficiently.
Bug: 181812624
Test: atest FrameworksCoreTests:android.os.BytesMatcherTest
Change-Id: I55193051354278abaef8bef51413c632b07c7177
|