yashsingh1/xdaforums huggingface dataset:
[Sprint Samsung Galaxy S 4 Q&A, Help & Troubleshoot] sjsharksfan420:
I will start by disclosing that I am not in any way claiming credit for anything discussed in this thread. If someone knows the devs screen name, I would like to post it here..

As this is just a general info thread, I am assuming that you know the general process for flashing roms and/or know how to find that info if needed..

ROM download link is here: http://revolt.basketbuild.com/index.php?dir=uploads/jfltespr/Nightlies/

I noticed that we do not have a thread started yet for the ReVolt-JB ROM built for the S4 (Sprint version specifically) so I thought it would help some folks that might be testing this build. (At the time I created this thread, I am the only 1 person that had downloaded the 7/25 build) so this thread might not even be needed.. yet..

But anyways, hopefully with this thread being started, we can get a few more folks to run some tests for the dev that is building it.

My current tests:

I was running on the 7/6 build for a few days, I started getting the systemUI crashes after trying to update to the 7/22 build.. I needed my phone stable so had to pause my testing.. but I will be flashing the 7/25 build as soon as the download finishes.. I will post my results here

Update: So far the 7/25 nightly is running great, knock on wood for no systemUI crashes.. I still get an FC when trying to open the lock screen settings under ROM control..

Update 2: After almost a full day, everything is very stable. Except for the lock screen settings bug, this build is a perfect daily driver..

Last update: I just got a systemUI FC, I restored a nandroid that I had made right after updating to the 7/25 build, and its back good to go again, but the frustrating thing about it is, I haven't touched my phone for at least 15 minutes and just outta nowhere, the systemUI crashes.. :/ I don't know how to fix that issue besides restoring a backup (which is not a fix at all). If someone knows exactly how to pull a logcat for the systemUI crash specifically, please let me know

sj
[Nexus 7 (2013) General] phonic:
So it appears that some people (myself included) are having issues with their new Nexus 7. Specifically, where it is failing to install the second OTA update, which brings the tablet to version JSS15J. The first update (which is almost instant) works, but the second 50+MB one fails after rebooting into stock recovery.

It is failing because the file "/system/app/PrebuiltGmsCore.apk" is failing the sha1 checksum check. Why is this happening? Because the tablet is looking for a different version of the file then what is installed on some of our tablets. Why do different people have different versions? I have no idea. But it's certainly an issue for a few people including myself. I tried various standard work arounds but came up with no fix to get the OTA update, as is, to install. Then I decided to see if that was the only issue present and develop a work around.

I'm pleased to say that:

1) The PrebuiltGmsCore.apk file is the only one that breaks the OTA update. Everything else is fine.

2) I was successful in fixing this by creating a custom OTA update zip and installing it on my tablet.

3) I'm providing this modified update.zip for people to load on their tablets if they are having the same issue.

A couple of notes first...

Obviously, flash this at your own risk.

You NEED TO HAVE A CUSTOM RECOVERY for it to work. TWRP has already been ported over, so install that first.

Once you are in custom recovery, flash this file just like any other update.

Lastly, you should only download/install this if you are having the problem where the second OTA update fails. If you are currently running JSS15J, this update will fail (as it should).

This is 98% stock OTA update. All I did was some minor tweaks to fix the issue. Specifically:

1) I removed both the check for the PrebuiltGmsCore.apk file as well as the patching of it (since this fails).

2) I took the full JSS15J version of PrebuiltGmsCore.apk and built it directly into the update.

3) I removed the parts of the OTA update that mess with custom recovery. It will not install the /system/boot-from-recovery.p or /system/etc/install-recovery.sh files.

Once you install this, your tablet should be running identically to one that didn't suffer this issue.

Outside of using this, the only other option (AFAIK) is to wait until Google releases the full factory images and flash everything manually.

A big thanks to ATGAdmin for providing the stock JSS15J system dump that let me extract the updated PrebuiltGmsCore.apk file.

So without further ado, here is the update:

http://core.routed.com/JSS15J-Update.zip

Enjoy, and let me know if you have any questions.
[Nexus 7 (2013) General] shredder47:
Question: was your nexus 7 missing the wallpaper that they've been marketing with?
[Nexus 7 (2013) General] phonic:
Yes.

And I bought mine from Best Buy, which seems to be a common denominator with both of those issues.

