Add lz4 support in CowWriter/CowReader. Lz4 should offer faster
read/write performance but slightly larger COW sizes.
Download time: Reduced from 1264s to 825s (~35% faster)
Filesystem verification time: from 69s to 59s (~15% faster)
COW Size: 2.59GB to 3.21GB, (~25% regression)
Merge time: 37046ms to 27690ms (~25% faster)
Boot time: LZ4 is 2.7% faster
Overall, LZ4 offers faster read/write performance at the cost of 25%
space regression.
Test: th
Bug: 228478555
Change-Id: Ie521852fb3c9ff8a12e55b764c1eb1838f7b2181
```
std::vector<std::string> v2;
for (auto&& e : get_temporary_v1()) { v2.push_back(e); }
```
^^^ This is constructing v2 from a temporary object, which is an
unnecessary manual clone. We should just let copy-elision do its thing:
```
// Give compiler the chance to optimize this with copy-elision...
auto v2 = get_temporary_v1();
```
Also `lp_names` appends an extra ',' at its end. Just use
android::base::Join() here.
Bug: 235111004
Test: Presubmit GSI boot test
Change-Id: Ibe8ce7a29b8521e789aa0a99f7f6d31f3f9c70e9
Now that emulated FBE is no longer supported, there is no longer any
distinction between native FBE and emulated FBE. There is just FBE.
Referring to FBE as "fscrypt" is also poor practice, as fscrypt (the
Linux kernel support for filesystem-level encryption) is just one part
of FBE, the Android feature.
Therefore, rename fscrypt_is_native() to IsFbeEnabled().
Bug: 232458753
Change-Id: Ib4dcdf799833b91d326b4b6f7120b0a3d4f4fc31
If booting with debug ramdisk (ro.force.debuggable is true), override
the persistent property "persist.sys.usb.config" to always enable adb.
This ensures a consistent debug experience. The developer can expect
that after debug ramdisk (debug boot image) is flashed,
1. Device is rootable with (adb root)
2. adb is enabled automatically
3. no-auth (if $ADB_VENDOR_KEYS is used)
Bug: 223517900
Test: 1. Flash & boot user build, verify device doesn't have usb
debugging enabled.
2. Reboot to bootloader and flash vendor_boot-debug.img.
3. Boot and verify usb debugging is automatically enabled.
4. Enter Developer Options and manually turn off usb debugging.
5. Reboot and verify that usb debugging is automatically enabled.
Change-Id: I729e961d645f2dd521ead8ca30b5cb8eb1d9f909
When a process is started as a native service,
oom_score_adj is set to -1000 so that processes
are unkillable by lmkd.
During boot, snapuserd process is not started as a service;
hence, we need to set the oom_score_adj explicitly else in
the event of low memory situation, lmkd can kill the
process thereby device can never boot.
Bug: 234691483
Test: th and OTA on Pixel
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: Ic2c85aa470522b4bc847a16b4f5cebfc528ed3cf
Some partitions may not have build.prop files (and it's totally fine).
Rather than logging such failures as WARNING, load_property_from_file
now returns a Result<void> object so callers can manually log for
themselves.
Bug: 228389036
Test: boot and logcat
Change-Id: Ia4ad7eef34d572182a3f6e86547664ae31dfd29f
Mainline modules are not supposed to rely on 'on' action triggers in
their init scripts because events/properties are not guranteed to be
stable across many devices.
To reduce the potential risk of enabling 'on' for APEXes, for now, we
enable it for only Vendor APEXes.
When an init script in a non-Vendor APEX contains 'on' section, init
emits an error on parsing the script and skip the section.
For example, when init.rc in the ADBD APEX has 'on' section,
the following error is emitted on parsing the script.
init: Parsing file /apex/com.android.adbd/etc/init.rc...
init: /apex/com.android.adbd/etc/init.rc: 8: ParseSection() failed:
'on' is supported for only Vendor APEXes.
Bug: 232543017
Test: see above
Change-Id: I6509c8d2c6b632369d215128f740f9ed78858605
We have a case where a service is requested to be started and does
not appear to be running, but we see no indication that it is
actually starting. This log should be enough information to see
if init is in a bad state.
Bug: 232297944
Test: doesn't add too much spam
~/android/aosp/system/core/init :) adb logcat -d | grep "requested start" | wc -l
42
Change-Id: Ic07f250c98b200b9e5b4432200c3668c6ca0ff35
All the individual directories being treated specially by
FscryptInferAction() already have an explicit encryption action in the
corresponding mkdir commands. The explicit action is the source of
truth, so the special cases in FscryptInferAction() are unnecessary.
Also, some of these cases were outdated. For example, /data/app-staging
was changed from encryption=None to encryption=DeleteIfNecessary at some
point, but FscryptInferAction() was not updated. This is causing the
warning "Inferred action different from explicit one" to be logged.
Additional "Inferred action different from explicit one" warnings are
logged due to subdirectories of /data/apex being explicitly encrypted.
Change FscryptInferAction() to only do what it needs to do: check
whether the directory is a top-level directory of /data or not. Remove
the above-mentioned warning which is not useful.
Bug: 232554803
Change-Id: If6611d64107a19d242892c92dfea095577e193e5
To determine the default encryption action, the mkdir command checks
whether the given path is a top-level directory of /data. However, it
assumed a path without any duplicate slashes or trailing slash(es).
While everyone *should* be providing paths without unnecessary slashes,
it is not guaranteed, as paths with unnecessary slashes still work
correctly for all other parts of the mkdir command, including the
SELinux label lookup and the actual directory creation. In particular,
the /data/fonts directory is being created using 'mkdir /data/fonts/'.
The effect is that the mkdir command thinks that /data/fonts/ is *not* a
top-level directory of /data, so it defaults to no encryption action.
Fortunately, the full command happens to use "encryption=Require", so we
dodged a bullet there, though the warning "Inferred action different
from explicit one" is still triggered.
There are a few approaches we could take here, including even just
fixing the /data/fonts/ command specifically, but I think the best
solution is to have mkdir clean its path at the very beginning. This
retains the Linux path semantics that people expect, while avoiding
surprises in path processing afterwards. This CL implements that.
Note, this CL intentionally changes the behavior of, and thus would
break, any existing cases where mkdir is used to create a top-level
/data directory using a path with unnecessary slashes and without using
an explicit encryption action. There are no known cases where this
already occurs, however. No cases exist in platform code, and vendor
init scripts shouldn't be creating top-level /data directories anyway.
Test: atest CtsInitTestCases
Test: Booted and verified that a trailing slash is no longer present in
the log message "Verified that /data/fonts/ has the encryption
policy ...". Also verified that the message "Inferred action
different ..." is no longer present just above it.
Bug: 232554803
Change-Id: Ie55c3ac1a2b1cf50632d54a1e565cb98c17b2a6a
Instead of using config file path, use APEX's preinstalled path to
determine whether to use subcontext or not for APEX configs.
Bug: 232021354
Test: CtsInitTestCases, CtsBluetoothTestCases
Change-Id: Iba603f09602f0bec3113e2be3d15c62055c09e72
APEX configs have supported only 'service' definitions. For those
services relying on 'on' trigger actions, we had to have separate config
files installed in read-only partitions (e.g. /system/etc/init).
This was suboptimal because even though APEXes are updatable, read-only
partitions are not.
Now, 'on' is supported in APEX configs. Putting 'on' trigger actions
near to service definitions makes APEX more self-contained.
'on' trigger actions loaded from APEX configs are not sticky. So, events
happens before loading APEX configs can't trigger actions. For example,
'post-fs-data' is where APEX configs are loaded for now, so 'on
post-fs-data' in APEX configs can't be triggerd.
Bug: 202731768
Test: atest CtsInitTestCases
Change-Id: I5a01d9c7c57b07955b829d6cc157e7f0c91166f9
Replace libbacktrace with the new AndroidUnwinder object.
Bug: 120606663
Test: Ran unit tests.
Test: Added call of UnwindMainThreadStack() in DebugRebootLogging()
Test: and verified unwind data is logged properly.
Change-Id: Ia724f9485377d6d2c894283242a3c5653bf82768
To prevent bugs, directory creation and encryption should happen
together. /data/user/0 (and its "alias" /data/data) is a per-user
encrypted directory; such directories can only be encrypted by vold.
Therefore, move its creation to vold as well.
Besides closing the uncomfortably-large gap between the creation and
encryption of /data/user/0, this allows removing init's write access to
/data/user and similar directories (SELinux type system_userdir_file) to
prevent any such issues from being reintroduced in the future.
To also allow removing init's write access to /data/media (SELinux type
media_userdir_file), which also contains per-user encrypted directories,
also move the creation and encryption of /data/media/obb to vold.
Bug: 156305599
BYPASS_INCLUSIVE_LANGUAGE_REASON=Linux API ("slave" mount flag)
Change-Id: I7245251eeb56b345b6c7711482c0aa5848648edb
When system_server crashes or gets killed, it causes zygote to kill
itself, which in turn leads to killing all processes in the same
process group (all apps). This leaves empty process groups because
system_server is not there to remove them.
Purge empty process groups when init detects zygote death.
Bug: 228160715
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I0ce27eea28f8713e52033bbec2d5363a7b8ff5db
When bootchart is enabled its thread shares the mount namespace context
with the main thread. This prevents the main thread to switch the mount
namespace later with setns().
So, unshare() the mount namespace of the bootchart thread.
Bug: 229983560
Test: rebooted with bootcharting on/off
enter_default_mount_ns should succeeded.
Change-Id: Idac0d0efcb4f7f7d8a7cbcebf8fa2fa29f104c35
If there are snapshot metadata persisting in /metadata/ota/snapshots,
remove them before applying a new update. Make sure that
the snapshots are indeed invalid before removing them.
On a sidenote, add a comment in init.cpp related to
b/223076262.
Bug: 228250473
Test: 1: Apply OTA in recovery through adb sideload
2: Reboot
3: Apply OTA OTA again through update_device.py
4: Re-run Full OTA updates just from update_device.py
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: I116bbafae09042b9c391ccd58c102704571c214e
* changes:
DO NOT MERGE: Revert "init: Add more diagnostics for signalfd hangs."
DO NOT MERGE: Revert "init: Add diagnostics for signalfd epoll failures."
writepid usage to add a task to a cgroup was deprecated in favor of the
task_profile command. The reason is that writepid hardcodes cgroup path
and makes it hard to change it in the future, whereas task profiles
configure cgroup paths in one centralized place and are easy to change.
Log a warning when writepid is used with cgroups and try converting it
into a task_profiles command for well-known cgroups. If conversion is
not possible the writepid operation will still be attempted to avoid
breaking existing use cases and an error will be logged.
Bug: 191283136
Test: build and boot
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Ie58393468ef7d92ab0ffb41e6f339e36d21f7478
During process startup, system creates a process group and places the
new process in it. If process group creation fails for some reason, the
new child process will stay in its parent's group. This poses danger
when the child is being frozen because the whole group is affected and
its parent is being frozen as well.
Fix this by treating group creation failure as a fatal error which would
prevent the app from starting.
Bug: 227395690
Test: fake group creation failure and confirm service failure to start
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I83261bef803751759c7fd709bf1ccd33ccad3a0b
It could be the case that /dev/console is created at the first stage
boot. ueventd doesn't have a permission to relabel from tmpfs to
console_device, so we should try restorecon /dev/console, together with
/dev.
Bug: 193118220
Test: atest MicrodroidHostTestCases
Change-Id: Ic538bc9214d3996fe7b37fa2224c1f0c6eb373d1
