summaryrefslogtreecommitdiffstats
path: root/java
Commit message (Collapse)AuthorAgeFilesLines
* DBTAdapter::reset(): Utilize HCI host implementation specific reset ↵Sven Gothel2020-10-131-0/+5
| | | | | | | procedure incl bring-up back into POWERED functional state Notable: DBTAdapter::poweredOff() shall not close the HCI connection, as the unique host HCI channel will survive.
* AdapterStatusListener[1] and DBTAdapter[2] API Refinement: [1] non const ↵Sven Gothel2020-10-139-76/+117
| | | | | | | | | | | | | | DBTAdapter, [2] use HCIStatusCode for start/stopDiscovery and well as [2] return boolean for set[Discoverable|Bondable|Powered](..). AdapterStatusListener needs to pass non-const DBTAdapter to allow actionable modification of adapter state, e.g. start/stopDiscovery. HCIStatusCode is desired for start/stopDiscovery, allowing user to read actual HCI status code on failure. boolean return value for set[Discoverable|Bondable|Powered](..) reflecting general success or failure on these basic commands.
* DBTAdapter::reset(): Promote HCIHandler::reset() to adapter incl Java bindingSven Gothel2020-10-094-0/+32
| | | | | | | Ability to reset and power-on and off (the latter was already supported) might help recovering congested or otherwise stuck adapter. This is experimental work and has to be tested more thoroughly.
* dbt_debug: Have DBG_PRINT and WORDY_PRINT as macros, suppressing argument ↵Sven Gothel2020-10-081-6/+1
| | | | | | | | | evaluation if condition is false Following commit 581260d3f4144df3716eac736c9e8792be264edb Also reverting COND_PRINT to drop __func__, __FILE__ and __LINE__ as not intended for this verbose ourput instrument (like DBG_PRINT etc).
* JNI BluetoothUtils::decodeUTF8String(): Limit scope of JNICriticalArray, not ↵Sven Gothel2020-09-301-6/+8
| | | | entering another JNI call - hence removes jni-check warnings.
* JNI helper_base.hpp: java_exception_check_and_throw(..) after adding object ↵Sven Gothel2020-09-301-0/+3
| | | | to array
* JNI helper_base.cxx: Fix ArrayList class name, drop decorating 'L' and ';'Sven Gothel2020-09-301-1/+1
|
* Direct-BT JNI: DeleteLocalRef when no more needed, avoiding the 32 max ↵Sven Gothel2020-09-305-21/+40
| | | | local-ref count and ease resources on stack-frame
* DBT[Adapter|Device].close(): Utilize own AtomicBoolean synchronization ↵Sven Gothel2020-09-303-4/+21
| | | | avoiding reentry; DBTAdapter.removeStatusListener(): Avoid @ within isClosing (warning on failure)
* Make clang++ 9.0 happy (no warnings)Sven Gothel2020-09-281-2/+2
|
* DBTAdapter::removeDevice(): Use scoped_lock(device.mtx_connect, ↵Sven Gothel2020-09-272-22/+5
| | | | | | | | | | | | | mtx_sharedDevices) removing connect/disconnect sideffects; Only disconnected if not connected. DBTAdapter::removeDevice() called from DBTDevice::removeDevice() exclusively to benefit from atomic operation of potential disconnect and removal of references. Use scoped_lock(device.mtx_connect, mtx_sharedDevices) removing connect/disconnect sideffects, otherwise a DBTDevice disconnect/connect could interfere. Only disconnected if not connected. Even though disconnect is re-entrant safe, have this intend be well defined here.
* [DBT|DBus]Manager.LazySingletonHolder: make static final, properly showing ↵Sven Gothel2020-09-262-2/+2
| | | | unique singleton initialization intend
* DBTAdapter::startDiscoveryBackground() check isEnabled(); ↵Sven Gothel2020-09-261-4/+2
| | | | | | | | | | | | | | | | | DBTAdapter.stopDiscovery() shall always call DBTAdapter::stopDiscovery() DBTAdapter::startDiscoveryBackground() check isEnabled() same as startDiscovery(), adapter needs to be powered on. Added note in stopDiscovery(), as we don't check isEnabled. Here we shall pass through to have at least the discovery state updated and listeners notified. +++ DBTAdapter.stopDiscovery() shall always call DBTAdapter::stopDiscovery(), same as DBTAdapter.startDiscovery(). Just in case 'isDiscovery' state differs from native implementation, it shall be corrected here. (Robustness)
* DBTAdapter.adapterSettingsChanged(): Handle 'initialSetting' (0 == oldmask): ↵Sven Gothel2020-09-261-35/+40
| | | | | | Set all related states, skip all actions. Also added notion of 'initialSetting' to dbt_scanner10 and DBTScanner10.
* AdapterSettings.java: Add isEmpty() to check for an initial settings on ↵Sven Gothel2020-09-261-5/+3
| | | | adapterSettingsChanged() callback; toString shall at least return "[]"
* DBTAdapter.cxx [add|remove]StatusListener(): add-case needs setInstance ↵Sven Gothel2020-09-262-6/+10
| | | | before adding to receive the initial setting event; Use more readable getInstanceUnchecked() and clearInstance()
* BluetoothFactory: Use new BluetoothManager get-method name (oops)v2.1.29Sven Gothel2020-09-251-1/+1
|
* Java Example: Rename ScannerTinyB10 -> DBTScanner10: Requiring Direct-BT, ↵Sven Gothel2020-09-251-1/+1
| | | | name aligned with dbt_scanner10.cpp
* BluetoothAdapter.getManager() added; BluetoothManager.Settings added; ↵Sven Gothel2020-09-2511-42/+138
| | | | | | | | | | | | D*Manager.getManager() use 'Magic Statics' now - Magic Statics usage to avoid synchronization for singletons, like C++11 - BluetoothManager.Settings provide the Direct-BT related settings of isCharacteristicValueCacheNotificationSupported(), moved from the BluetoothFactory. - Having implementation agnostic access to the Manager from Adapter is helpful for user applications, as this notion was lost during the interface abstraction (refactoring split for having multiple implementations).
* GATTNumbers: Concluding review: API doc, better naming, have optional data ↵Sven Gothel2020-09-241-1/+1
| | | | and erroneous missing data handle nicely (no crash)
* DBTDevice JNI: Tolerate an already destructed native instance on ↵Sven Gothel2020-09-241-3/+15
| | | | | | | | | 'remove*CharacteristicListener()' methods 'remove*CharacteristicListener()' methods might be called from Java @ shutdown or takedown. User application would need to test whether the instance is still valid, to avoid such safety sugar coating - simply bail out in such cases instead of throwing an exception.
* DBTAdapter.java: poweredOff(): Don't clear discoveredDevices (!references); ↵Sven Gothel2020-09-231-1/+0
| | | | Have !POWERED come past settings notification
* Merge Secure Pairing API changele_secure_connectionsSven Gothel2020-09-233-14/+15
|\
| * BluetoothDevice.get[Supported|Required]PairingModes(): Return ↵Sven Gothel2020-09-223-14/+15
| | | | | | | | | | | | | | List<PairingMode> instead of plain array for direct usability As user needs to test certain features using contains(PairingMode::XYZ), returning a list is more straightforward. C++ also returns a vector.
* | Conclude POWERED state change across C++/Java; Newly added ↵Sven Gothel2020-09-232-1/+17
|/ | | | | | | | | | | | | | | | | | | | | | | | | AdapterStatusListener shall receive adapterSettingsChanged(..) for initial AdapterSettings Conclude POWERED state change across C++/Java - DBTAdapter.java must be notified to have isDiscovering and discoveredDevices cleared on !POWERED. It will additionally react to !POWERED state change, by clearing the mentioned states for robustness. - DBTAdapter.cpp's stopDiscovery() shall send MgmtEvtDiscovering (-> AdapterStatusListener.discoveryChanged(..)) itself in case of le_enable_scan != SUCCESS, otherwise - DBTAdapter.cpp's poweredOff(): -- Shall not clearAllMgmtEventCallbacks() on HCI before stopDiscovery() and disconnectAllDevices(), otherwise stopDiscovery events won't be received and forwarded to AdapterStatusListener. hci->close() will deal with it afterwards. It is up to the user (application) to react to POWERED (power on) state change, i.e. restart discovery! +++ Newly added AdapterStatusListener shall receive adapterSettingsChanged(..) for initial AdapterSettings. This is required to have e.g. the DBTAdapter.java instance be aware of its initial state, e.g. isPowered etc.
* Fix Java_direct_1bt_tinyb_DBTGattDescriptor_toStringImpl(..): Wrong arg ↵v2.1.27Sven Gothel2020-09-221-4/+4
| | | | list, oops. Added call to C++/Java example for validation
* LE Secure Connections: Initial API to support secure pairing with varying ↵Sven Gothel2020-09-225-21/+274
| | | | | | | | | | | PairingModes (C++, Java) For now, DBTDevice has a NOP implementation, i.e. returning zero length vectors (or arrays in Java) for supported and required PairingMode. The pair(String passkey) simply returns HCIStatusCode::INTERNAL_FAILURE; Intention is to validate the new API entry with our application.
* Handle abort() via dbt_debug's new ABORT(..), ensure a message is being send ↵Sven Gothel2020-09-201-2/+1
| | | | and process aborted; Use it.
* C++ DBTManager / Java BluetoothFactory: Default operation is BTMode::LE (Was ↵Sven Gothel2020-09-201-3/+3
| | | | | | | | | | DUAL in Java) All global BTMode defaults to LE (only) - C++ DBTManager: Add MgmtEnv::DEFAULT_BTMODE, env-var 'direct_bt.mgmt.btmode' first, then try 'org.tinyb.btmode'. - DBTEnv:getProperty(name): Add COND_PRINT(debug,..) for no default value root method as well.
* POctets::malloc: throw new exception type OutOfMemoryError early on malloc ↵Sven Gothel2020-09-192-1/+8
| | | | | | | | | | | failure, also throw IllegalArgumentException on size <= 0 - Add exception type 'direct_bt::OutOfMemoryError' and wire it in helper_base for C++/JNI interoperability. - std::malloc may not return nullptr on zero size, but a valid dummy pointer usable by free. Hence check for malloc(0) and throw IllegalArgumentException - also throw OutOfMemoryError on nullptr == malloc(size)
* C++/JNI: helper_base.hpp/cxx: Rework raise_java_exception(..) and ↵Sven Gothel2020-09-192-119/+131
| | | | | | | | | | | | | | | | | | | rethrow_and_raise_java_exception[->_impl](..) .. Commit 5cfe7e13c4dbf07360d928e421050de5e00684a1 intention was noble, however, 'inline' is not guaranteed and doesn't work here. I.e. the desired inline reduction with automatic elision and using __FILE__ and __LINE__ macros is not supported. Instead, move the functions back to helper_base.cxx and add paramter for __FILE__ and __LINE__ to be passed by the only caller macro 'rethrow_and_raise_java_exception(E)'. The latter simply explodes to 'rethrow_and_raise_java_exception_impl((E), __FILE__, __LINE__)', which serves the purposed of having exposed the file and line position where the exceotion got caught. Also support api/tinyb/BluetoothException, rendering commit 3139f93409cac61ba5b80caf506375d94eff8778 valid, i.e. use rethrow_and_raise_java_exception(..) in the tinyb C++/JNI code instead of exploded exception case blocks.
* C++ tinyb/general: Use rethrow_and_raise_java_exception(..) instead of ↵Sven Gothel2020-09-197-1336/+268
| | | | exploded exception case blocks
* helper_base.hpp: Have all raise_java_exception(..) and ↵Sven Gothel2020-09-192-111/+126
| | | | | | | rethrow_and_raise_java_exception(..) inline, benefitting from __FILE__ and __LINE__ Also have all raise_java_exception(..) call print_exception(..) upfront unconditionally, to not miss any exception in case a thread has died or the Java caller suppresses the output.
* DBTDevice: Resolve disconnect/remove resource race condition @ rapid connect ↵v2.1.22Sven Gothel2020-09-182-11/+35
| | | | | | | | | | | | | | | | | | | | | | w/ one thread per device Testing w/ 2 devices in fastest rapid reconnect (using automatic disconnect) on Raspberry-Pi: (1) Native run-dbt_scanner10.sh -silent_gatt -mac C0:26:DA:01:DA:B1 -mac C0:26:DF:01:E5:CA -disconnect -count 12 (2) Java run-java-scanner10.sh -silent_gatt -mac C0:26:DA:01:DA:B1 -mac C0:26:DF:01:E5:CA -disconnect -count 12 The Java (2) test case disclosed a race condition as follows: "An application using one thread per device and rapid connect, should either use disconnect() or remove(), but never issue remove() after disconnect(). Doing so would eventually delete the device being already in use by another thread due to discovery post disconnect!" The example code was issuing (1) disconnect and waiting for being diconnected and only then (2) removing the device. In between the device got discovered already and a new processing thread has started while the closing previous processing thread is removing the device and hence the underlying DBTDevice. A user shall either use disconnect() or remove(), period.
* Correct API doc for DBTDevice::remove() (C++ and Java):Sven Gothel2020-09-161-4/+6
| | | | | | Fix order of explicitly removing shared reference: connected-devices, discovered-devices and shared-devices. Fix disconnect also removes its ref from discovered-devices, besides connected-devices, but not shared-devices.
* CMake: Support full parallel build by adding target dependenciesSven Gothel2020-09-152-0/+4
| | | | | | | | | | | | | | | | C++ Libs -> none (2x) Java Jar -> none Java JNI Libs -> C++ Lib + Java Jar (2x) C++ Examples -> C++ Libs Java Examples -> Java Jar Test -> C++ Lib +++ scripts/[re]build.sh uses `getconf _NPROCESSORS_ONLN` for the make -j <number of parallel processes>.
* Only generate JNI headers when Java sources have been modified, i.e. when ↵Sven Gothel2020-09-151-9/+21
| | | | | | | | | | | | | Jar file is being build. JNI header generation is satisfied by 'add_jar(.. GENERATE_NATIVE_HEADERS <target> DESTINATION <dir>)', note that its GENERATE_NATIVE_HEADERS target is a dummy target, since jni/direct_bt defines target javadirect_bt. Weakness of not directly checking build dependency of javadirect_bt against generated headers exists, however, it is unrealistic to assume that the transient generated JNI header will be edited manually within the process. Therefor we can use the dummy target javadirect_bt_javah and JNI header generation will only occur when java sources have been modified, i.e. the jar file being actually build.
* C++ noexcept: DBTManager, DBTAdapter and DBTDevice (concluding for now)Sven Gothel2020-09-151-1/+1
| | | | | | | | | | | | | | | | | | RELEASE Builds w/ -O3: dist-amd64/lib/libdirect_bt.so.2.1.20 pre-opt: 2,131,720 post-opt: 74,424 bytes reduced: 3.5% 2,057,296 commit (this commit) Besides footprint and natural performance benefits, mostly quality regarding conscious managing of exception handling benefitted this last 'noexcept' changeset. Notable here *Octets and ATTPDU types range checking has been moved into the ctor to allow member access w/o range checks and hence avoiding potential exceptions.
* C++ noexcept: JavaUplink, DBTObject, JavaGlobalObjSven Gothel2020-09-151-11/+11
|
* C++ noexcept: JNIMem* (convert exception in dtor to abort)Sven Gothel2020-09-152-17/+19
|
* CMake Build: Use C++17 (C++20 not yet supported on all target platforms, ↵Sven Gothel2020-09-121-1/+2
| | | | | | | | | i.e. Debian 10 Buster with GCC 8.3) GCC 10.1 mostly covers C++20 and is default on Debian 11 Bullseye, we will move there when established. For now let's use C++17 at least, especially since GCC C++ ABI fixes a few code generation issues and we intend to further simplify our C++ codebase.
* Fixing Example crossreference and Menu itemSven Gothel2020-09-031-0/+26
| | | | The \example tag referring to the example code file must be added to the actual API (header) files.
* Complete mapping of BTMode (C++, Java) and have Adapter recognize actual ↵Sven Gothel2020-09-034-8/+107
| | | | | | BTMode from AdapterInfo's AdapterSettings Java property is 'org.tinyb.btmode' (not yet mapped to C++)
* DBTDevice::pingGATT(): Disconnect and return false if: GATT not connected or ↵Sven Gothel2020-08-281-2/+5
| | | | | | | | | no GATTServices available This required getGATTServices() (C++) or getServices() (Java) to be completed, hence added remark in API doc. Reasoning is that pingGATT shall not initiated resource creation, but assumes all set set up well. If failing, it shall cause a disconnected.
* DBTManager, HCIHandler, GATTHandler: Defer fetching timeout+ config from ↵Sven Gothel2020-08-281-1/+1
| | | | | | | environment until instance creation using singleton holder Otherwise static initialization at library load will occur and hence not allow the Java BluetoothFactory to pass the properties to the environment before.
* BluetoothFactory, DBTEnv: Only pass '[org.]tinyb.*' and 'direct_bt.*' ↵Sven Gothel2020-08-271-5/+7
| | | | | | properties to native environment, remove the 'jvm.' prefix! Make it more simple.
* BluetoothGattCharacteristic: API Change: 'writeValue(byte[] value)' -> ↵Sven Gothel2020-08-266-15/+75
| | | | | | | | | | | | | | | | | | | 'writeValue(byte[] value, boolean withResponse)' Add both writeValue(..) mapping to Java [1] BT Core Spec v5.2: Vol 3, Part G GATT: 4.9.1 Write Characteristic Value Without Response [2] BT Core Spec v5.2: Vol 3, Part G GATT: 4.9.3 Write Characteristic Value Previously only [1] existed and [2] seemingly isn't supported by DBus yet(?) Adding the additional paramter 'boolean withResponse' to determine which variant is desired, while removing the original method type. The TinyB/DBus implementation will throw a BluetoothException if 'withResponse' == true, as it is not supported. This change allows clarification of the actual method being desired and supports a fail fast if not supported.
* PlatformToolkit: EABI_AARCH64 maps to 'arm64' not 'aarch64' for our common ↵Sven Gothel2020-08-261-1/+1
| | | | os_arch
* PlatformToolkit: Properly map 'os.arch' -> CPUType (reduction) -> 'os_arch' ↵Sven Gothel2020-08-261-5/+250
| | | | | | | | | | | | | | | | | | | | | | | | (our common name) As it turned out that OpenJDK uses 'arm' for 'os.arch' on an armhf machine, we are required to perform some mapping, i.e. reduction of 'os.arch' and map. Hence the reuse of CPUFamily, CPUType (reduction) and ABIType which eventually map to our common name. This is also required as we already have chosen our common name, based on the 'archabi' name used on the platform. Too bad OpenJDK couldn't use same name here, so they use 'armhf' for the native installation folder but 'arm' for 'os.arch'. However, introducing this 'reduce map' will easy further support. Tested on OS Linux - i386 - amd64 - armhf - aarch64 (not yet, but names are known)
* PlatformToolkit: White space fixSven Gothel2020-08-261-277/+275
|
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-05 03:15:25 +0000