However, I just checked, and I have that wallpaper now after installing this update.
[Nexus 7 (2013) General] shredder47:
Yeah sounds like that's the common denominator... I'm out right now but I'll try this out when I get home, thanks man!
[Nexus 7 (2013) General] chandeliho:
Thanks so much! This worked for me after trying other options failed. Mine was from Best Buy also.
[Nexus 7 (2013) General] phonic:
Oh, one other quick note:

As I wanted to leave this as close to the stock OTA update as possible, this WILL remove root. Technically, the 'su' binary will remain, but it will lose it's suid permissions. It will also remove the daemon launcher (which is installed as the install-recovery.sh file).

So make sure to flash the root zip after installing this update.

One more thing:

While there aren't many mods out there yet that will mess with the update, eventually there will be. This custom update will check and verify that everything else (except that one file) is stock. So if you made any other modifications to any other system file (ie: build.prop, etc.), it will fail just like any other OTA. Your best bet is to install this before tweaking.
[Nexus 7 (2013) General] Nburnes:
Worked great man!

Also, your download was rather slow so if you don't mind I made a mirror on mega: https://mega.co.nz/#!aE4CwJZB!J7QtUlqXhthhZcpPOUriaQ_u861k7rAGdHffRCmkQao
[Nexus 7 (2013) General] fosser2:
I have one from best buy and it updated just fine (both updates). I guess it's just luck of the draw.
[Nexus 7 (2013) General] phonic:
Awesome, glad to hear! And sure, that's perfectly fine with me.

It's on a 100Mb pipe, but the data center occasionally has some bad routing that makes certain destinations slow. Can't complain since I get a dedicated server for $59/month :D.
[Nexus 7 (2013) General] phonic:
Yeah, I believe it to be a minority of tablets. Maybe just a bad batch that all happened to get sent to Best Buy. As time goes on and more people get them we'll see how wide spread it is. I'm curious to see what Google's official fix will be.
[Nexus 7 (2013) General] paranoid android85:
Yeah, got mine from best buy too, the 2nd update stood at the boot screen. I just rebooted and it's back to normal
[Nexus 7 (2013) General] phonic:
Did you check to see if the update worked? If your version is still JWR66N, then it failed and you will either need to flash this or wait for an official fix from Google.
[Nexus 7 (2013) General] phuduong:
I brick my nexus. Can someone upload nandroid backup please?
[Nexus 7 (2013) General] Bob Smith42:
Interesting. My update worked (mostly because oldblue910 was doing it). LOL

I got mine at Walmart and noticed one of the box labels had been modified. There is an extra label covering one label on the box (also, there are labels on both ends). It is barely noticeable. I tried to remove the one on top (to peek) but it started to tear.

I theorize mine was part of a modification process. Do you think some of those failed units at Best Buy *might* have missed the modification process?
[Nexus 7 (2013) General] phonic:
I'm not really sure. After looking at the first OTA update that oldblue910 posted, it definitely indicates that it was modified by that. If so, it had to have initially passed that first check. Why some units fail the second check makes little sense to me. The lack of the official wallpaper is also weird.

Additionally, that first OTA clearly shows that these devices were rushed. The fact that they were sent out with developer keys is just really bad QA.

My device, hardware wise, seems to be perfect. So I don't want to roll the dice and try to get another one, especially if the only issue is some minor software glitch that I already corrected. I haven't had a chance to really play with it yet, as I've been spending my time backing up/restoring files, so I'll see how it goes.
[Nexus 7 (2013) General] stab244:
Thanks for this. Bought mine at Best Buys too and had the update fail.

Edit: TWRP gave the option to fix SU after flashing that zip and it seemed to work. I'll probably refresh zip anyways but TB still works.
[Nexus 7 (2013) General] phonic:
Yes, you should reapply the root zip.

The OTA update does two things in this regard. It removes the two 'recovery recovery' files, and it also removes the suid bit from the su binary. The TWRP su fix will reapply the suid bit to 'su' (thus making it actually work), but it doesn't put back the SuperSU daemon launcher (/system/etc/install-recovery.sh). By applying the root zip again, it will fix both of these.

I thought about removing the part of the update that deletes this file, but again I wanted to keep it as stock as possible. Also, for people who hadn't rooted yet but do have a custom recovery, it would help keep it custom and not require them to manually remove those files that would (stock) reset the recovery back.
[Nexus 7 (2013) General] xene97:
I also purchased mine at Best Buy, therefore I also have the problem.

