ACR35 reader with Android Cordova application

[StuartParticipant]

I am currently developing an NFC based attendance system and investigating the possibility of using an ACR35 reader. An Apache Cordova mobile application and Python web server backend is being developed, but it is unclear how I would go about integrating Cordova with the reader. I understand that to use the Flomio SDK I would need to purchase an “upgrade” for the reader so that it uses your firmware, but it seems like your Cordova plugin currently only supports iOS systems, which are not currently available to me. I have little idea how I would start to write my own interface between Cordova and the Android library that ACS provides.

Do you have any suggestions for how to proceed?

[RichardKeymaster]

Hi Stuart, the Flomio Cordova Plugin is currently in development for iOS. The Android version will follow after that. Writing Cordova Plugins isn’t too complicated, the challenge is getting the driver API settled across the many devices we support. The best place to learn how to create a Cordova plugin is here. You can reference the ACR35 driver documentation to see what features you want to access through the plugin and expose them.

[StuartParticipant]

Hi Richard,

I’ve since created a basic Cordova plugin that reads UIDs using the ACR35 drivers. However, it’s not completely stable and I’ve been having difficulties coding basic functionality like querying whether the reader is plugged in and active. Considering that power management best practices may also be lacking, it seems like using your (beta) Android SDK would be sensible. My project supervisor has emailed you about getting access to the SDK but you only replied with instructions relevant to iOS. What is the process for modifying keys on the device so that it can be used with the Android SDK demo?

Stuart

[RichardKeymaster]

Hey Stuart, I’m glad to hear you got something basic working. We struggled for a while on iOS to get the connect/disconnect management working along with the tag polling loop. Then getting good coverage of all the tag diversity and low level protocols is an evolving effort. Unfortunately, we still haven’t gotten a chance to work much on the Android side of things. I wrote this code for the FloJack v1 a couple years ago so you could look at the repo to dig up some ideas. It’s not the easiest code to read so if you’d like you can fork it, add you Cordova code in, and send us a pull request. I’ll take a look at it and see what I can do to add more stability to it.

thanks,
Richard

[StuartParticipant]

Hi Richard,

Thank you for offering to take a look at the code, that would be great! However, it’s not really clear to me whether the FloJack example code requires the reader to have been “upgraded” from the standard ACR35. After installing the app on my Nexus 7, it seems unable to interface with the reader.

Thanks,
Stuart

[RichardKeymaster]

That code was written for the FloJack v1 which is a different hardware architecture than the ACR35 or FloJack v2. That said, the underlying mechanics are the same and that was what I was referring to in my last post. You just have to look through the code and make sense of is in order to pull out what’s useful. That’s where I can help.

[StuartParticipant]

Hi Richard,

I’ve resolved some of the issues I was encountering on Android. However, there is one major unresolved issue left: the ACR35 reader only intermittently “starts up” correctly. This means that sometimes the reader will poll for a card using the read UID APDU command but it will receive no response even though a card is actually there. Other times, it will work without any problems. Interestingly, the issue is always resolved by resetting the reader from within the “AudioJackDemo” application, then restarting my Cordova application.

The code I’m using to start the reader is as follows:

AudioManager mAudioManager = (AudioManager) this.cordova.getActivity().getApplicationContext()
                    .getSystemService(Context.AUDIO_SERVICE);
AudioJackReader mReader = new AudioJackReader(mAudioManager);
mReader.setOnPiccResponseApduAvailableListener(...)
mReader.setOnResetCompleteListener(..)
mReader.start();
mReader.reset();

...
/* Polling code (inside while loop) */

// Power on the PICC
mReader.piccPowerOn(timeout, cardType);
// Transmit the APDU
mReader.piccTransmit(timeout, apdu);

I’m confident that the issue lies within this section of the code since everything works exactly as expected if the reader is instead reset through the “AudioJackDemo” application provided by ACS.

Thanks,
Stuart

[RichardKeymaster]

Hey Stuart, great progress! I’m happy you’re sticking with it. The tough part about working with the AudioJack is that you need to be conscious of threading. This is because the modulator/demodulator is very sensitive to latency. On the flipside, the UI thread can’t be blocked because your app (webview rendering layer) may become unresponsive. From looking at your code (and being somewhat unfamiliar with the Android Cordova make up), it seems that you’re instantiating the the AudioJackReader from the same thread that’s running the Cordova bridge. In this case, you could be encountering issues because of delays in servicing the didSendPiccAtr() and didSendPiccResponseApdu() callbacks. You’re going to want to roll a separate thread for the polling code.. something like this:

private class PollingThread extends Thread {
    public boolean mStop; //to detect when to stop thread
    public void run() {
       // reset reader when necessary (plug/unplug event)
       while (true) {
           synchronized (this) {
              if (mStop) {
                 return;
              }
           }
           // Power on the PICC
           mReader.piccPowerOn(timeout, cardType);

           //handle message assembly 
              //synchronized (mRequestPool)
       }
    }
}

The FloJack/ACR35 hardware can be temperamental so be patient as it will take some tweaking to get right. For our iOS SDK have all sorts of flags, semaphores, and edge cases covered for when the app goes foreground/background, device is plugged/unplugged, and scan tone is played/not-played. Let me know how it goes, I’m glad to provide ideas/input to keep you moving forward.

cheers,
Richard

[StuartParticipant]

Hi Richard,

Thanks for your help. I’ve now created a GitHub project with example code for both Android and iOS using the ACR35 SDK. It’s a Cordova project with a companion plugin that wraps UID reading functionality from the ACR35 SDK into two simple JavaScript functions. It’s there to help developers who want to get up and running quickly with the SDK, and also saves them the hassle of having to write a Cordova plugin from scratch.

Going forward, it could be expanded to incorporate more functionality from the SDK. However, I no longer have access to an ACR35 reader so I’ll need to order another one for testing.

If you have any suggestions I would greatly appreciate them – this is my first project that I’ve published online and so I may not have adhered to every convention. The main purpose, however, is to make things a bit easier for others by providing extensive example code (with documentation).

The project can be found here: https://github.com/stuart-xyz/acr35

Thanks,
Stuart

[Author]

Posts