| commit | 3bf8c650290b6fc1770128103ef9ff869ed8b5c7 | [log] [tgz] |
|---|---|---|
| author | Tao Bao <tbao@google.com> | Fri Mar 16 12:59:42 2018 -0700 |
| committer | Tao Bao <tbao@google.com> | Mon Mar 19 13:35:38 2018 -0700 |
| tree | 35940d67245682123ca8af455e89df4a94111df3 | |
| parent | 93a84dd9a685d9864326f31b9b5970bc1d5b7c20 [diff] |
releasetools: Handle two edge cases in FinalizeMetadata(). In FinalizeMetadata and PropertyFiles, we need to reserve space between the calls to Compute() and Finalize(). We used to put a 10-byte placeholder, in the hope of covering the 'offset:length' space for the metadata entry, as well as the possible value changes in other entries. However, this could fail in two possible cases: (a) metadata entry itself has a large offset (e.g. staying near the end of a 1-GiB package, where the offset itself has 10-digit); or (b) the offsets for other entries change substantially due to entry reordering. Note that for case (b), it's space inefficient to always reserve 15-byte for _each_ token in the property-files. This CL handles both of these two cases. For (a), we bump up the 10-byte to 15-byte, which is large enough to cover a package size up to 10-digit number (i.e. ~9GiB) with a metadata entry size of 4-digit. All these 15-byte will be used for the metadata token alone. For (b), we add a fallback flow that would retry one more time, but based on the already signed package that has entries in desired order. Bug: 74210298 Test: python -m unittest test_ota_from_target_files Test: Generate aosp-bullhead full OTA with '--no_signing' flag. Change-Id: If20487602d2ad09b3797465c01972f2fa792a1f1
This is the Makefile-based portion of the Android Build System.
For documentation on how to run a build, see Usage.txt
For a list of behavioral changes useful for Android.mk writers see Changes.md
For an outdated reference on Android.mk files, see build-system.html. Our Android.mk files look similar, but are entirely different from the Android.mk files used by the NDK build system. When searching for documentation elsewhere, ensure that it is for the platform build system -- most are not.
This Makefile-based system is in the process of being replaced with Soong, a new build system written in Go. During the transition, all of these makefiles are read by Kati, and generate a ninja file instead of being executed directly. That's combined with a ninja file read by Soong so that the build graph of the two systems can be combined and run as one.