ANT Forum

Attention ANT and ANT+ Android Developers:

Today we are happy to announce the release of a new version of both the ANT and ANT+ Android SDKs. There are many bug fixes and many improvements and new features such as the ability to search for multiple ANT+ devices simultaneously, support for Fitness Equipment Controls - including trainer and stationary bike devices, improvements to the Heart Rate profile, private network key support, and better airplane mode handling. For full change logs see below. This thread can be used to ask any questions or give any feedback on these versions.

New Versions:
Today (2014-06-24) we are releasing:
-ANT SDK v.C.B1 RC1
-ANT+ SDK v.P.B1 RC1
-ANT+ SDK v.P.B1.MO RC1(members-only release with trainer support)

These are API final versions and are ready for development. They are labelled RC 'release candidate' as part of our new release strategy to release development versions before the public Play Store release to allow developers a chance to test their apps with the new versions first. In one week we will remove the release candidate flag and push the apks to the Play Store.

Distribution:
As before, the SDKs are available on our website at http://www.thisisant.com/developer/resources/downloads/.

Beginning with this release we will now also host the SDKs on GitHub at https://github.com/ant-wireless/ANT-Android-SDKs. We encourage everyone to sign up as a watcher on that repo so you will be notified whenever SDK changes are made.

This release also marks the first members-only version, which is only available to ANT+ Members in the thisisant.com 'Member Early Release' section. The members-only version includes support for the Fitness Equipment Controls - including trainer and stationary bike devices. To use it download the members-only zip and reference the PluginLib 'MO' version contained therein in your apps.

In one week we will remove the release candidate flag and push the apks to the Play Store where they can also be downloaded.

Changelogs:
Instead of making a massive post here, the full changelogs are easily viewable on GitHub:
ANT+ SDK: https://github.com/ant-wireless/ANT-Android-SDKs/tree/master/ANT Android SDK
ANT SDK: https://github.com/ant-wireless/ANT-Android-SDKs/tree/master/ANT+ Android SDK

Note on Future Announcements:
Major updates will always be posted in the forums here, but moving forward any minor updates to the SDKs will only be posted in the last major forum post and updating the packages. So, if you want to monitor all updates, subscribe to this forum post or add yourself as a watcher on the GitHub project.      

The ANT SDK changelog (forum doesn't support links with spaces) shows ANT USB Service version 4.5.0 (RC7, RC4), but the SDK only contains version 1.3.0.      

There is no .apk for the new version of the ANT+ Plugin Sampler      

The Heart Rate Grapher in the SDK is version 2.1.0, but the Play Store version is 2.2.0.      

Arrgh, you are awesome, thanks for your feedback.
-USB Service Version was wrong in changelog notes, fixed to be 1.3.0
-Plugin Sampler APK was missing, fixed
-Heart Rate Grapher version is outdated, not fixed yet, we will have a new version ready before the end of the week
     

Yes the new service is compatible with all old versions of the pluginLib, as well as the new plugin lib being backwards compatible with all old versions of the service (The only thing being new features added may not be available in old service versions).

It's worth using the new pluginLib in your app, even if you don't need the new features because there are a number of useful bug fixes and the better approach to cleaning up devices. However, there is no requirement to do so from the perspective of compatibility with the new releases.      

Is the new ANT+ API deliberately incompatible with the previous one? I would like to request having the removed methods added back in, but marked @Deprecated. Switching the API is a bigger task than I would like to take on right now, but I would appreciate having the ability to build with the new library so I can see if the regular logcat error messages are removed.      

@bkool Those methods are in the members-only version available in the members-only section on the website. They are now accessed by calling getBikeMethods() or getTrainerMethods(). We pushed them into the sub-class so people weren't trying to use them on illegible device types and it was easier to find applicable methods for a given device type. I thought the last beta we had given you had this change already, so sorry this was a surprise for you, we should have given you a heads up.      

@arrgh Yes we have made several small deliberate changes. If you investigate changing a name or two should be all that is required to bring your application up to date.      

With the new ANT+ Plugins Service I am not seeing a search timeout in response to a request access. When I activate the sensor later it is not found. Also, when the device state changes to SEARCHING, it will only reconnect if the device is found within a few seconds.
Everything works when going back to the previous service version.

Edit: This is on a Sony Ericsson Ray. A search timeout does occur on a Nexus device with a USB stick connected.

Edit2: MultiDeviceSearch is impacted by the lack of search timeout bug, and it is preserved across apps.
Let the ANT+ Sampler do a multi device search. After 10 seconds switch to my app, nothing is ever found in multi device search. If really quick switching when start search I have managed to get my app to find one of 4 devices.      

What phone are you using?      

RSSI reporting during search has been added (yahoo!), but which device the value is for is identified by a new resultId. We have been just fine using a combination of DeviceType and antDeviceNumber to identify a device, as I believe this is the standard approach. Can you provide the already reported device object, or at least these 2 values, with RSSI so we can use our own/existing matching implementation? Or is this added so that two devices with the same DeviceType and antDeviceNumber give a different resultId?

Why do I need to care about RSSI in MultiDeviceSearch? What if I don't want to provide an RSSI event receiver?      

From multi device search javadoc:
"throws IllegalArgumentException If any of the parameters are null"
This is currently done for forward compatibility reasons. If you don't use RSSI updates, pass a blank function.

For the id, the multiDeviceSearch is designed to be forward compatible with several possibilities of conflicting device numbers and types so you should always use the resultId. If you need to associate the info then just keep a hashtable of the result objects.      

Yes, that entry in the Javadoc is why I was asking.

Is resultID added so that two devices with the same DeviceType and antDeviceNumber give a different resultId?

It is ok for non-Android implementations to get by without resultID. The fact that I have needed to add another HashMap to implement RSSI is why I am questioning this. I am really liking being able to just save the provided "device", but this is only available for MultiDeviceSearch. We already have to keep a list of the device details reported from onDeviceFound (existing from before MultiDeviceSearch), so why should we have to keep another? My request is for there to be a common way to identify all sensors, no matter if we are saving one returned from request access or those returned from an async scan or multi device search.      

I have seen these LogCat messages on a Sony Ericsson Ray. Sorry I can't give much information on what was going on as I just took a copy when something unexpected showed up, but thought any information is better than nothing:

1)
API does not understand its own return codes an outputs a warning in LogCat:
W/AntPluginPcc(14891): BBD30000: RequestAccess: Unrecognized return code: -10!!!
Which is: ANT+ scan stopped. Reason=ADAPTER_NOT_DETECTED


