Приложение ble scanner как пользоваться

Обновлено: 06.01.2025

В предыдущей статье мы подробно поговорили о подключении/отключении BLE устройств. Эта статья о чтении и записи характеристик, а также включении-выключении уведомлений.

Чтение и запись характеристик

Многие разработчики, которые начинают работать с BLE на Android , сталкиваются с проблемами чтения/записи BLE характеристик. На Stackoverflow полно людей, предлагающих просто использовать задержки… Большинство таких советов неверные.

Есть две основные причины проблем:

Операции чтения/записи асинхронные. Это значит, что вызов метода вернется немедленно, но результат вызова вы получите немного позже – в соответствующих колбеках. Например onCharacteristicRead() или onCharacteristicWrite() .

Одновременно может быть запущена только одна операция. Нужно дождаться выполнения текущей операции, и затем, запускать следующую. В исходном коде BluetoothGatt есть блокирующая переменная, которая при запуске операции устанавливается и при вызове колбека сбрасывается. Google забыла про это упомянуть в документации… (Прим. переводчика: речь идет о mDeviceBusy и mDeviceBusyLock здесь).

Первая причина, на самом деле, не является проблемой, такова природа BLE. Асинхронное программирование это распространенная штука, используется, например, при сетевых вызовах. Однако вторая причина раздражает и требует специального подхода.

Ниже кусок кода BluetoothGatt.java с блокировкой переменной mDeviceBusy , перед чтением характеристики:

Когда приходит результат чтения/записи, переменная mDeviceBusy сбрасывается в false снова:

Используем очередь

Выполнять чтение/запись по одной операции за раз неудобно, но любое сложное приложение должно это учитывать. Решение этой проблемы - использование очереди команд. Все BLE библиотеки, которые я ранее упоминал, так или иначе реализуют очередь. Это одна из лучших практик! Идея простая – каждая команда сначала добавляется в очередь. Затем команда забирается из очереди на исполнение, после результата, команда помечается как «завершенная» и, удаляется из очереди. Запускать команды можно в любое время, но они выполняются точно в том порядке, в котором поступают в очередь. Это очень упрощает разработку под BLE. В iOS аналогично работает фреймворк CoreBluetooth (Прим. переводчика: который намного удобнее, чем реализация Bluetooth стека в Android ).

Очередь создается для каждого объекта BluetoothGatt . К счастью, Android сможет обрабатывать очереди от нескольких объектов BluetoothGatt , вам не нужно об этом беспокоиться (Прим. переводчика: у меня это не сработало, я использовал глобальную очередь команд для всех устройств). Есть много способов создать очередь, мы будем использовать простую очередь Queue с Runnable для каждой команды и переменной commandQueueBusy для отслеживания работы команды:

Мы добавляем новый экземпляр Runnable в очередь при выполнении команды. Ниже пример чтения характеристики (readCharacteristic):

В этом методе, сначала проверяем все ли готово для выполнения (наличие и тип характеристики) и логгируем ошибки, если они есть. Внутри Runnable , фактически вызывается метод readCharacteristic() , который выдает команду на устройство. Мы также отслеживаем сколько было попыток, чтобы сделать повтор в случае ошибки (Прим. переводчика: это лучшая тактика, чтобы добиться стабильной работы с устройством). Если чтение характеристики возвращает false , мы логгируем ошибку, «завершаем» команду, чтобы можно было запустить следующую. Наконец вызывается nextCommand() , чтобы запустить следующую команду из очереди:

Обратите внимание, мы используем метод peek() для получения объекта Runnable из очереди, чтобы можно было повторить запуск позже. Этот метод не удаляет объект из очереди.

Результат чтения будет отправлен в ваш колбек:

Мы завершаем команду completedCommand() после обработки нового значения. Это помогает избежать одновременный вызов другой команды и состояния гонки.

Теперь мы готовы завершить команду, убираем Runnable из очереди через вызов poll() и запускаем следующую из очереди:

В некоторых случаях (ошибка, неожиданное значение), вам нужно будет повторить команду. Сделать это просто, так как объект Runnable остается в очереди до вызова completedCommand() . Чтобы не уйти в бесконечное повторение – проверяем лимит на повторы:

Запись характеристик

Чтение характеристики достаточно простая операция, а запись требует дополнительных пояснений. Для выполнения записи нужно предоставить характеристику, массив байтов и тип записи. Существует несколько типов записи, важные для нас это:

WRITE_TYPE_DEFAULT (вы получите ответ от устройства, например, код завершения);

WRITE_TYPE_NO_RESPONSE (никакого ответа от устройства не будет).

Использовать тот или иной тип зависит от вашего устройства и характеристики (иногда она поддерживает оба типа записи, иногда только один конкретный тип).

В Android каждая характеристика имеет дефолтный тип записи, который определяется при ее создании. Ниже фрагмент кода из исходников Android , где определяется тип:

Как вы видите, это работает нормально, если характеристика поддерживает только один их двух типов записи. Если характеристика поддерживает оба типа, то значение по умолчанию будет WRITE_TYPE_NO_RESPONSE . Имейте это ввиду!

Перед записью можно проверить характеристику, поддерживает ли она нужный тип записи:

Я рекомендую всегда явно указывать тип записи и не полагаться на дефолтные настройки выбранные Android !

Итак, запись массива байтов bytesToWrite в характеристику выглядит так:

Включение/выключение уведомлений

Кроме самостоятельного чтения и записи характеристик, вы можете включить или отключить уведомления от устройств. При включении уведомления, устройство сообщит вам о появлении новых данных и отправит их автоматически.

Для включения уведомлений нужно сделать две вещи в Android :

вызвать setCharacteristicNotification . Bluetooth стек будет ожидать уведомления для этой характеристики.

записать 1 или 2 как unsigned int16 в дескриптор конфигурации характеристик (Client Characteristic Configuration, сокращенно - ССС). Дескриптор CCC имеет короткий UUID 2902.

