yashsingh1/xdaforums huggingface dataset:
[SuperSU] elreydenj:
This report of a server side block is false. Something else that you guys have done is affecting your AP. I am on DP5 with EX Kernel and systemless root and all is working just fine. Paid at quick check with Android Pay 10 minutes ago.
[SuperSU] Pig Vomit:
This is the same way it happened before......sporadic early reports, then the full rollout. You'll see. And I totally understand why they do it. I was surprised they didn't do it sooner. I must have root so I can mirror my phone to my Pioneer head unit (ARUnchained), and that trumps my need for Android Pay.

It would be ironic if I am able to use Chase Pay while rooted. There are other options out there.....just haven't explored them.
[SuperSU] shoey63:
Is /su folder permission set to 0751? Or did it revert to 0755 on latest supersu update?
[SuperSU] Pig Vomit:
I hadn't considered that. Just checked, yes, reverted to 755. Now set to 751. su/bin was still 751, though. I will check later. Fingers crossed.

****EDIT****

Had to review past posts to refresh my memory. I don't think /su folder permissions at 755 was ever a problem. it was only /su/bin that needed to be at 751, and that was still the same for me when AP failed. And, no, I do not have xbin_bind folder.

One more thing......I have definitely used AP since updating SuperSU binary, so I don't think that's at play here.

And, for what it's worth.....just tried Capital One Wallet, which supports NFC payments. It specifically said it would not work on my device because it is rooted. None of my other cards currently have their own NFC apps.
[SuperSU] rebretz000:
I tried using the old 2.74 supersu zip and no go. Google patched something so that sucks.
[SuperSU] DROITURK182:
Okay so I went into SuperSU app and disabled it, rebooted phone, Safety net check passed and Android Pay works. Now to enable SuperSU all you have to do is open app, select cancel to update binaries, go into settings of SuperSU and enable it and reboot phone, you have root again. No more flashing the zip after disabling SuperSU like before, that's the only way I can still use Android Pay and have root now.
[SuperSU] bobby janow:
That did not work for me. Only full unroot did. DP5 n5x
[SuperSU] antroid88:
Is it possible that different terminals use different verification? I use rooted Nexus 5X with stock ROM, no kernels. I updated to Z build with full image using FlashFire on 7/14. 7/15, 7/16 and 7/17 I successfully used AP in Google play, BJs and Wholefoods. And yesterday AP failed and asked me to unroot phone in Petco. But I didn't change anything in the system since 7/14. And AP was updated on 7/11. I noticed that all stores have different types of terminals.

BTW, I checked my phone with Safetynet and it fails. Tried to reboot it, reflashed SuperSU to 2.76 - no luck, Safetynet fails. I'll try DROITURK182 method. Update soon.
[SuperSU] Citizen_Snips:
AFAIK, no. It doesn't matter what terminal you use. SafetyNet sees that the device is "comprised" and blocks the transaction. I'm 99% sure if you go back to BJ's / Wholefoods it will fail now.

I tried doing what was mentioned above about disabling systemless root and rebooting (yes, systemless Xposed as well) and it still came back failed. There's similar reports all over XDA right now. It was the same thing before systemless came out. First there were a few reports of failed SN here and there, then a full rollout. Stopped working for everyone. Seems to be the same thing again. We can only wait and see where it leads. I quoted part of Chainfires reply on the issue a few posts back. in the systemless Xposed thread. Basically he said that if any device rooted with SuperSU passes SafetyNet, it's a bug on their end and not a feature of SuperSU. Also that he wasn't going to get into messing with payment systems.So I guess it's up in the air and we just have to wait for now.. Unless someone stumbles on a fix. Hopefully someone does, I love AP but I can't live without root or Xposed. :(

Edit; wrong thread
[SuperSU] Alxoom33:
Can confirim that AP not allowing me to update credit cards, Nexus 6 running N DP5 rooted with SU 2.76 and EX kernel.

Haven't tried to use the current credit cards on AP at a terminal, but I suspect.......

---------- Post added at 09:53 AM ---------- Previous post was at 09:45 AM ----------

Just for fun, I changed permissions on SU folder to 751, SU still works, on reeboot AP still doesn't allow me to add a credit card.

AP didn't work at McDonald's. So we are SOL if we want to keep root.
[SuperSU] antroid88:
So I assume, root verification is done not on the phone, but somewhere on a server side.

