1 page.title=Block-Based OTAs 2 @jd:body 3 4 <!-- 5 Copyright 2015 The Android Open Source Project 6 7 Licensed under the Apache License, Version 2.0 (the "License"); 8 you may not use this file except in compliance with the License. 9 You may obtain a copy of the License at 10 11 http://www.apache.org/licenses/LICENSE-2.0 12 13 Unless required by applicable law or agreed to in writing, software 14 distributed under the License is distributed on an "AS IS" BASIS, 15 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 16 See the License for the specific language governing permissions and 17 limitations under the License. 18 --> 19 <div id="qv-wrapper"> 20 <div id="qv"> 21 <h2>In this document</h2> 22 <ol id="auto-toc"> 23 </ol> 24 </div> 25 </div> 26 27 <p>You can enable block-based over-the-air (OTA) updates for new devices 28 running Android 5.0. OTA is the mechanism by which OEMs remotely update the 29 system partition of a device:</p> 30 <ul> 31 <li><b>Android 5.0</b> and later versions use block OTA updates to ensure that 32 each device uses the exact same partition. Instead of comparing individual 33 files and computing binary patches, block OTA handles the entire partition as 34 one file and computes a single binary patch, ensuring the resultant partition 35 contains exactly the intended bits. This allows the device system image to 36 achieve the same state via fastboot or OTA.</li> 37 <li><b>Android 4.4</b> and earlier versions used file OTA updates, which 38 ensured devices contained similar file contents, permissions, and modes, but 39 allowed metadata such as timestamps and the layout of the underlying storage 40 to vary between devices based on the update method.</li> 41 42 </ul> 43 <p>Because block OTA ensures that each device uses the same partition, it 44 enables the use of dm-verity to cryptographically sign the system partition. 45 For details on dm-verity, see 46 <a href="{@docRoot}security/verifiedboot/index.html">Verified Boot</a>. 47 </p> 48 49 <p class="note"><strong>Note:</strong> You must have a working block OTA 50 system before using dm-verity.</p> 51 52 <h2 id="Recommendations">Recommendations</h2> 53 54 <p>For devices launching with Android 5.0 or later, use block OTA updates in 55 the factory ROM. To generate a block-based OTA for subsequent updates, pass 56 the <code>--block</code> option to <code>ota_from_target_files</code>.</p> 57 58 <p>For devices that launched with Android 4.4 or earlier, use file OTA 59 updates. While is it possible to transition devices by sending a full block 60 OTA of Android 5.0 or later, it requires sending out a full OTA that is 61 significantly larger than an incremental OTA (and is therefore discouraged). 62 </p> 63 64 <p>Because dm-verity requires bootloader support found only in new devices 65 shipping with Android 5.0 or later, you <i>cannot</i> enable dm-verity for 66 existing devices.</p> 67 68 <p>Developers working on the Android OTA system (the recovery image and the 69 scripts that generate OTAs) can keep up with changes by subscribing to the 70 <a href="https://groups.google.com/forum/#!forum/android-ota">android-ota (a] googlegroups.com</a> 71 mailing list.</p> 72 73 <h2 id="File vs. Block OTAs">File vs. Block OTAs</h2> 74 75 <p>During a file-based OTA, Android attempts to change the contents of the 76 system partition at the filesystem layer (on a file-by-file basis). The update 77 is not guaranteed to write files in a consistent order, have a consistent last 78 modified time or superblock, or even place the blocks in the same location on 79 the block device. For this reason, file-based OTAs fail on a dm-verity-enabled 80 device; after the OTA attempt, the device does not boot.</p> 81 <p>During a block-based OTA, Android serves the device the difference between 82 the two block images (rather than two sets of files). The update checks a 83 device build against the corresponding build server at the block level (below 84 the filesystem) using one of the following methods:</p> 85 <ul> 86 <li><b>Full update</b>. Copying the full system image is simple and makes 87 patch generation easy but also generates large images that can make applying 88 patches expensive.</li> 89 <li><b>Incremental update</b>. Using a binary differ tool generates smaller 90 images and makes patch application easy, but is memory-intensive when 91 generating the patch itself.</li> 92 </ul> 93 94 <p class="note"><strong>Note:</strong> <code>adb fastboot</code> places the 95 exact same bits on the device as a full OTA, so flashing is compatible with 96 block OTA.</p> 97 98 <h3 id="Unmodified Systems">Updating unmodified systems</h3> 99 100 <p>For devices with <i>unmodified</i> system partitions running Android 5.0, 101 the download and install process for a block OTA remains the same as for a 102 file OTA. However, the OTA update itself might include one or more of the 103 following differences:</p> 104 <ul> 105 <li><b>Download size</b>. Full block OTA updates are approximately the same 106 size as full file OTA updates, and incremental updates can be just a few 107 megabytes larger.</p> 108 109 <img src="../images/ota_size_comparison.png" alt="comparison of OTA sizes"> 110 111 <p class="img-caption"><strong>Figure 1.</strong> Compare Nexus 6 OTA sizes 112 between Android 5.0 and Android 5.1 releases (varying target build changes)</p> 113 114 <p>In general, incremental block OTA updates are larger than incremental file 115 OTA updates due to:</p> 116 <ul> 117 <li><i>Data preservation</i>. Block-based OTAs preserve more data (file 118 metadata, dm-verity data, ext4 layout, etc.) than file-based OTA.</li> 119 <li><i>Computation algorithm differences</i>. In a file OTA update, if a file 120 path is identical in both builds, the OTA package contains no data for that 121 file. In a block OTA update, determining little or no change in a file depends 122 on the quality of the patch computation algorithm and layout of file data in 123 both source and target system.</li> 124 </ul> 125 </li> 126 <li><b>Sensitivity to faulty flash and RAM</b>. If a file is corrupted, a file 127 OTA succeeds as long as it doesn't touch the corrupted file, but a block OTA 128 fails if it detects any corruption on the system partition.</li> 129 </ul> 130 131 <h3 id="Modified Systems">Updating modified systems</h3> 132 <p>For devices with <i>modified</i> system partitions running Android 5.0:</p> 133 <ul> 134 <li><b>Incremental block OTA updates fail</b>. A system partition might be 135 modified during an <code>adb remount</code> or as a result of malware. File 136 OTA tolerates some changes to the partition, such as the addition of files 137 that are not part of the source or target build. However, block OTA does not 138 tolerate additions to the partition, so users will need to install a full OTA 139 overwriting any system partition modifications) or flash a new system image to 140 enable future OTAs.</li> 141 <li><b>Attempts to change modified files cause update failure</b>. For both 142 file and block OTA updates, if the OTA attempts to change a file that has been 143 modified, the OTA update fails.</li> 144 <li><b>Attempts to access modified files generate errors </b><i>(dm-verity 145 only)</i>. For both file and block OTA updates, if dm-verity is enabled and 146 the OTA attempts to access modified parts of the system filesystem, the OTA 147 generates an error.</li> 148 </ul> 149