Почему 1 или 2? Потому что «под капотом» Bluetooth стека есть Уведомление и Индикация. Полученное Уведомление не подтверждаются стеком Bluetooth , а Индикация наоборот – подтверждается стеком. При использовании Индикации, устройство будет точно знать, что данные получены и может их, например, удалить из локального хранилища. С точки зрения Android приложения нет разницы: в обоих случаях вы просто получите массив байтов и Bluetooth стек уведомит устройство об этом, если вы используете Индикацию. Итак, 1 включает уведомления, 2 – индикацию. Чтобы выключить их, записываем 0. Вы должны самостоятельно определить, что записать в дескриптор CCC.

В iOS метод setNotify() делает всю работу за вас. Ниже пример, как сделать тоже самое на Android , там сначала идут проверки входных параметров, определяется что записать в дескриптор и, наконец команда отправляется в очередь:

Результат записи в CCC дескриптор обрабатывается в колбеке onDescriptorWrite . Здесь вы должны отличить запись в CCC от записей в другие дескрипторы. Во время обработки колбека, мы также должны хранить, какие в данный момент характеристики уведомляются.

Чтобы узнать из какой характеристики пришло уведомление – используйте метод isNotifying() :

Лимиты на установку уведомлений

К сожалению, нельзя включить столько уведомлений, сколько хочешь. Начиная с Android-5 лимит равен 15. В более старых версиях он был равен 7 или даже 4. Большинство смартфонов поддерживают 15 уведомлений. Не забывайте отключать их, если они вам больше не нужны, чтобы не исчерпать лимит.

Проблемы с потоками

Итак, мы научились читать/писать характеристики, включать/выключать уведомления, а значит готовы использовать это в реальном проекте. Я думаю, что устройства BLE можно разделить на две категории:

Простые устройства. Например, термометр, который использует официальный Bluetooth Health Thermometer сервис. Такие устройства легко использовать, вы просто включаете уведомления и данные начинают поступать. Здесь мы используем только операции чтения характеристики, запись не нужна;

Сложные устройства. Это может быть любое устройство, но обычно все они используют свой внутренний протокол обмена данными. Часто эти протоколы не спроектированы под BLE, а просто транслируют внутренний последовательный протокол в BLE, где одна характеристика используется для отправки данных, а другая для приема. Сложность в том, что вам требуется знать большое количество команд для работы с устройством: авторизация, обновление пользовательских параметров, параметров самого устройства, получение сохраненных данных и т.д.

Простые устройства обычно не создают проблем с потоками, для сложных – следует работать внимательно. Чтение, запись и уведомления в этом случае будут чередоваться и могут мешать друг другу, особенно если у вас устройство с высокой частотой передачи данных (30Hz или около).

Типичная проблема с потоками выглядит так:

вы отправляете событие в свою собственную очередь для обработки

запускается обработку полученных данных

в это время приходит новое уведомление и перезаписывает предыдущее значение в BluetoothGattCharacteristic

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

Причины такого поведения:

Android переиспользует BluetoothGattCharacteristic объекты внутри. Они создаются в время обнаружения сервисов (services discovering) и после этого переспользуютсямногократно. Таким образом, когда приходит уведомления Android сохраняет значение в объект BluetoothGattCharacteristic . Если характеристика в этот момент обрабатывается в другом потоке мы получим гонку состояний (race condition) и результат будет непредсказуемым.

Очевидно, что нужно всегда работать с копией массива байтов. Получили данные, сразу же делаем копию и работаем с ней.

Ниже пример, который использует такую тактику:

Другие рекомендации по работе с потоками

Есть несколько дополнительных рекомендаций по работе с BLE на Android . Поскольку стек BLE в основном асинхронный, у нас есть мульти-поточная обработка задач.

Android использует потоки:

При сканировании (результаты приходят в main поток);

Вызове колбеков BluetoothGattCallback (выполняются в потоках Binder );

Обработка результатов сканирования на main потоке не будет проблемой. Но с потоками Binder все немного сложнее. При вызове колбека на потоке Binder, Android не будет отправлять новые данные пока не закончится обработка текущих, то есть поток Binder блокируется пока ваш код не завершится. Следует избегать тяжелых операций в колбеках, никаких sleep() или что-то подобное. Кроме того, никаких новых вызовов в объекте BluetoothGatt , пока вы находитесь в потоке Binder, хотя большинство методов асинхронные.

Я рекомендую следующее:

Всегда выполняйте вызовы BluetoothGattCallback в отдельном потоке, возможно даже из потока пользовательского интерфейса (Прим. переводчика: работать на main потоке - плохая идея, если у вас есть активный обмен с устройством, обязательно будут залипания UI, не делайте так);

Освобождайте потоки Binder как можно быстрее и никогда не блокируйте их;

Самый простой способ выполнить рекомендации выше – создать выделенный Handler и использовать его для обработки данных и выдачи новых команд. Обратите внимание, я уже использовал Handler на примере кода для колбека onCharacteristicUpdate .

Если хотите запустить Handler на main потоке:

Прокрутите назад и взгляните на наш метод nextCommand() , каждый Runnable выполняется в нашем собственном Handler , следовательно, мы гарантируем, что все команды выполняются вне потока Binder .

Следующая статья: сопряжение (bonding)

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

Не терпится поработать с BLE? Попробуйте мою библиотеку Blessed for Android . Она использует все подходы из этой серии статей и упрощает работу с BLE в вашем приложении.

Укажите причину минуса, чтобы автор поработал над ошибками

Клиническая картина: баннера нет,а вместо него квест про внимание к своему здоровью Пройти

Редакторский дайджест

Присылаем лучшие статьи раз в месяц

Скоро на этот адрес придет письмо. Подтвердите подписку, если всё в силе.

Могу точно сказать – это было сложней, чем представлял, мне пришлось приложить немало усилий для стабильной работы под Android. Я изучил много статей в свободном доступе, некоторые оказались ошибочными, многие были очень полезными и помогли в деле. В этой серии статей я хочу описать свои выводы, чтобы вы не тратили уйму времени на поиски как я.

Особенности работы BLE под Android