Anyways, root advantages are the way bigger than AP. I'll probably just ask Amex to replace my card with touchless one. Pay with a touch of a wallet is also a cool feature ;)
[SuperSU] Alxoom33:
It's done on the phone. That's why AP worked with Systemless Root until 7.0 N DP5.
[SuperSU] antroid88:
Hm, but in my case I run 6.0.1 on Nexus 5x. AP worked even after latest build update. It just suddenly stopped working for me.
[SuperSU] bobby janow:
I don't believe that to be correct. When dp4 first came out AP didn't work even unrooted. Google fixed it server side and then it started working again. It worked on DP5 as well up until around yesterday. With no changes to your device, not even an AP update, it started to fail. The phone checks with Google servers and if it passes checks then AP will work. If their servers are modified to detect root, yes even systemless now, the checks will fail as will AP. I changed nothing this morning except full system unroot. AP started working again and server side checks passed.

Until someone figures out what they are checking to make it fail we are stuck, yet once again.
[SuperSU] Alxoom33:
OK, if that's the case, why can't you add a credit card to your AP account. Try it, it will say the same thing. "Android Pay can't be used

Google is unable...." Do yu think that is on the Google serve side, as well...maybe you are right?
[SuperSU] dwreck420:
i can confirm this as well, they are checking something else now lol nexus 5x, fully stock, systemless root.

was able to use AP till yesterday
[SuperSU] Alxoom33:
Perhaps [MENTION=631273]Chainfire[/MENTION] may know what Google is doing and if there is a work-around.
[SuperSU] bobby janow:
I do believe it's server side, yes. The CTS profile is server side and if that fails not only can't you add a credit card but you can't use AP either. The CTS profile needed to be updated by Google in order for stock dp4 to work. Took them a few days but once they did it AP worked with no changes at all to the device.

---------- Post added at 04:43 PM ---------- Previous post was at 04:42 PM ----------

He has stated that root is not subject to passing Safetynet checks and he does not care nor will he modify anything to make it pass.
[SuperSU] sgloki77:
can confirm, AP stopped working on my Nexus 6 running dp5 with EX 4.06 kernel

after uninstalling supersu 2.76 AP started working again , tour is over boyos
[SuperSU] poulopoulosa:
Yep, I can confirm too. I used android pay fine just yesterday, until today morning when I tried to buy a coffee (cts: fail). I rebooted my phone and after boot it was rebuilding dalvik cache for just one app (Optimising app 1 out of 1). I know people argue that its a serverside patch but did anyone else had their phone updating rebuild dalvik for one app?

Also, Uninstalled Root to get it to work. Damn Google, takes the fun out of everything.
[SuperSU] antroid88:
Folks, think about it. Banks are reliable for our money. If someone steals from our debit cards, bank should compensate it. But they don't want to compensate lose from theirs pockets. So if someone steals money and AP will be related to this crime, banks will ask Google to provide information regardless the case. If they find out that related phone was rooted, they'll ask Google to compensate lose. What Google will do? Well, they can make root tougher or start investigation against Chainfire, just because his soft could be potentially related to crime.
[SuperSU] DROITURK182:
Well it was fun while it lasted, going back to using xposed missed it so much[emoji53]
[SuperSU] Ingenium13:
I wonder if something as simple as moving the su binary somewhere else (and updating the environment variable accordingly so root apps still work) would fix it? Say from /su to /su2 or something.

The CTS check is a signed binary that is downloaded from Google each time the check is run. You can't modify the check because it will fail the signature. The only way around it is to hide what it's looking for somehow. The permissions change likely made it so it couldn't look inside the /su/bin folder to see the binary.

On a somewhat related note, I wonder if there have been any instances of fraud from AP on a rooted device? I wouldn't think root would be sufficient to bypass the other security mechanisms. Don't they still use the secure element in the NFC chip to store everything?

