yashsingh1/xdaforums huggingface dataset:
[SuperSU] bunklung:
Awesome news! It's working again until Monday morning when Googlers come in to check their XDA subscriptions! *waves at Google reading this tread*

The good news for us east coast users is that'll be around Noon! So at least I can buy a coffee with my phone in the morning.

It's as if the solution need to be a secret as Google does not intend AP to play nice with SU. Has Google since reached out on the SU/Android Pay quagmire?
[SuperSU] Alxoom33:
No problems here. Been using it a couple of days on my Nexus 6 since it was noted on this thread. AP also works.[emoji106] [emoji106]
[SuperSU] Pig Vomit:
Modded the folder this morning....went to McD's for breakfast. Of course, their sensor wasn't working so hot, so I couldn't use Android Pay, but at least I didn't get an error.

Just came from Subway, AP worked flawlessly.

I only use root for ARUnchained (mirror to my Pioneer AppRadio head unit in my car), and Tasker. Both are working fine after the mod.

We should start a pool on how many days it will take for Google to kill this. My guess is Wednesday.
[SuperSU] rebretz000:
February 17th.
[SuperSU] timdorr:
This isn't working for me. I'm running stock 6.01 on a Nexus 6.

I flashed the Feb factory image (system, boot, recovery, and cache).

Booted up and confirmed SafetyNet was green.

fastboot boot twrp.img and installed the SuperSU 2.67 systemless root.

Booted up and adb shelled in to chmod 751 /su/bin.

SafetyNet comes back red

Is there another step I'm missing? Has Google fixed this on their end?
[SuperSU] spainter:
Yes you forgot to rename or delete the /su/xbin_bind folder. Then reboot and check it again
[SuperSU] phynias:
Anyone know why my /su directory is missing?? SuperSU 2.67 installed.
[SuperSU] nathanchance:
Because you didn't install SuperSU 2.67 as systemless
[SuperSU] phynias:
ok. i grabbed the supersu from here http://xdaforums.com/showpost.php?p=64161125 which says it detects if its 6.01 and installs systemless.

what else should i do?
[SuperSU] markwebb:
Did you type this mod in twrp before flashing supersu?

echo SYSTEMLESS=true>>/data/.supersu

echo BINDSYSTEMXBIN=false>>/data/.supersu
[SuperSU] Pig Vomit:
Here's how I did it. Hope it helps others.

Unrooted/Uninstalled SuperSU.

Flashed latest everything except userdata (probably only needed to flash system, recovery and boot, but I did everything anyway)

Used CFAutoRoot to install 2.65 (first time I've done it on my 6P without TWRP), so Recovery is still stock for me.

Deleted /su/xbin_bind folder using ES File Explorer.

Tried to change /su/bin folder permissions using adb shell ("adb shell", then "# chmod 751 /su/bin", right? I would love to know the right way to do it using adb shell for future reference). I didn't get any errors using these commands but it didn't work for me therefore I don't think I did it right.

I then tried to use ES File Explorer (Root Explorer) to change permissions, but ES is a little wonky with systemless and wouldn't work for me.

Then used Root File Manager (uncheck "Others Read" box on the /su/bin folder permissions) to change /su/bin folder permissions to 751 (this worked).

Reboot
[SuperSU] elreydenj:
Everything worked without issue. I use the usual suspects, (root explorer, TIBU, kernel apps for tweaks, ect.)
[SuperSU] nathanchance:
[MENTION=4303388]lethang90b[/MENTION] it sounds like you did not properly install SuperSU as systemless, as not having a /su folder means you are not systemless. You will need to follow this process:

1. Delete /data/.supersu (if it exists)

2. Go into SuperSU > Settings and do a full unroot.

3. Boot into recovery and navigate to Advanced > Terminal Command.

4. Type the two lines below (one at a time):

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

The first one forces systemless, the second prevents /su/xbin_bind from existing.

5. Flash SuperSU.

6. Reboot and attempt to change the permissions to get AP working.
[SuperSU] jgummeson:
Thanks for the mention and spreading the good news over here. Hopefully this keeps on working for awhile.
[SuperSU] Joshmccullough:
Any reason why I'd be running SuperSU systemless (confirmed through SuperSU settings in Pure Nexus) yet still not have an /su/xbin_bind directory? I see an /su/xbin but not an /su/xbin_bind directory.

EDIT: Maybe I'm misunderstanding......if I'm following systemless SuperSU correctly, would there be an /su/xbin_bind at all? I'm grasping at straws to get this working, probably mucking things up in the process :)
[SuperSU] secguy:
thanks for that JsChiSurf, I expected it'd pass. Be sure to keep checking it from time to time, google will probably update the safetynet system to 'detect' this at some point.
[SuperSU] provolinoo:
Thanks for the update :)