What exactly does this 2nd update do? Is it a drastic improvement over JWR66N?
[Nexus 7 (2013) General] phonic:
If you are asking what files it changes, you can look inside the zip file and see all of that. It's fairly extensive. The vast majority are patches to many components of the operating system and included applications. The first OTA update was only a few hundred kilobytes, while this one is 50megs, so a lot was updated.

If you are asking what the end-user result or benefit is between the two, I am not sure. I spent most of my time working on trying to get the update working, and spent very little time using the tablet before I was successful. So I can't comment about whether the update improves anything. However, others have said that it did help to resolve some issues they experienced before hand.

In any case, the new N7 was released quite quickly and we know that the factory installed OS had some issues. The fact that there were two OTA updates before the device was even released show that Google needed to fix a lot of stuff. While future updates (Key Lime Pie anyone?) will be more optional as it focuses on enhancements and upgrades, these two updates are significantly more important.
[Nexus 7 (2013) General] xene97:
Thanks for the clarification!
[Nexus 7 (2013) General] XBIRDIE98:
I'm a Best Buy-er as well, with this problem. Hopefully it won't cause lasting issues.

I have one question about the modified update.zip, however:

Can this be flashed with adb sideload, so as to avoid messing around with a custom recovery?

I'm perfectly willing to try, but I figured I should get input on the safety of such a move.

(From what I understand about adb sideload, it should be safe - sideload acts as a manual start to the OTA process. Since the Nexus 4 leak could be installed with sideload, I don't think that signing will be a problem either.)
[Nexus 7 (2013) General] phonic:
I didn't try that method on mine so I can't say for certain whether it will work or not. It's certainly worth a shot as it will either work or not, but won't cause any problems if it doesn't (outside of failing to update). If you try it and it does, please let us know.

I also hope there won't be any lasting issues from this problem. Honestly, I doubt it will be the case. Worst case scenario, we should be able to flash the factory image once it comes out (without losing data). Only one file caused the failure, so everything else was kosher. I'm still not sure why this happened or why our devices didn't have the Google wallpaper. If the first OTA update didn't touch that file I would have chalked it up to a bad flash from the factory, but something else appears to have caused it.
[Nexus 7 (2013) General] boom1212:
Thanks for your share！It's very useful for my JWR66N version which has been unlocked and rooted...by the way,i am very interested in how do you change the JSS15J update file,and which tool do you use,in windows or in Linux, can you share with me?So that i can use the method and thinking to change other update files in the future.in the end..i am sorry for my poor English..Aha！ :laugh:
[Nexus 7 (2013) General] cobyman7035:
does google have the stock full nex 7 4.3 JS factory images up yet?
[Nexus 7 (2013) General] phonic:
NP. Glad to help.

The process is actually fairly simple. You just need the original OTA update, unzip it, and the modify the script that the recovery runs when you attempt to install it. In that file, you can modify what the script does, etc. If you need to have it install something, for example the full version of the file that was causing the issues here, you can put that into the directory structure inside of the zip. I believe someone has written a lengthy how-to about this.

Not yet. When they do, it will be here:

https://developers.google.com/android/nexus/images
[Nexus 7 (2013) General] Archon810:
Can't we just have the stock PrebuiltGmsCore.apk that it's looking for instead, so that we can flash it and then have the OTA apply cleanly?

---------- Post added at 04:41 PM ---------- Previous post was at 04:27 PM ----------

I ended up going your update route, and it worked like a charm. Thank you for putting it together.
[Nexus 7 (2013) General] phonic:
To answer your first question, yes, if you were able to find the intermediate version (between update 1 and update 2) of the PrebuiltGmsCore.apk file, and it matches the checksum of what the standard OTA update is looking for, you could write a patch that only replaced that file, then flash the unmodified second OTA update.

However, I was unable to find this version of the file when I wrote my script (nor have I seen anyone post a system dump containing it since). Fortunately, someone was nice enough to provide the file after the second OTA update, so I was able to incorporate that into this custom update and replace it with that. Also, when I put together this, I was in the process of troubleshooting the underlying issue itself, which made me want to 'patch' the patch to make sure nothing else was broken (fortunately, nothing else was - at least that this OTA touched).

In the end, either route would result in the identical end result, as the remainder of the OTA update is applied. Well, almost everything, as like I said I removed some pieces that overwrote custom recovery. But the system itself would be identical outside of that.

Glad it was able to help!

I'm curious as to how widespread this problem is and what is actually causing it, as there has yet to be any public announcement about it as far as I've seen. According to my logs, 245 unique IPs have downloaded this patch, so it seems to be fairly problematic. I wonder what Google is going to do to fix it for the 99% of owners who don't know about XDA. I sent my custom update with a lengthy explanation to Google's tech support, but have yet to hear back other than a generic BS message - not that I was expecting anything more.
[Nexus 7 (2013) General] sfhub:
Attached is the update.zip to implement this.

I tested using a simulated environment as I don't have a unit suffering from this problem.

You need to be unlocked to boot into twrp.

You do NOT need to install twrp custom recovery and can leave stock recovery on the tablet.

Actually you must leave stock recovery on the tablet since the goal is to apply the actual OTA.

Basic instructions:

1) place following in your adb directory (I renamed the twrp img for convenience)

