Also reset some more properties to make bootanimation work properly.
Test: adb reboot userspace
Bug: 148172262
Change-Id: I0154d4fe9377c019150f5b1a709c406925db584d
Some recent changes can have these logging functions potentially set
errno. This change places android::base::ErrnoRestorer at the entry
point of the public functions where we want to guarantee errno is
restored to ensure this will not happen again.
Test: build
Change-Id: Iab4170ab16b9c7301474a509ee42d38b370b91a4
Currently when vendor overrides a profile the profile object is being
replaced with a new one. However the old profile might have been
referenced by an aggregate profile and with such profile replacement
the aggregate profile is left referencing a stale object. Fix this by
replacing the content of the old profile with the content from the new
one instead of replacing the object itself.
Bug: 148311066
Test: override profiles referenced in aggregate profile and verify
Test: correct replacement
Change-Id: Iabddbf3580455e5263fedad6665cf52fb323e50a
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
In the current state, schedboost_enabled() is true if and only if
schedtune is in use. As a result, all tests conditioned by
schedboost_enabled() will be skipped on devices using uclamp since it is
and extension of the CPU controller.
Fix this by making schedboost_enabled() return true if either schedtune
or the CPU controller is enabled.
Bug: 44953631
Change-Id: Idaadf252c9cf411a176180ab8988d559ca8a1332
Signed-off-by: Quentin Perret <qperret@google.com>
When using partitions backed by /data, for example during a Virtual A/B
merge or "adb remount" on a Virtual A/B device, the userdata block
device is seen as in-use when /data mounts in second-stage init. This
subsequently prevents mount() or e2fsck from working. Metadata-encrypted
devices are not affected, because dm-default-key provides a wrapping
block device that can be used exclusively.
This patch addresses the problem by detecting when userdata has
device-mapper dependencies. If it does, and the device is not
metadata-encrypted, we introduce a dm-linear wrapper around userdata.
It is created on demand, but like logical partitions, it exists until
the device reboots.
Bug: 134949511
Test: adb remount, cuttlefish boots
Change-Id: Ifbfea1591a6e58978fdaffd6ef889afabd10e270
libfs_mgr_defaults uses the e2fsdroid binary, make this dependency
explicit.
Add also e2freefrag as a dependency in preparation for filesystem
fragmentation monitoring.
Bug: 146078546
Test: m + e2freefrag on device
Change-Id: I878d1b090809861c803f6b17fbb3813e03842a50
Signed-off-by: Alessio Balsini <balsini@google.com>
To allow apps with MANAGE_EXTERNAL_STORAGE permission and therefore
external_storage gid to access unreliable volumes directly on
/mnt/media_rw/<volume>, they need access to the /mnt/media_rw path.
This change doesn't break the FUSE daemon, the only process that should
have media_rw gid in R because the FUSE daemon accesses the lower
filesystem from the pass_through bind mounts of the public volume mount
itself so it doesn't need to walk the /mnt/media_rw path itself
Test: With FUSE enabled, a reliably mounted public volume is accessible
on /storage
Bug: 144914977
Change-Id: Ia3fc9e7483894402c14fb520024e2acca821a24d
The memcpy should be for 31 GPRs, [x0, x30]. Currently it (accidentally)
also copies over the SP register (which ends up being harmless, as the
layouts match, and the value is reassigned again anyway).
Separately, I'm including an optional change for the iteration order,
since LR is the x30 GPR, it makes slightly more sense to print it
immediately after x29. However, this is a change in behaviour, so I can
undo the change if you think it's not worth it.
Tested: atest libunwindstack_unit_test
Change-Id: Ib6b81f8ee3a9a526bfabe4b09b327f083c855fb8
This gid allows processes full access to public areas of external
storage. This includes the following:
1. EmulatedVolumes: All files and directories excluding the app
specific directories under Android/
2. PublicVolumes: Including 'unreliable' volumes (USB OTG) that are
not typically accesible to ordinary apps
Apps with the MANAGE_EXTERNAL_STORAGE permission will automatically
have this gid
Test: m
Bug: 144914977
Change-Id: I17da0b2367e356edc031d063e214574463afc985
Build a test apex with an INT_MAX version code for the purposes of
update/rollback testing.
Test: atest adbd_e2e_tests # in internal master
Change-Id: I0e616db03dcbc940af2741dfca5b4c5f50a5a654
On ext4, enable casefolding if it is requested, but not currently
enabled.
Test: Enable casefolding on device. Check fs configuration on /data
Bug: 138322712
Change-Id: I3d54ab8bf15f28cf52c5b4344aa3fa254af83d60
Recently, the maps for an elf in memory might show up looking like:
f0000-f1000 0 r-- /system/lib/libc.so
f1000-f2000 0 ---
f2000-f3000 1000 r-x /system/lib/libc.so
f3000-f4000 2000 rw- /system/lib/libc.so
The problem is that there is logic in the code that assumed that the
map before the execute map must be the read-only map. In the case
above, this is not true. Add a new prev_real_map that will point
to the previous map that is not one of these empty maps.
This will fix the backtraces that look like this:
#00 pc 0000000000050d58 /apex/com.android.runtime/lib64/bionic/libc.so!libc.so (offset 0x50000) (syscall+24) (BuildId: 5252408bf30e395d49ee270b54c77ca4)
To get rid of the !libc.so and the offset value, which is not correct.
Added new unit tests to verify this.
Added new offline test which an empty map between read-only and execute
map. Before this change, the backtraces had lines like
libc.so!libc.so (offset XXX) would be present.
Bug: 148075852
Test: Ran unit tests.
Change-Id: Ie04bfc96b8f91ed885cb1e655cf1e346efe48a45
This takes a lot of space, isn't convincingly useful, and makes it
likely that the far more valuable stuff that comes after it gets
truncated. So let's just drop it.
Bug: http://b/139860930
Test: manual crasher, presubmit
Change-Id: Ie417ffc07e3cb17e95fdb3d183f8c87de0f34b89