Google документация по BLE очень общая, в некоторых случаях нет важной информации или она устарела, примеры приложений не показывают, как правильно использовать BLE. Я обнаружил лишь несколько источников, как правильно сделать BLE. Презентация Stuart Kent дает замечательный материал для старта. Для некоторых продвинутых тем есть хорошая статья Nordic.

Android BLE API это низкоуровневые операции, в реальных приложениях нужно использовать несколько слоев абстракции (как например сделано «из коробки» в iOS-CoreBluetooth). Обычно нужно самостоятельно сделать: очередь команд, bonding, обслуживание соединений, обработка ошибок и багов, мультипоточный доступ . Самые известные библиотеки: SweetBlue, RxAndroidBle и Nordic. На мой взгляд самая легкая для изучения - Nordic, см. детали тут.

Производители делают изменения в Android BLE стеке или полностью заменяют на свою реализацию. И надо учитывать разницу поведения для разных устройств в приложении. То что прекрасно работает на одном телефоне, может не работать на других! В целом не все так плохо, например реализация Samsung сделана лучше собственной реализации от Google!

В Android есть несколько известных (и неизвестных) багов которые должны быть обработаны, особенно в версиях 4,5 и 6. Более поздние версии работают намного лучше, но тоже имеют определенные проблемы, такие как случайные сбои соединения с ошибкой 133. Подробнее об этом ниже.

Не претендую на то, что я решил все проблемы, но мне удалось выйти на «приемлемый» уровень. Начнем со сканирования.

Сканирование устройств

Перед подключением к устройству вам нужно его просканировать. Это делается при помощи класса BluetoothLeScanner :

Сканер пытается найти устройства в соответствии с настройками filters и scanSettings , при обнаружении устройства вызывается scanCallback :

В результате сканирования мы получаем экземпляр ScanResult , в котором есть объект BluetoothDevice , его используют для подключения к устройству. Но прежде чем начать подключаться, поговорим о сканировании подробнее, ScanResult содержит несколько полезных сведений об устройстве:

Advertisement data - массив байтов с информацией об устройстве, для большинства устройств это имя и UUID сервисов, можно задать в filters имя устройства и UUID сервисов для поиска конкретных устройств.

RSSI уровень - уровень сигнала (насколько близко устройство).

… дополнительные данные, см. документацию по ScanResult здесь.

Помним про жизненный цикл Activity , onScanResult может вызываться многократно для одних и тех же устройств, при пересоздании Activity сканирование может запускаться повторно, вызываю лавину вызовов onScanResult .

Настраиваем фильтр для сканирования

Вообще можно передать null вместо фильтров и получить все ближайшие устройства, иногда это полезно, но чаще требуются устройства с определенным именем или набором UUID сервисов.

Сканирование устройств по UUID сервиса

Используется если вам необходимо найти устройства определенной категории, например мониторы артериального давления со стандартным сервисным UUID: 1810. При сканировании устройство может содержать в Advertisement data UUID сервис, который характеризует это устройство. На самом деле эти данные ненадежные, фактически сервисы могут не поддерживаться, или подделываться Advertisement data данные, в общем тут есть творческий момент.

Прим. переводчика: одно из моих устройств со специфичной прошивкой, вообще не содержало список UUID сервисов в Advertisement data, хотя все остальные прошивки этого устройства работали ожидаемо.

Пример сканирования службы с артериальным давлением:

Сканирование устройств по имени

Поиск устройств использует точное совпадение имени устройства, обычно это применяется в двух случаях:

поиск конкретного устройства

поиск конкретной модели устройства, например, мой нагрудный напульсник Polar H7 определяется как «Polar H7 391BBB014», первая часть - «Polar H7» общая для всех таких устройств этой модели, а последняя часть «391BBB014» - уникальный серийный номер. Это очень распространенная практика. Если вы хотите найти все устройства «Polar H7», то фильтр по имени вам не поможет, придется искать подстроку у всех отсканированных устройств в ScanResult . Пример с поиском точно по имени:

Сканирование устройств по MAC-адресам.

Обычно применяется для переподключения к уже известным устройствам. Обычно мы не знаем MAC-адрес девайса, если не сканировали его раньше, иногда адрес печатается на коробке или на корпусе самого устройства, особенно это касается медицинских приборов. Существует другой способ повторного подключения, но в некоторых случаях придется еще раз сканировать устройство, например при очистке кеша Bluetooth.

Вероятно вы уже поняли, что можно комбинировать в фильтре UUID, имя и MAC-адрес устройства. Выглядит неплохо, но на практике я не применял такое. Хотя может быть вам это пригодится.

Настройка ScanSettings

ScanSettings объясняют Android как сканировать устройства. Там есть ряд настроек, которые можно задать, ниже полный пример:

ScanMode

Безусловно, это самый важный параметр. Определяет метод и время сканирования в Bluetooth стеке. Такая операция требует много энергии и необходим контроль над этим процессом, чтобы не разрядить батарею телефона быстро. Есть 4 режима работы, в соответствии с руководством Nordics и официальной документацией:

SCAN_MODE_LOW_POWER . В этом режиме Android сканирует 0.5с, потом делает паузу на 4.5с. Поиск может занять относительно длительное время, зависит от того насколько часто устройство посылает пакет advertisement данных.

SCAN_MODE_BALANCED . Время сканирования: 2с, время паузы: 3с, «компромиссный» режим работы.

SCAN_MODE_LOW_LATENCY . В этом случае, Android сканирует непрерывно, что очевидно требует больше энергозатрат, при этом получаются лучшие результаты сканирования. Режим подходит если вы хотите найти свое устройство как можно быстрее. Не стоит использовать для длительного сканирования.

SCAN_MODE_OPPORTUNISTIC . Результаты будут получены, если сканирование выполняется другими приложениями! Строго говоря, это вообще не гарантирует, что обнаружится ваше устройство. Стек Android использует этот режим в случае долгого сканирования, для понижения качества результатов (см. ниже «Непрерывное сканирование»).

Callback Type

Эта настройка контролирует как будет вызываться callback со ScanResult в соответствии с заданными фильтрами, есть 3 варианта:

