RangeSet("2-10").monotonic gives a wrong result of "False". Fix the bug
and add more tests into test_rangelib.py.
Bug: 28760775
Change-Id: I04780571b45ecafd34040f405756b9745a9e21a5
(cherry picked from commit e8f756137c)
After applying update_target_files_incr_ext4.sh, some files may end up
occupying unsorted block fragments. In one example, an apk file has the
block range [258768-259211,196604]. The monotonic flag in rangelib sets
incorrectly for this example and leads to a bad input file for imgdiff.
After fixing the flag, bsdiff is called instead of imgdiff and the
incremental OTA package generates successfully.
Bug: 28760775
Bug: 28053885
Change-Id: Ib841bf449ff6a29314fc4a1b8fba941a6dc532ac
(cherry picked from commit cd1e16a761)
Modify the number of max blocks per transfer to reduce splitting of
large files during patch generation. This will reduce the size of
final incremental OTA updater package. In specific, the size limit
for each file to transfer is set to 1/8 cachesize instead of a fix
number.
Bug: 26472126
Change-Id: Iffb135e378c4c7a91640f2fc4c40e9e93d1fe4bb
(cherry picked from commit bb86e1d9c2)
We used to use the update-binary from the target build when creating
incremental OTAs. But for downgrade OTAs, we should use the one in the
source build instead, which is actually newer.
Bug: 27556903
Change-Id: Ib6415729b979dbffdebdda24902f7f560942801a
(cherry picked from commit 4996cf03d2)
Add --downgrade flag to ota_from_target_files.py script. It allows
generating an incremental OTA that updates from a newer build to an
older one (based on timestamp comparison). "post-timestamp" line in the
metadata file will be replaced by "ota-downgrade=yes". A data wipe will
always be enforced, so "ota-wipe=yes" will also be included in the
metadata file.
Bug: 26883782
Change-Id: Iaa05f662d948b7ab632a9fbb7051cc3f8bf68c21
(cherry picked from commit 5d1825664a)
When building incremental packages, the info_dict from the source build
should be the one in use. We have done that for most of the partitions
(system and etc.), and should pass that to vendor's script as well.
Also includes the CL in commit aac4ad56b6
that fixes a bug in commit 6f0b219ac5.
Bug: 24898607
Change-Id: I4ea6037dad7061e1683661fc4c394fa3a7a7c5cd
(cherry picked from commit 6f0b219ac5)
This CL changes to use a fixed timestamp only when packaging
into the target_files zip.
Bug: 24377993
Change-Id: I01d136f4b99e1eff80c559192d93db83a3c5c0a4
(cherry picked from commit 822f5840c0)
* commit 'b16edb5f3ef9032b7e19c29aac2496c34bb8ac76':
add unique ID to each windows download link. These IDs are necessary for the TOS wall to identify which link should be applied to the download button.
These IDs are necessary for the TOS wall to identify which link should be applied to the download button.
Change-Id: I1b5b8b516a5b8d7fd8433c02011cb4fb2044b71f
The signing process requires the boot and recovery images be signed
by CROS-Signer, which is done after a signed_target_files.zip is
available. Once the boot/recovery images are signed, we need
to insert it back into signed_target_files.zip and regenerate the
system.map and verity tree. The script (add_img_to_target_files) does
this operation and needs to be aware of verity specific flags.
Bug: 23831896
Change-Id: Id24e878161052c768b74da1231b97eb0574b4c8b
In BBOTAs if the last block of a DataImage is padded, we should always
write the whole block even for incremental OTAs. Because otherwise the
last block may be skipped if unchanged, but would fail the post-install
verification if it has non-zero contents in the padding bytes.
Bug: 23828506
Change-Id: I6f6789eec568ed0b808b9e425f5ecdbea1bdf446
(cherry picked from commit 7589e961a7)
For file-based OTAs, symlinks in the source build but not in the target
build will be deleted. However, if a symlink is replaced by a regular
file in the target build, the file will be accidentally deleted when
applying (resuming) the same package again.
Verify the checksum of a symlink that will be unpacked or renamed to.
Delete the file only if it doesn't have the target checksum.
Bug: 23646151
Change-Id: I77bae035e39f2e0be25f7f6d71c5882464e3d50f
(cherry picked from commit 84006eacd0)
* commit '4ffdc8faf2c795027f38b6ef4685dd6d1179878e':
Fix bug that caused table of Studio links to result in "stand-alone" tools instructions. bug: 23570662
For BBOTA v3, we need to stash source blocks to support resumable
feature. However, with the growth of file size and the shrink of the
cache size, source blocks that represent a file are too large to be
stashed as a whole. CL in [1] solves the issue by replacing the diff
command with a "new" command. However, it may increase the generated
package size substantially (e.g. from ~100MB to ~400MB).
With this CL, if a file spans too many blocks, we split it into smaller
pieces by generating multiple commands. For the same case above, it
reduces the package size to ~150MB.
One potential downside is that after splitting, files like .jar,
.apk and .zip can no longer use imgdiff. We may lose the potential
benefit of using imgdiff for patch size reduction.
[1] commit 82c47981bd
Bug: 22430577
Change-Id: Iee1ad6543f3d40368e079e418cc31728e1ab3f48
(cherry picked from commit 9a5caf2c30)
When generating incremental BBOTAs (v2 and above), we need to ensure
that the needed runtime stash is below the given threshold. If it's
running out of space on /cache, we replace the command that uses a
stash with a "new" command instead.
This may increase the OTA package size, since it is carrying more full
blocks instead of patches. It gets even worse for large files that span
a number of blocks, because currently we will store all the blocks for
the file as "new" blocks if stashing cannot be satisfied. We may further
optimize by splitting them into smaller chunks so that most of them can
still be stashed.
Bug: 22430577
Change-Id: Ieae5243d461e3f899f613f76a380f6f7c3edb356
(cherry picked from commit 82c47981bd)
With block-based OTA v2 and v3, it requires stash space on the /cache
partition to back up blocks during an update. We need to ensure that
it doesn't exceed the partition size. Since there might be other files
on /cache as well, we use cache_size * threshold as the maximum allowed
size. The threshold defaults to 0.8, which can be overridden by command
line option '--stash_threshold'.
Change-Id: Ieee5d373c9bfb2ea401d85ca8a3adb491579de76
(cherry picked from commit 23ac404212)
* commit 'ed7e864a735f004f1dbb4a2db5261855b5693913':
fix a few bugs in the studio download button behavior: - make button text always white (avoid blue on blue during hover) - revise logic to add the platform name to download button to avoid weird duplicity bug on small screens - remove the animation script when clicking download before agree because it reloaded the page (unkown cause) depends on: https://googleplex-android-review.git.corp.google.com/#/c/752757/
- make button text always white (avoid blue on blue during hover)
- revise logic to add the platform name to download button to avoid weird duplicity bug on small screens
- remove the animation script when clicking download before agree because it reloaded the page (unkown cause)
depends on: https://googleplex-android-review.git.corp.google.com/#/c/752757/
Change-Id: I1b2b4ff9c0b0cbbd34f1c77a2b736fe3425a16e4
In ext4 filesystems, some blocks might be changed even being mounted
R/O, such as the superblock (block 0). We need to exclude such blocks
from integrity verification. Plus such blocks should always be
written to the target by copying instead of patching.
Bug: http://b/20939131
Change-Id: If9efab3d7a0071a87b4d4297daf7963c3b818afe
(cherry picked from commit ff7778166b)
* commit '71a33c4d5b010757423980b90681445ca2bb2be0':
Add the ability to display annotations in the generated docs (cherry-picked from commit 87c44d8a11) Bug: 8440225 Change-Id: I41c1c7909b283832b818b8860ffe370cd4328f20