On the same topic:

when I boot in recovery with TWRP as first screen it tells me it found an untouched system partition and asks me for keeping it read only or allowing modifications to avoid stock rom replaces recovery

what's the right answer here? :D
[SuperSU] provolinoo:
I'm on Nexus 6 :)

My concerns were related to the SafetyNet check, I was worried about breaking it if I would have allowed TWRP to modify system partition.

Anyway I tried and it still passes the check, so it seem TWRP doesn't really modify something, it's just a warning message.

It seems TWRP asks for modifying the recovery script that flash stock recovery back on reboot but since it's not present in Google factory images (I tested that rebooting the device after flashing TWRP without entering in it and TWRP was still there on next reboots), it doesn't do nothing at all.
[SuperSU] JsChiSurf:
Additionally, with systemless root, even if restoring from TWRP were problematic, it's just as easy to flash a stock system image anyway, as opposed to a TWRP restore.

I'm rooted using the "systemless" option and have not modified /system in anyway, while still gaining the benefits of Titaniumbackup, root browser, root in shell / terminal emulator, running tasker root commands, etc. Haven't touched build.prop or host files in any way (and never do).

Now, when / if xposed comes along for Marshmallow, now I've got a decision to make. Until then, for the time being at least, I have root and the benefits I need as a result, an untouched /system, and Android Pay working.
[SuperSU] Cares:
Hmm actually I seem to pass Google SafetyNet CTS test with standard Adaway host file modification. I'll test if Android Pay works.

If I wanted to remove systemless root though, would I just uninstall SuperSU or are there other files that I need to delete on my phone? If I "Disable Ad Blocking" does that revert my host file to default and my system partition will be stock?
[SuperSU] ashyx:
Run the uninstaller, this will only remove the apk. Then flash a stock boot image and then flash v2.52
[SuperSU] Techie#1:
Yeeeah! Success!

So, after unsuccessfully trying to obtain unlock + root & still be able to use Android Pay, I finally saw success thanks to this guide! Awesome!!! I'm so happy about that! However, I also had to overcome what several others have experecienced as well which was the Google Services crashes immediately following boot up the 1st time around.

Thanks to the additional suggestions to upgrade/re-flash a the newer K boot.img I finally saw success & the crashes are a thing of the past & I just confirmed from Root Checker that I am officially rooted!

However, now that I'm officially rooted, I now am itching to try out a new, almost stock with enhancements Marshmellow rom which only seems to currently support the older 08 build.

Regardless, thank you Chain-Fire for showing all of us that this exploit is the real deal!

You deserve all of the props that you and your team are getting. for such a reliable and quick way to get unlocked, rooted, & with Android Pay still available! Cheers
[SuperSU] Alxoom33:
A little confused. I am on a preerooted Shamu custom rom, with the Google MRA58R November security update Cataclysm with EX 3.06 Kernel.

Yesterday I unrooted my Nexus 6 using SuperSu with the unroot function and successfully used Android Pay[emoji2]

I reerooted by flashing SuperSu 2.56 and upgrading to Pro (my usual setup). Everything working. Root checker says I have root and I am granting root permissions as before.

So, do I have Systemless root? If not, what do I have? Thanks.
[SuperSU] stangri:
Since there's a disclaimer about possible issues with encrypted devices I wanted to join the other users who have reported success.

I've had a bootloader unlocked Nexus 5 which was fully stock and encrypted. By flashing the systemless boot image and the SuperSU 2.56 I was able to achieve root (with Android Pay still working) on MRA58N.
[SuperSU] Dr0idgroove:
Which systemless boot image?

I have seen one but few posts below someone reported it didn't work. It also wasn't by an esteemed and experienced recognized contributor like yourself ;)
[SuperSU] Alxoom33:
One big advantage is the ability to use Android Pay without unrooting your Nexus device!
[SuperSU] elreydenj:
Absolutely. Some people actually love to use Android Pay and only need a few of the simpler advantages of root like being able to use titanium backup or editing build.prop easily. Also, has anyone created a systemless boot.img for the newest 6P image MDB08M? Can someone please create and post one. Thank you.
[SuperSU] Tzfardaya:
The original 6p file that Chainfire provided in the beginning worked for me on 8m
[SuperSU] stangri:
Well, with systemless root and Xposed installed into system I can still use Android Pay. Not sure it would have been possible with the non-systemless root.
[SuperSU] Alxoom33:
I tried with the N6, didn't work. Xposed prevented use of Android Pay.
[SuperSU] stangri:
Bummer, I'm about to switch to N6. :(

