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
Networking on old emulator device(a.k.a. goldfish) relies on RIL;
However, RIL is not available on ranchu device yet. For ranchu device
to have a functional networking, we need to add ethernet permission
and start dhcpcd_eth0 service on ranchu device. This CL adds ethernet
permission to both goldfish (which is harmless) and ranchu devices.
This addition was originally proposed by miroslav.tisma@imgtec.com
and the ethernet permission was only added to arm64 and mips64 after
discussion. With the ranchu device supporting more architectures,
it makes sense to allow this permission on all devices and all CPU
architectures.
related CL by miroslav.tisma@imgtec.com on AOSP:
b09fb84becf73bf2bc578ebf27910d75b79d668a
bug: 24070972
Change-Id: I81ac5d8901adee43784fe9dd45a170fb90bb824a
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
- MNC currently has security patches from the August OEM bulletin with patch date of Sep 1 plus only critical fixes from September OEM bulletin
- To be cherry-picked if picking up remaining fixes from September OEM bulletin to MNC
Change-Id: I2d1ba9c5a893727962f3f1837df1dd9df49e44f5
This reverts commit d07bfc5196.
Real fixes [1][2][3] are ready to merge. Time to revert the workaround.
[1] commit d47d8e1488
[2] commit 1fc67631ee
[3] commit 937847ae49
Bug: 22430577
Change-Id: Icd6623e8717c93ad1f12cd1ba43db5e006e928ad
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)
