yashsingh1/xdaforums huggingface dataset:
[Nexus 7 (2013) General] phonic:
Yes, that is what he was looking for.

Very weird. It looks like your libchromeview.so file is not matching up to either the pre or post update contents. Similar incident to the other problem.

I just extracted this file from the pre-OTA2 system image and put it in a flashable zip for you:

http://core.routed.com/libchromeview-fix.zip

(credit for the container goes to sfhub since I took his other zip and just replaced that one file and edited the updater-script)

Try flashing that first. It should replace your libchromeview.so file with the one the update is looking for. Assuming this is the only 'oops' on your system, the other update should work fine now.

Did your system fail on the PrebuiltGmsCore.apk file as well? The libchromeview.so file is about half way down on the checks, so you made it through most of the others ones.

Also, please let us know where you bought yours from.
[Nexus 7 (2013) General] phonic:
True, but it would be nice to see what else (if anything) is broken, at least from a tracking perspective.

If he flashes the zip I just posted and then tries to flash the first zip (which should actually take less time than doing the full image (assuming there aren't other issues)), we should know if other files are affected as well. So far, he is the only other person reporting this problem.
[Nexus 7 (2013) General] sfhub:
Yes, for diagnosis it is better to iterate through the errors. Actually it would be better if he saved off libchromeview.so prior to overwriting it so we could examine the file for differences. It is exactly the same file size, so some possibilities are some header changed or the file got corrupted.

OP if you type (prior to installing the update.zip)

adb pull /system/lib/libchromeview.so

that would save the existing file prior to overwriting it.

My thinking was that my previous theory about the tablets being updated at the factory with JWR66N is highly unlikely since I doubt they would have 2 factory images so early.

That introduces the possibility of corruption, and if there is one file there might be more. If there are more, IMO it would be simpler (from his perspective) if he just blasted the JSS15J factory image on top.

Of course if there is enough energy it would be nice to get to the bottom of this.

So if I were him, I would probably start downloading the factory images now, and try iterating through the errors. If it starts getting troublesome, the images will be ready to use as a fallback. It is good to have the images around anyway, so it isn't a wasted download.
[Nexus 7 (2013) General] phonic:
Also, regarding the earlier theory, the only way that it would have been possible is if all the patches in the OTA#1 had already been applied in that affected factory image prior to being released. I say this because OTA#1 applied patches to quite a few files that OTA#2 patched as well. If the first update failed completely, which it would have had to if PrebuiltGmsCore.apk was different, none of those other files would have been able to be patched. If that was the case, the system state going into OTA#2 would fail for every single one of the commonly patched files. We know that it did not, so that means either:

1) OTA#1 did successfully update the system, which means all the checks passed, but the PrebuiltGmsCore.apk file somehow got corrupted (highly unlikely).

2) Google released an updated factory image on the affected devices that was patched with everything from OTA#1, somehow broke PrebuiltGmsCore.apk, and forgot to exempt it from the OTA#1 update (or just trusted that it would fail anyway and didn't bother).

#2 still is a likely candidate since only one person has reported anything else broken. Assuming he had that same thread issue, it could just be that somehow that file got corrupted and it is a sole fluke.

Oh, and for reference sake, the broken PrebuiltGmsCore.apk had the same file size as the one that validates.
[Nexus 7 (2013) General] sfhub:
I wasn't suggesting that the factory applied the OTA #1 then produced an image.

I was suggesting they assembled an image by gathering the appropriate set of binaries from the build machine, but one file PrebuiltGmsCore.apk was the wrong one and they missed a wallpaper.

It is moot now though, as I don't think it is possible for there to be two factory images this early on each suffering from different incorrect files.

However unlikely it seems like data corruption is moving up on the possibility list unless this person above is a red-herring.

---------- Post added at 05:16 PM ---------- Previous post was at 05:12 PM ----------