Sent from my Nexus 6P
[SuperSU] guhvanoh:
That's funny, why don't the banks ask Microsoft to compensate them because we all have admin privs on our Windows machines? Or Apple for that matter? Or my Linux distributor??? Having a rooted fone has got nothing to do with that. All they want is control. Well I own my fone, so I run it how I want. It the app can't run on my rooted fone, the app goes. Simple.
[SuperSU] antroid88:
Because there privileged user comes out of the box. On the phones we gain this privilege differently.
[SuperSU] poulopoulosa:
I wouldn't use the word "privilege". :))
[SuperSU] Alxoom33:
Well we know that changing permissions on the /su file from 755 to 751, which I unsuccessfully tried on my Nexus 6 didn't work. So need to figure out something else that might....
[SuperSU] bobby janow:
You make a good point. But thinking about it you don't walk around with your laptop open or really have as much a chance of it getting stolen, lost or scanned as you walk by. Rooted devices are more subject to malicious behavior when they are mobile which they are. But laptops do get stolen and information compromised. Websites install malware to steal your credentials. But maybe it's the fact you are connected to cell towers vs wifi or internet cables. Either way in order for Google to get AP accepted by institutions they need to show due diligence as Microsoft has done (kind of) with updates, Linux has done with root privileges, and Apple.. ahh who the heck knows what Apple does but they got that locked down pretty good.

I'm trying to live without root for the time being just to see. Not so much as for AP but just to test the waters in case this becomes the standard in the future. With Chainfire sort of gone I'm not sure how much longer root will be available on new devices and OS. We shall see.
[SuperSU] egingell:
You can elect to not use whatever words you want, but that's what it is - a privileged user.

Sent from: SGS5 - MM 6.0.1 / SGS4 - LP 5.0.1
[SuperSU] sherlock5545:
Unfortunately we don't live in world where banks are controlled by Google. Android Pay needs their cooperation, which means accepting their terms. If banks say they won't partner up if Android Pay runs on rooted devices, you'd have no Android Pay regardless, because there wouldn't be any bank to use it with.
[SuperSU] guhvanoh:
Fortunately I live in a world, country, where the banks cater to the needs of there customers and not the other way round. I don't need android pay, it needs me to use it. It's got to do that on my terms. It is my money
[SuperSU] Max88888:
Could you make sure that it works now?
[SuperSU] guhvanoh:
I tried that, living without root on my Z5P, the ads are killing me. I've gotta unlock my bootloader and root. Grand Prix wknd, Jason Bourne, bummer...
[SuperSU] Citizen_Snips:
Read the OP.

In case any SuperSU-rooted device passes SafetyNet, that is a bug in SafetyNet, not a feature of SuperSU.

While I may not agree with Google's stance, I'm not about to go messing with payment systems. Is it possible though? Probably yes.
[SuperSU] shoey63:
OK, so it's time to ditch SuperSU if you want AP. Unlocked bootloader plus TWRP will have to do (for now).
[SuperSU] guhvanoh:
You won't be able to pry SuperSU from my hands, not now, not ever. I'm just being lazy. I'll find the time to do my Z5P soon...
[SuperSU] Silarn:
Well. I'll have to debate with myself about it now. One of the main root functions I use is a clear all recent apps button and themeing. N will resove the former and the latter still sort of works (with Layers \ substratum themes). You have to root to run the theme install, but once it's installed you can still run the theme after removing root again. It's a pain to have to install and remove every time but it would still work...
[SuperSU] Mircolino:
It's ironic how, when I walk by my local grocery store, I still get the notification that Android Pay is accepted there, even though it no longer works.

AdAway, Gravity Screen, WiFi tethering and forcing Chrome to display desktop sites by default are, alone, worth a thousand Android Pay. Back to plastic!
[SuperSU] kryptikal:
Problem solved... sort of.

If you've got a compatible device just use multirom.

My main ROM has a custom kernel, is rooted, and runs xposed with lots of modules. I set up a secondary, Android Pay compatible, ROM (all syncing disabled and nothing installed but Android Pay) and just boot into that whenever I need Android Pay. It's basically the same process from when I was using systemless xposed. That always required a reboot anyway.

The reboot takes less than a minute (I just now timed it for giggles) and can easily be done while waiting in line at the checkout.

The secondary OS isn't rooted so it's a non-issue. Safetynet doesn't complain and Android Pay works great.

Nexus 6

multirom

Main rom - custom kernel, root, xposed, substratum

Secondary rom - stock as stock can be for AP

issues - none :)
[SuperSU] mickrussom:
but everyone can do banking with windows and linux and os x and they all have root. Google is pathetic.

---------- Post added at 07:26 PM ---------- Previous post was at 07:23 PM ----------

