I'm a C/C++ programmer with good windows and linux development experience and I also know a bit of java too. Recently, a client asked me to develop an Android app for him, wich, will most likely run on a Samsung Galaxy S or Galaxy S II, with Android 2.3, that basicaly consists in connecting a standard smartcard reader on the USB port of the device and using it to access the smartcard.
I have programmed smartcards before, but I have no experience with android. So my questions are:
Is it possible to do what I need in this hardware and O.S.?
Will I have to write my own driver to interface with the USB?
Going into more detail, I need to at least be able to execute APDU commands with the cards.
Something like the PC/SC standard. Are there any solutions in this subject already implemented?
Any ideas of where to begin?
Thanks in advance.
Short answer: not really.
Long answer: you might need to use custom firmware (Android build) to do this. Here's a project that does this, although their focus is on using embedded chips not external readers. They have a PC/SC implementation for Android.
Android has USB host support since 3.1, not sure if that is sufficient to implement a reader driver, so you can talk to your card: http://developer.android.com/guide/topics/usb/host.html
Even if you do though, you will need to somehow bridge it to your PC/SC stack.
Please open source it if you implement it :)
Did you test to connect a external smartcard reader to connect to a android device. What where results?
Greetings,
Wouter
Related
I want to connect my Xbee module to my android phone and communicate with it by sending AT commands.
I do know of the USB host facility provided by Android phones, but I do not know how to send data to it.
I have the java-Xbee API and I am able to talk to the Xbee using my computer but since my project involves using the Android OS, any help on this topic will be appreciated.
According to this Google Code Page, the java-Xbee API requires Java >= 5 and RXTX. Considering those two requirements:-
RXTX on android is not an out of the box lib and may require some hacking which may or may not work.
I'm not a Java VM expert, but i know desktop OS JVMs work differently from Dalvik.How well would Dalvik run code developed for JVM? Here is a nice StackOverflow topic discussing the two.
Faced with the above challanges, are you brave enough to boldly go where no man has gone before?
Could you also consider the following well documented and supported approaches:-
Ytai Ben-Tsvi & Sparkfun's IOIO-OTG
Saves you the headache writing android 3.1+ USB host code and thus allows you to use cheaper phones that run droids 1.5 to 2.3 (without hacking the latter).
Digi's WiFi to Xbee
Allows you to link your android phone (or any other programmable wifi enabled computer) to your device over the internet.
Well, I believe this should be able to be implemented on the Android.
Recently, I found some Android developers created the Android remote controller(KB/MOUSE) app by
installing an app onto the server side(could be Windows or Mac or Linux) system and interact each other by bluetooth.
However, I believe it shouldnt be necessary to install an app onto host side if
we can take advantage of standard Bluetooth HID profile.
I have implemented the Android Bluetooth HID application which can make your android device play as a bluetooth kb/mouse input device.
to control my Ubuntu without installing any host side daemon.
The engineering approach involves Bluez deeply so it doesnt work on Mac or Windows.
Please bear my lack of bluetooth knowledge. I am really curious about the possibility of this matter.
If any of you has any approach or idea about this, please kindly share.
Thank you.
well, it seems this question is not yet implemented by the developer.
However, if any of you is interested in how to do this for Linux system. Feel free to write me an email. I would be happy to share the skill.
I´ve been reading a lot about NFC, card emulation and etc.... I found two very helpful posts about this issue:
Android and Symbian NFC mobile development questions and answers (FAQ)
http://forum.xda-developers.com/showthread.php?t=1281946
Reading them I realized that it is quite complicated to write an application to make a payment.
Since I just want to see "something" working I'd like to ask the more experienced people if using the patch provided at xda-developers forum (second link above) would be enough just to write an appication that would open some door ou register/authorize someone´s entrance at an event (provided that I have a NFC device to properly interact with my phone, of course).
Thank you all
Payment is mostly impossible since you don't have the keys for the JavaCard card manager, better forget about it. Additionally, to write a Visa, etc compatible payment applet, you
need access to their specs, which means signing NDAs, paying money, etc.
Apparently the Mifare chip has stock keys, so you can modify it. So if you have a reader, and a device (door, etc.) that uses Mifare cards, you might be able to get it work. The thread also mentions that you might be able to clone your transport card. But:
you need to build your own firmware and flash it on a rooted phone
you may need to port the patches to whatever is the current GB version (2.3.7) or use exactly the same (old) tag
You need to do a lot more reading :)
In my opinion, you shouldn't bother with trying the patches on XDA Developers, especially if you are considering using Android 4.0 ICS. Android 4.0 already has built-in functionality on the Nexus S and Galaxy Nexus phones to enable card emulation. Drawback: you need a rooted phone to make it all work (see e.g. How to obtain NFCEE_ADMIN permission on rooted phone? for an example of someone succeeding).
A perhaps simpler approach is using NFC peer-to-peer communication ("Android Beam") with an external reader. This can work with any Android NFC device using a simple app to push the necessary data to the reader. Provided the reader support peer-to-peer communication, this is far the easiest solution. It would require some development work on the reader side, though, see http://code.google.com/p/ismb-npp-java/wiki/NppFromPhoneToACR122 for an example of this approach.
I am writing an Android 2.1 application that needs to get data from a USB device. The USB device is an embedded system i created. The embedded system has no OS. Also, the android device does not send any data to the embedded system.
How should i go about this, I'm guessing i will need to make a high-level driver to communicate from USB to the application. But, i have never made a Linux driver before.
If creating a high-level driver is the best way to do this, can someone give me some references so i have somewhere to start.
If there are other ways to accomplish this i would also like to hear about it
-Thanks
The Android Open Accessory Development Kit is where you should start looking. Like many of other Google's documents, the tutorial is reasonably complete and should provide you with a good starting point
Good Luck!
I think you will need to recompile Android kernel to add usb device support.
It can be an option if you are working on some dedicated project and only one Android phone should be supported. If you want to support all kinds of Android phones, I can suggest to implement USB host in your embedded system( if it is possible), thus your Android phone can be connected using ADB protocol.
I'm relatively new to android development, but not to programming. I'd like to be able to use an Android Tablet with a mag-stripe reader, either via bluetooth or USB interface. Is Android capable of reading the serial input from the gun? If so, can anyone point me to the libraries I would need to write classes for this input?
Thanks in advance
Square uses an audio jack mag-stripe reader. You could use a similar device like this: http://www.idtechproducts.com/products/mobile-readers/112.html
I think the easiest way to build your skimming gear would be to use a standard serial usb dongle/chip (such as one from ftdi) that already has a serial driver for linux. There are a lot of good magnet card readers that talk RS-232, and programming against a serial device is a piece of cake compared to writing a usb-driver without documentation.