CALLBACK_TYPE_ALL_MATCHES . Callback будет вызывать каждый раз, при получении advertisement пакета от устройств. На практике - каждые 200-500мс будет срабатывать сallback, в зависимости от частоты отправки advertisement пакетов устройствами.

CALLBACK_TYPE_FIRST_MATCH . Callback сработает один раз для устройства, даже если оно далее будет снова посылать advertisement пакеты.

CALLBACK_TYPE_MATCH_LOST . Callback будет вызван, если получен первый advertisement пакет от устройства и дальнейшие advertisement пакеты не обнаружены. Немного странное поведение.

В практике обычно используются настройка CALLBACK_TYPE_ALL_MATCHES или CALLBACK_TYPE_FIRST_MATCH . Правильный тип зависит от конкретного случая. Если не знаете - используйте CALLBACK_TYPE_ALL_MATCHES , это дает больше контроля при получении callback, если вы останавливаете сканирование после получения нужных результатов - фактически это CALLBACK_TYPE_FIRST_MATCH .

Match mode

Настройка того, как Android определяет «совпадения».

MATCH_MODE_AGGRESSIVE . Агрессивность обуславливается поиском минимального количества advertisement пакетов и устройств даже со слабым сигналом.

MATCH_MODE_STICKY . В противоположность, этот режим требует большего количества advertisement пакетов и хорошего уровня сигнала от устройств.

Я не тестировал эти настройки подробно, но я в основном использую MATCH_MODE_AGGRESSIVE , это помогает быстрее найти устройства.

Number of matches

Параметр определяет сколько advertisement данных необходимо для совпадения.

MATCH_NUM_ONE_ADVERTISEMENT . Одного пакета достаточно.

MATCH_NUM_FEW_ADVERTISEMENT . Несколько пакетов нужно для соответствия.

MATCH_NUM_MAX_ADVERTISEMENT . Максимальное количество advertisement данных, которые устройство может обработать за один временной кадр.

Нет большой необходимости в таком низкоуровневом контроле. Все что вам надо - быстро найти свое устройство, обычно используются первые 2 варианта.

Report delay

Задержка для вызова сallback в миллисекундах. Если она больше нуля, Android будет собирать результаты в течение этого времени и вышлет их сразу все в обработчике onBatchScanResults . Важно понимать что onScanResult не будет вызываться. Обычно применяется, когда есть несколько устройств одного типа и мы хотим дать пользователю выбрать одно из них. Единственная проблема здесь - предоставить информацию пользователю для выбора, это должен быть не только MAC-адрес (например имя устройства).

Важно: есть известный баг для Samsung S6 / Samsung S6 Edge, когда все результаты сканирования имеют один и тот же RSSI (уровень сигнала) при задержке больше нуля.

Кеширование Android Bluetooth стека

В результате процесса сканирования вы получаете список BLE устройств и при этом данные устройств «кешируются» в Bluetooth стеке. Там хранится основная информация: имя, MAC-адрес, тип адреса (публичный, случайный), тип устройства (Classic, Dual, BLE) и т.д. Android нужны эти данные, чтобы подключится к устройству быстрее. Он кеширует все устройства, которые видит при сканировании. Для каждого из них записывается небольшой файл с данными. Когда вы пытаетесь подключиться к устройству, стек Android ищет соответствующий файл, чтобы прочитать данные для подключения. Важный момент - одного MAC-адреса недостаточно для успешного подключения к устройству!

Очистка кеша

Bluetooth кеш, как и любой другой, не существует вечно, есть 3 ситуации, когда он очищается:

Выключение и включение системного переключателя Bluetooth

Очистка данных приложения (в ручном режиме в настройках телефона)

Это достаточно неудобный момент для разработчиков, потому что телефон часто перезагружается, пользователь может включать-выключать самолетный режим. Есть еще различия между производителями телефонов, например на некоторых телефонах Samsung, кеш не очищался при выключении Bluetooth.

Это значит, что нельзя полагаться на данные об устройстве из BT кеша. Есть небольшой трюк, он поможет узнать закешировано ли устройство или нет:

Это важный момент, если нужно подключиться к устройству позже, не сканируя его. Подробнее об этом позже.

Непрерывное сканирование?

Вообще хорошая практика – избегать непрерывного сканирования потому что, это очень энергоемкая операция, а пользователи любят, когда батарея их смартфона работает долго. Если вам действительно нужно постоянное сканирование, например при поиске BLE-маячков, выберите настройки сканирования с низким потреблением и ограничивайте время сканирования, например когда приложение находится только на переднем плане (foreground), либо сканируйте с перерывами.

Плохая новость в том, что Google в последнее время ограничивает (неофициально) непрерывное сканирование:

c Android 8.1 сканирование без фильтров блокируется при выключенном экране. Если у вас нет никаких ScanFilters , Android приостановит сканирование, когда экран выключен и продолжит, когда экран снова будет включен. Комментарии от Google. Это очевидно очередной способ энергосбережения от Google.

c Android 7 вы можете сканировать только в течение 30 минут, после чего Android меняет параметры на SCAN_MODE_OPPORTUNISTIC . Очевидное решение, перезапускать сканирование с периодом менее, чем 30 мин. Посмотрите commit в исходном коде.

с Android 7 запуск и останов сканирования более 5 раз за 30 секунд временно отключает сканирование.

Непрерывное сканирование в фоне

Google значительно усложнил сканирование на переднем плане. Для фонового режима вы столкнетесь с еще большими трудностями! Новые версии Android имеют лимиты на работу служб в фоновом режиме, обычно после 10 минут работы, фоновый сервис прекращает свою работу принудительно. Посмотрите возможные решения этой проблемы:

Проверка разрешений (permissions)

Есть еще несколько важных моментов, прежде чем мы закончим статью. Для начала сканирования нужны системные разрешения (permissions):

Убедитесь, что все разрешения одобрены, или запросите их у пользователя. Разрешение ACCESS_COARSE_LOCATION Google считает «опасным» и для него требуется обязательное согласие пользователя.

Прим. переводчика, в моем проекте для корректной работы с BLE потребовалось еще 2 разрешения: ACCESS_FINE_LOCATION (для API<23) и ACCESS_BACKGROUND_LOCATION обсуждение на Stackoverflow.