Did you do a binary compare on the two PrebuiltGmsCore.apk files? What were the differences? If it was some header, then that is understandable files can get mixed up when they get assembled into a release, but if it is just one byte flipped, then that sounds more like corruption.
[Nexus 7 (2013) General] phonic:
Sorry, I guess I didn't say that correctly. What I meant was that the only way for that theory to be true is if the affected factory image included the same binaries from a post-OTA#1 update. Not necessarily patched, but the same end result either way. That would be the only way that the second OTA would have worked as it did - assuming the theory was true.
[Nexus 7 (2013) General] phonic:
I did pull the file off, but accidentally deleted it before I had the opportunity to compare the two. :(
[Nexus 7 (2013) General] sfhub:
Yes, that is exactly what I was suggesting. Every file in the newer image would be exactly the same as the results of OTA #1, except for the one file PrebuiltGmsCore.apk, which was the wrong file. This fileset would have been assembled from the build machine rather than being the result of applying OTA #1 on the original release.
[Nexus 7 (2013) General] 8bitrobo:
I wanted to give you guys an update on my situation. I went with the one click factory restore to try and start over, but this actually updated me to JSS15J and I am still rooted. So everything went better than expected.

One click factory restore

http://xdaforums.com/showthread.php?t=2381582

This tablet was the 32gb from Newegg and was in their second shipment. My original problem was finding a solution to poor wifi performance, which then resulted in finding out I was stuck In JWR66N. JSS15J has helped with my wifi connection.

I want to thank you guys for your help. This thread saved me a lot of time and headache.
[Nexus 7 (2013) General] Tankslappa:
Good to know I'm not the only one suffering from this.

Mine *didn't* come from Best Buy. I'm in the UK, mine came from Ebuyer on Saturday 24th August.

Looks like we now know where Ebuyer got the stock from to be 5 days earlier than Google's play store!
[Nexus 7 (2013) General] sfhub:
Given the fixes Google added for eMMC "stability" (usually code word for corruption) in JSS15Q, I now believe the issues in this thread were caused by file corruption from the first mandatory OTA update that brought you from JWR66N-devkeys to JWR66N-releasekeys.

http://xdaforums.com/showthread.php?p=44954087#post44954087

This then caused the sanity sha1 checks in the second JSS15J update to fail.

It might only by limited to the hynix part or could be related to random reboots, but somehow these files were getting corrupted, and not always the same file, which leads to the theory that eMMC corruption during one of the OTA updates was the culprit.
[Nexus 7 (2013) General] phonic:
Do you think it was more of a fluke that is now fixed, or something that could result in an ongoing issue due to bad hardware?

It seems weird that the same file would be affected for everyone.

I haven't looked too carefully at the JSS15Q update - does it patch or replace the affected file? If the former, that means the issue could still be present for who-knows-how-many people, who will be stuck on JWR66N.
[Nexus 7 (2013) General] sfhub:
I don't think it was a fluke. The fix wasn't to the OTA update. The fix was to the kernel and mount options to try and avoid the corruption. If you have a corrupted JWR66N, just like with the JSS15J OTA update, JSS15Q OTA will not install correctly and will complain about a file that doesn't match the SHA1 it expects.

I believe the same problem was causing units to get corrupted UserData. You'll see various posts about I just rebooted and got stuck with the X screen or Android tells me UIDs are inconsistent, are you feeling lucky. I believe these are all manifestations of the same eMMC corruption issue.

So is it an ongoing problem? I don't know. I think they probably have done enough in their changes to avoid the issue, but you only get those "fixes" if you are running a JSS15Q kernel/recovery.

The fixes were in the generic eMMC read/write code and mount options for the eMMC volatile file systems.

I believe what happened was the unit shipped with all perfect files but they were JWR66N-devkeys versions.

Then you got the mandatory JWR66N-releasekeys OTA update right after you entered your wifi info. When it rebooted and applied this OTA update to bring you from JWR66N-devkeys to JWR66N-releasekeys, it patched a bunch of files including PrebuiltGmsCore.apk

When it did that patch, it took the perfect PrebuiltGmsCore.apk and slightly corrupted it. If someone can send me the corrupted file I can tell where/what got corrupted. I don't have an example of the corruption so cannot do it myself.

If you look back at the posts, it didn't always corrupt that file, there was another poster who had a different file corrupted.

Anyway, they made a change in the kernel that affected how they communicated with the Hynix (Samsung) eMMC part and also changed the mount options to remove some performance enhancements which could exacerbate corruption.
[Nexus 7 (2013) General] phonic:
I understand all that.

What I meant was:

1) Isn't it odd that everyone would have have had the same corrupted file? Since it corrupted in between factory->OTA#1, it seems unusual to me that out of the hundreds of files modified, the vast majority had the same one get corrupted.

