Sorry for the caps everyone, but THIS IS IMPORTANT! People like myself and TheManii who keep track of OTA updates for Nexus devices need this information!!
When you first turn on your N7, the minute you connect it to WiFi, it will do a force OTA update that you CANNOT defer.
Before you boot up your N7 for the first time, could someone please do the following steps:
1. Boot into fastboot mode by holding down volume down while you power it on.
2. Unlock the bootloader with "fastboot oem unlock"
3. Boot up TWRP for the new N7 using "fastboot boot twrp.img". Please DO NOT use "fastboot flash recovery twrp.img" because that will overwrite the stock recovery.
4. Do a full Nandroid backup.
5. Post the Nandroid somewhere for us.
6. Have our eternal gratitude.
We would be most appreciative. Thank you!
oldblue910 said:
Sorry for the caps everyone, but THIS IS IMPORTANT! People like myself and TheManii who keep track of OTA updates for Nexus devices need this information!!
When you first turn on your N7, the minute you connect it to WiFi, it will do a force OTA update that you CANNOT defer. Before you boot up your N7 for the first time, could someone please boot straight into fastboot mode, unlock, flash TWRP and get two pieces of info:
1. The bootloader version displayed on screen in fastboot mode.
2. The build.prop file in /system. You can pull that via adb once you boot into TWRP.
3. Totally optional, but we wouldn't complain if you would do a full nandroid backup of the ROM and post it somewhere.
We would be most appreciative. Thank you!
Click to expand...
Click to collapse
Hey, I'm just down the road in Raleigh, I can bring my new Nexus 7 16GB to a local Starbucks if you want to do this yourself. I have it fully charged but not yet turned on. Send me a PM and I'll give you my phone #, email.
Thought you were going to be here, anyway I posted the 2nd update, JWR66N to JSS15J, here (if it helps in anyway)
http://forum.xda-developers.com/showpost.php?p=43984053&postcount=5
Edit: See that you already have it on your Razor page!
Bob Smith42 said:
Hey, I'm just down the road in Raleigh, I can bring my new Nexus 7 16GB to a local Starbucks if you want to do this yourself. I have it fully charged but not yet turned on. Send me a PM and I'll give you my phone #, email.
Click to expand...
Click to collapse
Dude, PM me. I'm on it.
If this isn't done by the time I get mine tomorrow, I'll get it done
Sent from my Nexus 7 using Tapatalk HD
Flippy125 said:
If this isn't done by the time I get mine tomorrow, I'll get it done
Sent from my Nexus 7 using Tapatalk HD
Click to expand...
Click to collapse
Thanks, but BobSmith came to the rescue. I met him at a McDonalds and got everything. What happened is that somebody at Google messed up big time. The ROM that comes preloaded on the N7 is 4.3/JWR66N, but it's erroneously signed with development keys and not release keys. This is a huge problem, of course, since lots of apps that rely on DRM won't work right on dev-keys ROMs. So this forced OTA update simply updates you from JWR66N/dev-keys to JWR66N/release-keys. We don't know the URL to the OTA file since it's not in the normal place on Google's servers, but I managed to get the OTA update file out of /cache on BobSmith's device. The OTA file is available on http://randomphantasmagoria.com/firmware/nexus-7/razor.
Interesting.
Thank you for sharing that first OTA. I found something interesting...
If you hadn't heard, some of the new Nexus 7s, particularly those at Best Buy, are failing on the second OTA update due to a sha1sum mismatch on PrebuiltGmsCore.apk. According to the first OTA update, it too patches that file.
Looking at OTA1 and OTA2, it looks like it was supposed to go:
9392ccc5b4753684b73adf89b790b607f6a29388 -> f6193294456e67aad2a2d7e5ae03a2865d8544f6 -> 8e01a021b1edcfcc31266bc3193dec82c601f0bd
from out of the box -> OTA1 -> OTA2.
But in my case, and others, the sha1sum was something else (starting with 123 IIRC).
It's weird that the first OTA would verify and patch the file, which means it had to have the original 9392... sha1sum, but then fail on the second update. I wonder what would have caused it to break, and why it's only affecting a handful of devices.
phonic said:
Interesting.
Thank you for sharing that first OTA. I found something interesting...
If you hadn't heard, some of the new Nexus 7s, particularly those at Best Buy, are failing on the second OTA update due to a sha1sum mismatch on PrebuiltGmsCore.apk. According to the first OTA update, it too patches that file.
Looking at OTA1 and OTA2, it looks like it was supposed to go:
9392ccc5b4753684b73adf89b790b607f6a29388 -> f6193294456e67aad2a2d7e5ae03a2865d8544f6 -> 8e01a021b1edcfcc31266bc3193dec82c601f0bd
from out of the box -> OTA1 -> OTA2.
But in my case, and others, the sha1sum was something else (starting with 123 IIRC).
It's weird that the first OTA would verify and patch the file, which means it had to have the original 9392... sha1sum, but then fail on the second update. I wonder what would have caused it to break, and why it's only affecting a handful of devices.
Click to expand...
Click to collapse
I hadn't heard that, but that's very interesting. I wonder if we're going to see a new OTA from Google soon that has a full version of that file rather than a patch. It's happened in the past.
oldblue910 said:
I hadn't heard that, but that's very interesting. I wonder if we're going to see a new OTA from Google soon that has a full version of that file rather than a patch. It's happened in the past.
Click to expand...
Click to collapse
I made my own
http://forum.xda-developers.com/showthread.php?t=2380258
Fortunately, someone was kind enough to make a backup of a JSS15J that I was able to pull that file from.
On a completely unrelated note, does anyone have any idea why I am unable to access apk.gz backup files from TiBu? I'm trying to copy my apps from my old N7 to the new one, but am running into a very weird issue. Nothing I've tried (including adb pull) seems to be able to access them. I can move/delete the files, and I can make TiBu recreate them from scratch, but I can't copy them off of the device or even to another directory. I tried making a backup with tar via the shell, but that fails too. I can't even cat the file:
-rw-rw-r-- root sdcard_rw 2550494 2013-07-27 00:13 stericson.busybox-05fe3b964848cdb5fb3c07890734e899.apk.gz
sh: cat: stericson.busybox-05fe3b964848cdb5fb3c07890734e899.apk.gz: Permission denied
The properties and data files are not affected by this, only the apk.gz files...
This reminds me of the weird issue with the earlier versions of custom recovery, where you could make nandroid backups but couldn't delete them.
---------- Post added at 12:52 AM ---------- Previous post was at 12:43 AM ----------
NM. I changed the directory TiBu was using and I can access the new backups now. Instead of using /storage/emulated/0/TitaniumBackup, I now have it as /sdcard/TitaniumBackup.
Six in one hand, half a dozen in the other.
Weird bug....
We still need a dump of JWR66N/dev-keys (or specifically just /system)
The JWR66N/dev-keys -> JWR66N ota doesnt touch anything beyond stuff in /system.
As I already have a complete dump of JWR66N, I can regenerate a complete dump of JWR66N/dev-keys if i had a dump of it's /system.
While I dont expect it to be terribly useful for anyone, I like to collect these things for historical purposes.
What you have to do is make a nandroid before letting it connect to wifi and updating.
I do as soon as get mine pm me if need it
Sent from my LT28h using xda premium
tejasvi1 said:
I do as soon as get mine pm me if need it
Sent from my LT28h using xda premium
Click to expand...
Click to collapse
I'm all set now thanks to BobSmith42. Thanks, though.
oldblue910 said:
Thanks, but BobSmith came to the rescue. I met him at a McDonalds and got everything. What happened is that somebody at Google messed up big time. The ROM that comes preloaded on the N7 is 4.3/JWR66N, but it's erroneously signed with development keys and not release keys. This is a huge problem, of course, since lots of apps that rely on DRM won't work right on dev-keys ROMs. So this forced OTA update simply updates you from JWR66N/dev-keys to JWR66N/release-keys. We don't know the URL to the OTA file since it's not in the normal place on Google's servers, but I managed to get the OTA update file out of /cache on BobSmith's device. The OTA file is available on http://randomphantasmagoria.com/firmware/nexus-7/razor.
Click to expand...
Click to collapse
so if the Forced OTA patches the Dev signed keys to Release Keys then why do you /we need the Nandroid dump BEFORE the patches? what will that do for you/us considering that after the OTAs we are fine and wont have any issues?
nextelbuddy said:
so if the Forced OTA patches the Dev signed keys to Release Keys then why do you /we need the Nandroid dump BEFORE the patches? what will that do for you/us considering that after the OTAs we are fine and wont have any issues?
Click to expand...
Click to collapse
It's more just for archival purposes to have the JWR66N/dev-keys ROM since there will never be any factory images released. Plus, it's good for seeing exactly what was changed between the devkeys and releasekeys ROMs.
good job bob
Please someone provide a stock Jwr66n build.
Related
Ok. So here's the deal. I'm trying to update to 4.2.2 from 4.1.2, but in recovery I get assert failed, emmc this that and the other.
I'm currently on JZ054K trying to update to JOP40C. I am also fully stock. It's hurting my head using everything I learned from other devices.
*I don't want to do anything with the Nexus into the rooting process. I want to stay fully stock for once.
Please and thank you.
Curiousn00b said:
Ok. So here's the deal. I'm trying to update to 4.2.2 from 4.1.2, but in recovery I get assert failed, emmc this that and the other.
I'm currently on JZ054K trying to update to JOP40C. I am also fully stock. It's hurting my head using everything I learned from other devices.
*I don't want to do anything with the Nexus into the rooting process. I want to stay fully stock for once.
Please and thank you.
Click to expand...
Click to collapse
The "this that and the other" is the only thing which is relevant.
Post the exact error message. If you don't remember what it was, re-attempt the OTA and post a screen shot.
I'll take a photo today. I've been slacking. Away from the forums a bit.
Re: 4.1.2 > 4.2.x
That's the assert failed error. Fully stock neXus.
Sent from my HTC One V using Tapatalk 2
Curiousn00b said:
That's the assert failed error. Fully stock neXus.
Click to expand...
Click to collapse
OK, thanks for that.
Time to come clean though - when you say "fully stock", do you mean
(a) The device has never been rooted ever, or
(b) The device was rooted at one time and then (believed to be) returned to stock.
The assert error that is occurring is a complaint that the boot partition ("LNX") fails a checksum.
This would really only happen under two or three circumstances:
(1) Somehow the boot partition got modded by a root user - eg replacement of the entire boot image such as a "new kernel" or even something tiny like a change to /default.prop, OR
(2) You developed a media (eMMC flash chip) error in your boot partition after the device left the factory, OR
(3) Google/Asus somehow screwed up either the checksum calculation or your N7 slipped out of Asus's factory with a non-standard flash of the boot partition.
Now (3) seems a little bit unlikely. There was a previous user in these forums that reported exactly this same thing happening with a stock (never rooted) device; iirc though, he had a different factory ROM than what you are reporting. So, both his case and yours could be condition (2).
The things which is strange about this possibility (2) is that if a media error occurred randomly in the boot partition, it would be in most cases be fatal to the booting of the device, and neither you nor that other user reported booting troubles. The media error would have to be in a non-critical location such as in the slack space after the end of the boot image but before the end of the partition.
The reason I mention this is because of the way that apply_patch_check() assert seems to work: note that there are 5 parameters total:
filename,length1,sha1val1,length2,sha1val2
This suggests that a successful apply_patch_check() checks the SHA1 signature of the starting file - over an exact byte count, and if that succeeds it actually performs a trial patching operation so that it can compute the SHA1 signature of the output (patched) file and verify that the patch-trial-file has the correct length. This means that partition slack space is probably not included in the first checksum.
This is an extremely conservative and excellent approach to patching things in the field. Note also that the OTA does not touch/modify a single file on your tablet unless everyone of these checks goes to completion.
Also, the stock recovery performs a signature check on the entire zip file that is downloaded by the OTA before any of these other checks begin - which means, that when a stock recovery is used it is impossible to have a bad download being responsible for the errors that you observe.
If your device was never rooted then it seems to me that the odds point towards a hardware error that occurs during the patching-test operation.
If your device is still in Warranty and truly was never rooted, I would encourage you to try and get a new replacement or RMA repair (not a refurb). You are going to have to haggle with Google and show them that assert failure image.
good luck
Re: 4.1.2 > 4.2.x
It bears mentioning that, since the OTA is a patch, it's going to error out if the system is as the OP describes it. I'm unaware of any update zip that patches 4.1.2 to 4.2.2 directly. Since he's skipped a couple updates, he's going to have to do some sideloading to catch up and get to an upgradable state.
Sent from my Nexus 7 using Tapatalk HD
najaboy said:
It bears mentioning that, since the OTA is a patch, it's going to error out if the system is as the OP describes it. I'm unaware of any update zip that patches 4.1.2 to 4.2.2 directly. Since he's skipped a couple updates, he's going to have to do some sideloading to catch up and get to an upgradable state.
Sent from my Nexus 7 using Tapatalk HD
Click to expand...
Click to collapse
Good catch najaboy
I didn't catch that (JZO54K -> JOP40C) reference, but oldblue910's OTA thread does list such an OTA as having been available in the past.
Plus, iirc the boot image check occurs late in the OTA installer script, possibly even the very last assert() before patching actually starts - so it is hard to imagine that all other checks would have succeeded had a mis-matched OTA been applied.
However, it is indeed odd for "back dated" OTAs to get downloaded automatically esp when more recent upgrades are available, i.e. JZO54K->JDQ39. And nowhere did the OP mention side-loading.
Looks like the OP's got some 'splainin to do...
Ok. So yes.
A. The Device is FULLY STOCK. Never touched anything on it. Brand new on Christmas day.
I've been watching QBking's videos about upgrading it, and yes. I thought the same thing. Going from 4.1.2 to 4.2.2 directly, I noticed that seemed a bit off. I've seen more than just me with this issue. A few on XDA, and few on other websites.
I have tried downloading the 4.2.1 update. I tried sideloading it once. It failed. Atleast I believe it did. I don't know if I had the right download though.
All help is appreciated. I thank you guys as well. This 4.2.2 update is just what the OTA checker keeps throwing at me. I've tried clearing the data/cache of Google Services Framework(I believe this made me redownload the update).
Curiousn00b,
I'm 99.99% positive that you were applying a valid OTA file.
For instance if you have JZO54K on your tablet, and you were going to apply a sideloaded OTA you could choose any of 3 OTAs
JDQ39 (4.2.2) from JZO54K
JOP40D (4.2.1) from JZO54K
JOP40C (4.2) from JZO54K
My comment in the prior post was only that the automatic download always seem to download the OTA update to the most recent (in this case JDQ39) release, so your mention of JOP40C ota seemed slightly off; but if there was some reason to pick an older update, sideloading should still allow that to work correctly.
Bottom line is that a fully stock, never unlocked, never rooted tablet should be capable of accepting a factory OTA, and I would thus consider your tablet to have some unknown defect.
Just to be clear (I recall that the previous person reporting your symptoms was on JRO03S), you are currently on JZO54K, correct?
I found multiple people with it via Google. Couldn't really find a fix for it.
And yes. I'm on JZ054K.
Tomorrow I'll try going to 4.2 from 4.1.2. I'm pretty sure I've tried it already. I remember seeing the C/D parts at the end of these 2 files.
Curiousn00b said:
Tomorrow I'll try going to 4.2 from 4.1.2. I'm pretty sure I've tried it already. I remember seeing the C/D parts at the end of these 2 files.
Click to expand...
Click to collapse
If the problem occurs during the initial checksum of the (currently installed) boot image, then none of the three OTAs (starting from the same JZO54K base) will succeed. If there is something very strange - say a read/write error during the trial patching operation, I suppose it is feasible that one could succeed and another not. But they all should start out looking for the identical bootloader SHA1 checksum as they should be expecting the same (jzo54k) starting condition.
Anyway, post your results.
Re: 4.1.2 > 4.2.x
This is after trying 2 of the updates.
One to 4.2 and other to 4.2.2.
The first on is 4.2.2
Sent from my HTC One V using Tapatalk 2
Curiousn00b said:
This is after trying 2 of the updates.
One to 4.2 and other to 4.2.2.
The first on is 4.2.2
Click to expand...
Click to collapse
As I said, I didn't really expect any of them to succeed.
Where to proceed from here? You really only have 3 choices:
- Use your tablet on 4.1.2 and never upgrade
- RMA for repair/refurb replacement
- Root it, fix the problem, and relock it (so that it is 100% stock again). No guarantess that some trouble won't develop down the road.
As I said before, neither you nor I have any explantion for why a never-rooted tablet would not be able to accept a valid factory OTA. Your tablet either:
(a) slipped out of the factory with an unknown bootloader variant, OR
(b) the boot partition managed to develop bit-rot that does not affect the tablet's ability to boot, OR
(c) there is some other unidentified hardware fault that occurs during the apply_patch_check() process
I would call Asus and see what they will do for you before you make a final decision. (Their warranty has a lot of weasel-words in it; they might tell you that it's not their problem.) If you want an RMA and they push back, I think you should keep repeating that the tablet is less than 3 months old.
good luck
I also noticed that I can't boot into recovery normally. I use ADB or the OTA way to reboot into recovery.
If I get into Bootloader and plug the USB in, the Nexus 7 will freeze at whatever selection I am currently on. Bootloader, Restart, Recovery, etc and nothing will happen.
When I click Recovery, I get a black screen with Google, nothing happens, plug the USB in, and still. Nothing happens. I don't know what's wrong with it.
Thanks for the help.
bftb0 said:
As I said, I didn't really expect any of them to succeed.
Where to proceed from here? You really only have 3 choices:
- Use your tablet on 4.1.2 and never upgrade
- RMA for repair/refurb replacement
- Root it, fix the problem, and relock it (so that it is 100% stock again). No guarantess that some trouble won't develop down the road.
Click to expand...
Click to collapse
My N7 has the same error about the boot partition. It's rooted, unlocked, and has CWM installed. I'm running 4.1.2 (JZO54K). I downloaded the JZO54K to JDQ39 zip file, and got the failure
script aborted: assert failed: apply_patch_check("EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5013504:c48f8e86c73fb2c2ba1794f5ec98e27c9e206ed5:5062656:af83f09e77a64ed7ede2adad2a16bd0c12d5d7fd")
when I tried to install it via CWM.
How would I fix this - I assume I need to get a copy of the 4.1.2 boot.img and flash it, but I'm not sure how to flash it. I can do it in Windows if I have to, but I'd rather use Linux if I can. I have the adb tools installed on Linux.
mvi57 said:
How would I fix this - I assume I need to get a copy of the 4.1.2 boot.img and flash it, but I'm not sure how to flash it.
Click to expand...
Click to collapse
Yes, that's right. It is easiest is to flash it with fastboot
Code:
fastboot flash boot boot.img
It can also be flashed to the block device
/dev/block/platform/sdhci-tegra.3/by-name/LNX
from a root shell (say in a terminal emulator) using the "dd" utility if you are familiar with that.
A custom kernel or even a trivial re-packing of the boot image (say for a small /default.prop file change) probably is what caused the boot image to be changed from stock.
bftb0 said:
A custom kernel or even a trivial re-packing of the boot image (say for a small /default.prop file change) probably is what caused the boot image to be changed from stock.
Click to expand...
Click to collapse
I didn't install a custom kernel, and as far as I know I didn't change default.prop either.
I reflashed the boot image, it went ok, but I still get the error trying to do the update. I guess I'll have to wipe and flash the whole 4.2.2 image to get it installed.
mvi57 said:
I didn't install a custom kernel, and as far as I know I didn't change default.prop either.
I reflashed the boot image, it went ok, but I still get the error trying to do the update. I guess I'll have to wipe and flash the whole 4.2.2 image to get it installed.
Click to expand...
Click to collapse
Never mind, I flashed the bootloader-grouper-3.41.img instead of pulling boot.img from the .zip. It's working now.
mvi57 said:
Never mind, I flashed the bootloader-grouper-3.41.img instead of pulling boot.img from the .zip. It's working now.
Click to expand...
Click to collapse
That observation is extremely counter-intuitive.
While the bootloader is responsible for booting the recovery, it is certainly not "running" after the recovery starts booting, so it's hard to understand why or how it could have any effect at all on the OTA processing.
Is it possible that the error which occurred after you re-flashed the boot image (LNX) was something different than the original error concerning the checksum on the boot partition?
You might want to consider flashing the v4.18 bootloader to the tablet if you plan on using any dev kernels.
bftb0 said:
That observation is extremely counter-intuitive.
Click to expand...
Click to collapse
Poorly worded, sorry. After I flashed the boot.img I extracted from the zip file, the update ran fine. I looked at the error message again and noticed that one of the numbers matched the size of boot.img, and then realized I flashed the wrong file. I shouldn't do this stuff when I'm tired.
Thank you for all your help!
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.
Question: was your nexus 7 missing the wallpaper that they've been marketing with?
Sent from my Nexus 4 using xda app-developers app
shredder47 said:
Question: was your nexus 7 missing the wallpaper that they've been marketing with?
Sent from my Nexus 4 using xda app-developers app
Click to expand...
Click to collapse
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.
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!
Sent from my Nexus 4 using xda app-developers app
Thanks so much! This worked for me after trying other options failed. Mine was from Best Buy also.
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.
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
I have one from best buy and it updated just fine (both updates). I guess it's just luck of the draw.
Sent from my Nexus 7 using Tapatalk HD
Nburnes said:
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
Click to expand...
Click to collapse
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 .
fosser2 said:
I have one from best buy and it updated just fine (both updates). I guess it's just luck of the draw.
Sent from my Nexus 7 using Tapatalk HD
Click to expand...
Click to collapse
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.
Yeah, got mine from best buy too, the 2nd update stood at the boot screen. I just rebooted and it's back to normal
Sent from my Nexus 4 using Tapatalk 4 Beta
paranoid android85 said:
Yeah, got mine from best buy too, the 2nd update stood at the boot screen. I just rebooted and it's back to normal
Sent from my Nexus 4 using Tapatalk 4 Beta
Click to expand...
Click to collapse
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.
phonic said:
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.
Click to expand...
Click to collapse
I brick my nexus. Can someone upload nandroid backup please?
phonic said:
... 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. ...
Click to expand...
Click to collapse
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?
Bob Smith42 said:
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?
Click to expand...
Click to collapse
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.
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.
Sent from my Nexus 4 using Tapatalk 4 Beta
stab244 said:
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.
Sent from my Nexus 4 using Tapatalk 4 Beta
Click to expand...
Click to collapse
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.
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?
xene97 said:
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?
Click to expand...
Click to collapse
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.
phonic said:
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.
Click to expand...
Click to collapse
Thanks for the clarification!
NEW 22.21.11 OTA Zip posted on the site 12/1/14
YOU MUST BE ON 22.11.6 TO UPDATE
NEW 22.11.6 OTA Zip posted on the site 11/11/14
http://www.graffixnyc.com/motox.php
OTA is there!
Instructions:
This is ONLY for the XT1095 Pure edition.. Support priority will be given to those with a XT1095. If you have another model number you will have to figure out how/if you can run this OTA. It's not up to this thread to support devices the OTA was not meant for.
IF YOU ARE ON THE FIRST SOAK TEST OTA .5 YOU CANNOT UPDATE TO .6. IT WILL FAIL! YOU WILL HAVE TO DOWNGRADE TO 4.4.4 THEN APPLY THE .6 OTA
Follow @SolarTrans Guide found here: http://forum.xda-developers.com/moto-x-2014/general/guide-update-xt1095-pure-edition-to-t2937074
Be unaltered unrooted system. The device cannot be rooted and then unrooted.. it must be a never rooted system or the update will fail. It seems it's failing on devices that were rooted and then unrooted. On devices that were never rooted or where the user had stock back up they made prior to rooting the ota will update fine
Boot into Stock Recovery
ADB Sideload the zip
For people getting the modem error. Make sure you back up your current modem using the DD command (google if you don't know how)
After that download the AT&T modem from my website, flash it, then take the OTA. You MAY lose LTE after the update. If you do just reflash your old modem and you'll be good to go. It's also been confirmed if you reflash the AT&T modem after the update you will get LTE back.
Download Links can be found on my website: http://www.graffixnyc.com/motox.php
Also, please do not PM me for support. PM's will not be answered. Post it in the thread. It helps other's having the same issue find a solution. If it's over PM it only benefits you and not everyone else
Disclaimer: I am not responsible if you use this and brick your device or if your device blows up, implodes, flames start shooting from it or it kills your neighbor's dog. Flash at your own risk. I am not responsible.... It was the other guy... I swear....
This is going to sound really nooby but do i just flash this in recovery? Or in the bootloader?
Sorry, this is my first Moto device, have had Nexus and HTC phones before this
Use ADB sideload to flash on a stock unrooted system. Went through perfectly for me and currently optimizing apps. Thanks
jellydroid13 said:
Use ADB sideload to flash on a stock unrooted system. Went through perfectly for me and currently optimizing apps. Thanks
Click to expand...
Click to collapse
So, unroot, flash stock recovery, then go to the bootloader and adb sideload?
THEindian said:
So, unroot, flash stock recovery, then go to the bootloader and adb sideload?
Click to expand...
Click to collapse
yeah but go to recovery and sideload
I'm rooted, but still stock recovery. Can I still boot to stock recovery and sideload?
Also, how do I adb sideload? Can someone explain? I have somewhat of an idea, but want to make sure before I go ahead and do so.
dmbfan13 said:
I'm rooted, but still stock recovery. Can I still boot to stock recovery and sideload?
Also, how do I adb sideload? Can someone explain? I have somewhat of an idea, but want to make sure before I go ahead and do so.
Click to expand...
Click to collapse
Yeah, so i just got it to start flashing. Yes, you have to be unrooted but this is pretty simple, to unroot:
Go to the SuperSU app, go into the 3rd tab with all the settings, in there, there should be an option, something along the lines of "clean unroot", hit that, it should only take a minute or so
If you still see the SuperSU app once thats done, go into the play store and uninstall it
You are unrooted
To flash, plug in your phone and type in "adb reboot recovery"
You'll the that little android, once you see this, press the UP volume button, then power button, then release
Scroll down to where it says apply update from adb
type in "adb sideload BLAH BLAH BLAH.zip"
It should start applying. Hope this helps!
CRAP. I got an error in the installation and now it won't boot. It was something along the lines of how it didn't have the intall-recovery.sh file. Someone please help!
Can be root achieved?
sent from my Nexus 7
THEindian said:
Yeah, so i just got it to start flashing. Yes, you have to be unrooted but this is pretty simple, to unroot:
<snip snip>
CRAP. I got an error in the installation and now it won't boot. It was something along the lines of how it didn't have the intall-recovery.sh file. Someone please help!
Click to expand...
Click to collapse
Same thing happened to me. I suppose we'll have to flash stock back?
THEindian said:
Yeah, so i just got it to start flashing. Yes, you have to be unrooted but this is pretty simple, to unroot:
Go to the SuperSU app, go into the 3rd tab with all the settings, in there, there should be an option, something along the lines of "clean unroot", hit that, it should only take a minute or so
If you still see the SuperSU app once thats done, go into the play store and uninstall it
You are unrooted
To flash, plug in your phone and type in "adb reboot recovery"
You'll the that little android, once you see this, press the UP volume button, then power button, then release
Scroll down to where it says apply update from adb
type in "adb sideload BLAH BLAH BLAH.zip"
It should start applying. Hope this helps!
CRAP. I got an error in the installation and now it won't boot. It was something along the lines of how it didn't have the intall-recovery.sh file. Someone please help!
Click to expand...
Click to collapse
It seems like either the install-recovery.sh file was removed when you unrooted (SuperSU uses that file) or it detects it has been modified and is failing. You will have to ask someone to pull it from a non rooted device
I assume so, trying to do this but i have yet to find a stock image, the only is the one OP has his website is almost down. Do you know where else i could get an image?
---------- Post added at 05:18 AM ---------- Previous post was at 05:14 AM ----------
Could you mirror your system.img to dropbox or mega or something? The download for the system.img is taking 1 day.
Is there a guide to re-root?
will I get the next OTA if I sideload the soak test?
just wondering.
Mine is also bricked due to using unroot in supersu....
THEindian said:
I assume so, trying to do this but i have yet to find a stock image, the only is the one OP has his website is almost down. Do you know where else i could get an image?
---------- Post added at 05:18 AM ---------- Previous post was at 05:14 AM ----------
Could you mirror your system.img to dropbox or mega or something? The download for the system.img is taking 1 day.
Click to expand...
Click to collapse
I am in the same boat as you.
edwardgtxy said:
Mine is also bricked due to using unroot in supersu....
Click to expand...
Click to collapse
Yeah... mine's in a bootloop that I can't seem to stop. Holding the power button doesn't actually seem to turn it off. The screen goes black... and then eventually it just starts up again.
Im getting an error that says /modem/image/modem.b00 has unexpected contents.
any clues?
matt99017d said:
Im getting an error that says /modem/image/modem.b00 has unexpected contents.
any clues?
Click to expand...
Click to collapse
Same here.
THEindian said:
I assume so, trying to do this but i have yet to find a stock image, the only is the one OP has his website is almost down. Do you know where else i could get an image?
---------- Post added at 05:18 AM ---------- Previous post was at 05:14 AM ----------
Could you mirror your system.img to dropbox or mega or something? The download for the system.img is taking 1 day.
Click to expand...
Click to collapse
No, do not mirror my files. I like to keep count of my downloads. Get a better internet connection. I downloaded the file in less than 5 minutes as others did.
It appears you need a non-rooted system image that's never been rooted. You need to be fully stock. Not rooted and then un rooted. I believe the unrooting process still leaves files in an altered state than their original. If there is a single extra character in a file, if it's the slightest smallest difference the file is considered altered and will fail OTA checks.
Quite a few people have tried this and it has worked. It seems the ones it's failing on are ones that were rooted then unrooted. Derek Ross just told me it worked like a charm for him.
any tips to stop the boot loop? I am parking mine in recovery now to drain the battery.
Btw, it seems the OTA modified modem, system and boot. So theoretically, we can just use fastboot to go back to the your imgs, and the phone should still work right?
For anyone interested here is the firmware image for Verizon Nexus 6 [5.1] [ LMY47E].
VRZ_XT1103_5.1_SHAMU_LMY47E_release-keys_subsidy-default_CFC.xml.zip
http://www.filefactory.com/file/12c...Y47E_release-keys_subsidy-default_CFC.xml.zip
Nexus 6 Firmware Folder
http://www.filefactory.com/folder/74e3c3d68254b075
This where I upload my stuff so sorry if I offend anyone for doing so.
So the difference in between whats out there and this is? I'm curious as the build is different.
coldconfession13 said:
So the difference in between whats out there and this is? I'm curious as the build is different.
Click to expand...
Click to collapse
Not sure what's actually different but the build number is different, LMY47D vs LMY47E.
Could this be flashed with twrp without losing custom recovery?
Sent from my Nexus 6 using XDA Free mobile app
Hopefully we will find out if there are any significant changes or additions. I really hope that I do not need to follow a Verizon firmware through the life of this phone. I hope that there is nothing meaningful in the E version.
Not positive as I am just downloading it, but pretty sure it is the factory image for the Nexus 6 for VZW so I imagine it will remove root and probably custom recovery.
But the nice thing about the Nexus 6 is that you are NOT tied to your carrier's firmware/ROM's for it. Unlike previous phones, there are only two versions, US and International. So we don't have to worry if 'x ROM' is for the T-Mobile version, the Sprint version, etc., etc.
Well no worries this all but confirms vzw is rootable and unlockable
Anyone Flash this yet?
Has anyone flashed this yet...very interested how you went about it and what the results are.....thx
Is there a rooted version??
Parsing the image filename
coldconfession13 said:
So the difference in between whats out there and this is? I'm curious as the build is different.
Click to expand...
Click to collapse
Also waiting another few hours for download to complete. In the mean time, just parsing all the attributes of the file name:
LMY47E: Newer than LMY47D, which is explicitly called 5.1.0 on the Nexus Factory Image page (not the usual numbering convention, which would be 5.1; possibly foreshadowing that they know 5.1.1 is hot on its heels)
release-keys: signed by Google
subsidy-default: Includes parameters that resets the SIM Lock on the radio to "default" status, which we assume is factory-unlocked.
CFC: any idea what means?
I would assume this also gives us an image for the /oem partition
Judging by the name this was made on the same day as the image on Google's website, so it is very unlikely that there are major changes.
Nexus 6 subsidy lock config
@autoprime:
1. Does the contents of the included slcf_rev_b_default_v1.0.nvm look like plain QMI commands to you?
2. Do you still have a user-friendly one-click tool that can send DFS commands to a device in diag mode?
How to Flash
Maybe a dumb question... but can this be TWRP flashed (I thinking no) or is there some other method? I was thinking this was a standard recovery image that could be flashed in stock recovery?? Other than that, I am not sure... if anyone has success flashing let me know!
edit...
duh.... ok sorry... my bad for not looking into the zip.... I see the flash all .bat
mahst68 said:
Maybe a dumb question... but can this be TWRP flashed (I thinking no) or is there some other method? I was thinking this was a standard recovery image that could be flashed in stock recovery?? Other than that, I am not sure... if anyone has success flashing let me know!
Click to expand...
Click to collapse
I believe you will need the Motorola Fastboot tool (mfastboot) to flash this in the motoboot mode. You can get it from the MotoDev site, or search on the forums. Note that this is NOT the same as the standard fastboot that ships with the Android SDK (which will also work with the Nexus 6, but not with this particular zip file).
Did It!!!
DA6030 said:
I believe you will need the Motorola Fastboot tool (mfastboot) to flash this in the motoboot mode. You can get it from the MotoDev site, or search on the forums. Note that this is NOT the same as the standard fastboot that ships with the Android SDK (which will also work with the Nexus 6, but not with this particular zip file).
Click to expand...
Click to collapse
As described, used mfastboot... flashed each individual image file based on the steps in the flashfile.xml!!! Booted up everything real nice.... download myverizon and voicemail as soon as I went through initial setup.... rooting now!!! :good:
bootloader remained unlocked the whole time!!!!
mahst68 said:
As described, used mfastboot... flashed each individual image file based on the steps in the flashfile.xml!!! Booted up everything real nice.... download myverizon and voicemail as soon as I went through initial setup.... rooting now!!! :good:
bootloader remained unlocked the whole time!!!!
Click to expand...
Click to collapse
Does the firmware seem configured for VZW? VZW ringtones and boot animation and the like? Or does it appear like something that Google will drop on us in the near future? I wonder if it will ever hit the factory images page?
elreydenj said:
Does the firmware seem configured for VZW? VZW ringtones and boot animation and the like? Or does it appear like something that Google will drop on us in the near future? I wonder if it will ever hit the factory images page?
Click to expand...
Click to collapse
only thing Verizon really are the 2 app downloads.... everything else is the same... not boot animations nothing. Root and TWRP setup worked fine as well.... Not going to relock bootloader though... I know the horror stories of Hard Bricks.... Not going to take off force encrypt either.... was having trouble with the phone wanting to go bootloopy with the regular image from google when I made it force before... I will let everyone know bugs and post some pictures as well once I set it up fully!! :highfive:
mahst68 said:
only thing Verizon really are the 2 app downloads.... everything else is the same... not boot animations nothing. Root and TWRP setup worked fine as well.... Not going to relock bootloader though... I know the horror stories of Hard Bricks.... Not going to take off force encrypt either.... was having trouble with the phone wanting to go bootloopy with the regular image from google when I made it force before... I will let everyone know bugs and post some pictures as well once I set it up fully!! :highfive:
Click to expand...
Click to collapse
Question: I think I may have been under the same circumstances as you. I am rooted, with TWRP, and bootloader unlocked. I am however, running a custom rom (5.0.1 encrypted). I won't be relocking the bootloader. What steps (if you are able to provide them) should I take to achieve 5.1 with bootloader still locked and then root and install TWRP. (Please keep in mind I a have not had a Nexus device since the very first one).
Edit: I am on VZW network but Google Play Store Nexus 6.
TIA
Will do... I am still setting up the phone. Once I complete it and make sure it works fine for a little bit then I'll post. Don't want to cause any issues that might lead to someone bricking their phone
Initial observations
DA6030 said:
LMY47E: Newer than LMY47D, which is explicitly called 5.1.0 on the Nexus Factory Image page (not the usual numbering convention, which would be 5.1; possibly foreshadowing that they know 5.1.1 is hot on its heels)
Click to expand...
Click to collapse
System partition looks complete, but I won't have time to do a diff between the two until next week. But by then, we might have an official changelog.
DA6030 said:
subsidy-default: Implies there's something within this file that sets the SIM Lock parameters on the radio? Extracting that could be very interesting to AT&T and Sprint customers.
Click to expand...
Click to collapse
I don't have an AT&T device to test, but applying this file certainly attempts to set the SIM lock to it's default factory-unlocked state. But it's also possible the radio firmware could reject the unlock commands if it has been previously locked by a carrier. Only way to know is to test.
DA6030 said:
I would assume this also gives us an image for the /oem partition
Click to expand...
Click to collapse
There is an oem partition file within the zip, but it's literally just the string "Hi, Fly Guy". Just open oem.img with a text editor to see it. I cannot imagine that is a valid ext img file, so I'm shocked that it was able to be flashed. If so, that would suggest that the Verizon devices will ship with no unique customizations (e.g., bootanimation, ringtones, that cannot be removed without root), and has a sense of humor.
---------- Post added at 10:39 AM ---------- Previous post was at 10:32 AM ----------
mahst68 said:
As described, used mfastboot... flashed each individual image file based on the steps in the flashfile.xml!!!
Click to expand...
Click to collapse
@mahst68, did you flash only the image files, or also the subsidy_lock_config file (slcf....nvm)? What mfastboot command did you use to send the slcf? What was the response did you get back from that command? And when you flashed the oem.img what response did you get back?
< include generic disclaimer here >
TL;DR
Since update 3.1, Nvidia can force updates (such as the one that bricks your tablet) to be downloaded and installed silently. No guarantees, but:
If you're on stock, delete TegraOTA (/system/app/TegraOTA or /system/priv-app/TegraOTA if you're on 5.0 or newer, or /system/app/TegraOTA.apk if you're still on 4.4) before booting into Android (the attached ZIP file does this for you, but please check with the file manager in recovery before rebooting and let me know if it didn't work), then reboot
Note: you also will need to delete TegraOTA again if you ever install an OTA from Nvidia or a recovery image
If you're not on stock, you're probably safe
EDIT: The urgent OTA is currently not getting sent out to any devices anymore, not even to those who have been getting it before.
EDIT 2: The urgent OTA is now being delivered again, this time named "ST - yy"!
What if my tablet is already deactivated?
Unless you can still boot into fastboot mode (in which case your tablet isn't really deactivated yet), your tablet is probably gone for good. The only way to fix this would be through nvflash, and using it requires the SBK that is unique to each device and that only Nvidia knows, so it's pretty unlikely that we'll ever be able to fix these deactivated tablets.
What/why/how?
In the last OTA (Update 3.1), Nvidia has made some changes to their TegraOTA application. The most important/interesting/suspicious of which is the ability for them to mark OTAs as "urgent". What this means is that these updates will be downloaded without ever notifying the user, and they will be installed without asking the user for permission first. If this is how the kill switch is delivered, all users will see is the tablet randomly rebooting and installing an update, then the tablet would never boot again. As some of you might notice, this would match what has been happening to a few users already, both here and on reddit.
But that's not all. I've been connecting to the OTA servers using various serial numbers (both found and provided to me by a few people) in hopes of actually finding the update that bricks the device. The first serial number I've tried that wasn't mine was the serial number from the screenshot on the recall page. It revealed an interesting "urgent" OTA, named "SHIELD Tablet xx - LTE", which does nothing but flash a blob (which, among other things, contains the bootloader). Many more questions appear now, but the main one is: if this is nothing but a routine bootloader update, why is it marked urgent? And why is it not attached to any Android update? But this by itself is not enough to prove anything, as I could only obtain it with one serial number, so as far as I could have known, it might had just been an internal update or something similar. (update is linked and analysed in the second post below)
Today, however, one of the serial numbers I've been given by some of the people here (thanks for the help guys!) turned out to have the same update waiting for it the next time it connected to the Internet. This rules out the possibility of an internal update, so the next somewhat obvious possibility is that this is the kill switch. Mind you, I still have no direct way of proving this without flashing the ZIP to see what happens (which I'm not planning to do myself), but I will keep checking on the other serial numbers I've gotten to see if this update turns up for them too.
The same person who has given me this serial number has also tested running the old tablet on the latest stock Android version but with TegraOTA removed, and, as expected, the tablet is still working perfectly fine now. Your mileage may vary.
How can I know if the kill switch has been triggered for my tablet?
Go to http://shield.bogdacutu.me/ and enter the full serial number of your old tablet. If the next OTA returned is "SHIELD Tablet xx" "ST - yy", the kill switch has been triggered for your tablet.
Warning: the serial number from the box of the tablet and the one etched on the side of the tablet are not complete, as they only contain the first 13 characters of the full (20 characters) serial number. You can get the full serial number from Android (Settings -> About -> Status), from the bootloader (it will be on the screen when you boot into bootloader mode), or from your computer if the tablet is or (in some cases) if it was previously connected, using various tools such as USBDeview. Example: 0413714803249000a4cf (you can try this on the page and it will return that the kill switch is activated).
Why would I want to also do the fix on my new tablet too?
The update is signed by Nvidia, and communication with the OTA server does not use HTTPS, so, for example, a malicious WiFi network could MITM your connection and cause this update (as well as any other signed update) to be flashed to your new tablet without your permission, thus permanently disabling it too. If you have the stock recovery, only updates signed by Nvidia can run. The story might be slightly different if your recovery doesn't enforce signature verification (such as TWRP and CWM by default).
Can I still get updates from Nvidia after doing this?
Not directly, but people will post OTA download links here on xda when new updates get released. I'd personally recommend that you wait before flashing though until someone here checks the new update to confirm that there's no new way for Nvidia to kill your tablet.
Many hours of work have gone into investigating this. Even if it doesn't help your specific scenario, consider hitting that Thanks button, so that I can at least know it wasn't for nothing.
I'd also like to thank the people who have given me their serial numbers to use for testing again, this wouldn't have been possible without their help: @Beauenheim, @Jackill, and @runandhide05 (who has even volunteered to test removing TegraOTA with the latest update on his old tablet :highfive
Fragments of code from TegraOTA.apk
< screenshots temporarily removed >
Also, from what I've seen so far, the update isn't delivered instantly after activating the new tablet. I don't know exactly what the rule is, but out of the 4 serial numbers that I have, only 2 have this update waiting for them.
EDIT: One more serial number from the ones I have has gotten the xx update. Only one left...
EDIT 2: All the serial numbers I have have the urgent OTA waiting for them now.
"SHIELD Tablet xx" - Update Analysis
OTA URL: http://ota.nvidia.com/ota/data/post...wf-full_ota-32256_554.0168.20150624152335.zip
yy OTA URL: http://ota.nvidia.com/ota/data/posted-roms/uploaded/st---yy--092704233775---7294.20150819152732.zip (if you don't know what you're doing, DO NOT DOWNLOAD THIS, it's very likely that this will permanently brick your device upon flashing it!!!) - also attached to this post in case this link becomes invalid
updater-script is the first file we check:
Code:
getprop("ro.product.device") == "shieldtablet" || abort("This package is for \"shieldtablet\" devices; this is a \"" + getprop("ro.product.device") + "\".");
nv_copy_blob_file("blob", "/staging");
reboot_now("/dev/block/platform/sdhci-tegra.3/by-name/MSC", "");
Suspiciously enough, this only flashes a blob to the staging partition. But what exactly does this blob do, you might ask? Well, the blob actually contains data for 9 partitions, which are automatically replaced during the next boot (before the bootloader does anything else at all, so once you've rebooted, there's no going back) with the contents present in this blob. The 9 partitions are as follows (also detailing comparison with files from update 3.1):
BCT (Boot Configuration Table) - stores some information that is needed for the device to find the bootloader stored on the other partitions, initialize the RAM and some other stuff
Status after update: probably corrupted - the previous OTAs have binary BCTs, but this update replaces it with a text file (which, while it does contain somewhat relevant information, is likely not a valid format). If this is corrupted, it's enough for the device not to be able to boot anymore.
BMP (boot logo) - intact
DTB - intact
EBT (part of the bootloader) - has a zeroed out region
NVC (part of the bootloader) - intact
RBL (part of the bootloader) - has a zeroed out region
RP4 (landscape boot logo) - intact
TOS (Trusted OS - probably part of the bootloader too) - has a zeroed out region
WB0 (related to the boot process, source file is named "nvbootwb0.bin") - has a zeroed out region
The update also contains a few other files, but those are not used at all (probably leftovers from the 5.1 AOSP update template that they are using).
DO NOT DOWNLOAD THE ATTACHMENT IF YOU DON'T KNOW WHAT YOU'RE DOING. THIS IS THE XX OTA, NOT THE ZIP THAT REMOVES TEGRAOTA!
Just as I suspected!!
Thanks a lot this is great. So the silent updater can force updating even with a custom recovery like cwm?
How to install the provided zip?
Thanks again.
tecnoworld said:
Thanks a lot this is great. So the silent updater can force updating even with a custom recovery like cwm?
How to install the provided zip?
Thanks again.
Click to expand...
Click to collapse
CWM and TWRP are both compatible with OTAs, so yes, it can. If you completely erase the recovery (fastboot erase recovery), the update can't get flashed, but the tablet will still reboot (which is at least annoying).
You can flash the provided ZIP through CWM or TWRP (but please check through the file manager if /system/app/TegraOTA still exists after installing it, the ZIP hasn't gone through a lot of testing so it might not work properly in all cases)
tecnoworld said:
Thanks a lot this is great. So the silent updater can force updating even with a custom recovery like cwm?
How to install the provided zip?
Thanks again.
Click to expand...
Click to collapse
This was to be my question too... Normal ota updates will not flash if you have a custom recovery, so how would this silent ota update?
bluegizmo83 said:
This was to be my question too... Normal ota updates will not flash if you have a custom recovery, so how would this silent ota update?
Click to expand...
Click to collapse
Normal OTAs don't work through custom recoveries because they do various checks that usually fail when you have a custom recovery (such as if the system partition is modified, by rooting for example), this urgent OTA has none of those checks
Bogdacutu said:
Normal OTAs don't work through custom recoveries because they do various checks that usually fail when you have a custom recovery (such as if the system partition is modified, by rooting for example), this urgent OTA has none of those checks
Click to expand...
Click to collapse
Oh ok! Great explaination. Thanks for all your hard work on this! I'm flashing the zip now, i'll report back if it removes the file
Edit: Ok I flashed the zip, and TegraOTA is gone. Now I will finally turn on my new tablet and set it up!
So out of interest, what do you think the chances are that thisll work?
How did you find out if the update is waiting? FYI I flashed the ZIP... All is good and it booted fine on LTE 32Gb...
Plus the deleting of the TegraOTA File has gone through... So you really think the TegraOTA removal has stopped it?
How do i check if i have downloaded randomly that update?
Great post. Hopefully that's as far as Nvidia is going to go. I flashed a custom rom on my old tablet. I'm keeping my new one stock but deleting the system app per your post. Just in case Nvidia is spiteful when I don't return the old tablet. I don't want to leave them any option of nuking the new one.
fkofilee said:
So out of interest, what do you think the chances are that thisll work?
How did you find out if the update is waiting? FYI I flashed the ZIP... All is good and it booted fine on LTE 32Gb...
Click to expand...
Click to collapse
Decompiled the OTA application. Using information from there I can connect to the OTA server directly from my PC, and request updates for any given serial number and Android version combination.
I wouldn't have posted this if I weren't relatively confident in my findings
Bogdacutu said:
Decompiled the OTA application. Using information from there I can connect to the OTA server directly from my PC, and request updates for any given serial number and Android version combination.
I wouldn't have posted this if I weren't relatively confident in my findings
Click to expand...
Click to collapse
I know fella I appreciate it. Could you check my second point? 2 x Nvidia Shields would be awesome! One for Work, One For Home
fkofilee said:
Plus the deleting of the TegraOTA File has gone through... So you really think the TegraOTA removal has stopped it?
How do i check if i have downloaded randomly that update?
Click to expand...
Click to collapse
Yes, I think it did. If that update was downloaded on your device, it would have been too late (as it reboots instantly after the update is downloaded), so I wouldn't worry about that.
Bogdacutu said:
Yes, I think it did. If that update was downloaded on your device, it would have been too late (as it reboots instantly after the update is downloaded), so I wouldn't worry about that.
Click to expand...
Click to collapse
So heres an interesting one for you, using a logical mindset, if you receive your new tablet, activate it, the next time that the old one connects to the network, it downloads this update and bricks it? But it wont technically do this until the new tablet is turned on?
fkofilee said:
So heres an interesting one for you, using a logical mindset, if you receive your new tablet, activate it, the next time that the old one connects to the network, it downloads this update and bricks it? But it wont technically do this until the new tablet is turned on?
Click to expand...
Click to collapse
As mentioned in the OP, the update doesn't get delivered immediately after you activate the new tablet. But yes, the old tablet shouldn't get the update before the new one is activated.
Bogdacutu said:
As mentioned in the first post, the update doesn't get delivered immediately after you activate the new tablet. But yes, the old tablet shouldn't get the update before the new one is activated.
Click to expand...
Click to collapse
Sorry fella missed that part, I will be donating some funds when i get paid later this month Mucho Gracias!
Totally not related to this thread, but I just went to setup my new tablet and it's not letting me restore apps & settings from my old Shield Tablet... It doesn't show my old tablet as a restore option. I doubt checked and the old tablet is setup to backup all settings and apps though. Anyone else have this issue when setting up they're new tablet?
bluegizmo83 said:
Totally not related to this thread, but I just went to setup my new tablet and it's not letting me restore apps & settings from my old Shield Tablet... It doesn't show my old tablet as a restore option. I doubt checked and the old tablet is setup to backup all settings and apps though. Anyone else have this issue when setting up they're new tablet?
Click to expand...
Click to collapse
Upgrade to 5.1 on the new tablet without restoring any data, then do a factory reset and you should get the option to restore
Bogdacutu said:
Upgrade to 5.1 on the new tablet without restoring any data, then do a factory reset and you should get the option to restore
Click to expand...
Click to collapse
AWESOME man, thank you!!