В итоге полный список разрешений включая версию Android10:

После получения всех нужный разрешений, нужно проверить включен Bluetooth, если нет - используйте Intent для запуска запроса на включение:

Заключение

Мы научились запускать сканирование BLE устройств с учетом жизненного цикла Activity (Fragment / Service), использовать фильтры и различные настройки сканирования, также узнали все нужные разрешения (permissions) для удачного запуска сканирования и особенности работы Android-Bluetooth кеша. В следующей статье мы погрузимся глубже в процесс подключения и отключения к устройствам.

Еще недавно пользователи Mi Band 3 самостоятельно устанавливали модифицированные прошивки при помощи разных программ, чтобы использовать девайс на привычном русском языке. В официальном приложении Mi Fit имеется автоматическое обновление, но запустить его вручную или откатить назад не получится. Эта программа самостоятельно запускает процесс обновления, после чего пользователям остается только ждать его завершения.

Устранение проблемы

Такая ошибка возникает по причине конфликта самого приложения и прошивки браслета. Другими словами, во время обновления не установились необходимые ресурсы. В таких ситуациях для устранения проблемы достаточно будет просто вручную обновить компоненты системы. А вот делать это можно несколькими способами, о которых речь пойдет ниже. Если применение одного не помогло, то следует использовать следующий.

Советы с форумов

Ниже собраны методы решения проблемы, которые были применены пользователями гаджета и оказались эффективными, как они говорят. Вот что пишут юзеры на 4pda:

Привязать Ми Бэнд NFC к другому смартфону, после чего начнется автоматическое обновление и устранится ошибка;
Отключить трекер от смартфона, сразу подключить обратно, после чего в настройках Mi Fit отключить погоду, закрыть приложение, открыть его снова, запустить погоду, синхронизировать данные.

Установка необходимых ресурсов

Если вы не знаете, что делать при обнаружении ошибки, то нужно установить файлы ресурсов, имеющие расширение .res. Кроме того, потребуется программа Gadgetbridge.

Обратите внимание, что гаджет должен быть не разряжен, чтобы у него хватило заряда для переустановки прошивки.

Пошаговая инструкция, если устройство начало просить “Откройте приложение”:

Загрузить файл с прошивкой .fw, открыть его с помощью ES проводника, а на всплывающем окне нажать “Открыть с помощью” и из списка выбрать “Gadgetbridge”;

Начать установку ПО и дождаться ее окончания;
По такому же методу установить ресурсы и шрифты.

Откройте приложение Mi Band 3 после обновления. Если этот метод устранения ошибки не помог, то приступайте к другому.

Как и со всеми гаджетами, с фитнес-трекерами бывают неполадки. В этой статье подробно рассказано о том, что делать, если Mi Band 3 не подключается к телефону.

Возможные причины и их решения

Неполадки бывают не только из-за браслетов, но и телефонов. Некоторые проблемы решаются быстро, с некоторыми придется повозиться.

Подключено несколько устройств

Если перед подключением Mi Band 3 использовалась предыдущая версия трекера, то повторно соединять нужно после отключения устарелой модели. Чтобы отсоединить старый устройство, нужно зайти в MiFit, затем во вкладку «Профиль», нажать на иконку предыдущего браслета в меню «Мои устройства». В самом низу будет кнопка отключения.

Неоригинальное устройство

Подделка Mi Band 3 не синхронизируется с официальным приложением. Чтобы не купить фальсификат, рекомендуется покупать в проверенных магазинах. Часто пользователи приобретают не настоящие модели на алиэкспресс. Обращайте внимание на рейтинг и отзывы о продавце.

Проблемы с Bluetooth

Некоторые интересуются, подключится ли браслет к смартфону с блютузом, например, 4.0. По заявлениям производителя, фитнес-трекер разработан под версию 4.2 и выше. Если в телефоне установлен Bluetooth 4.0, то гаджет будет работать. Иногда возможны ошибки.

Но если в смартфоне коннект версии 3.0 или 2.0, то часто возникают проблемы с соединением. Такое случается со старыми телефонами.

Другие решения

Если предыдущие не помогли, то рекомендуется воспользоваться следующими способами.

Метод первый

Mi Band 3 часто не ищет мобильный телефон из-за неполадок с Bluetooth. Чтобы проверить все ли хорошо с коннектором, нужно соединиться с другими устройствами, которые точно работают, например, с колонкой.

Перезагрузите Bluetooth.
Повторно подключитесь к устройству. Если не соединило — перезапустите телефон.
Повторите попытку, соединив смартфон с устройством. Если опять не подключает, нужно переходить к следующему шагу.

Метод второй

Этот способ подходит для тех, кто уже пользовался браслетом. Если после некоторого времени использования трекера телефон не видит Mi Band 3, либо устройство не подключается к мобильному, то рекомендуется сделать следующие действия:

Отключить устройство через Ми Фит.
Переустановить приложение.
Подключить браслет заново.

Переустановка программного обеспечения

Большинству помогает отвязка устройства от мобильного телефона и последующая переустановка официального приложения.

Если этот способ не решил проблему, то рекомендуется поэкспериментировать с версиями. К примеру, если телефон старый, то часто помогает откат Ми Фит к более старой версии. В других случаях нужно обновить программу.

Если проблема не решилась, то стоит попробовать неофициальные приложения, а также Lolex. Возможно неисправность из-за особенностей операционной системы. В крайнем случае стоит сбросить мобильный телефон к заводским настройкам.

Будьте осторожны: при откате смартфон теряет все файлы. Рекомендуется сделать резервную копию.

Телефон не видит фитнес-трекер

Если смартфон не отображает браслет, то нужно следовать следующей инструкции:

Удалить официальное приложение.
Установить более старую версию.
Подключить трекер к компьютеру через USB-кабель.
Запустить Mi Fit на телефоне, после чего вынуть капсулу, отсоединив от компьютера.
В большинстве случаях проблем решается, но иногда нужно проделать еще несколько шагов.
Обновить Ми Фит до последней версии.
Заново подключить устройство.