Have you had your APay setup before rooting/Xposing tho? I have, maybe that made a difference.
[SuperSU] lePoMo:
the short answer: it doesn't matter that much

the long(er) answer:

It depends on what you're doing with root, and your device/rom.

Systemless root has two (to three) advantages:

* applying OTA has a few less steps. Before applying, flash back stock boot.img. After applying, flash modified boot.img. While these steps are needed for both root-methods, with systemless, that's it. you're now rooted again. That's because root now resides in the data partition, so the files never went away (assuming you were rooted with systemless before)

* if you're working with scripts (or any other files) in /su, they'll stick after applying OTA. In my case that would be a custom hosts file and a script that mount-binds it to /system/etc/hosts. Other things in /su could be the busybox executables, etc.

* many reported that Android Pay works with systemless root (I guess because it uses an untouched kernel and untouched system partition. that may be "fixed" though by google)

I don't see any disadvantages to systemless root. But there are ways to not benefit of all of the advantages. The main one would be touching /system with any root app, and hence loosing the easier way to apply OTAs. (In reality it's a little more diverse: if you're on a device that shipped with 5.0 (like the N6), then even mounting /system writable is enough of a change. if you're on a device that shipped with <5 (like the N5), then you can actually do changes as long as you revert them back before applying the OTA, and even then only need to revet back the files the OTA cares about)

tl;dr: I'd go systemless. (It's really not a commitment. Going back from systemless is easy)
[SuperSU] stangri:
BTW, no issues with Android Pay with the systemless root and v78 of Xposed on my N6.
[SuperSU] natemup:
Is that to say that editing the build.prop or using Xposed will "break" systemless root and Android Pay will stop working?
[SuperSU] Alxoom33:
That was my experience with Xposed. Others have disagreed.
[SuperSU] Alxoom33:
Your install probably deleted the file. Just change permissions, reeboot and you will be good to go!
[SuperSU] nathanchance:
If you ran that second terminal command above, that prevents /su/xbin_bind from existing. It is not a problem. /su/xbin is expected to be there.
[SuperSU] lethang90b:
thanks. it works
[SuperSU] DroidForLife33:
I followed all the steps above after flashing superuser I don't have the app in the app tray. Can I just install it manually? And I also looked I still have a Superuser app in the data / superuser is that supposed to be there?
[SuperSU] nathanchance:
Are you on a ROM that places it in the Settings app?
[SuperSU] DroidForLife33:
No I'm running stock moto x Pure. I'm rooted but just doint see the app. I did see it in data/supersu.apk and data/su.img

I tried ap today and it works great. Thanks
[SuperSU] 1riddim:
Yeah tried this and cant get it to work with AP but my banking app works now with root which is nice ???? ????
[SuperSU] bouchigo:
I'm running viper4android and 751 with AP still working. You sure you installed the correct viper4android zip?
[SuperSU] ifwillems:
I flashed PON's zip file. Which V4A did you install? Do you have a link? Also, does this need to be installed before running UnSu and SuperSu?
[SuperSU] bouchigo:
I'm not sure if that zip is for systemless root or not. Anyway, here's the link: http://xdaforums.com/showpost.php?p=65099094&postcount=292

Flash it after you've setup systemless root, and installed busybox to either /su/bin or /su/xbin (preferably /su/xbin).
[SuperSU] ifwillems:
My phone hangs upon boot. Come to find out this is for Nexus 6P, but I have a Nexus 5X.
[SuperSU] bouchigo:
Yeah, it's for the Nexus 6P; it's in the file name so people wouldn't accidentally flash it on the 5X, or any other phone. You'd have to modify the cmdline text if you want it to work on the 5X.

I added one for the 5X, just go back to the thread link I previously posted if you still want to try it :good:

EDIT: I should have mentioned it instead of just assuming you had a 6P, sorry about that.
[SuperSU] luigidk:
This is your best v4a installer for most any device, root or no root http://xdaforums.com/nexus-6/themes-apps/viper4android-t2952137/page551
[SuperSU] ifwillems:
Thank you very much! This is awesome! I have it working now on Bullhead.
[SuperSU] Mircolino:
I did the "chmod 751" trick this morning and successfully used AP while rooted.