2) Since it seems that most people didn't have this issue, while others did, do you think that there was also a hardware problem that might not be 'fixed' by this update.

3) While people who suffered the bug from this thread who read this thread, or are smart enough to fix it themselves, now have a working and up to date system, the average guy is not going to even know they have a problem, let alone be able to fix it. If PrebuiltGmsCore.apk is corrupted, it will never pass OTA checks. Unless of course Google realized this and has JSS15Q replace, not patch, that file, to bring them all up to the latest version. Without this extra step, I think there are going to be some very upset Nexus7 owners.
[Nexus 7 (2013) General] sfhub:
I think SOME people got PrebuiltGmsCore.apk corrupted and others had different files like libchromeview.so

http://xdaforums.com/showthread.php?p=44464021#post44464021

There likely were other files that could get corrupted also, but just went undiagnosed because they just went ahead and flashed the factory restore or returned the unit.

I think there might be a hardware/eMMC firmware problem with the Hynix part, but it is also possible not all Nexus 7's use that part as it is common to source eMMC from different vendors. It may also have to do with whether a "crash" happens after the OTA is done but before the pages are commited to physical disk. I think people should be aware of the issue, but probably Google/Asus/Hynix did resolve it by changing how they communicate with the eMMC part. These things are rigorously tested for basic functionality so I doubt they have a major issue with just standard read/writes. It is always with the eMMC "extensions" that offer some additional performance or privacy that we see the issues with.

I think for the low frequency of this happening, Google will just depend on people either flashing the factory image to get JSS15Q or returning/exchanging their unit.

Their units appear to be mostly functional on JWR66N with the corruption though there may be some seemingly random instability, which will probably get all categorized as the random reboot problem that got cleared up with a factory image restore. Even without the restore, they'll probably just go about their business using the tablet with the only immediately obvious detriment being they won't be able to get any OTAs.
[Nexus 7 (2013) General] sfhub:
BTW I finally got the PrebuiltGmsCore.apk from a damaged system.

I can pretty much confirm 99% this is eMMC corruption.

The damaged file is here:

http://xdaforums.com/showthread.php?p=45244469#post45244469

There's about 7MB of zeros, followed by an exact match of what the file should look like.

There is no way the mandatory JWR66N-devkeys to JWR66N-releasekeys OTA could have completed successfully if this file was shipped from the factory this way (and I did verify that that OTA does patch PrebuiltGmsCore.apk)

So the only conclusion is that that first mandatory OTA tried to patch this file and it resulted in filesystem corruption, which then later causes the second OTA to fail.

Now if the first mandatory OTA had failed, then that there could have been a posibility it came from the factory this way, but since it succeeded, there is no way it came from the factory this way.

This is not surprising after I saw the various changes Google put in to address eMMC data corruption in JSS15J/Q:

http://xdaforums.com/showthread.php?p=44954087#post44954087
[Nexus 7 (2013) General] phonic:
Thanks for the update.

I wonder if the first OTA being so quick was part of the cause. I forget how long it took exactly, but it seemed to be less than a couple of seconds. If you weren't paying attention, you would have missed it. It's possible that, with noauto_da_alloc enabled, the device rebooted too quick and didn't have a chance to commit the file changes.
[Nexus 7 (2013) General] red_ferrari007:
Same Prob ?

My NEXUS 7 (2013) is running on Android 4.3 with the build version JWR66N

The Problem is that i get an OTA update notification for Android 4,3 System Update which is of appx (56 MB).

When i try to install it the Tab reboots and the update fails and it restarts again with the same build version ie. JWR66N.

Again after 2-3 days i get the same notification for that 4.3 System update and again it fails. PLEASE HELP !!!

How will i update to android 4.4 ???

I dont want to sideload or root.... Please suggest a normal fix !!!

AM I FACING THE SAME PROB ?

1) I HAVE ZERO KNOWLEDGE OF rooting,sideload,boot etc

2) I am afraid to do update fearing something wrong will happen

3)Can somebody please guide me with a In detail Step By Step Process to implement this update ???
[Nexus 7 (2013) General] sfhub:
It will not be possible for you to fix the problem in this thread without unlocking.