После проделанных действий телефон, как правило, начинает отображать Mi Band 3.

Может дело в модели смартфона?

Некоторые пользователи считают, что виновник проблемы — смартфон, а именно модель. Неважно, к какому телефону подключать Mi Band 3, все зависит от характеристик устройства.

Возможно модель не поддерживает подключение различных смарт-часов, фитнес-трекеров, беспроводных наушников и пр. Если проблемы иногда возникают с телефонами Lenovo, Huawei, Apple Iphone и др., то на смартфонах Xiaomi все работает отлично.

Полезные утилиты

Существует программное обеспечение, позволяющее решить неполадки с соединением приборов. Если одна не помогла, рекомендуется использовать другую. Судя по отзывам, ПО работает.

Fix-it

Фикс-ит — распространенное приложение для решения проблемы. Большинство отзывов — положительные.

Отсоединить браслет через официальное приложение.
Удалить Ми Фит.
Установить программу «Фикс-ит».
Ввести адрес профиля Bluetooth или MAC.
Заново привязать трекер.

Теперь есть возможность пользоваться неофициальными приложениями.

NRF-Connect

Если с прошлой утилитой ничего не вышло, то следует воспользоваться этой. С помощью NRF-Connect устанавливается соединение телефона с Ми Бенд 3.

Установить программу.
Включить соединение Bluetooth.
Разрешить софту доступ.
Отсканировать.
После завершения сканирования — привязать фитнес-браслет.

После завершения операции, девайс отображается во вкладке «Привязанные» или «Bonded».

BLE-Scanner

Интерфейс утилиты прост.

Для решения неполадки нужно:

Установить ПО, открыть BLE-Scanner.
Запустить поиск.
После завершения соединиться с браслетом.

Задача всех этих программ — подключить мобильный телефон и трекер Ми Бэнд 3. После проделанного устанавливается Ми Фит и подключается заново.

Перепрошивка браслета

Если все перечисленные методы не помогли, проблема не решилась, то следует прибегнуть к этому способу. Это радикальный метод, но зачастую именно он помогает.

Обратите внимание: при прошивке желательно включить режим «В самолете», отключить Ми Фит и уведомления, чтобы ничего не прервало установку прошивки браслета Mi Band 3. Также рекомендуется зарядить устройства.

Руководство по перепрошивке шаг за шагом:

Установить на телефон GadgetBridge.
Запустить Ми Фит. Во вкладке «Профиль» нужно выбрать «Mi Band 3», зайти в «Видимость» и включить опцию.
Далее запустить GadgetBridge. В списке должен быть браслет. Нужно нажать на него, подождать, пока соединит. Если не подключается — удалить устройство из списка, перезагрузить смартфон. После перезапуска — открыть утилиту, добавить гаджет. Браслет должен подключиться к GadgetBridge.
Далее нужно найти в интернете официальную или пользовательскую прошивку, скачать ее, загрузить на внутреннюю память мобильного телефона. После скачивания желательно проверить на наличие вирусов.
После проделанного, свернуть GadgetBridge, найти в файловом менеджере загруженную прошивку. Зачастую там 3 файла. Нужно нажать на тот, что с расширением *.fw, выбрать утилиту. Затем, подтвердить установку.
После завершения — открыть папку с загруженными файлами, выполнив те же действия с остальными двумя файлами. Это займет некоторое время. Нужно выполнить все в таком порядке: сначала файл .fw, затем .res, после чего .ft.
Прошивка браслета завершена. Теперь можно удалить файлы с телефона. Если утилита не нужна, то ее также можно убрать со смартфона. Теперь необходимо проверить, все ли работает.
Желательно вернуть настройки видимости в Mi Fit, чтобы уменьшить расход заряда батареи. Сделать это можно также, как и во пункте 2.

Что в итоге

В случае, если ни один метод не решил задачу, необходимо проверить все ли хорошо с самим фитнес-браслетом. С помощью QR-кода на упаковке проверяется подлинность устройства. Если проблема в браслете, то можно вернуть его по гарантии, либо отнести в сервисный центр. Чтобы исключить покупку подделки, желательно покупать в официальных магазинах, на настоящих сайтах, у проверенных продавцов.

В заключение хочется подметить, что не всегда проблема есть. Бывает такое, что после обновления перестает соединяться смартфон с Ми Бендом. В некоторых случаях это ошибка программистов. Следовательно, нужно подождать некоторое время, пока не выпустят следующий апдейт без ошибок.

Этичный хакинг и тестирование на проникновение, информационная безопасность

Bluetooth, как мы знаем, является одной из самых популярных и широко используемых беспроводных технологий в современном мире. В связи с быстрым ростом IoT, ускоряющим развитие технологии Bluetooth, Специальная группа по интересам Bluetooth (Bluetooth Special Interest Group (SIG)) предпринимает постоянные усилия по увеличению скорости передачи с максимальным акцентом на маяки, развлечения, сферу здравоохранения и фитнес.

Примечание: IoT - «Интернет вещей», термин относится к совокупности разнообразных устройств, обычно более простых, чем персональный компьютер, которые подключены к Интернету.

Bluetooth Low Energy (BLE) является частью спецификации Bluetooth 4.0, которая также включает протоколы классического Bluetooth и протокол высокоскоростного Bluetooth (Classic Bluetooth and Bluetooth High Speed Protocols). По сравнению с классическим Bluetooth, BLE предназначен для использования меньшей мощности при сохранении аналогичного диапазона связи. BLE — это технология, которая всегда отключена и передаёт только короткие объёмы данных, когда это необходимо. Это значительно снижает энергопотребление, что делает его идеальным для использования в случаях, когда требуется постоянное долговременное соединение с низкой скоростью передачи данных. BLE идеально подходит для пульта дистанционного управления телевизором, но не для беспроводного устройства потоковой передачи мультимедиа, которому для передачи требуется большой объем данных.

Bluetooth Low Energy встроен во многие гаджеты, которые мы используем сегодня. От смартфонов, умных телевизоров, передовых технологий, таких как медицинское оборудование, до базовых устройств, таких как наши кофемашины, - все используют BLE.

