Database Develop

One workaround for 'assert failed' during CM install

Error message during failed install of CM zip: assert failed: get prop ("ro.product.device") == "ovation" || get prop ("ro.build.product") = ="ovation"
Solved: See below.
When I first got my HD+, I did an SD "install" of CM 11. Then I installed CM 11 to the emmc, via CWM, per all the instructions on the xda website.
Once CM 11 was installed, I changed to TWRP 2.6.3.0. (I like being able to name the backups.)
Then I did a wipe and dropped down to CM 10.2.1. (More stable.) I did the install from TWRP.
Then I installed the fuzz kernel from TWRP.
Last, I updated to TWRP 2.6.3.0a when I couldn't get Succulent's CM 11 to install.
Okay, so tonight I wanted to do a clean install of CM 10.2.1, without gapps this time.
So I booted to recovery, did a wipe, and tried installing CM 10.2.1.(The build came direct from Cyanogen mod's website for the Ovation.)
I get an error similar to what I got when I tried to install Succulent's CM 11. Here's the error message:
assert failed: get prop ("ro.product.device") == "ovation" || get prop ("ro.build.product") = ="ovation"
I dropped back to CWM and tried installing the ROM from three different versions: CWM 6.0.4.5, 6.0.4.5b, and CWM 6.0.4.6.
I tried installing CM 10.2.1 from the internal and the external SD card.
No joy. Fortunately, a Nandroid backup beforehand and I've restored to where I was.
Any ideas what's wrong? It shouldn't be this hard. It doesn't seem that a ROM install should be Recovery Dependent . But maybe it is?
==========
Solved. leapinlar, in the thread where I originally posted this question, said to use an older version of CWM to install. Apparently some incompatibility between versions of CWM (and TWRP) and the ROM zip.
Another solution was alluded to by King200 in another forum, but it sounded arcane and hard to do. It wasn't.
Here are Windows instructions:
++++++++++
Note: This method removes the "sanity check" built into the recovery image which checks to make sure the ROM you're installing is compatible with your tablet. Obviously, flashing the wrong ROM can/will brick your tablet.
So be warned.
Since I only have one tablet that I flash CM 10.2.1 on, no problem for me. If you have more than one tablet, perhaps you should delete your hacked zip after you install, to be safe.
Okay?
But for educational purposes, here's what I did to work around the problem.
++++++++++
You do this with 7-Zip. (So install 7-Zip if you don't have it already.)
Right click on the ROM that you're trying to install.
A 7-Zip context menu opens.
Select "Open Archive."
Drill your way down to
/META-INF/com/google/android/updater-script
Right click on the updater-script and select "Edit."
Open updater-script with Notepad.
Delete the first line of code, all the way up to the first semicolon. And delete the first semi-colon as well.
Save the edited file in Notepad. You'll get a 7-zip message asking if you want to incorporate your changes back into the archive. "Yes."
Now the ROM will install with later versions of CWM or TWRP.
Note: I had to do with this with the "fuzz" kernel too.
P.S. I don't know how to read code, so I don't understand exactly what the problem here is. I peeked at the scripts. I have an "ovation" tablet. Both the ROM and the Recovery image mention "ovation" in their updater scripts. Seems like they ought to talk to each other.

Please don't do this procedure. It is dangerous. It could brick your device. And the issue is not whether you have more than one tablet, it is if you accidentally download a hummingbird (HD) zip when you have an ovation (HD+) and try to flash it to an HD+. If you remove that assert statement the HD zip will merrily install to an HD+. And you will have a real mess.
A real case happened where a Nook Color user tried to flash a Nook Tablet ROM to his Color. The assert statement which was designed to prevent that did its job and prevented it. However, another user recommended he remove the assert statement, which he did, and thus flashed the Tablet ROM to his Color. His Color ended up bricked.
NEVER REMOVE AN ASSERT STATEMENT!
There are two more safe procedures.
One, use an older version of CWM to flash the older zips.
Two, do as the procedure says by opening the archive, but don't edit the updater-script file to remove the assert line. Look in a newer zip like CM11 and extract the file 'update-binary' and copy it to the old zip replacing the old update-binary file there. Then the old zip is flashable with the newer CWM/TWRP recoveries.
Sent from my BN NookHD+ using XDA Premium HD app

Patch LRX22C?

This may very well be a foolish question, but I'll ask anyway.
My wife and I both have Nexus 6 devices. I have unlocked, rooted and installed TWRP on both.
On mine, I just installed the Pure Nexus ROM; after trying a couple other custom ROMs.
However, my wife's phone is still running LRX22C (5.0.1); and I'd like to update to the latest 5.1.1.
So what is the problem, you may ask...
She has a lot of work stuff on the phone, she loves the phone, but to use it at work, she needs to accept the security policies from their IT dept and mandatory encryption (plus they pay most of the monthly invoice).
I just want to confirm that it would be ok to dirty flash LYZ28J (5.1.1 TMO stagefright fix) from the available zips in this post:
http://forum.xda-developers.com/nexus-6/development/fxz-nexus-6-recovery-flashable-fastboot-t3066052
I just don't want to end up sleeping in the bathtub if anything were to happen to her data or settings.
Thanks in advance

poodleDoo said:
This may very well be a foolish question, but I'll ask anyway.
My wife and I both have Nexus 6 devices. I have unlocked, rooted and installed TWRP on both.
On mine, I just installed the Pure Nexus ROM; after trying a couple other custom ROMs.
However, my wife's phone is still running LRX22C (5.0.1); and I'd like to update to the latest 5.1.1.
So what is the problem, you may ask...
She has a lot of work stuff on the phone, she loves the phone, but to use it at work, she needs to accept the security policies from their IT dept and mandatory encryption (plus they pay most of the monthly invoice).
I just want to confirm that it would be ok to dirty flash LYZ28J (5.1.1 TMO stagefright fix) from the available zips in this post:
http://forum.xda-developers.com/nexus-6/development/fxz-nexus-6-recovery-flashable-fastboot-t3066052
I just don't want to end up sleeping in the bathtub if anything were to happen to her data or settings.
Thanks in advance
Click to expand...
Click to collapse
Here's what I would do:
Back up all the important stuff to PC.
Unlock her bootloader and flash the entire factory image for the latest build. Then transfer the backup back to the phone.
Otherwise you can sideload OTA's but it will take much longer.

The_Merovingian said:
Here's what I would do:
Back up all the important stuff to PC.
Unlock her bootloader and flash the entire factory image for the latest build. Then transfer the backup back to the phone.
Otherwise you can sideload OTA's but it will take much longer.
Click to expand...
Click to collapse
Nope. Can't sideload OTA since the phone's not stock (root and TWRP).
What I would do is to backup everything (nandroid in TWRP) and then fastboot flash the factory image, leaving out userdata.img and recovery.img. I'd also take the opportunity to flash the latest TWRP. You'll loose root doing this, but just enter TWRP before booting (you need to do this anyway so that your recovery won't get overwritten) and it should ask you if you want to root when you reboot.
No data lost this way.

Didgeridoohan said:
Nope. Can't sideload OTA since the phone's not stock (root and TWRP).
What I would do is to backup everything (nandroid in TWRP) and then fastboot flash the factory image, leaving out userdata.img and recovery.img. I'd also take the opportunity to flash the latest TWRP. You'll loose root doing this, but just enter TWRP before booting (you need to do this anyway so that your recovery won't get overwritten) and it should ask you if you want to root when you reboot.
No data lost this way.
Click to expand...
Click to collapse
That sounds easy enough...
Nandroid backup
fastboot system.img
fastboot boot. img
fastboot latest twrp recovery
fastboot bootloader
fastboot cache
fastboot radio
boot recovery and have TWRP ask about root
Reboot
Does that sound right?
Thanks (used the Thx button for both of you guys).

Looking at the updater script in the zip file, this is what I see; so cna I just flash the zip from TWRP?
Sorry for keeping asking questions...
Code:
getprop("ro.product.device") == "shamu" || abort("This package is for \"shamu\" devices; this is a \"" + getprop("ro.product.device") + "\".");
ui_print("Writing logo ...");
package_extract_file("logo.bin", "/dev/block/platform/msm_sdcc.1/by-name/logo");
ui_print("Writing boot ...");
package_extract_file("boot.img", "/dev/block/platform/msm_sdcc.1/by-name/boot");
ui_print("Writing system ...");
block_image_update("/dev/block/platform/msm_sdcc.1/by-name/system", package_extract_file("system.transfer.list"), "system.new.dat", "system.patch.dat");
ui_print("Erasing cache ...");
delete_recursive("/cache");
ui_print("Erasing oem ...");
package_extract_file("oem.img", "/dev/block/platform/msm_sdcc.1/by-name/oem");
The contents of the zip are:
META-INF -> com -> google -> android (update-binary & updater-script)
system.new.dat
system.patch.dat
boot.img
oem.img
file_contexts
system.transfer.list
logo.bin
Thanks again

Don't forget to flash bootloader, cache and radio as well... They're kind of important.
---------- Post added at 19:00 ---------- Previous post was at 18:54 ----------
poodleDoo said:
Looking at the updater script in the zip file, this is what I see; so cna I just flash the zip from TWRP?
Sorry for keeping asking questions...
Code:
getprop("ro.product.device") == "shamu" || abort("This package is for \"shamu\" devices; this is a \"" + getprop("ro.product.device") + "\".");
ui_print("Writing logo ...");
package_extract_file("logo.bin", "/dev/block/platform/msm_sdcc.1/by-name/logo");
ui_print("Writing boot ...");
package_extract_file("boot.img", "/dev/block/platform/msm_sdcc.1/by-name/boot");
ui_print("Writing system ...");
block_image_update("/dev/block/platform/msm_sdcc.1/by-name/system", package_extract_file("system.transfer.list"), "system.new.dat", "system.patch.dat");
ui_print("Erasing cache ...");
delete_recursive("/cache");
ui_print("Erasing oem ...");
package_extract_file("oem.img", "/dev/block/platform/msm_sdcc.1/by-name/oem");
The contents of the zip are:
META-INF -> com -> google -> android (update-binary & updater-script)
system.new.dat
system.patch.dat
boot.img
oem.img
file_contexts
system.transfer.list
logo.bin
Thanks again
Click to expand...
Click to collapse
What zip are you talking about? An OTA update.zip? That won't work, since you're not stock...
I'm talking about the factory images from here:
https://developers.google.com/android/nexus/images?hl=en

What zip are you talking about? An OTA update.zip? That won't work, since you're not stock...
I'm talking about the factory images from here:
https://developers.google.com/android/nexus/images?hl=en
Click to expand...
Click to collapse
I'm talking about these:
http://forum.xda-developers.com/nexus-6/development/fxz-nexus-6-recovery-flashable-fastboot-t3066052
[FXZ][OTA] Nexus 6 Recovery Flashable Fastboot Files (Unlocked Bootloader Only)

poodleDoo said:
[/COLOR]
What zip are you talking about? An OTA update.zip? That won't work, since you're not stock...
I'm talking about the factory images from here:
https://developers.google.com/android/nexus/images?hl=en
Click to expand...
Click to collapse
I'm talking about these:
http://forum.xda-developers.com/nexus-6/development/fxz-nexus-6-recovery-flashable-fastboot-t3066052
[FXZ][OTA] Nexus 6 Recovery Flashable Fastboot Files (Unlocked Bootloader Only)[/QUOTE]
As it says as long as you are unlocked with TWRP. Just flash the whole zip in TWRP. Still better off fastboot the full factory images. If locked and it fails you in for a butt full of hurt.

Needed: stock "install-recovery.sh"

can someone please upload the stock "install-recovery.sh"?
It's located in /system/etc.
I forgot to backup it, while rooting the device.
I need it for the OTA updates.
thanks

@vel_tins
Do not flash the ota if you are rooted, you might get bootloop. Full unroot your device before attempting to update. Anyhow, the ota will most likely fail since you already modified your system partition. Your best option is to unroot your device and capture the ota link, modify the ota updater-script and remove the lines that are showing "unexpected contents" errors. The original "install-recovery.sh" is still there, supersu renamed it to something like "/system/etc/install-recovery_original.sh". Keep in mind, you might loose your custom recovery if you renamed it back to "install-recovery.sh".

Well, OTA was a pain in the a**.
Because I had no stock "install-recovery.sh", I've edited the updater-script and removed all the matching entries.
Executed a full un-root.
Tried to flash the modified update.zip via TWRP, but failed because TWRP couldn't mount partitions with this name scheme:
Code:
"/dev/block/platform/[B]7824900.sdhci/by-name/system[/B]", "/system",
(will investigate later, any ideas?)
Because too lazy to modify the updater-script again,
I've booted into fastboot and loaded my "modded" stock recovery, which accepts also self-signed .zips.
Flashing worked well, but on reboot, I got a nice bootloop because of the formerly installed Xposed framework.
Had to restore from a Nandroid Backup and after reboot, I removed Xposed completely.
Eventually, I was able to flash the OTA and got back a working device...
Gosh...

^^
??

vel_tins said:
Well, OTA was a pain in the a**.
Because I had no stock "install-recovery.sh", I've edited the updater-script and removed all the matching entries.
Executed a full un-root.
Tried to flash the modified update.zip via TWRP, but failed because TWRP couldn't mount partitions with this name scheme:
Code:
"/dev/block/platform/[B]7824900.sdhci/by-name/system[/B]", "/system",
(will investigate later, any ideas?)
Because too lazy to modify the updater-script again,
I've booted into fastboot and loaded my "modded" stock recovery, which accepts also self-signed .zips.
Flashing worked well, but on reboot, I got a nice bootloop because of the formerly installed Xposed framework.
Had to restore from a Nandroid Backup and after reboot, I removed Xposed completely.
Eventually, I was able to flash the OTA and got back a working device...
Gosh...
Click to expand...
Click to collapse
If you still have the original OTA zip, can you please post it for future reference?
As for TWRP mounting /dev/block/platform/7824900.sdhci/by-name/system, what error message did you get? Try running "ls -l /dev/block/platform/7824900.sdhci/by-name/" in both normal Android and TWRP, then compare the results.

pawitp said:
If you still have the original OTA zip, can you please post it for future reference?
Click to expand...
Click to collapse
No problem
pawitp said:
As for TWRP mounting /dev/block/platform/7824900.sdhci/by-name/system, what error message did you get? Try running "ls -l /dev/block/platform/7824900.sdhci/by-name/" in both normal Android and TWRP, then compare the results.
Click to expand...
Click to collapse
Stock and Cyanogen recovery are working with this partition naming scheme.
But in TWRP, I get the following error message:
Code:
ls: /dev/block/platform/7824900.sdhci/by-name: No such file or directory
For TWRP I have to use the following syntax in recovery.fstab:
Code:
/cache ext4 /dev/block/mmcblk0p29
/system ext4 /dev/block/mmcblk0p25
/data ext4 /dev/block/mmcblk0p31 length=-16384
.........etc.

vel_tins said:
No problem
Stock and Cyanogen recovery are working with this partition naming scheme.
But in TWRP, I get the following error message:
Code:
ls: /dev/block/platform/7824900.sdhci/by-name: No such file or directory
For TWRP I have to use the following syntax in recovery.fstab:
Code:
/cache ext4 /dev/block/mmcblk0p29
/system ext4 /dev/block/mmcblk0p25
/data ext4 /dev/block/mmcblk0p31 length=-16384
.........etc.
Click to expand...
Click to collapse
On TWRP, try running "find /dev/block/platform" and see if anything is created there.
The directory should have been populated by init. See https://android.googlesource.com/pl...0ab94b7d5a888f0b6920b156e5c6a075fa0741a^!/#F0.
That code should also be in TWRP, but something might have prevented it from working properly on this device. You might find some clues in dmesg or TWRP's logs.

Well, eventually I've got it.
In TWRP, the naming is a little bit different from stock or Cyanogen recovery.
I had to change:
Code:
/dev/block/platform/[COLOR="Red"]7824900.sdhci[/COLOR]/by-name/cache <--- STOCK
to
/dev/block/platform/[COLOR="Blue"]soc.0[/COLOR]/by-name/cache <--- TWRP
However, the "/dev/block/mmcblk0p" naming worked also in TWRP, so this was only a minor issue.

vel_tins said:
Well, eventually I've got it.
In TWRP, the naming is a little bit different from stock or Cyanogen recovery.
I had to change:
Code:
/dev/block/platform/[COLOR="Red"]7824900.sdhci[/COLOR]/by-name/cache <--- STOCK
to
/dev/block/platform/[COLOR="Blue"]soc.0[/COLOR]/by-name/cache <--- TWRP
However, the "/dev/block/mmcblk0p" naming worked also in TWRP, so this was only a minor issue.
Click to expand...
Click to collapse
IMO, you should fix TWRP so that it has the same naming convention. Otherwise OTA packages using the "stock" naming convention can't be flashed on TWRP.
Personally, I prefer the "by-name" mapping rather than the "/dev/block/mmcblk0p" because it is harder to make mistakes if you use a name. With numbers, if a wrong number is typed, then you might end up flashing the wrong partition and bricking the device.
EDIT: It might have something to do with the "system/core" repository you've used to build your recovery. Which Android tree did you use to build Cyanogen Recovery and which one did you use to build TWRP?

vel_tins said:
Well, OTA was a pain in the a**.
Because I had no stock "install-recovery.sh", I've edited the updater-script and removed all the matching entries.
Executed a full un-root.
Tried to flash the modified update.zip via TWRP, but failed because TWRP couldn't mount partitions with this name scheme:
Code:
"/dev/block/platform/[B]7824900.sdhci/by-name/system[/B]", "/system",
(will investigate later, any ideas?)
Because too lazy to modify the updater-script again,
I've booted into fastboot and loaded my "modded" stock recovery, which accepts also self-signed .zips.
Flashing worked well, but on reboot, I got a nice bootloop because of the formerly installed Xposed framework.
Had to restore from a Nandroid Backup and after reboot, I removed Xposed completely.
Eventually, I was able to flash the OTA and got back a working device...
Gosh...
Click to expand...
Click to collapse
Hi sir ,
Please share to us , how you do this , because I have status 7. Install-recovery.sh problem
I have stock recovery , and I'm only make a root for my device by kingroot .
Please share update.zip file and tel me how to make ota update

pawitp said:
IMO, you should fix TWRP so that it has the same naming convention. Otherwise OTA packages using the "stock" naming convention can't be flashed on TWRP.
Click to expand...
Click to collapse
Exactly this is the point...
pawitp said:
EDIT: It might have something to do with the "system/core" repository you've used to build your recovery. Which Android tree did you use to build Cyanogen Recovery and which one did you use to build TWRP?
Click to expand...
Click to collapse
I have to correct myself, Cyanogen has exactly the same problem.
I've used the latest CM 12.1 and Omnirom source trees to build TWRP, but with the same result.
TWRP/Cyanogen only detects "soc.0" instead of "7824900.sdhci" and that will break compatibility with OTA packages (Until you patch "updater-script").

So how you made this ota update after all ?

theeteempire said:
So how you made this ota update after all ?
Click to expand...
Click to collapse
OTA doesn't work with rooted devices.
Do a full un-root and try again.

vel_tins said:
OTA doesn't work with rooted devices.
Do a full un-root and try again.
Click to expand...
Click to collapse
I did it , full unroot , I couldn't update even that with full-unroot , I used kingroot for root ,
Also error status 7 , install-recovery. Sh shown on the update after full-unroot my device !!!
can you help me please !!!!!

theeteempire said:
....I used kingroot for root ,
Also error status 7 , install-recovery. Sh shown on the update after full-unroot my device...
Click to expand...
Click to collapse
I would strongly suggest, to open an new thread, because I guess a lot more people will or had run into these issues.
I don't know what Kingsoft (never used it) has modified/replaced, so in your case I would search for a stock "install-recovery.sh" and replace the modified.
Everything else would be too complicated. (You have read my post on the first page).

vel_tins said:
I would strongly suggest, to open an new thread, because I guess a lot more people will or had run into these issues.
I don't know what Kingsoft (never used it) has modified/replaced, so in your case I would search for a stock "install-recovery.sh" and replace the modified.
Everything else would be too complicated. (You have read my post on the first page).
Click to expand...
Click to collapse
So I need the stock install-recovery. Sh ,.
Are you have it ?

vel_tins said:
Exactly this is the point...
I have to correct myself, Cyanogen has exactly the same problem.
I've used the latest CM 12.1 and Omnirom source trees to build TWRP, but with the same result.
TWRP/Cyanogen only detects "soc.0" instead of "7824900.sdhci" and that will break compatibility with OTA packages (Until you patch "updater-script").
Click to expand...
Click to collapse
This is just a guess. Try adding "TARGET_PLATFORM_DEVICE_BASE := /devices/soc.0/" to BoardConfig.mk.
If you know C, you might want to try mucking around in system/core/init/devices.c and see why it's behaving that way.

pawitp said:
This is just a guess. Try adding "TARGET_PLATFORM_DEVICE_BASE := /devices/soc.0/" to BoardConfig.mk.
.....
Click to expand...
Click to collapse
Seems to work, thanks!
PS: A google search for "TARGET_PLATFORM_DEVICE_BASE" threw only six results, so it doesn't seem to be a very popular flag.

vel_tins said:
Seems to work, thanks!
PS: A google search for "TARGET_PLATFORM_DEVICE_BASE" threw only six results, so it doesn't seem to be a very popular flag.
Click to expand...
Click to collapse
From my experience, you can't rely too much on Google for ROM development. I've found the flag by reading the source file I've previously mentioned.
Sent from my Nexus 4 using XDA Free mobile app

How to re-soft the tablet?

As that subject mentions, I was wondering if someone could please provide me with a step by step guide on how to completely re-soft my Asus Memo Pad 7 ME176CX. I'd like to reinstall Lollipop from scratch because after I rooted it long time ago and also messed with some stuff/took out apps,etc. , now I can't install any updates. So I'd like everything to be back to the way it was before messing up stuff/rooting. I'd appreciate the help

I would assume you need to unroot the device first. Most root programs will have a removal tool as well. After that, you should be able to go into settings - backup and reset and then reset from there, provided you did not install a custom Rom.

If you are already in lollipop, i sugest downloading on asus me176c support website version WW .36, after that extract and go to meta-inf and look for updater script and remove 1st line and repack everything. After that if you dont have it already look for Intel Temporary Recovery Session, download and open it on your desktop (make sure you have adb drivers and adb debug on), write ACCEPT and then write 2 and then T4, it should make you boot to TWRP (this is a temporary recovery), and flash WW .36 with modified updater script. And now something i tought you should now is that you can now install a permanent recovery, ill leave all links for TWRP permanent, temp recovery, and me176c support website.
If i helped you please press the thanks button :good:
Links:
Temporary Recovery Session:
http://forum.xda-developers.com/android/development/intel-android-devices-root-temp-cwm-t2975096
ME176C/CX Support Website:
https://www.asus.com/support/Download/28/6/0/23/3HzHuNmdcAgeMhJ1/32/
ME176C/CX Tutorial Installing Permanent Recovery:
http://forum.xda-developers.com/memo-pad-7/general/asus-me176c-cx-unlock-bootloader-t3315603

Hi
Just to make sure what line(s) to delete from the update script, since some posts mention 1 and som mentioin 2 lines. Is it the line below marked in red that has to be removed?
Line1: getprop("ro.product.device") == "K013" || abort("This package is for "K013" devices; this is a "" + getprop("ro.product.device") + "".");
Line2: show_progress(0.750000, 0);
\Sorenjul

[Solution] Getting Android Pay working on Pure Nexus , Chroma, or OMNI

Special thanks to @funkyboy1281, @lentm, @macboy3000 for helping getting this work. As far as I can tell, this is the easiest and most straight forward instruction set for getting Android Pay to work on the latest version of Pure Nexus, Chroma, or OMNI Rom
Clean Flashing
Download the appropriate Rom.
Pure Nexus Discussion​Chroma Discussion​OMNI (no link available, sorry)​
Download Pure Nexus Dynamic Gapps 2-3-16 (Very important, you cannot use 15-3-16 or later). Yes, even if you use Chroma or OMNI, these Gapps should work for you. Link
Download the unSU script for completely unrooting before installing systemless root. Link
Download SuperSU 2.68 (or higher) Link || Discussion
Advance wipe in recovery all but internal storage
Install the ROM, gapps, and unSU
Optional: Install custom kernel
In TWRP, under advanced, go to terminal and type the following:
Code:
echo SYSTEMLESS=true>>/data/.supersu
echo BINDSYSTEMXBIN=false>>/data/.supersu
Note: You may also do this using ADB in recovery (adb shell, and then enter the same commands. This is much easier in my opinion, and is the method I used.
Flash 2.68 beta in TWRP
Fully reboot, go through initial device setup
Verify in SuperSU that you cannot install SU to the system. This will verify that we are using the systemless root option
Download SafetyNet Helper and make sure it passes
Install Android Pay and profit!
Dirty Flashing
Verify that SafetyNet still passes in Android.
Verify in Android that /data/.supersu is still present and contains the appropriate options (see clean flashing). You may also verify in recovery by going to terminal commands and entering in:
Code:
cat /data/.supersu
Install the updated ROM (do not reinstall gapps unless your ROM builder specifically tells you to do so. Pure nexus does not require a reflash)
Optional: Install unSU. This was not necessary on PureNexus, but I cannot be sure for other roms. It shouldn't hurt anything to flash.
Optional: Install custom kernel
Install SuperSu 2.68 (or higher)
Check SafetyNet Helper and make sure it still passes
FAQ
Q. Can I still install and use AdAway?
A. Yes. You must first install something in recovery before installing AdAway. See the discussion Thread. You should be installing v3.1 of the app after you install the recovery zip.
Q. Can I still use V4A?
A. Yes. I do not use this however, but it has been reported that nothing special needs to be done.
Q. Can I change the screen density?
A. We have not found a way to do this without tripping Safety Net

..

@skaforey thanks for this thread! Might want to note in the OP that Wiping Data erases the internal storage. Some people may not know that.

MrBrady said:
@skaforey thanks for this thread! Might want to note in the OP that Wiping Data erases the internal storage. Some people may not know that.
Click to expand...
Click to collapse
Noted, thank you! Still hoping some of the lucky folks that have it working can help us out here.

Has anyone found a way to adjust the screen density while keeping Android Pay functional?

MrBrady said:
Has anyone found a way to adjust the screen density while keeping Android Pay functional?
Click to expand...
Click to collapse
You (should) be able to change the density through adb using
Code:
adb shell wm density DPI
with dpi being what you want, or if you have root you can do that from a terminal emulator, just remove the adb shell part.

I tried the 2nd method without formating data in different combos to no avail, still hesitant to wipe my internal sdcard, it shouldn't be that hard man, will follow this thread
anyone know other aosp ROMs that have AP working outside of pure nexus?
Sent from my Nexus 6 using Tapatalk

Following the steps in the top most instructions in the OP...
1) Pure Nexus 3/8 does not have root out of the box, so the Unroot step was not needed.
2) TWRP did not show any files/folders in the /su directory, so the Terminal command didn't work. I booted up the device and did it through the Terminal there instead and then rebooted.
After that, loaded up Android Pay and it says "Android Pay can't be used".
Running SafetyNet reports....
SafteyNet request: success
Response validation: success
CTS profile match: false

Tried different methods, not working for me.
1. Download Pure Nexus 1/03/16 or newer (Layers), the latest PN GApps, UnSU, the latest SuperSU.
2. Backup any important data.
3. Boot into TWRP and wipe everything including internal storage
4. Format data.
5. reboot TWRP with USB-OTG that has fines necessary.
6. Flash Pure Nexus.
7. Flash GApps.
8. Flash UnSU.
9. In terminal I saw I still had a folder /supersu so I deleted that.
reboot. Setup phone with google account. Did not have it restore apps, but did have it restore basic setup from google.
Install Safetynet helper
Still fail CTS Profile Match
Don't know what the people are doing different, but not working for me.
Are you using the PN-Gapps or others?
The updated-unsu is what date?
Thanks!

The only way I have gotten AP to work is from a stock image based ROM. It doesn't seem to work with AOSP ROMs like Pure Nexus.
For example, I am currently running Tupac's debloated stock ROM with Cataclysm MOD, Viper4Android and AdAway ad blocking. Android Pay works fine, as long as you follow the SU steps listed in the OP of this thread.

What I did to get AP to work was removing these lines from updater-script located in META-INF > com > google > android
Code:
ui_print("Flashing SuperSU..");
package_extract_dir("supersu", "/tmp/supersu");
run_program("/sbin/busybox", "unzip", "/tmp/supersu/supersu.zip", "META-INF/com/google/android/*", "-d", "/tmp/supersu");
run_program("/sbin/busybox", "sh", "/tmp/supersu/META-INF/com/google/android/update-binary", "dummy", "1", "/tmp/supersu/supersu.zip");
ui_print(" ");
and removed the supersu folder inside the zip file. I then installed my custom kernel and systemless supersu. After that, I set the permissions for bin folder inside su to 751 using a root explorer and deleted xbin_bind.

@macboy3000 what kernel and what version of SuperSU did you use, ? I tried your method, ROM booted fine but safetynet test failed...
this is how I did it
unzip ROM
edit code out
delete supersu folder
zip ROM
advance wipe everything but internal
flash ROM
flash pn gapps
flash elemental kernel
flash supersu
boot into android, delete xbin_bind
reboot system
permissions on bin folder were already 751, so didn't need to change
Sent from my Nexus 6 using Tapatalk

sgloki77 said:
@macboy3000 what kernel and what version of SuperSU did you use, ? I tried your method, ROM booted fine but safetynet test failed...
this is how I did it
unzip ROM
edit code out
delete supersu folder
zip ROM
advance wipe everything but internal
flash ROM
flash pn gapps
flash elemental kernel
flash supersu
boot into android, delete xbin_bind
reboot system
permissions on bin folder were already 751, so didn't need to change
Sent from my Nexus 6 using Tapatalk
Click to expand...
Click to collapse
Weird...I'm using SuperSU 2.67 and I'm also using Elemental kernel.

macboy3000 said:
Weird...I'm using SuperSU 2.67 and I'm also using Elemental kernel.
Click to expand...
Click to collapse
Did you format data? I'll give it a shot with 2.67, I used 2.68
Sent from my Nexus 6 using Tapatalk

sgloki77 said:
Did you format data? I'll give it a shot with 2.67, I used 2.68
Sent from my Nexus 6 using Tapatalk
Click to expand...
Click to collapse
I formatted everything except internal storage before installing.

macboy3000 said:
What I did to get AP to work was removing these lines from updater-script located in META-INF > com > google > android
Code:
ui_print("Flashing SuperSU..");
package_extract_dir("supersu", "/tmp/supersu");
run_program("/sbin/busybox", "unzip", "/tmp/supersu/supersu.zip", "META-INF/com/google/android/*", "-d", "/tmp/supersu");
run_program("/sbin/busybox", "sh", "/tmp/supersu/META-INF/com/google/android/update-binary", "dummy", "1", "/tmp/supersu/supersu.zip");
ui_print(" ");
and removed the supersu folder inside the zip file. I then installed my custom kernel and systemless supersu. After that, I set the permissions for bin folder inside su to 751 using a root explorer and deleted xbin_bind.
Click to expand...
Click to collapse
Well I tried this and still no luck
I even tried flashing the modified ROM, gapps, and never flashing SuperSU at all (so my rom wasn't rooted at all), and SafetyNet still gives me a red screen. I really wish I knew what was triggering this for some and how others can make it work.

I tried again using 2.57 SuperSU and Elemental X and still fails. Would someone that got it working be able to post a more detailed log of exactly what steps you're using and exactly what files you're flashing.

MrBrady said:
The only way I have gotten AP to work is from a stock image based ROM. It doesn't seem to work with AOSP ROMs like Pure Nexus.
For example, I am currently running Tupac's debloated stock ROM with Cataclysm MOD, Viper4Android and AdAway ad blocking. Android Pay works fine, as long as you follow the SU steps listed in the OP of this thread.
Click to expand...
Click to collapse
This has been my experience as well !

jcrompton said:
This has been my experience as well !
Click to expand...
Click to collapse
Got Android Pay working with Tupac's debloated stock ROM too! Thanks!
Is it possible to change DPI and keep Android Pay working?

lentm said:
Got Android Pay working with Tupac's debloated stock ROM too! Thanks!
Is it possible to change DPI and keep Android Pay working?
Click to expand...
Click to collapse
Not that I have found, unfortunately. Even via just ADB commands.