I suggest you either unlock and flash the factory image or exchange the unit if you really can't so that, though I think you'd be surprised how much you are capable of if you try.
[Nexus 7 (2013) General] red_ferrari007:
So at least can someone tell me that the problem I am facing and the problem mentioned here is the same ?
[Nexus 7 (2013) General] and2nckiko:
Im still on JWR66N wifi version since my device bought on 1st week of august..july batch..i havent installed my initial update 50mb+ because of the issues surrounding nexus 7 at that time,i have no issue at all with my device,thats why i didnt update,and you qouted me also that time not too :) ...im still on stock,lock bootloader..my question is can i update jumping from JWR66N to Kit Kat?..cause i have receive the OTA (kitkat) this evening,...after clearing google framework last night,ive check and i still have the initial update 50mb+ when the first time i open my nexus..but this evening it change to kitkat,253.1mb..is it possible to jump without having an issue..thanks in advance.
[Nexus 7 (2013) General] sfhub:
You will need to post the log output of your failed OTA update for us to confirm.

---------- Post added at 09:59 AM ---------- Previous post was at 09:51 AM ----------

You are actually the first I've heard that has gotten an OTA from JWR66N to KRT16S. Previously we've only had JSS15R to KRT16S, in which case you'd need to get updated to JSS15R first, and that would fail.

Now with a JWR66N to KRT16S OTA update, there is a chance for it to pass because PrebuiltGMSCore is shipped as a whole, rather than patch, file.

Depending on how many files you have damaged, it might be possible for the JWR66N->KRT16S update to work. If it is just PrebuiltGMSCore, it will probably work.

Just try it and get back to us. If any of the files are not what are expected, it will complain with an error. Now given that you've had past emmc corruption there is some remote possibility you get more corruption on the new flash, but that will always be a risk, especially given your past corruption.
[Nexus 7 (2013) General] red_ferrari007:
How to get the log of failed OTA ?

Instead of all this if I directly flash stock JSS15R then what will happen
[Nexus 7 (2013) General] sfhub:
That will probably be the least amount of work to get you a system that will update in the future and also a system at the OS level you want.

Whenever you flash there is always the chance of a bad flash, but IMO it is a low chance, but not zero.

So what will likely happen, based on past experience on this thread is once you get the correct files in place everything will work fine for future updates.
[Nexus 7 (2013) General] red_ferrari007:
So to summarize everything...

1) I can update my JWR66N to JSS15R by doing a Stock Flash and all my problems will be hoped to get solved ????

2) Will my current JWR66N corrupt file which u all talk about obstruct the new stock flash process ?
[Nexus 7 (2013) General] sfhub:
That should be the end result.

Corrupt files only obstruct ota updates, not factory images.
[Nexus 7 (2013) General] and2nckiko:
@ sfhub And i also wonder why did i receive a 253.1mb which is different from a lot of nexus user here in the philippines (have read in forum here)which is 245.2mb wifi version
[Nexus 7 (2013) General] red_ferrari007:
i also received 253 mb update normal ota

i did not root or unlock bootloader anything

i am at KRT16S and i am facing serious touch screen issues
[Nexus 7 (2013) General] sfhub:
Are you on the latest JSS15R software? If not, the OTA patch file you receive will have different contents because you are starting from a different point.
[Nexus 7 (2013) General] aritro88:
i too had the same problem.

i just did a factory reset on my device and then i updated the firmware BEFORE i updated anything else (viz gmail, maps etc ) .

problem fixed
[Nexus 7 (2013) General] and2nckiko:
Im still on JWR66N..i havent installed ota bcoz of spreading issue since release of device..im surprised my initial ota sizing 53mb change into kit kat..i might aswell try to install,but what im worrying about is my touch screen,it work perfect since day one..i know there is a fix you provided..the ts thing,is that working on 4.4...thanks.
[Nexus 7 (2013) General] ganomi:
Fixed it differently on Nexus 7 2013 (JSS15J)

Hi.

I have the same issue and found different way how to fix it.

To fix the issue I had to perform the following steps. They are quite easy, but might be difficult for non tech person.

Best

Reset the device to factory first. (I just like to work on clean device; just a precaution)

For the next step to work, you have to enable USB debugging mode in Developer options and change USB computer connection to PTP in Storage configuration

Unlock the bootloader using Skipsoft Android Toolkit (This step is menu driven, quite easy and very safe and will also reset the device)

Download the software and install it.

Run it and select your type of device

