Bluetooth SPP между Android и другим устройством, вопросы UUID и PIN

Я пытаюсь внедрить приложение Android для получения данных с медицинского устройства, но Я не могу пройти процесс обнаружения и получить телефон, а устройство сопряжено или подключено друг к другу.

Описание медицинского устройства: Устройство использует протокол обнаружения обслуживания (SDP) и профиль последовательного порта (SPP). Он начинает процедуру запроса, чтобы обнаружить (до 10) окружающих точек доступа с соответствующим фильтром ХПК и именем службы. Затем он последовательно устанавливает соединение (используя процедуру страницы) с точкой доступа, проверяя PIN-код. После сопоставления ПИН данные загружаются. После загрузки данных устройство ждет подтверждения. Решением является мастер и инициирует сообщение.

У меня нет контроля над медицинским устройством. Все, что я могу сделать, это запустить его и ждать процедуры, описанной выше (после измерения).

Приложение для Android: Я начал с Bluetooth Chat Example на страницах разработчиков. До сих пор я заменил UUID на 00001101-0000-1000-8000-00805f9b34fb на использование SPP и установил имя службы в соответствующее имя. Я могу подтвердить, что это кажется правильным путем осмотра услуги с компьютера. Поскольку медицинское устройство является тем, которое запрашивает и инициирует связь, моя служба использует метод BluetoothServerSocket и accept(), чтобы начать его прослушивание.

На страницах разработчиков я прочитал, что UUID должен совпадать между приложениями, пытающимися связаться. Поскольку я не могу установить UUID для медицинского устройства, мне интересно, будет ли это проблемой или достаточно, чтобы медицинское устройство использовало профиль SP?
Если имя службы и UUID верны, и медицинское устройство действительно попытается подключиться к моей службе Bluetooth, которая прослушивает подключения, система Android предложит мне ввести PIN-код вручную, чтобы иметь возможность сопрягать (поскольку медицинское устройство имеет предварительно установленный PIN-код)?
Я ничего не нашел в Android SDK API, который позволяет мне установить PIN-код для моей службы Bluetooth (в случае, если это не так), возможно ли это?

Я читал, что, как правило, PIN-код генерируется системой в настоящее время, и требуется только подтверждение пользователя. Я думаю, что не в моей системе, так как устройство немного старше.

Было бы здорово, если бы вы хотели поделиться некоторыми знаниями, подсказками, догадками о чем-либо, связанном с тем, что я описал выше!

Спасибо заранее, Фредрик

EDIT:

Теперь у меня есть устройство в паре с коробкой bluegiga, и они общаются правильно. Теперь я ищу критерии, чтобы выполнить для устройства кровяного давления подключение к моему телефону. Я могу проверить, с компьютера Linux (sdptool search SP в терминале), службы Bluetooth, предоставляемой синеггигой, и сравнить это с сервисом Bluetooth, который я предоставляю на Android. Эти значения я получаю:

~ $sdptool search SP

Запрос...

Поиск SP на 8C: 71: F8: E5: XX: XX.,.

Название услуги: 1808130054

Сервис RecHandle: 0x10003

Список идентификаторов класса обслуживания:

UUID 128: 00001101-0000-1000-8000-00805f9b34fb

Список дескрипторов протоколов:

"L2CAP" (0x0100)

"RFCOMM" (0x0003)

Канал: 13

Скрытие для SP на 00: 07: 80: 88: XX: XX.,.

Название услуги: 1808130054

Описание услуги: 1808130054

Сервис RecHandle: 0x10005

Список идентификаторов класса обслуживания:

"Последовательный порт" (0x1101)

Список дескрипторов протоколов:

"L2CAP" (0x0100)

"RFCOMM" (0x0003)

Канал: 12

Язык Base Attr List:

code_ISO639: 0x656e

enconding: 0x6a

base_offset: 0x100

Первым найденным устройством является телефон (mac = 8C: 71... Google Nexus S), а второй (mac = 00: 07...) - синегага. Я заметил, что на Android-устройстве нет описания сервиса. Я думаю, что самое важное отличие в списке идентификаторов класса обслуживания. UUID 128 на Android, но совершенно другой формат, описывающий это на bluegiga.

Возможно ли реализовать идентификаторы класса обслуживания с другим форматом, чем UUID на Android?
Можете ли вы манипулировать служебной записью, зарегистрированной в БД поиска служб?
Можно ли каким-то образом реализовать прямо к BlueZ напрямую, используя собственное развитие c/С++?

/Fredrik

Ответ 1

Если вы можете указать имя/ссылку на медицинское устройство (если это коммерческое устройство), это может помочь прочитать руководство, чтобы узнать больше о том, что может происходить. Вот несколько советов:

В дополнение к UUID последовательного порта каждая служба по SPP может иметь индивидуальный UUID - например, медицинское устройство может искать сервис, с которым он совместим, используя этот пользовательский UUID.
Если медицинское устройство в настоящее время успешно подключается к ПК или какой-либо другой точке доступа и передает данные, вы можете попробовать прочитать запись SDP этого устройства и определить, какой конкретный UUID в дополнение к UUID SPP используется, если таковой имеется, и использовать то же самое в вашем приложении.
Если медицинское устройство не может найти ваш телефон/приложение, это может быть связано с тем, что оно не поддается обнаружению. Устройство Android по умолчанию не доступно для обнаружения, даже если вы являетесь сервером, он будет доступен только для подключения и не может быть обнаружен, вы можете попытаться сделать его доступным для обнаружения или с помощью настроек и посмотреть, может ли медицинское устройство найти ваше устройство. См. Здесь - Включение возможности обнаружения в Android
Для соединения с ПП, устройство Android должно начать процесс сопряжения, когда не-сопряженное устройство пытается подключиться к нему, вы можете попробовать его после прохождения рекомендаций (1) и (2), Соединение с ПИН используется, если одно из устройств до версии Bluetooth 2.1. Даже с более новыми устройствами на телефоне потребуется 6-значный ключ доступа с некоторым вмешательством/подтверждением пользователя, чтобы разрешить сопряжение (это всего лишь хорошая политика безопасности чтобы это не происходило автоматически без вмешательства пользователя), мы надеемся, что спаривание будет требоваться только при первом подключении, а затем последующее подключение к нему не потребует вмешательства пользователя.