aboutsummaryrefslogtreecommitdiffstats
path: root/java/org
Commit message (Collapse)AuthorAgeFilesLines
* API Change C++/Java: BTGattChar::addCharListener(..): Use naive ↵v2.2.13Sven Gothel2021-08-282-41/+72
| | | | | | | | | | | | | | | | | | | BTGattChar::Listener and have implementation handle the BTGattChar association match for notifications Turns out previous API and code moved the burden to user to only have the calling BTGattChar object to be matched, which is not only not intuitive, but also a potential source of issues. Now we provide a naive interface BTGattChar::Listener to be passed and BTGattChar::addCharListener(..) wraps its instance in a BTGattCharListener to be delegated. BTGattChar::removeCharListener(..) has been removed due to high implementation burden on the Java side. This shall not cause harm to the user, as it isn't useful in a user application. BTGattChar::removeAllAssociatedCharListener(..) is available on the C++ and Java side, i.e. fixed API in C++ where we had BTGattChar::removeAllCharListener(..). Tested and demonstrated in dbt_scanner10.cpp and DBTScanner10.java, as usual. Both examples also print the service, characteristic and declaration in a more readable fashion.
* Fix EUI48Sub::scanEUI48Sub(..): Fail on missing expected colon, i.e. after ↵Sven Gothel2021-08-251-3/+10
| | | | each two digits
* BTDeviceRegistry::DeviceQuery: No need for EUI48Sub string representation if ↵Sven Gothel2021-08-051-1/+1
| | | | address
* EUI48Sub::toString(): if 0 == length return ":", allowing fully functional ↵Sven Gothel2021-08-051-2/+2
| | | | EUI48Sub <-> string conversion
* BTDeviceRegistry::DeviceQuery: Use explicit enum type distinguishing address ↵Sven Gothel2021-08-051-12/+30
| | | | or name to allow empty EUI48Sub for all devices
* BTDeviceRegistry, BTSecurityRegistry: Expose universal pattern matching, fix ↵Sven Gothel2021-08-052-45/+247
| | | | | | | | | | | | | | | basic use cases Universal methods use a 'matcher' interface (Java) or function pointer (C++), which can be defined 'on the fly' using lambda expressions. Basic use cases BTDeviceRegistry: - use 'contains' in general to match for awaited, processed etc devices Basic use cases BTDeviceRegistry: - For getOrCreate() uses 'equals' for a 100% match - For sec_level use getStartOf() with actual address and name - For PASSKEY etc use getStartOf() with actual addess only - no fuzzy name
* BTDeviceRegistry: Replace print*() to get*String() and clarify method names ↵Sven Gothel2021-08-041-10/+11
| | | | (C++ and Java)
* BTDeviceRegistry + BTSecurityRegistry: Expose underlying collection (C++ and ↵Sven Gothel2021-08-042-3/+60
| | | | Java)
* BTDeviceRegistry.[cpp/java]: Bring back unordered_set/HashSet for ↵Sven Gothel2021-08-011-24/+37
| | | | | | | devicesInProcessing and devicesProcessed for O(1) processing. Add hash_code()/hashCode() and equality operation to DeviceID using BDAddressAndType only, allowing devicesInProcessing and devicesProcessed to be mostly operated within O(1).
* Update Examples doc root entry for dbt_scanner10.cpp and DBTScanner10.javaSven Gothel2021-07-311-0/+3
|
* dbt_scanner10/DBTScanner10: Extract BTDeviceRegistry and BTSecurityRegistry ↵Sven Gothel2021-07-312-0/+306
| | | | | | | | | | | | | | to lib, support full EUI84Sub and name-sub pattern matching Same naming-schema and functionality C++/Java Due to using EUI48Sub and name-sub pattern matching, we naturally had to drop the hash-set fast-lookup approach. However, looking up device names via pattern-matching is essential to handle device groups, i.e. - specific security settings (level, passkey, ..) - actually accepting them to connect (waitForDevices)
* Java: EUI48Sub add: hash_code(), clear(), indexOf(), contains(), ↵Sven Gothel2021-07-312-53/+205
| | | | operator==() etc; EUI48[Sub]: Add static 'scanEUI48[Sub]'(string&) and static 'indexOf()'
* SMPKeyFile: Tightened Constraints: readAndApply(..) key file's ↵Sven Gothel2021-07-291-12/+32
| | | | | | | | | | | BTSecurityLevel must be >= given minimum; Remove key file if invalid or failed otherwise Drop paramter 'removeInvalidFile', since read(..) and readAndApply(..) shall always delete invalid files or key files with non-matching BTSecurityLevel. This ensures valid, usable and current key files. This also resolved scenario reading a key file with BTSecurityLevel NONE, but requested higher BTSecurityLevel.
* Passthrough all paramter BTAdapter::startDiscovery(..) -> ↵Sven Gothel2021-07-282-2/+25
| | | | | | | | | | | | | HCIHandler::le_set_scan_param(..): Add le_scan_active and filter_policy; Java: Add all. Also changing order of parameter, allowing to use default values in a most reasonable sense. Motivation: Expose `le_scan_active` to retrieve the AD EIR package with event-type SCAN_RSP, which gets queried via active scanning only and usually holds the device name if supported. TODO: Resolve propagating device found on SCAN_RSP message (name), since SCAN_IND is received before (w/o name). The 2nd SCAN_RSP is dropped, even though the BTDevice's name has changed properly.
* Add BTAdapter::[getV|v]isibleAddressAndType[()] and ↵Sven Gothel2021-07-282-1/+26
| | | | | | | | | | | | | | BTAdapter::get[Address->AddressAndType]() using BDAddressAndType, preparing for random address Thoroughly changes - 'EUI48 AdapterInfo::address' -> 'BDAddressAndType AdapterInfo::addressAndType' - BTAdapter C++ - BTAdapter and its DBTAdapter/DBusAdapter implementations (Java) Motivation: - The adapter's address as initially reported by the system is always its public address, i.e. BDAddressType::BDADDR_LE_PUBLIC - The adapter's visible BDAddressAndType might be set to BDAddressType::BDADDR_LE_RANDOM before scanning / discovery mode (TODO).
* SMPKeyBin: Make key base filename compatible to FAT32 Long filename (LFN)v2.2.6Sven Gothel2021-06-111-2/+20
| | | | | | | | Previous scheme : `bd_C0:26:DA:01:DA:B1:1.smpkey.bin' FAT32 LFN scheme: `bd_C0_26_DA_01_DA_B1_1-smpkey.bin' Tested interoperability with native and java test application.
* SMPKeyBin: Allow BTSecurityLevel::NONE case; Add more convenient ↵Sven Gothel2021-02-211-66/+257
| | | | | | | | | createAndWrite(..) and readAndApply(..) one-liner Further: - Bump to version 2 - Add creation timestamp (seconds since epoch) - Convenient createAndWrite(..) and readAndApply(..) one-liner handle overwrite and remove-invalid use-case
* BTUtils.java: Add 'long wallClockSeconds()'Sven Gothel2021-02-211-0/+6
|
* SMPKeyBin: Use fprintf_td(..) to have elapsedTime prependendSven Gothel2021-02-141-12/+12
|
* Completing BTDevice/AdapterStatusListener lifecycle handling: Fix leaked ↵Sven Gothel2021-02-144-4/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | AdapterStatusListener Completing BTDevice lifecycle handling comming 30b4e5f0c1f62c92c40a6ccceda8878f88a9521a "AdapterStatusListener::deviceFound: Resolve sharedDevices persistence of found device via return value" Fix leaked AdapterStatusListener: Turns out the introduced mechanism of not adding BTDevice's to sharedDevices list, but keeping them in discoveredDevices (to avoid duplicate scan results), did not consider removing its BTDevice bound AsapterStatusListener (here: DBTDevice.java). Example: - BTDevice found and instance C++/Java is created - Java's BTDevice creates and adds its AdapterStatusListener - All AdapterStatusListener::deviceFound(..) called - User is not interested, all 'AdapterStatusListener::deviceFound(..)' return 'false' - BTDevice remains in discoveredDevices, but not in sharedDevices. * Subsequent clearance of discoveredDevices leaks the AdapterStatusListener: Not removed * AdapterStatusListener::deviceUpdated(..) of the removed BTDevice eventually gets called, but the BTDevice is already deleted * The Java -> JNI call causes our exception: Null reference to native instance! Hence all BTDevice lifecycle bound AdapterStatusListener shall be marked as such, using a StatusListenerPair{AdapterStatusListener, weak_ptr<BTDevice>}. This way, every removed discoveredDevice's BTDevice will remove its associated AdapterStatusListener. Further, every explicitly BTDevice::remove() will remove its associated AdapterStatusListener. New 'BTDevice::addAdapterStatusListener(l)' (C++/Java) performs the required association. +++ On the Java side the discoveredDevices are now only using a WeakReference<BTDevice> to avoid leaking/holding BTDevice instances. +++ This added complexity of 'StatusListenerPair' only exists, b/c discoveredDevices holds complete BTDevice instances. We could have soothed this by just listing BDAddressAndType, but the current API required to query 'List<BTDevice> discoveredDevices' ... +++ BTDevice/BTAdapter: - Use lock-free 'jau::sc_atomic_critical sync(sync_data)' whenever possible, instead of mutex-lock, i.e. merely reading/copy data at an undeterministic point in time --- DBTDevice Misc - Added BTUtil.fprintf_td(..), prepending elapsedTime() - DBTDevice.java: sort method in proper groups: Unsupported, internal, ..
* SMPKeyBin: Add static remove(..) method, supporting deletion of key file.Sven Gothel2021-02-111-4/+22
|
* BTDevice::setPairingPasskeyNegative(): Added API doc and missing Java ↵Sven Gothel2021-02-111-0/+27
| | | | | | binding. Hint: Better use setPairingPasskey(passkey = 0) .. .. since current experience exposed a roughly 3s immediate disconnect handshake with certain devices and/or Kernel BlueZ code.
* SMPKeyBin (C++/Java): Add 'apply(BTDevice&)' method, setting Security params ↵Sven Gothel2021-02-091-0/+84
| | | | | | | | | | | | | | | | | | | | | | and uploading available LTKs Moving the SMPKeyBin setup and key-upload for the BTDevice to public SMPKeyBin, providing the proper setup and upload method. One change compared to removed coding in Scanner10 example occured: "BTSecurityLevel::ENC_ONLY is set to avoid a new SMP PairingMode negotiation, which is undesired as this instances' stored LTK shall be used for PairingMode::PRE_PAIRED." i.e.: 'device.setConnSecurity(BTSecurityLevel.ENC_ONLY, SMPIOCapability.NO_INPUT_NO_OUTPUT);' This has been evaluate with a Secure Connections capable LE device using BTSecurityLevel::ENC_AUTH_FIPS and SMPIOCapability::KEYBOARD_ONLY. After initial pairing using a dynamic generated passkey, we connected successfully and stored the LTKs and CSRKs with this connection parameter. Thereafter reconnect after setting (BTSecurityLevel.ENC_ONLY, SMPIOCapability.NO_INPUT_NO_OUTPUT) and uploading stored keys succeeded with Linux Kernel-BlueZ host implementation.
* BTDevice.java: Add isValid() query, i.e. device reference valid and device ↵Sven Gothel2021-02-091-0/+9
| | | | not removed
* Bump jaulib; Adapt to jau::bytesHexString(..) removed leading0X argument: ↵Sven Gothel2021-02-063-20/+16
| | | | | | | Unifying output. Having a leading `0x` always for MSB-First only, unifies the output and hence clarifies semantics of shown results. This is compatible with 'btmon' output.
* SMPKeyBin API doc: Refine, fix C++ enum-type.Sven Gothel2021-02-021-0/+2
| | | | | | | Note: "__pack(x)=x" still has issues, missing SMPLongTermKeyInfo and SMPSignatureResolvingKeyInfo, as well as EUI48. Funny, thought we had this fixed earlier..
* Fix BTDevice::setConnSecurityAuto(..) API doc (disabled by ..)Sven Gothel2021-02-021-1/+1
|
* Promote persistent SMP Key Storage to API: SMPKeyBinv2.2.3Sven Gothel2021-02-021-0/+393
| | | | | | | | | | SMPKeyBin stores device's BDAddressAndType, its security connection setup BTSecurityLevel + SMPIOCapability and optionally the initiator and responder LTK and CSRK within one file. Since the LTK and CSRK can be optionally set due to their availability per initiator and responder, implementation supports mixed mode for certain devices, e.g. LTK responder key only etc. This was the final motivation to promote the storage demo code to the API.
* BTDevice: Add automatic security negotiation of BTSecurityLevel and ↵Sven Gothel2021-02-011-0/+43
| | | | | | | | | | | SMPIOCapability pairing mode - 'setConnSecurityAuto(const SMPIOCapability iocap_auto)' See BTDevice::setConnSecurityAuto(..). Added to C++ and Java. SMPPDUMsg::Opcode::PAIRING_FAILED in hciSMPMsgCallback(..), will no more lead to L2CAP reopening w/o encryption, but device left in failed pairing state connected.
* BTDevice::setConnSecurity(..): Remove UNSET argument restrictions, allowing ↵Sven Gothel2021-02-011-4/+3
| | | | to reset values
* BTDevice.cpp disconnect() method is noexcept, since all invoked methods are ↵Sven Gothel2021-01-301-0/+1
| | | | noexcept; Earmark in BTDevice.java for direct_bt.
* API doc: Use '{@code tinyb.dbus}' to add implementation notesSven Gothel2021-01-302-38/+38
|
* BTDevice.cpp connect*() methods are all noexcept, since all invoked methods ↵Sven Gothel2021-01-301-0/+1
| | | | are noexcept; Earmark in BTDevice.java for direct_bt.
* API doc fix: 'direct_bt.tinyb' -> 'jau.direct_bt'Sven Gothel2021-01-292-5/+5
|
* BTAdapter.startDiscovery(boolean): Added implementation remark re ↵Sven Gothel2021-01-291-0/+5
| | | | removeDiscoveredDevices() for direct_bt
* BTManager.Settings Name FixSven Gothel2021-01-291-2/+2
| | | | | | BTManager.Settings: - rename: isCharacteristicValueCacheNotificationSupported() -> isCharValueCacheNotificationSupported() - property now: 'jau.direct_bt.characteristic.compat'
* Fix EUI48Sub::toString() if 0 == length: reserve() would become negative ↵Sven Gothel2021-01-291-6/+13
| | | | (C++); Add same path to Java StringBuilder capacity
* SMPLongTermKeyInfo (Java/C++): Add convenience isResolver() (from ltk prop) ↵Sven Gothel2021-01-282-2/+7
| | | | and use it, same for SMPSignatureResolvingKeyInfo.
* Example Scanner10 (C++/Java): Support Security setting per device ↵Sven Gothel2021-01-271-1/+1
| | | | | | BDAddressAndType; Tested reconnect reusing stored LTK Same code in C++ dbt_scanner10.cpp and DBTScanner10.java.
* API renaming of missed 'Characteristic', add listener to API name tableSven Gothel2021-01-276-23/+27
|
* Refine the API doc overview: Add Header and update linked names + add event ↵Sven Gothel2021-01-272-7/+26
| | | | driven adapter workflow
* Update README.md; Provide Java package API doc (Copied from C++) etc ..Sven Gothel2021-01-276-11/+112
|
* Have BTFactory.main(..) show version info and available adapter, also ↵Sven Gothel2021-01-272-50/+107
| | | | | | whether jaulib is used or not; BTFactory: Shorten names (API) direct_bt.jar: Don't use jaulib.jar in its Class-Path (manifest)
* DirectBTVersion: Use data transient onlySven Gothel2021-01-271-18/+18
|
* Adapt to jaulib changes: Jar naming convention (dash, not underscore for ↵Sven Gothel2021-01-261-0/+67
| | | | | | | extras) ..; direct-bt-fat* includes jaulib-fat (standalone) direct-bt-fat.jar is with Tinyb direct-bt-fat2.jar is ex Tinyb (merely testing size and encapsulation)
* Added EUI48Sub and EUI48::indexOf(const EUI48Sub& other) and contains(const ↵v2.2.0Sven Gothel2021-01-252-1/+148
| | | | EUI48Sub& other) (C++ and Java, both w/ unit tests)
* Complete build change: Using jaulib[_fat] if available (for Java) incl. ↵Sven Gothel2021-01-251-24/+70
| | | | native lib loading. Added junit test facility (Java).
* Java: New API Layout: Shorten named [Bluetooth -> BT], [Characteristic -> ↵Sven Gothel2021-01-2523-314/+314
| | | | Char] etc (align naming with direct_bt == java; reduce java code footprint and too long code lines)
* Java: New Layout: [tinyb2 -> direct_bt].jar ; org.[tinyb -> direct_bt] ..; ↵Sven Gothel2021-01-2537-38/+38
| | | | Upcoming API Cleanup (Drop TinyB only entries)
* Bump GetGitRevisionDescription.cmake to ↵Sven Gothel2021-01-2537-0/+0
| | | | 6a748896188fdf3f885820ccd686393ea5215dbf (from cmake-modules)
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-15 11:03:28 +0000