I'm currently working on my diploma work. Part of the work includes development of JavaCard applet for regular SIM cards. First option is to use JavaCard2.X API and use APDU commands to communicate with the applet. This might be very tricky as I need to develop client-app for android (which will be communicate with this applet) and that is so far possible only trough special - not so user friendly - API called Seek-for-android. (if I'm wrong, please correct me)
However, I also came across JavaCard3 Connected Edition, which provides much more options - for example web applets. Using webapps, deployed on SIM card and accessing them through browser in mobile device would be very convenient (of course developing such applet would be much easier as well). Problem is, that I can't find any mentions of Javacard3 being used in real life, or even on real SIM cards. I can't even find any mentions of possible date of release of such cards. Actually, there is almost no information on this topic.
So, my question is - do you know anything useful about this platform? Anything about real-life usage? Which card supports Javacard3? Are there any developers smart-cards, which are "JC3 enabled"? Will there be SIM cards with this platform in the future?
Thanks a lot for answers!!!
At JavaOne 2012 Moscow representatives of the JavaCard Oracle team demonstrated a prototype device with support for Java 3 Connected Edition based on Portable Security Token ES.
It's 2018 when I am writing this and I think this question needs a new answer.
Java Card 3 Connected Edition is dead in the water. It requires a large amount of RAM, which is still expensive even in the latest editions of the chips. SRAM takes large amounts of memory, and high end chips often still contain 8-10KiB of RAM max.
Furthermore, it was generated with the idea that web-developers would easily connect with it. This doesn't seem to have happened and it is questionable if a security device should be programmed by web-devs at all.
The additional overhead of the TLS protocol adds a heavy overhead without apparent benefit. The TLS protocol also requires a weird connection with the browser / end user. The idea that you can enter a PIN or password on a chip generated web page certainly has failed.
The idea of adding hardware support for browsers in general has failed. Before there were Java applets running in the browser, and the browser largely depended on add-ons. This has all gone away and it is very unlikely to return.
So even if RAM (or FRAM, MRAM, XCross or whatever hybrid memory solution will exist) ever comes cheap on a secure smart card processor, it is unlikely that JC 3 Connected will again see the light of day. Meanwhile Java Card Classic is still going strong although it is far from sexy at the moment - the OTN forum on Java Card is as good as dead (although OTN and sexy themselves are so far apart that they might as well exist on different poles, I certainly prefer SO).
There is no card in the field with JavaCard 3 right now. Everything under development.
But I recommend you to have a look to JSR 177. If Android supports it you can communicate with your applet by normal APDU commands.
Related
So I'd like to use Wifi-Aware for a program outside the Android universe (let's assume Linux/OSX/Windows) and cannot find any info on this at all.
At first I thought it would suffice to use a Wifi-Aware certified product
running one of these OSes and then implement the Wifi-Specs, but when I tried to download the specifications, I was asked to login first (but with no option of creating an account).
Do I understand correctly that you have to be a paying member of the Wifi-Alliance to even get the specifications?
Furthermore, is my assumption that, with the specification, I would be able to implement a Wifi-Aware/NAN application on say, Windows/Linux correct? Or is the specification something that is meant for OS developers and an application would rely on support from OS (like Android provides) to support this? (This would then mean that it is in fact impossible to implement Wifi-Aware applications on Windows/Linux, since the OSes do not seem to support it)
Edit: There is a question on this, but it seems to have been asked from a user, not a programmer perspective, and is not going into much detail, so I do not consider this one to be a duplicate.
You need support for WiFi Aware at the hardware and the OS levels.
The wifi.org website mentions the following "certified Wi-Fi Aware devices":
Broadcom BCM4361 11ac STA Reference Design
Intel® Dual Band Wireless-AC 8265
Marvell 802.11ac Wave2 Wi-Fi Test Bed Evaluation Kit
Qualcomm® mobile Wi-Fi AC2 chipset
I guess that Intel card might be your best bet? Although the iwlwifi driver page mentions that:
While we advertise support for Wi-Fi Location* and Wi-Fi Aware* on
8260, we can't commmit on accurate results for those features. NAN
isn't considered stable yet and may or may not work depending on the
firmware version.
As for OS support, as far as I know that is currently limited to Android.
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.
what do you think about using android in an industrial embedded environment?
I'm thinking, for example, about a vending machine with a touch screen monitor. I can think about many advantages:
It would increase the ease of making an advanced user interface
Android provides tuned libraries to handle task like low power internet connection or encrypted connections
Thanks to dalvik VM, it is easier to run on different HW platform (Arm9 - Arm11 - ....)
but there are also some cons like:
Android is not thought for a mission critical environment (like a device handling money)... at least not to some extent.
If not kept up to date, the software may have some bugs that compromise safety. Issue is worsen by widespread adoption.
Someone might regard Android as resource hungry compared to a real time implementation of linux, with code written in C rather than java.
On the internet you can find some resource on the subject, but most is out of date:
http://www.hsc.com/Portals/0/Uploads/Articles/Android-Porting-on-Embedded-Platform_v2_0633850602027036930.pdf
http://www.androidforembedded.com/whitepaper/android-for-embedded.pdf
anyone has direct experience on the matter or can link me to some resource? What do you think about it guys?
Cheers,
I know of a Swiss company - Noser Engineering AG, which provides development of Android Software for embedded devices. Also check-out their showcase android to market
Android can definitely be used in a non-cell phone device. There will be pros and cons that you can find all around the web, which could be discussed during weeks.
On our side, we have been playing with Android for a while now (from the port of the OS on custom ARM board to app dev) and we see real interest from customers. Regarding reliability, as in any embedded device, it is important to validate it by yourself against the use cases that your system will have to deal with.
Eventually, if cons make you decide not to move to Android, you can have other ways to develop interesting HMI such as QT which runs efficiently great HMIs.
Anyway, you can check out our website (http://www.adeneo-embedded.com) and contact us if you need some help.
Touch screens in anything industrial is pretty much out of the question, believe me. You'd just get laughed at and wouldn't be able to sell it. Luckily, a vending machine isn't an industrial application and there a touch screen would be more suitable.
If you just want a touch screen with some GUI pre-made, there are probably 1000 companies already making such products, no need to re-invent the wheel. It would need to be > IPx5 classed too, if you want to put it outdoors in the rain and snow.
The main challenge for this kind of application is the money transactions, not the user interface. You should start there. What good money transaction software is there already available on the market, and what hardware is most suitable for it? To handle the transactions will be the real software problem for this application. Anyone can make some GUI touch screen fluff and have it toggle some relays or drive a stepper motor.
Also, I reckon the market for this application will mainly need 1) reliability 2) reliability and 3) reliability. The design, user-friendliness, visual appeal and fluffiness may let you sell one machine to a customer, but reliability will make you sell several.
Does anyone know of a cheap Android or programmable device that has wifi?
I need it for a project for a company that needs a Wi-Fi handheld device for the shop floor.
I'm not too fussed about the language the device uses though I'm not really interested in the iTouch as there's no intention to release the app in the app store and I don`t really want to jail break everybody's iTouch.
Ideally it would be small, iTouch size for example and relatively cheap $100 or less. Nothing fancy, just ability to write a simple UI and have Wi-Fi. Voice is not needed.
Not too fussed about touch or qwerty keyboard either.
How cheap is cheap? On the weekend I searched eBay for "android slate" and found a bunch at US $99. I bought one immediately. It may not have the world's fastest CPU or a heap o' RAM, but at that price, how can I complain?
Like you, I want to develop apps for use in an industrial situation. I'll list voice as a feature if I use handphones, but don't really need it.
Would you please publish your final purchase decision here and I will likewise if I find a "better" option.
Bear in mind that it's not all about the cheapness of the device and consider the development effort.
Android has at least 2 good things going for it.
1) Generally programmed in Java (although you can use C & C++ if you jump through a few hoops). I may be wrong but it seems that new grads these days only know java (no offence intended to anyone reading this) and even "old hands" with C++ can quickly pick it up.
2) Android was designed from the start for developers and has an excellent development environment and good tools.
I bought a bunch of Android books and really liked Unlocking Android: A Developer's Guide, but you might want to check Amazon for readers 5 star votes.
And I have just noticed Android Wireless Application Development which I will have to buy; I think that you might benefit from it too.
Oh, and if you want to outsource any development at competitive rates ... ;-)
There were some cheap Android devices at http://dealextreme.com
I'm wondering if is possible to install/use Android with other phones? Will be nice to have it on such a piece of hardware like the new SH004.
Mobile phones are generally very hardware independent of each other and require a serious amount of hacking in order to do any sort of "moding".
I can barely find any information on the SH004, but I think it will have to be out for a few months before you will even start to hear people of moding it, yet alone installing another Operating system.
Your best bet is to find specialised forums such as CellPhoneHacks, (There are better around, but not sure if I should link to).
Android is actually designed to be portable, and to provide source code for most of the generic pieces. However, the possibility of running it on a consumer device intended for a different operating system/framework depends on three things:
1) The hardware must have sufficient capability - likely meaning it was originally designed to have comparable capabilities under whatever OS it shipped with.
2) Sufficient low-level documentation must be published or reverse engineered to adapt a Linux kernel, flash memory driver, user I/O drivers (touchscreen, etc), and anything communication related (wifi, mobile, etc) and optionally any extras (accelerometer, gps, etc)
3) It must be possible, either by design or by finding an exploit, to run arbitrary code on the device - ie, boot an image which has not been signed by an approved party such as the OEM.