On some devices we see a weird in which /metadata/apex will have a wrong
selinux label. This will effectively prevent such devices from getting
any apex updates. Since we haven't figured out a root cause for this
bug, it's safer to explicitly call restorecon on /metadata/apex to make
sure it's correct.
This change shouldn't affect a normal boot flow, since /metadata/apex
will already have a correct label and restorecon_recursive will be a
no-op.
Test: rm -Rf /metadata/apex && \
mkdir /metadata/apex &&
mkdir /metadata/apex/sessions
Bug: 149317789
Change-Id: I971ffe35c93bb79d9e71106c24515ec0ee70333a
If the flashed boot image is smaller than the block device, the AVB
footer will not be at the end of the partition. Although images are
normally created to match the partition size the GKI boot.img must work
on all devices, and the size of the boot partition will vary.
Copy the AVB footer to the end of the partition before flashing, if it
is not there already.
Bug: 159377163
Change-Id: I5a5e25fb54dc9d6a2930fda63434968808ffa1f0
Merged-In: I5a5e25fb54dc9d6a2930fda63434968808ffa1f0
Documentation is synchronized to match external, to ease updating.
blacklist is replaced with ignorelist or ignore depending on context.
Bug: 159345740
Test: none
Merged-In: I6db7ad321684759e3c5ac1f66f940b6e8a5709a0
Change-Id: I6db7ad321684759e3c5ac1f66f940b6e8a5709a0
Bug: 156225476
Test: Build for f2fs and ext4 device, make sure checkpoints roll back
and commit
Merged-In: I7a772ff712dec9e69df175de840d69d296c65923
Change-Id: I7a772ff712dec9e69df175de840d69d296c65923
Improve app startup performance before the new app is in the top-app
cpuset.
Test: boots, zygote64 in top-app stune group
Bug: 159201879
Change-Id: I3aad4b4b1d2f54db9e7ba86db8a655d8552bad0a
d3ecc66b9c "liblog: support extended logger_entry headers" removed
the logger_entry::msg variable and instead uses hdr_size as an offset
from logger_entry to where the message starts in parent log_msg
buffer.
In pmsg, hdr_size is not recorded and therefore uninitialized when it
was referenced, causing corruption when reading last logcat. This
change uses sizeof(log_msg->entry) instead.
Bug: 158263230
Test: last logcat works
Merged-In: Ic01e73bf4d8ba8419cc770138565aa1210a6078b
Change-Id: Ic01e73bf4d8ba8419cc770138565aa1210a6078b
(cherry picked from commit 34d7bd98ad)
There are two locks used by AppFuseBridge.
First is it's object lock, and the second is a mutex lock in app fuse library.
There are two oppsite routines to get those locks.
(Thread A) Got Java lock -> Try to get Native lock
(Thread B) Got Native lock -> Try to get Java lock
The order must be followed to obtain two locks.
If not, the dead lock will be caused.
Therefore we change the routine to get the mutex lock first, and the object lock later.
Signed-off-by: hyeeun.jun@samsung.com <hyeeun.jun@samsung.com>
Bug: https://issuetracker.google.com/issues/145707568
Bug: 157535024
Test: atest --test-mapping apex/blobstore
Change-Id: I0ab002da9a0b7ca2f518d50ab477a080cabe3788
As the EXT4_MAX_BLOCK_SIZE defined as 65536 which reached maxium value
of unsigned int. The superblock value maybe larger than 65536. This is
found by the Integer Overflow Sanitizer.
This patch fixed below boot error when userdata is corrupted:
init: processing action (fs) from
(/vendor/etc/init/hw/init.freescale.rc:221)
init: [libfs_mgr]Invalid ext4 superblock on '/dev/block/by-name/userdata'
init: InitFatalReboot: signal 6 init: #00 pc 00000000000af7e8 /system/bin/init
(android::init::InitFatalReboot(int)+208) init: #01 pc 00000000000afbd0 /system/bin/init
(android::init::InstallRebootSignalHandlers()::$_22::__invoke(int)+32)
init: #02 pc 00000000000006bc [vdso:0000ffff9691b000] (__kernel_rt_sigreturn)
init: #03 pc 000000000004e070 /system/lib64/bootstrap/libc.so (abort+176)
init: #04 pc 000000000003427c /system/lib64/libfs_mgr.so
(read_ext4_superblock(std::__1::basic_string<char, std::__1::char_
traits<char>, std::__1::allocator<char> > const&,
android::fs_mgr::FstabEntry const&, ext4_super_block*, int*)+1804)
Test: boot with corrupted ext4 superblock
Bug: 156200421
Signed-off-by: Haoran.Wang <elven.wang@nxp.com>
Change-Id: Ib1b69bf4623f69696cb637b226ec3359fc2ed409
(cherry picked from commit cb472b92e5)
SnapshotUpdateTest uses a relatively small super partition, which
requires a small alignment and 0 alignment offset to work. For the
purpose of this test, hardcode the alignment and offset.
This test isn't about testing liblp or libdm.
Fixes: 154355449
Fixes: 157437632
Bug: 158718136
Bug: 157633441
Bug: 154646936
Test: atest on devices with alignment of data partition >= 512KiB
Change-Id: I1d0474f028cc824bd4197d0228350395239b3b81
(cherry picked from commit 31739669e91c7a3afc5bee23e43bc45fb4154667)
Merged-In: I1d0474f028cc824bd4197d0228350395239b3b81
If the superblock of /data is corrupted, fs_mgr would skip check_fs.
But, e2fsck actually may reference backup superblock to recover
the filesystem. This fix gives fs_mgr second chance to fix corrupted
ext4 /data.
Bug: 156200421
Test: boot with corrupted ext4 superblock
Signed-off-by: Randall Huang <huangrandall@google.com>
Change-Id: Ieb89e7274d772962fe37927dcd62567dd5aa4657
(cherry picked from commit 72abd7b246)
