summaryrefslogtreecommitdiffstats
path: root/java
Commit message (Collapse)AuthorAgeFilesLines
* GATTCharacteristic: Add enableNotificationOrIndication(..)..; ↵v2.1.15Sven Gothel2020-07-256-21/+165
| | | | | | | | | | | | | | | | | | | | | | | 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-2415-157/+388
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - 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
* 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-221-5/+4
| | | | | | | | | | | | | | | | '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.
* DBTAdapter: Make HCIHandler instance aggregated (lifecycle over full adapter ↵Sven Gothel2020-07-211-2/+2
| | | | | | | | | | | | | 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.
* 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-175-21/+456
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* 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-041-7/+97
| | | | 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-043-58/+28
| | | | native libs commonly exposed in Java via BluetoothUtils.cxx JNI
* tinyb: fix jni unresolved symbols (add namespace to implementationSven Gothel2020-07-041-4/+4
|
* DBTDevice lookup in DBTAdapter requires its EUI48 address _and_ BDAddressTypeSven Gothel2020-07-031-10/+2
| | | | | 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-032-5/+14
| | | | | | | | | | 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.
* DBTAdapter_removeStatusListener (JNI): No complaint for unused ↵Sven Gothel2020-07-021-1/+1
| | | | statusListener (remove @ takedown)
* 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-026-28/+155
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+1
| | | | | | 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
* 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.
* DBTDevice.java: Align its identity with C++: Only use EUI48 address for hash ↵Sven Gothel2020-06-291-2/+2
| | | | and equality
* Resolve circular references (p3): Java: Ensure DBTDevice can be GC'ed (at ↵Sven Gothel2020-06-294-26/+32
| | | | | | | | | | | | | | | | | | | | | | | remove()) DBTDevice.close() - Also issue adapter.removeDiscoveredDevice(this); Without, the Java DBTDevice wouldn't get GC'ed - close(): super.close() -> delete() -> deleteImpl() -> DBTDevice::remove() DBTDevice.remove() - Simply calls close(), implying DBTDevice::remove() and complete reference cleanup. ScannerTinyB10: - argument '-debug' to enable DEBUG/VERBOSE DBTAdapter.cxx: - Just give more clarity on DBTDevice.java creation and delete local ref. DBTDevice.cxx:: getServices() JNI - No need to call device->connectGATT()
* Resolve circular references (p2): Java DBTDevice, GATTHandler, GATTService, ↵Sven Gothel2020-06-296-22/+64
| | | | | | | | | | | | | | 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-293-6/+18
| | | | | | | | | | | | | | | | | | | | 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.
* Java DBTNativeDownlink toString(): If !valid use alternative short ↵Sven Gothel2020-06-286-6/+32
| | | | | | | representation adding '✝' after type. This shall allow still using toString() while marking it deleted, after 'notifyDeleted()' or 'delete()' has been issued.
* Notify DBTNativeDownlink when its native JavaUplink -> JavaGlobalObj ↵Sven Gothel2020-06-276-8/+49
| | | | | | | | | | | counterpart gets destructed DBTNativeDownlink.notifyDeleted() gets called from native destructor, so isValid and nativeInstance can be set accordingly. This resolves a periodic crash when GATTHandler flushes it's GATTServices and linked resources. Here the DBTGATTService.java's DBTNativeDownlink still holds the native instance handle and as it gets finalized after the native object, accessing it post mortem causes a SIGSEGV.
* BluetoothDevice pingGATT() non implementation shall return true, as false ↵v2.1.7Sven Gothel2020-06-252-2/+2
| | | | shall lead to aborting the application process.
* GATTHandler/DBTDevice (incl Java): Add ping[GATT](), testing device ↵Sven Gothel2020-06-254-0/+45
| | | | | | | | | | | | | | | | 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.
* DBTDevice::getServices() shall not throw an exception but return null on ↵Sven Gothel2020-06-242-2/+13
| | | | error (TinyB API)
* HCIHandler: Use async event mechanism for delayed replies, commands shall ↵Sven Gothel2020-06-241-11/+11
| | | | | | | | | | | | | | | | | return immediately (2/2) Adjust using HCIHandler changes, see commit 9900ef4b93c191c0ac4fa8f941e06a5a8045257c - DBTAdapter listens to HCIHandler callbacks: *connected* and *disconnected* using same callback implementations as for DBTManager. - DBTDevice::notifyConnect receives the actual connection handler and will be called for all connected callbacks (DBTManager and HCIHandler) - DBTDevice adjusted return values for *connect* and *disconnect*, no more connection handle available immediately. Further changes:
* Direct-BT: API doc and clarify interface JavaAnonObj, JavaUplink and ↵Sven Gothel2020-06-181-1/+9
| | | | | | | JavaAnonObj implementation JavaGlobalObj JavaAnonObj is now a full virtual interface. JavaGlobalObj gets default spec for copy and move ctor and assignment.
* DBTAdapter (Java/C++): Explicit synchronization on start/stop discovery, ↵Sven Gothel2020-06-101-7/+12
| | | | avoiding race condition on discovery state
* DBTDevice (C++/Java): Expose getLastDiscoveryTimestamp() and rename ↵Sven Gothel2020-06-094-10/+53
| | | | | | | lastUpdate: getLastUpdateTimestamp() For performance measurement discovery -> gatt complete, we need to use the last discovery timestamp, since the device could have been created earlier.
* BluetoothManager startDiscovery(): Add @Deprecated tag; Fix misc DBG_PRINT ↵Sven Gothel2020-06-091-0/+1
| | | | commands
* Java/C++: start/stop discovery shall return true even if operation not requiredSven Gothel2020-06-091-1/+1
|
* C++: Utilize 'currentScanType' for start/stop discovery same as for Java ↵Sven Gothel2020-06-091-0/+4
| | | | | | | | | | code; use atomic<ScanType> avoiding race conditions C++/Java: Only update the discovering state for false in DISCOVERING listener if keepAlive == false. C++ like Java pendant, only perform start/stop discovery in appropriate discovery state C++ expose discovery state 'currentScanType'
* DBTDevice.java: Add missing semicolon (oops)Sven Gothel2020-06-091-1/+1
|
* DBT Adapter/Device (java): Use AtomicBoolean for states and only handle ↵Sven Gothel2020-06-092-153/+139
| | | | | | | results from AdapterStatusListener - DBTAdapter.java: Explicitly lock user callbacks (like DBTDevice) - Remove unnecessary synchronized from methods, AtomicBoolean and explicit locks must suffice
* DBTAdapter.java: startDiscovery() -> keepAlive=true defaultSven Gothel2020-06-091-2/+2
|
* [DBT]Adapter (Java/C++) startDiscovery(bool keepAlive) policy change: ↵Sven Gothel2020-06-094-1/+27
| | | | | | | | | | | | | | | keepAlive default := true Using startDiscovery(keepAlive=true) and stopDiscovery() is the recommended workflow for a reliable discovery process. Without keepAlive=true, we already experienced a too short discovery cycle where the subsequent manual startDiscovery restart will purge the already discovered devices via removeDiscoveredDevices(). Hence keepAlive=true is strongly indicated for increased reliability especially when _not_ using the AdapterStatusListener, since adapter.getDevices() may simply come too late.
* Expose 'org.tinyb.verbose' and 'org.tinyb.debug' via BluetoothFactory ↵Sven Gothel2020-06-092-2/+8
| | | | VERBOSE and DEBUG. Use the latter in DBTManager.
* L2CAPComm/GATTHandler: User 'enum class' constants for type safety; Drop ↵Sven Gothel2020-06-091-1/+1
| | | | GATTHandler::State for L2CAPComm::State
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-03 03:47:48 +0000