[Nexus 5 Q&A, Help & Troubleshooting] Entropy512:
So, in the name of "security", you've made the system less secure? In the original Wallet tap-and-pay architecture, there was an app-specific PIN. I've never heard of this architecture actually getting compromised, and during the era from the time Wallet with HCE was released until now, we lived in a Golden Age where people weren't directly attacking the Wallet APK to bypass arbitrary restrictions like the device whitelist. See http://www.modaco.com/forums/topic/354635-xmod-region-device-root-patched-google-wallet/ and http://xdaforums.com/xposed/modules/mod-disable-network-device-checks-t2126241 (yes, I created the second one of these) for examples where, until Wallet had it arbitrary artificial limitations removed, it was subject to direct attack of the APK in order to remove its limitations. While to my knowledge, the Modaco APK was probably safe and my Xposed module was easy to review, the existence/need of such APKs desensitized users to the usual "modified APKs are bad, I shouldn't use them" mantra, leaving a perfect opportunity for someone to deploy an APK that had additional malicious alterations.

Your new "more secure" method was already compromised as of launch - http://arstechnica.com/security/201...ives-attackers-full-access-to-locked-devices/ Let's not forget the plethora of CTS-verified builds Pay will happily run on that contain the Stagefright vulnerability (Note that the Stagefright vulnerability is a perfect example of your logic in http://xdaforums.com/showpost.php?p=63024715&postcount=226 being flawed - since a malicious Stagefright exploit payload comes in via MMS and thus Play Store's protections are completely irrelevant. So with a Stagefright-based attack payload - there's no race against the clock because carriers and OEMs are slow, there's no need to get past Play Store's Bouncer, and the target audience is anyone you know the phone number for, and the number of vulnerable devices is going to be well above 0.5% for a LONG time.), the old KitKat futex memory corruption aka towelroot vulnerability, etc. Anyone who is stuck with a device that the OEM isn't updating (I know Google is attempting to solve this, but let's be realistic - if you honestly thing Google is going to get OEMs and carriers to stop being insanely sluggish, I have three words for you - Android Update Alliance.)

Now, with Android Pay, we've returned to those Dark Ages of the Wallet device whitelist, and it's just a matter of time before the SafetyNet system or the Pay APK comes under direct attack for the purposes of removing these artificial limitations - which will, just like in the previous Dark Age, be a perfect opportunity for someone to deploy a maliciously altered APK.

As to constructive criticism - The old approach WORKED and it was demonstrably more secure in the real world (no known compromises even on known rooted phones vs. already compromised at launch via a lockscreen bypass bug) than this one. Please bring back the old app-specific PIN approach - if it isn't broken, don't fix it. It wasn't broken, and in "fixing" it, you completely and totally broke it. Another benefit of the app-specific PIN was that it allowed users to put in their payment PIN prior to tapping their device to the reader - now, in numerous use cases (but not all), users need to have a lockscreen code AND sometimes (but not always) they have to type in a PIN when they tap their device to the reader - the remove/type/re-tap workflow here often results in a confused reader and a failed payment. (In the time since Pay launched, I have had a grand total of ONE successful payment due to "SoftCard" branded payment terminals causing a PIN input request and not allowing the re-tap after PIN input. Wallet, on the other hand, was 100% reliable on my Sony Xperia Z3.)