Изначально Nokia разработала BLE для собственного проекта под названием «WIBREE», который впоследствии был передан Bluetooth SIG. BLE был задуман с акцентом на лучшую скорость сопряжения и энергоэффективность.

Что выделяет BLE?

Обеспечивает многоплатформенную связь: может легко общаться через большое количество устройств, работающих на Android, iOS, Linux, Windows Phone, Windows 8 и OS X
Лучшая скорость сопряжения
Помогает поддерживать связь в течение более длительных периодов времени
Значительно ниже затраты на внедрение
Энергоэффективный

На бумаге BLE выглядит хорошо, а как на практике?

Это хороший вопрос с точки зрения безопасности. Дело в том, что BLE — это просто протокол. Изготовители должны безопасно внедрить BLE в своё устройство. Известно, что даже самый сильный криптографический протокол не будет работать, если генератор случайных чисел не является «достаточно случайным». То же самое относится и к BLE. Таким образом, можно сказать, что безопасность BLE лежит в руках его исполнителей.

В то время как все устройства Bluetooth с низким энергопотреблением были разработаны с основной целью улучшения взаимодействия с пользователем, безопасность заняла последнее место во время процесса?

Давайте посмотрим на три основные уязвимости, которым BLE могут подвергать своих пользователей:

Подслушивание: как следует из названия, подслушивание относится к стороннему устройству, прослушивающему данные, которыми обмениваются два сопряжённых устройства. Соединение между двумя сопряжёнными устройствами означает цепочку доверия. Цепь разрывается при удалении одного из устройств. Злоумышленник может использовать номер устройства для доступа к другим Bluetooth-устройствам. Даже если ключи шифрования/расшифровки должны были быть удалены, атакующий может офлайн брутфорсить ПИН, используя Bluetooth Sniffer (на основе идентификатора устройства). Как только PIN-код будет получен, устройство может быть легко взломано.
Атаки «человек посередине» (MITM). Атаки «человек посередине» включают стороннее устройство, имитирующее законное устройство, обманывая два легитимных устройства, заставляя их поверить в то, что они связаны друг с другом, когда на самом деле законные устройства подключены к имитатору (посреднику). Этот тип атаки позволяет злоумышленнику/имитатору получить доступ ко всем данным, которыми обмениваются устройства, а также манипулировать данными, удаляя или изменяя их, прежде чем они достигнут соответствующего устройства.
Отказ в обслуживании и Fuzzing атака. Поскольку большинство беспроводных устройств в наши дни работают на встроенных аккумуляторных батареях, эти устройства подвержены риску атак типа «отказ в обслуживании» (DoS). DoS-атаки подвергают систему частым сбоям, приводящим к полному истощению её батареи. Fuzzing атаки также приводят к сбою систем, поскольку злоумышленник может отправлять искажённые или нестандартные данные на радиомодуль устройства Bluetooth и проверять его реакцию, что в конечном итоге может сбить с толку устройство.

Итак, резюмируя, по своей задумке BLE это упрощённая версия Bluetooth, которая всегда не меняет каналы (частоты), что облегчает сниффинг и атаку человек-посередине. BLE не имеет встроенного протокола обеспечения безопасности. Реализация безопасности BLE возложена на производителей конечных устройств, которые не всегда подходят к этому добросовестно. По этой причине многие BLE устройства можно легко обнаружить практически в любое время их работы. При этом зачастую они не содержат каких-либо механизмов для ограничения чтения и даже записи на них, то есть открыты для подключения и модификации кому угодно.

Основные понятия в BLE

В BLE есть два основных понятия.

GAP - Generic Access Profile (общий профиль доступа)
GATT - Generic Attribute Protocol (протокол общих атрибутов)

Общий профиль доступа (GAP)

Он ответственен за подключение и распространения информации о наличии устройства BLE. GAP отвечает за видимость устройства во внешнем мире, а также играет важную роль в определении того, как устройство взаимодействует с другими устройствами.

Следующие две концепции являются неотъемлемой частью GAP:

Периферийные устройства. Это небольшие устройства с низким энергопотреблением, которые могут подключаться к сложным, более мощным центральным устройствам. Монитор сердечного ритма является примером периферийного устройства.

Центральные устройства: в основном это мобильные телефоны или гаджеты с увеличенной памятью и вычислительной мощностью.

Advertising process (обеспечение видимости устройства)

Процесс обнаружения устройств заключается в том, что Периферийное устройство в заданные интервалы отправляет в округу данные о своём существовании. Если эти данные получит Центральное устройство, то оно отправит запрос на сканирование. В ответ Периферийное устройство пришлёт данные результата сканирования.

Периферийное устройство будет отправлять «рекламные» данные каждые 2 секунды. Если центральное устройство готово прослушать рекламные пакеты, оно ответит запросом сканирования. В ответ на этот запрос периферийное устройство отправит данные ответа сканирования. Таким образом, центральное и периферийное устройства узнают друг о друге и связывается друг с другом.

Протокол общих атрибутов (GATT)

Используя общий протокол данных, известный как протокол атрибутов, GATT определяет, как два устройства BLE обмениваются данными друг с другом, используя понятия — сервис (service) и характеристика (characteristic). Этот протокол сохраняет все сервисы и характеристики в справочной таблице с использованием 16-битных идентификаторов, как указано в Bluetooth SIG. Важно отметить, что GATT инициируется только после того, как Advertising процесс, регулируемый GAP, завершён.

Две основные концепции, которые образуют GATT

Сервисы (service)
Характеристики (characteristic)

Сервисы

Сервисы можно представить просто как шкаф, в котором может быть много ящиков, которые в свою очередь называются характеристиками. Сервис может иметь много характеристик. Каждый сервис уникален сам по себе с универсально уникальным идентификатором (UUID), который может быть размером 16 бит для официальных адаптированных сервисов или 128 бит для пользовательских сервисов.

Характеристики

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

Вот спецификации SIG для характеристик и сервисов для устройств BLE. Любое устройство BLE, которое официально приняло UUID от SIG, должно использовать идентификатор, указанный ими в своих приложениях.

