Home › Forums › Ask the Flomies › SDK Pro for Android?
Tagged: 16byte payload, android, SDK Pro, Tx Power
-
AuthorPosts
-
October 4, 2016 at 2:14 pm #56638
If I buy the SDK pro is it for Android too? I am using the Android SDK that came with my Flomio Plus currently.
October 4, 2016 at 3:02 pm #56641Hey Walt, we haven’t released the Pro SDK on Android yet since we still need to add a lot of the premium features we include on the iOS version. It’s also worth mentioning that we’re in the process of changing our licensing options to better fit what our customers need and what revenue we need to stay in business. More details on this thread.
Does your application specifically need to operate exclusively offline? or just for a predictable yet extended period of time? Are you intending to use the license on one device or scale your application to a presumably endless number of them? Is your application still in the experimentation stage or deployed and being used in the filed?
thanks for the feedback,
RichardOctober 4, 2016 at 3:20 pm #56645I would prefer offline but would be ok with for an extended period. Even the 1 month would be fine with me. How does it update? How will I know it has updated and good to go offline?
For right now it would be just one device. But down the road maybe a few.
Experimentation only right now.
I also would like to be able to set the power to full power even if it can’t be controlled by the app. Is there a way to do that while you work out the issues in the SDK? A firmware update or something? I would be happy to use beta code for now.
I thought I read that you can only send and receive 16 bytes but I just sent an ADPU code that was 19 bytes and received back a valid 46 byte response. Did I misunderstand or is that fixed.
October 4, 2016 at 4:28 pm #56648Hi Walt, the way our licensing system works is pretty simple, if you purchase an “@ 1month” license then we generate a token that lasts a month and download it to your SDK the moment you’re online next. The default token that ships with our Basic Flomio SDK requires you to get online every hour to download a new token. With the “@ 1month” token, this would naturally be a month. This approach allows customers to adjust their license subscription on the fly and only get charged when the readers are actually being used. For instance, if you went 3 months without using the SDK with your reader you would only have paid 1 month subscription rather than three since we only charge you when a new token is generated.
RE: Tx power settings. The FloBLE Plus does support several Tx power settings but the default is lowest power at -23dBm since the battery impact of high settings is substantial. We can expose this setting for you to raise the power level via an SDK configuration parameter. It’ll be a beta release and slated to be included in our v2.2 drop next month. We’ll post a link to the beta on this thread once we get it done. Will probably take until the end of the week.
RE: The 16 byte limitation is in reading data off of a tag on not exchanging data across the Bluetooth link. There are APDU commands and responses that are indeed longer than 16bytes but the data blocks read off (or written to) the target tag are limited to 16byte payloads per the device driver.
best,
RichardOctober 4, 2016 at 4:40 pm #56656Fairly new to android programming. How is the token is downloaded? I haven’t done anything yet and have been playing around for a few days. Is it when I rebuild the APK? Is it somehow automatic? I may be missing something simple…sorry if so.
Regarding the 16byte what I am saying is I just sent an ADPU Command and received back data that was 46 bytes and it was accurate data. It wasn’t truncated.
October 4, 2016 at 7:54 pm #56671The token download is handled completely behind the scenes and inside the SDK.
RE: 16byte. yes, I understood what you meant originally. What I was trying to explain is that APDUs can be longer than 16bytes. What is limited to 16bytes is data read or written to data blocks on the NFC tag.
October 5, 2016 at 11:04 am #56683Hi Walt,
Can you elaborate on the 19 bytes command APDU which received back a valid 46 byte response? This is likely an APDU that is only dealing with the reader and does not rely on reading data via NFC from a tag. For example, configuration settings of the reader can be changed and receive response APDUs greater than 16 bytes, but this will only be from the reader, not a tag.
Kind Regards,
ScottOctober 5, 2016 at 2:45 pm #56684I am reading contactless EMV cards. Selecting the standard 2pay.sys.ddf01 directory on the card like this
readerManager.sendAPDU(“00A404000e325041592e5359532e4444463031”)My response is 46 bytes of data which contains the AID from the card. I then select the AID with another ADPU command and it gives me back 72 bytes of data containing the PDOL of required data objects the card requires just fine.
I am using the following to receive the data and it definitely is the full length. Not limited to 16 bytes. And it is definitely information the card had to provide.
if (callback.equals(ReaderManager.didFindBlocks)) {
EMVResponseString = message.get(“message”).toString();Hope this helps.
October 5, 2016 at 5:23 pm #56685Good observation, contactless EMV cards are NFC Forum Type 4 cards and indeed don’t have the 16 byte read/write data block limitation like the more popular Type 2 tags that our customers normally ask us about. Sorry for the confusion and thanks for clarifying.
Still working to get you the updated SDK with Tx Power settings… stay tuned.
October 10, 2016 at 3:35 pm #56734Any luck on the power settings yet?
October 11, 2016 at 4:44 pm #56745Hello Walt,
We are working on a completely new SDK for Android, we are now testing and debugging and will release as soon as possible, be sure that we are actively working on this so we can give everyone a better version of our SDK in the least possible time.
October 11, 2016 at 5:15 pm #56746Can you give me an idea of the time frame? I am working on a project and have to have a timeline. Thanks.
The current SDK is working for me except for the power setting.
October 12, 2016 at 1:54 pm #56754Hello Walt,
I expect to have a beta version between this and the next week. I’ll keep you posted.
October 20, 2016 at 10:39 am #56990Hate to keep bugging but anything I can use? Even pre beta? Thanks.
October 25, 2016 at 1:54 pm #57052Just checking again. Would it speed up getting the sdk for android if I paid for instant support?
October 25, 2016 at 2:08 pm #57053Hey Walt, yes that would help to bring on more resources. Recently we’ve had some internal restructuring and are bringing on a junior Android developer to continue the effort of augmenting the Pro SDK for your needs. The learning curve is steep so extra cash will allow for our senior developers to help him along rather than focusing on our bottom line.
sorry for the delay. we will keep you posted here.
RichardOctober 25, 2016 at 2:17 pm #57055Ok Done.
Like I mentioned though I have everything working accept the power setting so I don’t really need a new sdk just the power setting exposed or the method call to do it.
-
AuthorPosts
You must be logged in to reply to this topic.