Android BLE // Использование пользовательских сервисов UUID

Мы разрабатываем настраиваемую периферийную систему с низкой энергией Bluetooth, и нам нужно определить наш пользовательский сервис. Основано на этой ссылке: https://www.bluetooth.org/en-us/specification/assigned-numbers/service-discovery Android BLE // Использование пользовательских сервисов UUID

Весь короткий UUID (16 бит) зарезервирован в ожидании будущих пересмотров спецификаций услуг BT. И похоже, что текущая версия Android (4.4) не поддерживает 128-битный UUID.

Так что я не могу использовать 16-битный UUID для определения моего сервиса, но я не могу отфильтровать свои сервисы с Android для 128-битного UUID. Кто-нибудь получил представление о наилучшем способе его реализации? Спасибо

источник

2014-01-29 M to the K

По-видимому, не все 16-битные UUID зарезервированы. Указанные UUID и UUID в диапазоне 0x000E - 0x01FF зарезервированы. Я использовал UUID FFF0 - FFFA для моего настраиваемого профиля, и он все еще работает нормально.

Взгляните на простойGATTProfile в простом периферийном примере TI.

источник

2014-01-30 07:06:39 nightgaunt

Из того, что я понимаю, кажется, что диапазон 0x00E - OxO1FF зарезервирован только для атрибутов. (Из документа: следующие идентификаторы атрибутов имеют одинаковое значение для всех служб. Эти идентификаторы атрибутов должны быть в диапазоне от 0x0000 до 0x01FF.). Поэтому я не уверен, что все, что было выше, можно было бы использовать ... В примере с TI они использовали id 0xFFF0 для их обслуживания, но с точки зрения Bluetooth это нормально? Вероятность столкновения с другими услугами довольно высока? –

Назначение пользовательских «внутренних» диапазонов UUID от 0xffff не рекомендуется. Организация по разработке стандартов (SDO) [описывает] (https://www.bluetooth.org/en-us/specification/assigned-numbers/sdo-16-bit-uuids), как компании могут подать заявку на 16-битный UUID и единственная, одобренная до сих пор, для A4WP. Он имеет 0xFFFE, поэтому кажется вероятным, что они начали оттуда и просто уменьшали счетчик. –

Я все еще не уверен, что это нормально использовать пользовательские 16-битные UUIDS, поэтому нам удаётся сделать что-то другое на основе этого вопроса SO. startLeScan with 128 bit UUIDs doesn't work on native Android BLE implementation

Мы сканируем все устройства и поиск нашей службы в байт [] scanRecord возвращенного LeScanCallback.

источник

2014-01-31 13:51:26

Это всегда будет безопасным и будущим доказательством. И Android, похоже, поддерживает более длинные UUID в своем новом API сканирования (уровень 21). Apple рекомендует [инструмент] (http://developer.android.com/reference/android/bluetooth/le/ScanFilter.Builder.html#setServiceUuid (android.os.ParcelUuid, android.os.ParcelUuid)) для просто создания случайный UUID для использования. Так кажется, что это правильный путь. –

Android BLE // Использование пользовательских сервисов UUID

ответ

Смежные вопросы