You know a lot of us paid for SuperSU (I did). Too bad people take the money and then take the side of a vile act by Google rather than the paying users. We want root and AP. We paid to get stuff like this. And now we are SOL. Bad mojo in the entire android ecosystem. Funny I can do banking with computers (linux, win, osx) with "root". Google is slime.
[SuperSU] androcraze:
The implementation is quite different going through a web browser. Rooted Android users can do that. Sounds like a non-issue then.
[SuperSU] guhvanoh:
Actually you're wrong on that. What you paid/donated for was spelt out for you. It had nothing to do with SuperSU & AP. If you really need both, code it. [MENTION=631273]Chainfire[/MENTION] has made his position clear on this. It is his right, respect that.
[SuperSU] natemup:
Seems an odd thing to be up for disagreement. What I'm concerned about us the build.prop editing, though, as I would love to have WiFi tethering on the stock setup I'm running with systemless for Android Pay.
[SuperSU] Alxoom33:
Build.prop editing does not affect your ability to use Android Pay with Systemless Root.
[SuperSU] embql:
From what I've heard, as soon as anything has been edited in the system folder, Android Pay may stop working, because of implemented security reasons.

Xposed installs itself in the system folder. Build.Prop is a file in the system folder.

Maybe Android Pay only checks the files it uses itself to see if there were any changes made, so editing Build.prop may not affect anything (see what people wrote just before me), but Xposed may.

Again, your mileage may vary :)

The "root" itself will not break, it is still systemless, but it won't make any difference as opposed to a normal root solution, again, because the system folder has been "compromised" ;)
[SuperSU] Almighty1:
Here is the scenario. I updated SuperSU v2.46 that came with the LG G4 root injection method with SuperSU v2.52 by running the Superuser.apk which basically installed /data/apps/<appname>/base.apk which worked as v2.52 except SuperSU will not install itself to /system even though I selected that option in SuperSU in which it said it will need to do a cleanup and reboot. So I manually renamed the base.apk to SuperSU.apk, changed the owner/group to root/root and kept the permissions as rw-r--r--, moved the file to /system/apps/SuperSU/SuperSU.apk, deleted the /data/apps/<appname> folder for SuperSU and restarted the phone. The only thing is SuperSU does not show up in the app launcher and the SuperSU.apk has the Android icon instead of the SuperSU app icon so I flashed the SuperSU v2.52 zip file with flashfire and it did restore /system/apps/SuperSU/SuperSU.apk with the correct icon except the problem is I noticed with Android 5.1 lollipop, you just can't replace a .apk in /system/app by moving it from /data/app as it will not even show up in the launcher. Not sure if this is a Lollipop thing or a LG thing as on previous Motorola phones running 4.4 Kitkat and below, replacing the .apk will usually work. I've cleared the app cache, deleted the files in /data/dalvik-cache/arm, /data/dalvik-cache/arm64 and /data/dalvik-cache/profiles without deleting the folders as I don't know if it's safe deleting the folders and also clearing the system /cache to see if it makes a difference. Didn't work. Does anyone know how I can fix this because it seems like once you updated to a newer version that installs in /data/apps, even if you delete the /data/apps version, it will not use the /system/apps version and simply ignore it. The only reason I still have root is probably because of the su binary still on the system.

---------- Post added at 09:42 PM ---------- Previous post was at 09:37 PM ----------

All one has to do is with xposed module rootcloak2 installed, you would add Android Pay and Google Play Services so it blocks root from them. Android Pay is tied to Google Play Services as you cannot uninstall updates for Google Play Services if Android Pay or Android Device Manager is enabled.
[SuperSU] kato7youknow:
reply

Try copy a and pasting it to system private app with a root explore app and reboot to see if it stays rooted and go into settings in super user app and check survival mode. Hope this helps.
[SuperSU] Almighty1:
Just tried it and it didn't work as SuperSU still didn't show up in the application launcher. It's just weird as it seems like if you had a system app and you updated to a newer version that gets installed in data/apps on Android 5.1, if you move it to system/app or system/priv-app and replace the original apk with the newer version or even keep the original apk and deleting the one in /data/app, the app will just disappear from the system after reboot. If you use root explorer and click on the apk so it installs back to data/apps, then the app will show up. I'm still rooted probably because of the su binary and busybox except the app doesn't show up in the application launcher's list of apps so I cant even open the app to get in settings. I read that unlike Android versions below 5.0, where the apk directly resides in the app or priv-app directories under system or data, the new structure is a folder with the app name and then in the folder, there is the apk and also a lib directory. In this case, it seems to be ignoring the apk in system if the same app got installed in data even if the one in data no longer exists so not sure if there is a way to log system bootup to see what android actually reports or force a scan of system so the app re-registers.
[SuperSU] Ingenium13:
I'm having the same issue with Secure Settings. I don't need to use it very often and want to try Android Pay, so I'm sticking with systemless for now.