Например, официальный UUID мощности передачи (TX power) в соответствии с мандатом SIG равен 0x1804.

Чтобы было наглядно, посмотрите на этот пример сервисов и характеристик конкретного устройства:

В нём «Generic Access (1800)» - это 16-битный сервис. Внутри этого сервиса, следующие 16-битные характеристики:

Ещё один 16-битный сервис это «Generic Attribute (1801)», он содержит только одну 16-битную характеристику: Service Changed (2a05).

анализ приложения для управления устройством (многие устройства имеют программы под Android)
фаззинг — ввод различных данных и наблюдение за устройством, что в нём поменялось

Как взломать Bluetooth Low Energy

Суть процесса взлома Bluetooth Low Energy можно описать следующими стадиями:

Обнаружение устройства
Считывание его сервисов и характеристик
Обнаружение среди характеристик те, которые можно перезаписать
Определение, за что отвечают характеристики
Изменить значения характеристик

Четвёртый этап является творческим и самым сложным. Иногда роль характеристик можно найти в документации разработчиков для данного устройства. Иногда приходится перебирать значения и смотреть, что поменялось в устройстве. Самый сложный вариант — это обратная инженерия перехваченного Bluetooth трафика или приложения для управление устройством.

Я покажу пример изменения BLE параметров на устройстве с помощью bettercap.

Вводим команду для включения модуля по обнаружению BLE устройств:

Чтобы вывести устройства, которые в данный момент в пределах досягаемости, выполните команду:

Для показа характеристик конкретного устройства, запустите команду следующего вида, где вместо MAC укажите MAC-адрес устройства:

К примеру, меня интересует устройство C8:DF:84:1A:9F:26:

В столбце Properties вы увидите свойства данной характеристики, они могут быть:

READ (чтение)
WRITE (запись) — то есть возможно изменение данной характеристики
NOTIFY (уведомление)
INDICATE (индикатор)

В колонке Data присутствует текущее значение характеристики, либо дополнительная информация, например:

Для записи данных HEX_DATA в BLE устройство с указанным MAC адресом, в характеристику с идентификатором UUID:

Чтобы знать, что именно записывать, нужно понимать, за что отвечают характеристики. Вот пример значений для моего устройства — это электрическая зубная щётка Oral-B Genius 9000 (кстати, рекомендую). Значение характеристик я нашёл в Интернете.

Исследование и взлом Bluetooth Low Energy (BLE) с телефона

Поскольку на всех современных телефонах имеется Bluetooth, то вы можете использовать приложения для работы с Bluetooth Low Energy (BLE) окружающих устройств на телефоне.

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

Просмотр сервисов устройства:

Просмотр свойств характеристик:

Редактирование значений характеристик:

Работа с Bluetooth Low Energy (BLE) в Linux

Конечно, в Linux можно работать с устройствами, поддерживающими BLE, напрямую, без таких программ как Bettercap.

К сожалению, этот аспект довольно запутанный. В Debian и производных программы для работы с Bluetooth Low Energy собраны в пакете bluez. В Arch Linux и производных, пакет bluez также имеется, но утилиты, которые нас интересуют, помещены в пакет bluez-utils. Но не это самая большая проблема.

После очередного обновления утилит bluez, авторы вдруг признали многие важные программы «устаревшими», а именно устаревшими объявлены:

Поразительно, но для них не было представлено полноценных замен. Путаницу добавляет отсутствие нормальной документации и даже справки по программам.

Была составлена такая таблица замены:

Устаревший инструмент	Самая подходящая замена
gatttool	btgatt-client, D-Bus Gatt API
hciattach	btattach
hciconfig	btmgmt (и bluetoothctl?)
hcidump	btmon (и btsnoop)
hcitool	отсутствует, доступно в D-Bus Device API
rfcomm	отсутствует, реализовано в D-Bus Profile1 API?
ciptool	отсутствует, реализовано в D-Bus Profile1 API?
sdptool	отсутствует, кажется, что функциональность разбросана по разным объектам D-Bus: Profile, Advertising, и массивы UUIDs в device и adapter.

Слова «отсутствует» не вселяют уверенности. По этой причине для Debian и производных этот пакет компилируется с ключом --enable-deprecated, а на Arch Linux в дополнении к пакету bluez-utils, доступному в стандартных репозиториях, в AUR имеется пакет bluez-utils-compat, в котором тоже включены устаревшие инструменты.

В относительно свежих инструкциях, для взаимодействия с Bluetooth Low Energy используются утилиты:

Поскольку они устарели и однажды всё-таки будут удалены окончательно, рассмотрим несколько простых вариантов использования их замен для поиска BLE устройств и получения с них данных.

Если запустить программу btmgmt:

И в ней выполнить команду:

То она выведет список обнаруженных устройств:

Будут выведены как BLE, так и обычные Bluetooth устройства.

Также умеет искать BLE устройства, если ввести:

С помощью команды connect можно подключиться к устройству, для этого нужно указать его MAC-адрес:

Информация по устройству:

Если перейти в меню GATT:

То можно получить список характеристик:

А также перезаписать характеристики устройства.

Для получения информации по отдельным характеристикам:

Ещё одна программа, которая выведет сразу все характеристики устройства — btgatt-client. Например, выполним подключение и посмотрим характеристики устройства с MAC C8:DF:84:1A:9F:26:

В дополнении к рассмотренным программам, в отдельной консоли можно запустить Bluetooth monitor:

Как и полагается программе-монитору, она будет выводить множество информации о происходящем с Bluetooth и об обнаруженных устройствах.

Заключение

Системные утилиты Linux для работы с Bluetooth заслуживают более внимательного изучения — с их помощью можно узнать более подробную информацию о своей системе и сделать тонкую настройку Bluetooth адаптера.

Также с помощью них можно реализовать сканеры BLE и Bluetooth устройств и/или написать или приспособить фаззеры для исследования назначения характеристик BLE устройств. Поэтому вполне возможно, что в одной из следующих статей будут более подробно рассмотрены программы для работы с BLE.

Читайте также: