yashsingh1/xdaforums huggingface dataset:
[SuperSU] :
Just tested it live. As I thought, just as it was before systemless root, AP's actual point of transaction is stricter than the safetynet check app or add a new card prompt. Disabling su through supersu app will allow both of the latter but not the former. Simply rebooting to twrp, renaming su.img to su.imk, and rebooting back to system so that /su was empty allowed me to complete multiple tap and pay transactions. The supersu app was still installed and untouched while also having a custom kernel installed. A little less convenient than desired, but considering the relatively low utility of android pay for me, not that big a deal.
[SuperSU] Alxoom33:
No, you didn't need to do all that! Just need to disable su in the su app, and reeboot! See my post above. I just purchased tea at McDonalds using AP. Didn't work w/o reeboot.[emoji108]
[SuperSU] Chainfire:
Conflicting results here ... :)
[SuperSU] Alxoom33:
I'm still at McDonalds. Still works my man![emoji2]

It was a good cup of tea paid with AP! ;)
[SuperSU] garyd9:
If they are applied via scripts in su.d, they WILL work even if /su/bin/su is missing on the reboot.

Confirmed that if I boot the phone with /su/bin/su not there, that AP is working.

I'm not using the supersu mechanism for disabling superuser. Instead, I've just deleted /su/bin/su. When I need root for something that I can't do on startup with su.d scripts, I have another script that creates a symbolic link from /su/bin/deamonsu to /data/local/tmp/su, and then uses that newly created "su" (with the -c parameter) to copy /su/bin/daemonsu to /su/bin/su (and chmod to 755.) (Actually, I don't need to copy and chmod... just a link works fine):

#!/system/bin/sh
ln -s /su/bin/daemonsu /data/local/tmp/su
/data/local/tmp/su -c ln -s /su/bin/daemonsu /su/bin/su
rm /data/local/tmp/su

Then when I don't want root anymore, I just delete the file again.

su -c rm /su/bin/su

For my device, this lets me boot without 'su' intact (which seems to impact AP) and gives me a way to automate "unrooting" and "rerooting" the device.
[SuperSU] Chainfire:
Having /su/bin/su be a symlink will sooner or later lose you root.
[SuperSU] garyd9:
Well, easy enough to change the script to copy and chmod. The real problem would be if daemonsu is no longer identical to su. If/when that happens, I'll have to make a copy of the su binary someplace for safe keeping.

It works for me right now, and I only have root active for short intervals of time such as when I need to use titanium backup, get a root shell prompt, etc.
[SuperSU] Alxoom33:
Seems much more complicated then un- checking a box in the su# app and reebooting. [emoji107]
[SuperSU] DROITURK182:
Update 2: I can confirm you must reboot phone after disabling su in the app, just worked at the vending machine at work. Just two more taps and a free chromecast. :)
[SuperSU] NuShrike:
A lot less complicated then, for now thanks.
[SuperSU] dadsterflip:
Where do you see that ? Been tapping with mine
[SuperSU] DROITURK182:
Did you get the tap 10 card in Android pay?
[SuperSU] dadsterflip:
No. In google play?
[SuperSU] DROITURK182:
It's a special promotion inside the Android pay app.
[SuperSU] aergern:
So ... we're all just kind of screwed as far as root and Android Pay unless we want to unroot ... reboot each time and re-enable root. What a shame ... guess it's plastic for a while longer. :/
[SuperSU] clevebb:
With all the workarounds so far has anyone figured out why google is excluding us from using AP?
[SuperSU] Pig Vomit:
Unroot, reboot, use, re-root. This is what I had to do to use Google Wallet for the last couple months before AP's introduction in the days before systemless root. A step backwards. At the same time, I understand Google's desire to keep AP secure and prevent use on rooted devices. Trust and security is the key towards increased use and increased revenue for Google. I just wish they would make it so you couldn't even open AP if it's not going to work on my device. Hate being in line, trying to tap and pay, and only then having the error message pop up.

And then there's this future trend, which means banks are also likely to make every effort to ensure their apps won't work on rooted devices:

Big U.S. banks will be rolling out ATMs that take smartphones, not cards
[SuperSU] bunklung:
Perhaps a better solution for a subset of people is to only root the phone when you need root, and not have the device rooted all the time? You could setup a Tasker item that roots the phone for x seconds to preform a task. Perhaps then Safetynet would not be triggered and a reboot could be avoided.

When I suggest rooting the phone, I don't suggest using Supersu.apk, but a few automated shell commands. I have had good luck with this.
[SuperSU] wvcadle:
Not everyone got the Tap 10 reward email. Only some of us.
[SuperSU] luigidk:
I've removed systemless root and safetynet now passes as expected.

I already have a custom rom, themed, and have v4a running. I'm going to run without root for a while as im not sure I'm giving up that much. I guess Kernel adiutor doesn't work so my custom rom is less viable...
[SuperSU] Alxoom33:
I don't understand all the fuss!

It's really very simple. Uncheck a box in the Su app and reeboot. That's it!

Then AP works perfectly! Not a big deal! Really, what are you moping about?

After you are done shopping, if you need Root, check the box in Su app and reeboot. I don't know what the big fuss is about? [MENTION=631273]Chainfire[/MENTION], do you understand this?
[SuperSU] aergern:
I've been an Android user since 1.5 so I get how simple it is. I also get that that having to disable something, reboot and then enable and reboot again is a pain the tuchus. It's more work than reaching in my front pocket and pulling my wallet out for my plastic and doing what you suggest sucks away battery. Or I could reach in my back pocket an pull out ye old work phone which is a iPhone 6 plus. It's not a life altering event since Apple Pay works on jailbroken phones because OMG! a secure chip! Whodathunkit. ;)

Also, I wasn't moping. I was just commenting.

Maybe if 100 apps didn't start themselves and hang out due to legacy "must be ready in case they need me because ... slow handset" then Greenify and other apps wouldn't be needed. Those apps are more valuable to me then AP every could be. *shrug*

And thanks for mansplaining the entirety of this thread as if I hadn't read it and couldn't figure out how do what you suggest. SO awesome. :good:
[SuperSU] rebretz000:
It's a sad day when iPhone has more freedom than a Nexus.
[SuperSU] PhilipTD:
I don't know anything about iphones or apple, and not much about security IT in general, so I hope you'll forgive my ignorance. I'm just wondering why Google doesn't use that technology... unless it's a proprietary Apple thing? Or is it something that we may look forward to in the future?
[SuperSU] aergern:
Yeah, pretty much. I'm sure that this issue could be bypassed. Just not by me.

---------- Post added at 03:50 PM ---------- Previous post was at 03:45 PM ----------

---------- Post added at 03:51 PM ---------- Previous post was at 03:50 PM ----------

It's not proprietary to put logic into a specific chip to handle this type of operation. I'd bet they just wanted more folks to use it than those with new handsets that have this specific chip. Anything iPhone prior to the handset they released with the Apple Pay ability can not do Apple Pay so there is the rub.
[SuperSU] egingell:
Such a Tasker task would require root.

Sent from: SGS4 - JB 4.2.2 MF9
[SuperSU] bunklung:
Sorta, just need to keep a backup su binary. SuperSU.apk can restore root when it's not rooted. I don't fully understand how the APK does it, but one could manually do it.

I have had good luck. I just don't know how quickly Safetynet and/or Android Pay identifies when su is restored.
[SuperSU] garyd9:
No, it wouldn't. That was why I posted the steps needed to create a script that would restore the 'su' binary (from a non-root shell.)

The responses I got made it obvious that most people didn't put that together. (For example, the person that suggested it'd be less steps to go into the app and click a checkbox.) The people who aren't able to put things together, in my opinion, shouldn't be messing with root anyway, so I didn't argue.
[SuperSU] PhantomGamers:
FWIW Here's what's going on for me:

Sometime in the past week or so Android Pay must have been updated because now even Systemless Root triggers "We cannot verify your system" or whatever the message is. Prior to yesterday every transaction worked for me with systemless root enabled (not sure exactly when I used it last before that but it couldn't have been more than a day or two before yesterday).

Now as long as I disable root before I attempt to make a purchase it works fine, and I can reenable it after the purchase with no issues. If I try to make a payment with root enabled and I trigger the "We cannot verify your system" screen I won't be able to make a purchase, even after disabling root, until I remove and add my card back with root disabled (perhaps rebooting alone is enough but I usually just do this because it's faster).

(Also, I'm currently running SuperSU Pro v2.66 so YMMV)
[SuperSU] tallgrasshawk:
Running a Nexus 5x with latest Chroma build (1-18, I belive) and SU 2.66. Was able to uncheck Enable SU in SU app. Checked on AP that I was able to add a card and could. Successfully purchased with AP at my local store.

Re-checking the box in SU gives me update binary warnings, which will fail- but I still have some SU capabilities. Need to reflash 2.66 to regain full functionality.
[SuperSU] Joshmccullough:
Did you have to reboot after unchecking 'Enable SU' in order to get Android Pay to work?
[SuperSU] tallgrasshawk:
No. Just unchecked SU. Opened AP, could add a card, paid for stuff with AP.
[SuperSU] ldubs:
So it sounds like we can't use systemless root at this point as ap still fails. Is there any need to run systemless then?
[SuperSU] elreydenj:
I really hope that once android pay is readily available to use outside of the US that someone will pick up the ball and run with a way to bypass the checks by Google. Right know there is kind of a love/hate relationship for pay being that users outside of the US cant use it yet. I remember days where there was a modified play services in order to get google wallet to work on certain carriers, ect. I am not saying that old wallet hack is an apples to apples reference, but I am referring to a developer committing to playing the cat and mouse game..... I am not downplaying the amount of work that it may take, but the majority of root users do not fall into the "oh well Pay isnt that important and I'll just have to choose root over the functionality" group. Some may say this out of frustration, however they will be the first to jump on the work around when it is finally posted. This will especially be the case when Pay can finally make its way to many other countries I would presume.
[SuperSU] Alxoom33:
Did you people read the last 2-3 pages?
[SuperSU] ldubs:
Yes I read the whole thread. What I was asking was, is there any further need for systemless root at this point? I.e if I want to use ap just unroot in the SuperSU app, use away, then reroot. Or maybe I just leave my device unrooted until I need root for something.
[SuperSU] garyd9:
That's a decision each person needs to make on their own. Some might not need root to be continuously active. Those people might decide to un-root and leave root disabled until needed.

However, that's something YOU have to decide on for YOUR device and YOUR needs.
[SuperSU] Alxoom33:
If you are rooted in system, I don't think simply disabling Root in the Su app will allow AP to pass Safety Check. Nice to see your post Lou.
[SuperSU] DROITURK182:
That's what I'm doing leaving it unrooted to use AP, only going to flash the SuperSu.apk when I need it. One good thing I noticed my adaway app that I use with root, of course it changed the host file and after I disable su in app, and reboot it keeps the adaway host file intact.
[SuperSU] egingell:
Systemless was not intended to make Android Pay work. It was to make OTAs work.

Sent from: SGS4 - JB 4.2.2 MF9
[SuperSU] luigidk:
I have the same question - with also the question being - any need for root at all?

I'm unrooted and seeing how it goes... giving up a few features I enjoyed but not must have (e.g.: dbltap2wake, adaway)... so far I don't feel like I've given up much. I can still run my custom ROM/Kernel - and most of what I want is in there.

If I go back to root - my understanding is that systemless root works better with MarshMallow (can't recall for sure but that was what I recall seeing).
[SuperSU] RandomPooka:
The last few posts basically sum up what I've been wondering. How badly do I need root vs how much do I want it just to have it?

I run custom ROMs only. If the custom ROM has in-built provisions for everything I would have rooted for, the only real reason to root would be for TiBu restoring of SMS/MMS/Call Log .. There are plenty of apps out there that do this very thing, apparently.

There's an occasional instance when I want to roll back an app version, but APK Mirrors are available for that as well.

I usually use the EX kernel on my N6, and all the settings that I actually bother messing with are able to be set with the installer in recovery.

Basically, it is coming down to realizing that rooting is becoming a nonessential process and you CAN have the best of both if you find the right ROM (or build at home and pull in whatever features you like)
[SuperSU] Shemploo:
Silly question: Post install, does XPosed need constant root to activate/de-active modules?

I'm asking cause people might have a point here, with a feature rich custom ROM, Root might be only needed once in a while.

Also, I guess AdAway needs root to update the hosts file too.
[SuperSU] RandomPooka:
From what I'm seeing, none of the custom ROM images for my device work with AP, even with no root.

I'm not sure if Xposed modules will function in a root free environment, but I'm fairly sure that having the framework installed means that your /system partition is already compromised. That alone would likely break AP/SafetyNet
[SuperSU] Falinor:
For me, simply unchecking supersu and rebooting doesn't work. If I want to use AP, I have to choose the "full unroot" option, and hit "No" on the prompt about going back to the stock boot image. I reboot, and I can use AP just fine (used it this morning).

When I don't need to use AP, I simply reboot into recovery and reflash supersu. Takes 2 minutes tops. I stay rooted until I need to use AP, problem solved.
[SuperSU] FletchF:
If I have to uncheck "enable supersu" to use AP, is there any point anymore to deleting xbin_bind?
[SuperSU] luigidk:
All you need to do is grab the HOSTS file that AdAway manages and use TWRP to move it to system/etc and chmod to 0644... then AdAway is not needed. Adaway is really nothing more than the HOSTS file manager... Here's the post that helped me: http://xdaforums.com/showpost.php?p=65100932&postcount=4561
[SuperSU] Alxoom33:
Good question! I was just wondering about the same issue.

Probably not, unless it somehow affect the System Partition when su disabled. Will have to test it. [emoji2]

---------- Post added at 01:20 PM ---------- Previous post was at 01:17 PM ----------

Curious, did you delete or disable su/xbin_bind?
[SuperSU] Falinor:
I deleted su/xbin_bind
[SuperSU] Alxoom33:
Just tested. AP did not work for me. Even when I disabled Root in Su app. Can anyone else confirm? I tried it with and without the su/xbin bind folder enabled.
[SuperSU] Falinor:
did you reboot after selecting "full unroot"? Also, did you hit "no" when asked to set boot back to stock?
[SuperSU] Alxoom33:
No I disabled SU on the app. Not full unroot. However, I think that the base rom I used to update last night has a substantially modified System Partition. I am going to try again with Tupacks base.

Edit: I am on HeckNoTechno's NX6ShamuM MMB29Q base.
[SuperSU] Falinor:
keep us posted, friend.
[SuperSU] elreydenj:
I believe that you have to reboot after un checking. The reports of just disabling SU and using it are unfounded. There is more to it. I was going to respond to your post about reading threads yesterday but i did not... I saw one person say that they used AP after just simply unchecking enable SU and frankly I dont believe it. You can uncheck SU add a card in AP and pass safety net, however you will not be able to pay with AP unless you reboot. Takes away from all of the ease of functionality of AP. That is where my thread about a work around came from. AP should offer an ease of use. You are texting or browsing in Walgreens and come up to a register. Without much effort, you tap, and keep on going. Having to reboot simply takes all of the fun out of using AP. I am still hoping for an actual work around to come about in the near future. I dont underestimate the work that it may entail and i understand that Google may catch on but it is a reasonable request for a root user and one that people would donate for.
[SuperSU] Alxoom33:
Thanks, but I did reeboot. In fact it was me preaching to seemingly deaf ears this weekend to reeboot after uncheaking the Su àpp.[emoji2] I think this is a losing war, since it is easy for Google to patch things so AP is totally useless. They may have already. I'll try again tonight and test.
[SuperSU] Alxoom33:
Well, I found the culprit. Techno's Rom installed a build prop for permissive.sh file in a su.D folder in the System. I moved the folder to a su/backup file and disabled the folder. Temporarily disabled AP reebooed and it worked just fine. Still had su/xbin_bind disabled. Will test that next time[emoji2]
[SuperSU] PhantomGamers:
I can't say for the new update but previously even with system root just disabling it worked fine for me.
[SuperSU] luigidk:
What worked for me was simply to unroot and be done with it. I've given up a few features but after a couple days don't miss anything enough that would cause me to want to root and fight the ap battles
[SuperSU] Alxoom33:
Does it still work for you. Google upped their game.
[SuperSU] PhantomGamers:
I mean I still have systemless root installed so I can't test, I'll probably give it a shot when the next android update comes out and I have to flash something anyway.
[SuperSU] Alxoom33:
It came out on Monday MMB29Q, I believe is the latest.
[SuperSU] WACOMalt:
It does still work to just disable root in the SuperSU app IF you took these precautions before installing SuperSU:

You must run these commands in TWRP's terminal emulator.

echo SYSTEMLESS=true>>/data/.supersu
echo BINDSYSTEMXBIN=false>>/data/.supersu

After that install SuperSU (tested up to 2.67) and when you need to use Pay just disable root from the app.

Note that reenabling won't work in the app, you'll have to flash again (but those terminal commands stick, so you only need to reflash)

It's annoying, but it passes safety net when installed this way, and then disabled.

Oh, and if you have already flashed root without running those use the full unroot option in SuperSU app and then do this all and you should be good to go.
[SuperSU] elreydenj:
It passes safety net but Android Pay doesnt work. It has been discussed and confirmed already.
[SuperSU] Alxoom33:
Sorry, but I used AP with my rooted N6 just this week. Disabled SU in app and reebooed.
[SuperSU] DROITURK182:
I can concur +1
[SuperSU] elreydenj:
Absolutely correct. I thought you were referencing without a reboot. You left that out of your original post. For those of us who utilize certain kernel optimizations that require root access on boot having to reboot really isnt a viable work around. Oh well.....
[SuperSU] Alxoom33:
Yes, I agree, you need an alternative solutions. Can the Kernel optimizations be reset in a script upon Reeboot using eg Tasker?
[SuperSU] bouchigo:
[MENTION=4377296]jgummeson[/MENTION] posted this that you can try, and that it worked for him (he made an actual AP purchase) :

Try changing the permissions of the /su/bin folder to 751 instead of 755. You can use Root Explorer, or a similar file browser; you can also send the permission change commands through adb if you don't want to use a file explorer.

I did it using Root Explorer and It's passing the SafetyNet checks without disabling SuperSu in the app settings. I haven't had a chance to make a purchase yet, but I will if I get a chance tonight to see how it goes :good:
[SuperSU] rebretz000:
Worked for me also. Got it with Root Explorer. For the life of me I can't figure out how to change permission with Solid Explorer.
[SuperSU] chazall1:
to change permission with Solid Explorer.

Long press on the file, go to 3 ... properties and slide over to permissions.
[SuperSU] rebretz000:
Thank you. I was trying to find a place that I typed in the different number.
[SuperSU] Alxoom33:
Changed permission to 751. Can't wait to try it out!

Edit: Doesn't seem to pass Safety Net check on the AP app. Are you sure the only thing I need to do is the permission change and reeboot?
[SuperSU] spainter:
This is the text directly from [MENTION=4377296]jgummeson[/MENTION] original post.

-Starting from stock 6.01

-Flashed systemless SuperSU 2.67 from TWRP

-run "adb shell"

-from adb shell run "su"

-from adb shell run "chmod 751 /su/bin"
[SuperSU] ldubs:
And this works to make a purchase with AP? Hey [MENTION=3137037]spainter[/MENTION] good to see you over here
[SuperSU] Alxoom33:
I made the modifications with Root Explorer. Do you think we still need to disable su/xbin_bind?
[SuperSU] spainter:
He doesn't mention it in his post. Since it doesn't hurt to rename it and test it I wouldn't think it would be a problem. If it doesn't work it is a breeze to rename it back and reboot.
[SuperSU] Alxoom33:
That seemed to fix things. Passes Safety Net on this end. Will try purchase later today.
[SuperSU] luigidk:
Changing /su/bin to 751 - very exciting and easy - will be following along to see what everyone's experience with this is.

That said - I am getting used to not having root - so in a way - going back to root feels like a step backwards. Also - I'm sure it'll be just a matter of time before Google discovers this and shuts it down also. :(
[SuperSU] rebretz000:
For Android Pay do we still type

echo BINDSYSTEMXBIN=false>>/data/.supersu

echo SYSTEMLESS=true>>/data/.supersu

with twrp 3.0.0.0 on nexus 6p?
[SuperSU] nathanchance:
Well yes but systemless root without chmoding the /su/bin folder does not work with Android Pay anymore.
[SuperSU] elreydenj:
When did that happen? I used it yesterday...

---------- Post added at 06:52 PM ---------- Previous post was at 06:47 PM ----------

I didn't read correctly. You wrote "without" chmodding.... I read that AP wasn't working. Jumped the gun!
[SuperSU] rebretz000:
That's the changing permission from 755 -> 751
[SuperSU] Alxoom33:
AP works perfectly using this technique. Just purchased at McDonalds

Need to disable su/xbin_bind.
[SuperSU] Empty Hand:
Is that working without disabling su and rebooting?
[SuperSU] Alxoom33:
Yes! Just change permissions of the su/bin folder to 751 and disable su/xbin_bind and reeboot.
[SuperSU] Joshmccullough:
I'm looking in my /su/xbin folder and there's nothing there, completely empty..... Did i goof something up in my flashing process, or any tip as to why this might be?
[SuperSU] ldubs:
Sweet I changed permissions on the su/bin folder to 751 and was able to add my bank card. Will try making a purchase soon
[SuperSU] spainter:
My folder is also empty. I believe it is a place holder for a symlink
[SuperSU] Chainfire:
Has anyone ran into any problems whatsoever with the 751 chmod?
[SuperSU] ifwillems:
I was able to get Android Pay to work, as described above. But then I went back into TWRP and installed Viper4Android. It installed fine but SafetyHelper said my device was no longer compatible and AP didn't work any longer. Any idea what happened?
[SuperSU] rebretz000:
I haven't but I run so few apps that require root.

Kernel app, Naptime, Solid Explorer, TWRP