Someone said you could look up the commands the Tasker plugin executes in the SuperSU log and run them manually and it works, but I haven't gotten it to actually work for me. It just kills my root shell every time I run the exec app_process command, and the action doesn't run. So far though I haven't found an alternative way to programmatically enable/disable app notifications.

Hopefully the developer comes back or Chainfire figures out a way to do a unionfs style mount.

Sent from my Nexus 6P
[SuperSU] mobileman88:
Once you make changes to build.prop which resides in /system, then you'd have modified it and break Android Pay.

---------- Post added at 10:05 PM ---------- Previous post was at 10:05 PM ----------

Just install the one from the play store. Remove SuperSU before you flash SuperSU 2.6 .
[SuperSU] jackdubl:
OK, but you can make the changes. Unfortunately, only way to unlock tethering on the 5X that I know is to adjust the build.prop. Wish I could have both.
[SuperSU] FletchF:
Have you tested this? I thought I read somewhere that a modified build.prop will not prevent Android Pay from working as long as /system is otherwise unchanged.
[SuperSU] spyder91:
Changing only DPI via build.prop was enough for it to break Pay for me. At that point I decided I would rather just root than worry about Pay, but that seemingly trivial change was enough to flag it.
[SuperSU] c3k:
+1

I still use 2.52 while upgrading my 5x to 6.0.1 because I don't need android pay and I want to keep the things simple as possible.

For updates instead of flash boot&recovery before each OTA I prefer flash boot&system&radio from factory image (that are out sooner on each update).
[SuperSU] jcsww:
I wouldn't mind having Android Pay work, but only if that can be done while still allowing me to change the system files I want. Because it is just one or the other though. My want to edit the system files is more important to me than having Android Pay working.
[SuperSU] sirxdroid:
I assume someone made a modified boot.img available for the 5X for /system root to work in 6.0.1? I have a 6P and there isn't a modified stock boot.img available as far as I can tell.
[SuperSU] Chainfire:
I think there is a bit of confusion going on here. Let me explain this one more time.

(1) Being able to change things on /system is completely unrelated to having a system-based root or a system-less root. System-less root does not prevent you from making any changes to /system you want. The root itself just doesn't make any changes to your /system. It is true that on some devices modifying /system doesn't work right even with root, but this is not due to root itself or how/where it is installed, these are two separate issues.

(2) On 6.x, even with a system-based root, you still need a patched (custom) boot image (kernel). If you don't want the system-less root because you don't want to need a patched kernel, installing root to /system isn't going to solve that problem for you.

(3) Root on /system still works if installed that way, it just isn't installed that way by default. I'm keeping it available in case the exploiters need it to root locked bootloader devices. I have no idea how they would do this, but I'd rather not limit them at this point.

(4) I will provide a solution to increase compatibility with old apps by doing something with /system/xbin/su, for 2.62.

Aside from point (4), there are no benefits that I can see to using a /system based root over the system-less variant. Please, try to explain to me why you think you need it. What benefit will it bring you? Because none of the points raised in the quoted posts above (again, aside from 4) actually work the way it appears you think it does.
[SuperSU] sirxdroid:
Exactly. If you can root you can flash a new build. And what are the chances that OTA updates actually work when you are rooted (systemless) and some app may have modified /system anyway without you realizing? OTA updates are over-rated. Now Android Pay is a different story.
[SuperSU] qdroid:
Nexus 6P/Angler 6.01/SuperSU 2.61 systemless

SuperSU 2.61 seems to have installed via TWRP without issue and I did not allow TWRP to install SuperSU.

System is running without issue but I'm not getting grant dialogs for root apps.

Is there something else that needs to be installed/done post boot? Didn't want to try different things as Android Pay is functional and wanted to keep it that way.

Thanks

*** FIXED - went flash happy and forgot to reflash SuperSU 2.61 *after* flashing a new kernel (franco's)