aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* ScannerTinyB10: Expose start/stop discovery result / dbt_scanner10: Align ↵Sven Gothel2020-08-232-7/+16
| | | | discovery toggle with ScannerTinyB10
* DBTAdapter::stopDiscover() now returns the boolean result w/ proper native ↵Sven Gothel2020-08-233-5/+5
| | | | | | | | | -> java proagation As we use HCIHandler's le_enable_scan etc, the result of start/stop discovery is meaningful now. This especially as the HCI command is of CMD_COMPLETE class and hence completes its operation. See commit e7164946014ab8d5c5587fe8f69e6262aed64bc5
* DBTAdapter: Use HCIHandler discovery/scan start and stopSven Gothel2020-08-231-4/+72
| | | | | | | | | | | TODO: For now we send the DISCOVERY events ourselves as the le_enable_scan command is a CMD_COMPLETE type procedure, i.e. has no lagging result and finishes its operation. Need to validate why Linux Mgmt uses a lagging event notification in the first place, however the current code should be compliant w/ HCI spec. See commit 5cb8c348f36359ea8e81fc6789337a582bbd516b, which adds le_enable_scan(..) to HCIHandler
* HCIHandler: Add le_set_scan_param(..) and le_enable_scan(..)Sven Gothel2020-08-232-0/+60
| | | | | | | This replaces Linux Mgmt's discover start/stop with native HCI commands. Besides avoiding side-effects, we can utilize le_set_scan_param(..) similar to le_create_conn(..) for fine grained scanning performance.
* DBTAdapter: Use HCIHandler to listen to DEVICE_FOUND eventsSven Gothel2020-08-232-21/+24
| | | | | Utilzing new HCIHandler MgmtEvtDeviceFound events from LE_ADVERTISING_REPORT, see commit a49ce8a8a72eb34cc6a4c8d23e4907684350d078
* HCIHandler: Produce MgmtEvtDeviceFound events from LE_ADVERTISING_REPORT; ↵Sven Gothel2020-08-235-69/+144
| | | | | | | | | | | | | | | EInfoReport: Fix address-type AD -> BDAddressType Parse LE_ADVERTISING_REPORT and produce MgmtEvtDeviceFound, call its listener. This removes dependency of Linux Mgmt's MgmtEvtDeviceFound events. MgmtEvtDeviceFound optionally holds the parsed std::shared_ptr<EInfoReport> instance, removing the need to process the raw EIR again in DBTAdapter later on. Misc: - Fix EInfoReport AD address-type -> BDAddressType conversion (missing) - Expose LEADVEventType enum w/ string presentation.
* HCIHandler: Unify processSimpleCommand/processStructCommand -> ↵Sven Gothel2020-08-233-60/+62
| | | | | | | | | | | | | | | processCommandStatus/processCommandComplete using base HCICommand Whether a simple HCICommand or HCIStructCommand<..> is being sent is up to the caller and agnostic to the methods. We either process a command with intermediate status respone (lagging result) and hence no detailed result structure/data - or - we process a command with complete status (and completed operation) potentially with detailed result structure/data.
* ScannerTinyB10: Simplify 'Processing Device' tail @ pre pingGATT: ↵Sven Gothel2020-08-231-5/+7
| | | | startDiscovery(true) if no devices in process
* HCIHandler::disconnect(..): Resolve CONNECTION_ALREADY_EXISTS re-connect ↵Sven Gothel2020-08-221-2/+8
| | | | | | | | | | | failure on CSR adapter post lost connection (ioError) Always issue DISCONNECT command, even in case of an ioError (lost-connection), see Issue #124 fast re-connect on CSR adapter. This will always notify the adapter of a disconnected device. We still send the DISCONN_COMPLETE in such case, i.e. not waiting for the lagging DISCONN_COMPLETE event from the adapter.
* DBTAdapter: Have non-enabled adapter to be valid, use lazy HCI ↵Sven Gothel2020-08-2215-32/+144
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | initialization; DBTManager: Validate enabled for non-user default adapter. DBTAdapter: Have non-enabled adapter to be valid, use lazy HCI initialization In a multi adapter setting, it is possible to have one adapter not being enabled, i.e. blocked from operations (e.g. rfkill). HCI communication is not possible in such cases and 'openHCI()' will fail. We still need to treat such adapter as valid, as they are, and distinguish the states: 'valid' and 'enabled'. This allows 'delivery' of all adapters to a manager and allows querying whether they are enabled. Therefor, the native DBTAdapter will not issue an aggregated 'openHCI()' at construction and initial validation, but treat the HCI instance as a singleton to be lazily created via 'getHCI()' if not yet existing. Here the required listener are also attached to the instance. In the future, this shall also allow dynamically adding/removing and enabling/disabling adapters. Hence before using a chosen adapter, one should query its enabled state via 'isEnabled()', which will also potentially initializing HCI. +++ DBTManager: Validate enabled for non-user default adapter. On the Java side, we can chose a default adapter via the property 'org.tinyb.default_adapter'. If so chosen, it shall be the default adapter, regardless of its 'enabled' state. Otherwise, the default adapter shall be the first enabled adapter in the list.
* Refine send DISCOVERY event (m true, n false) -> (m false, n false), fix ↵v2.1.20Sven Gothel2020-07-291-4/+21
| | | | state transition.
* DiscoveryState: Complete state transition tableSven Gothel2020-07-292-20/+20
|
* JNI: Complete C++ to Java Exception mappingSven Gothel2020-07-293-29/+77
|
* DBTAdapter DiscoveryState: Refine currentMetaScanType, introduce ↵Sven Gothel2020-07-293-30/+124
| | | | | | | | | | | | | | | | | | | | | | | | | currentNativeScanType, check valid states, add sendEvent Define the 'DiscoveryState' consisting out of: currentMetaScanType, currentNativeScanType and keepAlive * + ------+--------+-----------+----------------------------------------------------+ * | meta | native | keepAlive | Note * + ------+--------+-----------+----------------------------------------------------+ * | true | true | false | - * | false | false | false | - * + ------+--------+-----------+----------------------------------------------------+ * | true | true | true | - * | true | false | true | temporarily disabled -> startDiscoveryBackground() * | false | false | true | manual event generation * + ------+--------+-----------+----------------------------------------------------+ Added rare case of stopDiscovery() transition from (meta=true, native=false, keepAlive=true) to.. (meta=false, native=false, keepAlive=true), where we are required to send an new Discovering event to the user. Added checkDiscoveryState() validation method, called after each transition to ensure consistency throwing an IllegalStateException.
* Refine enum BTMode and ScanType: Elevate to 'enum class', shorten value ↵Sven Gothel2020-07-299-55/+107
| | | | definition and add getScanTypeString(..) getScanType(BTMode)
* GATTHandler::l2capReaderThread: 'l2cap read error' merely a warning, if at allSven Gothel2020-07-291-1/+1
|
* Fix typo in HCIStatusCode enum valueSven Gothel2020-07-283-4/+4
|
* DBTAdapter::ctor: Avoid using adapterInfo before initialized (SIGSEGV)Sven Gothel2020-07-281-3/+5
|
* DBTAdapter: Reduce verbosity again of stopDiscovery() and ↵v2.1.19Sven Gothel2020-07-281-6/+5
| | | | | | findDiscoveredDevice, .. .. however, we leave certain INFO_PRINT giving us notice about non-tracked devices.
* Expose hciConnectionHandle: AdapterStatusListener connect/disconnect ↵Sven Gothel2020-07-2815-51/+89
| | | | | | | | | | (C++/Java) and BluetoothDevice.java To help tracking a device in user space and support more 'down to the metal' access, the HCI connection handle has been exposed to the Java DBTDevice and the AdapterStatusListener. For the latter, especially disconnectDevice(..) is of interest, since the disconnected handle is lost already when the callback gets invoked.
* DBTAdapter: Increase verbosity DBG -> INFO + enhance output (shall moved to ↵Sven Gothel2020-07-281-8/+15
| | | | DBG later on)
* DBT Adapter/Device: Enhance WARN and DBG PRINT (no more verbosity)Sven Gothel2020-07-282-6/+14
|
* DBTAdapter::mgmtEvDeviceDiscoveringMgmt: Don't hold mtx_discovery: Not ↵Sven Gothel2020-07-271-1/+0
| | | | | | | | | | | | necessary (all atmomic) and performing listener callbacks! DBTAdapter::mgmtEvDeviceDiscoveringMgmt will eventually call all AdapterStatusListener::discoveringChanged(..) methods, which may in return call stopDiscovery(..) to force 'radio silence' (in a user application). Any mutex locks on native callbacks, which are calling user callback functions itself are under scrutiny and prone to deadlocks! DBTManager as well as DBTManager have no more mutex locks in their own potentially relaying callbacks.
* DBTAdapter::mgmtEvDeviceFoundMgmt: Fix drop INFO_PRINT to ↵Sven Gothel2020-07-271-5/+5
| | | | 'DBTAdapter::EventCB:DeviceFound: Drop already discovered...'
* Add convenient GNU/Linux start/stop scripts for bluetoothdv2.1.18Sven Gothel2020-07-272-0/+14
|
* DBusManager_delete: Do not call destructor, C++ implementation says so. ↵Sven Gothel2020-07-271-1/+2
| | | | Avoid double free @ closing.
* DBTManager.getServices(): Simplify gathering services, dropping manual connect.Sven Gothel2020-07-271-17/+6
|
* C++/Java *Device::connect*(..), disconnect(): Return HCIStatusCode instead ↵Sven Gothel2020-07-2718-141/+224
| | | | | | | of just boolean, passing through potential HCI error detail The HCIStatusCode on failed connect*/disconnect commands issued via direct_bt HCI, could help applications making a better fail-recovery decision than just having the binary result.
* ScannerTinyB10: Wrap whole services/characteristic walk through block in a ↵Sven Gothel2020-07-271-15/+15
| | | | try - catch, avoiding retry on exception and fail once only.
* BluetoothUtil: Add getElapsedMillisecond(); ScannerTinyB10 shows elapsed ↵Sven Gothel2020-07-273-62/+95
| | | | | | | | | milliseconds in log upfront. BluetoothFactory stores the magic t0, i.e. module startup time, to be used to be substracted from current time to determine elapsed milliseconds. Naturally, this can only be used after initialization of the native library, before initialization this value is just 0.
* GATTHandler::sendWithReply(): Disclose timeout value in error and exception ↵Sven Gothel2020-07-272-4/+4
| | | | on .. timeout
* DBTAdapter.cpp: Turn VERBOSE_ON off (oopsie)Sven Gothel2020-07-261-1/+1
|
* GATTHandler: INFO -> ERROR: MULTI-NTF not implementedv2.1.17Sven Gothel2020-07-261-1/+1
|
* DBTDevice::disconnect/GATTHandler::[dis]connect: Place atomic-switch before ↵Sven Gothel2020-07-263-19/+36
| | | | | | | | | | | | | mutex-lock, avoiding re-entry deadlock Commit 86eef03c262a0e93800c1558ce81e32e0d899ab1, GATTHandler: connect/disconnect: Lock mtx_command, actually introduced a deadlock putting the mutex-lock before the 'atomic-switch'. Since DBTDevice.disconnect can be issued by GATTHandler:disconnect (fault situation), and another thread may also tries to directly DBTDevice.disconnect about the same time (shutdown), we need the atomic-switch skipping the sensitive operation before locking down the object. Further, silence the disconnect* commands, INFO_PRINT -> DBG_PRINT.
* GATTCharacteristic::toSafeString(): Remove further dereferencing to service...Sven Gothel2020-07-261-15/+2
|
* ScannerTinyB10: Add shutdown test issued from notify/indicate callback, ↵v2.1.16Sven Gothel2020-07-261-1/+43
| | | | testing robustness of object lifecycle
* dbt_scanner0[01]: Fix conversion from getDevice() -> getDeviceChecked()Sven Gothel2020-07-262-4/+4
|
* GATT[Service,Characteristic,Descriptor]: Use new 'toSafeString()' for ↵Sven Gothel2020-07-266-21/+89
| | | | | | | | | | constructing exception message, avoiding virtual function variant. For an unknown reason, using the virtual function 'toString()' while constructing an exception message causes a SIGSEGV. This method represents a non-virtual variation, which also does not call any other virtual function.
* DBTTypes/JavaUplink: Provide default toString() implementationSven Gothel2020-07-262-1/+4
|
* GATTHandler: connect/disconnect: Lock mtx_command.Sven Gothel2020-07-261-0/+4
|
* Robustness: Distinguish between get<Type>Checked() and get<Type>Unchecked(): ↵Sven Gothel2020-07-2610-50/+64
| | | | Use it accordingly, reducing duplicated code etc.
* Shutdown: Drop special case, working on robustnessSven Gothel2020-07-263-56/+34
|
* DBTDevice.cpp: Fix DBG_PRINT..Sven Gothel2020-07-261-3/+3
|
* Have GATT[Service,Characteristic,Descriptor] derived from DBTObject for ↵Sven Gothel2020-07-2612-77/+118
| | | | valid check; Use new JNI getInstance() -> getDBTObject() w/ valid check
* Make GATTHandler::configNotificationIndication(..) fault tolerant on disable ↵Sven Gothel2020-07-251-1/+11
| | | | | | call, similar to GATTCharacteristic::configNotificationIndication Disabling notify/indicate must be tolerated, as it usually gets called @ shutdown
* GATTCharacteristic: Add enableNotificationOrIndication(..)..; ↵v2.1.15Sven Gothel2020-07-2511-43/+255
| | | | | | | | | | | | | | | | | | | | | | | DIRECTBT_CHARACTERISTIC_VALUE_CACHE_NOTIFICATION_COMPAT GATTCharacteristic (Java/C++): Add enableNotificationOrIndication(..) and use it as default for BLE active addCharacteristicListener(..). It is recommended to utilize notification over indication, as its link-layer handshake and higher potential bandwidth may deliver material higher performance. +++ Add setting BluetoothFactory.DIRECTBT_CHARACTERISTIC_VALUE_CACHE_NOTIFICATION_COMPAT (and also document DEBUG and VERBOSE). DIRECTBT_CHARACTERISTIC_VALUE_CACHE_NOTIFICATION_COMPAT Have direct_bt provide compatibility to TinyB's BluetoothGattCharacteristic API: BluetoothGattCharacteristic#getValue() value cache and BluetoothGattCharacteristic#enableValueNotifications(BluetoothNotification) value notification. DBTGattCharacteristic benefits from _disabled_ compatibility (and DEBUG) performance wise, as no listener nor cache needs to be added in this case!
* DBTGattCharacteristic::configNotificationIndicationImpl(..): Tolerate ↵v2.1.14Sven Gothel2020-07-243-2/+17
| | | | deleted native instance @ disable
* DBTGattCharacteristic removeAllAssociatedCharacteristicListener(..): Also ↵Sven Gothel2020-07-241-0/+1
| | | | clear valueNotificationCB
* DBTGattCharacteristic: Always pass valid boolean[2] to ↵Sven Gothel2020-07-241-2/+2
| | | | configNotificationIndication(..)
* Reworking GATTCharacteristicListener (C++ and Java)Sven Gothel2020-07-2427-327/+697
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Aligned all related C++ and Java API doc entries and made sure it matches implementation. - Renaming SpecificGATTCharacteristicListener to AssociatedGATTCharacteristicListener, as we refer to the associate GATTCharacteristic of a GATTCharacteristicListener AssociatedGATTCharacteristicListener is a specialization knowing its associated GATTCharacteristic to be used for match(). - Renamed 'configIndicationNotification(..)' to 'configNotificationIndication(..)', matching order of arguments and the returned enabledState array. - Exposed 'configNotificationIndication(..)' incl enabledState array to Java - Clarified the 'add listener' and 'configNotificationIndication(..)' semantic in API doc and implementation. Added new API entries to distinguish them. - DBTGattCharacteristic.java skips adding its 'TinyB API compatibility' GATTCharacteristicListener in case neither notify nor indicate property exist. Also skip the native configNotificationIndication(..) in such case. This reduces the overall listener load to GattHandler by factor 5! - General: Add new method 'removeAllAssociatedCharacteristicListener(GATTCharacteristic)', allowing removal of all GATTCharacteristic associated listener. This is usefull to complete the GATTCharacteristic C++ dtor or Java close() operation. - DBTDevice: Add GATTCharacteristicListener methods to align with Java API and allow user not to deal with GATTHandler directly. Convenience and validates the C++/Java API alignement. - C++ JNICriticalArray: Added 2nd template typename for the java-array-type, enabling it for other than jbyteArray. Here used for a jbooleanArray. - The GATTCharacteristicListener Java to C++ native holding specialization JNICharacteristicListener keeps a new global reference to the Java GATTCharacteristicListener and the optional associated GATTCharacteristic. This ensures the instances won't get garbage collected and hence ensures proper object lifecycle even when passing 'throw away' listener object created just for the add*Listener call. - Removal and hence destruction of the listeners is always guaranteed at: -- Device / GATTHandler disconnect -- GattCharacteristic dtor or close
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-14 04:43:57 +0000