aboutsummaryrefslogtreecommitdiffstats
path: root/api
Commit message (Collapse)AuthorAgeFilesLines
...
* DBTAdapter::stopDiscover() now returns the boolean result w/ proper native ↵Sven Gothel2020-08-231-1/+1
| | | | | | | | | -> 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
* HCIHandler: Add le_set_scan_param(..) and le_enable_scan(..)Sven Gothel2020-08-231-0/+20
| | | | | | | 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-231-1/+1
| | | | | Utilzing new HCIHandler MgmtEvtDeviceFound events from LE_ADVERTISING_REPORT, see commit a49ce8a8a72eb34cc6a4c8d23e4907684350d078
* HCIHandler: Produce MgmtEvtDeviceFound events from LE_ADVERTISING_REPORT; ↵Sven Gothel2020-08-233-18/+71
| | | | | | | | | | | | | | | 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-232-6/+9
| | | | | | | | | | | | | | | 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.
* DBTAdapter: Have non-enabled adapter to be valid, use lazy HCI ↵Sven Gothel2020-08-221-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* DiscoveryState: Complete state transition tableSven Gothel2020-07-291-10/+10
|
* DBTAdapter DiscoveryState: Refine currentMetaScanType, introduce ↵Sven Gothel2020-07-291-5/+26
| | | | | | | | | | | | | | | | | | | | | | | | | 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-295-18/+45
| | | | definition and add getScanTypeString(..) getScanType(BTMode)
* Fix typo in HCIStatusCode enum valueSven Gothel2020-07-281-1/+1
|
* Expose hciConnectionHandle: AdapterStatusListener connect/disconnect ↵Sven Gothel2020-07-282-5/+7
| | | | | | | | | | (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.
* C++/Java *Device::connect*(..), disconnect(): Return HCIStatusCode instead ↵Sven Gothel2020-07-272-29/+37
| | | | | | | 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.
* DBTDevice::disconnect/GATTHandler::[dis]connect: Place atomic-switch before ↵Sven Gothel2020-07-261-1/+2
| | | | | | | | | | | | | 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.
* GATT[Service,Characteristic,Descriptor]: Use new 'toSafeString()' for ↵Sven Gothel2020-07-263-5/+33
| | | | | | | | | | 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
|
* Robustness: Distinguish between get<Type>Checked() and get<Type>Unchecked(): ↵Sven Gothel2020-07-263-7/+9
| | | | Use it accordingly, reducing duplicated code etc.
* Have GATT[Service,Characteristic,Descriptor] derived from DBTObject for ↵Sven Gothel2020-07-265-8/+21
| | | | valid check; Use new JNI getInstance() -> getDBTObject() w/ valid check
* GATTCharacteristic: Add enableNotificationOrIndication(..)..; ↵v2.1.15Sven Gothel2020-07-253-13/+53
| | | | | | | | | | | | | | | | | | | | | | | 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!
* Reworking GATTCharacteristicListener (C++ and Java)Sven Gothel2020-07-243-34/+141
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - 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
* DBTAdapter/Device: Simplify adapter's HCIHandler access, as we can rely on ↵Sven Gothel2020-07-222-6/+10
| | | | its existence if adapter.isValid()
* DBTAdapter: startDiscovery(..) also might need to change ↵Sven Gothel2020-07-221-1/+1
| | | | | | | | | | | | | | | | 'keepDiscoveringAlive' even if still in discovery Hence adding locking mtx_discovery in mgmtEvDeviceDiscoveringMgmt due to multiple state changes and updating keepDiscoveringAlive even if not initiating discovery (still running). Further all calls to startDiscovery(..) (C++ and Java) shall clear the list of discovered devices to end up in the same state, regardless of an alread running discovery or not. Note: We might have to observe this behavior in more detail, but as we usually utilize the status listener model, this list is of less interest. The Java implementation simply always calls down to native code, ensuring same 'keepAlive' behavior. It hence also always clears the list of discovered devices.
* HCIHandler: Track all incoming connections, even if not initiated by user ↵Sven Gothel2020-07-211-11/+31
| | | | | | | | | | | | | | | | directly (e.g. whitelisted devices) HCIConnection: - Clarify identity using address _and_ addressType - Make members private for immutable access only, except handle. HCIHandler: - Track all incoming connections, i.e. events. Earlier we initiated tracking only via user connect calls, now we allow any incoming connection being tracked (e.g. whitelisted devices). - Correctly identify devices with address _and_ addressType - or - the connection handle using HCIConnection etc.
* DBTAdapter: Make HCIHandler instance aggregated (lifecycle over full adapter ↵Sven Gothel2020-07-211-14/+9
| | | | | | | | | | | | | lifecycle) Since HCIHandler is being used to track all connections (direct or whitelisted), it is essential to have it running over the whole adapter lifecycle. openHCI() is now being performed within validateDevInfo(), hence also sets adapter's valid state. Call newly added checkValid() in user API on most 'action' methods, throws exception if adapter is in invalid state.
* Direct-BT: Fix API doc regarding DBTDevice's HCI connect requirement; HCI ↵Sven Gothel2020-07-173-9/+1
| | | | | | | | | connect must be performed (not a performance issue) Our earlier code used the manager's implicit whitelist feature to connect. The earlier performance lag was due to slow scanning parameter, not the fact that no connection has been made.
* Direct-BT: Update API doc details: Remove mentioning HCIComm (too low level now)Sven Gothel2020-07-171-2/+1
|
* Direct-BT: Update API doc details: DBTManager's BlueZ Kernel utilization and ↵Sven Gothel2020-07-171-5/+7
| | | | new HCIHandler
* DBTDevice: Clarify and distinguish GAP discovered services from read GATT ↵Sven Gothel2020-07-151-8/+20
| | | | | | services; Add findGATTService(..) Note: We might want to add more find(..) functionality, similar to the TinyB Java API.
* Extract dfa_utf8_decode.[cpp/hpp] added to libtinyb.so, i.e. used for both ↵Sven Gothel2020-07-042-14/+53
| | | | native libs commonly exposed in Java via BluetoothUtils.cxx JNI
* DBTAdapter::printDevices() -> printSharedPtrListOfDevices() + API doc ↵Sven Gothel2020-07-031-1/+5
| | | | remark: .. debug facility
* DBTDevice lookup in DBTAdapter requires its EUI48 address _and_ BDAddressTypeSven Gothel2020-07-031-6/+5
| | | | | Concluding commit 22e3abf3661d7de42b3e6c738d8167718e3ca218, having all DBTDevice lookups (find) in DBTAdapter using the BDAddressType as well.
* DBTDevice (C++/Java) equality/identity requires its EUI48 address _and_ ↵v2.1.11Sven Gothel2020-07-031-1/+1
| | | | | | | BDAddressType The BDAddressType is the magic 49th bit of the EUI48 address, as it specifies the semantics of its 2-high bits.
* EUI48::getBLERandomAddressType(): Pass BDAddressType, to only return a valid ↵Sven Gothel2020-07-031-4/+2
| | | | | | | | | | BLERandomAddressType related to the BDAddressType. We validated the BLERandomAddressType in DBTDevice.java, but created an invalid value in DBTDevice.cpp regardless of BDAddressType. Resolved! We also perform the validate in DBTDevice.cpp now.
* GATTHandler: Initial GATT reply may even require ~2s, setting timeout to 2500ms.v2.1.10Sven Gothel2020-07-021-2/+2
| | | | See commit 6f67d72923b31dd5db32227a0a8f46c11bc9a9f3
* GATTHandler: Tolerate a 3x usual reply timeout (3x 500ms) for first GATT ↵Sven Gothel2020-07-021-2/+4
| | | | | | | | | exchange (MTU) Certain devices might require more time for their first GATT response, which usually shall lie within 500ms. This patch tolerates 1500ms.
* Support BDADDR_LE_RANDOM (p1.3): HCIHandler: Earmark notable SPEC sections ↵Sven Gothel2020-07-021-0/+27
| | | | and procedured WIP
* Support BDADDR_LE_RANDOM (p1.2): Map BLERandomAddressType::STATIC_PUBLIC -> ↵Sven Gothel2020-07-021-2/+1
| | | | | | | | | | | | | | RANDOM; L2CAPComm uses device->getAddressType() Map BLERandomAddressType::STATIC_PUBLIC -> HCILEPeerAddressType::RANDOM This only works for a static random address not changing at all, i.e. between power-cycles - hence a temporary hack. We need to use 'resolving list' and/or LE Set Privacy Mode (HCI) for all devices. +++ L2CAPComm uses device->getAddressType(), i.e. no need for a (wrong) public argument flag.
* Support BDADDR_LE_RANDOM (p1.2): Add ↵Sven Gothel2020-07-021-4/+14
| | | | HCILEPeerAddressType/HCILEOwnAddressType String representation + API doc
* aarch64: <sys/param.h> defines __u64 _le64 and __be64Xerxes Rånby2020-07-021-0/+10
| | | | | # Conflicts: # api/direct_bt/linux_kernel_types.hpp
* Support BDADDR_LE_RANDOM (p1): Add BLERandomAddressType, distinguish ↵Sven Gothel2020-07-025-71/+141
| | | | | | | | | | | | | | | | | | | | | | | | | | HCIAddressType..., Move EUI48 into direct_bt namespace Add BLERandomAddressType Exposed in DBTDevice and BluetoothDevice C++ and Java. See "BT Core Spec v5.2: Vol 6 LE, Part B Link Layer Specification: 1.3.2 Random device Address" +++ Distinguish HCIAddressType -> HCILEPeerAddressType + HCILEOwnAddressType As used for HCIHandler::le_create_conn(..) See "BT Core Spec v5.2: Vol 4, Part E Host Controller Interface (HCI) Functionality: 7.8.12: LE Create Connection command" DBTDevice::connectLE(..) translates its own BDAddressType -> HCILEPeerAddressType using BLERandomAddressType (BDAddressType, address). Currently only HCILEPeerAddressType::STATIC_PUBLIC is allowed and passed through. +++ Move EUI48 into direct_bt namespace
* Minor armv7l g++ 8.3.0 build fixedSven Gothel2020-07-021-2/+2
| | | | | | Used 32bit machine: Raspbian 10.4 'buster', armv7l (armhf), g++ 8.3.0, OpenJDK 11.0.7 Note that main development occurs on GNU/Linux Debian 11 'bullseye', amd64, g++ 9.3.0, OpenJDK 11.0.7
* Resolve circular references (p2): Java DBTDevice, GATTHandler, GATTService, ↵Sven Gothel2020-06-294-4/+4
| | | | | | | | | | | | | | pp are not owner of their resepctive backreference Even though the Java GC is capable to resolve circular references as long they are not specifically being hold by a running thread, we use WeakReference for a more clean lifecycle description. This is aligned to the C++ changes of commit dfdfd883f52e8d31c005d0f8ae42bbe6dd60c2b8 Further, also have 'DBTDevice -> DBTAdapter' backreference being weak for completion. Further, DBTDevice.remove() also removes itself from DBTAdapter's discoveredDevice list.
* Resolve circular references (p1): C++ GATTHandler, GATTService, pp are not ↵Sven Gothel2020-06-297-14/+51
| | | | | | | | | | | | | | | | | | | | owner of their resepctive backreference GATTHandler, GATTService, pp are not owner of their resepctive backreference, hence use std::weak_ptr for backreferences in general and validate on usage (nullptr, if destructed). No DBTDevice has been ever destructed after using GATTHandler and discovering all GATT services. In contrast to Java, C++ has no magic GC and hence shared_ptr use_count gets only increased when emplying circular backreferences - none gets destructed. Current ownership relationship is: DBTAdapter -> DBTDevice -> GATTHandler -> GATTService ... each contains a backreference, now using a weak_ptr. Result is that depending on the use-case, DBTDevice instances are destructed: - Using device->remove(): Immediately - No explicit device->remove(): Adapter keeps sharedDevices, destruction occurs at end.
* DBTAdapter::mgmtEvDeviceFoundMgmt: Show count of device in discoveredDevices ↵Sven Gothel2020-06-281-0/+1
| | | | | | if already discovered Should max return 1, however, analyzing issue having no more devices being discovered.
* Use HCIHandler *connect*/disconnect; Enhance native + java testSven Gothel2020-06-273-19/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Use HCIHandler *connect*/disconnect incl related events (Drop DBTManager in this regard) > Add CONNECT_FAILED HCI listener mgmtEvConnectFailedHCI -- Issuing a DISCONNECT event > DBTAdapter: mgmtEvDeviceConnectedHCI -- Always pass through, just issue WARNING if not a new_connect (TBD) > DBTAdapter: mgmtEvDeviceDisconnectedHCI + mgmtEvDeviceConnectedHCI -- removeConnectedDevice pre event issuing -- removeDiscoveredDevice post event issuing > DBTDevice: -- Add isConnectIssued to differentiate isConnected on event -- Only use HCIHandler's *connect*/disconnect -- disconnect(..) no more issues removeConnectedDevice, rely ion correct event issuing/handling, as performed in time @ mgmtEvDeviceDisconnectedHCI... -- remove() issues removeConnectedDevice and removeDiscoveredDevice pre releaseSharedInstance to ensure a clean tracking state. The whole purpose of this command. +++ Enhance native + java test After disconnect() wait (poll) until no more connected, before issuing remove(), this shall ensure proper workflow pre remove() - validation of disconnect command.
* HCIHandler: Complete HCIConnection Tracker for full *connect* and disconnect ↵Sven Gothel2020-06-273-34/+46
| | | | | | | | | | | | | | | | support incl HCI connection handle We move *connect* and disconnect from DBTManager to HCIHandler, as we need full control of the connection tracker due to: - expose HCI connection handle to match actual session for disconnect - control the disconnect on IOError (no command, purge tracker element and send event) DBTManager::disconnect: - no more used - still aligned the 'send event' on ioerror code path HCIHandler, DBTManager: - Own callbacks for verbose mode only added in VERBOSE_ON compilation
* DBTAdapter: Unify all findDevice*(..) methods, ensure all list access is ↵Sven Gothel2020-06-271-5/+7
| | | | synchronized
* L2CAPComm/GATTHandler: Use prefetched 'deviceString' for verbose outputSven Gothel2020-06-261-4/+2
| | | | This potentially avoid a SIGSEGV in case of an error, i.e. destructed device instance.
* Align DBTDevice's C++ getGATTServices() w/ Java getServices(): Catch ↵Sven Gothel2020-06-261-2/+8
| | | | exception and return an empty list (on error/exception)
* GATTHandler: Add mtx_command for all public accessible functions, ensuring ↵Sven Gothel2020-06-251-0/+1
| | | | | | | | | sequential processing is ensured GATTHandler servers one device, however, applications may utilize multithreading and concurrent command requests may lead to wrong replies. Similar to DBTManager and HCIHandler, top-level entries shall be synchronized.
* GATTHandler/DBTDevice (incl Java): Add ping[GATT](), testing device ↵Sven Gothel2020-06-252-0/+30
| | | | | | | | | | | | | | | | availability via retrieval of GATT info Issues a ping to the device, validating whether it is still reachable. This method could be periodically utilized to shorten the underlying OS disconnect period after turning the device off, which lies within 7-13s. In case the device is no more reachable, disconnect will be initiated due to the occurring IO error. +++ Implementation attempts to read the mandatory APPEARANCE CharacteristicValue of the mandatory GENERIC_ACCESS service.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-14 16:58:10 +0000