I'm sure everybody can agree, it makes almost no sense that the Nexus 9 is only now receiving a tiny maintenance update to 5.0.2 a couple of months after 5.1 came out. Nevertheless, that's how events are playing out, so we should at least know what's so special about this update. We've generated a changelog from AOSP, and honestly, there's not much to see.

Be aware, the Nexus 9 update goes from 5.0.1_r1 to 5.0.2_r3. However, since we've already seen the changelog for 5.0.1_r1 to 5.0.2_r1, we're keeping the previously seen changes in the old list, and producing a new one that includes only the commits that make up r1 to r3. Both changelogs are linked below for convenience.


With a grand total of 7 changes (not counting 5.0.1_r1 to 5.0.2_r1), there's not much to look at here. On top of that, three of the commits belong to CTS (Compatibility Test Suite) and have no bearing on functionality. Two more are just bug fixes from the Chromium project, one of which even appears in the 5.1 update for other devices.

Believe it or not, the remaining two adjustments might actually explain why a minor OTA is necessary before moving on to 5.1 or above. The first change was made to the code for Recovery, increasing the max_map_count, which is probably to support larger and more complicated OTAs. The second and far more obvious modification was made to the platform/frameworks/base project, which directs the PowerManagerService to allow for a longer timeout while "uncrypting" OTA packages. The extended description explicitly states that this is because large OTAs could take too long to write to storage.

There's no way to be sure, but it looks like a pretty massive (in size) update is anticipated, and this smaller update is all about preparing the Nexus 9 to handle it. It's possible that these changes might prevent a future OTA from bricking the Nexus 9 as part of the install process. At least, let's hope that's the case.

Again, the new changes are separated from the previously seen changes, and both are linked below.