Now I just got an email from Wells Fargo that my AP credit card has been deactivated. Hmm, fishy.

I removed and re-added the card, we'll see tomorrow if it still works or Google already caught up.

Nexus 6P / MMB29Q / SU 2.67
[SuperSU] r80ies:
Crap I just used mine as well. Don't have wells fargo though. We'll see.
[SuperSU] aergern:
My wife is the primary on our BofA and she got notice that this same thing happened to my number in AP but when she read the numbers off sans the last 4 of the card .. they differed. Do they redo the tokens every so often if you haven't used the card via AP in a while? It made no sense that the card was removed but the virtual numbers didn't match at all.
[SuperSU] rebretz000:
I think there's a problem on Google's side with Android Pay. For almost a month they've had my CitiBank card block from being able to be added to AP. I called CitiBank a few times and they told me they haven't even gotten a request from Google to add the card to Android Pay since January. I was unrooted, stock, locked bootloader. Google has no idea why I can't add my card but they know the issue is on there side.
[SuperSU] clevebb:
Just waited on line at a store and realized I forgot my wallet. I'm a lot more bitter towards Google. Why did they disable the old google wallet? ?
[SuperSU] drewski_1:
Not all Citibank cards can be used. I have my Debit card in AP, but my American Airlines card can't be added.

There's a table in this link that gives specifics for each bank around what will or will-not work.

https://support.google.com/androidpay/answer/6314169?hl=en
[SuperSU] rebretz000:
I have a regular CitiBank Credit Card. Double Rewards or whatever it is. I had it added previously and used. I got a new 6P as the first was defective. Whenever I try to add the card I get an error saying that my card is already added to Android Pay and too many devices and must be removed. I have no other phone so I don't have AP anywhere else. Google has no idea what's going on and have been working on it for over two weeks.
[SuperSU] aergern:
Yeah, but my card is still in Android Pay. The "Virtual Account Number" that she read to me from the email .. the one for the entry that was "removed" .. is not the same as the one in Android Pay. I still haven't been anywhere that I can actually try it out. :/
[SuperSU] Alxoom33:
Yeah, my AA Advantage Citibank card also can't be added.
[SuperSU] Pig Vomit:
I am a fan of clean installs and so I had added my Costco Amex to my Nexus 5, and then my Nexus 6P, for a total of 5 times. So then I go to add it a 6th time, and I got an error saying Amex won't authorize it and to call them. So I call them, and I got a clueless rep who couldn't understand why I kept adding the card. I explained it was for the same phone, and he said his records show it was for two phone (the 5 and the 6P), and I told him he can take it off the 5 and I would delete the card from my profile and start over. He then panicked and said not to do that (I guess they really want me to be able to use the card as much as possible), but then he kept questioning me over and over regarding why I had to reinstall the card so many times on the same phone. I kept telling him that I did clean factory installs on my Nexus (Nex huh?). I then basically told him that I've tried to explain and since he's even admitted he's sure I'm the cardholder, it shouldn't matter why I'm doing it anyway, just authorize the damned add. He never did get it to work. So I did what I should have done in the first place......deleted the card from my Google profile, then added it again. And it worked.

The whole episode was very frustrating and took about 30 minutes.

On the bright side.....Android Pay is still working for me with the 751 mod on my rooted but otherwise stock phone. And since it's not getting a lot of discussion out there, hopefully Google will let it go. Because I don't really have a choice.....my ability to use AR Unchained Reloaded to mirror my phone to my car's Pioneer head unit trumps Android Pay any day of the week. I was well prepared to say goodbye to Android Pay for good. I'm glad I didn't have to. Just wish Google was giving me a Chromecast instead of 3 songs. My brother on last years 6 didn't get offered anything.
[SuperSU] rebretz000:
I just tried to add my BoA card and I got the Android system not compatible error. I have the 751 setup. Running XtraFactory w/Cata on my Nexus 6P

Just ran Safety Net also and it failed. Wonder if Google patch it already.
[SuperSU] elreydenj:
it is not patched.
[SuperSU] rebretz000:
SOB..... i change the SU/BIN to 715 not 751.

