November 21, 2013 By: Will Verduzco
One of the most highly anticipated user-facing features in Android 4.4 KitKat is NFC Host Card Emulation. What makes this important is that up until very recently, only devices with NFC Secure Element hardware could access the tap-to-pay functionality in Google Wallet. Host Card Emulation lifts this requirement by emulating the ISO/IEC 7816-based smart cards that use the contactless ISO/IEC 14443-4 (ISO-DEP) protocol for transmission. This allows any device running Android 4.4 KitKat (with a US SIM card) to use Google Wallet’s tap-to-pay feature.
Now, we’re seeing the first fruits of KitKat’s software additions. Previously seen only on the Nexus 5, the new Google Wallet allows any KitKat user with NFC hardware (and a US SIM card) to use tap-to-pay functionality, regardless of whether or not the device has an NFC Secure Element.
Head to the Play Store listing to get in on the latest update. The update is rolling out gradually, but those who are overeager can get in on the action by visiting the via link below.
Not too long ago, we saw a wave of substantial application updates for some of Google’s first party Android apps such as Maps, Search, Keep, YouTube, Hangouts, and more. Since then, we’ve also seen major updates to Chrome for Android, as well as some of Mountain View’s lesser known (but still awesome) offerings like MyTracks.
One app that hasn’t received much attention recently, however, was Google Wallet. This can partially be attributed to the fact that not many devices support Google Wallet’s tap-to-pay functionality. In fact, according to Google, only 29 devices to date have featured the NFC secure element required to be compatible with Google Wallet’s tap-to-pay functionality. And prior to today’s update, this meant that the app was essentially without purpose on unsupported devices without the requisite hardware.
Today, Google added functionality to the Wallet app, allowing users to easily send money to friends in a manner similar to what was recently added to Gmail. In many ways, this can be viewed as Google’s ever strengthening assault on PayPal. Google also added loyalty card functionality, bringing it inline with Apple’s Passbook functionality. Of course, the core tap-to-pay functionality is still present for supported devices. However, this new app opens up various features to almost any device running Gingerbread or later, regardless of its NFC hardware status.
Are you eager to get your hands on the new Wallet app? Head over to the Google Play Store listing to download a copy to your device. Read the announcement post on the Google Commerce Blog to learn more.
March 18, 2012 By: Conan Troutman
It’s undeniable that Android is blessed with a huge selection of high quality applications. “Fart Machines” and “Love Calculators” aside, there is a multitude of incredibly well developed apps out there. Developing is not easy, and the people that do this spend a huge amount of time pouring their heart and soul into these applications and understandably they often wish to charge a fee for their hard work.
While some developers view their work as a hobby or secondary income, it is how many of them make their living. They depend on the income from their hard work to pay the bills and put food on the table. This is one of the main reasons that we have a strict zero tolerance policy towards warez here on XDA Developers. Unfortunately, over the course of the last week, a large number of European developers have been left somewhat in the lurch as far as this income is concerned. You may or may not have already heard about the recent “technical issue” which resulted in many developers not receiving the money they were entitled to from the sale of their apps. Just in case you missed it however, here’s a quick rundown of the situation.
On the 7th of March a developer posted in the Google Checkout forums stating stating that, ”For some reason my Google Checkout March payment which has been showed as paid out on the 2nd March has not arrived in my bank account? It normally arrives in my bank account on the 7th of each month.” The developer then inquired as to whether this had affected others as well. As it happened, there were. Pretty soon afterwards, numerous developers from various countries including the UK, France, Spain, Portugal, The Netherlands, Germany, Sweden, Norway, Ireland, Austria and, just to mix things up a little, Brazil, were reporting the same issue. They were also unhappy at the non-existent level of support from Google. The first reported official contact came on the 13th oF March in the form of an Email from the Google Wallet team. “Hello xxxxxx, Thanks for reaching out to us. To ensure a faster resolution, I’ve forwarded your message to a team that’s better able to address your concerns. We’ll respond with additional information as soon as possible. In the meantime, feel free to contact us again if you have further questions. We appreciate your patience. If you have additional questions, please visit our Help Centre at http://www.google.com/support/wallet/.”
Very helpful I’m sure you’ll agree. The discontent among developers continued to grow, with many openly considering removing their applications from Google Play in favour of 3rd party dispensaries such as the Amazon App store. This was followed by a post in the original comment thread from an official Google representative stating that “We’re aware of reports from some European developers that they have yet to receive their March 2012 payout for February sales. We’re actively investigating this and are working to resolve it as soon as possible. We apologize for this inconvenience. At this time, no action is needed on your part.” Bear in mind that this is six days after the issue was initially raised. On the 15th of March the issue was acknowledged on the developer console and coupled with a broken “Learn More” link. And finally, a day later, the news that everyone had been waiting for, “We have worked to resolve this, and payouts were initiated on 15 March 2012. However, your bank may take up to three additional business days to register the payout in your account. We apologize for any inconvenience you may have experienced and appreciate your understanding.” Not long after reports began appearing that the money developers were waiting for had been credited to their accounts. Better late than never, I guess.
Now, if you’ll allow me to play Devil’s advocate for a moment, it was pointed out that the Checkout FAQ does state, “In the event of a technical issue, your payment may be delayed and is expected to be initiated on the 15th of the month.” This line however appears to be specific only to certain countries, and was not relevant to all of those suffering the delay in payment. Call me overly suspicious, but that seems a lot like a pre-emptive addition to the fine print when these “technical issues” became a distinct possibility. There was also a post on the Google Forums which claimed the Checkout Merchant Centre Team were going through a “major transition” and that a new three person team were preparing to “take ownership of the codebase” and address these issues. This post however was made from a standard user account, and cannot therefore be confirmed as legitimate.
Although it seems now that the issue is resolved and all those left without payment have now been paid in full, I suspect that the drama will continue to haunt Google for some time. Affected developers are obviously very unhappy with the financial disruption. And many seemed to be just as, if not more, annoyed at the fact that they were completely unable to consult Google directly about the issue. It’s unacceptable that a company on the scale of Google does not have the capability to engage the development community when something like this happens. I appreciate that it may well be infeasible for them to operate a permanently staffed Checkout customer service operation, but this total lack of communication has been a slap in the face to the many hard working developers who depend on these payments. Let’s not forget that 30% of the purchase price of an application never makes its way to the developers, and that is a sizeable chunk by anybody’s standards.
During the lengthy waiting periods for any kind of official feedback, the conversation among developers at one point turned towards payments from Google’s AdMob service, which were seemingly also held up. As if that wasn’t bad enough, there are reports of a sharp decrease in Ad revenue, despite no drop in traffic. One opinion was that this is due to the type of ads that are placed in applications, and how they are assigned by Google. Recent changes to the way this has been done could have a detrimental effect on developers revenue. It’s important at this point to state that there is not conclusive evidence to back this up, but if it were to be the case, it’s a move that would anger a lot of developers, which certainly warrants a little more digging.
With regard to the original issue, one of the commentators raised the point of whether or not Google would compensate those affected by adding interest to the payments. I would imagine though that this is something that was immediately thought of by whichever finely tuned legal mind drew up the smallprint. However, it seems that those affected will have to make do with the incredibly brief and generic apology posted on the checkout forums. It would, in my opinion, be a very grave mistake for Google to assume that the development community will forget this anytime soon, whether or not they choose to completely remove their work from Google Play in favour of other outlets or simply choose to utilize both, it’s going to reduce the number of those 30% cuts they receive. And let’s not forget that when all is said and done, they are still a business and there isn’t a single business out there that can afford to annoy its customers, staff, or suppliers. Which one of those three categories the development community falls into is hard to say—probably all three, which makes this whole affair even more of a problem for Google.
If you are a developer and were in any way affected by either the late payments or have noticed a sharp and unexplainable decline in ad revenue from your applications, please contact us to air your opinions on the matter. Remember, XDA-Developers has always and will always do whatever it can to aid and advance the development community.
Google Wallet is all over the headlines lately, first with its release on the Verizon network with the Galaxy Nexus and then with its release on the AT&T network with the Samsung Galaxy S II. Sprint and T-Mobile users have even been able to sideload the Google Wallet app on their respective variants of the Nexus S.
The app itself relies on the devices NFC chip to communicate with non-contact payment stations, like Mastercard’s PayPass. Google Wallet stores your credit card information allowing you to make in-store purchases with a swipe of your phone. Since the information on the chip can be accessed without direct contact several security measures were put in place to protect users. A four digit PIN is required to make purchases with the app, adding an additional layer of security. XDA Member and zvelo employee miasma discovered a flaw in the PIN system, allowing retrieval of credit card information. viaForensics, a company specializing in proactive forensic security (software hacking with the goal of reporting flaws and protecting users), also helped to demonstrate the exploit, proving that the process could be repeated on other devices.
Multiple problem areas were identified but the biggest was in the encryption of the PIN. Using SHA256 hex encoding, the PIN is secured in the app data. Knowing the PIN is 4 digits, viaForensics’ calculations show a brute-force would take, at-most, calculating 10,000 SHA256 hashes. This takes little effort and both miasma and Google have been able to compromise the PIN security in private tests.
Rooted users take note; the security flaw can only be exploited on phones with root privileges. Google has acknowledged the flaw and they are working on a fix. In order to preform this attack a hacker would have to have physical access to your phone, so until a fix is published users can assure their safety by keeping their device within reach. As always, for the security of your phone, stay up to date with the latest software. Don’t forget to keep your phone secure with a lockscreen pattern, PIN or password (or face unlock if your device supports it).
To see the exploit in action, check out the video here. The original thread announcing the vulnerabilities can be found here. Google is working with the banks and card companies involved to make Google Wallet more secure and to patch this security flaw, so hopefully we’ll see some updates soon. Until then, keep those NFC enabled phones within reach at all times!
February 3, 2012 By: Ian Stacy
If you have a phone with an NFC chip and aren’t using Google Wallet, now’s your chance. Check out this thread for reports of working NFC payment locations.