[Nexus 7 (2013) General] sfhub:
The OTAs always go through a verify stage first.

Every file being modified must either match the pre or post patch sha1 else the OTA fails immediately.

This check is done BEFORE any file is modified.

The apply_patch edify function is provided both the pre and post patch sha1. Presumably it will verify the post patch sha1 but I have never verified this.

You have 3 cases, either

OTA #1 passed successfully

OTA #1 did not pass successfully

OTA #1 never download nor ran

If #1, then the script must have

verified sha1 of PrebuiltGmsCore.apk matched pre-patch sha1

applied patch the PrebuiltGmsCore.apk and presumably verified post patch sha1

Given the operations being done I don't see how you can be in scenario #1 (successful OTA #1) and have left yourself with PrebuiltGmsCore.apk that didn't match the post sha1.

One possibility is corruption of file. However, it is unlikely everyone gets corruption on the same file with the same sha1.

Another possibility is the file gets changed after OTA #1 is done. This is also unlikely as /system is mounted r/o and if someone hasn't unlocked their bootloader, changes to /system are not persistent (ie they don't get written to non-volatile memory)

Ok so lets look at case #2, OTA did not run successfuly.

In the scenario I proposed, your /system was already updated from JWR66N-devkeys to JWR66N-releasekeys at the factory using an image. That means your fingerprint already matches JWR66N-releasekeys so you may ask if the fingerprint matches why would it even download OTA #1. My theory is OTA #1 was special and went through some special update process where it gets downloaded to every tablet regardless of whether the fingerprint suggests they need it or not. I've never seen an OTA that gets downloaded as part of your initial setup right after you enter wifi info and also goes ahead and wipes your data so it is certainly possible this type of OTA is reserved for special situations where you don't want to give the user any choice in the matter (like when Google releases a tablet with devkeys instead of releasekeys) It is not far-fetched to believe given the outlined behavior, this OTA is going through a "critical" patch procedure that might not match normal patch protocol.

Ok, so let's say you already had JWR66N-releasekeys from the factory, but the image they used has some slight differences like PrebuiltGmsCore.apk didn't match what would be expected after OTA #1 completed. Also it was missing some wallpaper (which wouldn't matter to the OTA unless the wallpaper was being patched)

Your tablet turns on, you enter your wifi, tablet searches for critical "don't give user choice" OTA patches, finds one and tells you it is going to reboot and install. Determination of whether you should receive this patch might be based not on fingerprint, but on whether this is the first time your serial # ever connected.

OTA #1 goes through verification stage where it first checks whether you are at JWR66N-devkeys OR JWR66N-releasekeys before continuing. If either of these match, it will continue (presumably it continues even you are at JWR66N-releasekeys in case the OTA failed half-way and needs to be rerun)

In my scenario, since your tablet shipped with JWR66N-releasekeys, the build.prop already has that fingerprint and it matches one of the version checks in OTA #1 so it is allowed to continue.

Next it checks every file being modified to see if it matches the pre or post patch sha1 (again presumably it would continue even if your file matched the post patch sha1 so the ota update could be rerun in case something failed the first time through)

In my scenario, since PrebuiltGmsCore.apk was shipped from the factory not matching the pre or post sha1, OTA #1 fails at this point.

You are left with build.prop that has the JWR66N-releasekeys fingerprint even though the OTA #1 never modified a single file because your build.prop came from the factory that way. You are left with your PrebuiltGmsCore.apk which also does not match the pre or post sha1 for OTA #1, again because that is how it came from the factory. Finally, it also explains why you are missing a wallpaper, because that is how it came from the factory.

So I will skip scenario #3 where the OTA never downloaded nor ran since you seem to recall it did reboot to run OTA #1 during the initial install.

Correct, so if your supposition is OTA #1 did run successfully, what explanation, in your scenario, would cause PrebuiltGmsCore.apk to no longer match the post patch sha1 from OTA #1? Keep in mind, after OTA #1 ran successfully, PrebuiltGmsCore.apk should match the post patch sha1. Then if by the time OTA #2 comes around, PrebuiltGmsCore.apk doesn't match the pre patch sha1 of OTA #2, then between those two points in time the change must have happened. Keep in mind the explanation above that /system is mounted read-only at runtime and if you have not unlocked your phone, changes to /system wouldn't even be persistent.

You might say then that PrebuiltGmsCore.apk didn't match the pre patch sha1 for OTA #1, but then the OTA #1 would have failed verification and you would be the scenario I suggested.

If you have a full nandroid backup right after the OTA #1, then there might be a recovery.log in /cache that will show you what happened.

As I explained, your build.prop could have already had the JWR66N-releasekeys fingerprint from the factory, so there is no need for OTA #1 to have modified any files. By having the JWR66N-releasekeys fingerprint in build.prop, that will prevent OTA #1 from re-downloading and installing for the "regular" OTA patch process that runs periodically *after* Android is done with initial install and is based on your fingerprint.

My explanation for why OTA #1 downloaded in the first place was that OTA was downloaded through a separate "emergency" mechanism that occurs *before* initial setup is complete and is based either on your serial # (and possibly, also your fingerprint). So the first time you go through initial install it sees your serial # has never connected so it sends you OTA #1 even if you had JWR66N-releasekeys fingerprint already. 2nd time around it doesn't give you OTA #1 because your serial # already connected. OTA #2 is downloaded using the normal updater process that checks for updates based on your build.prop fingerprint.

Yes, I agree it makes little sense the scenario described thus I came up with a different scenario where you could have the JWR66N-releasekeys fingerprint in your build.prop even if OTA #1 failed. My explanation is it was shipped from the factory with JWR66N-releasekeys ALREADY in build.prop.

IMO this is actually stronger support for my theory, as the file isn't even patched by the OTA so how did you lose it? My explanation is you never had it because the factory image you got for JWR66N-releasekeys was missing that file. If you had the same factory image as everyone else that is successfully running OTA #2, how did you lose the standard wallpaper?

Well that is my theory as to what happened.

Certainly I could be wrong which is why I call it a theory, but it was the only scenario I could come up with that could be consistent with all the verification steps being done.