Dyslexia again strikes.
[SuperSU] bobby janow:
I see by removing it from Google Pay and re-adding it worked for you. Same thing happened to me a few weeks ago and I was transferred to a 2nd tier support person. He looked at the account and I told him I've been playing with roms and factory resets and image updates. He removed all the AP authorizations, also 5 just like you, and I was then able to add the card again. So I think Amex has a security feature that my other card doesn't have. I still can't get my main credit card in but that's a different issue. So as a heads up if anyone has this issue you might just want to avoid frustration and simply tell them to remove all the devices from your account, remove it from Google and re-add it. They'll see the authorization go through if they remain on the phone and you're done for another 5 tries.
[SuperSU] ifwillems:
I have the strange issue that AP used to work fine. But the last two days the AP app shows some hick ups: At the register, holding my phone close to the register gives the familiar vibration, but nothing happens: No recognition that a payment went through, nor a rejection. I ended up paying with a regular credit card.

I am not sure if this has anything to do with the upgrade of PureNexus. I dirty flashed the latest PN and GAPPS and redid UnSu, echo ... , SuperSu, Osm0sis' BusyBox, chmod 0751 to /su/bin and delete the xbin_bind directory. Should a clean flash resolve all this?
[SuperSU] ecossais:
You do not need to flash gapps on a dirty flash, and doing so often leads to problems. A clean flash will likely solve your problem. I successfully used AP yesterday after a dirty flash ( but I did not reflash gapps).
[SuperSU] Pig Vomit:
This is usually indicative of a NFC reader problem at the register. A significant percentage of retailer readers simply don't work right, and what you describe is what happens. I just used AP successfully this morning with the 751 mod (but only on rooted stock, not PureNexus). I have a couple of locations I know are reliable for working whenever I have a stretch of bad reads and begin to wonder whether it's been patched by Google.
[SuperSU] markwebb:
OK I did the same: dirty flash without gapps and now safety net fails ;(
[SuperSU] ecossais:
I think at this point a clean flash is your best option.
[SuperSU] jgummeson:
Just so everyone here knows - last week I created a simple flashable zip that makes the permissions change to get AP working with root, in case that's easier for some people than ADB or making the change from a file manager. I've attached it here for anyone who wants to try it. All it does is mount the su.img and then does the chmod. You can flash this anytime after you've installed SuperSU with the systemless setup without the xbin bind. These are the steps:

1. If you haven't rooted yet, make sure AP works. If it doesn't work before rooting it won't work after rooting with the permissions change.

2. Configure SuperSU for a systemless install without the xbin bind if you haven't already. From ADB or terminal run these commands :

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

3. Flash SuperSU and reboot

4. Flash UnSafetyNet.zip (or just boot up your phone and do the permissions change with a file explorer/ADB - the change from failing to passing should be immediate and doesn't require a reboot)

So far I've gotten reports that the .zip works on at least the 5x, 6, and 6p. It should work on others where SuperSU can install in systemless mode.
[SuperSU] markwebb:
I rerooted and used the new zip and now working without clean install!
[SuperSU] DROITURK182:
Just used the zip on a GPE M8 and it works thanks
[SuperSU] ecossais:
Glad to hear it.
[SuperSU] phraxen:
Hi there:

So I'm on a Droid Turbo, which is still stuck for the moment on Lollipop. Is there a method that works on the non-systemless SuperSU? Far as I know, systemless is only available on Marshmallow, but happy to be directed otherwise.

Thanks.
[SuperSU] corkiejp:
Latest SuperSU already chmod 0751 /su/bin, so should make it easier for Android Pay.
[SuperSU] spainter:
Flashed 2.68 on my Nexus 6 and 2013 Nexus 7 Deb via TWRP. No problems with update, and everything working. AP with mods in place works with no problem.
[SuperSU] rebretz000:
Question on adding these commands

Code:

echo SYSTEMLESS=true>>/data/.supersu

echo BINDSYSTEMXBIN=false>>/data/.supersu

When changing kernels and you have to either dirty flash ROM or flash stock boot.img, then flash SuperSU again then flash kernel.

Do I need to type these commends again or are these only needed on a clean ROM flash?
[SuperSU] Captain_Throwback:
It's probably helpful if you know what typing those commands is doing - then you'd have the answer to your question already ;).

Those commands are adding lines to the file /data/.supersu. If you look on your device in /data, you'll see the file there. If you open it and look at its contents, you'll see

SYSTEMLESS=true
BINDSYSTEMXBIN=false

If you look in the update-binary shell script in the SuperSU zip, you'll see that it looks for and reads the flags from that file prior to installing the zip so that it knows whether to override the automatic install options with what you've specified in the file.

So, that being said, that file will remain there unless you wipe /data. Does that answer your question?
[SuperSU] Alxoom33:
Thanks for the excellent explanation and insight.

Website signature