update-repair-JWR66N.zip (attached file)

twrp.img (from TWRP custom recovery thread)

2) run the following commands from your adb directory

adb push update-repair-JWR66N.zip /sdcard/

adb reboot bootloader

fastboot boot twrp.img
​

3) twrp should be started now

Choose Install

Select update-repair-JWR66N.zip

Swipe to install

Verify log output says "Repair of JWR66N installation successful"

Select Reboot

4) Now you can just apply the JSS15J OTA update as if nothing was ever wrong
[Nexus 7 (2013) General] sfhub:
I have a theory that some units got updated from dev keys to release keys using a factory image and that image had a PrebuiltGmsCore.apk which differed from what one would get after applying OTA #1 (dev keys to release keys)

Going with this theory then it would be likely your OTA #1 either failed to install completely or was never downloaded and applied. In either case, you were still left with JWR66N release keys, but with PrebuiltGmsCore.apk with the wrong sha1.

Then when OTA #2 came along, you had that one file mismatch that carried over.

Considering other possibilities, seeing how the updater-script is written, I don't see how you could have successfully (completely) installed OTA #1 and have been left with a PrebuiltGmsCore.apk with sha1 that didn't match what JSS15J was expecting.

The scenario that fits best would be that your unit had the release key image already and the mismatch came from there.
[Nexus 7 (2013) General] phonic:
Something along those lines might be possible, but I don't believe it is as simple as that.

I took a look at the contents of the OTA Update #1 and confirmed that it modifies, among other files, the PrebuiltGmsCore.apk. After Update #2 failed, I also took a look at what the checksum was for that file and it did not match either the pre-1, post-1 or post-2 value that the two OTAs had in their validation. Other files that Update #1 patches were certainly at the correct post-1 values, because Update #2 checked their checksum and validated it.

I can't say for certain whether the Update #1 actually did anything, since it was so quick and unexpected when it happened on my device. It is also quite small, so it completing so quickly doesn't mean it failed, though that is certainly possible.

The problem with assuming that Update #1 failed is that it had to have changed some components in the system - certainly the build.prop file. Otherwise it would have continued to try and update it and not move on to Update #2. However, that is one of the last things the update itself does, so if any of the prior validation checks failed, it would never have completed that step. Which means that the first update had to have completed successfully - unless something else was very broken. And if that's the case, then the PrebuiltGmsCore.apk file had to have passed the pre-1 check, but somehow failed to be patched to the correct post-1 state. Again, it makes little sense to me.

Also, don't forget about our lack of the standard wallpaper.

