Android Pay use after rooting has been discussed in a few other threads, here on XDA, notably the 6P and 5X Nexi:
http://forum.xda-developers.com/nexus-6p/general/android-pay-root-t3309072
http://forum.xda-developers.com/nexus-5x/general/passing-safetynet-root-t3307659
With our newly rooted H830s (courtesy of http://forum.xda-developers.com/tmobile-lg-g5/development/root-h830-t3384526), it'd be nice to collect our information here.
I am very interested in how Android Pay may or may not work after our TOT flash. Here's a quick tutorial:
SuperSU must install via a 'systemless' root method due to security changes with Marshmallow. Thus, when SuperSU is flashed in TWRP as described in the TOT root thread, it can only install this way. It should not affect the /system partition.
Android Pay uses the "Safetynet API" to detect for tampering/root. What they classify as tampering is not entirely clear. But they do check /system among other things. It looks like apps that have altered the /system partition in some way are detected via this method.
(more boring info here http://www.howtogeek.com/241012/saf...y-and-other-apps-dont-work-on-rooted-devices/ )
It must also check the permissions of the /su/bin folder, as it should have a 751 permission profile (which is the described fix in the TOT root original post).
That is:
-Run "adb shell"
-From the shell run "su"
-On the # prompt run "chmod 751 /su/bin/"
Or, you can use root explorer to change the permissions octal to 751 for that folder.
It is set to this permission state in the rooted TOT upon first install. Obviously other root alterations you do may change it.
There are apps, such as Safetynet Helper sample (https://play.google.com/store/apps/details?id=com.scottyab.safetynet.sample), which can utilize the API to see if the API is tripped.
Right after installing the TOT and getting everything to boot properly, the app shows everything is still kosher. I was able to run Android Pay, add credit cards, and have confirmed with a payment transaction.
I believe any root app that doesn't make permanent changes to /system in and of itself will probably keep Android Pay working. Obviously, for instance, if you have a terminal program app with root, and run some commands that alter your system partition/files, it may trip SafetyNet, though just having the app installed does not.
EDIT1: As of 7/25/16, a change was made to the SafetyNet API and it now detects systemless root. Android Pay no longer works on rooted devices, regardless of method. A new method will need to be developed.
EDIT2: As of 8/22/16, a workaround has been developed and tested!Developer @topjohnwu has created Magisk (http://forum.xda-developers.com/android/software/mod-magisk-v1-universal-systemless-t3432382). This is a new way of integrating systemless changes into Android devices. This includes root, xposed, etc. The unique thing with Magisk is that you can instantly un-root your device, run Android Pay, and then reactivate root, all without rebooting. It is pretty seamless.
See the referenced thread for the latest information. It does take some work to install but it's fairly straightforward.
If you want to start from a clean install, @Gungrave223 has detailed the steps here:
http://forum.xda-developers.com/showpost.php?p=68353051&postcount=22
If you want to keep your data, it's just slightly more work. Assuming you are starting with a rooted install, here is a quick summary on how to do this:
0. You may want to first un-register the cards you have in Android Pay. Some banks apparently only allow a set # of installs before they block additional installs, thus requiring you to call the bank directly to have them reset that number. If Android Pay resets (unsure what security changes trigger this), it will forget your cards, thus leaving those cards registered on a phantom install. Un-registering first may prevent this.
1. Get the Magisk flashable zip, the Magisk-altered phh-superuser.zip, and the Magisk manager apk from the referenced thread.
2. Go to SuperSU and select full unroot. DO NOT restore the stock boot.img. DO NOT restore the default recovery. The phone should reboot and your root will be lost.
3. You should now restore the stock boot.img. This can be done without losing your data or re-encrypting your data. There are 2 ways.
Flash autoprime's stock boot.img zip file through TWRP (recommended), OR
Flash the TWRP-ed TOT file through LGUP, using the UPGRADE (not refurbish) setting
Why not just allow SuperSU to restore the stock boot.img in step 2? Because it will reboot instantly into system and start encrypting your data, with no way for you to intervene and boot into TWRP first!
4. You likely did not have data encryption on your initial rooted installation. If you want to keep yourself un-encrypted, you MUST immediately boot into TWRP before the next power on. If you do not, it will re-encrypt your data. This is the default behavior of the stock boot partition, which you just restored in the step above. You can make this easy for yourself by TWRP flashing autoprime's stock boot.zip and then immediately doing the next steps. Note: Magisk can be installed just fine on a phone with an encrypted data partition if you don't care about data encryption.
Flash the magisk.zip from the Magisk thread. This installs Magisk and also disables the forced encryption (just like the dm-verity zip)
Re-establish root by then flashing the special modified phh-superuser.zip
Note: Chainfire's SuperSU is NOT compatible if you want to use Android Pay
5. Reboot into system. You need to then install from the Playstore phh's superuser app. You also need to install the Magisk manager apk. Grant all your usual apps root permission in the superuser app.
6. Run Magisk Manager and grant it superuser access. You'll find a simple toggle to mount/unmount root. Unmount! Check that SafetyNet will pass. If you've done everything right, it will!
7. Run Android Pay. Add your card(s) back. Mount root back and go about your business.
8. When you want to use Android Pay, unmount root and run the app. Here's a tricky part (and currently a work in progress). We do not know how often or when Android Pay checks for root. We DO know that it does this when you initiate adding a new card. So you can try an Android Pay transaction. If it fails (they often do, even if you are unmounted root at that time), pretend to add a card, cancel it, and then do the transaction again. It should work now!
pay was not working after I installed the Fluence patch, uninstalled xposed and Android Pay is working with no issues with root.
fatapia said:
pay was not working after I installed the Fluence patch, uninstalled xposed and Android Pay is working with no issues with root.
Click to expand...
Click to collapse
The Fluence patch has a huge # of system changes. I would totally expect xposed to break the SafetyNet.
So do you have Fluence still installed, with only xposed removed?
waylo said:
The Fluence patch has a huge # of system changes. I would totally expect xposed to break the SafetyNet.
So do you have Fluence still installed, with only xposed removed?
Click to expand...
Click to collapse
Yup you got it, I had been running Xposed off Fluence for a while until I left my wallet at home and didn't feel like starving. So I downloaded the Xposed uninstaller only, ran it in recovery and then let it reboot and Pay was working again.
I followed the instructions for rooting in this thread, http://forum.xda-developers.com/tmo...p-step-guides-rooting-t-mobile-lg-g5-t3388272 and then the instructions here to change the permissions but an still having problems. The only app root app I installed after rooting was an app to export google play music with track names intact.
What problems specifically are you having?
Did you install the safetynet helper app? What happens when you run it?
What root app did you install? Was it this one? http://forum.xda-developers.com/showthread.php?t=2620331 (play music exporter) aka https://www.david-schulte.de/en/play-music-exporter/
Looks like that app doesn't work in MM regardless, per the developer's page.
waylo said:
What problems specifically are you having?
Did you install the safetynet helper app? What happens when you run it?
What root app did you install? Was it this one? http://forum.xda-developers.com/showthread.php?t=2620331 (play music exporter) aka https://www.david-schulte.de/en/play-music-exporter/
Looks like that app doesn't work in MM regardless, per the developer's page.
Click to expand...
Click to collapse
Yes, that is the app. I noticed MM was not supported after I had it installed
I have installed and run the safetynet app and it shows it gets tripped on the CTS profile
---------- Post added at 02:03 PM ---------- Previous post was at 01:40 PM ----------
I just realized I also had Adguard installed. I have uninstalled it and turned off suppersu and restarted but the phone still does not pass the CTS profile check
Wondering if any of those apps made some changes to /system that were not completely reversed.
Doesn't look like that music app does any permanent changes anyway, rather just copies cache not normally accessible into another folder.
Can you check the permission profile of your /su/bin folder?
Briefly looking at the Adguard website I can't make out how its root version works exactly.
What other apps are listed under your SuperSU app list? You're not running xposed, right?
Apps listed in supersu are adb shell, root checker basic, and Titanium backup.
Titanium backup was installed after safetynet app test failed.
I'm not 100% sure what the permissions are but I followed your instructions above to change the permissions and it appeared to run correctly
eremeya said:
Apps listed in supersu are adb shell, root checker basic, and Titanium backup.
Titanium backup was installed after safetynet app test failed.
I'm not 100% sure what the permissions are but I followed your instructions above to change the permissions and it appeared to run correctly
Click to expand...
Click to collapse
SafetyNet still failing after the permissions change?
It was today. I can try changing them again tonight when I'm at my computer and report back.
I have confirmed that the folder permissions are set to 751
eremeya said:
I have confirmed that the folder permissions are set to 751
Click to expand...
Click to collapse
Well if we can't track down the actual changes made, and you're interested in getting Android pay to work, you could try reflashing the system partition.
It looks like from reports on other threads (Nexus mostly), that something has changed with the SafetyNet check. Phones that were working just fine yesterday now fail. Most likely something server-side was patched so now Android Pay will not work with systemless root.
Details updated as I find them.
For those interested in this topic, a pretty major development has occurred at this thread:
http://forum.xda-developers.com/android/software/mod-magisk-v1-universal-systemless-t3432382
Essentially, this is a brand new way to implement root systemless, which can be toggled via an app, without rebooting. This does allow the SafetyNet api to remain untripped. The steps involved include flashing back to stock kernel/system, flashing the application .zips, and flashing special SuperSU or SuperUser .zips. I have not done any of this yet as it is still very early.
There are some reports, unfortunately, such as this post:
http://forum.xda-developers.com/showpost.php?p=68045722&postcount=121
which reports that despite SafetyNet passing, Android Pay still does not work (user is on Nexus 6P).
I have read of no G5 users doing this yet, but there is a V10 user who has. Stay tuned.
I've been watching the Magisk threads for the past week and decided to take the plunge today. Many Nexus phones seem to have a lot of trouble with Android Pay, but other makes seem to do better. There were confirmations from LG G4 owners. As of this writing Magisk is on v3.
The install steps from the Magisk thread are this:
1. Reflash a stock boot.img to reset your systemless root
2. Flash Magisk.zip
3. Flash modified phh-superuser.zip (not the official one). Chainfire's SuperSU does not currently have as much support, but there is a modified supersu zip as well.
4. Boot and install phh's superuser app from the App store.
5. A 'magisk manager' app is installed via the flashed .zips. This allows you to turn off root for a set # of minutes, without rebooting.
Given the unique way the G5 is rooted, with automatic encryption, I figured it might not be so simple to install this if I wanted to keep my data without a full wipe. It quickly became much more complicated than what I wanted. Here's exactly what happened.
First, I made a full boot+system+data backup.
Then, these were my thoughts/concerns:
I have Adaway installed with the systemless addon zip and SuperSU installed. Magisk installation requests flashing back the stock boot.img. What would this do to the supersu install and Adaway?
The adaway systemless zip makes a script file which is kept in the /su/su.d/ folder. I removed this.
The SuperSU has a complete uninstall feature. As part of this uninstall process, it asks if you want to restore the boot.img (yes--this stock one is backed-up after the initial supersu.zip flash during our initial root/TOT process) and/or the recovery (no, don't do this, but it probably would not have done anything as there is no stock recovery backup). I thought this would accomplish our goal. It does warn you that you may have re-encrypting of the data partition if you go this route.
And unfortunately, after rebooting, it automatically and immediately encrypted the data partition.
Well shoot. Correct me if I'm wrong, but an encrypted data partition cannot be worked on. It booted just fine, but without root.
I started having some doubts at this time so I decided to try to restore back to my initial setup. Through TWRP, I wiped the data partition and flashed the no-verity.zip, to hopefully stop any re-encryption.
Then, after figuring out how to mount system properly (TWRP defaulted to mount system as r/o), I restored my nandroid backup in its entirety.
But upon reboot, it went immediately into bootloader mode. And it continued to do this after every battery pull and power on. I had never heard of this before! Finally, I realized I could still boot into TWRP. I flashed the 10Dcomplete.zip made by autoprime, restoring the boot and system partitions to stock. And then I flashed the magisk v3.zip and the modified phh-superuser zip.
It finally rebooted into Android, with data intact! Oddly, my unlock pattern had changed without my knowledge, but the backup PIN worked. I installed the market phh Superuser. Magisk is installed properly and it passes SafetyNet, and I can add cards to the app. I'll test out Android Pay next opportunity I have.
If I had to do it all again and wanted to keep data intact, this is what I would do.
1. Autoprime did make a 10D boot flashable zip. So this would restore the stock boot.img as intended. There are some files to clean up, such as data/su.img, but that can be dealt with later.
2. I do not know if just flashing the stock boot.img would result in re-encrypting. It probably would. So, immediately after flashing the boot.img in TWRP I would flash magisk and the phh-superuser.
Alternatively, they say you should not dirty flash for things this complex. So consider starting completely new from a 10Dcomplete flash with wiped data.
I've learned that Magisk will work fine with an encrypted data partition, so if you are set on having that, it won't be a problem.
waylo said:
I have a thread here discussing Android Pay while rooted on our G5s:
http://forum.xda-developers.com/tmob...le-g5-t3395036
I thought I was the only one who cared about this kind of stuff!
Which version Magisk did you install?
I just did this 2 days ago but haven't had the opportunity to test AP yet.
What rooted apps are you running? AdAway?
Click to expand...
Click to collapse
To answer your question... I'm using v3 with his v2 of his modified phh superuser.
As for rooted apps...yes AdAways still works perfectly....TB...my one time use of System App Remover etc...
I haven't been able to test Android util tomorrow....but SafetyNet did pass when Magisk was disabled and failed when enabled.
I'll report back tomorrow after I go buy my weekly chicken at my local Fresh Mart.
I'm using the same install as you.
I tried it this AM for the first time and it failed.
On the Magisk-AP thread, someone has posited that maybe the AP app caches any root inquires during that boot. So if you test out AP and it fails while the root is active, it will remember that failure until the next reboot.
That could explain how so many people are getting weird inconsistent results. I'm testing out that theory later today.
Bah, still doesn't work, even if done immediately after a reboot =(
Lately it seems more and more developers are relying on safetynet for apps and features (especially google, i REALLY miss getting surveys with opinion rewards :[ )
So I'm curious if anyone has an idea what currently triggers a failed response.
Does busybox fail?
Does selinux need to be enforcing?
Does system status need to be "official"
Etc.
Lastly, bonus question:
Are there any custom kernels for g920p that don't auto root and install busybox?
It is fairly complex.
1) https://developer.android.com/training/safetynet/index.html
"SafetyNet examines software and hardware information on the device where your app is installed to create a profile of that device. The service then attempts to find this same profile within a list of device models that have passed Android compatibility testing. "
2) https://www.howtogeek.com/241012/sa...y-and-other-apps-dont-work-on-rooted-devices/
"Google uses something called SafetyNet to detect whether your device is rooted or not, and blocks access to those features. Google isn’t the only one, either–plenty of third-party apps also won’t work on rooted Android devices, although they may check for the presence of root in other ways."
You may already know this from the other thread regarding Magisk, but my suggestion is to return to stock via Odin, then follow the instructions from the Magisk thread here: https://forum.xda-developers.com/apps/magisk/official-magisk-v7-universal-systemless-t3473445
koop1955 said:
It is fairly complex.
1) https://developer.android.com/training/safetynet/index.html
"SafetyNet examines software and hardware information on the device where your app is installed to create a profile of that device. The service then attempts to find this same profile within a list of device models that have passed Android compatibility testing. "
2) https://www.howtogeek.com/241012/sa...y-and-other-apps-dont-work-on-rooted-devices/
"Google uses something called SafetyNet to detect whether your device is rooted or not, and blocks access to those features. Google isn’t the only one, either–plenty of third-party apps also won’t work on rooted Android devices, although they may check for the presence of root in other ways."
You may already know this from the other thread regarding Magisk, but my suggestion is to return to stock via Odin, then follow the instructions from the Magisk thread here: https://forum.xda-developers.com/apps/magisk/official-magisk-v7-universal-systemless-t3473445
Click to expand...
Click to collapse
Thanks for chiming in!
Dang there's a lot going on, i guess google is being pretty tight lipped about exactly what info they use.
But yea, at the moment I'm completely stock with magisksu and magisk v11.1
The issue is that magisk has to be re-installed after every boot, meaning there are a few minutes where safetynet and gms have the opportunity to see my root before i re-install magisk. (From what i gather from the magisk op thread, this could be fixed with a custom kernel... tested succesfully with skyhigh, but then failed safetynet and i don't know why.)
The other issue with the magisk set-up on complete stock is that Titanium backup and some other root-related apps seem to be almost entirely broken. Magisk OP thread sheds some light about that, something about system needing to mounted as rw (which I'm unable to change, since root hardly works at all)... a couple weeks ago the magisk dev said he was going to work on a fix for that, but I'm not banking on it.
So to summarize, I'm trying to figure out how to run a custom kernel (or even rom if possible) without failing safetynet... because even if i flash skyhigh on stock, Uninstall busybox, set se linux to enforced, uninstall supersu, and wipe davlik i still fail safetynet.
Or I'm i just too greedy wanting the freedom of root AND the comfort of stock behavior? (android pay, google opinion rewards, consistent play service function and updates etc)
I would guess that a custom kernel alone (no SuperSU or BusyBox) would cause a failure. It seems like any kernel mod would do so.
Magisk is an attempt to solve this, but doesn't seem quite there.
koop1955 said:
I would guess that a custom kernel alone (no SuperSU or BusyBox) would cause a failure. It seems like any kernel mod would do so.
Magisk is an attempt to solve this, but doesn't seem quite there.
Click to expand...
Click to collapse
I'd believe that, i guess that'd really be the obvious first step in profiling a device's environment.
Given that I'm guessing it'd just check the system info, all the info on the about device page in settings and compare it to which kernel i should have.
So in the interest of crawling deeper down this rabbit hole, I'm going to see what can be done to mock that info >
Also in defense of magisk, from what i gather, magisk is an extremely effective hands-off root solution... unless you have a samsung device.
@Nye-uhls, you should definitely check this out: https://forum.xda-developers.com/showpost.php?p=71398440&postcount=342
New kernel with built-in Magisk support.
koop1955 said:
@Nye-uhls, you should definitely check this out: https://forum.xda-developers.com/showpost.php?p=71398440&postcount=342
New kernel with built-in Magisk support.
Click to expand...
Click to collapse
Thats huge. I'm officially no longer putting effort into getting magisk working in anticipation of that new kernel.
Thank you for the heads up, probably wouldve kept sweating over this for a few more days lol.
As far as I understand it many banking apps simply check for the existance of supersu.apk, and if found denies access. Is it correct that by using another method to getting root, this problem might be solved? And if so, which alternatives are there (can Magisk be used on a OP3)?
snegom said:
As far as I understand it many banking apps simply check for the existance of supersu.apk, and if found denies access. Is it correct that by using another method to getting root, this problem might be solved? And if so, which alternatives are there (can Magisk be used on a OP3)?
Click to expand...
Click to collapse
Yes it can be done (I can use banking apps and Android Pay on my OP3).
1. Disable any in-built root/remove exisiting SuperSU.
2. Flash Magisk
3. Install Magisk Manager
4. Enable Magisk Hide
5. Try app - If it still doens't work go back onto Magisk Hide and enable it on that specific app by pressing the checkbox and it should work. (Try rebooting if it doesn't work)
6. If possible turn off devloper options/ADB options in settings as these can stop banking apps from working.
I hope this helps
I confirm magisk is legit and fantastic!!!
Sent from my OnePlus 3 using XDA Labs
Magisk works perfectly for all the apps which checks for the SAFETYNET......some apps need not be hided using magisk hide ...just bypassing the safetynet is enough for A-pay and banking apps ...
check this thread out:
https://forum.xda-developers.com/apps/magisk/official-magisk-v7-universal-systemless-t3473445
byAidan said:
Yes it can be done (I can use banking apps and Android Pay on my OP3).
1. Disable any in-built root/remove exisiting SuperSU.
2. Flash Magisk
3. Install Magisk Manager
4. Enable Magisk Hide
5. Try app - If it still doens't work go back onto Magisk Hide and enable it on that specific app by pressing the checkbox and it should work. (Try rebooting if it doesn't work)
6. If possible turn off devloper options/ADB options in settings as these can stop banking apps from working.
I hope this helps
Click to expand...
Click to collapse
Had this as a small project for this Easter. However for 1) above, is it as simple as just running "Change superuser app" in SuperSU free before proceeding with 2-6) ? Have seen some rather complicated install instructions elsewhere - and can also see that some users have experienced various problems.
snegom said:
Had this as a small project for this Easter. However for 1) above, is it as simple as just running "Change superuser app" in SuperSU free before proceeding with 2-6) ? Have seen some rather complicated install instructions elsewhere - and can also see that some users have experienced various problems.
Click to expand...
Click to collapse
The only way I could completely remove SuperSU was to dirty flash OOS. Otherwise safety net still detected SuperSU. Rooted with magisk and used magisk hide. Can now play Mario run and used Android pay.
So, I'm looking around, and I can't find any up to date information on rooting using SuperSU, only this new thing (to me) called Magisk.
So, my questions are:
1. What EXACTLY is Magicsk?
2. What makes it better than SuperSU that's been around, tried & true, for forever?
3. Why does it seem that everyone is so hyped about Magisk?
So basically consider this the ultimate newbie thread on Magisk. To summarize, SuperSU has been around forever, why should I care about this Magisk thing?
Thanks!
1. Magisk is a superuser app that gives you root obviously, it also has modules you can install kind of like exposed.
2. Chainfire the creator of SuperSu has been retired for a while now, so everyone jumped ship and went to Magisk.
3. Magisk is actually a really good app and has a lot of cool modules on it.
Try it out it's really nice to have and does the same job SuperSu does plus more. I still give my respect to Chainfire as he is one of the greatest.
Magisk let's you hide root also
DR3W5K1 said:
Magisk let's you hide root also
Click to expand...
Click to collapse
SuperSu had SuHide also, so they both could be hidden lol.
loeffler23 said:
SuperSu had SuHide also, so they both could be hidden lol.
Click to expand...
Click to collapse
So true it works out of the box just like magisk too....
supersu 2.82 sr5 is the latest revision of supersu and is incompatible with the pixel xl ever since the january update. when Chainfire retired from supersu development, he handed it over to a company, ccmt, to take over. they've been radio silent; no posts in the supersu forum nor any new updates to supersu. it seems like development on supersu has stalled or is dead, which is sad. Chainfire put a lot of work into supersu.
the only other root option available for the pixel xl is magisk. i was a long time user of supersu, but switched over to magisk. it's been working fine for me.
Yeah I stayed on the SuperSU camp for as long as I can remember too but since last 3-4 months almost every dev has suggested to switch to Magisk and so I did and I don't regret it for a second. And I don't even use any modules at all.
I was in your exact position, and didn't actually learn what magisk or start using it until 3ish months ago. And I've been around since Motorola Droid.
I say give it a flash and try it, mess around, have fun. They have an uninstaller script you can always return to stock.
Magisk, besides root access, has expandable modules. There's even a subsection in xda dedicated to modules.
My favorite modules are.....
Busybox for Android
Modded pixel 2 launcher
Unified adblock host (if I'm not using adaway)
Hide nav bar (when using lmt for pie controls)
Injected YouTube Vanced
And many more.
Look at it kind of like xposed (please don't bash me, I know it's no where near the same but this is for correlation sake)
You have lists of different modules to install.