summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* 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
* ScannerTinyB10: Fix verbose and debug setting: Set properties _before_ ↵Sven Gothel2020-07-241-2/+7
| | | | | | | accessing BluetoothFactory BluetoothFactory static init will set its VERBOSE and DEBUG field as read from properties, hence we need to postpone its access.
* ScannerTinyB10 @ pingGATT: Only initiate discovery temporary w/o need to ↵v2.1.13Sven Gothel2020-07-221-2/+1
| | | | | | | | | | | disable it (self disable) The temp discovery enabling kick-off simply ensures that discovery allows new devices to be found, no need to disable it @ pingGATT. Further startDiscovery commands will be ignored if in process, may only change the keepAlive state. This reduces the overall workload.
* DBTAdapter/Device: Simplify adapter's HCIHandler access, as we can rely on ↵Sven Gothel2020-07-224-30/+22
| | | | its existence if adapter.isValid()
* DBTAdapter::dtor: Also clear HCIHandler's event callbacksSven Gothel2020-07-221-0/+5
|
* Java DBTAdapter + DBTDevice close @ JVM shutdown: Avoid all interaction, ↵Sven Gothel2020-07-223-31/+54
| | | | | | | | | native dtor (deleteImpl) cleans up. Shortcut of 'close' take-down @ JVM shutdown, avoiding any potential deadlocks. However, all device's and adapter's deleteImpl() gets issued, allowing the native adapter's destructor to be called for orderly device cleanup.
* DBTAdapter: startDiscovery(..) also might need to change ↵Sven Gothel2020-07-224-7/+16
| | | | | | | | | | | | | | | | '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-212-86/+84
| | | | | | | | | | | | | | | | 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-215-83/+64
| | | | | | | | | | | | | 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.
* DBTDevice: Use atomic 'isConnected' to query connection status; Check ↵Sven Gothel2020-07-171-2/+8
| | | | connection status in connectGATT(..)
* 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
* dbus java: Add minimalistic toString() implementation; direct_bt toString(): ↵Sven Gothel2020-07-178-3/+28
| | | | Add uuid for non-native-valid instance's impl.
* Direct-BT Java: Implement find(..) in manager, adapter, device, service and ↵Sven Gothel2020-07-177-65/+561
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | characteristic In contrast to the dbus implementation, where all find(..) is being funnelled through manager's native find(..) vehicle, direct-bt goes the opposite direction reusing the existing cached data within the objects. Manager, adapter, device, service and characteristic object implement findInCache(..), which compares the uuid and/or name *case-sensitive* of its direct childs (if approriate) and traverses through its children's findInCache(..) if required. Note to *case-sensitive* comparison: - EUI48 (mac) address string use capital hex-letters - UUID uses lower-case hex-letters Since service and characteristic object already stores its UUID no extra caching is required here. For device, an extra WeakReference cache of the services has been added when retrieved via getServices(). This cache is used for device's findInCache(..). service and characteristic always check whether their WeakReference uplink is still valid, i.e. no resources pulled (GC'ed) - as well as whether device's cached services exist. This detail is implemented via each object's 'checkServiceCache()'. device's 'checkServiceCache(true)' also will retrieve the services if not done yet within 'findInCache(..)'. This also ensures services has been retrieved for manager and adapter traversing through device via 'findInCache(..)'. Notable, manager's generic find(..) method is *not* implemented: Due to generic type erasure, we cannot determine the matching BluetoothType for the return parameter, hence this orig TinyB API method is rather misleading than useful.
* DBTDevice: Clarify and distinguish GAP discovered services from read GATT ↵Sven Gothel2020-07-152-36/+60
| | | | | | services; Add findGATTService(..) Note: We might want to add more find(..) functionality, similar to the TinyB Java API.
* org.tinyb.BluetoothFactory: API doc note: The chosen implementation can't be ↵v2.1.12Sven Gothel2020-07-041-0/+15
| | | | changed within a running implementation...
* org.tinyb.BluetoothFactory: More versatile ImplementationIdentifier and ↵Sven Gothel2020-07-044-32/+178
| | | | getBluetoothManager(..) using fq BluetoothManager implementation class name
* org.tinyb: API doc: Add @implNote for tinyb.dbus implementationSven Gothel2020-07-044-0/+22
|
* Extract dfa_utf8_decode.[cpp/hpp] added to libtinyb.so, i.e. used for both ↵Sven Gothel2020-07-0410-124/+158
| | | | native libs commonly exposed in Java via BluetoothUtils.cxx JNI
* tinyb: fix jni unresolved symbols (add namespace to implementationSven Gothel2020-07-041-4/+4
|
* DBTAdapter::printDevices() -> printSharedPtrListOfDevices() + API doc ↵Sven Gothel2020-07-033-5/+9
| | | | remark: .. debug facility
* DBTDevice lookup in DBTAdapter requires its EUI48 address _and_ BDAddressTypeSven Gothel2020-07-033-45/+24
| | | | | 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-032-2/+2
| | | | | | | 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-035-20/+39
| | | | | | | | | | 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
* DBTAdapter_removeStatusListener (JNI): No complaint for unused ↵Sven Gothel2020-07-021-1/+1
| | | | statusListener (remove @ takedown)
* Example scanner10 (Java/C++): Show pingGATT OK on console for feedbackSven Gothel2020-07-022-0/+2
|
* GATTHandler: Tolerate a 3x usual reply timeout (3x 500ms) for first GATT ↵Sven Gothel2020-07-022-13/+16
| | | | | | | | | exchange (MTU) Certain devices might require more time for their first GATT response, which usually shall lie within 500ms. This patch tolerates 1500ms.
* DBTAdapter: Remove debug code (discoveredDevices count)Sven Gothel2020-07-021-3/+1
|
* README.md: Refine 'two implementations', add notice how to disable BlueZ ↵Sven Gothel2020-07-021-2/+16
| | | | userspace daemon
* scripts/setup-machine-arch.sh: aarch64Sven Gothel2020-07-021-0/+6
| | | | Original commit by Xerxes Rånby <[email protected]>
* 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-023-11/+15
| | | | | | | | | | | | | | 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-023-14/+57
| | | | 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.1): Add missing DBTAdapter.cxx patch for ↵Sven Gothel2020-07-021-3/+7
| | | | changed DBTDevice.java ctor, added getBLERandomAddressType()
* DBTManager: Range-check user given DefaultAdapterIndex before usingSven Gothel2020-07-021-1/+4
| | | | | DefaultAdapterIndex is user given via property 'org.tinyb.default_adapter', hence a range check is appropriate.
* Support BDADDR_LE_RANDOM (p1): Add BLERandomAddressType, distinguish ↵Sven Gothel2020-07-0217-134/+423
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-022-3/+3
| | | | | | 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
* DBTManager: Use system property (int value) 'org.tinyb.default_adapter' for ↵Sven Gothel2020-06-291-1/+7
| | | | optionally seeding defaultAdapterIndex other than 0
* DBTAdapter: Fix equals(..)Sven Gothel2020-06-291-1/+1
|
* DBTDevice.java: Update 'name' on deviceUpdate EIRDataTypeSet.DataType.NAME ↵v2.1.9Sven Gothel2020-06-292-2/+26
| | | | | | | | | (drop final qualifier, add volatile) On rare occasions (?) it may happen that the device discovery didn't include the device's name when reported via deviceFound(..) callback etc. Therefor allow updating of the name, using the C++ DBTDevice::getName().
* DBTGattCharacteristic.disableValueNotifications(): Tolerate exception at ↵Sven Gothel2020-06-291-3/+10
| | | | 'take down' and ensure valueNotificationCB ref is nulled
* DBTAdapter: DBTDevice list find operations: Always compare the DBTDevice ↵Sven Gothel2020-06-291-17/+19
| | | | address and perform nullptr checks
* Resolve regression calling DBTNativeDownlink.delete() having notifyDeleted() ↵Sven Gothel2020-06-2914-47/+72
| | | | | | | | | | | | | | | being called back from deleteNativeJavaObject(..) Regression introduced with commit 83e0c7f75b4206701c1b9c62ebd4282f50f92a31 DBTNativeDownlink.delete() calls DBTNativeDownlink.deleteNativeJavaObject(..), which by itself now calls back using DBTNativeDownlink.notifyDeleted() and purges isValid and nativeInstance. Therefor, DBTNativeDownlink.delete() needs to cache the nativeInstance reference and pass it down to DBTNativeDownlink.deleteImpl(long) as argument. Further refine synchronization, using a local Object and isValid being an AtomicBoolean to allow isValid() return the current state.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-01 12:32:53 +0000