Install the device drivers without the device being connected to the computer. (Option #1)

Connect the device

Unlock the bootloader (option 3 for Nexus 7 2013)

Then start system update again and it will work.

I also reset the device after 4.4 comes up. Again just my habit.

I am assuming the issue is related to the locked bootloader, but I am not sure. But if you try to install the zip file using ADB without unlocking the bootloader you hit the same issue.

Would be nice to get answer from Google.

Jiri
[Nexus S Q&A, Help & Troubleshooting] osos96:
nexus s i9023 with ics offical rom rooted and unlocked but power button suddenly stopped working so i flashed a jb volume wake zip to enable this feature but it gave me a bootloop now i cant even recover because of the power button i managed to get in the fastboot mode by putting the battery and quickly press volume up but in fastboot the device is not even detected by the usb (original) i have sdk and usb drivers but the problem is i put my phone in usb its like ive put a potato nothing happens and the sentences usb control init and usb control init end have disappeared in fastboot mode so i cant send commands to the phone through adb is there a way to make my phone detectable although when my phone is in the bootloop process its detected by the computer normally but no response of course.

THANKS in ADVANCE
[Nexus S Q&A, Help & Troubleshooting] osos96:
EDIT/UPDATE 1: i managed to get into recovery mode :victory:

HOW? NOTICE: IM NOT RESPONSIBLE FOR ANY DAMAGE OF ANY KINND YOU DO TO YOUR PHONE USE AT YOUR

OWN

RISK

1. keep phone plugged in usb

2.download SDK Manager from (http://developer.android.com/sdk/index.html)

3.install it in root path in Windows 7>>>>>C:/Users/[yourusername]/SDK

4.boot your phone NORMALLY in boot loop

5.connect your phone in usb if you neglected step one

6.your computer should detect it

7.open command promote (CMD) (shortcut windows flag+R) type cmd

8.a black screen will appear type in it "cd SDK/sdk/platform-tools" and press enter

9.path now should be C:\users\[your user name] \SDK\sdk\platform-tools>adb shell second line root@android:/ #

10.now type this (copy and paste is recommended) "mount -o remount,rw -t yaffs2 /system /system"

11.now simply type reboot recovery and your phone should reboot in recovery img

12.wipe factory settings now you should be good :D
[Nexus S Q&A, Help & Troubleshooting] !Lür:
I will try it now! If this works, then you are superman for me :D :good:

Edit:

1. should I type "adb shell second line root@android:/ #" after the new path is set and press enter?

2. if I do it, i always get the message "the command mount is wrong or can not be found" :(
[Nexus S Q&A, Help & Troubleshooting] !Lür:
Was much easier for me, don´t know why.

Solution for me:

1. Turn device into Bootloop

2. Connect it via USB (PC founds it)

3. type in CMD "adb reboot recovery"

4. device is in recovery

Requirement is a working Android-SDK.
[Nexus S Q&A, Help & Troubleshooting] osos96:
yup i just made it a step by step tut for noobs :D and your welcome :(
[MDA II, XDA II, 2060 General] texwiller:
I'm interested on a Deutch XDA IIi but it has the German Windows 2003Se on it. Is it possible to change to the English version (or italian !!) ?

Please if anyone know the answers include the links to the downloads or posts.

Thanks!!
[MDA II, XDA II, 2060 General] Weicomm:
Hello, looking for the same. I'm near on a solution to fix the problem. Could anybody write his DeviceData.txt of an english XDA 2i in this topic. (Download GetDeviceData.exe here)
[MDA II, XDA II, 2060 General] texwiller:
No solutions?
[MDA II, XDA II, 2060 General] epicus:
My devicedata.txt only contains 'PH10C'.
[MDA II, XDA II, 2060 General] Bubisch:
You must copy it to your PC. You can find more Informations in it.
[MDA II, XDA II, 2060 General] epicus:
there u go, attached the devicedata.txt file.
[MDA II, XDA II, 2060 General] koddy:
I´m looking for the same too....

Can anyone help me, how to change from german ROM to english ROM?

I´m a newbie here... and don´t know how to use it.

I´ve tried Getdevicedata.exe and there came an error message not valid win32 application.

How can I got txt files then?
[Galaxy S III Mini Q&A, Help & Troubleshooting] chrisxxx:
I noticed the gaslaxy s3min has 900 and rogers in canada uses HSDPA 850 is it possible to flash radi to change the frequency of this radio to work the 850 mhz ?