Scoped storage has some unique requirements that are hard to implement
with the two mount namespaces, because the daemon that does the mounting
(vold) lives in a different namespace than the processes using those
mounts.
In particular, /mnt/installer is a special bind mount that should
receive mount events under /mnt/user, but at the same time only
only propagate mount events under /mnt/installer to /mnt/installer in
the other namespace. More details in the code.
Bug: 134706060
Test: /mnt/installer shows up and is setup correctly.
Change-Id: I6dab5ace5a345d9d684a9f1ae94c833fc294d49e
While handling the fatal signals and abort, exits from the signal
handler to panic the system if "androidboot.init_fatal_panic" in cmdline
is configured as "true".
Bug: 146818493
Change-Id: I59fffb7598ce981383ae24961a97fd2fd8e8d64e
Commit Ida1a6da988c10d364b3ccdaa6c5d63e5264d1b27 allows specifying
AVB-related partitions to be probed in first-state mount, e.g.,
"avb=vbmeta_system" in the fs_mgr_flags will make init wait uevents
for vbmeta_system partition, which is required for AVB verification.
However, when specifying "avb=dtbo" to chain a /dtbo partition, first-stage
init will emit the following error as it assumes all partitions are
verified by Hashtree descriptors.
init: [libfs_avb]Hashtree descriptor not found: dtbo
This change fixes this by skipping raw partitions for first-stage mounting,
where raw partitions should already be verified by bootloader with Hash
descriptors. Although first-stage init does not perform Hash verification,
it still reads all Hash/Hashtree descriptors to calculate then compare
the "VBMeta Digest" passed from bootloader.
https://android.googlesource.com/platform/external/avb/#The-VBMeta-Digest
The following is an example of a fstab entry to chain /dtbo partition:
/dev/block/bootdevice/by-name/dtbo /dtbo emmc defaults slotselect,avb=dtbo,first_stage_mount
Bug: 146935233
Test: enable /dtbo as a chain partition, then boot the device
Change-Id: I590f1d9b78ef89b5aef21cb7bf19fdb90b27f808
Marks this CTS test module as supporting secondary_user, meaning that
the tests are eligible to be run from a regular Android user other
than the system user (i.e. other than user 0).
Note that 'user' here refers to the concept of users in Android
Multiuser; it is NOT the same as a uid.
Bug: 141773058
Test: module passed with secondary_user params
(--enable-optional-parameterization --module-parameter secondary_user)
Change-Id: Ic8d29cabe2542d75c8f873b677550db9f11b3050
The apex data directories must be accessed by apexd in order for it to
perform snapshot and restore as part of the rollback process. As apexd
runs as root, this CL changes the apex data directories under /data/misc
to be owned by root.
Bug: 141148175
Test: Build and flash; check permissions are set correctly.
Change-Id: Ib534e705802c06900884a15f39fee257d4987f4c
When BCB (bootloader message structure inside of misc partition) is
malformed (contains some non-printable characters in its fields),
"reboot recovery" command won't be able to write required string to
"command" field. It can happen for example when partition table was
created anew and 'misc' partition area contains some garbage. Also this
behavior can be emulated with this command:
$ fastboot erase misc
which leads to 'misc' partition to be filled with 0xFF characters. Hence
this code:
if (boot.command[0] == '\0') {
won't let us to set new string to "command" field. Let's check if
"command" field is malformed and fix it, before actually checking for
previously set content.
"fastboot erase" shouldn't be used for testing purposes though, as it
doesn't work sometimes due to alignment, on bootloader side:
Erasing blocks 6144 to 6144 due to alignment
........ erased 0 bytes from 'misc'
Instead one might use "dd" command to fill 'misc' with 0xFF's:
$ dd if=/dev/zero ibs=2k count=1 | tr "\000" "\377" >misc.img
$ fastboot flash misc misc.img
Test: Fill 'misc' partition with 0xFF's, then do "adb reboot recovery"
Change-Id: Ica8ca31012b9b2249645e7305830c07a20dd013c
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Current linkerconfig targets for specific output file. However,
linkerconfig will generate more than 1 file based on APEX modules, so it
should take argument for target directory rather than target file. This
change updates linkerconfig's argument to point output directory.
Bug: 146993126
Test: m -j passed & Cuttlefish succeeded to boot
Change-Id: I3a720a047077688582436aabd307adafeafc5398
Since I was there, added two more properties to reset, and switched
ordering of sys.init.updatable_crashing and
sys.init.updatable_crashing_process_name setprops to make sure that
process name is already set when apexd/PackageWatchdog get's notified
about sys.init.updatable_crashing.
Also fixed a typo in what HandleUserspaceReboot function.
Test: adb reboot userspace
Bug: 135984674
Change-Id: I954ec49aae0734cda1bd833ad68f386ecd808f73
There are two namespaces from init - bootstrap and default - and those
will have different set of APEX modules. To support difference between
two namespaces, linker config should be generated per namespace and each
namespace should use its own linker configuration. As a first step of
the work, this change will create different mount point for each
namespace, and re-generate linker config after APEX mount from each
namespaces.
Bug: 144664390
Test: m -j passed & tested from cuttlefish
Change-Id: Iac2e222376ec4b0ced6c29eed18b21d39ff0b1ba
The first_stage_mount code for DSUs predates both the DSU name and the
ImageManager abstraction. Move this code to ImageManager, so it can be
shared with overlayfs/scratch handling. And while we're here, rename GSI
to DSU for clarity.
Bug: 134949511
Test: dsu works
Change-Id: I9ef374bccc6cdbe2ada88baef4e7c0bc81b1e85e
When bind-mounting flattened APEX, use the apex name found in
apex_manifest.pb as the mount point, instead of the directory name which
might be different from apex name in case when the apex is overridden.
This allowed us to remove the special casing for the ART apex since we
/system/apex/com.android.art.release will be mounted to
/apex/com.android.art instead of /apex/com.android.art.release.
Bug: N/A
Test: m
Test: OVERRIDE_TARGET_FLATTEN_APEX=true m, device is bootable
Change-Id: Ibdde7002b9078db390e6672b0eb82c474925451d
The previous code would lazily check for 'exact' and accept any other
value as a prefix match. This should be a tighter check allowing only
'exact', 'prefix', or an empty string for this option.
Test: build fails if an invalid string is used for the match operation
Test: build succeeds normally
Test: `getprop -Z` shows exact vs prefix is differentiated correctly
Change-Id: I21dcb193810d65f468f8960967eabfd261f71e21
As part of Watchdog-triggered rollback logging, it would
be useful to know the service which has caused
updatable_crashing to be set. Store this in a new property
sys.init.updatable_crashing_process_name.
Test: manual
Bug: 138782888
Change-Id: Iffa38b2b746abbb5d823a8d69b7b8d2456836f4e
We do not need to set up all directories from system.img for the first
stage ramdisk, only those which first stage init mounts on.
Test: n/a
Change-Id: I877c623bac0b6dd2927ebdefa20da929ff98b341
This creates the directory /data/misc/apexdata, at the same time as other
directories under /data/misc. Then, when apexd has finished activating
APEXes, a directory is created under /data/misc/apexdata for every
APEX, with the same name as the APEX module name.
See go/apex-data-directories.
APEXes are discovered by scanning the /apex directory. It may be better
to delegate this process to a library, but it is proposed to defer that
change to a future CL.
Bug: 141148175
Test: Built and flashed, checked directories were created.
Change-Id: I639d6f490ae0b97f116ce38ff3ac348bd73aa20e
Currently linker config locates under /dev, but this makes some problem
in case of using two system partitions with chroot. To match system
image and configuration, linker config better stays under /linkerconfig
Bug: 144966380
Test: m -j passed && tested from cuttelfish
Change-Id: Iaae5af65721eee8106311c1efb4760a9db13564a
Such services will be re-parsed and added back to the service list
during post-fs-data stage.
Test: adb reboot userspace
Test: atest CtsInitTestCases
Bug: 145669993
Bug: 135984674
Change-Id: Ibb393dfe0f101c4ebe37bc763733fd5d981d3691
Init is no longer a special case and talks to property service just
like every other client, therefore move it away from property_set()
and to android::base::SetProperty().
In doing so, this change moves the initial property set up from the
kernel command line and property files directly into PropertyInit().
This makes the responsibilities between init and property services
more clear.
Test: boot, unit test cases
Change-Id: I36b8c83e845d887f1b203355c2391ec123c3d05f
During userspace reboot FscryptInstallKeyring will be called again, this
CL will make it second call a no-op, which IMHO is better than having a
special logic in init to conditionally call FscryptInstallKeyring
depending on whenever it's normal boot, or userspace reboot.
Test: adb reboot userspace
Test: checked in kernel logs that new keyring is not created
Bug: 135984674
Change-Id: I4ad5aee6887b7318fb1cd02bf1c7be8da6ece599
There are a few directories for builtin APEXes: /system/apex,
/system_ext/apex, /product/apex, /vendor/apex.
For devices with ro.apex.updatable=false, init should bind-mount
"flattened" apexes from all of above.
Bug: 144732372
Test: OVERRIDE_TARGET_FLATTEN_APEX=true m && device boot
Change-Id: If151145e6e3d966b202300ff3a0ddb5ec9fdaa87
A recently added subcontext test was failing beause it was running as
non-root, but GTEST_SKIP() didn't work as I expected it to.
In retrospect, all of these tests except for the property one, can
easily run as root, so this changes allows all of these tests to run
as root, while fixing the original issue.
Bug: 144707143
Test: root and nonroot subcontext unit tests
Change-Id: Ia835597701698f6be2101f92d6f4c9450bd3c7dd
~2007 a change was added that would allow oneshot services to
daemonize by not killing their process group. This was a hack at the
time, and should certainly not be needed now. I've resisted removing
the behavior however, as it hadn't caused any issues.
Recently, it was detected that the cgroups that these processes belong
to, would exist forever and therefore leak memory. Instead of simply
removing the cgroups when empty, this provides a good opportunity to
do the right thing and fix this behavior once and for all.
The new (correct) behavior only happens for devices with vendor images
built for Android R or later. Init will log a warning to dmesg when
it detects this difference in behavior has occurred.
Bug: 144545923
Test: boot CF/Coral and see no difference in behavior.
Test: boot CF with a service that daemonizes and see the warning.
Change-Id: I333a2e25a541ec0114ac50ab8ae7f1ea3f055447
sys.init.userspace_reboot.in_progress will be used to notify all
the processes (including vendor ones) that userspace reboot is
happening, hence it should be treated as stable public api.
All other sys.init.userspace_reboot.* props will be internal to /system
partition and don't require any stability guarantees.
Test: builds
Test: adb reboot userspace
Bug: 135984674
Change-Id: Ifb64a6bfae2de76bac67edea68df44e33c9cfe2d