I agree with you that it seems that something happened at the factory. I just can't think of any scenario where we would have the outcome we did.
[Nexus 7 (2013) General] 8bitrobo:
In TWRP I get a error flashing zip. I have tried re-downloading the file or placing it in a different folder. Is there something I am missing? I rooted my nexus just to fix this update issue.
[Nexus 7 (2013) General] sfhub:
What error do you get in the status window?
[Nexus 7 (2013) General] 8bitrobo:
asser failed: apply_patchcheck ("/system/lib/libchromeview.so"

E :error excuting updater binary in zip 'sdcard/JSS15J-Update.zip'

error flashing zip '/sdcard/JSS15J-update.zip"
[Nexus 7 (2013) General] phershey0747:
How to ID failure

First update went fast and smooth. I've now been staring at the lovely, colorful X (after telling it to apply the 2nd update and looking at Lloyd for a bit) for over an hour now. How long does this take? Recommendations? Just received my unit directly from Google today. Thanks. :confused:
[Nexus 7 (2013) General] sfhub:
Well it looks like the verify stage for that file is failing. Possibly there is another file missing or changed that is different than the one folks were encountering earlier.

Either that file doesn't match the pre/post patch SHA1 hash or it is missing.

assert(apply_patch_check("/system/lib/libchromeview.so", "053523029121cc103fffed311283bae69162ce17", "2fd9c62ca92576e4918b37e524004afa2fe17f1b"));

The pre patch SHA1 (ie JWR66N version) is supposed to be

SHA1 - 2fd9c62ca92576e4918b37e524004afa2fe17f1b

MD5 - 7bad2cd8d88dec3cf5d9620ecc4352a7

The post patch SHA1 (ie JSS15J version) is supposed to be

SHA1 - 053523029121cc103fffed311283bae69162ce17

MD5 - 9ed183354304e87562d2eb733bccee3f

Can you boot into android, start an adb shell session, and type

cd /system/lib

ls -l libchromeview.so

md5 libchromeview.so

and post the output.

---------- Post added at 02:05 PM ---------- Previous post was at 02:00 PM ----------

Shouldn't take an hour.

Suggest you boot into recovery and do a wipe data factory reset.
[Nexus 7 (2013) General] 8bitrobo:
Thanks for the replies. Here is the full twrp status window as i missed a some stuff.

Updating partition details...

installing 'sdcard/JSS15J-update.zip'

checking for MD5 file...

Skipping MD5 check: no Md5 file found

Warning: no file_nontexts

Verifing current system...

asser failed: apply_patchcheck ("/system/lib/libchromeview.so" "0535230291cc103fffed311283bae69162ce17"

E :error excuting updater binary in zip 'sdcard/JSS15J-Update.zip'

error flashing zip '/sdcard/JSS15J-update.zip"

This is what I got in the adb shell. I am not a programer in anyway so I probably entering the commands wrong.

C:\Users\Gunhaver\Desktop\android-sdk-windows\platform-tools>cd /system/lib

The system cannot find the path specified.

C:\Users\Gunhaver\Desktop\android-sdk-windows\platform-tools>ls -l libchromeview

.so

'ls' is not recognized as an internal or external command,

operable program or batch file.

C:\Users\Gunhaver\Desktop\android-sdk-windows\platform-tools>md5 libchromeview.s

ocd /system/lib

'md5' is not recognized as an internal or external command,

operable program or batch file.
[Nexus 7 (2013) General] sfhub:
In your windows prompt, you need to first type "adb shell" to start the adb session to your tablet. You typed the commands on your windows pc so they have no meaning.
[Nexus 7 (2013) General] 8bitrobo:
Ok so hopefully this is what you are looking for.

shell@flo:/ $ cd /system/lib

cd /system/lib

shell@flo:/system/lib $ ls -l libchromeview.so

ls -l libchromeview.so

-rw-r--r-- root root 33282556 2013-06-15 15:54 libchromeview.so

shell@flo:/system/lib $ md5 libchromeview.so

md5 libchromeview.so

41e5250c036a6b62c1150e31d6658821 libchromeview.so

shell@flo:/system/lib $ V
[Nexus 7 (2013) General] sfhub:
So, this is what it is supposed to look like:

shell@flo:/system/lib $ ls -l libchromeview.so

-rw-r--r-- root root 33282556 2013-06-15 12:54 libchromeview.so

shell@flo:/system/lib $ md5 libchromeview.so

7bad2cd8d88dec3cf5d9620ecc4352a7 libchromeview.so

The filesizes match, but the MD5 hashes are different.

That means the OTA in the first post will not work for you.

I could provide the file that you need, but it isn't clear how many files you'll end up having issues with since we don't know how your file got that way.

It might be easier if you just do the factory img restore. It'll probably be less work.

http://developers.google.com/android/nexus/images#razorjss15j

Direct JSS15J factory image download:

http://dl.google.com/dl/android/aosp/razor-jss15j-factory-2e08b83b.tgz