| commit | b6105dcba3a67e43c8df7cf331d58e8fb889a531 | [log] [tgz] |
|---|---|---|
| author | xunchang <xunchang@google.com> | Thu Dec 06 16:39:46 2018 -0800 |
| committer | xunchang <xunchang@google.com> | Wed Jan 16 12:59:13 2019 -0800 |
| tree | f5909cd57caa5fedaf49c42884a7ee4e78689957 | |
| parent | 885787f4d36ea9352a9dcfb9e232d5d665fbd297 [diff] |
blockimgdiff: selectively convert 'diff' commands to 'new' to reduce stash size We cannot simultaneously stash more blocks than the size limit imposed by the cache size. As a result, some 'diff' commands will be inevitably converted to new. We used to do this conversion blindly when iterating through the transfer list. This leads to an unintended large package. In order to choose the right transfers to convert, we calculate the size of the compressed data, and build a heuristic about the package size increase to remove each stash blocks. After the process, the given package size for the watch device further reduces from 186M->155M. In some rare cases, the removed stashed blocks don't directly contribute to the maximum simultaneously stashed size. For example, stash A: 10 blocks stash B: 5 blocks free B: 5 blocks <-- stash B has been freed before we reach max stashed blocks stash C: 10 blocks Converting these blocks lead to an uncertain result. On one hand, patches are generally smaller than the new data; while on the other hand, the regenerated graph may have fewer order violation and thus give some size reduction. But these cases are rare and it seems an overkill to consider all possible scenarios here. Bug: 120561199 Test: build non-A/B incrementals and check the size (p.s. it can be tested on all target files with customed cache threshold) Change-Id: I599420a91b80f1a1d83d22ee1b336b699050cfb4
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.