Является ли встроенная реализация Android BLE синхронной по своей природе?

Я помню, как читал в "Guide and Hint" a>-doc к Samsung BLE API (архивная страница ):

Одной из наиболее важных концепций Samsung F/W и стека является их синхронный характер. То есть, если мы вызываем, например, writeCharacteristic для определенной характеристики, если она возвращает true, следующий вызов любого метода BluetoothGatt или BluetoothGattServer должен быть выполнен после получения обратного вызова onCharacteristicRead. Это связано с тем, что стек предназначен для поддержки и обработки только одного вызова GATT за раз, и если, например, вы вызываете writeCharacteristic или readCharacteristic по какой-либо характеристике вскоре после первого, он игнорируется.

  1. Относится ли это также к собственной реализации BLE, представленной в Android 4.3?
  2. Samsung API также поддерживает одновременно только одно подключенное устройство GATT. Изменилось ли это в родном API?

android bluetooth-lowenergy gatt android-4.3-jelly-bean
person OneWorld    schedule 02.08.2013    source источник
comment
Существует текущая тема, связанная с синхронным характером API в системе отслеживания проблем Google: code.google.com/p/android/issues/detail?id=58381   -  person Ash Eldritch    schedule 07.01.2014
comment
Я только что реализовал очередь для всех записей, и пока это работает хорошо.   -  person Ash Eldritch    schedule 08.01.2014
comment
@Ash Согласно документам, предоставленным SAMSUNG, поведение не ограничивается операциями записи. Да, использование очереди является распространенным способом решения этой проблемы. «пока работает хорошо»: трудно протестировать и воспроизвести отмену одной команды другой. Часто вы сталкиваетесь с проблемами, когда ваш код BLE становится более сложным, потому что вы делаете больше вещей на основе предыдущих вызовов. Я выполняю следующую операцию BLE только после завершения предыдущей (получил ответ) или после того, как предыдущая операция не завершилась в нужное время. Кстати, ваши комментарии больше подошли бы в качестве ответа на этот вопрос.   -  person OneWorld    schedule 08.01.2014
comment
@Ash, можешь поделиться своей реализацией?   -  person Ewoks    schedule 30.04.2015
comment
@Ewoks gist.github.com/SoulAuctioneer/ee4cb9bc0b3785bbdd51   -  person Ash Eldritch    schedule 01.05.2015
comment
Большое спасибо .. :) тем временем я тоже реализовал, но полезно увидеть ваше решение. Я правильно понял, что вы также ставите в очередь характеристики чтения?   -  person Ewoks    schedule 05.05.2015

Ответы (2)


arrow_upward
18
arrow_downward

Samsung недавно опубликовал документ о «миграции» на той же странице, на которую я ссылался в своем вопросе. Они точно отвечают на мой вопрос, сравнивая новый нативный BLE API с Samsung BLE API:

Синхронный характер стека и F/W не был затронут. То есть, если мы вызываем, например, writeCharacteristic для конкретной характеристики, если она возвращает true, следующий вызов любого метода BluetoothGatt или BluetoothGattServer должен быть выполнен после получения обратного вызова onCharacteristicRead. Это связано с тем, что стек предназначен для поддержки и обработки только одного вызова GATT за раз, и если, например, вы вызываете writeCharacteristic или readCharacteristic любого characteristic вскоре после первого, он игнорируется.

person OneWorld    schedule 05.08.2013
comment
Я очень рад, что нашел этот вопрос. Google не делает все возможное, чтобы прояснить это. Возврат true, когда запрос на чтение/запись фактически игнорируется, довольно сбивает с толку. - person svens; 15.11.2013
comment
Может ли кто-нибудь подтвердить, может ли android.bluetooth.BluetoothGatt обрабатывать только одну ожидающую операцию GATT НА УСТРОЙСТВО, НА ПРОЦЕСС или ПЕРИОД (т. е. во всех процессы). Я предполагаю, что это НА УСТРОЙСТВО, но эта проблема настолько запутана, что меня бы не удивило, если бы это было иначе. Если ограничение только НА УСТРОЙСТВО, то ОС/устройство, способное обрабатывать несколько одновременных операций, является неопровержимым доказательством того, что эта проблема возникает исключительно из-за какой-то слабой наивной реализации в экземпляре BluetoothAdapter, который ОС передает каждому процессу (что, как я предполагал, было синглтон для всех процессов). - person swooby; 22.03.2016
comment
Это одна ожидающая операция для каждого объекта BluetoothGatt. - person Emil; 10.09.2017
comment
@ Эмиль, я только что отменил твое изменение в этом вопросе. Пожалуйста, не изменяйте цитату инженеров Samsung. Если у вас есть проблемы с его содержанием, пожалуйста, добавьте это в качестве комментария. - person OneWorld; 03.11.2017
comment
Ну это явная опечатка. Вы ждете ответа на запись после запроса на запись. Вы не ждете ответа на чтение после запроса на запись... - person Emil; 03.11.2017

arrow_upward
-2
arrow_downward

  1. Нет. Большинство вызовов функций асинхронны.
  2. Я не знаю. В официальных документах об этом не упоминается, но и не говорится, что он поддерживает только одно устройство. Я верю, что это возможно сделать. Прочтите эту статью: http://blog.lemberg.co.uk/getting-bottom-android-bluetooth-low-energy-api#.UfvK6ZK-1cY

В нем говорится (я не знаю, каков его источник), что несколько периферийных устройств могут подключаться к одному устройству Android Central.

person edoardotognoni    schedule 02.08.2013
comment
Samsung ble API также в некотором роде асинхронен. Вы получаете ответ в обратном вызове (кстати, API очень похож). Однако, если вы запустите 2 запроса за короткое время, пока первый не будет полностью выполнен, первый может быть отменен. Итак, вопрос в том, имеет ли родной API такое же поведение. - person OneWorld; 03.08.2013
comment
Ах хорошо, теперь я понимаю. Я не знаю, следуют ли этому поведению собственные API. Я так думаю. Если вы запустите 2 scanBLE, предыдущий будет отменен, но я в этом не уверен. - person edoardotognoni; 04.08.2013