This has kept adb_debug.prop from being installed.
Ignore-AOSP-First: fixes sc-release test breakage
Bug: 192432810
Test: build ramdisk-debug.img and see contents
Change-Id: I254579d2c6427213f40e9ae8e50d046e19390ba5
This test requires running test services, which causes test to crash
(and still incorrectly be reported as passing) when running on
non-rooted device.
Ignore-AOSP-First: reboot_test is not in AOSP yet
Bug: 190958734
Test: atest CtsInitTestCases
Change-Id: I3c5c9917d0a787d66272ccf4aefc57e6573841bc
This reverts commit 0a799bdfd6.
Now that the kernel bootconfig feature has been to updated to handle
mixed subkeys and values, androidboot.hardware parameter is supported.
Test: build and boot Cuttlefish with "androidboot.hardware=cutf_vm"
Bug: 191502832
Merged-In: I0e436a27730d20689bc6974562c3e88d744385db
Change-Id: I0e436a27730d20689bc6974562c3e88d744385db
The sysfs node of sd blk_device is /sys/fs/f2fs/sd-<num>, we shouldn't
skip partition number at this time.
Bug: 189257443
Test: access sd-<num> sysfs correctly
Signed-off-by: Guo Weichao <guoweichao@oppo.com>
Signed-off-by: Huang Jianan <huangjianan@oppo.com>
Change-Id: Ibcd7bb265f8fca9cd26f8770403f1bafad433acb
Androidboot parameters have moved from /proc/cmdline to /proc/bootconfig
so we need to check both places in reboot_utils.
"ro.boot.*" properties can not be used because this is initialized
before the properties are set.
Test: boot Cuttlefish with init_fatal_panic and
init_fatal_reboot_target in bootconfig and in cmdline
Bug: 191494101
Merged-In: I6c230496ec1c3632470d20ff4a31f28db96ea71b
Change-Id: I6c230496ec1c3632470d20ff4a31f28db96ea71b
adb_debug.prop is migrated too. And ramdisk_available is added to all
dependencies.
Bug: 187196593
Test: boot
Change-Id: I59cd149e0021211b8fd59c44b93bbf18dc8637bf
Merged-In: I59cd149e0021211b8fd59c44b93bbf18dc8637bf
This reverts commit 0a799bdfd6.
Now that the kernel bootconfig feature has been to updated to handle
mixed subkeys and values, androidboot.hardware parameter is supported.
Test: build and boot Cuttlefish with "androidboot.hardware=cutf_vm"
Bug: 191502832
Change-Id: I0e436a27730d20689bc6974562c3e88d744385db
Androidboot parameters have moved from /proc/cmdline to /proc/bootconfig
so we need to check both places in reboot_utils.
"ro.boot.*" properties can not be used because this is initialized
before the properties are set.
Test: boot Cuttlefish with init_fatal_panic and
init_fatal_reboot_target in bootconfig and in cmdline
Bug: 191494101
Change-Id: I6c230496ec1c3632470d20ff4a31f28db96ea71b
adb_debug.prop is migrated too. And ramdisk_available is added to all
dependencies.
Bug: 187196593
Test: boot
Change-Id: I59cd149e0021211b8fd59c44b93bbf18dc8637bf
Ban weird paths such as /../system or //vendor in first stage mount.
Add utility function fs_mgr_create_canonical_mount_point() that:
* mkdir(mount_point) to ensure mount_point's existence
* Test that realpath(mount_point) =?= mount_point
Bug: 188898525
Test: Presubmit
Test: Boot CF
Change-Id: Iaf2ec52701277f26cc81f3e15a47b6083a788334
Merged-In: Iaf2ec52701277f26cc81f3e15a47b6083a788334
(cherry picked from commit 3431d52675)
PD#SWPL-45884
BUG:187441275
Problem:
ueventd: coldboot took too much time
Solution:
1.The parallel restorecon dirs can be configured in ueventd.rc
2.Add 'parallel_restorecon_dir' keywords
parallel_restorecon_dir <directory>
Verify:
redi
Change-Id: Id5b13f18d36afb894891697f21ac63e78b3fe130
Signed-off-by: yuehu mi <yuehu.mi@amlogic.com>
Ban weird paths such as /../system or //vendor in first stage mount.
Add utility function fs_mgr_create_canonical_mount_point() that:
* mkdir(mount_point) to ensure mount_point's existence
* Test that realpath(mount_point) =?= mount_point
Bug: 188898525
Test: Presubmit
Test: Boot CF
Change-Id: Iaf2ec52701277f26cc81f3e15a47b6083a788334
Rename fs_mgr_overlayfs_mount_fstab_entry() to
fs_mgr_mount_overlayfs_fstab_entry() and move it out of
fs_mgr_overlayfs.cpp to make it available for user builds.
Add checks to unsure overlayfs mount point doesn't contain symbolic
link or /../.
Check the mount point with an allowlist if user build. The mount point
should either be /vendor, /product ... or their submounts, or strict
submounts of /mnt/vendor and /mnt/product.
Bug: 188862155
Test: Boot test with overlayfs mount entries on user build
Change-Id: I3b60dfa4b63cf2ae0754f53d1d08365aa7be1ee0
Merged-In: I3b60dfa4b63cf2ae0754f53d1d08365aa7be1ee0
(cherry picked from commit 23816e84ca)
* Add logs.
* Append "override_creds=off" overlayfs mount flag only if
fs_mgr_overlayfs_valid() returns kOverrideCredsRequired.
Pre-4.6 kernels or kernels without the override_creds patch don't
need or don't recognize the override_creds mount flag.
(Background: I832c8ca3fce0269bdef4ce988541adb7ba9662ed)
* mkdir(mount_point) before mount() to ensure the mount point exists.
This could happen if the mount point is in a tmpfs, such as /mnt.
Bug: 188862155
Test: Boot to normal with overlayfs mount entries in first stage fstab
Change-Id: I1a05696346610d7fd61de6d25c379520fd58ca9b
Merged-In: I1a05696346610d7fd61de6d25c379520fd58ca9b
(cherry picked from commit dcf1c1f462)
GetDmVerityDevices() should filter out overlayfs fstab entries in the
first place, so InitRequiredDevices() don't need to filter out overlayfs
pseudo device names.
Bug: 188862155
Test: Boot to normal with overlayfs mount entries in first stage fstab
Change-Id: I0ac8b7ac0f21daa0c191580d9349adf217854864
Merged-In: I0ac8b7ac0f21daa0c191580d9349adf217854864
(cherry picked from commit 87290f8e9b)
Rename fs_mgr_overlayfs_mount_fstab_entry() to
fs_mgr_mount_overlayfs_fstab_entry() and move it out of
fs_mgr_overlayfs.cpp to make it available for user builds.
Add checks to unsure overlayfs mount point doesn't contain symbolic
link or /../.
Check the mount point with an allowlist if user build. The mount point
should either be /vendor, /product ... or their submounts, or strict
submounts of /mnt/vendor and /mnt/product.
Bug: 188862155
Test: Boot test with overlayfs mount entries on user build
Change-Id: I3b60dfa4b63cf2ae0754f53d1d08365aa7be1ee0
* Add logs.
* Append "override_creds=off" overlayfs mount flag only if
fs_mgr_overlayfs_valid() returns kOverrideCredsRequired.
Pre-4.6 kernels or kernels without the override_creds patch don't
need or don't recognize the override_creds mount flag.
(Background: I832c8ca3fce0269bdef4ce988541adb7ba9662ed)
* mkdir(mount_point) before mount() to ensure the mount point exists.
This could happen if the mount point is in a tmpfs, such as /mnt.
Bug: 186342252
Test: Boot to normal with overlayfs mount entries in first stage fstab
Change-Id: I1a05696346610d7fd61de6d25c379520fd58ca9b
GetDmVerityDevices() should filter out overlayfs fstab entries in the
first place, so InitRequiredDevices() don't need to filter out overlayfs
pseudo device names.
Bug: 186342252
Test: Boot to normal with overlayfs mount entries in first stage fstab
Change-Id: I0ac8b7ac0f21daa0c191580d9349adf217854864
It's possible that CONFIG_ZRAM_WRITEBACK is y,
but userspace doesn't set the /sys/block/zram0/backing_dev,
so its value is 'none'.
It's the same with "CONFIG_ZRAM_WRITEBACK is not set".
Change-Id: I2df89ceee68e4685deef5113bada21be96779e9b
Signed-off-by: shisiyuan <shisiyuan@xiaomi.com>
The external firmware handler always has root group privileges because
it is forked/executed without setgid() by ueventd which has root
privileges. This patch calls setgid() with group ID specified in
ueventd.rc before execv().
Test: atest CtsInitTestCases
Signed-off-by: Suchang Woo <suchang.woo@samsung.com>
Change-Id: Id1430e783b0e409d55ac80fe213e81ba099729e2
Add a test to check the build fingerprint when the dynamic build
id is in use.
Bug: 186786987
Test: th
Change-Id: I44d6be0c18552f319bcb8d19cca5659ce580d26c
Background in http://go/compatible-build-fingerprint. To uniquely
identify the mixed build, we plan to append the unique vbmeta digest
to ro.build.id.
If BOARD_USE_VBMETA_DIGTEST_IN_FINGERPRINT is true, the build system
will not set ro.build.id. Instead, init will set it at runtime, by
appending the digest to the legacy build id.
Bug: 186786987
Test: build and boot a device with new build id
Change-Id: Idea57df599bfd6eede760671e2555541f7dc3f21
emulator migrated to bootconfig, we don't use
the kernel command line to pass userspace properties.
Bug: 182291166
Test: boot
Signed-off-by: Roman Kiryanov <rkir@google.com>
Change-Id: Iff2f627aec64b7ba2240444639acedc76a1aa806
This reverts commit 6cb4311f4d.
Reason for revert: no need to keep the compatibility now
Bug: 186485355
Change-Id: Iffdf3abebc17f32e36f3b3fe2b4f9c2592da9653
Test: TreeHugger
Add a new service flag SVC_STOPPING which tracks whether a service is
being manually stopped by init, and make the "reboot_on_failure" service
setting not apply when SVC_STOPPING is set.
This is needed for devices that use FDE, because otherwise the device
reboots during the following init script fragment:
on property:vold.decrypt=trigger_shutdown_framework
class_reset late_start
class_reset main
class_reset_post_data core
class_reset_post_data hal
... because that stops all services, including apexd which has been
marked with reboot_on_failure since
https://android-review.googlesource.com/c/platform/system/apex/+/1325212.
So init was killing apexd, then rebooting the device because apexd
"failed" due to having been killed. Making reboot_on_failure not apply
when init stops a service itself fixes the problem.
This is one of a set of changes that is needed to get FDE working again
so that devices that launched with FDE can be upgraded to Android 12.
Bug: 186165644
Test: Tested FDE on Cuttlefish
Change-Id: I599f7ba107e6c126e8f31d0ae659f0ae672a25e4
If precompiled vendor policy has system_ext hash, system_ext also has to
have its hash, to use precompiled sepolicy.
Bug: 186727553
Test: remove system_ext's hash and see sepolicy compiled in runtime
Change-Id: I4af3418d614156b5e9cd0b0116c2814ba994ee81
The existing code has a lot of references to the
`ro.boot.qemu` and `ro.boot.qemu.something` properties
which is not supported by the bootconfig if we place
everything under `androidboot.qemu`.
Bug: 182291166
Test: getprop | grep qemu
Signed-off-by: Roman Kiryanov <rkir@google.com>
Change-Id: Icb9d29c8dc39e1fa52a6f2ce43b4f42182b7995d
Currently the gki_4_19_pixel5 presubmit test uses an old
vendor_boot-debug.img from a release branch. Adding fallback
paths to load debug resources from /first_stage_ramdisk dir to
pass the presubmit.
This CL should be reverted later once the vendor_boot-debug.img
gets updated to store the debug resources on the root dir.
Bug: 186082603
Test: boot a device with boot-debug.img
Test: boot a device with vendor_boot-debug.img
Change-Id: I9fcd77fc5a60a15cff254e432e05f1c9122ad80d
Currently the debug resources might under /first_stage_ramdisk/*
of the ramdisk, if there is androidboot.force_normal_boot=1 in the
kernel cmdline to request init chroot into /first_stage_ramdisk dir.
To make a generic boot-debug.img works on devices with and without
this chroot, moving the debug resources to the root of the ramdisk.
And copy them for later use before the chroot.
Bug: 186082603
Test: boot a device with boot-debug.img
Test: boot a device with vendor_boot-debug.img
Change-Id: I052a92b2d26c7fdf749991fc55015ff68743efc2
init starts services in "bootstrap" mount namespace until the "default"
mount namespace is ready even when init's current mount namespace is
"default".
apexd and linkerconfig are those processes to set up the mount
namespaces: apexd activates apexes and linkerconfig generates linker
configs.
Previously apexd is allowed to be started in the "current" namespace by
checking its "service name"(it should be "apexd"). But there can be a
certain environment apexd is started in a different way. For example, in
microdroid, apexd is started using "exec -- /system/bin/apexd --vm"
because it wants to run in a different execution mode.
So, instead of checking the service name, its executable's path is
checked against to allow apexd to be started in the current mount
namespace.
Bug: 179342589
Test: MicrodroidTestCase (microdroid boots)
Test: cuttlefish boots
Change-Id: I7c2490e15d481c28ddf382d2d3fdf58a78e467ec
Only the exact same devpath uevent can launch external handler specified
in ueventd.rc. So, you should specify all possible devpaths, even
firmware with different filenames on the same device. Pattern mactching
can be used to simplify this.
Test: atest CtsInitTestCases
Signed-off-by: Suchang Woo <suchang.woo@samsung.com>
Change-Id: If3b7a2cabb8055bf4b768d928f0fc0012da3c177
'/sys/block/zram0/backing_dev' will exist even if zram is not swapped on in some devices. And there is no reason to ensure that zram is swapped on if '/sys/block/zram0/backing_dev' exists. So, if we want to kill backing_dev during userspace reboot, we should check if zram is swapped on first.
TEST: as follow
- adb root
- adb shell swapoff /dev/block/zram0
- adb shell echo 1 > /sys/block/zram0/reset
- adb shell setprop test.userspace.reboot.flag 1
- adb reboot userspace
- (wait reboot ending) adb shell getprop test.userspace.reboot.flag (1 will be show if successful)
Signed-off-by: luwei9 <luwei9@xiaomi.com>
Change-Id: Icca569cf8d64bc024b867dae2ab789fc9e76445a
emulator passes `android.checkjni` in the kernel
command which we want to use in
frameworks/base/core/jni/AndroidRuntime.cpp
Bug: 182291166
Test: getprop ro.boot.dalvik.vm.checkjni
Signed-off-by: Roman Kiryanov <rkir@google.com>
Change-Id: If9473aa9492fa09d8de7cc8fb08614380e4e15f3
emulator passes `android.bootanim=0` in the kernel
command line to disable boot animation.
Bug: 182336906
Test: boot emulator with -np-boot-anim
Signed-off-by: Roman Kiryanov <rkir@google.com>
Change-Id: Id89a6c92dd4724cac414ffbf8ee731b2bfcc7195
args[2](user name to run as) is used instead of args[1](devpath).
Test: atest CtsInitTestCases
Signed-off-by: Suchang Woo <suchang.woo@samsung.com>
Change-Id: Id271755993d55e332bad54d0414e2232071e5e8e
restrictions
Use the property ro.product.enforce_debugfs_restrictions to enable
debugfs restrictions instead of checking the launch API level. Vendors
can enable build-time as well as run-time debugfs restrictions by
setting the build flag PRODUCT_SET_DEBUGFS_RESTRICTIONS true which in
turn sets ro.product.enforce_debugfs_restrictions true as well enables
sepolicy neverallow restrictions that prevent debugfs access. The
intention of the build flag is to prevent debugfs dependencies from
creeping in during development on userdebug/eng builds.
Test: build and boot
Bug: 184381659
Change-Id: If555037f973e6e4f35eb7312637f58e8360c3013
Minor refactoring and renaming, goal is to make the follow-up patch
easier to read.
Bug: 184132970
Test: Presubmit
Change-Id: I66416161b30ac310934d901cbaf11bc926e2cbf7
So we can extend platform policies with target specific compat rules.
This use case surface in the context of system only upgrade, when the
vendor policy cannot be updated, then the system_ext partition can
contain target specific compat policies.
Bug: 183362912
Test: Presubmit
Change-Id: Ic6436eb8a269f07f932331dedf7dbaa629538ade
The emulator migrated to `ro.boot.qemu`.
Bug: 182291166
Test: presubmit
Signed-off-by: Roman Kiryanov <rkir@google.com>
Change-Id: Iaa3bdff5cc1efa79c21ae2dc2bdf7ec74731f66c
Since recovery mode doesn't switch root to /first_stage_ramdisk, we need
to update the debuggable file paths for recovery mode. Without this,
adb needs to be authorized in recovery mode even with a debug
vendor_ramdisk.
Bug: 182612208
Test: verify adb is authorized on pixel 5
Signed-off-by: Will McVicker <willmcvicker@google.com>
Change-Id: I557429e1834efcdd92ba0e135377055ffa677137
Some devices might not have system_ext or product partitions. But init
has been refusing to use precompiled sepolicy because init always checks
system / system_ext / product hashes, regardless of existence. This
makes system_ext and product optional, so hash check can be skipped for
non-existing partitions. Of course system is always checked.
Bug: 181640066
Test: boot microdroid and cuttlefish, see precompiled sepolicy works
Change-Id: I32c296fffd894c27097e8b4e10ade977a21d61ab
`ro.kernel.` is an emulator specific prefix.
Bug: 182291166
Test: presubmit
Signed-off-by: Roman Kiryanov <rkir@google.com>
Change-Id: Ie4a19127f05f3074ccb02bd055711e9b70702ba6
The parameter "androidboot.hardware" has been removed from bootconfig
and replaced by "hardware" parameter.
Test: launch_cvd with 4.19 and 5.10 kernels
Test: atest CtsFsMgrTestCases
Bug: 173815685
Change-Id: I627426ae1bd0a165b70b8f2584ec184abfb4236f
This check in export_oem_lock_status happens after PropertyInit() so
all of the ro.boot.* properties will be set. There is no need to import
the kernel cmdline again.
Test: build and boot cuttlefish
Bug: 173815685
Change-Id: I5df7c0105566d4617442dbb8e77eb26e465775f1
The androidboot.selinux property is loaded in a special way, because it
happens in the "selinux_setup" stage, and not the true second stage.
Allow it to be passed through bootconfig instead of only via the kernel
cmdline.
Bug: 173815685
Test: launch_cvd -extra_kernel_cmdline androidboot.selinux=permissive
Test: launch_cvd -guest_enforce_security=false [bootconfig method]
[..]
init: Permissive SELinux boot, forcing sys.init.perf_lsm_hooks to 1.
[..]
Change-Id: I92003c7a2dac5d6e7d0e0f4ee2757f86cc0087c7
The androidboot.android_dt_dir property is special, because it is loaded
to find out where to get the other DT properties from, and those DT
properties are supposed to override the cmdline/bootconfig ones. So, it
need special casing, and that special case lacked bootconfig support.
Bug: 173815685
Test: launch_cvd -extra_kernel_cmdline androidboot.android_dt_dir=/tmp
[..]
init: Using Android DT directory /tmp
[..]
Change-Id: Ie0958dd0a96394d65f6568653b754ea6f885212e
As parameters are moved from kernel cmdline to bootconfig,
first_stage_init needs to be updated to handle the new
location.
/proc/bootconfig should be checked first, if not present, then check
/proc/cmdline.
Test: launch_cvd
Test: launch_cvd with 4.19 kernel artifacts that do not support
bootconfig
Test: Both of the above configurations with --num_instances 0 or 4
Test: Both configurations with androidboot.boot_devices or
androidboot.boot_device set
Bug: 173815685
Change-Id: I03743f922351d58375e8b9a903899b8bc54bd71e
Any service which is executed when Runtime apex is mounted, but
linkerconfig is not updated can fail to be executed due to missing
information in ld.config.txt. This change updates init to have a status
variable which contains if current mount namespace is default
and APEX is not ready from ld.config.txt, and use bootstrap namespace if
it is not ready.
Bug: 181348374
Test: cuttlefish boot succeeded
Change-Id: Ia574b1fad2110d4e68586680dacbe6137186546e
This is a follow-up of I828ce999be6d786bf46dd5655dfda81d046906ab. The
change introduced a behavioral change that fstab is read twice: before
root is changed to /first_stage_ramdisk, and once again after that.
Previously, that happend only after the root is switched. That change
caused a problem when there is no fstab in DT and fstab is provided via
a file. The fstab file has been at
/first_stage_ramdisk/fstab.<hardware> because that file was supposed to
be read after the root switch.
With the change, init fails to read the fstab during the first attempt
because there is no /fstab.<hardware> at the moment. Here comes the
problem. Although it failed to read fstab, DoCreateService() is invoked
because ReadFirstStageFstab() doesn't report the failure; it returns an
empty fstab object. As a result, DoCreateDevices() is called but it
doesn't create the dm linear device because it couldn't find an fstab
entry having `logical` option.
Then after /first_stage_ramdisk becomes the root, the fstab file is
correctly read. But since the prior run of DoCreateDevices() is recorded
as 'done', init doesn't try to do that again; dm linear device is never
created. Then we fail to mount any of the logical partitions.
This change fixes the problem by modifying ReadFirstStageFstab()
function so that the failure is correctly reported back to the caller.
When it fails, DoCreateDevices() is not called.
Bug: N/A
Test: Watch TH
Change-Id: Idf2dbc6c0fb6c311ab3f5ff1f28315f7daa2b4ce
Androidboot parameters are being moved from the kernel commandline to
bootconfig.
fs_mgr looks for these parameters in properties and falls back to
reading directly from /proc/cmdline. So both of these sources are
updated for bootconfig.
The androidboot parameters from /proc/bootconfig
are added as ro.boot properties, and fs_mgr will fall back to searching
/proc/bootconfig if it is too early.
Test: boot cuttlefish with androidboot.fstab_suffix and
androidboot.hardware in bootconfig and not in cmdline.
Test: atest CtsFsMgrTestCases
Bug: 173815685
Change-Id: Iea36a0da94c26e1aa37d97c576725e0ad77cd3ad
The action reads a file with individual `export` actions declared on
each line, and calls `setenv` for each.
See go/updatable-classpath for details on how this is going to be used.
Bug: 180105615
Test: manual
Change-Id: I5390e52cf8ffd9c3babf31ed854eeecc727351eb
Add a property ro.boottime.init.modules to provide kernel modules
loading time in milliseconds. Also add corresponding log to show in init
log along with loaded module count.
Test: boot test
Bug: 178143513
Change-Id: I77e3939c2a271da6841350a8c2a34ad32f637377
The first-stage init has been built in Make due to some requirements
(like placing it directly under the root directory rather than bin/, and
creating mountpoints like /proc, etc.) that are not supported in Soong.
However, Ie06dc5a93635ea8b1e18be517ed8615b6c82fee6 will make it possible
to satisfy the requirements in Soong. The build of the boot image is
done in Soong and we can create mount points using the `dirs` property
and create a symlink /init that points to /bin/init_vendor using the
`symlinks` property.
To complete the picture of build everying in Soong, this change adds a
Soong-version of the first-stage init.
Note that the Soong-based boot image creation is currently only for the
microdroid usecase. Therefore, the Android.mk-based first-stage init
still remains and will be removed later.
Bug: 178562516
Test: m init_first_stage_soong
Change-Id: I278cb60a11d94fb48341fd3592be0652a25bdbfb
When there is a transition of daemon from selinux stage, we observe
intermittent hangs during OTA. This is a workaround wherein
we don't do the transition and allow the daemon to continue which
was spawned during selinux stage.
Bug: 179331261
Test: Incremental OTA, full OTA on pixel
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: I622a0ed8afcd404bac4919b1de00728de2c12eaf
This has been something the kernel does automatically since 2014, so
there's no obvious reason to add extra work during boot to duplicate
that effort.
Bug: http://b/179086242
Test: treehugger
Change-Id: I44cce99a892e4f2a6a303c2126bd29f955f5fb23
None of them are necessary, and it's more intention-revealing to say
`c++2a` or whatever anyway.
Test: treehugger
Change-Id: Ie1df26499d160d6fc757d17fcb0121997bda14f9
Revert submission 1563392-remove_art_from_bootstrap
Reason for revert: Bug: 179002105
Reverted Changes:
I65e2a2089:Remove ART APEX from the bootstrap apexes
Ic20df80e2:Remove ART APEX from the bootstrap apexes
Change-Id: I474ab95805c5ca28e0bba91f3d226e8db5a7a9ea
During device bringup, dynamic partitions may not be properly
configured by some sort of build or load misconfiguration. Diagnosing
such issues can be difficult without being able to see which partitions
are available and what they contain.
Aditionally, making logical partitions available to first stage console
permits early mounting of vendor partition and allows primitive
validation of vendor scripts without requiring full Android
environment. For instance, vendor_dlkm partition and modules can be
probed needing to have a full Android bootup.
Creation of logical partitions is done only when first_stage_console is
requested in order to have minimal impact on normal boot. Thus, only a
small refactor is required to split CreateLogicalPartitions out of
MountPartitions.
Bug: 174685384
Bug: 173732805
Change-Id: I828ce999be6d786bf46dd5655dfda81d046906ab
Signed-off-by: Elliot Berman <eberman@quicinc.com>