2)
07-04 21:07:29.030: E/AntChannelExecutor(25644): BBC30000: Executor Dying: AntChannel fired OnChannelDeath()
07-04 21:07:29.090: E/AntChannelExecutor(25644): BBC30000: Executor Dying: RemoteException occured executing DoWork() in task: Scan Search Controller
07-04 21:07:30.290: D/dalvikvm(25598): GC_CONCURRENT freed 558K, 8% free 9514K/10247K, paused 2ms+4ms
07-04 21:07:30.420: D/dalvikvm(25644): GC_CONCURRENT freed 336K, 7% free 9098K/9735K, paused 2ms+3ms
07-04 21:07:31.030: E/Adapter 1 - AdapterStateMachine(25662): Error - Bad reset response during disable: [03][40][00][4B][00]
07-04 21:07:31.050: D/AntHal(282): failed to read from client=204
07-04 21:07:31.050: I/bluedroid(282): Stopping hciattach deamon
07-04 21:07:31.090: E/ANTSocketManagerThread(25662): rxThread: Socket connection closed unnexpectedly. Attempting reconnection (after 6 second pause).
07-04 21:07:31.120: D/dalvikvm(25662): GC_EXPLICIT freed 313K, 6% free 8976K/9543K, paused 2ms+5ms
07-04 21:07:31.300: I/bluedroid(282): Stopping hciattach deamon
07-04 21:07:31.310: D/AntHal(282): client 204 closed
07-04 21:07:31.310: D/AntHal(282): waiting for new client


3)
07-04 21:07:34.320: E/AsyncScanController(25598): BBD30000: requestAccess failed
07-04 21:07:34.320: W/AntPlusSensorScan(25598): [1] ANT+ Bike Cadence Sensor scan stopped. Reason=OTHER_FAILURE
07-04 21:07:34.350: E/AntPluginService(25644): BBC30000: UnexpectedError, acquireChannel_helper called with null ArsComm
07-04 21:07:34.350: E/CombinedBikeSpdCadService(25644): BBC30000: Could not acquire resultSent semaphore on failed channel acquire
07-04 21:07:34.350: E/AsyncScanController(25598): BBD30000: requestAccess failed
07-04 21:07:34.350: E/AsyncScanController(25598): BBD30000: Unexpected Event: ScanFailure on already null object, code: -4