89fbb0f6d586b4111b9207438d5d047ba0ad6d5f |
|
10-Jan-2017 |
Tao Bao <tbao@google.com> |
releasetools: Replace print stmt with print(). So that it's compatible with Python 3. Test: pylint --pylint=pylintrc Change-Id: If06c135a492c94bedd713c8cbdf03155a502d5cd
/build/make/tools/releasetools/img_from_target_files.py
|
d42e97ebb45fdc5a30799a3f37e482948d318010 |
|
30-Nov-2016 |
Tao Bao <tbao@google.com> |
Build recovery-two-step.img for two-step OTAs. In two-step OTAs, we write recovery image to /boot as the first step so that we can reboot from there and install a new recovery image to /recovery. However, bootloader will show "Your device is corrupt" message when booting /boot with the recovery image. Because the recovery image encodes the path of "/recovery" as part of the signature metadata, which fails the verified boot. This CL generates a special "recovery-two-step.img" in addition to the regular recovery.img. This image encodes "/boot" when being signed, which will be flashed to /boot at stage 1/3 in a two-step OTA. Here are the desired changes: - 'IMAGES/recovery-two-step.img' exists in target_files.zip for non-A/B targets (e.g. bullhead). The image should not exist for targets that don't have a recovery partition (e.g. A/B devices like sailfish). - <device>-img.zip should not contain 'recovery-two-step.img'. - Nothing should change when building non-two-step OTAs. For two-step OTAs, 'recovery-two-step.img' should be included in the OTA package; 'updater-script' should flash this image to /boot at stage 1/3. - When building a two-step OTA with an input TF.zip that doesn't have IMAGES/recovery-two-step.img, it should use the existing IMAGES/recovery.img instead. Bug: 32986477 Test: Tested the steps above on bullhead and sailfish. Change-Id: I34e6c599bcf2011d4cd5c926999418b3975d6d0f
/build/make/tools/releasetools/img_from_target_files.py
|
db45efa64764c1de5c007384ab172ad817e1d295 |
|
28-Oct-2015 |
Tao Bao <tbao@google.com> |
Honor TARGET_NO_RECOVERY flag. Don't generate recovery.img when calling 'make dist' if TARGET_NO_RECOVERY is set. The build system passes the flag to the packaging script which then generates recovery.img conditionally. Bug: 25329471 Change-Id: Ifbc999300d5c31e897878f81e231ae7dd2aca660
/build/make/tools/releasetools/img_from_target_files.py
|
7a5bf8a645fea21ab4f8d67f900c16692643d166 |
|
22-Jul-2015 |
Tao Bao <tbao@google.com> |
releasetools: Support packaging for system_root_image. For system images that contain the root directory, we need to find the root directory at ROOT/ instead of BOOT/RAMDISK/. Change-Id: Ica345c8b1b03475f8ac6c44fd576045fcf17c882
/build/make/tools/releasetools/img_from_target_files.py
|
2c15d9eefe977db63d7561bde326f24fab31653d |
|
09-Jul-2015 |
Tao Bao <tbao@google.com> |
Pack file_contexts into target_files zip. file_contexts (specified by SELINUX_FC) is needed both when building and (re)packaging. We used to use the copy in out/ when building, and looked for the copy in BOOT/RAMDISK/ when packaging from target_files zip. With system_root_image enabled, the file_contexts needed for building and packaging might be different from the one on device. So we explicitly pack the file as META/file_contexts in target_files zip. Also refactor out the overriding of selinux_fc property into common.LoadInfoDict(). Change-Id: I94f9ea6671b3792c12c1c21573840743d63da39a (cherry picked from commit aa7318c3849095aeb3bea00efbf303c0c40a089d)
/build/make/tools/releasetools/img_from_target_files.py
|
2ed665a033c587b276b1615516e5354e2ace47cd |
|
01-Apr-2015 |
Tao Bao <tbao@google.com> |
Wrap zipfile.write(), writestr() and close() In order to work around the zip 2GiB limit, we need to wrap the related functions in zipfile. Calls to those functions should always be replaced with calls to the wrappers instead. Bug: 18015246 Change-Id: Ice494371ca6654e88ded2ae0eb680f51082effcb
/build/make/tools/releasetools/img_from_target_files.py
|
8b72aefb5a8ed4da28c6f83854e8babf53b9cb53 |
|
24-Mar-2015 |
Dan Albert <danalbert@google.com> |
Make releasetools pylint clean. This caught a few bugs/syntax errors (a few character classes were not escaped properly in regex patterns, some indentation was illegal, etc). Change-Id: I50637607524e68c4fb9cad7167f58a46b8d26b2c
/build/make/tools/releasetools/img_from_target_files.py
|
6701db814585431ee032a5dab26a9c9af2323c7e |
|
23-Mar-2015 |
Greg Hackmann <ghackmann@google.com> |
Allow system images larger than 2GiB, pt. 2 We need to patch zipfile during close() too, because it refers to the ZIP64 file size threshold when writing out the central directory Bug: 18015246 Bug: 19888174 Change-Id: I1b49d653d0831fcc2106808f86c929d7a2b22ff3 Signed-off-by: Greg Hackmann <ghackmann@google.com>
/build/make/tools/releasetools/img_from_target_files.py
|
8e0178d41b9eeb6754eda07292d78762e3169140 |
|
28-Jan-2015 |
Dan Albert <danalbert@google.com> |
Allow system images larger than 2GiB. Python 2.7's zipfile implementation wrongly thinks that zip64 is required for files larger than 2GiB. We can work around this by adjusting their limit. Note that `zipfile.writestr()` will not work for strings larger than 2GiB. The Python interpreter sometimes rejects strings that large (though it isn't clear to me exactly what circumstances cause this). `zipfile.write()` must be used directly to work around this. This mess can be avoided if we port to python3. The bug (b/19364241) in original commit has been fixed. Bug: 18015246 Bug: 19364241 Bug: 19839468 (cherry picked from commit cd082d4bfe917b2e6b97436839cbbbc67c733c83) Change-Id: I7b5cc310e0a9ba894533b53cb998afd5ce96d8c6
/build/make/tools/releasetools/img_from_target_files.py
|
f21cb5a2198b843fe1c8e9577cc2ad61e0f5cfb4 |
|
12-Aug-2014 |
Doug Zongker <dougz@google.com> |
save file block allocations in target_files make_ext4fs can now output a file listing the blocks used for each file in the image. Request this file and save it in the target_files; it will be used for future improvements to block OTAs. Bug: 16984795 Change-Id: Id1e60465e3b5a9d126a7934b4d089cf34d8fec44
/build/make/tools/releasetools/img_from_target_files.py
|
3c84f569487c4e59baa332be33b5430fdefb76b3 |
|
31-Jul-2014 |
Doug Zongker <dougz@google.com> |
store images in target-files Store sparse images in the target-files, and use those (when they're available) for building block OTAs. - New script add_img_to_target_files is added to make the images and add them to the IMAGES/ subdir in the target-files. It gets run from the Makefile when building a target-files. - img_from_target_files becomes mostly vestigial: it creates the img.zip by just copying the images out of the target-files. (It still knows how to build images for use on older target-files.) - ota_from_target_files uses images from the target-files in preference to rebuilding images from the source files. - sign_apk_target_files builds images and includes them in its output target files (even if the input target-files didn't have them). Bug: 16488065 Change-Id: I444e0d722d636978209467ffc01750a585c6db75
/build/make/tools/releasetools/img_from_target_files.py
|
4d09dcb2c6d5e2fe8e8ed0780ee2da6ac8bda3c4 |
|
27-Jun-2014 |
JP Abgrall <jpa@google.com> |
releasetools: only allow yaffs to have no userdata image size (fix build) In the past, there was an exception for ext-base fs types to deal with the lack of image size. Back then it was only yaffs and ext*. So now we explicitely only allow yaffs to have no userdata image size. Change-Id: Ie354ee6222a58228dbcce2c6934971a0737422af Signed-off-by: JP Abgrall <jpa@google.com>
/build/make/tools/releasetools/img_from_target_files.py
|
c8b4e849f10f3a382694b00453b3f49608c83b48 |
|
17-Jun-2014 |
Doug Zongker <dougz@google.com> |
full support for OTA of vendor partitions Make vendor partition a first-class member of the OTA system (for target_files that contain a VENDOR/ subdirectory). Build vendor images in a way that is compatible with block-based OTA. Support updating the vendor partition in both full and incremental, block and file OTAs. In most cases this is handled by refactoring the existing code to handle the system partition to handle either, and then calling it twice. Currently we don't support incremental OTAs from a target-files without a VENDOR subdirectory to one with one, or vice versa. To add or remove a vendor partition a full OTA will need to be done. Bug: 15544685 Change-Id: I9cb9a1267060bd9683a9bea19b43a26b5a43800d
/build/make/tools/releasetools/img_from_target_files.py
|
8282282122a22f87c94862e97674bf48fd921d48 |
|
16-Jun-2014 |
Doug Zongker <dougz@google.com> |
use fs_config and file_contexts from target_files When building images, we want to use the file_contexts and fs_config data contained in the target_files zip, rather than whatever happens to be in the current client. Change-Id: I13df2405898039f5a9b4bb4837147e76b31b068a
/build/make/tools/releasetools/img_from_target_files.py
|
f8824aff68f63cf5484063bda4d5342034eb82c0 |
|
03-Jun-2014 |
Ying Wang <wangying@google.com> |
Allow to build the update.zip for emulator build. img_from_target_files.py just skipps the boot.img and recovery.img since there is no kernel or recovery.fstab for emulator. Bug: 15383279 Change-Id: I4035193e6ab933194ff1417dfae4eab963fe5301
/build/make/tools/releasetools/img_from_target_files.py
|
15d5348e6cc7a6fdae792ab308c23cb564e10f0b |
|
14-May-2014 |
Geremy Condra <gcondra@google.com> |
Reopen temporary system image to avoid stale data. NamedTemporaryFile's aggressive caching behavior can cause an issue where changes made by another process aren't visible even after the fseek() below or a flush(). To avoid this, simply open the file again and read from the fresh version. This fixes an issue where verity metadata written by append2simg doesn't become visible to img_from_target_files. Change-Id: I291fb3a95d5b532218ac6205ecc9e9b4f3a36bd4
/build/make/tools/releasetools/img_from_target_files.py
|
5fad2039bbd4e55d671106c8b39a6e451b85ac23 |
|
24-Feb-2014 |
Doug Zongker <dougz@android.com> |
handle don't care regions in the system image The system partitions has regions that we shouldn't write and can't depend on the contents of. Adds a new script to generate a map of these regions (using the sparse image as input), and include the map in the package zip so it can be used when writing or patching the system partition. Also fixes a bug where the wrong SELinux file contexts are used when generating incrementals. Change-Id: Iaca5b967a3b7d1df843c7c21becc19b3f1633dad
/build/make/tools/releasetools/img_from_target_files.py
|
d75d7128cec052beb13376c711082ee68bb45b0a |
|
20-Feb-2014 |
Geremy Condra <gcondra@google.com> |
Merge "Add support for block incremental OTAs"
|
36bd365625e6beba77698a93795a603180a5b476 |
|
07-Feb-2014 |
Geremy Condra <gcondra@google.com> |
Add support for block incremental OTAs Change-Id: Ie72015e34ed8d7595a5c74c8df41cba73275afab
/build/make/tools/releasetools/img_from_target_files.py
|
cf6d5a90740e50e03d9f16c6fd449d90d396f924 |
|
18-Feb-2014 |
Doug Zongker <dougz@android.com> |
bump releasetools python requirement to 2.7 These scripts already use some post-2.4 features, so let's make it official: Python 2.7 is needed to run them. Change-Id: I256e9ed99b0b62abe4e22a7b1f811acb7419e88e
/build/make/tools/releasetools/img_from_target_files.py
|
01ce19c95f358ac8ef9bb939d2637ac976320401 |
|
04-Feb-2014 |
Doug Zongker <dougz@android.com> |
make full OTAs block based Instead of writing individual files and fixing up their metadata, make full OTAs contain a system image and simply write it to the block device. This is only done for target-files that already contain the recovery flashing information, older target-files still get a file-based full OTA. Bug: 12893978 Change-Id: If7586083c8f275e24fec49d260af5b5aff4a0a88
/build/make/tools/releasetools/img_from_target_files.py
|